OCR på räkningar

wulax, vad är syftet med att skanna den högraste delen?

 

Jag är inte säker på vad du menar. På de räkningar jag sett är delen längst till höger "(kontonumret) #(siffra)(siffra)#". Jag vet inte vad de fyra sista tecknen är till för ifall det är vad du menar. I aGirokoden ignorerade jag dem förutom i funktionen som känner igen vilken typ av nummerserie den skannar. Om den ser de fyra sista tecknen är de innan kontonummret. Kanske ett dåligt sätt att göra det på dock.

 

Ah! Jag som inte va tillräckligt observant. Ser nu att det är BG/PG-numret.

 

Okej, de fyra sista verkar vara "Bankgirots (och antagligen Plusgirots) interna kod för avier med komplett kodrad".
Här är en pdf som verkar innehålla all information som behövs för att avkoda teckenserien på fakturor. Se del 5.3.2:
http://www.bgc.se/upload/Gemensamt/Trycksaker/Manualer/BG6070.pdf

Det verkar också som att vissa referensnummer innehåller en "längdsiffra" förutom kontrollsiffran, typ 123456(8 längd)(2 kontroll). Ytterligare en sak som kan implementeras i aGiro.

 

Om vi hjälps åt att färdigställa de andra delarna så kanske appen får lite uppmärksamhet, och därmed förhoppningsvis lockar fler kunniga inom OCR-biten som kan optimera den vidare? Lite proof-of-concept ungefär.

 

Grabbar: Får ni detta att fungera är ni gudar!

 

wulax, skulle du kunna ge en kort intro till koden du har? Är nog bättre att höra direkt från dig än att sitta och försöka förstå på egen hand. Du använder zxing för bildskanning, men viss kod från det projektet verkar ligga under namespacet com.agiro.scanner.android. Hur mycket är det som zxing gör och vart i kedjan är det som din kod hoppar in?

 

Alla filer under com.agiro.scanner.android förutom BitmapParser, Normalizer och StringDecoder är modifierade versioner av Barcode Scanner. De filer från zxing jag inte behövt modifiera lade jag under com.google.zxing. Detta främst för att hålla koll på vilka filer jag modifierat. Då jag modifierat en från Barcode Scanner har jag skrivit att jag gjort det i licensdelen överst i filen. Jag är inte säker på hur man behandlar sådant om man ska vara helt laglig under Apachelicensen.

Kanske inte det bästa sättet att arrangera det egentligen.
Nå, i korthet fungerar det såhär:

BitmapParser: Läs beskrivningen jag gav den efter importraderna.
CaptureActivity: Aktiviteten som sköter GUI:et, start, stopp, resume och liknande.
CaptureActivityHandler: Skickar/tar emot meddelanden till/från CameraManager, CaptureActivity, DecodeThread, osv. (success, faliure, result, restart).
DecodeHandler: Tar bilder från CameraManager (kamerans previewbild) och säger åt BitmapParser att läsa dem. Skickar meddelande med resultat till CaptureActivityHandler om BitmapParser ger ett resultat. Annars ett faliuremeddelande.
DecodeThread: Jag är inte helt säker på hur denna fungerar, den behövde inte mycket modifiering innan den gjorde vad jag ville. Men jag antar att den skapar en tråd för dekodningsprocessen.
Normalizer: Innehåller bara 2 metoder för kontrast- och ljusändring.
StringDecoder: Ska läsa strängen som BitmapParser gav och avgöra vilka siffror som lästs in.
ViewfinderView: Ritar rutan och den grå bakgrunden i previewbilden.

Alla under *.camera: Gör i princip vad namnen antyder.

LuminanceSource och PlanarYUVLuminanceSource: Används i aGiro för att göra om kamerans YUV-bild till RBG. Kanske inte helt nödvändigt egentligen, men jag tyckte RGB verkade lättare att arbeta med.

Om du vill veta något mer specifikt så ställ en mer specifik fråga.

 

Så, det som zxing ger oss är egentligen kamerahanteringen (starta kameran, läsa in bild), rätt? Själva bildanalysen är skriven från scratch?

 

Det stämmer.

 

Något är märkligt. När jag gör en decodeResource på en av referensbilderna och läser ut storleken så är den 24x36 (inte 16x24). Oavsett vilken resurs jag läser in så stämmer inte storleken. En 500x500 som läses in blir 750x750. Vad beror detta på tro?

 

Hmm, intressant. Det verkar som att man måste sätta BitmapFactory.Options.inScaled till false för att den inte ska skala bitmaps efter skärmupplösningen (eller screen density). Detta hade jag ingen aning om och har inte använt i koden.

 

Ja, insåg detta när jag ritade ut referensbilderna under debugbilden. Man borde kunna räkna med bättre träffsäkerhet då kanske, efter denna fix.

 

Låg och funderade lite på webbdelen igår innan jag somnade. Borde man inte kunna generalisera hela den biten till att inte bara stödja just det här OCR-programmet? Den skulle ju kunna ta godtycklig text och mata in i aktivt fält på datorn. Med ett öppet API i andra änden så kan ju andra program också använda det för att skicka in text till datorn.

Vad gäller säkerhet så kan man tvinga användaren att "aktivera" mottagning av data på något sätt samtidigt som man fyller i en 4-siffrig kod som måste matchas av sändande applikation i andra änden. Likt Awesome Drop för er som testat det. Programmet skulle vara mottaglig för indata under en begränsad tidsperiod (fåtal minuter).

 

Blev enorm skillnad när jag slog av automatisk skalning.
Använder följande bild för test:


Utan fix:

Code:

01-09 10:43:35.601: DEBUG/BitmapParser(30642): Complete Result: 3045454304272224>4040225>

Med fix:

Code:

01-09 10:45:52.132: DEBUG/BitmapParser(30701): Complete Result: 102924216750000282#20008>

 

Utmärkt! Nu blev jag sugen på att fortsätta med programmet. Jag mergar in din fork. Ska försöka förbättra StringDecoder.parseString så att den blir lite vettigare och klarar flera teckenserier. Kanske lägga till någon liten PreferenceActivity också.

 

Jag gillar den idén. Det låter som ett ganska stort projekt, men om någon här kan skriva ett sådant program vore det nog perfekt. Som sagt har jag i princip ingen erfarenhet av sådant.

 

Jag gillar också idén om generiskt API, men brukar vis av erfarenhet börja i mindre skala så man inte tar sig vatten över huvudet och tappar intresset. Det kan ju alltid abstraheras senare i utvecklingen.

En tanke kring kopplingen och autentiseringen; Android-appen broadcastar en förfrågan på det anslutna lokala nätverket. PC-programmet snappar upp och kvitterar tillbaka, varpå en sifferkombination visas i telefonen som då ska matas in på PC:n.

När autentiseringen är avklarade borde efterföljande anslutningar mellan samma enheter skötas per automatik (cookies).

 

Jag kom just på att det kanske är onödigt för programmet att känna igen vilken nummerserie det skannar. Ifall det skickar resultatet omedelbart till markerat fält i datorn (efter det ev. kollar mod 10 för att veta att det skannat rätt) behöver det inte kunna skilja på referensnr, belopp, osv. Problemet med den metoden är dock att man inte kan skanna t.ex. både referensnr. och belopp samtidigt. Kanske ingen stor förlust?

Det hade nog varit en god idé att rita något sorts flödesschema för hur programmet ska fungera.

 

Bör man inte sträva efter att bara behöva läsa in hela fakturan en enda gång? En möjlighet är isåfall att läsa in precis hela kodraden, leta fältmärkena och inställningsmärket och sedan per position borde man kunna hitta samtliga fält.

Det kanske skulle underlätta övriga teckentolkningen om man i första hand letade yttersta fältmärket samt inställningsmärket?

Här är Plusgirots dokumentation av kodraden:
http://www.plusgirot.se/sitemod/upl...445_allman_beskrivning_inbetalningservice.pdf