davisking / dlib

A toolkit for making real world machine learning and data analysis applications in C++
http://dlib.net
Boost Software License 1.0
13.45k stars 3.37k forks source link

2:1 aspect ratio causes issue when running dnn_mmod_ex #299

Closed goranrauker closed 7 years ago

goranrauker commented 7 years ago

I filled some images with random noise and then zeroed out a rectangular portion of the image. I labeled the training and testing images using imglab (nice tool) and then started the training using the following command:

./dlib/examples/build/dnn_mmod_ex ./training_boxes/

After a few iterations, I get the following error.

num training images: 10 num testing images: 5 detection window width,height: 57,28 overlap NMS IOU thresh: 0 overlap NMS percent covered thresh: 0 step#: 0 learning rate: 0.1 average loss: 0 steps without apparent progress: 0 step#: 3 learning rate: 0.1 average loss: 29.5953 steps without apparent progress: 0 step#: 5 learning rate: 0.1 average loss: 20.9261 steps without apparent progress: 0 Encountered a truth rectangle with a width and height of 154 and 129. The image pyramid and sliding window can't output a rectangle of this shape. This is because the rectangle's aspect ratio is too different from the detection window, which has a width and height of 57 and 28.

I'm not sure how a truth rectangle is being generated of that size as all of my rects are constrained to 2:1.

See attached for my training files.
training_boxes.zip

davisking commented 7 years ago

The random_cropper in that example is randomly rotating the boxes. Turn that off if you want to have 2:1 boxes.

goranrauker commented 7 years ago

Thanks Davis! I'm new to dlib (love what I'm seeing here) and I apologize for the newbie issue :)

davisking commented 7 years ago

No worries :)

HBouchech commented 7 years ago

Hi Davis and thank you for dlib, am trying to use dnn_mmod_ex as well but facing a problem with "Truth rectangle" this is it: these are the four images am trying to use to learn a car number plate detector:

the aspect ratios are 4.15, 4.6, 4.08 and 4.41...i have selected the smallest box as target size which is 161*35 but i got an aspect ratio error as fellow: detection window width,height: 155,36 overlap NMS IOU thresh: 0 overlap NMS percent covered thresh: 0 step#: 0 learning rate: 10 average loss: 0 steps without apparent progress: 0 Encountered a truth rectangle with a width and height of 166 and 105. The image pyramid and sliding window can't output a rectangle of this shape. This is because the rectangle's aspect ratio is too different from the detection window, which has a width and height of 155 and 36. My main question is from where the truth rectangle 166*105 comes from, as you can see all provided boxes has less then 50 height.... Other strange behaviors i encountered are: 1- these two lines where not showing the same detection window width and height: 1.1 detection window width,height: 2.2 This is because the rectangle's aspect ratio is too different from the detection window, which has a width and height of ... 2- i managed one time to train on a different dataset with a initial learning rate 0.1 and patch size 20, but when i tried different initial learning rate of 10 and bigger patch size 30 i got the aspect ratio problem again though i kept the same dataset ....i believe that changing the learning rate should not generate a aspect ratio problem ! issue number 1 was solved by just restarting my computer !!! issue number 2 was not solved I appreciate Davis if you give me explanation to these questions and especially how are you generating the truth rectangles thanks
HBouchech commented 7 years ago

i post here the training boxes i used: box top='212' left='286' width='187' height='45' box top='235' left='237' width='161' height='35' box top='191' left='253' width='200' height='49' box top='138' left='275' width='172' height='39'

HBouchech commented 7 years ago

btw i have disabled flipping using cropper.set_randomly_flip(false);

davisking commented 7 years ago

You need to look at the crops coming out of the cropper. They apparently aren't what you think they are. There is an example program that shows you how to view them http://dlib.net/random_cropper_ex.cpp.html. Look at them and see what is going on.

HBouchech commented 7 years ago

Davis, thank you for your answer....yes the generated boxes were most of them ignored (orange color)...i have changed the min and max object height and most of the boxes are now accepted (red color)...but the main problem is still there, the randomly generated boxes didn't preserve the same aspect ratio as the provided initial boxes, i think during scale jittering dlib is not preserving aspect ratio ? am i wrong .....i have tested that for the box width=172, height= 39 and one of the generated boxes was width=373, height=64 ....hence a different aspect ratio of 4.41 and 5.8...in other samples the difference was even higher (i have disabled the random rotation )

davisking commented 7 years ago

See my comments on this issue https://github.com/davisking/dlib/issues/320

HBouchech commented 7 years ago

Thank you Davis for your time...i don't have a problem of truth rectangle outside image, but a truth rectangle that do not preserve the aspect ratio of the initial boxes, this way even if we get well located boxes inside image the aspect ratio problem will be always generated..

davisking commented 7 years ago

My answer is the same. Look at the mini-batches being created and see what is the problem. It must be that there are boxes you don't expect.

hexiangquan commented 7 years ago

Encountered a truth rectangle located at [(13, 112) (28, 153)] that is too close to the edge of the image to be captured by the CNN features. i do not how to address the problem?