jskye / car-classifier-research Goto Github PK

There has been further research built on the cascaded VJ approach to car detection. Han et al incorporated vertical edges, the car’s shadow and intensity during hypothesis generation and feature symmetry during verification for more accurate detection [19].

[19] Han, Sungji, Youngjoon Han, and Hernsoo Hahn. "Vehicle detection method using Haar-like feature on real time system." World Academy of Science, Engineering and Technology 59 (2009): 455-459.

Its not clear that this will always be effective. Some FP hypotheses will be symmetrical.
Also, some TP will be non-symmetrical if the training hasn't produced a symmetrical model (even though ideally it should be close to symmetric for frontbacks). But even in side cars, there is not complete shape symmetry.

This approach could be tried.

frontback training was done with original datasets that werent crop to the car. better models may be trained if this is done.

improve training samples by background subtraction for positives and better curation of natural to scene negatives

running side test:
python $DETECT_SCRIPT $TESTDATA_IMG_S_TESTSET $CLASSIFIER_DIR_S"/cars3.xml" $LABELLED_DATA_DIR_S"/uiuc_100.txt" $TEST_RESULTS_DIR_S $TEST_RESULTS_DIR_S $COLORSPACE 2 S
produces negative JI on last image. shouldnt be negative JI's.

this was because most of the time the bounding box (of the car) was outside the image size.
to fix this, we can just "take a step back" to "get a clearer picture", by embedding the image inside a bigger one such that the bounding box around the car can now be within the image.

currently labels are targeted to the experiment.
ie. frontback experiment uses only labels cars that should be recognisable as frontbacks.
should label all cars, and perhaps label if it is a frontback or side.

consider not comparing similarity (or relaxing JTHRESH) if hypothesis fully contains ground truth.

if we can see the sky, or some significant portion of it, then we shouldn't need to look for cars in say the top third of the image. of course, if we have a very good trained classifier wed assume this shouldnt be the case. but cascade classifiers are very sensitive to the training data so having post-hypothesis methods to screen out bad hypotheses is still often necessary.

consider change to use a standard labelling format.
eg. using sloth (json) or xml based

Negri, Pablo et al then fused Haar and HOG detectors to provide a better overall detector [21].
Similarly, Wang et al combined HOG and LBP features when applied to detecting humans.[22].
Hota et al introduced HOG and Gabor features at later stages of training to boost the final stages where traditionally learning tapers off [23]. They did this by nesting an SVM previously trained on these shape based features into the cascading classifier. This was utilising the nested approach introduced by Verschae et al [24].

Could be tried to boost detection.

improved detection by culling hypotheses inside other hypotheses.
this assumes sufficient training such that the outer hypotheses will be a car.
there shouldn't be a car within a car ("carception").

labelled data could include other objects.
currently, detection script says that any detection that isn't similar to a labelled car is a FP.
labelling other objects could be useful in determining whether a hard to classify object is indeed a car or not.

for detection with side cars, because they are more horizontal than vertical, cars are often deemed FP when they should be deemed TP (as seen by inspection) because JI is low due to verticality of detection rectangle.

a fix as go (agile, limited time) approach was used in developing this algorithm.
simple single tests were used to fix bugs along the way.
should be properly unit tested before used in live system.

main detect.py script was useful as script when small.
but now is big and needs to be made into a class with methods.

there still exists double counting that effects results.
example, here we can see two hypotheses that each require a minimum of 8 neighbored features.
but the two hyotheses are both counted as TP which is true (according to comparison criteria hyo:label), but there is only one car. these hypotheses should be merged into one.

rectangles are too simplistic for cases where cars are partially occluded by other cars. for example, the occluding car's features will be inside the comparison rectangle of the occluded object and will be wrongly considered when deciding if the occluded object is in fact a car.
a polygon label in this situation could be better.
this might be useful for polygon labelling.

append all results of detection runs to a single results file for easier viewing/export

a method that screens out hypotheses based on average size of hypotheses might be useful dependant on application. for example if the cars are lined in a row, and you either dont expect smaller sized ones in the background or dont care if theyre not detected, then you could assume the hypotheses are of the similar averaged size and reject all other sized hypotheses. You would have to ensure you reject the right average size though, probably the larger.

implement multi-detectors on multi-detect branch.
A detection (in a scene) should be able to use multiple detectors.

For example, a scene may have both front and back cars.
The front trained classifier should detect the fronts and the back trained detect the backs.

Also, different classifier types should be able to be utilised on the same detection