Normalisatie module¶
Tijdens het experimenteren met de Demo op de Raspberry Pi bleek het omgevingslicht veel invloed te hebben op de correctheid van de OCR-module. Het bleek dat veranderd omgevingslicht voor schaduwen en andere ruis te zorgen, zowel als verminderd contrast op het scherm. Dit was hardware-matig simpel op te lossen door de Raspberry Pi in een doos te plaatsen met witte wanden en LED-strips voor een homogeen lichtveld.
Bij de demo bleek dat de product owner graag de doos vervangen zien worden door een software oplossing. Deze feature zou dan onderdeel worden van de preproccesor als module genaamd ‘normalisatie’.
Het onderzoek¶
De manier waarop de normalisatie gedaan moest worden was vooraf nog niet goed omgeschreven en wat de mogelijkheden zijn was ook niet duidelijk.
Om een overzicht te krijgen van wat normaliseren inhoud is er eerst gekeken naar het spectrum van de grijswaarden van een plaatje. Dit is een overzicht van de frequentie dat elke grijswaarde voorkomt.
Hieronder een overzicht van de onderzoek resultaten behaalt tijdens het experimenteren met de contrast in de plaatjes. Na een korte speurtocht leek een contrast verhogende functie uit de OpenCV bibliotheek een goede kandidaat hiervoor. Er zullen echter ook andere methoden zijn dan contrast verhogen, die hebben we niet bekeken.
Het onderzoek is opgebouwd uit de volgende stappen: Eerst de analyse van een enkele cijfer, in dit geval de nummer 3. Eerste een vergelijking tussen een gegenereerde 3 op witte achtergrond met behulp van cijfer generator en een gegenereerde 3 maar dan met een achtergrond vergelijkbaar met het display van de rekenmachine. Het resultaat is redelijke voorspelbaar en een leuke inleiding in het onderzoek.
Todo
Documentatie nummergenerator maken.
In het tweede deel zijn er 3 verschillende 3’en bekeken. De gegenereerde 3 op rekenmachine achtergrond, een foto van een 3 met goede verlichting condities en een foto van een 3 onder slechte verlichting.
In het derde deel is het onderzoek uitgebreid naar het gehele display. Hierin zijn meerdere versie bekeken. Het kleinst mogelijk getal qua segmenten en het grootste mogelijk getal qua aantal segment.
Introductie: Grijswaarde vergelijking¶
links de grijswaarde histogram van de 3 met witte achter grond en recht met solide zwart 3 met rekenmachine (korrelige) achtergrond. Hier het verschil tussen de voorgrond (de letter) en de achtgrond goed zichtbaar in beide plaatjes.
Introductie: Vergelijking met echte foto¶
- Drie varianten:
- links: rekenmachine achtergrond, ideaal zwarte karakter,
- midden: foto van rekenmachine onder goed verlichte omstandigheden,
- rechts: foto van rekenmachine in minder ideale verlichting dus zeer laag contrast en moeilijk leesbaar voor de mens.
Introductie: Histogrammen¶
Te zien is dat er zelfs bij weinig contrast nog steeds goed onderscheid gemaakt kan worden tussen voorgrond echt achtergrond pixels. Dit resulteert in het volgende plaatje:
Gehele beeldscherm (enkel getal)¶
Uit de analyse hierboven bleek dat het contrast tussen de voorgrond (het cijfer) en de achtergrond met de computer goed te bepalen.
Uit de volgende analyse moet blijven of dat met het gehele display ook kan.
Het bekijken van een enkele cijfer is zoals hierboven is redelijk recht vooruit.
Nu kunnen we er de equalizeHist overheen halen van OpenCV. Dan veranderen de histogrammen naar dit:
De bijbehorende plaatjes zijn dit:
Uit deze figuren kunnen we halen dat het middelste plaatje onbruikbaar is zoals het nu is. Het zwart van het cijfer is niet anders dan het zwart links op het scherm.
Gehele beeldscherm (meerdere getallen)¶
Het bekijken van een reeks 8 op het beeldscherm
Nu kunnen we er de equalizeHist overheen halen van OpenCV. Dan veranderen de histogrammen naar dit:
De bijbehorende plaatjes zijn dit:
Plaatjes vanuit de doos¶
Een foto van het display in de box met homogene verlichting.
Tesseract: .3 1 1 5 . …. 2214..21 1 11 53 19. . 15
Histogram van voor en na de ‘normalisatie’.
Het resultaat van de normalisatie:
Tesseract: 5 2 3 1 1 47 21 2 1 1 4 1
Het resultaat van een ‘goede’ threshold.
Tesseract: 2 7 4 3 33 545 2 9 1
Het resultaat van een ‘goede’ threshold op een genormaliseerd beeld.
Tesseract: 1 4 7 3 5 5 2 2
Normalisatie vs Goede threshold functie¶
Input
Output van bovenstaande plaatje door de normalisatie module
Tesseract resultaat met normalisatie: 5 2 9
Output ‘goede’ threshold, nu nog met de handbepaald dus dit moet nog geautomatiseerd worden:
Tesseract resultaat met threshold: 33 5 7288 38873 3 3
Het ‘goede threshold’ plaatje met wat extra poetsen, dit was ook nog handmatig, De randen van de het scherm zijn verwijderd verder niets.
Tesseract resultaat met threshold (opgepoetst): 99989995
Conclusie¶
Op de manier hierboven beschreven kunnen we niet concluderen dat de geïmplementeerde normalisatie significant de uitkomst van de OCR beter maakt (of slechter). De output uit de OCR van de verschillende plaatjes, met of zonder normalisatie en met of zonder threshold geven allemaal verkeerde resultaten.
De moeilijkheid zit in het bepalen van een ‘normaal’ spectrum, dus welke vorm moet de histogram hebben na de normalisatie. Hierboven staan er meerdere spectra en geen van deze lijken transformeerbaar naar een ‘normaal’ spectra.
Een mogelijkheid voor een volgende groep is dit onderzoek op te pakken door de normalisatie te combineren met de andere bewerkingen die in de preproccesor zijn verwerkt.
Dan nog een opmerking om de normalisatie in het geheel te plaatsen. Het doel van de preproccesor is een input plaatje om te zetten naar een plaatje waarvan de OCR het slecht 1 op de 100 000 keren het foute antwoord leest. De normalisatie zou hierbij de variatie in lichtinval moeten compenseren.
Aanbevelingen¶
Iets waar we wel mee bezig zijn geweest maar verder niets concreets mee hebben bereikt is de analyse van de RGB kanalen apart. Een voorbeeld kan zijn dat alle puur rode pixels als achtergrond gezien kan worden omdat deze onderdeel uitmaken van plastic materiaal van de rekenmachine.
Een tweede toevoeging aan deze test zou zijn om nog te kijken naar andere methode om te normaliseren. Denk hierbij aan het platslaan van de grafiek (ipv witwaardes toevoegen), of andere manieren om te egaliseren. OpenCV heeft ook nog een andere veelbelovende functie om te ‘normaliseren’, namelijk CLAHE. Hiervan staat een test scriptje in de TryOut map, compare_equalize.py, maar er was tijdens dit project niet genoeg tijd om hier verdere tests mee te doen.