Skillnad mellan versioner av "Liggaren inläsning"
Från wpu.nu
| Rad 8: | Rad 8: | ||
Tabellinjerna förvirrar också OCR-algoritmen. Därför behöver man "klippa ut" endast texten i varje cell och sedan visa den för OCR-algoritmen separat. För att göra det för ca 300 000 celler behöver man en automatisk lösning. Det måste också klippas ganska noga eftersom texten är mycket nära tabellinjerna i liggaren. Om man klipper för mycket så försvinner bokstäver, klipper man för lite kommer ramen tolkas som bokstäver. | Tabellinjerna förvirrar också OCR-algoritmen. Därför behöver man "klippa ut" endast texten i varje cell och sedan visa den för OCR-algoritmen separat. För att göra det för ca 300 000 celler behöver man en automatisk lösning. Det måste också klippas ganska noga eftersom texten är mycket nära tabellinjerna i liggaren. Om man klipper för mycket så försvinner bokstäver, klipper man för lite kommer ramen tolkas som bokstäver. | ||
| − | Ett annat problem är maskningen. Den ställer till med problem på flera ställen. När tabellinjerna ska detekteras kan den förvilla. Om enstaka ord är maskade så ställer det till det för OCR-algoritmen eftersom den tappar linjen den ska läsa på. Jag använder dilation+erosion för att skapa en mask för att ta bort maskningen. Sedan detekteras konturer på maskningen för att avgöra dess position och storlek. När det är gjort ersätts den med ' | + | Ett annat problem är maskningen. Den ställer till med problem på flera ställen. När tabellinjerna ska detekteras kan den förvilla. Om enstaka ord är maskade så ställer det till det för OCR-algoritmen eftersom den tappar linjen den ska läsa på. Jag använder dilation+erosion för att skapa en mask för att ta bort maskningen. Sedan detekteras konturer på maskningen för att avgöra dess position och storlek. När det är gjort ersätts den med '{{Maskat|Längd=5}}' som funkar bättre för OCR. |
Trots detta är exaktheten inte tillfredsställande. För att öka den lite har jag tränat OCR-algoritmen (Tesseract 4) på liggaren för att den ska känna igen texten bättre, vilket den gör. Trots detta kommer texten ut med en del fel. Tex att vissa bokstäver ofta blir fel. A blir 4, I blir 1, rn blir m, osv. Detta kan till viss del fixas med rättstavning. Det gäller om det är korrekt fritext för vilken det finns korrekta ord. Ofta är det bara korta anteckningar med förkortningar. Dessa kan visserligen läggas in i en egen ordlista för att kunna känna igen dem, men... pga de korta förkortningarna och OCR-felen kan det vara svårt att få rätt. tex "ANK" är det en felstavad version av "ANKN" eller "ANG", det beror på. Ser man ett uppslagsnummer är det ''förmodligen'' "ANKN". | Trots detta är exaktheten inte tillfredsställande. För att öka den lite har jag tränat OCR-algoritmen (Tesseract 4) på liggaren för att den ska känna igen texten bättre, vilket den gör. Trots detta kommer texten ut med en del fel. Tex att vissa bokstäver ofta blir fel. A blir 4, I blir 1, rn blir m, osv. Detta kan till viss del fixas med rättstavning. Det gäller om det är korrekt fritext för vilken det finns korrekta ord. Ofta är det bara korta anteckningar med förkortningar. Dessa kan visserligen läggas in i en egen ordlista för att kunna känna igen dem, men... pga de korta förkortningarna och OCR-felen kan det vara svårt att få rätt. tex "ANK" är det en felstavad version av "ANKN" eller "ANG", det beror på. Ser man ett uppslagsnummer är det ''förmodligen'' "ANKN". | ||
| Rad 16: | Rad 16: | ||
Vilket av dessa är rätt? | Vilket av dessa är rätt? | ||
| − | PM, HUDDINGE PD,TUMBA BRUK UTR,PASS+VAPEN, 1982 | + | PM, HUDDINGE PD,TUMBA BRUK UTR,PASS+VAPEN, 1982 {{Maskat|Längd=3}} |
| − | PM HUDDINGE PD TUMBA BRUK UTR PASS+VAPEN,I982 | + | PM HUDDINGE PD TUMBA BRUK UTR PASS+VAPEN,I982 {{Maskat|Längd=3}} |
Det beror på. är I982 ett giltigt uppslagsnummer, och finns det i så fall i utredningen. Finns det något annat ställe i närheten som nämner "1982" eller "I982"? Om det hade stått "AUG I982", så borde det ju vara ett årtal, kanske är det det som gömmer sig bakom maskningen? Detta kan vara enkelt för en människa, men svårt för en algoritm. | Det beror på. är I982 ett giltigt uppslagsnummer, och finns det i så fall i utredningen. Finns det något annat ställe i närheten som nämner "1982" eller "I982"? Om det hade stått "AUG I982", så borde det ju vara ett årtal, kanske är det det som gömmer sig bakom maskningen? Detta kan vara enkelt för en människa, men svårt för en algoritm. | ||
Under tiden jag håller på med liggaren står det ganska still i övrigt med utvecklingen här på wpu. OCRning av dokument och allt annat ska/borde fungera :) | Under tiden jag håller på med liggaren står det ganska still i övrigt med utvecklingen här på wpu. OCRning av dokument och allt annat ska/borde fungera :) | ||
Nuvarande version från 23 december 2020 kl. 11.50
Hur går det med liggaren?
Framåt. Sakta.
Varför?
Dels handlar det om källmaterialet, dels om noggrannheten som krävs, dels om dokumentets storlek.
Tabeller är generellt svåra att översätta till text av lite olika anledningar. En sak är att textens position är viktig. Om tex en uppslagssiffra hamnar på fel rad blir informationen i stort sett oanvändbar. Tabellinjerna förvirrar också OCR-algoritmen. Därför behöver man "klippa ut" endast texten i varje cell och sedan visa den för OCR-algoritmen separat. För att göra det för ca 300 000 celler behöver man en automatisk lösning. Det måste också klippas ganska noga eftersom texten är mycket nära tabellinjerna i liggaren. Om man klipper för mycket så försvinner bokstäver, klipper man för lite kommer ramen tolkas som bokstäver.
Ett annat problem är maskningen. Den ställer till med problem på flera ställen. När tabellinjerna ska detekteras kan den förvilla. Om enstaka ord är maskade så ställer det till det för OCR-algoritmen eftersom den tappar linjen den ska läsa på. Jag använder dilation+erosion för att skapa en mask för att ta bort maskningen. Sedan detekteras konturer på maskningen för att avgöra dess position och storlek. När det är gjort ersätts den med '' som funkar bättre för OCR.
Trots detta är exaktheten inte tillfredsställande. För att öka den lite har jag tränat OCR-algoritmen (Tesseract 4) på liggaren för att den ska känna igen texten bättre, vilket den gör. Trots detta kommer texten ut med en del fel. Tex att vissa bokstäver ofta blir fel. A blir 4, I blir 1, rn blir m, osv. Detta kan till viss del fixas med rättstavning. Det gäller om det är korrekt fritext för vilken det finns korrekta ord. Ofta är det bara korta anteckningar med förkortningar. Dessa kan visserligen läggas in i en egen ordlista för att kunna känna igen dem, men... pga de korta förkortningarna och OCR-felen kan det vara svårt att få rätt. tex "ANK" är det en felstavad version av "ANKN" eller "ANG", det beror på. Ser man ett uppslagsnummer är det förmodligen "ANKN".
Detta gör också att vi har ett par hundra tusen celler som ska behandlas varje gång man kör igenom liggaren. Inte nog med att det behöver automatiseras. Det behöver kunna köras parallellt också på flera datorer med flera processorer. Jag har ett litet beräkningskluster här hemma, med några hundra CPU-kärnor, beroende på hur många datorer jag vill ha igång. På detta kan man köra igenom liggaren på några timmar. Men, resultatet är ännu ej tillfredsställande.
Vilket av dessa är rätt?
PM, HUDDINGE PD,TUMBA BRUK UTR,PASS+VAPEN, 1982 PM HUDDINGE PD TUMBA BRUK UTR PASS+VAPEN,I982
Det beror på. är I982 ett giltigt uppslagsnummer, och finns det i så fall i utredningen. Finns det något annat ställe i närheten som nämner "1982" eller "I982"? Om det hade stått "AUG I982", så borde det ju vara ett årtal, kanske är det det som gömmer sig bakom maskningen? Detta kan vara enkelt för en människa, men svårt för en algoritm.
Under tiden jag håller på med liggaren står det ganska still i övrigt med utvecklingen här på wpu. OCRning av dokument och allt annat ska/borde fungera :)