MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Optimalizace DML-CZ OCR workflow BAKALÁŘSKÁ PRÁCE Radek Vystrčil Brno, jaro 2009
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: doc. RNDr. Petr Sojka, Ph.D. ii
Poděkování Zde bych chtěl poděkovat doc. RNDr. Petru Sojkovi, Ph.D., vedoucímu mé bakalářské práce, za poskytnutou odbornou pomoc a za podnětné rady a připomínky, které přispěly k úspěšnému vyřešení této práce. Také bych rád poděkoval ostatním řešitelům projektu DML-CZ za spolupráci při dosažení společného cíle. iii
Shrnutí Tato práce pojednává o řešení problémů s OCR v rámci projektu DML-CZ. Nejdříve je čtenář seznámen s principy OCR, jeho využitím obecně, i v rámci české digitální matematické knihovny. Další kapitoly se zabývají řešením problémů během OCR a jejich aktualizací. Dalším tématem je postup testování OCR založený na referenční sadě příkladů dobře rozpoznaných stránek (ground truth), vůči které se automatizovaně vyhodnocuje úspěšnost nových verzí OCR. iv
Klíčová slova OCR, DML-CZ, Workflow, FineReader, InftyReader v
Obsah 1 Motivace.............................. 1 2 Seznámení s OCR........................ 2 2.1 Co je OCR.......................... 2 2.2 Využití OCR......................... 3 3 Česká digitální matematická knihovna............ 4 3.1 Co je to DML-CZ...................... 4 4 OCR workflow.......................... 6 4.1 Současná podoba OCR workflow............. 6 4.2 FineReader Engine 8.1 SDK................ 7 4.3 InftyReader ver. 2.4.4.................... 7 4.4 Další nástroje tvořící OCR workflow........... 10 5 Aktualizace DML-CZ OCR................... 13 5.1 VMware........................... 13 5.2 Workflow........................... 13 5.2.1 Pomocné třídy................... 14 6 Porovnávání nových verzí OCR................ 15 6.1 Program ImlCompare................... 15 6.1.1 Struktura souboru iml............... 15 6.1.2 Princip práce ImlCompare............. 16 6.2 Testování Infty........................ 18 6.3 Výsledky........................... 19 6.4 Hodnocení.......................... 20 7 Závěr................................ 22 A Přílohy............................... 25 vi
Kapitola 1 Motivace Dnešní doba klade stále větší důraz na automatizaci jak ve výrobě, tak i v dalších oborech, jako například v informatice. Je to snaha o zrychlení, zjednodušení opakujících se triviálních úkonů, na které není třeba lidské úvahy. Jedním z mnoha podoborů snažících se o automatizaci je i tzv. zpracování přirozeného jazyka a zpracování digitálního obrazu, na jehož základech stojí OCR (Optical Character Recognition). Projekt DML-CZ ze zabývá vytvořením české matematické digitální knihovny, která by obsahovala množství matematických textů, jako jsou učebnice, sborníky, odborné publikace, časopisy apod., vydaných nejen před příchodem digitálních technologií, a tak zpřístupnila tyto materiály dnešním čtenářům, kteří by se k nim jinak těžko dostávali. V této práci se zaměřím na postup zpracovávání matematických textů a jejich převod do digitální podoby. Nejprve stručně představím OCR a jeho využití. V další kapitole bude následovat charakteristika české digitální matematické knihovny. Další kapitola se bude věnovat OCR workflow (toku práce) v rámci DML-CZ a jeho aktualizaci. Nakonec popíši postup automatizovaného testování výsledků různých verzí OCR. 1
Kapitola 2 Seznámení s OCR 2.1 Co je OCR OCR neboli optické rozpoznávání znaků [11] (z anglického Optical Character Recognition) je metoda, která nejčastěji pomocí skeneru (nebo také z elektronických dat) umožňuje digitalizaci tištěných textů, s nimiž pak lze pracovat jako s klasickým počítačovým textem. Nebo se též může jednat o převod obrázků znaků do standardní kódované podoby, která dané znaky reprezentuje (např. ASCII nebo UNICODE). Počítačový program převádí obraz bud automaticky, nebo se musí naučit rozpoznávat znaky. Převedený text je velmi často v závislosti na kvalitě předlohy třeba podrobit důkladné korektuře, protože OCR program nerozezná všechna písmena správně. OCR zpracování textu z tištěné do elektronické podoby je použitelné pro všechny tištěné výstupy z laserových, inkoustových, termosublimačních nebo jehličkových tiskáren a samozřejmě pro předlohy vytištěné knihtiskem. OCR [4, 5] je obvykle součástí složitějšího procesu, jehož úlohou je převod fyzicky existujícího dokumentu do elektronické podoby některého ze zaužívaných formátů na ukládání elektronických dokumentů. Tento proces většinou začíná digitalizací vstupního dokumentu (jak již bylo zmíněno, nejčastěji prostřednictvím skeneru), následovanou obrazovými úpravami na získaném obraze dokumentu, rozdělením dokumentu na bloky podle typu obsahu, rozpoznáním jednotlivých znaků v blocích (OCR), lexikálním postprocessingem a nakonec uložením ve zvoleném formátu. Častokrát se celý proces označuje jako OCR. Proces převodu dokumentu do digitální podoby se skládá z následujících kroků: 2
2. SEZNÁMENÍ S OCR 1. digitalizace předlohy, 2. provedení obrazových úprav, 3. segmentace dokumentu na bloky, 4. rozpoznávání bloků, 5. lexikální postprocessing, 6. uložení ve zvoleném výstupním formátu. Podrobněji popisuje jednotlivé kroky [5, 6, 9]. 2.2 Využití OCR Praktické využití OCR tkví nejen v tom, že převedený text zabírá řádově menší prostor, ale především je možné ho indexovat. To znamená, že ve výsledném souboru je možno vyhledávat text, kopírovat ho apod. Tím se nabízí možnost vzniku digitálních databází obsahujících dokumenty, které vznikly ještě před příchodem počítačové techniky a jejich elektronická verze tím pádem neexistuje. Samotné oskenování by nebylo dostačující, protože to neumožňuje v materiálech vyhledávat text a sekvenční procházení je u větších záznamů pochopitelně časově náročné. Zásadní výhodou oproti ručnímu přepisování je samozřejmě rychlost, resp. možnost dávkového zpracovávání, které je mnohem efektivnější než manuální metoda. I když současné verze OCR softwaru se na závěr rozpoznávacího procesu bez manuální korektury zatím neobejdou, je možnost využití OCR bezpochyby výhodnější. 3
Kapitola 3 Česká digitální matematická knihovna 3.1 Co je to DML-CZ Česká digitální matematická knihovna [3] (zkratka DML-CZ) je plnotextová digitální knihovna zaměřená na oblast matematiky. Jejím cílem je volně zpřístupnit na internetu nejvýznamnější českou matematickou literaturu, potenciálně jako součást plánované světové digitální matematické knihovny WDML World Digital Mathematics Library. Knihovna nabízí především časopisy (v současnosti jde o 10 časopiseckých titulů, včetně Časopisu pro pěstování matematiky a fysiky, vydávaného již od roku 1872), vybrané monografie (mimo jiné například sebrané spisy proslulého českého matematika Bernarda Bolzana) a sborníky matematických konferencí. Práce na DML-CZ započaly v roce 2005, dokončena bude v roce 2009. V současnosti knihovna zahrnuje již kolem 16 tisíc matematických článků (přes 160 000 stran textu) a v polovině června roku 2008 se dočkala oficiálního představení mezinárodní odborné veřejnosti. Vedle provádění vlastní digitalizace a budování uživatelské digitální knihovny jsou v projektu DML-CZ zkoumány i pokročilé technologie pro digitalizaci matematiky a vyvíjeny podpůrné softwarové nástroje. Na projektu DML-CZ spolupracují matematici, počítačoví specialisté, knihovníci a studenti pěti institucí: Matematického ústavu AV ČR (koordinace projektu), Knihovny AV ČR (digitalizace), Ústavu výpočetní techniky Masarykovy univerzity (integrace digitálních dokumentů a implementace digitální knihovny), Fakulty informatiky Masarykovy univerzity (OCR a začleňování aktuálních digitálních čísel časopisů) a Matematicko-fyzikální fakulty Karlovy univerzity v Praze (tvorba metadat). Více informací o projektu DML-CZ lze nalézt na http://dml.muni.cz a v [1, 2, 7, 8]. 4
3. ČESKÁ DIGITÁLNÍ MATEMATICKÁ KNIHOVNA Do DML-CZ jsou zařazovány materiály tří různých forem ze tří různých období: 1. Tištěné dokumenty: časopisy, monografie a sborníky vydané před rokem 1990 a existující obvykle pouze v tištěné podobě. Tyto dokumenty jsou skenovány, obrazy stránek jsou dále zpracovávány (prahování, odstraňování šumu, narovnávání, OCR), následně jsou seskupovány do článků a pro články jsou vytvářena popisná metadata. 2. Retro-born-digital dokumenty: materiály od počátku devadesátých let do současnosti. Tyto dokumenty již existují v nějaké digitální podobě, takže není třeba je skenovat. Digitální forma však není jednotná a často se v průběhu doby několikrát měnila i v rámci jednoho dokumentu (časopisu), takže je nezbytné konvertovat ji do požadovaného jednotného tvaru. Metadata lze obvykle extrahovat přímo z digitálních dokumentů, je však třeba přitom zohledňovat specifika a možnosti dané digitální formy. 3. Digitální dokumenty (born-digital): jde především o přebírání aktuálně vydávaných čísel časopisů. Cílem je vytvořit pro každý časopis mechanismus, kdy z nově publikovaného čísla časopisu je automaticky vygenerována i verze pro digitální knihovnu DML-CZ. Začleňování nově vydávaných časopiseckých čísel DML-CZ pak může probíhat automatizovaně, bez nutnosti dodatečné ruční práce. Digitální knihovna DML-CZ nevzniká jako izolovaný národní systém, je plně integrována do mezinárodního matematického prostředí. Články v DML-CZ a odkazy v seznamech referencí jsou provázány se záznamy a recenzemi v matematických referenčních databázích MathSciNet (Mathematical Reviews), Zentralblatt-MATH a Jahrbuch über die Fortschritte der Mathematik; knihovna DML-CZ nabízí uživatelské rozhraní a pro neanglické články jsou poskytována základní metadata v angličtině; jsou dodržovány mezinárodní standardy pro interoperabilitu v rámci připravované světové matematické digitální knihovny. Podobné národní matematické knihovny vznikají i v dalších zemích zmiňme alespoň francouzský NUM- DAM, http://www.numdam.org. 5
Kapitola 4 OCR workflow 4.1 Současná podoba OCR workflow OCR workflow v rámci DML-CZ je programová aplikace (vytvořená v jazyce Java) spojující několik samostatných programů pracujících izolovaně nad společnými daty jednoho dokumentu. Celý workflow se spouští pomocí příkazové řádky a běží pod systémem Windows XP. Workflow se skládá ze dvou samostatných programů zabývajících se OCR. Prvním z nich je produkt ukrajinské firmy Abbyy a nese název FineReader Engine 8.1 SDK (build 8.1.0.638; dále jen FR ), který se spouští jako první. Tento program se spouští dvakrát, nejprve se použije univerzální slovník, pomocí něhož jsou odhadnuty jazyky, ve kterých jsou dané bloky textu napsány. Při druhém průchodu FR použije vybrané slovníky na konkrétní bloky, a tím se zvýší úspěšnost rozpoznávání. Výstupem tohoto OCR je především dvouvrstvé PDF. První vrstva, která je viditelná uživateli, obsahuje původní obrázek pořízený skenováním. Ve druhé, neviditelné vrstvě, se skrývají znaky rozpoznané FR, umístěné přesně pod rozpoznávaným textem. Jako druhý přichází na řadu program InftyReader, který je dílem skupiny lidí kolem profesora Suzukiho z japonské univerzity v Kyushu. Ten se specializuje na matematiku, která by měla v budoucnu tvořit třetí vrstvu PDF. Dále workflow obsahuje několik tříd, které upravují diakritiku špatně rozpoznaných znaků, resp. spojují výstupy výše zmíněných programů. Jejich autory jsou Mgr. Mudrák a Mgr. Panák, viz [4, 5]. Použité verze programů jsou z roku 2006, a tak bylo třeba poohlédnout se po nových verzích. Navíc při skenování obrázků docházelo v programu FineReader občas k selhání (řádově jednotky 6
4. OCR WORKFLOW procent), a nedošlo tak k vytvoření dvouvrstvého PDF. Tento problém překonaly pozdější verze. K bližšímu porozumění workflow je třeba alespoň rámcově představit oba zmíněné programy. 4.2 FineReader Engine 8.1 SDK Komerční produkt ukrajinské firmy Abbyy je jedním z nejlepších sotwarů zabývajících se OCR na trhu. FineReader Engine [5] je software development kit umožňující integrování algoritmů a technologií programu FineReader z oblasti OCR, ICR (Intelligent Character Recognition, rozpoznávání rukou psaného textu) a rozpoznávání čárových kódů za účelem vytvoření vlastní 32bitové aplikace systému Windows. SDK implementuje jádro funkcionality produktu FineReader Professional, určeného koncovým uživatelům, a neposkytuje uživatelské rozhraní. FineReader Engine je tvořený množinou souborů DLL (Dynamic Link Library), které představují binární kód používaných algoritmů a technologií, a množinou podpůrných souborů, které obsahují další údaje používané při procesu OCR (definice zabudovaných jazyků, abeced, korekčních gramatických slovníků, atd.). Na rozdíl od verze Professional Edition nabízí možnost dávkového spouštění z příkazové řádky. Je tak vhodnější pro naše účely v rámci DML-CZ. 4.3 InftyReader ver. 2.4.4 Jedná se o software k rozpoznávání vědeckých dokumentů zahrnujících matematické výrazy. Je vyvíjený v laboratoři Masazaku Suzukiho, na univerzitě v Kyushu ve spolupráci s několika dalšími univerzitami. Software je k dispozici bezplatně pro všechny, kdo ho nehodlají využívat ke komerčním účelům. Program rozpoznává pouze binární (černé a bílé) stránky skenované v rozlišení bud 400 DPI, nebo 600 DPI. Vstupní formáty mohou být čtyři, a to PDF, TIFF, GIF a PNG. Pro kvalitní výsledky je zapotřebí, aby stránky byly naskenovány pečlivě, bez zbytečného šumu a nečistot, které mohou výsledky nepříjemně ovlivnit. Autoři uvádějí úspěšnost rozpoznávání matematických znaků a výrazů větší než 99 %. Slabým místem programu vzhledem k našim potřebám 7
4. OCR WORKFLOW je, že software ovládá pouze dva jazyky (angličtinu a japonštinu). Není tedy schopen vyhodnocovat diakritická znaménka, což bylo také předmětem zkoumání diplomových prací [4, 5]. InftyReader (viz [9], dále jen Infty ) je integrovaný OCR systém pro matematické dokumenty. Sestává se ze čtyř procedur: 1. analýza rozvržení textů, 2. rozpoznávání znaků, 3. strukturovaná analýza matematických výrazů, 4. ruční opravy chyb. V těchto procedurách je použito několik nových technik pro zlepšení rozpoznávacího výkonu. Zkušební výsledky provedené japonskými tvůrci na souboru 500 stránek matematických dokumentů ukázaly vysokou úspěšnost rozpoznávání znaků v matematických výrazech i obyčejných textech. Infty čte skenované stránky z matematického dokumentu a poskytuje jejich OCR. Protože Infty analyzuje strukturu matematických výrazů v dokumentu, může produkovat výsledek ve formátu L A TEX. Nové a nevšední aspekty Infty: rozpoznávání znaků se sestává ze dvou nezávislých a vzájemně se doplňujících částí, první je OCR procedura pro textové dokumenty a druhou tvoří procedura vyvinutá pro rozpoznávání matematických symbolů, rozlišení textových a matematických částí se provádí v první fázi a také používá výsledky rozpoznávání, analýza struktury je založena na optimalizačním rámci, a proto je robustní proti chybám při rozpoznávání a nejednoznačnostem v matematických výrazech, použití technik shlukování pro vyšší přesnost a efektivitu. 8
4. OCR WORKFLOW Obrázek 4.3: Diagram zpracování v InftyReaderu. Převzato z [9]. 9
4.4 Další nástroje tvořící OCR workflow 4. OCR WORKFLOW Důvod spojení dvou nezávislých programů byl jednoduchý. FR má dobré výsledky na čistě textových blocích, obsahuje podporu diakritických znaků, ale na matematických textech zpravidla selhává. Oproti tomu Infty se specializuje na matematiku, chybí mu však podpora české diakritiky a také podpora více jazyků. Pro rozpoznávání českých a slovenských textů je tak nevyhovující. Proto vznikla myšlenka tyto produkty nějakým způsobem spojit a vytvořit tak samostatnou aplikaci, tedy workflow (tok práce). Navíc v rámci svých diplomových prací Mgr. Panák a Mgr. Mudrák implementovali několik tříd (celý workflow je naprogramováno v jazyce Java), které upravují výstupy výše zmíněných programů tak, aby zlepšily schopnost rozpoznání skenů. Hlavními třídami podporujícími OCR workflow jsou tu především třída IMLCorrector, upravující výstup Infty a OCRJoiner, která spojuje výstupy FR a upraveného IML souboru po zpracování Infty- Readerem. Autorem třídy IMLCorrector je Mgr. Radovan Panák. Vzhledem k tomu, že Infty nepodporoval českou diakritiku, tak pokud při rozpoznávání znaků narazil na znak obsahující nějaký akcent (například háček), zapsal ho do výstupního IML souboru specifickým způsobem. Vytvořil vztah dvou samostatných znaků, kde bylo konkrétní písmenko spojené ve vztahu under (pod) příslušným akcentem. Navíc bylo dané místo uvedeno jako oblast matematiky, a nikoli klasického textu. Třída IMLCorrector zapisuje špatně rozpoznanou diakritiku jako jeden znak v kódování UTF-8. Navíc přesouvá tyto znaky z oblasti matematického na obyčejný text, který je velice efektivní pro další OCR zpracovávání. Podrobnější popis viz [5]. Třídu OCRJoiner naprogramoval Mgr. Tomáš Mudrák a jejím úkolem je spojit výstup programu FR ve formátu XML a upravený IML soubor zpracovaný Infty. Třída vyhledává v XML výstupu (FR) diakritické znaky a podle jejich pozice hledá příslušné znaky i v IML (Infty). Pokud se znaky neshodují, je znak v IML přepsán znakem z XML. O tom, zda bude znak přepsán, či nikoliv, rozhoduje parametr charconfidence. Udává míru pravděpodobnosti, s jakou byl znak rozpoznán správně. Na- 10
4. OCR WORKFLOW bývá hodnot od nuly do sta, kde 100 reprezentuje míru největší jistoty rozpoznání. Hodnota proměnné je nastavena na číslo 60. Jak je uvedeno v [4], jedná se o citlivé nastavení, jehož hodnota může výrazně ovlivnit výsledky OCR. Pokud hodnota charconfidence u příslušného znaku nepřesahuje prahovou hodnotu, znak nahrazen není. Podrobnější popis viz [4]. 11
4. OCR WORKFLOW Obrázek 4.4: Workflow zpracovávání OCR. Převzato z [5]. 12
Kapitola 5 Aktualizace DML-CZ OCR Jedním z hlavních úkolů mé práce bylo zajistit aktualizace jednotlivých částí workflow, a to nejen komerčních produktů, ale i zdrojového kódu binárky, která celý tok práce ovládá. 5.1 VMware Vzhledem k tomu, že OCR workflow běží pouze pod systémem Windows, je na FI nainstalovaný na virtuálním stroji, ke kterému se přistupuje přes nástroj VMware [10]. Na jaře 2009 došlo k aktualizaci z VMware 1.0 na 2.0. Změnil se také způsob přístupu ke vzdálenému stroji. Místo modulu VMware na terminálu počítače se nyní přistupuje přes webové rozhraní. Je pro to třeba mít nainstalovaný zásuvný modul VMware Remote Console Plug-in. S přechodem na vyšší verzi došlo také k zvýšení počtu virtuálních strojů z jednoho na nynější tři. To umožňuje mít nainstalované různé verze FR, resp. Infty současně. Při spouštění workflow je třeba mít aktivovanou licenci FR pro konkrétní stroj, protože Fakulta informatiky vlastní pouze jeden hardwarový klíč. 5.2 Workflow Díky stále trvající záruční lhůtě má Fakulta informatiky nárok na bezplatné aktualizace FR. V současnosti je na jednom z virtuálních strojů nainstalovaný nejnovější build 8.0.1.1193. V případě Infty podobnou možnost nemáme, a tak jsou novější verze k dispozici pouze v podobě sharewaru, který běží jen ome- 13
5. AKTUALIZACE DML-CZ OCR zenou dobu a na omezený počet stránek. Nejnovější verze 2.7.9 je nainstalována na jednom stroji spolu s poslední verzí FR. 5.2.1 Pomocné třídy OCR workflow se spouští pomocí souboru ocr_batch.jar. Třídou obsahující metodu main je Batcher.java, která spouští jednotlivé části OCR. Do této třídy jsem implementoval několik chybových hlášení pro snazší lokalizaci chyb v případě neúspěšného rozpoznání obrázků. Konkrétně jde o tato hlášení: přesný popis vstupních parametrů, vstupní adresář je špatně zadaný nebo prázdný, hodnota parametru je mimo interval. Dále jsem implementoval jeden povinný parametr, kterým lze nastavit spuštění pouze některých částí workflow. Nemusí se tak nutně spouštět programy nepotřebné pro požadovaný výstup. Přepínač je druhým parametrem spouštěcího souboru a jedná se o číslici nabývající celočíselné hodnoty od nuly do tří. Pro dané hodnoty se vykoná následující: 0 kompletní OCR (FR + Infty + pomocné třídy), 1 pouze FR, 2 pouze Infty, 3 FR + Infty (bez pomocných tříd). Příklad spuštění binárky přes příkazový řádek: C:\OCR>java -jar ocr_batch.jar c:\testfiles 0 14
Kapitola 6 Porovnávání nových verzí OCR Pro porovnání výstupních souborů InftyReaderu bylo třeba nalézt nástroj, který by přehledně vyhodnotil rozdíl v rozpoznání dvou shodných stránek různými verzemi programu Infty. To by výrazně zjednodušilo vyhodnocení, jak a v čem se jednotlivé verze liší, nebot doposud jedinou možností bylo stránky opravovat ručně. Ruční zpracování je časově velmi náročné, a tak není možné ho provádět na větším množství dat. Výsledky pak nemusejí být přesné. Pro zautomatizování této činnosti jsem se rozhodl vytvořit speciální program (ImlCompare), který posoudí vždy jednu dvojici stránek (výstupní soubory s příponou iml, out) a vyhodnotí, o kolik znaků či matematických symbolů se jednotlivé výstupy liší. 6.1 Program ImlCompare Jako programovací jazyk jsem zvolil C++, který je vhodný především díky rychlosti výpočtu. Program má tři povinné vstupní parametry. První dva jsou soubory, které se budou porovnávat, třetím parametrem je číslovka udávající toleranci souřadnic znaků v pixelech. Pokud není korektně zadána celočíselná hodnota, nastaví se automaticky na hodnotu 0. 6.1.1 Struktura souboru iml Jako první krok k vytvoření ImlCompare programu je třeba pochopit strukturu výstupního iml souboru. Jedná se o formát XML. Vyjma úvodní poznámky, udávající informace o autorech projektu, je celý obsah uzavřen do základního párového tagu <InftyDocument>. Uvnitř se nachází hlavička <head> 15
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR a tělo <body>, obsahující informace o všech rozpoznaných znacích. Ty se dělí na dvě kategorie: Textová: textová oblast je vždy ohraničena odstavcem <p>, jednotlivé znaky definuje tag <char>. Jeho hlavním atributem je ocrparam, udávající přesné souřadnice znaku. Matematická: tato oblast je definována analogicky podle textové. Pokud je znak rozpoznán jako matematický, je ohraničen v matematické oblasti <mblock>. Jednotlivé mat. znaky jsou reprezentovány tagem <munit>, který může dále obsahovat tag <mlink>, značící, že daný znak má nějaký index. Příklad textu v reprezentaci iml: <p>... <char ocrparam= 232,317,282,412,0 >Space</char> <char ocrparam= 387,1323,413,1376,0 >t</char>... </p> <mblock>... <munit italic= 1 ocrparam= 326,979,363,1019,0 >A <mlink type= rsub > <munit ocrparam= 372,999,399,1035,0 >2 </mlink></munit>... </mblock> V textové části je zápis pro mezeru a písmenko t, v matematické pak A 2. 6.1.2 Princip práce ImlCompare Úkolem programu je porovnat jednotlivé znaky mezi dvěma OCR výstupy různých verzí. Jednotlivé znaky jsou určeny čtyřmi souřad- 16
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR nicemi: left, top, right a bottom, udávajícími po řadě levou, horní, pravou a dolní hranici znaku v pixelech. Nabízí se jednoduchý způsob vložení znaků do paměti programu pomocí kontejneru <map>, kde klíčem by byly souřadnice znaku a hodnotou znak samotný. V praxi ale různé verze programů přidělují znakům mírně odlišné souřadnice. Odlišnost v souřadnicích stejných znaků by mohla způsobit velké rozdíly i mezi výstupy, které jsou ve skutečnosti velmi podobné. Jako řešení tohoto problému jsem se rozhodl zvolit klíčem pouze jednu ze souřadnic, a to souřadnici left, udávající místo levé hrany znaku. Je vhodnější než například souřadnice bottom (spodní hranice), protože tu mají společnou nebo velmi podobnou všechny znaky na stejném řádku. Z testů vyplynulo, že shodný parametr left mají na hustě popsané stránce A4 řádově jednotky znaků. I to způsobuje možné opakování hodnot klíčů, a tak bylo nutné místo kontejneru <map> použít <multimap>, který duplicitu klíčů povoluje. Hodnotou záznamu je celá souřadnice včetně samotného znaku odděleného mezerou. V první fázi program projde oba vstupní soubory a naplní dva kontejnery <multimap> znaky podle výše zmíněného principu. V případě, že se jedná o matematický znak, je na konec řetězce pro hodnotu záznamu přidán řetězec (Math), aby mohl program následně tento fakt rozeznat. Po naplnění je třeba oba kontejnery porovnat a zjistit, které znaky se shodují, které se liší, a které druhý soubor neobsahuje. Kontejnery automaticky řadí svoje záznamy podle velikosti klíčů (lexikograficky). V druhé fázi program postupně prochází první kontejner klíč po klíči pomocí cyklu for. Pro daný klíč je vyhledán klíč stejné hodnoty v kontejneru druhém. Kvůli možné odchylce souřadnice je tato hodnota pro druhý klíč snížena o nastavenou toleranci. Pokud je například hledaná hodnota klíče 355 a tolerance 2 pixely, je iterátor druhého kontejneru nastaven na hodnotu 353. V případě, že tuto hodnotu vůbec neobsahuje, je iterátor posunut na nejmenší vetší hodnotu. Poté se zkontroluje rozdíl mezi oběma klíči; pokud je menší než tolerance, je možné, že se jedná o hledaný znak. (V opačném případě je znak označen za nerozpoznaný druhým souborem a program po- 17
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR kračuje dalším znakem prvního kontejneru.) Následuje extrahování zbývajících souřadnic z hodnot obou záznamů a jejich porovnání. Pokud rozdíl mezi jednotlivými souřadnicemi nepřesáhne ani v jednom případě toleranci, program považuje umístění obou znaků za shodné a jsou porovnány jejich hodnoty. Při neshodě souřadnic program prochází sekvenčně druhý kontejner, dokud nenarazí na vyhovující umístění nebo rozdíl pravých hran znaků nepřesáhne toleranci. Každý nález je zaznamenáván do výstupního souboru, kam program nakonec zapíše celkové vyhodnocení výsledků. 6.2 Testování Infty Současný workflow využívá již starší verzi Infty (2.4.4) z roku 2006. Rozhodl jsem se ji porovnat s novější verzí 2.7.6 a nejnovější 2.7.9, dostupnou na internetu (http://www.inftyproject.org). Do testu byl zahrnut i výstup OCR workflow, tzn. Infty(2.4.4) upravený třídou ImlCorrector a spojený s FineReaderem 8.1 pomocí třídy OCRJoiner. Pro testování byly vybrány stejné obrázky, jaké použil Mgr. Panák ve své diplomové práci [5] na vyhodnocení přínosu nové verze workflow. Tyto obrázky (resp. jejich iml výstupy) jsem opravil tak, aby v nich nebyly žádné chyby. Představují tak vzorově rozpoznané stránky. Obrázky byly porovnávány po dvojicích vždy se svým vzorem. Každá odchylka znamenala chybu. Porovnával se počet shodně rozpoznaných znaků, záměna znaků a počet znaků, které nebyly rozpoznány, zvlášt pro textovou a matematickou část. Seznam testovaných stránek: Obrázek 1: ABA007001146421956000300059.tif.iml Obsah: Anglický text s matematickými výrazy. Obrázek 2: ABA007001146421970000200080.tif.iml Obsah: Francouzský text s matematickými výrazy. Obrázek 3: ABA007001146421976000100009.tif.iml Obsah: Anglický matematický text s blokem referencí. Obrázek 4: ABA007001146421976000100024.tif.iml Obsah: Anglický matematický text s blokem referencí. 18
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR Obrázek 5: ABA007001146421976000100064.tif.iml Obsah: Anglický text s matematickými výrazy. Obrázek 6: ABA007001146421976000100070.tif.iml Obsah: Anglický text s matematickými výrazy. Obrázek 7: ABA007001146421976000100082.tif.iml Obsah: Anglický text s matematickými výrazy. Obrázek 8: ABA007001146421976000300081.tif.iml Obsah: Anglický blok referencí. 6.3 Výsledky Sloupce tabulky Za, Mz, Ne, Mn představují záměnu znaků, záměnu matematických symbolů, nerozpoznané znaky a nerozpoznané matematické symboly. Verze Za Mz Ne Mn 2.7.9 3 0 0 0 2.7.6 6 1 0 0 workflow 41 40 41 20 2.4.4 41 40 41 20 Tabulka 6.1: Odchylky pro obrázek č. 1 Verze Za Mz Ne Mn 2.7.9 5 5 0 0 2.7.6 6 6 10 0 workflow 25 8 41 4 2.4.4 25 8 41 4 Tabulka 6.3: Odchylky pro obrázek č. 3 Verze Za Mz Ne Mn 2.7.9 11 6 0 0 2.7.6 9 6 0 0 workflow 12 28 19 16 2.4.4 12 28 19 16 Tabulka 6.5: Odchylky pro obrázek č. 5 Verze Za Mz Ne Mn 2.7.9 18 15 0 0 2.7.6 18 15 0 0 workflow 14 12 22 26 2.4.4 32 12 28 26 Tabulka 6.2: Odchylky pro obrázek č. 2 Verze Za Mz Ne Mn 2.7.9 22 1 0 0 2.7.6 29 0 0 0 workflow 24 10 52 0 2.4.4 24 10 52 0 Tabulka 6.4: Odchylky pro obrázek č. 4 Verze Za Mz Ne Mn 2.7.9 0 5 0 0 2.7.6 2 5 0 0 workflow 3 17 18 6 2.4.4 3 17 18 6 Tabulka 6.6: Odchylky pro obrázek č. 6 19
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR Verze Za Mz Ne Mn 2.7.9 0 18 0 0 2.7.6 0 18 1 0 workflow 9 30 28 3 2.4.4 9 30 28 3 Tabulka 6.7: Odchylky pro obrázek č. 7 Verze Za Mz Ne Mn 2.7.9 10 0 0 0 2.7.6 43 0 10 0 workflow 74 0 156 0 2.4.4 81 0 164 0 Tabulka 6.8: Odchylky pro obrázek č. 8 Z tabulek je vidět především velký rozdíl mezi verzemi 2.4 a 2.7 jak v počtu zaměněných, tak nerozpoznaných znaků. Většina testovaných obrázků je anglicky, a tak rozdíl mezi verzí 2.4.4 a OCR workflow najdeme jen u dvou obrázků obsahujících francouzskou, resp. českou diakritiku v referencích. Tím workflow stále předčí i nejnovější verze Infty, který (alespoň v sharewaru) rozpoznává pouze dva jazyky, a to japonštinu a angličtinu. Z jednotlivých hodnot byla následně vytvořena tabulka udávající procentuální úspěšnost všech verzí na výše zmíněných obrázcích: Obrázek 2.4.4 Workflow 2.7.6 2.7.9 1 93,13 % 93,13 % 99,66 % 99,85 % 2 94,65 % 95,70 % 98,10 % 98,10 % 3 96,03 % 96,03 % 98,88 % 99,49 % 4 96,36 % 96,36 % 98,77 % 99,03 % 5 96,67 % 96,67 % 99,34 % 99,25 % 6 97,85 % 97,85 % 99,66 % 99,76 % 7 96,32 % 96,32 % 99,00 % 99,05 % 8 85,19 % 86,09 % 96,80 % 99,40 % Dohromady 94,53 % 94,77 % 98,78 % 99,24 % Tabulka 6.9: Celková procentuální úspěšnost jednotlivých verzí 6.4 Hodnocení V tomto testu bylo naměřeno zlepšení OCR workflow oproti samotnému Infty 2.4.4 o 0,24 %. Novější verze 2.7.6 přinesla zlepšení o další 4,01 % a poslední 2.7.9 o 0,46 % na 99,24 %. Celkové výsledky hodně ovlivnil obrázek č. 8, obsahující pouze blok referencí, u kterých starší verze Infty identifikovaly některá slova 20
6. POROVNÁVÁNÍ NOVÝCH VERZÍ OCR kvůli interpunkčním znakům jako matematické oblasti. OCR workflow díky třídě ImlCorrector některé znaky správně opravil, novější verze 2.7 tato slova rozpoznaly jako text, a tak dosáhly i bez oprav lepšího výsledku. V porovnání výše zmíněných verzí je patrný velký pokrok jak v matematických, tak textových částech, kde starší verze nevykazovala dobré výsledky. Program ImlCompare zpracovává jen iml výstupy, a tak není možné porovnat výsledky se samotným FineReaderem. Počty zaměněných a nerozpoznaných znaků nejsou jediným výsledkem programu ImlCompare. Kompletní výsledky všech provedených testů jsou k dispozici na přiloženém CD. 21
Kapitola 7 Závěr Seznámil jsem se s postupy rozpoznávání textů (OCR), se stávající podobou workflow, jeho fungováním a pracoval na jeho dalším zlepšování. Byly přidány tři nové virtuální stroje na serveru apollo, na kterých jsou nainstalovány nejnovější verze programů tvořících OCR workflow. Do třídy Batcher.java byly implementovány některé chybové výstupy a možnost spuštění jen některých částí workflow. Programem ImlCompare byla vyhodnocena úspěšnost nových verzí Infty vůči té původní v OCR workflow. Z výsledků lze přesně vyčíst konkrétní rozdíly ve výstupních souborech Infty. Jako další krok ke zlepšení kvality OCR workflow vidím potřebu, aby Infty začal rozpoznávat více než dva jazyky (angličtinu, japonštinu), a tím zlepšil svoje výsledky na předlohách ostatních jazyků. 22
Literatura [1] Miroslav Bartošek and Vlastimil Krejčíř. Jak se dělá digitální matematická knihovna. In Sborník konference AKP 2007, Liberec, Czech Republic, 2007. dostupné (květen 2009) na http://dml.muni.cz/docs/akp2007-sbornik.pdf. [2] Miroslav Bartošek, Martin Lhoták, Jiří Rákosník, Petr Sojka, and Martin Šárfy. DML-CZ: The Objectives and the First Steps. In Jonathan Borwein, Eugénio M. Rocha, and José Francisco Rodrigues, editors, CMDE 2006: Communicating Mathematics in the Digital Era, pages 69 79. A. K. Peters, MA, USA, 2008. [3] M. Bartošek. Česká digitální matematická knihovna. Masarykova univerzita, Ústav výpočetní techniky, Brno, May 2008. prezentováno na konferenci o profesionálních informačních zdrojích, Praha. [4] T. Mudrák. Digitalizace matematických textů [diplomová práce]. Fakulta informatiky, Brno, 2006. dostupné (květen 2009) na http://theses.cz/id/cyy7hk/. [5] R. Panák. Digitalizácia matematických textov [diplomová práce]. Fakulta informatiky, Brno, 2006. dostupné (květen 2009) na http://theses.cz/id/t0ob8h/. [6] P. Sojka and J. Rákosník. From Pixels and Minds to the Mathematical Knowledge in Digital Library. Masaryk University, Brno, 2008. [7] Petr Sojka. From Scanned Image to Knowledge Sharing. In Klaus Tochtermann and Hermann Maurer, editors, Proceedings of I-KNOW 05: Fifth International Conference on Knowledge Management, pages 664 672, Graz, Austria, June 2005. 23
7. ZÁVĚR Know-Center in coop. with Graz Uni, Joanneum Research and Springer Pub. Co. [8] Petr Sojka, Radovan Panák, and Tomáš Mudrák. Optical Character Recognition of Mathematical Texts in the DML-CZ Project. Technical report, Masaryk University, Brno, September 2006. Presented at CMDE 2006 conference in Aveiro, Portugal. [9] M. Suzuki, F. Tamari, R. Fukuda, S. Uchida, and T. Kanahori. INFTY: an integrated OCR system for mathematical documents. Kyushu University, Japan, 2008. [10] VMware, Inc. VMware. dostupné (květen 2009) na http://www.vmware.com/. [11] Wikipedie, otevřená encyklopedie. OCR. dostupné (květen 2009) na http://cs.wikipedia.org/wiki/ocr. 24
Příloha A Přílohy K bakalářské práci je přiloženo CD. V kořenovém adresáři je složka ImlCompare, obsahující zdrojové soubory programu i jeho spustitelnou binárku. Dále složky test a results, obsahující zdrojové soubory a jejich výsledky. Ve složce Batcher je aktualizovaný zdrojový kód třídy Batcher.java. Součástí je i PDF dokument s textem bakalářské práce ve složce thesis. 25
A. PŘÍLOHY Porovnani souboru: 9\9ok.iml 9\9a.iml Zvolena tolerance: 10 pixelu ----------------------------------------- Prvni soubor: Pocet znaku: 1733 Pocet matematickych znaku: 230 ----------------------------------------- Druhy soubor: Pocet znaku: 1692 Pocet matematickych znaku: 268 ----------------------------------------- Shoda u znaku: 1667 Shoda u matematickych znaku: 218 Zamena u znaku: 25 Zamena u matematickych znaku: 8 Nerozpoznane znaky: 41 Nerozpoznane matematicke znaky: 4 ----------------------------------------- Druhy soubor znak nerozpoznal 156,553,199,652,0 Space 167,352,190,412,0 l (Math) Shoda 156,691,199,731,0 a 156,691,198,730,0 a Druhy soubor znak nerozpoznal 156,1834,200,1912,0 Space 167,352,190,412,0 l (Math) Shoda 156,1950,186,2000,0 t 156,1950,185,1999,0 t Shoda 157,2065,190,2105,0 r 157,2065,189,2104,0 r Shoda 158,1362,202,1402,0 a 158,1362,201,1401,0 a Shoda 160,957,204,1014,0 0 (Math) 160,957,203,1013,0 0 (Math) Shoda 161,459,203,519,0 b 161,459,202,518,0 b Shoda 161,2713,185,2774,0 bigleftpar 168,2713,184,2773,0 bigleftpar Druhy soubor znak nerozpoznal 161,2799,201,2864,0 Space 182,1597,234,1617,0 = (Math) Shoda 161,3066,184,3126,0 bigleftpar 161,3066,183,3124,0 bigleftpar Druhy soubor znak nerozpoznal 161,3155,203,3206,0 Space 182,1597,234,1617,0 = (Math) Shoda 162,2889,186,2951,0 bigleftpar 169,2889,185,2950,0 bigleftpar Druhy soubor znak nerozpoznal 162,2977,202,3039,0 Space 182,1597,234,1617,0 = (Math) Shoda 162,3419,185,3479,0 bigleftpar 168,3419,184,3478,0 bigleftpar Druhy soubor znak nerozpoznal 162,3507,202,3569,0 Space 182,1597,234,1617,0 = (Math) 26
A. PŘÍLOHY Shoda 163,1449,217,1508,0 F 163,1449,216,1507,0 F Shoda 163,1696,197,1735,0 r 163,1696,196,1734,0 r Shoda 163,2259,206,2317,0 b 163,2259,205,2316,0 b Znak 163,3243,186,3304,0 bigleftpar zamenen na 163,3243,185,3303,0 [ (Math) Druhy soubor znak nerozpoznal 163,3330,202,3392,0 Space 182,1597,234,1617,0 = (Math) Shoda 164,2172,205,2212,0 o 164,2172,204,2211,0 o Shoda 165,3594,186,3656,0 bigleftpar 169,3594,185,3655,0 bigleftpar Znak 167,3683,189,3741,0 i zamenen na 167,3683,188,3740,0 f Shoda 168,1060,226,1121,0 A 168,1060,225,1120,0 A Shoda 168,1275,183,1313,0 i (Math) 168,1275,182,1312,0 i (Math) Shoda 170,888,183,925,0 i (Math) 170,888,182,924,0 i (Math) Shoda 182,1598,235,1618,0 = (Math) 182,1597,234,1617,0 = (Math) Shoda 187,786,252,879,0 sum (Math) 187,786,251,878,0 sum (Math) Shoda 188,2891,221,2940,0 2 188,2891,220,2939,0 2 Znak 188,3244,220,3294,0 4 zamenen na 188,3244,219,3293,0 4 Math) Shoda 189,3068,217,3117,0 3 189,3068,216,3116,0 3 Shoda 190,3421,216,3470,0 5 190,3421,215,3469,0 5 Shoda 190,3597,219,3646,0 6 190,3597,218,3645,0 6 Shoda 191,1175,257,1267,0 sum (Math) 191,1175,256,1266,0 sum Math) Shoda 193,2714,212,2764,0 1 193,2714,211,2763,0 1 Shoda 194,1282,228,1309,0 < (Math) 194,1282,227,1308,0 < Math) Shoda 194,1942,235,2001,0 h 194,1942,234,2000,0 h Shoda 194,2046,212,2105,0 i 194,2046,211,2104,0 i Shoda 194,3686,221,3735,0 7 194,3686,220,3734,0 7 Ukázka výstupního souboru programu ImlCompare 27