Skip to content

Conversation

lemairecarl
Copy link

I got -inf values in my target boxes, which propagated up to the loss. I tracked down this line in encode() where a log is taken on the width/height of the boxes. For some reason, some of my data-augmented boxes have zero-width (or height).

It probably happens in the data augmentation, when cropping, with boxes that are on the side of the image. One solution would be to look for zero-width/height boxes and remove them.

But I think it's a good practice to completely remove the risk of -inf by shifting the logarithm a tiny bit, like I do in my suggested change.

What do you think?

@rronan
Copy link

rronan commented May 12, 2018

I confirm I faced the same issue and fixed it the same way. Still don't know what is a good value for the "tiny shift" (@lemairecarl suggests 1e-10).

d-li14 added a commit to d-li14/ssd.pytorch that referenced this pull request Oct 15, 2018
@isthatyoung
Copy link

Thank you for your inspiration!!! My dataset has just 5 "dirty" data with zero width/height box, now my "inf" problem was solved, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants