I used the imglab exe to make the file with the boxes. while running the code to build the svm file on certain occasions it fails somewhere so i checked i changed the width and the height to random value it worked but that will increase the chances of misclassifications. How is it the bounding boxes are affecting this process of training?

Theres absolutely no error message the last check point is when it counts the no of images and then the crash

so is there a certain aspect ratio to maintained while drawing the bounding box over the object? because certain occasions the default window size 80 x 80 does not seem to work unless changed to 50 x 50. What features should be common? similar height, width , aspect ratio , area etc..

A few issues in the dlib compilation instructions for OS X:

In step 2, cmake should also be installed along with libjpeg.
You also will need XQuartz from http://xquartz.macosforge.org/ if you don't already have X installed.
Also, in step 5, "cmake .." is required before "cmake --build ."

Now I have the tools working, one practical note: you need a lot of high resolution pictures to make this work which makes it fairly problematic for improving the speed tagging in OSM compared to the old "mark waypoints on the GPS at speed limit changes and take notes" approach.

Using my Garmin Virb Elite my success rate at getting interval photos at its maximum rate (30 frames/minute) with 16 megapixel images that have enough resolution to reliably find a speed limit sign in images taken at anything over 30 mph is hit or miss at best. Picture 1 will often be too small and you've blown by the sign by the time picture 2 shows up. Alas it won't go faster than 30 frames/minute (1/2 fps) except in video mode, which is limited to 1080p (2 MP) but will time-lapse up to 2 fps.

My dashcam will get me the frame rate (up to 30 fps) but not the image quality (1-2 MP, and subjectively much worse than the Virb even in video mode). Plus it's a ton of image files to deal with and I'd have to correct the lens distortion adding extra processing to the mix.

My only other ideas are to train the classifier some more with crappier pictures or pointing the camera off-axis. Then I'll have to hack on train_object_detector to have do batch output rather than being interactive (should be easy enough) to make it a more practical tool.

Edit: after playing around a bit more, I've found that upsampling the images (using the -u command line parameter) from either the Virb or the dashcam improves the recognition rate at a distance substantially. So apparently the sign images don't have to be quite as spectacular as I thought and thus my initial pessimism may not be justified. 😄

FYI, I now have a working (but slow) implementation using the Python interface to dlib at https://github.com/lordsutch/MUTCDSpeedSigns

thanks a bunch for the guided steps. in the compilation instructions #5 for building the imglab tool, i think you are missing cmake .. before make --build .