Digitalizácia matematických textov

}w
!"#$%&'()+,-./012345<yA| M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Digitalizácia matematických textov D IPLOMOVÁ PRÁCE Radovan Panák Brno, jaro 2006 Prehlásenie Prehlasujem, že táto diplomová práce je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Vedúci práce: RNDr. Petr Sojka, Ph.D. ii Pod’akovanie Ako prvému by som sa chcel pod’akovat’ vedúcemu práce RNDr. Petrovi Sojkovi, Ph.D. za vypísanie tejto témy ako diplomovej práce, za vedenie práce a za prínosné rady a podnety, ktoré mi pri riešení práce pomáhali. Ďalej sa chcem pod’akovat’ Bc. Tomášovi Mudrákovi za výbornú spoluprácu pri riešení spoločných problémov a skvelú komunikáciu pri zostavovaní spoločného riešenia. V neposlednom rade sa chcem pod’akovat’ ostatným riešitel’om projektu DML-CZ za ochotu a výbornú spoluprácu na riešení projektu. iii Zhrnutie Práca sa venuje riešeniu problému OCR projektu digitálnej matematickej knižnice DML-CZ. Špecifické požiadavky vyplývajúce zo spracovania za účelom vytvorenia digitálnej matematickej knižnice si vyžiadali zvláštny prístup. Podobne aj spracovanie matematických textov si vyžaduje špeciálny prístup k niektorým problémom. Ciel’om práce bolo umožnit’ automatizované spracovanie OCR v rámci projektu. Množstvo problémov sa podarilo uspokojivo vyriešit’, niektoré zostali čiastočne otvorené do budúcna. Zrejmé je, že procesy zabezpečujúce OCR je nutné pri automatizovanom dávkovom spracovaní objemov dát úrovne DML-CZ priebežne vylepšovat’ a prispôsobovat’ novým podmienkam. Implementácia riešení jednotlivých problémov je popísaná podrobnejšie. iv Kl’účové slová OCR, FineReader, InftyReader, XML, DML-CZ, automatická detekcia jazyka v Obsah 1 Motivácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Úvod do OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Čo je OCR? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 História a využitie . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 OCR – prevod dokumentu do digitálnej podoby . . . . . . . . . . 2.3.1 Digitalizácia dokumentu . . . . . . . . . . . . . . . . . . . . 2.3.2 Vykonanie obrazových úprav . . . . . . . . . . . . . . . . . 2.3.3 Segmentácia dokumentu na bloky a kategorizácia blokov 2.3.4 Rozpoznávanie blokov . . . . . . . . . . . . . . . . . . . . . 2.3.5 Lexikálny postprocessing . . . . . . . . . . . . . . . . . . . 2.3.6 Uloženie vo zvolenom výstupnomm formáte . . . . . . . . 2.4 OCR matematiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Špecifiká OCR matematiky . . . . . . . . . . . . . . . . . . 2.4.2 InftyReader . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Analýza potrieb OCR pre DML-CZ . . . . . . . . . . . . . . . . . . . . 3.1 Projekt DML-CZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Ciel’ projektu . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Riešitelia a ich úlohy . . . . . . . . . . . . . . . . . . . . . . 3.2 Návšteva Digitalizačného centra Knižnice Akadémie vied ČR . . 3.2.1 Skenovanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Book Restorer . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 IrfanView . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Sirius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Návrh a implementácia riešenia OCR . . . . . . . . . . . . . . . . . . . 4.1 Rozdelenie úloh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Ciele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 FineReader Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Dôvody použitia . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Popis FineReader Engine . . . . . . . . . . . . . . . . . . . 4.3.3 Implementované riešenie . . . . . . . . . . . . . . . . . . . 4.4 Automatická detekcia jazyka . . . . . . . . . . . . . . . . . . . . . 4.4.1 Dôvody použitia . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Porovnanie rôznych prístupov a nástrojov . . . . . . . . . 4.4.3 Implementované riešenie . . . . . . . . . . . . . . . . . . . 4.5 Inteligentné spojovanie výstupov OCR . . . . . . . . . . . . . . . . 4.5.1 Trieda IMLCorrector . . . . . . . . . . . . . . . . . . . . . 4.5.2 Trieda OCRJoiner . . . . . . . . . . . . . . . . . . . . . . . 4.6 Workflow OCR a dávkové spracovanie . . . . . . . . . . . . . . . 4.7 Pomocné triedy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 3 3 4 5 5 5 6 7 7 8 10 10 10 11 13 13 14 14 16 17 19 19 20 20 20 21 24 31 31 32 32 33 34 36 36 39 vi 4.8 Testovanie implementovaného riešenia 4.8.1 Metodika testovania . . . . . . . 4.8.2 Výsledky . . . . . . . . . . . . . . 4.9 Možné zlepšenia . . . . . . . . . . . . . 5 Záver . . . . . . . . . . . . . . . . . . . . . . . Bibliografia . . . . . . . . . . . . . . . . . . . . . . A CD príloha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 41 44 46 47 48 vii Kapitola 1 Motivácia Projekt DML-CZ predstavuje snahu o vytvorenie Digitálnej matematickej knižnice Českej republiky. Digitalizácia množstva matematických kníh, periodík a článkov nepredstavuje jednoduchý problém. V rámci projektu existuje hned’ niekol’ko problémových oblastí, ktorým treba venovat’ zvýšenú pozornost’, ak má projekt uspiet’. Jednou z nich je oblast’ OCR. Špecifické problémy OCR charakteristické pre spracovanie matematických dokumentov, ktoré má byt’ čo najväčšou mierou automatizované, vyžadujú množstvo vynaloženého úsilia pri implementácii a testovaní ich riešení. Pri tomto procese sa môžu zúročit’ poznatky z rôznych oblastí informatiky, ako sú napríklad spracovanie digitálneho obrazu a spracovanie prirodzeného jazyka, ako aj schopnosti vzájomnej spolupráce viacerých riešitel’ov v rámci väčšieho celku. 1 Kapitola 2 Úvod do OCR 2.1 Čo je OCR? Skratka OCR (Optical Character Recognition; optické rozpoznávanie znakov) najčastejšie označuje proces prevodu vysádzaného, prípadne strojom alebo rukou písaného textu do strojovo upravovatel’nej podoby s využitím optických charakteristík znakov, alebo prevod obrázkov znakov do štandardnej kódovacej schémy, ktorá dané znaky reprezentuje (napr. ASCII alebo UNICODE). OCR je obvykle súčast’ou zložitejšieho procesu, ktorého úlohou je prevod fyzicky existujúceho dokumentu do elektronickej podoby niektorého zo zaužívaných formátov na úschovu elektronických dokumentov. Tento proces väčšinou začína digitalizáciou vstupného dokumentu (najčastejšie prostredníctvom skeneru) nasledovanou obrazovými úpravami na získanom obraze dokumentu, rozdelením dokumentu na bloky podl’a typu obsahu, rozpoznávaním jednotlivých znakov v blokoch (OCR), lexikálnym postprocesingom a nakoniec uložením vo zvolenom formáte. Častokrát sa celý proces označuje taktiež OCR. Optické rozpoznávanie znakov (s použitím optických nástrojov, ako sú zrkadlá a šošovky) a digitálne rozpoznávanie znakov (používajúce digitalizačné zariadenia, ako skenery atd’., a počítačové algoritmy) boli spočiatku považované za rozdielne obory. Z dôvodu zániku väčšiny aplikácií používajúcich čisto optické techniky bol význam termínu OCR rošírený, aby pokrýval aj digitálne rozpoznávanie znakov. 2.2 História a využitie Existuje niekol’ko názorov na to, kde hl’adat’ začiatky optického rozpoznávania znakov. Niektoré zdroje [1] dokonca ako začiatky uvádzajú ešte dobu dávno pred vznikom prvého počítača, rok 1809, kedy boli udelené prvé patenty na prístroje pre pomoc slepcom. V roku 1912 získal Emmanuel Goldberg patent na prístroj, ktorý čítal znaky, transformoval ich do štandardného telegrafového kódu a následne vysielal po telegrafnom vedení bez zásahu človeka. Možnost’ komerčného využitia sa ale začala objavovat’ až v pät’desiatych rokoch 20. storočia, v začiatkoch počítačového priemyslu. V roku 1950 v AFSA (Armed Forces Security Agency, predchodca americkej NSA – United States National Security Agency) mala skupina kryptoanalytikov za úlohu navrhnút’ procedúry pre automatizáciu spracovania dát v agentúre[4]. Riešenie tochto problému zahŕňalo prevod vytlačených správ do strojového jazyka pre d’alšie počítačové spracovanie. 2 2.3. OCR – PREVOD DOKUMENTU DO DIGITÁLNEJ PODOBY Jeden z členov skupiny, David Shepard, o pár rokov neskôr založil Intelligent Machine Research Corporation, ktorá následne uviedla prvé OCR systémy do komerčnej prevádzky. Prvý systém bol inštalovaný v roku 1955 v Reader’s Digest. Prvé komerčné aplikácie zahŕňali rozpoznávanie nápisov na kreditných kartách za účelom vystavovania účtov, rozpoznávanie informácií na telefónnych účtoch a rozpoznávanie poštového smerovacieho čísla za účelom triedenia pošty. Praktickým využitím OCR je očividne umožnenie automatizácie spracovania dát s pomocou počítačov, a teda aj jeho urýchlenie. Počítačové spracovanie textu d’aleko prevyšuje možnosti ručného spracovania. S čoraz väčším stupňom informatizácie zároveň narastá aj potreba zadávania údajov do počítača. Užívatel’ské rozhrania počítačových programov niekedy nie sú dostatočne použitel’né pre hromadné vkladanie údajov, prípadne niekomu neposkytujú komfort alebo účelnost’ kombinácie pero a papier. Niekedy dokonca možnost’ vloženia údajov do počítača hned’ pri ich vzniku neexistuje. S ohl’adom na výhody počítačového spracovania teda vyplýva problém prevodu dát do počítačom spracovatel’nej formy. Prvou možnost’ou je manuálne prepisovanie údajov do počítača, ktoré ale môže narazit’ na spomínané problémy užívatel’ských rozhraní, okrem toho je neefektívne, nekonomické a relatívne pomalé. Všetky spomínané nevýhody pri použití OCR odpadajú, pričom poskytuje možnost’ dosahovania relatívne vysokej presnosti rozpoznávania. 2.3 OCR – prevod dokumentu do digitálnej podoby Ako sme už zistili v úvode, proces prevodu dokumentu do digitálnej podoby pozostáva z nasledujúcich krokov: 1. 2. 3. 4. 5. 6. digitalizácia dokumentu, vykonanie obrazových úprav, segmentácia dokumentu na bloky, rozpoznávanie blokov, lexikálny postprocesing, uloženie v zvolenom výstupnom formáte. Dostupné OCR programy sú schopné začat’ proces v l’ubovolnom z bodov 1 až 4. V prípade, že nechceme začat’ bodom 1, musíme sa postarat’ o predchádzajúce kroky sami (pomocou iných programov). 2.3.1 Digitalizácia dokumentu Prvý krok procesu predstavuje získanie (digitalizácia) dát, s ktorými d’alej pracujú nasledujúce kroky. Vstupom tochto kroku je papierový dokument, výstupom je rastrový obraz zodpovedajúci dokumentu. Najčastejšie sa na digitalizáciu používa skener, môže sa však použit’ aj digitálny fotoaparát alebo podobné zariadenie. Niektoré skenery dokument nesnímajú sekvenčne, no namiesto toho dokument fotia (zosnímajú celý naraz). Tieto skenery 3 2.3. OCR – PREVOD DOKUMENTU DO DIGITÁLNEJ PODOBY majú snímací prvok vo väčšej vzdialenosti od snímanej predlohy, vd’aka čomu nie je potrebné použit’ príliš vel’ký a nákladný snímač. Parametrami tochto kroku sú použité rozlíšenie a farebný hĺbka. Rozlíšenie sa udáva v jednotkách DPI (počet bodov na 1 palec, teda 25,4 mm). Odporúčané minimum je 300 DPI. Ako farebný priestor pre výsledný obraz nám budú väčšinou postačovat’ odtiene šedej. V prípade, že dokument obsahuje farebné obrázky, ktoré chceme vo výsledku zachovat’ v rovnakom, alebo aspoň podobnom farebnom podaní, môžeme použit’ iný farebný priestor. Nastavenie týchto parametrov môže mat’ vel’ký vplyv na výslednú úspešnost’ celého procesu. Pri príliš nízkom rozlíšení môžu obrazy písmen strácat’ detaily a v závislosti od predlohy dokonca aj čiastočne splývat’, resp. dotýkat’ sa, a proces rozpoznávania môže v dôsledku tochto podávat’ horšie výsledky. Vyššia farebná hĺbka taktiež poskytuje pre rozpoznávanie väčšie množstvo detailov. Nastaveniam vhodným pre naše účely sú rozobraté v [3]. 2.3.2 Vykonanie obrazových úprav Vstupom pre tento krok je obraz získaný v predchádzajúcom kroku, výstupom je obraz po aplikácii určitých úprav. Úpravy vykonané v rámci tochto kroku do vel’kej miery závisia na kroku predchádzajúcom. V prípade digitalizácie celej knihy po dvojstranách a bez porušenia väzby dochádza u výsledného obrazu k deformácii riadkov smerom k väzbe knihy. Riadky nie sú rovné, čo môže robit’ problémy v d’alších krokoch spracovania. Je preto vhodné obraz narovnat’ pomocou algoritmov geometrickej korekcie. Niektoré OCR programy tento typ úprav vykonávajú automaticky bez zásahu užívatel’a. Danú funkciu môžeme nájst’ aj v softvéri dodávanom k niektorým typom skenerov, alebo v softvéri špecializujúcom sa na obrazové úpravy pri digitalizácii dokumentov. Pri digitalizácii po dvojstranách je v závislosti na našich požiadavkách na formátovanie výstupu OCR vhodné obrazy rozrezat’ na jednotlivé strany. Ďalšou vhodnou úpravou je orez stránky. Pri digitalizácii dostaneme okrem obrazu textu, ktorý je hlavným predmetom nášho záujmu, aj obraz jeho okolia, často prázdneho miesta na papieri. Toto prázdne miesto (prevažne sa jedná o bočné okraje) je z pohl’adu d’alšieho spracovania väčšinou nezaujímavé, a teda je zbytočné uchovávat’ si jeho obrazovú podobu. Táto úprava má väčší význam hlavne pri hromadnom spracovaní vel’kých objemov obrazových dát, kde je ušetrená disková kapacita nezanedbatel’ná. Okrem ušetrenia diskového priestoru orezom zároveň skracujeme čas spracovania obrazu v d’alších krokoch, pretože zbytočné infromácie sú z obrazu už odstránené. Existujú aj prípady, ked’ je orez nežiaduci, hlavne z dôvodu potreby zachovania pôvodného vzhl’adu stránky. Možnost’ou, ako zbavit’ obraz šumu, je binarizácia. Binarizácia je prevod obrazu na čiernobiely. Vel’ké množstvo šumu pôvodného viacfarebného obrazu sa stratí, no zároveň dochádza k strate určitej informácie, obrazy znakov sa stanú zubatými. Väčšinou je výhodnejšie ponechat’ procesu rozpoznávania viac informácii a farebnú hĺbku obrazu neznižovat’. Ďalšie možné úpravy sú napríklad zmena jasu, kontrastu, sýtosti, odtieňu, svetlosti farieb a iné. 4 2.3. OCR – PREVOD DOKUMENTU DO DIGITÁLNEJ PODOBY 2.3.3 Segmentácia dokumentu na bloky a kategorizácia blokov Vstupom je obraz po vykonaných úpravách, výstupom je obraz spolu s informáciou o rozmiestnení blokov a ich typoch. Pod pojmom blok rozumieme súvislú čast’ vstupného obrázku obsahujúcu z vizuálneho hl’adiska totožné prvky dokumentu, ako napríklad odstavec (skupinu odstavcov) textu, tabul’ku, prípadne obrázok. Blok má tvar obdĺžnika, prípadne zložitejšieho útvaru, ktorý môžeme dostat’ ako zjednotenie viacerých obdĺžnikov (po zjednotení sa jedná o 1 súvislý útvar). V dokumente je blok od svojho okolia ohraničený prázdnym miestom. V d’alších krokoch sa rozpoznávanie rôznych typov blokov môže zásadne líšit’, pretože v snahe vylepšit’ výsledky rozpoznávania sú často implementované rozličné postupy pre rôzne typy blokov. Blok obsahujúci obrázok (napr. ilustrácia) v dokumente napríklad do výsledku prejde nezmenený, prípadne iba s miernymi obrazovými úpravami závislými na nastaveniach programu (požadovaná farebná hĺbka, výstupný formát atd’.), zatial’ čo obsah textového bloku prejde procesom rozpoznávania znakov. Pri hl’adaní blokov sa využíva hlavne fakt, že blok je oddelený od svojho okolia (v podstate ohraničený) prázdnym miestom. Kedže je nežiaduce, aby každý riadok textu skončil v samostatnom bloku, musí sa rozlíšit’ medzi prázdnym miestom ohraničujúcim blok a prázdnym miestom medzi dvoma po sebe idúcimi riadkami. Vzhl’adom k dobrým typografickým zvyklostiam býva prádzne miesto ohraničujúce blok podstatne väčšie. Pri kategorizácii blokov sa používajú špecifiká jednotlivých typov blokov (ohraničenie tabul’ky čiarami, . . . ). 2.3.4 Rozpoznávanie blokov Zameriame sa na popis spracovania textových blokov. Vstupom je obraz dokumentu spolu s informáciou o blokoch. Výstupom je rozpoznaný text bloku. V tomto kroku sa využíva užívatel’om zadaná informácia o jazyku dokumentu, ktorá určuje tok textu, a teda aj ovlyvňuje d’alšie rozpoznávanie. V d’alšom popise sa budeme venovat’ prípadu dokumentu v niektorom zo stredoeurópskych jazykov. Textový blok je rozdelený na horizontálne pásy predstavujúce jednotlivé riadky. Tieto pásy sa môžu čiastočne prekrývat’ (vid’ obrázok 2.1). Nasleduje rozpoznávanie znakov v rámci jednotlivých riadkov. Pri rozpoznávaní samostatných znakov sa využívajú hlavne vzory znakov, informácie o pomere výšky a šírky znaku a frekvencie výskytov znakov (prípadne v závislosti na uvedenom jazyku). 2.3.5 Lexikálny postprocessing Vstupom je text rozpoznaný v predchádzajúcom kroku, výstupom upravený text. Podl’a užívatel’om špecifikovaného jazyka dokumentu sa na text aplikuje korektor pravopisu. Celý proces prebieha poloautomatizovane s možným zásahom užívatel’a. Tento krok spracovania je napríklad v programe FineReader vel’mi podobný procesu gramatickej 5 2.3. OCR – PREVOD DOKUMENTU DO DIGITÁLNEJ PODOBY korektúry prítomnej v niektorých kancelárskych softvérových balíkoch (konkrétne v textových procesoroch). V dialógovom okne sa spracovávajú kandidáti (slová) na nahradenie. Pre každé nahradzované slovo má užívatel’ zobrazený rozpoznaný text, navrhované slovníkové korektúry a výrez obrázku spracovávanej strany, v ktorom je umiestnený obraz písmen príslušného slova. Užívatel’ má na výber z viacerých možností. Môže korektúru daného slova ignorovat’, čo má za následok pokračovanie procesu na d’alšom slove. Samozrejme užívatel’ môže vybrat’ korektúru slova nahradením z ponúkaných možností. V prípade, že bolo slovo rozpoznané nesprávne, no v danom slovníku sa nevyskytuje, môže opravu užívatel’ špecifikovat’ manuálne a jednoducho ju pridat’ do slovníka. Užívatel’ má pri procese zároveň možnost’ výberu práve používaného slovníka. 2.3.6 Uloženie vo zvolenom výstupnomm formáte Vstupom je rozpoznaný text po vykonaných korekciách, výstupom je dokument uložený v súbore zvoleného formátu. Najčastejším dôvodom OCR je lepšia archivácia dokumentov, ich úprava a l’ahšie vyhl’adávanie konkrétneho obsahu, prípadne poskytovanie dokumentov d’alej elektronickou formou. Existuje množstvo formátov, ktoré môžeme použit’ ako výstupný formát celého procesu (konkrétne formáty závisia od použitého programu): HTML, PDF, Open Document, Microsoft Word, Rich Text Format, plaintext a iné. Pre d’alšiu editáciu dokumentu je prichádzajú vhod formáty Open Document, Rich Text Format, Microsoft Word, prípadne plaintext. Kedže formát plaintext je iba obyčajný text v zvolenom kódovaní, poskytuje minimum informácii o členení dokumentu a jeho pôvodnej vizuálnej podobe (vel’kost’ písma, okraje stránky, použitý font atd’.) a neumožňuje uložit’ obrázky. Jeho použitie je teda zriedkavé. V prípade formátu Microsoft Word sa jedná o (v dobe písania tejto práce) uzavretý formát plne podporovaný iba v produktoch firmy Microsoft, i ked’ použitel’ná podpora existuje aj v konkurenčných produktoch. Pre určité prípady môže formát postačovat’, jeho použitie je teda potrebné zvážit’. Formát Rich Text je síce zastaralý, no stále môže poskytovat’ potrebné vlastnosti. Nejedná sa o uzavretý formát, jeho špecifikácia je známa. Open Document formát je relatívne novým otvoreným formátom, ktorý bol štandardizovaný skupinou OASIS a neskôr bol prijatý ako ISO štandard. Formát bol vytvorený s ciel’om poskytnút’ štandard pre formát (nielen) textových procesorov, aby sa ul’ahčila výmena a úprava dokumentov takéhoto typu. V prípade, že nepožadujeme editáciu dokumentu, sa javí ako ideálny formát PDF, ktorý sa postupne stal v podstate štandardným formátom pre poskytovanie a výmenu dokumentov na Internete. Dokumenty vo formáte PDF sa dajú optimalizovat’ pre prehliadanie na Internete a poskytujú rôzne pokročilé možnosti kompresie vložených obrázkov. Formát PDF poskytuje aj možnost’ viacerých vrstiev dokumentu. Táto vlastnost’ umožňuje uložit’ do dokumentu pôvodný obrázok danej strany dokumentu, pričom pod touto vrstvou môže byt’ pre užívatel’a neviditel’ná vrstva (zakrytá už spomínanou vrchnou vrstvou) rozpoznaného textu. Takýmto spôsobom sa prípadnými chybami pri rozpoznávaní textu nezt’aží jeho čitatel’nost’, pretože užívatel’ bude čítat’ pôvodný obraz strany, čo má vel’mi blízko k čítaniu 6 2.4. OCR MATEMATIKY samotnej fyzickej strany dokumentu. Zároveň však vd’aka prítomnosti rozpoznaného textu bude dokument programovo prehl’adávatel’ný. 2.4 OCR matematiky 2.4.1 Špecifiká OCR matematiky Matematické texty majú z hl’adiska OCR niekol’ko špecifických charakteristík, ktoré ich odlišujú od klasických textov. Matematické texty majú oproti tradičným textom komplikovanejšiu štruktúru. V prípade stredoeurópskych jazykov môžeme štruktúrou chápat’ rozdelenie do riadkov. Pri určitom zjednodušení môžeme povedat’, že riadok pre nás v tomto zmysle predstavuje postupnost’ znakov s rovnakým vertikálnym umiestnením. V tomto zmysle riadok teda pre nás nie je d’alej štruktúrovaný (rozhodne riadok neobsahuje d’alšie riadky). V prípade matematiky je situácia zložitejšia. Predstavme si riadok určitej rovnice, ktorej pravá strana predstavuje súčet a medzi sčítancami sa nachádza zlomok alebo matica. Postup rozpoznávania blokov z OCR klasického textu (vid’ Rozpoznávanie blokov) teda nemôžeme úplne presne použit’. Prvým dôvodom je, že pri rozdel’ovaní na horizontálne pásy sa nám toto nemusí podarit’ tak, aby každý znak bol celý obsiahnutý v práve jednom páse, čo je potrebné pre správne rozpoznanie znaku. Do pásu môžeme dostat’ čast’ znaku ležiaceho na inom účiarí, znak teda bude po častiach ležat’ vo viacerých pásoch a následné rozpoznanie časti daného znaku zrejme neposkytne želaný výsledok. Druhým dôvodom je, že ani pri úspešnom rozdelení na horizontálne pásy nám výsledok rozpoznávania nebude odrážat’ štruktúru daného výrazu (z hl’adiska významu), ale nanajvýš jeho vizuálnu podobu. Obrázok 2.1: pokus o rozdelenie matematickej rovnice na riadky programom FineReader 7 (riadky sú vyznačené farebne a zároveň vl’avo od bloku) Dôvodov, pre ktoré požadujeme zachovanie štruktúry matematického výrazu je niekol’ko. Ak požadujeme po matematickom texte, aby bol prehl’adávatel’ný (podobne ako klasický text po prechode OCR procesom), musí existovat’ možnost’ zadania požiadavky na vyhl’adanie matematického výrazu. Jediným rozumným spôsobom špecifikácie hl’adaného matematického výrazu je zápis popisujúci štruktúru výrazu. Vyhl’adávanie teda musí pracovat’ so štruktúrov matematických výrazov. Problému zadávania hl’adaných výrazov sa budeme venovat’ d’alej pri popise výstupných formátov. Symboly spolu so svojimi (viacerými) indexami by mali vo výslednom rozpoznanom texte predstavovat’ jeden logický celok, nie iba skupinu znakov. Štruktúra výrazov by teda mala zostat’ zachovaná. Pri rozpoznávaní znakov v klasickom OCR sa využívali informácie o pomere výšky a 7 2.4. OCR MATEMATIKY šírky znakov. Tento postup sa pri OCR matematiky použit’ nedá. V matematike totiž existujú symboly, ktoré sa „rozt’ahujú“ podl’a okolností (napr. výšku a šírku symbolu odmocniny určuje výška a šírka odmocňovaného výrazu, prípadne šírka zlomkovej čiary je tiež závislá na dĺžke výrazov pod a nad ňou, pričom sa jej hrúbka ale nemení). Podobne aj informácie o frekvencii výskytu znakov sú v matematických textoch značne odlišné. Obrázok 2.2: rozdielne vel’kosti symbolu odmocniny Ďalšou odlišnost’ou procesu OCR matematiky je vol’ba výstupného formátu. V prípade, že chceme vo výstupnom dokumente poskytovat’ možnost’ vyhl’adávania aj matematických výrazov, musíme uvážit’ fakt, že vyhl’adávanie v dokumentoch pomocou štandardných programov určených na prezeranie daných formátov (Adobe Reader, Microsoft Word Viewer atd’.) v súčasnosti nedokáže určit’ štruktúru matematického výrazu, ktorá je pri vyhl’adávaní potrebná (vid’ vyššie), iba z informácie o vzájomnej pozícii znakov v dokumente. Je teda potrebné znova premysliet’ výber výstupného formátu. Na prvý pohl’ad vhodným formátom sa zdá byt’ formát XML, konkrétne značkovanie MathML určené pre značkovanie matematiky. Nás ale zaujíma výstupný formát pre celý dokument, ktorý v prípade matematických textov obsahuje ako časti matematických zápisov, tak aj prevažne textové (alebo dokonca čisto textové) časti. Možným riešením je použitie novej vrstvy v PDF súbore, do ktorej môže byt’ vložený prepis rozpoznaných matematických výrazov vo vhodnom značkovaní (spomenuté MathML, prípadne TEXovský zápis matematiky). Textové časti môžu byt’ zachované vo vlastnej vrstve, vrchná vrstva môže takisto zostat’ zachovaná v podobe obrázka naskenovanej stránky. Vyhl’adávanie klasického textu by zostalo nezmenené, pričom zadávanie vyhl’adávaných matematických výrazov by bolo realizované vybraným značkovaním (spomínané MathML alebo TEX). 2.4.2 InftyReader InftyReader (vid’ [2]) je integrovaný OCR systém pre matematické dokumenty. Pozostáva zo štyroch procedúr: 1. 2. 3. 4. analýza rozvrhnutia textov, rozpoznávanie znakov, štruktúrovaná analýza matematických výrazov, ručná oprava chýb. 8 2.4. OCR MATEMATIKY V týchto procedúrach je použitých niekol’ko nových techník pre lepší rozpoznávací výkon. Skúšobné výsledky vykonané japonskými tvorcami na súbore pät’sto strán matematických dokumentov ukázali vysokú úspešnost’ rozpoznávania znakov v matematických výrazoch i v obyčajných textoch. InftyReader číta skenované stránky z matematického dokumentu a poskytuje ich OCR. Kedže analyzuje štruktúru matematických výrazov v dokumente, môže produkovat’ výsledok vo formáte LATEX. Použitie programu InftyReader ako samostatného OCR systému na sade dokumentov obsahujúcich okrem anglických textov aj texty iného jazykového pôvodu je ale nedostačujúce. Pre podrobnosti o výhodách a problémoch programu vid’ [3]. 9 Kapitola 3 Analýza potrieb OCR pre DML-CZ 3.1 Projekt DML-CZ 3.1.1 Ciel’ projektu Ciel’om tochto projektu je vytvorit’ Českú digitálnu matematickú knižnicu DML-CZ. Táto knižnica by vo svojej finálnej podobe mala obsahovat’ relevantnú čast’ odbornej českej a slovenskej matematickej literatúry. Projekt zahŕňa mnoho úkonov: skenovania dokumentov a časopisov, ich digitalizáciu, vytvorenie metadát, generovanie konečnej podoby elektronickej formy dokumentov a ich prezentáciu. V budúcnosti sa uvažuje o začlenení digitálnej knižnice DML-CZ do projektu WDML, svetovej digitálnej matematickej knižnice. Je teda nutné otestovat’ dostupné technológie a z nich vybrat’ tie, ktoré by tento ciel’ čo najviac ul’ahčili. Posledných niekol’ko rokov matematici po celom svete chcú koordinovat’ svoje úsilie, digitalizovat’ matematickú literatúru a sprístupnit’ ju na Internete. Komisia pre elektronické informácie a komunikáciu (The Committee on Electronic Information and Communication, CEIC) medzinárodného matematického zväzu učinila záväzok, že bude koordinovat’ snahy o vytvorenie WDML, svetovej matematickej knižnice. Viac informácií je dostupných na <http://www.wdml.org/>. Do digitálnej knižnice budú zaradené nasledujúce publikácie: • • • • • Czechoslovak Mathematical Journal (vydáva Matematický ústav AV ČR), Applications of Mathematics (vydáva Matematický ústav AV ČR), Archivum Mathematicum (vydáva Masarykova univerzita), zborníky konferencií vydané českými univerzitami a vedeckými ústavmi, monografie, učebné texty, dizertácie, výzkumné správy a dalšie. Odhadom by sa malo jednat’ o 200 až 300 tisíc strán. Jedná sa o dlhodobý ciel’, projekt je naplánovaný na 5 rokov. Digitálna matematická knižnica by mala prispiet’ k rozvoju matematiky v ČR, ale mala by slúžit’ i všetkým ostatným užívatel’om, študentom a taktiež pedagógom. Využívat’ ju budú môct’ matematici laici pre svoje súkromné bádanie, študenti z nej budú môct čerpat informácie k svojmu študiu i písaní rôznych prác a učitelia z nej budú môct’ t’ažit’ materiály pre tvorbu študijných podkladov. Jej vybudovanie predstavuje obrovské množstvo väčších a menších čiastkových úloh, ktoré bude treba vyriešit’. Rozsah úloh je vel’mi široký, od vlastnej digitalizácie, ktorá zahrňuje 10 3.1. PROJEKT DML-CZ množstvo volieb týkajúcich sa formátu skenovania, ukladania a predávania medzivýsledkov medzi jednotlivými riešitel’skými skupinami, po OCR (vol’ba OCR programov, nastavení, zvyšovanie presnosti, vol’ba výstupných formátov), tvorbu metadát (aké metadáta, ako ich získat’, ako ich doplnit’), až po generovanie finálnej podoby elektronického dokumentu (formát) a jeho prezentáciu. 3.1.2 Postup Podl’a [5], vecný obsah projektu zahrňuje návrh a realizáciu riešenia navzájom previazaných problémových okruhov v následujúcích piatich oblastiach (v zátvorke je uvedený predpokladaný hlavný riešitel’ pre danú oblast’): 1. akvizícia (MÚ AV ČR v spolupráci s MFF UK): • • • • • spracovanie právnej expertízy z oblasti vlastníckych a autorských práv (IPR – Intellectual Property Rights) vo vzt’ahu k DML-CZ, zriadenie pracoviska pre získávanie a prípravu materiálov pre digitalizáciu, výber konkrétnych materiálov (časopisy, zborníky, monografie, . . . ) pre digitalizáciu, ošetrenie IPR pre vybrané materiály, príprava materiálov pre digitalizáciu, 2. digitalizácia (KNAV ČR v spolupráci s MÚ AV ČR a d’alšími partnermi projektu): • • • • • • • • stanovenie technických parametrov digitalizáce v súlade s pripravovanými zásadami WDML-BPS (Best Practice Statement), stanovenie digitalizačného workflow (príprava, popis, digitalizácia, kontrola kvality, úpravy obrázkov, OCR, začlenenie do systému, . . . ), výber, prípadne adaptácia a nasadenie softvérového systému pre komplexnú podporu digitalizácie, overenie použitel’nosti dostupných digitalizačných zariadení v KNAV ČR a ich prípadné doplnenie, digitalizácia, skenovanie, úprava digitálnych obrázkov, vytváranie metadát (u deskriptívnych s využitím bibliografických záznamov v knižničnom systéme), OCR, 3. digitálny dokument (MFF UK v spolupráci s ÚVT MU, FI MU a KNAV ČR): • • • špecifikácia štruktúry digitálneho objektu (DO), stanovenie metadát (deskriptívne, štrukturálne, administratívne – spolu s technickými a IPR), perzistentná globálna identifikacia digitálnych objektov, 11 3.1. PROJEKT DML-CZ • • • • • • • • realizácia zložených DO pre rôzné typy dokumentov (seriál, článok, monografia), stanovenie archívnych a prezentačných formátov, konverzia medzi formátmi a generovanie digitálnych derivátov, transformácia born-digital (už vytvorených v elektronicky spracovatel’nej podobe) materiálov na unifikované DO vyhovujíce navrhnutým podporovaným DTD (definícia typu dokumentu), evaluácia možností automatizácie konverzie vizuálne značkovaných OCR dát na logicky štruktúrované dokumenty, štruktúrovaný textový obsah born-digital DO, vzájomná previazanost’ DO, možnosti automatizácie hypertextových odkazov, prepojenie s databázami, 4. digitální knižnica (ÚVT MU a FI MU v spolupráci s KNAV ČR a MFF UK): • • • • • • výber, prispôsobenie a nasadenie Content Management systému (CMS) pre digitálnu knižnicu DML-CZ (preferované budú vol’ne dostupné softvérové riešenia typu DSpace), správa DO, riadenie prístupu k DO, dlhodobá archivácia DO, vyhl’adávanie v digitálnej knižnici (metadáta, plné texty) a prezentácia výsledkov užívatel’om (obrazové súbory) – prístup užívatel’ov v prostredí www, indexovanie archívu pre presné dopytovanie, 5. začlenenie do WDML (MÚ AV ČR po koordinačnej stránke a ÚVT MU, FI MU po technickej stránke): • • zaistenie interoperability a začlenenia DML-CZ v rámci WDML (napr. na báze automatizovaného zberu metadát s využitím štandardov OAI – Open Archive Initiative a protokolu OAI-PMH – Protocol for Metadata Harvesting), napojenie digitálneho obsahu knižnice DML-CZ na referatívne databázy Zentralblatt MATH, MathSciNet. Riešeniu uvedených okruhov otázok bude vždy predchádzat’ štúdium existujúcích metód a postupov. S ohl’adom na začlenenie DML-CZ do WDML bude mat’ vel’ký význam spolupráca a výmena poznatkov so zahraničnými skupinami pracujúcími v oblasti digitalizácie a skúmánie možností ich využitia v našom prostredí. Pôjde predovšetkým o skupiny v Göttingen a v Grenoble. Dôležitá bude taktiež aktívna účast’ riešitel’ov na medzinárodných konferenciách a seminároch venovaných tématike WDML a digitalizácii obecne. Bude potrebné úzko spolupracovat’ s komisiami ustanovenými IMU a EMS pre koordináciu WDML. 12 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR 3.1.3 Riešitelia a ich úlohy Tu sú uvedené všetky riešitel’ské skupiny, ich členovia a stručný popis ich role v projekte DML-CZ. Skupina MÚ AV ČR a MFF UK: • • RNDr. Jiří Rákosník, CSc.; RNDr. Oldřich Ulrych; Doc. RNDr. Jiří Veselý, CSc.; Mgr. Helena Severová; Hlavnou úlohou tejto skupiny bude koordinácia všetkých riešitel’ov ako celku. Ďalej budú zodpovední za výber publikácií pre digitalizáciu, za otázky copyrightu a zaistia súčinnost’ s prevádzkovatel’mi databáz Zentralblatt MATH a MathSciNet. Skupina NKAV ČR: • • Ing. Martin Lhoták, Ing. Martin Duda; Ich úlohou bude zaistit’ vytvorenie digitálnych obrazov vybraných publikácií, vytvorenie základných metadát, ich prvotná archivácia a sprístupnenie ostatným skupinám. Skupina ÚVT MU: • • RNDr. Miroslav Bartošek, CSc.; Petr Kovář; Mgr. Martin Šárfy; Táto skupina bude riešit’ problémy týkajúce sa doplnenia metadát vytvorených pri digitalizácii, d’alej sa bude zaoberat’ realizáciou vlastnej digitálnej knižnice a všetkými úlohami s tým súvisiacimi. Skupina FI MU: • • RNDr. Petr Sojka, Ph.D.; Radovan Panák; Bc. Tomáš Mudrák; Úlohou tejto skupiny, teda našou, bude otestovat’ postupy týkajúce sa OCR. Je nutné vybrat’ programové vybavenie, zistit’ jeho možnosti, otestovat’ jeho nastavenia, vybrat’ výstupný formát (v súčinnosti s d’alšími skupinami). Po odskúšaní uviest’ daný softvér do chodu na serveru na FI. 3.2 Návšteva Digitalizačného centra Knižnice Akadémie vied ČR Po príchode na digitalizačné pracovisko Akadémie vied v obci Jenštejn u Prahy nás uvítala slečna Ryšánková. Zaviedla nás na svoje pracovisko. Jednalo sa o jednu miestnost’, v ktorej sú umiestnené dva skenery Zeutschel, d’alej 3 pracovné stanice, ktoré slúžia na spracovanie skenovaných stránok jednotlivých dokumentov. Digitalizačné centrum má d’alej k dispozícii ešte skener DigiBook 10000 RGB. Nasleduje zoznam parametrov skenerov: Scanner DigiBook 10000 RGB: • farebný, maximálne 24 bitov na pixel, 13 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR • • • • • max. formát A1 pri rozlíšení 400 DPI, max. rozlíšenie 1000 DPI pri formáte 2 × A5, rýchlost’ 100 strán za hodinu pri 2 × A4, 400 DPI, CCD line 3 × 10000 pixelov RGB, max. hrúbka knihy 50 cm, max. váha 40 kg. Scanner Zeutchel OS 7000: • • • • • • maximálne 256 odtieňov šedej, max. formát A2 pri rozlíšení 400 DPI, max. rozlíšenie 800 DPI pri formáte A4, rýchlost’ 180 strán za hodinu pri A4, 400 DPI, CCD line 7500 pixelov, max. hrúbka knihy 50 cm. 3.2.1 Skenovanie Prvným krokom je skenovanie vybraných kníh a dokumentov. Obsluha skeneru dostane do rúk dielo, ktoré sa má archivovat’. Programovo na skeneri nastaví príslušné rozlíšenie pre skenovanie, typicky to býva 400 DPI spolu s farebnou hĺbkou 4 bity na pixel, stránky sa skenujú šedotónne. Výstupné obrazy zo skeneru DigiBook majú bitovú hĺbku 8 bitov na pixel a tá je pred d’alším spracovaním znížená na 4 bity na pixel. Skener ukladá obrazy ako nekomprimované TIFF súbory, a preto sú s ohl’adom na diskové kapacity komprimované LZW kompresiou pomocou programu IrfanView. 3.2.2 Book Restorer Ďalším krokom je úprava pomocou softvéru Book Restorer 4.0.0.0. Book Restorer je komerčný softvér dodávaný ku skeneru DigiBook. Digitalizačné centrum si zakúpilo naviac ešte jednu licenciu. V štandardnom procese spracovania sa používajú iba dve funkcie a to narovnávánie stránok a orez obrazu. Prvá procedúra dokáže narovnávat’ naskenované obrazy a to hned’ v niekol’kých úrovniach. Kedže pri skenovaní kníh dochádza k tomu, že pri väzbe je stránka mierne ohnutá, na naskenovanom obraze je toto ohnutie pozorovatel’né. Pred d’alším spracovaním vrátane OCR je teda nutné obraz natočit’ a narovnat’, aby si s ním d’alšie programy dokázali efektívne poradit’. Narovnávat’ možno celú stránku, d’alej jednotlivé okraje, riadky textu a obrázky. Všetky vol’by si možno prehl’adne vybrat’ v dialógovom okne, ktoré ponúka aj rozšírené možnosti nastavenia. Riadky možno narovnávat’ podl’a rôznych čiar. Druhá procedúra, orezávanie obrazu, sa používa pre zmenu vel’kosti okrajov. Jej nastavenie prebieha v niekol’kých krokoch. Obrazy môžeme rozrezávat’, manuálne orezávat’ alebo používat’ automatické orezávanie. Toto práve využíva digitalizačné centrum a i tu si možno vybrat’ 14 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR z troch možných spôsobov orezu. Rezat’ sa dá od vonkajšieho kraja, od stredu, alebo od textu. Nastavovat’ sa dá aj citlivost’ spracovania. Typicky sa používa orez od textu s hodnotou 5 mm. Pri ukladaní v programe Book Restorer si môžeme vybrat’ z formátov Adobe PDF, BMP, TIFF nekoprimovaný, TIFF G-4 kompresia, JPEG-JFIF a PNG, a bitových hĺbok 1 bit, 8 bit šedotónne, 24 bit. Pri bitových hĺbkach je tiež možné vybrat’ vol’bu „best“, v tom prípade program zvolí najlepšie variantu ku zvolenému formátu a kvalite vstupného obrazu. V digitalizačnom centre ukládajú upravené obrazy ako nekomprimovaný TIFF a opät’ pridávajú LZW kompresiu pomocou IrfanView. Zoznam funkcií programu Book Restorer a ich stručný popis: • • • • • • • • • • • • • • • • Úprava histogramu – rozprestrie farby cez všetky možné hodnoty. V praxi to znamená, že v prípade príliš svetlého alebo naopak tmavého obrazu procedúra vypočítá nový, optimálnejší histogram tak, aby všetky časti obrazu boli dobre viditel’né. Detekcia oblastí – umožňuje manuálne alebo automaticky izolovat’ grafické komponenty a textové bloky obrazu. Každý element, ktorý má vysoký kontrast s pozadím a je väčší než riadok textu, je považovaný za obrázok. Binarizácia – prevádza obraz z odtieňov šedej alebo z farieb na čiernobiely, zbavuje ho šumu. Farebná konverzia – mení bitovú hĺbku obrazu (24 bit, 8 bit šedotónne, 1 bit). Kolorimetrické krivky – tieto krivky môžu být’ použité pre zmenu farebnej palety, ak farby na skenovanom obraze nezodpovedajú originálu. Orez obrazu – vid’ vyššie. Narovnanie stránky – dokáže natočit’ stránku do zvislej polohy, ak bola skenovaná šikmo. Kotviacimi bodmi sú l’avý okraj, pravý okraj, alebo celý text. Zacel’ovanie písmen – procedúra odstraňujúca šum a zacel’ujúca písmená v závislosti na zvolených parametroch. Filter – ostriaci a zmäkčujúci filter obrazu. Maskovanie prstov – kedže pri skenovaní je niekedy nutné pridržat’ predlohu prstami, tieto sú vidiet’ aj na výslednom obraze. Táto procedúra ich odstraňuje automaticky alebo manuálne výberom oblasti, kde se nachádzajú. Geometrická korekcia – vid’ vyššie. Odtieň, svetlost’ a sýtost’ farieb – umožňuje menit’ farebné zložky obrazu. ICC profily – pomocou tejto procedúry je možné overit’ koherenciu medzi rôznymi perifériami zahrnutými do procesu digitálneho spracovania. Jas a kontrast – nastavovanie jasu a kontrastu obrazu. Korekcia jasu – ak pri skenovaní vznikne v zhybe knihy pri väzbe tieň, táto procedúra ho odstráni, takže výsledkom je obraz s rovnomerným jasom. Negatív – invertuje farby v obraze. 15 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR • • • • • OCR – Book Restorer nemá interný OCR modul, ale môže využívat’ externý, napr. FineReader. Umožňuje aj spúšt’at’ OCR z príkazového riadku, všetky parametre sa nastavia v programe Book Restorer. Skripty pre Photoshop – umožňuje spúšt’at’ skripty vytvorené v Adobe Photoshop. Detekcia polarizácie – dokáže detekovat’, či je obraz pozitív alebo negatív a v prípade negatívu ho previest’ na pozitív. Zmena vel’kosti – zmena vel’kosti obrazu, rozlíšenia a proporcií. Transformácie – možno využit’ pre jednoduché otáčenie obrazu. V rámci našej návštevy (a taktiež pre účel použitia v projekte DML-CZ) sme sa rozhodli otestovat’ aj iné funkcie, ktoré program ponúka. Aspoň čiastočne sme otestovali všetky, no väčšina z nich nemá pre naše účely žiadny význam. Program však ponúka pár zaujímavých funkcií ako napríklad úpravu histogramu, zacel’ovanie písmen, korekciu jasu atd’. Zacel’ovanie písmen funguje iba pre čiernobiele obrazy. Úprava histogramu je použitel’ná bez problémov, ale percento obrazov, ktoré vyžadujú túto korekciu je nízke, takže by sa jednalo o zbytočné plytvanie strojovým časom. Spomenuté procedúry sú skôr vhodné pre manuálne opravy obrazov, ktorých predloha je už závažne poškodená. V automatizovanom procese spracovania obrovských dávok dát je plne dostačujúce použitie geometrickej korekcie a orezu obrazu. Ak by boli spracovávané poškodené zväzky, stoja procedúry za zváženie. V programe BookRestorer je možné pripravit’ si úpravy do dávky príkazov (vytvorit’ si makro), ktorá sa môže neskôr na dáta aplikovat’, najlepšie v dobe, ked’ s danou pracovnou stanicou nie je potrebné interaktívne pracovat’ (proces je totiž značne náročný na systémové zdroje). V digitalizačnom centre sa to deje cez noc. Pre úplnost’ d’alej uvádzam popis mechanizmu tvorenia názvov skenovaných obrazov. Príklad značenia: ABA007 12345678 2005 0022 0 0025 Význam jednotlivých skupín značenia: • • • • • • 6 miest – prefix digitalizačného centra; 8 miest – ISSN; 4 miesta – rok; 4 miesta – číslo časopisu v danom roku; 1 miesto – 1 značí, že sa jedná o prílohu, 0 opak; 4 miesta – číslo stránky v rámci výtlačku. 3.2.3 IrfanView Aby obrazy mali štandardnú šírku1 , tak digitalizačné centrum používa program IrfanView pre zníženie ich šírky na 1400 pixelov. Týmto ale zároveň dochádza ku zníženiu kvality ešte 1. predlohy pre skenovanie sú rôznych formátov 16 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR pred OCR obrazov. Pri skenovaní predlohy vo formáte A4 pri 400 DPI má obraz šířku približne 3300 pixelov. Ak znížime jeho šírku na 1400 pixelov, tak pri tlači pri 400 DPI bude mat’ potlačená plocha šírku 8,9 cm (A4 má 21 cm). Ak budeme chciet’ potlačit’ celú plochu A4, budeme musiet’ použit’ hodnotu DPI zhruba 169; obraz teda zodpovedá kvalite skenovánia 169 DPI. Toto je celkom alarmujúca hodnota, pretože obraz ešte len teraz po zmenšení bude vstupom pre OCR. Z hl’adiska použitia v rámci DML-CZ je tento postup neprípustný. Naše testy ukázali, že úspešnost’ rozpoznávania v programe FineReader rapídne klesá a program InftyReader obraz s tak malou hodnotou DPI odmieta spracovat’. Pre účely OCR je teda nutné obrazy nezmenšovat’, ponechávat’ v pôvodnom rozmere a prípadne ich zmenšovat’ až po vykonaní OCR. Ďalšou alternatívou je vykonanie OCR mimo digitalizačné centrum, kde by boly procesy OCR a zmenšovania obrazu nezávislé. 3.2.4 Sirius Ďalším krokom spracovania v digitalizačnom centre je vstup obrazových dát do systému Sirius. Autori systém Sirius popisujú ako program pre zjednotenie prístupu k informáciam v rôznej forme, resp. pre archiváciu (papierových) dokumentov v elektronickej podobe a poskytovánie prístupu k nim. Systém Sirius ale nesplňuje požiadavky na sprístupnenie obsahu širokým masám, nedá sa nazvat’ content management systémom (CMS). CMS využívaný KNAV ČR je teda systém Kramerius. Systém Kramerius a jeho vlastnosti nám neboli predvedené (nebolo to ani ciel’om návštevy). Systém Sirius slúži hlavne na vkladanie metadát a tvorbu určitej hierarchie (stromovej štruktúry) vo vstupných dátach. Najskôr sa v systéme vytvorí zákazka, ktorá môže predstavovat’ napr. naskenované 2 ročníky určitého periodika. V danej zákazke se buduje d’alšia hierarchia (napr. môžeme dáta na d’alšej úrovni členit’ podl’a ročníkov). Následne jednotlivým uzlom v našej stromovej štruktúre priradíme príslušné dáta (súbory TIFF), čím štruktúru rozšírime o d’alšiu úroveň. Pre dané dáta vytvoríme skupinu šablón za účelom ich d’alšej štrukturalizácie (napr. vytvoríme šablónu pre titulnú stranu daného periodika, čím sa nám automaticky oddelia jednotlivé čísla v rámci ročníku2 ) a získánia určitých metadát (napr. definícia obdĺžnikovej oblasti pre získávanie čísel strán pomocou OCR3 ). Pre jednotlivé uzly (nie nutne listy) v danej štruktúre môžeme definovat’ a zadávat’ rôzné metadáta. Zjednodušenie zadávania metadát je z daného postupu a vytvorenej štruktúry zrejmé. Spracovanie dát po pripravení šablón prebieha dávkovo. Môžeme na nich definovat’ určité obrazovo manipulačné operácie, no tieto možnosti systému Sirius ani zd’aleka nedosahujú komplexnosti ponuky programu BookRestorer. Jedná sa hlavne o orezávánie obrazu (prebieha v programe BookRestorer) a zmenu vlastností obrazu ako jas, kontrast, atd’. Táto oblast’ je z hl’adiska spracovania nezaujímavá, práve vd’aka použitiu programu BookRestorer v spracovaní pred systémom Sirius. 2. šablóna využívá rozpoznávanie titulnej strany na základe definície určitého vzoru a jeho umiestnenia (napr. logo časopisu) 3. pre l’avú a pravú stranu z dôvodu iného umiestnenia čísla stránky osobitná šablóna 17 3.2. NÁVŠTEVA DIGITALIZA ČNÉHO CENTRA KNIŽNICE AKADÉMIE VIED ČR Fáza OCR je v systéme Sirius poslednou, po výstupu dát zo systému sa OCR vyskytuje v podobe textového súboru. Následne dáta (spolu s metadátami a prípadným OCR) opúšt’ajú systém Sirius a pomocou počítačovej siete sú poslané na server KNAV ČR do Prahy. Tam sú dáta skonvertované z formátu TIFF do formátu DjVu, v ktorom potom vstupujú do systému Kramerius. 18 Kapitola 4 Návrh a implementácia riešenia OCR 4.1 Rozdelenie úloh Vzhl’adom na to, že prácu riešim spoločne s kolegom Bc. Tomášom Mudrákom, bolo jedným z prvých krokom práce (po zoznámení sa s problematikou) rozdelenie úloh. Rozdelenie sa neskôr premietlo aj do zadania práce. Snahou pri rozdel’ovaní bolo sadu problémov rozdelit’ na vzájomne čo najmenej závislé časti. V prípade, že dva podproblémy na sebe záviseli, snažili sme sa, aby riešenie oboch mal na starosti iba jeden z nás. Ja som sa pri práci zameriaval na vlastnosti OCR klasického textu, po určení softvérového vybavenia konkrétne na program FineReader verzie 8.0 spoločnosti Abbyy. Riešil som problém automatickej detekcie jazyka predrozpoznaného textu a úpravu existujúcich pomocných nástrojov pre naše účely. Implementoval som program využívajúci FineReader Engine 8.0 (SDK od Abbyy), ktorý umožňuje použitie jadra programu FineReader na dávkové spracovanie a rozpoznávanie obrazových dát. Riešenia jednotlivých podproblémov v rámci oboch prác som nakoniec zastrešil pod jeden ovládací program, ktorý bude riadit’ tok dát medzi jednotlivými komponentami riešenia a bude využívaný na dávkové spracovanie. Po úspešnej implementácii dávkového spracovania som analyzoval použitel’nost’ spracovania v rámci workflow (toku práce) DML-CZ. Bc. Tomáš Mudrák sa venoval testovaniu dostupného OCR softvéru a následnému výberu vhodného programu na použitie v rámci projektu DML-CZ. Po vybratí vhodnej kombinácie OCR softvéru (programy FineReader a InftyReader) sa začal venovat’ softvéru InftyReader špeciálne určenému pre digitalizáciu matematických textov, skúmat’ jeho najvhodnejšie využitie a riešenie niektorých slabín programu. Počas riešenia práce bol v emailovom kontakte s tvorcami spomenutého programu, konkrétne s vedúcim projektu, pánom Masakazu Suzukim. Na starosti mal d’alej výber a použitie vhodného formátu pre uloženie výstupu, ako aj možný postup pre vyhl’adávanie a doznačkovanie bibliografických citácií. Pred samotnou implementáciou sme riešenie niektorých problémov odhadovali ako pracnejšie, rozhodli sme sa teda venovat’ sa nim spoločne s prípadným neskorším jemnejším rozdelením práce. Takýmto problémom bolo spojovanie výstupov rozličných OCR programov. Po dôkladnejšom preskúmaní problému sme si prácu rozdelili. Ja som implementoval triedu IMLCorrector upravujúcu výsledky výstupu programu InftyReader, kolega implementoval triedu OCRJoiner vykonávajúcu spájanie výstupu programu FineReader a upraveného výstupu programu InftyReader (výstup triedy IMLCorrector). Vzhl’adom k vel’kej pracnosti sme spolupracovali aj pri porovnaní výsledkov získaných naším prístupom 19 4.2. CIELE s výsledkami získanými základnou neupravenou OCR aplikáciou FineReader Professional. Napriek snahe o čo najväčšiu vzájomnú izoláciu jednotlivých úloh sme sa pri žiadnej z nich nevyhli aspoň minimálnej forme spolupráce. Zodpovednost’ za riešenie danej úlohy ako aj riadenie postupu pri jej riešení však mal ten, komu bola daná úloha v našom rozdelení pridelená. 4.2 Ciele Hlavným ciel’om pri vypracovávaní práce bolo určenie softvéru vhodného na optické rozpoznávanie matematických textov a stanovenie workflow OCR. Zámerom bolo zachytit’ v rozpoznanom texte štruktúru matematických vzorcov, ktorá by mala zostat’ zachovaná aj vo výstupnom formáte. Zároveň však tento prístup nemal priniest’ neúmerné zníženie kvality rozpoznávania klasických textov. Kvalita implementovaného OCR mala smerovat’ k využitiu na indexáciu rozpoznaných textov, aby bolo koncovým používatel’om digitálnej matematickej knižnice nad danými textami umožnené vyhl’adávanie. Dôležitým ciel’om bola aj snaha o vytvorenie (polo)automatizovaného procesu s nutnost’ou čo najmenšieho zásahu užívatel’a. Pri riešení bolo taktiež potrebné stanovit’ si určité ciele potrebné pre d’alšie spracovanie údajov v rámci workflow projektu DML-CZ, ktoré už nie je súčast’ou workflow OCR. Išlo hlavne o umožnenie využitia rozpoznaných textov na identifikáciu a spracovanie bibliografikých citácií za účelom vzájomného prepojenia článkov z množiny textov dostupných v digitálnej matematickej knižnici (prípadne aj prepojenie na články dostupné prostredníctvom iných zdrojov) podl’a identifikovaných metadát článkov. Na dosiahnutie tochto ciel’a bolo potrebné minimalizovat’ počet chýb v rozpoznaných textoch bibliografických citácií. 4.3 FineReader Engine 4.3.1 Dôvody použitia OCR softvér zvolený pre použitie v rámci projektu DML-CZ bol program FineReader. Pre podrobnosti týkajúce sa jeho výberu a testov vid’ [3]. Ciel’om bolo použit’ FineReader pri dávkovom spracovaní ako súčast’ workflow OCR. FineReader sám o sebe poskytuje iba obmedzené možnosti dávkového spracovania prostredníctvom funkcie Automation Manager. Najväčším obmedzením nie je pritom samotné dávkové spracovanie, ale skôr jeho problematické začleňovanie do workflow OCR. Program FineReader totiž nedisponuje rozhraním využívajúcim príkazový riadok. Všetky funkcie vrátane Automation Manager sú ovládané prostredníctvom grafického užívatel’ského rozhrania. Začlenenie programu FineReader do workflow by teda bolo t’ažkopádne a s vel’kou pravdepodobost’ou by si vyžiadalo relatívne časté zásahy uživatel’a. Vzhl’adom na kvalitu rozpoznávacieho jadra programu FineReader ako aj jeho existujúcu implementáciu v rámci programu Sirius (vid’ Sirius) používaného Digitalizačným centrom Knižnice Akadémie vied ČR, s ktorou má Digitalizačné centrum KNAV ČR pozitívne skúsenosti, sme sa zvažovali začlenenie jadra programu FineReader 20 4.3. FINEREADER ENGINE (tzv. FineReader Engine) do nášho workflow. Po skúmaní možností FineReader SDK (FineReader Engine) prostredníctvom materiálov dostupných na webových stránkach spoločnosti Abbyy (<http://abbyy.com/>) sme na výstave Invex-Digitex 2005 navštívili stánok spoločnosti Nupseso, ktorá je výhradným distribútorom softvérových produktov Abbyy pre Českú a Slovenskú republiku. Následne sme získali bližšie informácie o cene, vlastnostiach produktu a možnosti získania skúšobnej verzie FineReader Engine. Zo získaných informácií sme zistili nové možnosti využitia flexibility poskytovanej SDK. 4.3.2 Popis FineReader Engine Pri vývoji som používal skúšobnú verziu FineReader Engine verzie 8.0. Skúšobná verzia obsahuje oproti plnej verzii určité obmedzenia. Všetky funkcie plnej verzie sú dostupné aj v skúšobnej verzii. Obmedzenia sa týkajú doby použitel’nosti. Po aktivácii produktu prideleným sériovým číslom začína plynút’ stanovená doba 60 dní, počas ktorých sa funkcie skúšobnej verzie dajú využívat’. Po uplynutí tejto doby prestanú funkcie FineReader Engine integrované do vyvíjaných aplikácií fungovat’. Skúšobná verzia je určená výhradne pre účely rozhodnutia o kúpe plnej verzie produktu. Počet strán, ktoré je možné spracovat’ skúšobnou verziou FineReader Engine, je obmedzený na desat’tisíc. Rozpoznané stránky môžu byt’ taktiež použité iba pre účely rozhodovania o kúpe plnej verzie produktu, použitie za účelom zisku alebo iného využitia je zakázané. Pre získanie trial verzie na účely práce bolo potrebné s tvorcami FineReader Engine uzavriet’ Zmluvu o skúšobnej verzii softvéru, tzv. TSLA (Trial Software License Agreement). Kontaktovaním Abbyy sa podarilo získat’ pripravený TSLA dokument – formulár, do ktorého stačilo vypnit’ potrebné vyznačené miesta. Dokument bol následne podpísaný dekanom Fakulty informatiky Masarykovej univerzity, Prof. RNDr. Jiřím Zlatuškom, CSc., opečiatkovaný a odfaxovaný na potrebné číslo. Spoločnost’ Abbyy nám obratom vytvorila na svojom FTP serveri prístupové konto, prostredníctvom ktorého bolo možné si produkt FineReader Engine verzie 8.0 stiahnut’. Informácie o vytvorenom konte, ako aj sériové číslo (aktivačný kl’úč) pre skúšobnú verziu obdržala v TSLA uvedené kontaktná osoba, vedúci diplomovej práce RNDr. Petr Sojka, Ph.D. FineReader Engine je Software Development Kit umožňujúci integrovanie algoritmov a technológií programu FineReader z oblasti OCR, ICR (Intelligent Character Recognition, rozpoznávanie rukou písaného textu) a rozpoznávania čiarových kódov za účelom vytvorenia vlastnej 32bitovej aplikácie systému Windows. SDK implementuje iba jadro funkcionality produktu FineReader Professional určeného koncovým používatel’om a neposkytuje užívatel’ské rozhranie. FineReader Engine je tvorený množinou súborov DLL (Dynamic Link Library), ktoré predstavujú binárny kód používaných algoritmov a technológií, a množinou podporných súborov, ktoré obsahujú d’alšie údaje používané pri procese OCR (definície zabudovaných jazykov, abecied, korekčných gramatických slovníkov, atd’.). Súčast’ou inštalácie produktu je aj dokumentácia, ukážkové zdrojové súbory a licenčný manažér. Inštalácia prebieha použitím inštalačného sprievodcu, v ktorom si môžeme zvolit’ inštalačný adresár 21 4.3. FINEREADER ENGINE a umiestnenie odkazov v ponuke Štart systému Windows. Dokumentácia pozostáva z jediného súboru formátu Microsoft Compressed HTML Help (používaná prípona CHM). Jeho obsah je rozdelený do nasledujúcich sekcií: • • • • • • • • • Úvod, Aktivácia, Licencovanie, Distribúcia, Problémy so spätnou kompatibilitou, Obecné vlastnosti, Sprievodca programátora, Referenčná príručka k API, Časté otázky. Najdôležitejšie informácie použité pri práci sa nachádzajú v sekcii Sprievodca programátora a Referenčná príručka k API. Sprievodca programátora obsahuje informácie potrebné na postupné zoznámenie programátora so spôsobom využívania FineReader Engine, prehl’ad objektov objektového modelu SDK rozdelených do skupín podl’a funkcie, popis niektorých ukážkových zdrojových súborov dodávaných ako súčast’ inštalačného balíku a popis spracovania niekol’kých činností často vykonávaných v aplikáciach integrujúcich funkcie FineReader Engine. Sekcia Licencovanie obsahuje informácie o dvoch druhoch licencií. Vývojárska licencia je určená vývojárom softvéru, ktorí využívajú FineReader Engine vo svojich aplikáciach, zatial’ čo tzv. „runtime“ licencia umožňuje vývojárom používat’ funkcie FineReaer Engine integrované v ich aplikáciach. Platby za runtime licenciu prebiehajú na základe stanovených poplatkov z každej kópie vývojárovej aplikácie distribuovanej používatel’ovi. Vývojár teda v rámci runtime licencie platí za možnost’ užívatel’ov jeho aplikácie používat’ integrované funkcie FineReader Engine. Vývojárska licencia je určená výhradne na účely vývoja. Ak chce vývojár sám používat’ vyvinuté aplikácie, musí si zaobstarat’ runtime licenciu. Ukážkové zdrojové súbory obsiahnuté v inštalácii FineReader Engine demonštrujú niektoré jednoduchšie ako aj zložitejšie techniky a možnosti používania SDK. Medzi uvedenými príkladmi je prítomný aj zdrojový kód programu poskytujúceho rozhranie k programu FineReader prostredníctvom príkazového riadku. Ukážkové zdrojové súbory sú dostupné pre rôzne programovacie jazyky a rôzne vývojové prostredia. Zastúpené sú prostredia Borland Delphi, Microsoft VisualBasic a Microsoft Visual C++ (v móde čistého C++, ako aj v móde so zapnutým rozšírením pre podporu technológie COM). Licenčný manažér je program zabezpečujúci správu licencií. Zabezpečuje aktiváciu produktu, prehl’ad o nainštalovaných moduloch, v prípade skúšobnej verzie taktiež podáva informácie o skúšobnom období a aktuálnom počte stránok, ktoré skúšobná verzia ešte umožňuje spracovat’ v rámci desat’tisícového limitu. V prípade vývojárskej licencie umožňuje taktiež prepínanie režimu medzi vývojárskou licenciou a simulovanou run-time licenciou. 22 4.3. FINEREADER ENGINE Táto vlastnost’ umožňuje vývojárovi simulovat’ prostredie, v ktorom bude funkcionalita FineReader Engine v rámci vývojárovej aplikácie spúšt’aná, teda užívatel’ov počítač s run-time licenciou. Aplikačné rozhranie (API) FineReader Engine spĺňa štandard COM (Component Object Model) firmy Microsoft (pre podrobnosti a d’alšie užitočné odkazy vid’ encyklopédia Wikipedia <http://en.wikipedia.org/wiki/Component_Object_Model>). Funkcionalita využívajúca vlastnosti FineReader Engine môže byt’ jednoducho implementovaná v C++, C#, v prostredí Visual Basic alebo v l’ubovolnom inom vývojom prostredí podporujúcom komponenty COM. Funkcionalita Abbyy FineReader Engine je implementovaná v množine objektov poskytujúcich metódy pre prácu s rôznymi aspektami procesu OCR. Objekty môžeme rozdelit’ do nasledujúcich skupín: • • • • • • • • hlavný objekt, objekt rozloženia stránky, objekty zapuzdrujúce hlavné mechanizmy, objekty zapuzdrujúce parametre rôznych častí procesu OCR, objekty pre prácu s obrázkami, objekty pre prácu s jazykmi, objekt reprezentujúci rozpoznaný text, pomocné objekty. Hlavný objekt je jediným objektom, ktorý je možné v našej aplikácii externe vytvorit’. Tento objekt tvorí prístupovú bránu k celému SDK, poskytuje metódy na vytváranie d’alších objektov, ktoré už zapuzdrujú konkrétnu funkcionalitu. Objekty zapuzdrujúce hlavné mechanizmy poskytujú možnosti analýzy rozloženia a rozpoznania stránky, skenovanie, export rozpoznaného textu a práce s formulármi. Prostredníctvom objektov zapuzdrujúcich parametre môžeme zmenit’ chovanie určitej časti procesu OCR ako export rozpoznaného textu, analýza a rozpoznanie stránky, manipulácia s obrázkami atd’. Pomocnými objektami rozumieme najmä rôzne pomocné dátové typy vhodne zapuzdrujúce určité údaje prítomné pri procese rozpoznávanie. Jedná sa najčastejšie o kolekcie rôznych objektov (zoznam použitých jazykov, zoznam blokov stránky atd’.). Pre úplnost’ uvádzam systémové požiadavky potrebné pre fungovanie FineReader Engine: • • počítač s procesorom Intel Pentium, Celeron, Xeon, AMD K6, Athlon, Duron, Sempron alebo kompatibilným pracujúcim minimálne na frekvencii 200 MHz; operačný systém Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0 (SP6 alebo vyšší), Windows Me/98 (pre lokalizované rozhranie je potrebná podpora príslušného jazyku), otváranie PDF súborov je dostupné iba pod systémami Microsoft Windows Server 2003, Windows XP a Windows 2000; 23 4.3. FINEREADER ENGINE • • • • • • 128 MB RAM; 350MB vol’ného priestoru na pevnom disku pre úplnú vývojársku inštaláciu, 70 MB pre beh programu; 100% TWAIN kompatibilný skener, digitálny fotoaparát, alebo fax modem; video karta a monitor (minimálne rozlíšenie 800x600); klávesnica, myš alebo iné vstupné zariadenie; užívatel’ musí mat’ oprávnenie čítania/zápisu do nasledujúcich vetiev registrov: HKCR, HKLM\ Software\ ABBYY, HKCU\ Software\ ABBYY. 4.3.3 Implementované riešenie Na vývoj programu využívajúceho FineReader Engine som použil vývojové prostredie Microsoft Visual Studio 2005 dostupné pre študentov FI MU prostredníctvom programu MSDN Academic Alliance. Využíval som jazyk C++ s podporou technológie COM. Vyvinutý program (d’alej DML-CZ OCR alebo program) je implementovaný ako 32bitová konzolová aplikácia pre systém Microsoft Windows. Program poskytuje jednoduché rozhranie pre príkazový riadok. Spracovanie je súborovo orientované, z čoho sa odvíjajú aj potrebné parametre pre príkazový riadok. Program má dva povinné parametre. Prvým parametrom je určenie spracovávaného súboru, druhým parametrom je vel’kost’ fontu použitého v predposlednom bloku na predchádzajúcej strane (čislo strany je takmer vždy úplne posledným blokom na strane), ak bol detekovaný ako blok obsahujúci referencie. Ak na predchádzajúcej strane nebol detekovaný žiadny blok referencií, prípadne takýto blok bol detekovaný, ale nebol to predposledný blok stránky, mal by tento parameter byt’ nastavený na hodnotu nula. Návratová hodnota programu predstavuje v prípade korektného ukončenia programu vel’kost’ fontu použitého v predposlednom bloku, ak bol tento detekovaný ako blok obsahujúci referencie, v opačnom prípade je to hodnota nula. V prípade výskytu chyby vráti program zápornú návratovú hodnotu. Priebeh programu je zrejmý z diagramov na obrázkoch 4.1, 4.2 a 4.3. Pri volaní metód objektov z SDK, ktoré vracajú typ HRESULT, teda číselný kód podl’a úspechu, prípadne neúspechu operácie, je vykonaný test na výskyt chyby. Po skončení metódy je na štandardný výstup vypísaná informácia o úspechu (neúspechu) danej metódy. V prípade výskytu chyby v metóde, ktorá je kritická pre korektnost’ procesu, prejde program do chybového stavu nastavením premennej success na hodnotu false. Kedže v prípade kritickej chyby je zbytočné pokračovat’ v behu programu, program vd’aka častej kontrole premennej success na prítomnost’ chybového stavu rýchlo ukončí svoj beh (časovo náročné operácie nebudú vykonané). Kl’účovým krokom procesu je rozpoznanie súboru, čiže funkcia recognize. Testami chybovosti výsledkov programu FineReader Professional pri rôznych jazykových nastaveniach (vid’ Automatická detekcia jazyka) sme zistili, že správne jazykové nastavenia majú relatívne významný vplyv na zníženie chybovosti rozpoznávacieho procesu. Z dôvodov 24 4.3. FINEREADER ENGINE (polo)automatizovaného dávkového spracovanie je nereálne určovat’ jazyk pre každý spracovaný článok časopisu. Z tochto dôvodu som do dávkového spracovania implementoval automatickú detekciu jazyka. Spracovávaný dokument sa najskôr rozpozná s použitím univerzálneho jazyka (krok analýza a predrozpoznanie obrázku). Pri použití univerzálneho jazyka sa na výstupe nepodiel’ajú korekčné slovníky, ktoré v prípade kombinácie väčšieho množstva rozpoznávacích jazykov vo výsledku iba zvyšovali chyby nesprávnym nahradzovaním slov (nahradenie slova v jazyku A podl’a podobného slova zo slovníka jazyka B). Najväčší vplyv na rozpoznávanie v tomto prípade majú zabudované vzory písmen. Na základe rozpoznaného textu je určený jazyk bloku (prípadne prítomnost’ referencií). Rozpoznané jazykové nastavenia sa pre daný blok uložia a pri opätovnom, „ostrom“, rozpoznaní budú použité. Rozpoznanie jazyka bloku je podrobnejšie popísané v kapitole Automatická detekcia jazyka. Pre problémy detekcie bloku referencií pomocou metódy automatickej detekcie jazykov v prípade, že blok referencií neobsahuje uvodzovací riadok pozostávajúci z jedného z kl’účových slov ako References, Literature a iných (nastane v prípade zlomu strany uprostred výpisu bibliografických záznamov), bolo potrebné programu predat’ stav z konca behu programu rozpoznávajúceho predchádzajúcu stranu. Pozorované chovanie programu FineReader Professional ukazuje, že daný riadok obsahujúci kl’účové slovo je spolu s referenciami obsiahnutý v jednom nerozdelenom bloku. Problém nastáva v prípade zlomu strany. Ak sú referencie rozdelené na viacerých stranách, ich detekcia pomocou kl’účových slov funguje iba pre úplne prvý blok referencií. Predávanie stavu zabezpečuje pri samostatnom spúšt’aní programu sám užívatel’ pomocou parametrov na príkazovom riadku, v prípade dávkového spracovania sa o predávanie stavu stará program obsluhujúci dávkové spracovanie. DML-CZ OCR vracia stavovú informáciu užívatel’ovi prípadne volajúcim programom pomocou návratovej hodnoty programu. Obrázok 4.2 ukazuje priebeh funkcie recognize, krok spracovania textového bloku je podrobnejšie priblížený na obrázku 4.3, na ktorom môžeme vidiet’ využívanie predanej stavovej informácie. Ak nebol detekovaný blok obsahujúci referencie, použije sa automatická detekcia jazyka. Krok detekcia jazyka (obrázok 4.3) funkcie recognize je v zdrojovom kóde implementovaný funkciou putLanguagesToCollection. Jej hlavnou úlohou je pripravenie vstupu pre skript jazyka Perl vykonávajúci samotnú identifikáciu jazyka, jeho spustenie, analýza návratovej hodnoty a aplikácia jazykových nastavení príslušných k rozpoznaným jazykom. Vzhl’adom k problémom pri predávaní predrozpoznaného textu priamo na štandardný vstup procesu skriptu v kódovaní UTF-8 (pre dôvody použitia UTF-8 vid’ podkapitola Workflow OCR a dávkové spracovanie), som sa rozhodol používat’ na predávanie textu dočasne vytvorený súbor. Funkcia teda zapíše text do dočasného súboru a skriptu predá jeho názov. Skript pomocou textu identifikuje jazyky daného bloku a vráti ich vhodne zakódované vo svojej návratovej hodnote (nastavenie bitu zodpovedajúceho poradovému číslu jazyka na hodnotu jedna v prípade identifikácie daného jazyka v texte), ktoré si volajúca funkcia môže jednoducho zistit’. Po aplikovaní jazykových nastavení je dočasný súbor odstránený. Najdôležitejšie kroky procesu detekcie jazyka implementovaného spomínanou funkciou je možné vidiet’ na obrázku 4.4. 25 4.3. FINEREADER ENGINE Výstupom programu (krok export vo funkcii recognize) sú 3 súbory obsahujúce rozpoznaný text daného vstupného obrázku: PDF, XML a TXT. Názov súboru je tvorený z názvu vstupného súboru vrátane jeho prípony (najčastejšie .tif), za ktorým sa nachádza prípona identifikujúca typ súboru (pre obrázok test.tif získame súbory test.tif.pdf, test.tif.xml a test.tif.txt). Súbor PDF je d’alej použitý ako vstup pre program InftyReader, súbor XML je vstupom pre triedu OCRJoiner a súbor TXT je ponechaný pre možnost’ prípadného budúceho jednoduchého využitia d’alej nespracovaného výstupu DMLCZ OCR. Nastavenia exportných a iných parametrov sa prostredníctvom FineReader Engine dajú jednoducho aplikovat’ s využitím tzv. profilov. Profil je textový súbor formátu INI (používané niektorými aplikáciami v prostredí Microsoft Windows). Jeho obsahom sú nastavenia rôznych parametrov objektov prítomných v SDK. Pre aplikáciu nastavení stačí načítat’ profil príslušnou funkciou SDK a d’alej pri vytváraní nového objektu, ktorého parametre sú nastavené v profile, sa tieto parametre inicializujú namiesto štandardných hodnôt na hodnoty uvedené v profile. Odpadá tak nutnost’ písania dlhšieho kódu nastavujúceho parametre, stačí iba použit’ funkciu nahratia pripraveného profilu. Pre naše účely bolo potrebné rozšírenie základnej dátovej výbavy FineReader Engine, ktorá je v podstate totožná s výbavou programu FineReader Professional. Rozšírenie sa týkalo vytvorenia nového používatel’ského jazyka pre rozpoznávanie dokumentov a natrénovania vzorov špecifických pre dostupné digitalizované dáta (časopis Czechoslovak mathematical journal) za účelom zvýšenia úspešnosti rozpoznávania znakov (pre podrobnosti týkajúce sa možností trénovania vzorov v programe FineReader Professional vid’ [3]). Získané dáta boli uložené vo formáte dávky programu FineReader Professional, ktorý podporuje aj FineReader Engine. Spracovanie dokumentov programom DML-CZ OCR prebieha v rámci uvedenej uloženej dávky. Jazyk pre spracovanie referencií (univerzálny jazyk) bol vytvorený v programe FineReader Professional 8.0. Prostredníctvom zabudovaného editoru jazyka bol zabudovaný jazyk Čeština (Czech) rozšírený o znaky potrebné na úplné pokrytie znakov Latin1, Latin2 a znakov cyriliky (daná množina znakov postačuje na úplné pokrytie všetkých jazykov obsiahnutých v digitalizovaných matematických časopisoch). Použitie korekčného slovníka bolo vzhl’adom na univerzálnost’ jazyka zakázané. Trénovanie znakov prebiehalo rovnako v prostredí programu FineReader Professional 8.0. Pre účely trénovania sa nám s pomocou vedúceho práce podarilo získat’ knihu popisujúcu postupy sadzby matematických textov v Československu štvorriadkovou metódou [9]. Súčast’ou publikácie bol aj prehl’ad znakov používaného fontu. Bc. Tomáš Mudrák publikáciu naskenoval, strany obsahujúce prehl’ad znakov som následne použil pre trénovanie. Vzhl’adom na to, že prínos natrénovaných dát nebol vel’mi viditel’ný (pravdepodobne z dôvodu nízkej kvantity), rozhodol som sa spustit’ trénovanie aj na reálnych obrazových dátach, teda na vybraných stranách časopisu Czechoslovak mathematical journal. 26 4.3. FINEREADER ENGINE Obrázok 4.1: diagram spracovania funkcie main 27 4.3. FINEREADER ENGINE Obrázok 4.2: diagram spracovania funkcie recognize 28 4.3. FINEREADER ENGINE Obrázok 4.3: diagram spracovania textového bloku vo funkcii recognize 29 4.3. FINEREADER ENGINE Obrázok 4.4: diagram spracovania funkcie putLanguagesToCollection 30 4.4. AUTOMATICKÁ DETEKCIA JAZYKA 4.4 Automatická detekcia jazyka 4.4.1 Dôvody použitia Pri hl’adaní vhodných univerzálnych jazykových nastavení pre FineReader (DML-CZ OCR) som vykonal testy úspešnosti rozpoznávania pri rozličných kombináciach jazykových nastavení programu a jazyka dokumentu. V tabul’ke sú znázornené výsledky. Skratky CZ, EN, FR, GE a ref predstavujú jazyky český, anglický, francúzsky, nemecký a referencie (teda tzv. univerzálny jazyk popisovaný podkapitole FineReader Engine). V prípade viacerých skratiek sa jedná o kombináciu príslušných jazykov. Čísla v tabul’ke znamenajú počet chýb, chýbajúce čísla, že meranie nebolo z časových dôvodov, prípadne z dôvodu nepotrebnosti, vykonané. Súbory, na ktorých sa test uskutočnil, sú uložené na CD prílohe. Riadky tabul’ky reprezentujú dokumenty rôznych kombinácii jazykov, stĺpce rozličné jazykové nastavenia programu FineReader. Jazyk dokumentu CZ EN CZ FR EN GE FR EN ref CZ EN 11 CZ FR EN GE FR EN 32 CZ 24 2 CZ GE FR 4 12 0 21 FR 19 0 >30 6 25 ref 26 24 22 5 17 Tabul’ka 4.1: počet chýb v závislosti na jazykových nastaveniach Z výsledkov podl’a očakávaní vyplýva, že najlepšie výsledky program FineReader Professional 8.0 vykazuje pri korektnom jazykovom nastavení, teda pri nastavení zodpovedajúcom jazyku spracovávaného dokumentu. Správne nastavenie jazyka zabraňuje ignorácii resp. nesprávnemu rozpoznaniu niektorých znakov (napr. akcentované znaky sú s anglickým jazykovým nastavením rozpoznané bez diakritiky) a zároveň pomáha zlepšit’ výsledky použitím vhodného jazykového slovníka programu FineReader Professional. zároveň z testov vyplýva, že použitie zabudovaného jazyku programu FineReader Professional zhoršuje chybovost’ pri rozpoznávaní dokumentov obsahujúcich referencie (citačné záznamy) a najlepšie výsledky pre takýto typ dokumentu podáva nastavenie univerzálneho jazyka, ktorý nepoužíva jazykový slovník. Pri našom spracovaní bolo teda pre zlepšenie chybovosti potrebné pre správny dokument používat’ správne jazykové nastavenia. Vd’aka možnostiam FineReader Engine som dokonca bol schopný aplikovat’ tieto jazykové nastavenia na úrovni jednotlivých blokov, čo je pre zlepšenie chybovosti d’alší prínos. Ciel’om bolo teda pre každý blok po hrubom rozpoznaní stránky s nastaveniami univerzálneho jazyka automaticky určit’ kombináciu jazykov, v ktorých je text bloku písaný, prípadne určit’ blok ako blok referencií, a použit’ tentokrát už správne nastavenia pri opätovnom rozpoznávaní blokov. 31 4.4. AUTOMATICKÁ DETEKCIA JAZYKA 4.4.2 Porovnanie rôznych prístupov a nástrojov Pri zvažovaní využitia nástrojov na automatickú detekciu som sa rozhodoval medzi troma nájdenými nástrojmi riešiacimi daný problém. Konkrétne šlo o moduly jazyka Perl Ligua::Ident, Lingua::Identify a skript jazyka Perl textcat. Lingua::Ident je nástroj pre automatickú štatistickú detekciu jazyka textu, ktorý funguje na princípe porovnávania histogramu bigramov a trigramov. Pre fungovanie je potrebné najskôr natrénovat’ jazyky, ktoré chceme byt’ schopný neskôr v textoch identifikovat’. Trénovaciemu programu stačí zadat’ súbor s dostatočne dlhými trénovacími dátami (podl’a [6] poskytuje 50kB textových trénovacích dát dostatočne kvalitné výsledky) a ret’azec identifikujúci daný jazyk. Program si z trénovacích dát vytvorí histogram bigramov a trigramov znakov trénovacieho textu, teda všetkých dvojíc a trojíc po sebe idúcich znakov (z ret’azca „aj tak“ vzniknú bigramy „aj“, „j “, „ t“, „ta“, „ak“ a trigramy „aj “, „j t“, „ ta“, „tak“). Pri identifikácii textu po natrénovaní dát musíme programu zadat’ súbory s uloženými histogramami pre jazyky, ktoré chceme byt’ schopní identifikovat’, ako aj samotný text, ktorého jazyk chceme zistit’. Program rovnako ako pri trénovaní vyúžíva historam bigramov a trigramov identifikovaného textu, ktorý porovnáva s uloženou informáciou o natrénovaných jazykoch. Balík naviac nad týmto procesom implementuje lepší štatistický model než ostatné programy využívajúce metódu bigramov a trigramov. Výstup programu je ret’azec identifikujúci jazyk s najväčšou pravdepodobnost’ou zhody s jazykom textu. Lingua::Identify je nástroj implementujúci viacero metód automatickej detekcie jazyka. Okrem spomínanej metódy n-gramov (umožňuje až do dĺžky štyri) implementuje metódu krátkych slov, predpon a prípon. Technika krátkych slov vyhl’adáva v texte najčastejšie slová každého aktívneho jazyka. Týmito slovami sú zväčša členy, zámená atd’., ktoré sú zvyčajne zároveň najkratšie slová jazyka. Metódy predpon/prípon analyzujú text na bežné predpony/prípony každého aktívneho jazyka. Metóda n-gramov tochto programu nevyužíva tak prepracovaný štatistický model ako modul Lingua::Ident. Program textcat je taktiež skript jazyka Perl. Implementuje metódu n-gramov podobne ako Lingua::Ident, no vychádza z iného výskumu v danej oblasti (vid’ [8]). Na základe porovnanie rôznych prístupov (vid’ [7]) bol zvolený modul Lingua::Ident, ktorý v porovnaní dosahoval najlepšie výsledky. 4.4.3 Implementované riešenie Najskôr bolo potrebné natrénovanie rozpoznávaných jazykov. Táto procedúra je podrobne popísaná v [3]. Pre naše potreby sme využili ukážkový skript identify, ktorý je súčast’ou balíka modulu. Pre účely použitia v rámci práce som však musel skript aj modul samotný mierne modifikovat’. Modifikácia modulu spočívala iba v zmene návratovej hodnoty funkcie modulu identifikujúcej jazyk textu. Namiesto ret’azca reprezentujúceho najpravdepodobnejšieho kandidáta na jazyk dokumentu funkcia po úprave vráti asociatívne pole, kde kl’účmi do pol’a sú čísla určitým spôsobom kvantifikujúce pravdepodobnost’ výskytu daného jazyku, 32 4.5. INTELIGENTNÉ SPOJOVANIE VÝSTUPOV OCR hodnotami sú ret’azce popisujúce jazyky s príslušnými pravdepodobnost’ami. Táto úprava bola nutná pre možnost’ vrátit’ identifikovanú množinu jazykov, namiesto jediného jazyka. Úprava skriptu vychádzala z novo poskytovanej návratovej hodnoty. Na výstup je po úprave vypísaný jazyk, ktorý sa vyskytuje v texte s najväčšou pravdepodobnost’ou. K ret’azcu identifikujúcemu tento jazyk je vypísané aj číslo 1. Ďalej je na výstup vypísaný každý jazyk, pre ktorý podiel’ kl’uča do asociatívneho pol’a pre najpravdepodobnejší jazyk a kl’úča pre tento jazyk je väčší alebo rovný hodnote 0,95 (teda pravdepodobnost’ výskytu jazyka nie je horšia než 0,95-násobok pravdepodobnosti výskytu najpravdepodobnejšieho jazyka). Hodnota 0,95 bola zvolená z dôvodu použitia tejto hodnoty ako štandardného nastavenia pri programe textcat. Vzhl’adom na skutočnost’, že skript musí byt’ schopný detekovat’ aj text ako referencie v prípade, že je to text počiatočného bloku referencií (obsahuje kl’účové slovo „References“ a pod.), musel byt’ skript d’alej modifikovaný. Detekcia referencií je postavená na regulárnych výrazoch využívajúcich kl’účové slová uvodzujúce referencie. V prípade detekcie referencií nie je d’alej text predávaný metóde na detekciu jazyka, ale skript okamžite ukončí svoju činnost’ a vo svojej návratovej hodnote dáva volajúcemu programu vediet’, že detekovaným jazykom je tzv. univerzálny jazyk (jazyk používaný v našom procese pre rozpoznávanie blokov referencií). Celý proces bol neskôr upravený tak, aby na každom mieste s možnost’ou vol’by kódovania používalo UTF-8. 4.5 Inteligentné spojovanie výstupov OCR Z [3] je vidiet’, že program FineReader Professional (resp. DML-CZ OCR) ako aj program InftyReader sú pre splnenie stanovených ciel’ov nepostačujúce. DML-CZ OCR ako OCR program pre rozpoznávanie bežných textov na matematických textoch zlyháva. Programu InftyReader matematicé texty problémy nerobia, no program sa zameriava predovšetkým na podporu metamatických textov v angličtine, jeho podpora diakritiky preto zaostáva. Pre dosiahnutie stanovených ciel’ov bolo tedá potrebné výstupy jednotlivých OCR programov vhodne skombinovat’. Pôvodným zámerov bolo spájanie resp. preberanie vhodných častí výstupu jednotlivých OCR programov za účelom vytvorenia nového výstupného formátu. Od tochto zámeru sme však z viacerých dôvodov upustili. S príchodom novej verzie programu InftyReader sa podpora diakritických znakov zlepšila, no stále nedosahovala potrebnú úroveň. Diakritické znaky boli vo výstupe programu InftyReader nesprávne umiestnené v tzv. matematických blokoch (jedná sa o čast’ textu rozpoznanú a označenú programom ako matematika). Jedným z pôvodných zámerov bolo zároveň mapovat’ matematiku z výstupu programu InftyReader na štandardné značkovanie matematiky, teda TEXovský zápis, prípadne MathML. Z dôvodu časovej náročnosti komunikácie s tvorcami programu InftyReader sme ale nezískali potrebné mapovanie IML značkovania matematiky využívajúceho pre popis vzt’ahy medzi znakmi (vid’ [3]) na zápis MathML, alebo TEX (oba výstupné formáty sú programom InftyReader podporované, takže mapovanie existuje). Tento problém teda zostal otvorený do 33 4.5. INTELIGENTNÉ SPOJOVANIE VÝSTUPOV OCR budúcnosti. Neskorší prevod na značkovanie TEXu alebo MathML by však po získaní potrebných informácií od tvorcov programu nemal byt’ problematický, pretože štruktúra matematických vzorcov zostáva pri popise pomocou znakov a vzt’ahov medzi nimi v našom výstupnom formáte (upravený formát IML) zachovaná. Po prehodnotení pôvodných zámerov sa teda spájanie výstupov zmenilo na postupnú dvojnásobnú korekciu výstupu programu InftyReader. 4.5.1 Trieda IMLCorrector Výstup programu InftyReader obsahuje slová s diakritikou nesprávne označené ako matematický blok1 napriek tomu, že neobsahujú matematické symboly. Ďalším problémom bol neštandardný zápis akcentovaných znakov. Napriek deklarovanej podpore UTF-8 v XML prológu výstupného formátu IML nebolo toto kódovanie využité. Znak s diakritikou bol v IML zapísaný pomocou dvojice znakov akcent a príslušné písmeno. K akcentu (napr. „check“) je v IML formou vzt’ahu „under“ (pod) pripojený príslušný znak (napr. „s“). Táto dvojica spojená príslušným vzt’ahom písmeno pod akcentom potom reprezentuje jeden akcentovaný znak (napr. „š“). Pre ul’ahčenie d’alšieho spracovania bolo mojou snahou tieto dva nedostatky odstránit’. Implementovaná trieda teda zmení spracovávané bloky matematiky na obyčajný text2 a zároveň zapíše dvojicu znakov akcent a písmeno ako jeden akcentovaný UTF-8 znak jednoznačne prislúchajúci danej dvojici. Kedže formát IML je označkovaný podl’a štandardu XML, je možné pre spracovanie použit’ nástroje ako XPath a DOM. Pomocou XPath výrazu trieda vyhl’adá množinu elementov mblock vyhovujúcim našim kritériam. Element musí obsahovat’ entitu (prítomnost’ určuje atribút entity) z množiny známych akcentov (mäkčeň, dĺžeň, krúžok a vokáň). Zároveň nesmie byt’ prítomná žiadnu iná entita, v opačnom prípade by sa mohlo jednat’ o matematický blok správne reprezentujúci matematický vzorec. Poslednou podmienkou je maximálna hĺbka vzt’ahov medzi písmenami 1. Použitý bol nasledujúci XPath výraz: //mblock[ munit[ @entity="1" and (text()="acute" or text()="check" or text()="ring" or text()="hat" ) and not(mlink/munit/*) ] and not(munit[ @entity="1" and text()!="acute" and text()!="check" and text()!="ring" and text()!="hat" ] ) ] 1. v tomto prípade sa nejdedná o blok v poňatí programu FineReader, ale iba o množinu znakov označenú ako matematika 2. v zmysle značkovania IML 34 4.5. INTELIGENTNÉ SPOJOVANIE VÝSTUPOV OCR Po nájdení popisovanej množiny elementov mblock je každý prvok z tejto množiny samostatne spracovaný. Postupne sú prechádzané všetky dcérske uzly daného elementu (elementy munit), odpojené z XML stromu a spätne pripojené na pozíciu tesne pred rodičovský uzol, element mblock. Pôvodný element munit teda bude v XML strome na rovnakej úrovni ako jeho pôvodne rodičovský element mblock, oba budú v rovnakej hĺbke. Následne je názov elementu zmenený z munit na char, aby bolo dodržané korektné značkovanie IML. V prípade, že sa pri elemente munit jedná o entitu, teda jeden z hl’adaných akcentov, je spracovanie trochu zložitejšie. Okrem zmeny pozície v XML strome a zmeny názvu si trieda IMLCorrector vyhl’adá k danému akcentu prislúchajúcu triedu AccentMap. Jedná sa o triedu pre daný akcent reprezentujúcu mapovanie3 z neakcentovaných písmen na akcentované znaky logicky totožné so znakom reprezentovaným dvojicou akcent a písmeno slúžiace ako kl’úč mapovania. Napríklad pre akcent „check“ získa trieda mapu CHECK_MAP, ktorá mapuje písmeno „s“ na písmeno „š“. Vzhl’adom na to, že element munit má dcérske podelementy (reprezentuje totiž vzt’ah medzi dvoma znakmi, vid’ príklad IML súboru), pri zmene pozície by bol presúvaný celý podstrom XML. Našim ciel’om je ale získat’ jediný znak, element char neobsahujúci žiadne dcérske elementy. Trieda teda na správne miesto XML stromu vloží element char, ktorého obsahom je jediné akcentované písmeno získané mapovaním (pre akcent „check“ a znak „s“ bude výsledkom písmeno „š“). Element char obsahuje atribút ocrparam špecifikujúci myslený obdĺžnik ohraničujúci znak v spracovanom obrázku. Kedže nový znak zodpovedá pôvodnej dvojici znakov akcentu a písmena, trieda upravuje tento obdĺžnik tak, aby reprezentoval najmenší možný obdĺžnik obsahujúci zároveň obdĺžniky oboch pôvodných znakov. Po presunutí všetkých dcérskych elementov práve spracovávanémo elementu mblock je tento z IML úplne odstránený. Pre úplnost’ nám ešte zostáva doplnit’ chovanie v prípade, že je akcent prítomný vo dvojici s písmenom, u ktorého to príslušná trieda AccentMap neočakáva, a teda nepozná príslušné mapovanie. Mapovanie pre podporované akcenty boli tvorené so snahou o úplnost’, takže v prípade neznámeho mapovania trieda predpokladá výskyt chyby v OCR (zrejme chybne rozpoznaný akcent) a namiesto výsledku mapovania použije pôvodný znak bez akcentu. Ukážka časti IML súboru použitého ako vstup algoritmu: ... <mblock> ... <munit entity="1" ocrparam="685,1746,704,1758,0"> check <mlink type="under"> <munit ocrparam="684,1761,707,1794,0">s</munit> </mlink> </munit> ... </mblock> ... 3. v súčasnosti je hotové mapovanie pre českú a slovenskú diakritiku, ktoré môže byt’ v prípade potreby vel’mi jednoducho rozšíritel’né jednoduchou zmenou triedy AccentMap 35 4.6. WORKFLOW OCR A DÁVKOVÉ SPRACOVANIE Zodpovedajúca čast’ IML súbor po korekcii: ... <char ocrparam"684,1746,707,1794" entity="1">š</char> ... Trieda bola implementovaná v jazyku Java. Pre účely spracovania XML bola použitá knižnica dom4j <http://www.dom4j.org/>. Vývoj prebiehal vo vývojovom prostredí Netbeans <http://www.netbeans.org/> 5.0. 4.5.2 Trieda OCRJoiner Trieda OCRJoiner má za úlohu spojit’ výstup DML-CZ OCR s výstupom programu InftyReader, ktorý už bol upravený triedou IMLCorrector. Formát výstupu generovaného triedou OCRJoiner je formát programu InftyReader, teda IML. Trieda funguje na princípe prevzatia diakritických znakov z výstupu DML-CZ OCR. Ku každému znaku v spomínanom výstupe je vyhl’adaný pozičný ekvivalent vo výstupe triedy IMLCorrector, ktorý je v prípade rozdielu znakov a dostatočne vysokej dôvery v správnost’ rozpoznaného znaku (údaj je uvedený vo výstupe DML-CZ OCR) nahradený znakom z výstupu DML-CZ OCR. Pre podrobnosti týkajúce sa implementácie triedy a popisu jej chovania vid’ [3]. Príklad časti výstupu DML-CZ OCR: <charParams l="582" t="201" r="637" b="263" wordStart="true" wordFromDictionary="false" wordNormal="true" wordNumeric="false" wordIdentifier="false" wordPenalty="0" meanStrokeWidth="99" charConfidence="89" serifProbability="87">š</charParams> Príklad zodpovedajúcej časti výstupu triedy IMLCorrector: <char ocrparam="581,211,636,262,0">s</char> Príklad výstupu triedy OCRJoiner vzniknutého spojením výstupov DML-CZ OCR a triedy IMLCorrector: <char ocrparam="582,201,637,263,0">š</char> 4.6 Workflow OCR a dávkové spracovanie Všetky doposial’ popísané podproblémy sú riešené implementovanými izolovanými programami. Pre výsledné dávkové spracovanie bolo teda potrebné jednotlivé programy pospájat’ do funkčného celku, fungujúceho workflow. Každý program alebo trieda riešiaca daný podproblém pracuje izolovane nad dátami reprezentujúcimi jednu stranu spracovávaného dokumentu. Dávkové spracovanie by malo fungovat’ nad sadou dát, nad viacerými digitalizovanými stranami. Implementované dávkové spracovanie používa ako jednotku spracovania adresár. Nutnost’ou dávkového spracovania je teda vytvorit’ funkčný ret’azec spracovania jednotlivých strán, ktorý bude programom na vstup dávat’ príslušné digitalizované 36 4.6. WORKFLOW OCR A DÁVKOVÉ SPRACOVANIE stránky obsiahnuté v spracovávanom adresári, bude spravovat’ predávanie informácií (medziproduktov spracovania) medzi jednotlivými článkami ret’azca, ako aj potrebné predávanie stavovej informácie medzi dvoma iteráciami procesu spracovávajúcimi odlišné stránky (vid’ detekcia pokračujúceho bloku referencií v podkapitole FineReader Engine). Z dôvodu využitia predávania stavovej informácie medzi dvoma po sebe idúcimi stránkami na detekciu referencií je potrebné, aby súbory zoradené lexikograficky podl’a ich názvu reprezentovali korektne po sebe idúce strany fyzickej skenovanej predlohy. Workflow zobrazuje obrázok 4.5. Obrázok 4.5: workflow spracovania OCR Najskôr pripadalo do úvahy využit’ pre implementáciu skriptovací jazyk (napr. Perl). Túto možnost’ som ale zavrhol hlavne z dôvodu použitia častí písaných v jazyku Java (triedy IMLCorrector a OCRJoiner). Ovel’a jednoduchším riešením sa javilo byt’ použitie 37 4.6. WORKFLOW OCR A DÁVKOVÉ SPRACOVANIE dávkového spracovania taktiež implementovaného v jazyku Java. Pri tomto riešení odpadá nutnost’ spúšt’ania dvoch javovských programov obal’ujúcich používané triedy rozhraním príkazového riadku. Stačí využitie tried priamo v rámci programu riadenia dávkového spracovania (d’alej Batcher). Batcher po postupnom spustení spracovania všetkými článkami ret’aze vyskytujúcimi sa pred samotným spracovaním používanými triedami inštanciuje triedu (teda vytvorí objekt daného typu IMLCorrector alebo OCRJoiner) a pomocou novej inštancie pokračuje v spracovaní. Predávanie stavovej informácie medzi po sebe nasledujúcimi spusteniami DML-CZ OCR je implementované uchovaním návratovej hodnoty prvého zo spustení procesu. Táto hodnota je pri druhom spustení predaná procesu formou parametru príkazového riadku. V prípade, že spracovanie akéhokol’vek súboru programom DML-CZ OCR zlyhá, je stavová informácia nastavená na počiatočnú hodnotu nula. Stavová informácia udáva vel’kost’ použitého fontu v predposlednom bloku na stránke, ak tento blok bol predtým určený ako blok obsahujúci referencie. Hodnota nula znamená, že predposledný blok na strane referencie neobsahoval. Po prvej implementácii dávkového spracovania a jeho prvom teste na viac než štyristo súboroch som odhalil v spracovaní problém. Napriek tomu, že implementácia programu DML-CZ OCR nepoužívala grafické užívatel’ské rozhranie a program nepotreboval k svojej činnosti po spustení žiadnu interakciu s užívatel’om, som pri kontrole výsledkov dávkového spracovania zistil, že bolo spracovaných iba pár súborov a proces sa zastavil po zobrazení okna informujúceho užívatel’a o chybe. Jednalo sa o spracovanie súboru zaberajúceho zhruba desat’násobne väčší diskový priestor než bežné obrazové súbory. Pri jeho spracovaní si s ním FineReader Engine neporadil, súbor odmietol spracovat’ aj program FineReader Professional. Samotná neschopnost’ spracovania súboru nepredstavovala problém (no napriek tomu som o chybe informoval firmu Abbyy). Jednalo sa o nevýznamný súbor obsahujúci takmer čisto čiernu plochu obrovských rozmerov, o ktorej pôvode môžem iba špekulovat’. Súbor tochto typu sa objavuje vo viacerých adresároch predstavujúcich čísla digitalizovaných periodík. Problém predstavovala skutočnost’, že sa celý proces spracovania zastavil, čakajúc na potvrdenie dialógového okna s hlásením o chybe, ktoré FineReader Engine poskytuje nezávisle na implementujúcom programe. Riešenie tochto problému som vytvoril zrušením čakania na ukončenie DML-CZ OCR a zavedením časového limitu na jeho ukončenie. Ak sa proces neskončil do tochto časového limitu, predpokladal som zastavenie dávkového spracovania na spomínanom dialógovom okne a proces bol násilne ukončený. Podobné chovanie vedúce k zastaveniu procesu dávkového spracovania bolo neskôr zistené aj v programe InftyReader, ktorý napriek prítomnosti iba rozhrania príkazového riadku poskytoval niektoré kritické chybové správy formou dialógových okien čakajúcich na potvrdenie užívatel’om. Spomínané riešenie som teda použil aj pre proces programu InftyReader. Časový limit bol nastavený s dostatočnou rezervou pre prípad dlhotrvajúceho, no stále korektného spracovania obrázku na dvesto sekúnd. Pri prenose dávkového spracovania na výkonovo odlišný hardvér môže byt’ potrebné túto hodnotu dodatočne prispôsobit’. Ciel’om pri dávkovom spracovaní bola jednotnost’ v kódovaní textových dát. Po dohode s Mgr. Martinom Šárfym zastupujúcim skupinu spracúvajúcu aj výstup nášho procesu OCR sme zvolili kódovanie UTF-8. Všetky podstatné súbory, u ktorých sme mali na nastavenie 38 4.7. POMOCNÉ TRIEDY kódovania vplyv, používajú UTF-8. Rovnaké kódovanie sme sa snažili použit’ aj pre zdrojové súbory. Zdrojové súbory v jazyku Java ako aj skript jazyka Perl identify.pl sú uložené v spomínanom kódovaní. Trénovanie dát pre automatickú detekciu jazyka tiež prebiehalo na textoch kódovaných v UTF-8. 4.7 Pomocné triedy Pre implementáciu spojovania a dávkového spracovania boli implementované niektoré pomocné triedy ul’ahčujúce vývoj. jednalo sa o triedy zapuzdrujúce bounding boxy (ohraničujúce obdĺžniky) znakov, jednotlivé znaky a thready spracovania programov DML-CZ OCR a InftyReader. Všetky pomocné triedy sú implementované v jazyku Java a sú zdokumentované pomocou nástroja JavaDoc. Vzhl’adom na to, že sa jedná o triedy určené iba na ul’ahčenie implementácie, ktoré neobsahujú z hl’adiska tejto práce podstatné algoritmy alebo postupy, ich podrobnejší popis nie je uvedený. V prípade záujmu je možné konzultovat’ dokumentáciu vygenerovanú nástrojom JavaDoc. Pre úplnost’ uvádzam obrázok 4.6 reprezentujúci triedny diagram balíkov riešenia implementovaného v jazyku Java vrátane pomocných tried (jedná sa o balík cz.muni.fi.dmlcz.ocr). 4.8 Testovanie implementovaného riešenia Aby sme overili prínos nášho riešenia, spustili sme dávku spracovania 444 súborov. Bohužial’, nebolo v naších silách spočítat’ chyby na každom súbore v každom kroku spracovania (vrátane porovnania pri rozpoznávaní v programe FineReader 8.0 Professional Edition), a preto bola vybraná reprezentatívna vzorka ôsmich obrázkov. Chyby boli počítané ručne v porovnaní s originálnym obrazom v nasledujúcich krokoch spracovania: 1. počiatočné rozpoznanie zodpovedajúce DML-CZ OCR s univerzálnym jazykom a s použitím natrénovaných vzorov, 2. druhé rozpoznanie zodpovedajúce DML-CZ OCR so správnym jazykovým nastavením pre každý blok, 3. rozpoznanie v programe FineReader 8.0 Professional Edition (pre porovnanie) – simulácia jednotného jazykového nastavenia pre celé číslo časopisu, 4. rozpoznanie v programe InftyReader, 5. upravený výstup programu InftyReader (výsledok dávkového spracovania). 4.8.1 Metodika testovania Chyby na všetkých obrazoch boli počítané ručne, výsledné OCR sa porovnávalo so vstupným obrazom. Boli vytvorené nasledujúce kategórie chýb pre text: text, diakritika, matematika a layout. Pre citačné záznamy boli použité tieto kategórie: text, diakritika a layout. 39 4.8. TESTOVANIE IMPLEMENTOVANÉHO RIEŠENIA Obrázok 4.6: triedny diagram 40 4.8. TESTOVANIE IMPLEMENTOVANÉHO RIEŠENIA Kategória chýb text predstavuje chyby v slovách bežného textu, mien, názvov, ako v prípade textu tak i referencí. Kategória diakritika zahŕňa všetky chyby v diakritických znakoch. Kategória matematika obsahuje chyby v matematických výrazoch („display“ matematika) a v matematických symboloch vyskytujúcich sa v bežnom texte („inline“ matematika). Posledná špeciálna kategória layout zahŕňa všetky chyby, kde bol znak rozpoznaný správne, ale jeho formátovanie správne nebolo (napr. bol chybne označený ako kurzíva, horný index a podobne). Za jednu chybu je počítaná skutočnost’, ked’ na pozícii znaku podl’a obrazovej predlohy sa vo výsledku rozpoznávania objaví iný znak. Pritom nezáleží na tom, či vo výsledku sa namiesto znaku neobjaví nič, chybný znak alebo dva a viac znakov, stále se jedná o jednu chybu. Správne rozpoznaný znak so zlým formátovaním je považovaný za „layout“ chybu. Pri nájdení chyby spadajúcej do viacerých kategórií má najväčšiu prioritu chyba kategórie text, potom matematika a diakritika. Kategória layout ma najnižšiu prioritu. 4.8.2 Výsledky Testovacia dávka obsahovala 3 čísla časopisu Czech mathematical journal, čo predstavovalo 444 súborov. Pri spracovaní sa zistilo, že na 7 súboroch spracovanie programu InftyReader zlyhá a skončí pádom programu. Tento nedostatok rieši kolega Bc. Tomáš Mudrák s tvorcami programu, pretože sa zjavne jedná o chybu v programe InftyReader. Zoznam vybraných obrázkov s uvedením ich obsahu: • Obrázok 1: ABA007001146421956000300059.tif Obsah: anglický text s matematickými výrazmi. Pozn.: vstupný obraz nebol upravený programom BookRestorer. • Obrázok 2: ABA007001146421970000200080.tif Obsah: francúzský text s matematickými výrazmi. Pozn.: vstupný obraz nebol upravený programom BookRestorer. • Obrázok 3: ABA007001146421976000100009.tif Obsah: anglický text s matematickými výrazmi a blok referencií. • Obrázok 4: ABA007001146421976000100024.tif Obsah: anglický text s matematickými výrazmi a blok referencií. • Obrázok 5: ABA007001146421976000100064.tif Obsah: anglický text s matematickými výrazmi. • Obrázok 6: ABA007001146421976000100070.tif Obsah: anglický text s matematickými výrazmi. 41 4.8. TESTOVANIE IMPLEMENTOVANÉHO RIEŠENIA • Obrázok 7: ABA007001146421976000100082.tif Obsah: anglický text s matematickými výrazmi. • Obrázok 8: ABA007001146421976000300081.tif Obsah: blok referencií. Pozn.: nekvalitná predloha. Stĺpce tabul’ky T, D, M, L predstavujú kategórie chýb typu text, diakritika, matematika a layout, Tr, Dr, Lr predstavujú kategórie text, diakritika a layout, všetky v referenciách. Krok 1 2 3 4 5 T 10 4 4 14 14 D 0 0 0 0 0 M 224 170 168 24 24 Krok 1 2 3 4 5 L 82 78 71 15 15 Tabul’ka 4.2: chybovost’ pre obrázok č. 1 Krok 1 2 3 4 5 T 25 7 4 1 1 D 1 0 0 2 2 M 120 94 102 5 5 L 31 39 48 1 1 Tr 9 5 9 6 6 Dr 0 3 3 1 1 Lr 26 2 0 0 0 Tabul’ka 4.4: chybovost’ pre obrázok č. 3 Krok 1 2 3 4 5 T 65 6 5 1 1 D 0 0 0 0 0 M 90 121 143 2 2 L 47 63 30 0 0 Tabul’ka 4.6: chybovost’ pre obrázok č. 5 T 29 6 9 6 6 D 0 0 0 2 2 M 145 149 146 5 5 L 54 41 53 5 5 Tabul’ka 4.3: chybovost’ pre obrázok č. 2 Krok 1 2 3 4 5 T 5 4 3 3 3 D 0 0 0 0 0 M 64 66 57 10 10 L 16 16 30 0 0 Tr 6 2 6 4 4 Dr 0 0 2 2 1 Lr 64 64 1 1 1 Tabul’ka 4.5: chybovost’ pre obrázok č. 4 Krok 1 2 3 4 5 T 12 4 2 0 0 D 0 0 0 0 0 M 275 235 219 5 5 L 133 169 142 3 3 Tabul’ka 4.7: chybovost’ pre obrázok č. 6 42 4.8. TESTOVANIE IMPLEMENTOVANÉHO RIEŠENIA Krok 1 2 3 4 5 T 8 5 0 1 1 D 0 0 0 0 0 M 95 90 105 16 16 L 36 29 13 0 0 Krok 1 2 3 4 5 Tabul’ka 4.8: chybovost’ pre obrázok č. 7 T 3 3 3 2 2 D 0 0 8 2 1 M 0 0 0 0 0 L 7 7 0 0 0 Tr 3 3 3 20 20 Dr 0 0 12 6 0 Lr 130 130 2 0 0 Tabul’ka 4.9: chybovost’ pre obrázok č. 8 V tabulkách je vidiet’ obrovské zníženie počtu chýb pri použití programu InftyReader. V prípade referencií je jeho výstup ješte viac vylepšený triedami IMLCorrector a OCRJoiner. Vel’ké percento chýb je z kategorie layout, počítanie týchto chýb sme najskôr zvažovali, no nakonie sme sa rozhodli chyby zahrnút’. V prípade referencií by mohla byt’ informácia o kurzíve využitá pre detekciu metadát, a tak sme chceli zistit’, ako sú v tomto smere OCR programy presné. Z jednotlivých počtov chýb bola následne zostavená nasledujúca tabul’ka, ktorá ukazuje percentuálnu úspešnost’ v jednotlivých krokoch spracována (stĺpce). V prvom stĺpci (DMLCZ OCR 1) je uvedená úspešnost’ pri úvodnom rozpoznaní programom DML-CZ OCR s nastavením univerzálneho jazyka. Druhý stĺpec (DML-CZ OCR 2) zodpovedá úspešnosti druhého rozpoznania v DML-CZ OCR so správnym jazykovým nastavením, tretí stĺpec (FR 8.0 PE) je úspešnost’ rozpoznania v programe FineReader 8.0 Professional Edition, štvrtý stĺpec (IR) je úspešnost’ programu InftyReader a posledný stĺpec (IR mod.) vyjadruje prínos tried IMLCorrector a OCRJoiner. V poslednom riadku je uvedená úspešnost’ celej sady ôsmich testovaných súborov. Obrázok 1 2 3 4 5 6 7 8 Spolu DML-CZ OCR 1 84,99 % 86,93 % 89,19 % 93,40 % 91,09 % 79,46 % 92,59 % 91,33 % 88,65 % DML-CZ OCR 2 88,03 % 88,76 % 92,35 % 93,52 % 91,62 % 80,05 % 93,39 % 91,33 % 89,90 % FR 8.0 PE 88,46 % 88,07 % 91,53 % 95,78 % 92,15 % 82,25 % 93,71 % 98,30 % 91,23 % IR 97,48 % 98,97 % 99,18 % 99,15 % 99,87 % 99,61 % 99,09 % 98,18 % 98,97 % IR mod. 97,48 % 98,97 % 99,18 % 99,19 % 99,87 % 99,61 % 99,09 % 98,61 % 99,02 % Tabul’ka 4.10: percentuálne úspešnosti v jednotlivých krokoch spracovania V našom teste bolo teda dosiahnuté v porovnaní s FineReader 8.0 Professional Edition zlepšenie o 7,79 %, z toho 7,74 % prinieslo úspešné naviazanie programu InftyReader na výstup DML-CZ OCR a jeho integrácia do procesu spracovania. Java triedy na výstupu 43 4.9. MOŽNÉ ZLEPŠENIA programu InftyReader zvýšili presnost’ o d’alších 0,05 %. Ďalej sme spočítali, že vo výsledkoch nášho testu prípadá priemerne 1,26 chyby na jeden bibliografický záznam. Toto číslo sa môže zdat’ vysoké, no negatívne ho ovplyvnil obrázok 8, ktorého fyzická predloha (číslo vyšlo v roku 1976) bola menej kvalitná. Tento obrázok bol však do testu zahrnutý zámerne, pretože proces pobeží aj na starších číslach časopisov. Celková úspešnost’ na 8 súboroch bola 99,02 %. 4.9 Možné zlepšenia Pri testovaní implementovaného riešenia som zistil oblasti, v ktorých by sa použité postupy dali vylepšit’. Niektoré zlepšenia sú nutné z dôvodu prispôsobenia postupov novým dátam, než na ktorých sa skúšali pri implementácii. Vzhl’adom na obrovské a neustále sa zväčšujúce objemy dát nebolo v mojich silách mnou implementované postupy a metódy odskušat’ na celej množine dát. Testovanie za účelom zhodnotenia prínosu preto odhalilo určitý priestor pre vylepšenia. Vzhl’adom na to, že toto nastalo už po ukončení implementácie, nie sú tieto vylepšenia v implementovanom riešení prítomné. Implementácia niektorých vylepšení bola zase nemožná z dôvodu nejasnosti niektorých v budúcnosti plánovaných väzieb na iné časti projektu DML-CZ. Pri testoch dávkového spracovania som identifikoval určité strany spracovávaného časopisu obsahujúce začiatok bloku, pred ktorým sa vyskytoval aspoň 1 odstavec d’alšieho textu. Algoritmy FineReader Engine po analýze rozloženia stránky na nej napriek vertikálnej medzere, pre človeka dostatočne jasne oddel’ujúcej dva bloky (odstavce) stránky, identifikovali čast’ referencií spolu s predchádzajúcim textom ako jeden súvislý blok. V tomto prípade zlyháva detekcia bloku referencií, pretože kl’učové slovo uvodzujúce referencie, napriek jeho korektnému predrozpoznaniu, sa nevyskytovalo na začiatku, ale niekde zhruba uprostred spracovávaného bloku textu. V prípade snahy o odstránenie obmedzenia sa regulárneho výrazu výhradne na začiatok bloku a akceptovanie kl’účového slova aj v tele bloku prestal fungovat’ mechanizmus detekcie pokračovania referencií4 . Pri ukladaní vel’kosti fontu referencií (vid’ FineReader Engine) sa totiž využíva skutočnost’, že začiatok bloku je určite textom skutočného bloku referencií a ako vel’kost’ fontu sa používa vel’kost’ fontu prvého písmena bloku. Vo vyššie opísanom prípade však prvé písmeno nebude patrit’ referenciám, takže bude uložená nesprávna vel’kost’ fontu. Tento problém by sa mal dat’ riešit’ presunutím vyhl’adávania pomocou regulárnych výrazov zo skriptu identify.pl do C++ kódu programu DML-CZ OCR. Po vyhl’adaní kl’účového slova sa dá jednoducho určit’ jeho pozícia v celom ret’azci. Toto číslo sa dá potom použit’ na zistenie indexu písmena s požadovanou správnou vel’kost’ou fontu, ktorú si chceme zapamätat’ (či už je to text za kl’účovým slovom alebo prvé písmeno kl’účového slova samotného). Pri snahe o implementáciu tejto funkcionality v skripte identify.pl by zrejme bolo problémové predávanie pozície v ret’azci medzi skriptom a DML-CZ OCR (návratové hodnota programu je už využitá na 4. vzhl’adom na to, že regulárny výraz stále požadoval slovo na samostatnom riadku, bola zámena s kl’účovým slovom vyskytujúcim sa náhodne v texte nepravdepodobná 44 4.9. MOŽNÉ ZLEPŠENIA predávanie nájdených jazykov). Vzhl’adom na to, že vstupný text je v skripte pred spracovaním zbavený nadbytočných bielych a iných znakov, nemusí získaná pozícia kl’účového slova zodpovedat’ realite programu DML-CZ OCR. V prípade existencie metadát o začiatočných a koncových stranách článkov v spojení s rozdel’ovaním strán tak, aby sa na jednej strane nestretli 2 rôzne články (jeden končí a iný začína), by sa dala detekcia pokračovania refrencií o túto informáciu rozšírit’. V prípade spracovania poslednej strany článku by sa s určitost’ou vedelo, že danou stránkou zoznam referencií končí. Zdrojové súbory DML-CZ OCR už obsahujú minimálnu podporu tochto vylepšenia vo forme zakomentovanej malej časti kódu, ktorá v prípade signalizácie poslednej strany článku na konci spracovania strany predpokladá koniec zoznamu referencií, a teda návratová hodnota aktuálnej inštancie programu, ktorá bude predaná nasledujúcej inštancii, nebude signalizovat’ prítomnost’ referencií. Trieda IMLCorrector by mohla vykonávat’ na IML súbore viaceré úpravy než je tomu teraz. Okrem rozšírenia množiny podporovaných akcentov (podl’a nedostatočnej podpory akcentov v programe InftyReader) by mohla byt’ činnost’ triedy rozšírená o substitúciu diakritických znakov zapísaných pomocou entít, umiestnených mimo matematických blokov za ich UTF-8 ekvivalent5 . Po vykonaní určitých testov a zistení častých chýb programu InftyReader by trieda taktiež mohla opravovat’ niektoré vel’mi pravdepodobné chyby OCR (napr. znak „1“ s dĺžňom bude pravdepodobne v skutočnosti znak „ĺ“ alebo „í“). Detekcia bloku referencií fungujúca na princípe jednoduchého regulárneho výrazu hl’adajúceho určité kl’účové slová na samostatnom riadku na začiatku textového bloku môže v prípade chyby v predrozpoznanom kl’učovom slove zlyhat’ (napr. namiesto „References“ budeme mat’ „Relerences“). Je otázne, či by používaný regulárny výraz nemal tolerovat’ určité množstvo chýb. V prípade tolerancie väčšieho počtu chýb sa môže zvýšit’ počet tzv. „false positives“, v prípade nízkej alebo žiadnej tolerancie chýb bude vyšší počet „false negatives“. Bolo by preto potrebné preskúmat’ chovanie programu na väčšej dávke súborov s počiatočnými blokmi referencií a zistit’, aké a kol’ko (ak vôbec) chyby sa v predrozpoznanom texte vyskytujú. Následne by mohla byt’ určená miera tolerancie vyhl’adávania k chybám. Na základe určitých predchádzajúcich skúseností sa domnievam, že počet tolerovaných chýb by sa mohol rovnat’ číslu 1, možno dokonca 2. Zlepšenia týkajúce sa práce Bc. Tomáša Mudráka možno nájst’ v [3]. 5. v súčasnosti prebieha substitúcia dvojice akcent + znak za UTF-8 znak, nahradzovaná dvojica sa však hl’adá iba v matematických blokoch 45 Kapitola 5 Záver Hlavným prínosom práce je vytvorenie automatizovaného workflow. Spolu s automatizáciou je dobrým výsledkom aj zlepšenie presnosti OCR pre matematické texty. OCR je problematika, pri ktorej sa dá devät’desiatpercentná (prípadne vyššia) úspešnost’ dosiahnut’ relatívne jednoduchými princípmi a postupmi, no d’alšia cesta smerom k zvyšovaniu presnosti je zložitá a pracná. Zlepšenie vyplývajúce z použitia popisovaného riešenia je zrejmé z výsledkov testovania (vid’ Testovanie implementovaného riešenia). Pri testovaní sa podarilo identifikovat’ niektoré problémy, prípadne d’alšie možné vylepšenia implementovaného riešenia, ktoré z časových dôvodov nemohli byt’ súčast’ou samotnej implemenácie. Pre účely d’alšieho rozširovania sú však tieto zachytené v podkapitole Možné zlepšenia. Riešenie implementované v tejto práci sa opriera o digitalozovaný časopis Czech mathematical journal a využíva niektoré jeho špecifiká, ktoré sa v iných digitalizovaných dátach nemusia vyskytnút’. Zrejmé je, že pri objemoch dát, s akými sa bude spracovanie OCR stretávat’ v rámci projektu DML-CZ, je potrebné implementované OCR postupy priebežne vylepšovat’ a prispôsobovat’ novým požiadavkám. Vzhl’adom na fakt, že čoraz väčšie množstvo dokumentov je v súčasnej dobe už vytváraných v digitálnej podobe, bude úloha OCR časom mierne klesat’. Mierne kompenzujúcim faktorom môže byt’ vel’ká snaha o retrodigitalizáciu už vytlačených textov, pričom existuje možnost’ (príkladom môže byt’ práve projekt DML-CZ) narazenia na vel’mi špecifické problémy OCR, v ktorých stále je čo zlepšovat’. 46 Literatúra [1] BookRags, Incorporated: Bookrags OCR, dostupné (máj <http://www.bookrags.com/sciences/computerscience/ optical-character-recognition-csci-02.html>. 2006) na [2] Suzuki, M. a Tamari, F. a Fukuda, R. a Uchida, S. a Kanahori, T.: INFTY - An integrated OCR system for mathematical documents, 2003, <http://www.inftyproject. org/articles/2004_ICCHP_Suzuki.pdf>. [3] Bc. Tomáš Mudrák: Digitalizace matematických textů, máj 2006. [4] Wikipedia, the free encyclopedia: Optical character recognition, dostupné (máj 2006) na <http://en.wikipedia.org/wiki/Optical_character_recognition>. [5] Rákosník, J.: Czech Digital Mathematics Library. Project proposal, august 2004, dostupné (máj 2006) na <http://dml.muni.cz/docs/projekt-dml.pdf>. [6] Dunning, T.: Statistical Identification of Language, marec 1994. [7] Kranig, S.: Evaluation of Language Identification Methods. [8] Cavnar, W. a Trenkle, J.: N-Gram-Based Text Categorization, apríl 1994. [9] Wick, K.: Sazba matematických vzorců čtyřřádkovým způsobem, 1961, Nakladatelství Československé akademie věd. 47 Dodatok A CD príloha V koreňovom adresári CD prílohy práce sa vyskytujú adresáre builds, sources, tests a súbor index.html. Adresár sources obsahuje zdrojové súbory implementovaných programov a diplomovej práce, adresár builds obsahuje súbory potrebné pre beh implementovanej sady programov, teda skompilované verzie zdrojových súborov, a PDF verziu diplomovej práce. Nakoniec adresár tests obsahuje vstupy a výstupy vykonaných testov porovnania prínosu práce a čiastočne aj vstupy a výsupy iných testov (čast’ výsledku testu dávkového spracovania). Pre podrobnejšie informácie o aktuálnom obsahu CD vid’ súbor index.html. 48