Hello, dear viewers!
Thanks for a great framework! An ecosystem is truly impressive in general.
I work on a few-shot detector and in the task I want to solve amount of objects I want neural network to find on an image may be reduced to 1, which results in a much severe imbalance of possible positive/negative boxes for RPNHead classification loss than usual. My neural network is based on the Mask R-CNN, I use a standard RPNHead. During training, RPNHead classification loss does not drop to zeros even after days of a training time. This leads to a severe training problem for second-stage Mack R-CNN components.
It seems that MaxIoUAssigner does not match boxes correctly for RPNHead. The reason is an additional check for low-quality boxes if the IoU is higher than min_pos_iou. See code line here.
I have found implementation of the same method in Detectron2 (link) where this check is absent.
Moreover, in Sec. 3.1.2 of Faster R-CNN paper, set of boxes with max overlap with a GT box are all considered positive not considering IoU lower min_pos_iou. These boxes in truth may be called low-quality but FAIR does not tell a word about comparison to IoU.
Also, there is a complete Guide to build Faster RCNN in PyTorch on Medium where authors tell in details how to match the boxes, read after words "Faster_R-CNN has some guidelines to assign labels to the anchor boxes...".
It would great to reveal if it`s a bug or a specific functionality. In the last case, I propose to add some additional flags to control the selection of low-quality boxes.
Hello, dear viewers!
Thanks for a great framework! An ecosystem is truly impressive in general.
I work on a few-shot detector and in the task I want to solve amount of objects I want neural network to find on an image may be reduced to 1, which results in a much severe imbalance of possible positive/negative boxes for RPNHead classification loss than usual. My neural network is based on the Mask R-CNN, I use a standard RPNHead. During training, RPNHead classification loss does not drop to zeros even after days of a training time. This leads to a severe training problem for second-stage Mack R-CNN components.
It seems that
MaxIoUAssignerdoes not match boxes correctly forRPNHead. The reason is an additional check for low-quality boxes if the IoU is higher thanmin_pos_iou. See code line here.I have found implementation of the same method in Detectron2 (link) where this check is absent.
Moreover, in Sec. 3.1.2 of Faster R-CNN paper, set of boxes with max overlap with a GT box are all considered positive not considering IoU lower
min_pos_iou. These boxes in truth may be calledlow-qualitybut FAIR does not tell a word about comparison to IoU.Also, there is a complete
Guide to build Faster RCNN in PyTorchon Medium where authors tell in details how to match the boxes, read after words "Faster_R-CNN has some guidelines to assign labels to the anchor boxes...".It would great to reveal if it`s a bug or a specific functionality. In the last case, I propose to add some additional flags to control the selection of low-quality boxes.