Project Blog

“Time flies when you’re having fun” – en zo kon het gebeuren dat de Google Summer of Code zomaar alweer helemaal voorbij was. Bedankt voor eenieders support, goede ideeen, en straatnaamborden.

De afgelopen week ben ik bezig geweest met naar een final toewerken van de signFinder. Het geheel is nu voorzien van aanmerkelijk duidelijkere code, die in de vorm van een library makkelijk in andere software gebruikt kan worden, en is er een stable versie online gezet in een tarball. Bovendien is er nu een verzameling documentatie, waarmee het voor iedereen duidelijk moet kunnen worden hoe de software werkt, en hoe deze voor eigen doeleinden gebruikt kan worden.

Is het hiermee dan helemaal afgelopen? – Nee, natuurlijk niet. Met name met roestige borden e.d. is er nog best wat te winnen aan nauwkeurigheid, en ik verwacht in mijn vrije tijd gewoon door te blijven bouwen aan het programma. Daarnaast wil ik natuurlijk iedereen aanmoedigen om dit product te gaan gebruiken. Daarom zullen Stefan en ik binnekort een website + webservice openen voor de signFinder, zodat iedereen eenvoudig de resultaten kan zien en kan gebruiken voor andere doeleinden.

Nog goede ideeen voor praktische toepassingen voor dit product? Laat een reactie achter!

Enkele weken geleden rapporteerde ik over de eerste pogingen om signFinder verkeersborden te laten lezen. Inmiddels is de software met sprongen vooruit gegaan. Zie hier de resultaten.

Om te beginnen heb ik de tesseract OCR netjes in de software geintegreerd. De gelezen tekst wordt in dit geval naast de borgen afgedrukt, maar kan natuurlijk ook zo na een database geschreven worden.

Daarnaast zijn de resultaten enorm verbeterd. Ik meet performance als het percentage van de borden die correct gedetecteerd worden in mijn eigen testset, dat vervolgens zonder enige fout door de OCR gelezen worden. Een stukje software wat dit getal genereerde, rapporteerde voor de initiele versie 42% performance.

Ik ben begonnen met de laatste versie van tesseract (2.04) te installeren. Dit zou performance moeten verbeteren, en bovendien kan ik hiermee een Nederlandse language file gebruiken. In eerste instantie was dit flink vloeken: zelfs met Nederlandse language file zakte de performance onmiddelijk naar slechts 24%. Vreemd genoeg bleek deze versie van tesseract, in tegenstelling van wat ik de vorige blogpost vermeldde, beter overweg te kunnen met greyscale images dan met de gegenereerde binaire images. Performance: rond de 58%.

Het is stom hoe de eenvoudigste oplossingen je soms weken kunnen ontschieten; In de vorige blogpost had ik het over het verbeteren van het contrast tussen de letters en de blauwe bordachtergrond. Nu worden deze plaatjes in RGB formaat opgeslagen, en de achtergrond heeft natuurlijk vooral brightness in het blue channel! Ik genereer nu mijn greyscale plaatje over alleen het red channel, en dit verbeterd het contrast behoorlijk.

eerst:

nu: Performance: Van 58% naar 75%

Dan zijn er van de 25% borden niet correct gelezen worden, veel borden met kleine foutjes. l wordt gezien als I, ruis zorgt, met name aan het begin en het eind, voor wat extra letters, enzovoort. Nu weten we een aantal dingen over verkeersborden die we kunnen gebruiken: Woorden op borden beginnen doorgaans met een hoofdletter, of zijn volledig in hoofdletters. Hoofdletters komen niet zomaar midden in een woord voor. We verwachten geen woorden van slechts een karakter, en bovendien beginnen borden vaak met een lidwoord.

Ik heb de vorige heuristieken toegevoegd, om kleine ocr-foutjes op te kunnen lossen:

• Woorden van 1 karakter worden verwijderd.
• Een I midden in een woord wordt in een l veranderd.
• Eerste woorden, die met minder dan 2 veranderingen (Levenshtein distance) in ‘De’ of ‘Het’ kunnen veranderen, doen dat.

Met deze simpele heuristieken, gaat performance op mijn testset van 75% naar 92%!

Nu is het belangrijk te beseffen dat hier overfitting optreed; Ik heb fouten die ik zag optreden in mijn testset opgelost, en daarmee heb ik een set heuristieken die met name helpen deze testset correct te detecteren. Desalnietemin: een performance tussen de 75% en 90% lijkt me zeer mooi. Als we nu alleen nog een breder scala aan straatnaamborden konden detecteren..

Deze week ben ik bezig geweest met het lezen van de straatnaamborden. Hier een eerste preview.
Ik gebruikt momenteel de open-source OCR engine Tesseract.

In eerste instantie heb ik gekeken hoe de prestaties zijn met de greyscale-images van de borden, zonder enige verdere processing.

Deze methode kan van de 22 borden die gevonden worden in de eerste testset, er zes correct lezen.

De engine is behoorlijk gevoelig. Het volgende plaatje wordt perfect herkend:terwijl hij niet eens meer tekst kan halen uit dit plaatje:

Enkele pogingen om het contrast te verbeteren maken de resultaten alleen maar slechter. Ook logisch: Tesseract blijkt zelf vrij geavanceerde image-processing aan boord te hebben.

Dat moet toch beter kunnen. Volgende poging: Het segmenteren van letters met de color-histogram-matching die ook gebruikt wordt om de borden te vinden.

Hier werkt tesseract een stuk beter mee, en slaagt er in om en nabij de helft van de borden goed te lezen.

Dit zorgt wel ook weer voor andere problemen.

De ruis om de ‘de’ heen, maakt dat de OCR dit bord leest als: J^_D$gg-Barkentijn
De volgende stap is nu om kleine ruis weg te filteren met blob detection. Ik hou jullie op de hoogte!

Vorige week ben ik voornamelijk bezig geweest met het uitsnijden van de verkeersborden, en het corrigeren van het perspectief zodat de letters er ‘zo recht mogelijk’ uitkomen en door OCR software gelezen te kunnen worden.

Tot mijn verbazing was het aanmerkelijk lastiger dan verwacht om aan de hand van de convex hull (het lijntje om borden heen) een plaatje uit te snijden: Het is verre van triviaal om de hoeken te vinden in een ruizig, vervormd, en mogelijk niet helemaal netjes omlijnt vierkant. Na diverse methoden geprobeerd te hebben, gebruik ik uiteindelijk de OpenCv GoodFeaturesToTrack functionaliteit. Als input voor de functie vul ik de convex hull om het bord heen in een los plaatje met wit op een zwarte achtergrond. Omdat corners nu eenmaal good features to track zijn (en lijnen niet), vindt deze functie netjes alle hoeken. Vervolgens sorteer ik de hoekpunten aan de hand van de punten in de convex hull.

Resultaat van het uitsnijden van borden.

Tot slot kan opencv plaatjes corrigeren voor perspectief aan de hand van vier hoekpunten. Linksonder het uitgesneden resultaat.
Merk ook op hoe kleine verschuivingen in de gevonden hoekpunten, meteen zorgen dat het bord minder ‘recht’ uitgesneden wordt.