Ignoring annotations outside of an image

[AldusLorde]

Hi! What is the purpose of doing so? You are trying to ignore anchors whose centres are outside of an image, but according to your code, generated anchors just can't be outside of the image. It's mentioned in the Faster R-CNN paper that cross-bounding anchors are ignored (but FPN doesn't ignore them). Another strange thing there is that you compare x coordinate with the height, not width.
Also, I checked your code and it seems that you doesn't shift width and height of anchors by 1 (pixel ranges are inclusive from both sides and so on, compute_overlap.pyx contains a good example of such shifting)

[hgaiser]

There's multiple questions there, I'll try to split them up:

Hi! What is the purpose of doing so? You are trying to ignore anchors whose centres are outside of an image, but according to your code, generated anchors just can't be outside of the image.

Generated anchors can't be outside the image batch, but the image batch can have caused a margin around some images. If you have images of different ratios, e.g. an image of shape (500, 500) and an image of shape (500, 400), then the latter image will get padded with zeros to match the shape of the former.

Another strange thing there is that you compare x coordinate with the height, not width.

We encode our boxes as (x1, y1, x2, y2), but batches are shaped (B, H, W, C). Perhaps anchors_center should be ordered (x, y) to make it comparable to anchors, but currently it is (y, x) because of the image batch.

Also, I checked your code and it seems that you doesn't shift width and height of anchors by 1 (pixel ranges are inclusive from both sides and so on, compute_overlap.pyx contains a good example of such shifting)

Hmm interesting point. I worked out the code treating the x2 and y2 as exclusive, but it seems indeed that compute_overlap.pyx treats them inclusive (this code is borrowed from py-faster-rcnn). Do you see any harm in changing compute_overlap.pyx to be exclusive?

[AldusLorde]

I see, thank you)

Hmm interesting point. I worked out the code treating the x2 and y2 as exclusive, but it seems indeed that compute_overlap.pyx treats them inclusive (this code is borrowed from py-faster-rcnn). Do you see any harm in changing compute_overlap.pyx to be exclusive?

A tough question. Unfortunately I'm not that skilled to give a correct answer. I came across this information while searching for a solution https://stackoverflow.com/a/57247833

[AldusLorde]

Generated anchors can't be outside the image batch, but the image batch can have caused a margin around some images. If you have images of different ratios, e.g. an image of shape (500, 500) and an image of shape (500, 400), then the latter image will get padded with zeros to match the shape of the former.

Have you considered the Darknet approach?
AlexeyAB/darknet#232 (comment)

It uses single size images and there are lots of ways to resize image (with keeping the aspect ratio or not) in this framework.

[hgaiser]

Hmm our approach is basically the same as their second approach, with the exception that they center the image. I'm not sure what the effects of that would be, I would image it doesn't matter much.

[AldusLorde]

Hmm our approach is basically the same as their second approach, with the exception that they center the image. I'm not sure what the effects of that would be, I would image it doesn't matter much.

They use a fixed-size network so all images have equal spatial dimensions,

[cl2227619761]

what about just clamp the size within the image, instead of ignoring them

[stale]

This issue has been automatically marked as stale due to the lack of recent activity. It will be closed if no further activity occurs. Thank you for your contributions.