Automatizované retušování digitalizovaných textů

13. 7. 2009 | Jiří Poláček | Návody | 9187×

Posledních pár týdnů jsem se věnoval digitalizaci knih, a to zejména fázi retušování naskenovaných stránek, přičemž jsem se seznámil s řadou užitečných programů a metodou pokusů a omylů si sestavil poměrně propracovaný postup, který by třeba mohl inspirovat i někoho z vás. Nuže, zde je jeho první část.

Obrázky skenované z knížky trpí mnoha neduhy, jejichž hlavním viníkem je skutečnost, že snímaná předloha není zcela rovná – text tak bývá naskenován zešikma, okraje i hřbetní předěl mezi listy je zvýrazněn černými šmouhami, o drobném šumu napříč celou stranou nemluvě. Se všemi těmito „neřády“ se snaží vypořádat program unpaper, který představuje vlajkovou loď mého pracovního postupu. Kromě „čistění“ stránek navíc umí rozdělit nasnímané dvoustrany na jednotlivé stránky, jejich otáčení, zmenšování a zvětšování, přidávání okrajů či hromadné zpracování více souborů najednou. Abych však nepřechválil, ani unpaper není všemocný a – jak ukázaly pokusy – na některé očistné procedury se lépe uplatní i jiné prográmky.

Získání naskenovaných obrazů

Zpět na začátek – ke skenování. V našich poloamatérských podmínkách se jako jednoznačně nejvýhodnější ukázalo snímání na „velké“ černobílé kopírce – oproti klasickému stolnímu skeneru je výrazně rychlejší a má větší snímací plochu (tj. A3). Snímáme černobíle v rozlišení 200 dpi; vyšší rozlišení pro naše potřeby nemá valného smyslu a odstíny šedé jsou spíše ku zlosti než k užitku – skeny nemají dostatečný kontrast, okolo písmen je patrný šum, občas je patrný text z druhé strany listu a velikost skenovaného souboru roste u průměrné 400stránkové knížky do stovek megabajtů. I s těmito vadami na kráse se samozřejmě dá něco dělat (viz dále), ale osobně preferuji se jim vyhnout.

Zmíněná kopírka umí nasnímané stránky uložit jako PDF či vícestránkový TIFF. Z hlediska obsahu je to celkem jedno, z praktického hlediska je však vhodnější PDF, neboť z něj lze získat strany v jednotlivých souborech v požadovaném formátu pro další zpracování a s potřebným číslováním přímo, zatímco s TIFFem je to poněkud krkolomnější:

 # tiffsplit sken.tiff dvoustrana 

→ vytvoří sadu souborů s jednotlivými nasnímanými dvoustranami pojmenovanými jako dvoustranaaaa­.tif, dvoustranaaab.tif atd. až dvoustranazzz.tif

 # for I in dvoustrana*.tif; do tifftopnm $I > ${I%%.tif}.pbm; done

→ převede jednotlivé dvoustrany do formátu PBM

 # C=1; for I in dvoustrana*.pbm; do rename $I dvoustrana$(printf %03d $C).pbm $I; C=$((C+1)); done 

→ přejmenuje do číselné posloupnosti, se kterou umí pracovat unpaper, tj. dvoustrana001.pbm atd.

Pro převod z PDF slouží program pdftoppm:

 # pdftoppm -r 200 -mono sken.pdf dvoustrana 

→ vytvoří sadu souborů dvoustrana001.pbm atd. ve formátu PBM

Parametr -r udává výstupní rozlišení – pokud není uveden, tak se předpokládá 150 dpi. Tímto programem tak zároveň lze měnit i velikost obrázků – za použití vhodného výstupního dpi a parametru -gray namísto -mono lze získat text obstojně vyhlazený do odstínů šedé. K tomuto účelu se mi nicméně nakonec více osvědčil jiný program, o kterém se zmíním později.

Vsuvka

Začínám zmiňovat nějaké formáty a programy a možná by nebylo od věci zmínit, co to je za formáty a kde ty programy vzít. PDF a TIFF předpokládám není třeba představovat. PBM je zkratka z Portable BitMap a jedná se nekomprimovaný formát pro uložení černobílé rastrové grafiky. Analogicky existují též PGM (aka Portable GrayMap) a PPM (Portable PixMap) pro uložení šedoškálových a barevných nekomprimovaných obrázků. Obecně se tato rodinka tří formátů označuje zkratkou PNM.

K těmto velice primitivním formátům postupem času přibyl ještě jeden – PAM. Slouží k uchovávání obecných dat v matici, lze v něm uložit nejenom to stejné, co v PBM, PGM a PPM, ale i některé věci navíc, třeba průhlednost. Drobnou vadou na kráse je skutečnost, že jiné programy (například Gimp, Okular, Gwenview) formátu PAM (zatím?) nerozumějí.

Vzhledem ke své jednoduchosti jsou tyto formáty snadno programátorsky uchopitelné i bez použití cizích knihoven (proto s těmito formáty také pracuje unpaper), na druhou stranu zabírají nemálo diskového prostoru, takže je záhodno obrázky po zpracování převést do něčeho úspornějšího.

Celé stovky programů pro práci s obrázky PNM – převodníky, editory, generátory, analyzátory a další – jsou obsaženy v nástrojové sadě netpbm, patří k nim již zmíněný tifftopnm, některé další zmíním později – většinou obsahují jeden z formátů v názvu. Základní manipulaci s obrázky TIFF obstará knihovna libtiff, její součástí je zmíněný tiffsplit i tiffcp, který naopak seskládává samostatné obrázky do vícestránkového TIFFu. Pro úplnost dodám, že pdftoppm je součástí balíčku poppler.

Oříznutí velkých černých okrajů

Kopírka, na které skenujeme většinu knih, je vybavena funkcí automatické detekce velikosti snímané předlohy. Vinou této funkce jsme museli některé knihy skenovat znovu, neboť autodetekce samozřejmě nefunguje dobře – chybějící čísla stránek by ještě šla jakž takž překousnout, ale přepůlený poslední řádek textu na stránce už je příliš. Proto jsme kopírku fixně přenastavili na maximální možný formát A3, abychom měli jistotu, že skutečně o nic nepřicházíme. To nicméně u snímání knih menšího formátu znamená, že ve výsledku máme velké černé okraje (viz obrázek), se kterými si unpaper tak úplně neví rady.

Přesněji řečeno bylo by zapotřebí si spočítat zvětšení a posun stránky, následně trochu experimentovat a výsledek by se určitě dostavil i s unpaperem. Mnohem jednodušší však je nepotřebné okraje hromadně oříznout programem pamcut:

 # for I in dvoustrana*.pbm; do pamcut 350 0 2510 1850 $I > ${I%%.pbm}orez.pbm; done

Parametry programu definují obdélník, který má po ořezu z obrázku zůstat – první dvě číselné hodnoty jsou xová a yová souřadnice levého horního rohu, druhé dvě pak šířka a výška obdélníku. Přesná čísla lze nejlépe odečíst z nějakého grafického editoru (sám používám Gimp) a jedné vybrané naskenované dvoustrany. Při počítání je jistě vhodné vymezit obdélník raději trošku větší než o něco přijít, tentokráte vlastní vinou.

Existuje též program pnmcrop, který odstraňuje okraje definované barvy, tj. nabízí se jakási automatika bez nutnosti počítání velikosti obdélníku, takto ořezané obrázky však mohou být různě velké, což pro další zpracování není zrovna žádoucí.

Čištění šedého pozadí

Neumím si to tak úplně vysvětlit, ale nemálo skenovaných knih obsahovalo texty v rámečku se šedým pozadím, které naskenováno černobíle nevypadá zrovna nejlépe – viz obrázky (1:1 a 8:1).

Unpaper sice obsahuje filtr na odstraňování šumu s volitelně nastavitelnou intenzitou, na takovéto šedé pozadí nicméně nezabírá – s malou intenzitou pročistí jen částečně a s velkou už se začnou ztrácet například také tečky nad „i“. Naštěstí existuje program pbmclean. Ten pro každý bod obrázku spočítá, kolik z osmi okolních bodů má stejnou barvu, a pokud jich je méně, než předepsané minimum, kontrolovaný bod invertuje. Výchozí minimum sousedů je jeden bod, takže se zahlazují pouze izolované body; s pomocí parametru -minneighbors lze toto minimum upravit. Podívejme se, co dokáže pbmclean s parametry -minneighbors=2 a -minneighbors=3:

Na čtveřici dokolečka spojených bodů je podmínka minimálně dvou sousedů nedostatečná, s minimálně třemi už není po původně šedém pozadí ani památky, avšak to negativně zasáhlo i písmena, jak je vidět například na přepůleném „z“.

Jelikož jsou nechtěné černé body pospojovány především diagonálně, zatímco pro chtěné body tvořící znaky to neplatí, nebylo by od věci čistící algoritmus aplikovat tak, aby za sousední body byly považovány jenom ty se společnou hranou. To originální pbmclean bohužel neumí – naštěstí se ale jedná o open source a úprava zdrojového kódu je opravdu jednoduchá. Zkompiloval jsem si tedy vlastní pbmclean (diff) a čištění nyní provádím ve dvou krocích následovně (pominu-li konstrukci cyklu):

 # ~/netpbm-10.26.62/editor/pbmcle­an -black zdroj.pbm > TMP && pbmclean -minneighbors=2 TMP > vysledek.pbm 

Přepínač -black zajistí, že předmětem zkoumání jsou pouze černé body, aby nedocházelo k invertování izolovaných bílých bodů uprostřed „koleček“. Neskromně si troufám tvrdit, že výsledek už nemůže být lepší:

Převod do odstínů šedé

Doposud nepředstavovalo omezení na jednobitovou barevnou hloubku žádný závažnější problém, spíše naopak se dala ocenit menší velikost souborů. S korekcí sklonu naskenovaného textu a tedy otáčením obrazu programem unpaper už to však problém je. Prostě a jednoduše řečeno, otočený černobílý obrázek nevypadá dobře – rozhodně ne tak dobře, jak originál, ostatně porovnejte sami (první obrázek je originál, druhý pootočený):

Některá písmena vizuálně ztloustla, jiná nikoliv – záleží na úhlu otáčení, někdy je to patrné více, jinde méně, v každém případě je však lepší se tomu vyhnout. Možnosti jsou zhruba následující:

1. nekorigovat sklon, tj. volat unpaper s parametrem --no-deskew
2. pomocí parametru -t pgm sdělit unpaperu, aby výsledek vracel v odstínech šedé
3. převést naskenované texty do šedé sám a teprve následně použít unpaper

Pokud šla skenovaná kniha dobře rozevírat a nasnímané texty tak jsou vesměs neskloněné, je první možnost ideální. U většiny materiálu, který se mi ale dostane na obrazovku, však touha po korekci sklonu přímo bije do očí. Druhá možnost také není vyloženě k zahození, ale výsledek trpí podobným neduhem jako černobílý výsledek:

Osobně se tedy přikláním ke třetí možnosti, protože když se povede dobrý převod do odstínů šedé, povede se i pootočení textu. A není následně problém výsledek relativně kvalitně převést zpět na černobílou, jak ukážu v příštím díle.

Vyhlazení textu do šedých odstínů jde vynutit změnou velikosti obrázku, jak již jsem zmínil u programu pdftoppm, z balíčku netpbm by na to šel použít například pamscale. Lepší způsob je ale použití programu příznačně pojmenovaného jako pbmtopgm. Jeho aplikací jsou všechny body v obrázku přepočítány jakou průměr hodnot z definovaného okolí; pár pokusů ukázalo, že nejmenší možné okolí 2 × 2 dává nejlepší výsledky. Poslední přípravnou operací před použitím unpaperu je tedy následující:

 # for I in dvoustrana*.pbm; do pbmtopgm 2 2 $I > ${I%%.pbm}.pgm; done 

Ale ouha. Výsledek sice vypadá dobře, ale je uložen s deklarací, že body nabývají pěti různých barevných hodnot, zatímco unpaper očekává plný rozsah 256 hodnot a není tak schopen zdrojový soubor zpracovat správně. I zde tedy přichází ke slovu úprava zdrojového textu programu pbmtopgm (diff) a kompilace vlastní verze, která uloží výsledek v odstínech šedé v kódování, kterému unpaper rozumí (chybu jsem nahlásil, ale těžko říci, zda bude někdy unpaper v tomto ohledu opraven).

Stránky naskenované v odstínech šedé

Na závěr prvního dílu návodu tu mám ještě jeden tip, který představuje další dva programy z balíku netpbm. Na začátku návodu jsem tvrdil, že je lepší se vyhnout skenování dokumentů v odstínech šedé – pokud však přeci jenom takový materiál dostaneme ke zpracování, zachrání nás následující magická formule:

 # pgmdeshadow strana001.pgm | pnmnorm -maxexpand=50 > vylepsena_stra­na001.pgm 

→

Program pgmdeshadow – jak již název napovídá – odstraňuje stíny v šedých obrázcích, pnmnorm pak normalizuje kontrast.

Příště

Druhý (a zároveň poslední) díl návodu k retušování digitalizovaného textu popíše program unpaper a potřebné kroky ke zkompletování výsledku.

       

Komentáře

[Fluttershy, yay!]

Parádní článek, díky! (Ale pochybuji, že to využiji... těch několik knížek mám nafocených a to v nepříliš vysoké kvalitě.)

[Petr Tomášek]

Bohužel tyto postupy nelze doporučit u rozličných orientálních písem (arabské, hebrejské, syrské...), kde občas dost záleží na detailech (tečky, tj. tzv. punktace, případně i tvary písmen). Nakonec jsem osobně unpaper úplně vyloučil ze svého repertoáru a při převodu na formát DJVU vyloučil „optimalizaci“.

Raději jsem se naučil, jak kopírovat a skenovat texty tak, aby se co nejméně musely posléze zpracovávat v počítači...

[Jardík]

Proč nepoužít ORC?

[Jardík]

Teda OCR

[Fluttershy, yay!]

Poradí si s něčím jiným než latinkou nebo azbukou? (Kanji.)

[Jardík]

Proč by neporadil ... stačí to naprogramovat. Trocha té algebry, ukázat tomu pár příkladů a OCR je na světě.

[Fluttershy, yay!]

IMHO to tak jednoduché nebude.

[qk]

Kdyz uz jsme u toho OCR - jake mate zkusenosti a co pouzivate sa programy?

[Jiří Poláček]

Otázce tak úplně nerozumím, každopádně OCR je určitě jedním z důvodů, proč retušování dělat – kvůli lepším výsledkům rozpoznávání textu.

[Filip Jirsák]

Jenže to retušování udělá OCR také, a může o udělat lépe, než nějaké obecné retušování. Třeba ono odstraňování šumu a šedého podkladu – to udělá OCR daleko lépe, protože může při odšumování zároveň kontrolovat, zda ona tečka náhodou není součástí nějakého znaku. Navíc se může orientovat také tím, že šum mimo řádky textu může odstraňovat automaticky atd.

[Jiří Poláček]

Zajímavé! Rozpoznáváním textů jsem se nikdy moc do hloubky nezabýval, takže jsem si nevšiml, že by z nějakého OCR-programu kromě textu vypadl též retušovaný obraz …

[Filip Jirsák]

Retušovaný obraz z něj zpravidla nevypadne, ale vypadne rovnou formátovaný text. Pokud z toho textu chcete mít retušovaný obraz, vyexportujte onen formátovaný text do nějakého obrázku

[Jiří Poláček]

Tak to bychom měli odpověď na původní otázku – protože chci zachovat původní vzhled skenovaného dokumentu.

[Filip Jirsák]

Jde o to, čemu říkáte původní vzhled. Pokud formátování – to zůstane. Pokud chcete mít původní obrázek – OCR ten dokument také správně otočí, nakloní a ořízne, zbytek ale nechá. Což je podle mne správně – pokud chci u textu nechat i původní obrázek, dělám to z toho důvodu, kdyby dopadlo rozpoznávání špatně (moc šumu apod.). A v takovém případě je nesmysl odstraňovat šum a dělat jiné vylepšení obrazu, protože chci zachovat právě ten originál, ze kterého lidský mozek možná ještě něco vyčte, ale automat na něm selhal.

Opravdu mi není jasné, k čemu je ta retuš bez OCR dobrá. Buď si s předlohou poradí automat, pak to nechám udělat OCR, které neodstraňuje jen šum z obrázku, ale má i informace o tom, co na obrázku má být, takže s ním dokáže pracovat daleko lépe. Nebo si s předlohou automat neporadí, a pak to přece nebudu automatem kazit a ponechám to v „originále“ (tzn. dostatečné DPI, rotace, naklonění a ořez, případné korekce interference skeneru a předlohy).

[Jiří Poláček]

Mám tu tisíce naskenovaných stránek a k nim retušované podoby. Každému, komu ukáži rozdíl, mi potvrdí kvalitativní skok kupředu – a to je pro mne dostatečný důvod k tomu vyrábět „vylepšené originály“. Tím netvrdím, že bych odmítal OCR, ale je to pro mne pouze volitelný krok v procesu zpracování.

[Filip Jirsák]

V tom případě právě ale nechápu, proč to rovnou neproženete OCRkem. Budete z toho mít rovnou text, ve kterém se dá vyhledávat, ze kterého se dá kopírovat. Bylo by to možná rychlejší, než ono „retušování“, a výsledek má mnohem vyšší užitnou hodnotu.

[Bilbo]

OCR je pekne a na obycejny text, doplneny semtam par obrazky funguje slusne, ale poradi si s matematickymi vzorci, pripadne jinymi specialnimi symboly (ruzne tecky ci podtrzitka nad/pod pismeny, caste napr. v matematickych textech, nebo nektery z velke hromady vselijakych technickych ci matematickych symbolu) a zmenami pisma (preskrtnuti, podtrzeni, ...)?

Obcas OCR selze a pak je clovek rad za takovyhle postup ke zkvalitneni predlohy.

[Filip Jirsák]

S příslušným profilem si OCR poradí i s tím. A když ne, pořád tam zůstane ten upravený (ořez, otočení) originální obrázek, ze kterého nějaká automatická retuš neodstranila ony tečky, zmenšená písmena a podtržení.

[JS]

Chtel jsem podotknout k tomu cernobilemu skenovani. Ja jsem si knizky vzdycky skenoval ve skale sedi ve 150 nebo 300 dpi (pokud byla vedecka a byly tam male symboly), a prislo mi to (uz tech 150) citelnejsi nez cernobila v rozliseni 600 dpi. Nedelal jsem to ale kvuli OCR, ktere miva se skalou sedi problemy (stejne jako ostatni nastroje). I kdyz je pak pomerne snadne to prevest - muzete to nejak interpolovat treba na tech 600 dpi a pak provest prahovani.

Ale moje hlavni zduvodneni bylo, ze pokud mam ja jako clovek mensi problem se ctenim knihy (na obrazovce) ve 150 dpi / 16 odstinu nez 600 dpi / 2 odstiny, pak by tato schopnost mela byt definovatelna nejakym algoritmem. Komprese je samozrejme jina otazka, ale dnes uz snad velikost knih nikdo neresi (ovsem dokud jsem neznal DJVU, tak i ten 600 dpi TIFF zabira vice nez 150 dpi PNG).

Jeste zajimava vec, kterou jsem delal k odstraneni cernych okraju byla, ze jsem vsechny stranky logicky secetl. Vysledny obrazek ukazoval, kde mam odstrihnout cerne pozadi (abych neporusil pismenka).

[petr_p]

Vícestupňový scan je něco jako antialiasing. Na výstupním zařízení s podobným rozlišením (obrazovky mají kolem 100 dpi) vypadá moc dobře. Ale zkuste si pak takový dokument zpětně vytisknout. Vzhledem k tomu, že většina tiskových technik (inkoustové taky?) mouhou odstíny pouze simulovat ditheringem, tak pak tisk vícestupňového 150dpi obrázku na řekněme černobílé 600dpi tiskárně dopadne hrůzostrašně. Proto si považuji za rozumnější scanovat ve vyšším rozlišení bitonálně. Na obrazovce se díky vyššímu rozlišení zubatost (téměř) ztratí, při tisku naopak získám přesně to, co jsem naskenoval, protože nedám šanci přepočítavacím algoritmům tiskárny.

Ohledně účinnosti DjVu: Nedávno jsem dělal pokus. 600dpi bitonální scan A4 čistého textu s větším písmem jsem bezztrátově zkomprimoval pomocí cjb2 -dpi 600 -clean. Výsledek 40 KB. To považuji za více než uspokojivý výsledek.

[Andrej Herceg]

Pred pár týždňami som sa pokúšal dať do djvu nejaké naskenované dokumenty. Veľkosť súboru bola výborná, ale hneď po tom, ako som si všimol, že je to nejaké rozmazané som sa s tým začal trochu hrať a prišiel som na to, že keď použijem rovnaké parametre (a teda hlavne DPI, rozmery, počet farieb...) v akomkoľvek formáte (a teda napr. v pdf) tak dostanem porovnateľne malé súbory a ak budem chcieť v djvu rovnakú kvalitu, tak budem mať zase veľké súbory.

[petr_p]

DjVu definuje několik kompresních formátů. Každý je vhodný na jiný typ „obrázku“. Třeba beletrie, kde jsou celostránkové ilustrace se dělají tak, že na běžné textové stránky a na stránky s obrázky se používají jiné algoritmy.

Silná zbraň DjVu je vlnková komprese. Jenže ta má smysl jen u čistých scanů ve vysokém rozlišení, protože je postavená na vyhledávání hran. U obrázků spíše připomínajících kostičky (což třeba 9pt písmo na 150 dpi je) je kontraproduktivní.

Další silná zbraň je oddělení pozadí od popředí. Tyto dvě vrstvy mají obvykle odlišný charakter, a tak se každá komprimuje jiným algoritmem.

Tohle všechno ale jsou věci, které se automatikou neudělají, protože ta těžko změří subjektivní dojem.

Je pravda, že DjVu nemá žádný überalgortimus, který by zázračně smrsknul soubor. Nicméně mám zkušenosti, že u hloupě zvolené komprese nebo nevhodného vstupu je výstup porovnatelný (mnohdy o deset dvacet třicet procent menší) s třeba PDF/JPEG. U kvalitních scanů s dobře vybraným algoritmem DjVu válcuje ostatní formáty velmi výrazně (50 a více procent). U opravdu mrňavých dokumentů s mizerným rozlišením a pár barev je ale PNG často lepší. To ale není cílová skupina DjVu.

Prostě moje zkušenosti jsou opačné. Jestli se ale chceme bavit seriózně, musíme se uchýlit k experimentu. Zkusím najít ten mnou vzpomínaný scan.

[petr_p]

Přílohy:

• nebezpecny_odpad.jb2 (41194 bytů)
• nebezpecny_odpad.pbm.lzma (108221 bytů)

Tohle je 600dpi dvoutónový scan. Poněkud větší patkové písmo, řídký text, malá grafika, černobílá předloha:

-rw-r--r-- 1 petr users   41194 11. čec 20.27 nebezpecny_odpad.jb2
-rw-r--r-- 1 petr users   41966 13. čec 20.26 nebezpecny_odpad.jb2.noclean
-rw-r--r-- 1 petr users 4348196 13. čec 21.02 nebezpecny_odpad.pbm
-rw-r--r-- 1 petr users  108221 13. čec 20.22 nebezpecny_odpad.pbm.lzma
-rw-r--r-- 1 petr users  161144 13. čec 20.22 nebezpecny_odpad.png

Verze *.noclean se liší vypnutým vyčištěním „drobků“. Podle rozdílového testu čištění příliš pixelů neodebralo.

[Ladislav Nešněra]

když už se takto skenuje ve "velkém" - neexistuje na to nějaký spec. kus HW, který by to usnadnil? Někde jsem viděl celé robotizované pracoviště, ale to nemyslím. Stačilo by něco, aby i bez lámání hřbetů zůstaly řádky rovné nevznikal středový pruh.

[bl4z4]

U dokumentů se používají specializované dokumentové skenery (malý / velký). Důležitá je rychlost skenování a objem naskenovaných listů za den. U knihy je špatné, že ji nelze šoupnout do zásobníku, pokud ji neroztrháte vazbu. Samotné naskenování je k ničemu pokud se dokumenty nezařadí do nějaké úložiště (digitální archiv) a nepřiřadí indexy. K tomu se většinou používají specializované programy jako Teleform, Kofax express (určitě jsou i další, ale s těmi nemám zkušenosti). Nedokáži si představit digitalizování dokumentů v domácích podmínkách. Obětovaný čas musí být nepředstavitelný.

Autorovi přikladám pár zkušeností s libtiff knihovnou (i pro win):

Instalace pod win: http://gnuwin32.sourceforge.net/packages/tiff.htm a http://gnuwin32.sourceforge.net/packages/jpeg.htm
Instalace pod Linuxem: apt-get install libtiff (či něco podobného), doporučuji si, ale přeložit 4.0.0beta3, která bez problémů zvláda kompresi/dekompresi JPEG, Old-style JPEG

Zjištění informace o TIFFu (šikovné i na testování zda není TIF špatný, jinak pozor na Old-style JPEG kompresi)
C:\Program Files\GnuWin32\bin>tiffinfo.exe C:\tiff-test\test.tif

Dekomprese TIFFu black and white s CCIT4 kompresí
C:\Program Files\GnuWin32\bin>tiffcp.exe -c none C:\tiff-test\test.tif C:\tiff-test\none-black-and-white.tif

Dekomprese TIFFu gray s JPEG kompresí
C:\Program Files\GnuWin32\bin>tiffcp.exe -c none C:\tiff-test\test.tif C:\tiff-test\none-gray.tif

Dekomprese color bohužel u verze win nejde, na Linuxu lze přeložit verze 4.0.0beta3 libtiff knihovny, která zvládne i toto.

Komprese TIFFu black and white pomocí CCIT4 komprese
C:\Program Files\GnuWin32\bin>tiffcp.exe -c g4 C:\tiff-test\none-black-and-white.tif C:\tiff-test\g4-black-and-white.tif

Komprese TIFFu gray s JPEG kompresí
C:\Program Files\GnuWin32\bin>tiffcp.exe -r 8 -c jpeg:r:82 C:\tiff-test\none-gray.tif C:\tiff-test\jpeg-gray.tif

Příkazy jsou samozřejmě stejné i v Linuxu s úpravou cest. Nechtělo se mi to přepisovat, tak snad nebudou rýpalové, kterým by to vadilo .

Ještě na závěr zjištění dle mých zkušeností:

Pro B/W je nejlepší CCIT4 komprese a pro Color JPEG komprese (ne Old-style JPEG - to je prasárna mimo standard!).

[bl4z4]

Tak ještě malé doplnění. Pro retušování (odstranění šedého pozadí, narovnání stránky, otočení dle orientace textu, oříznutí černých okrajů, odstranění prostřihů pro vkládání do desek, ostření, atd.) se používá technologie VRS (Virtual ReScan), pěkně popsáno zde. OCR je fajn věc při rozeznávání čárových kódů (pro indexaci ideální, pokud s tím počítá výstup). Rozeznání textu už je náročnější, ale pokud je pěkný sken nebývá to problém (stačí přidat většinou DPI). Velmi pěkné je rozeznávání textů u rukou psaných formulářů, kde je s pomocí korigovacího softwaru vyšší produktivita zpracování (např. Teleform Verifier).

[Jiří Poláček]

Ano, dalo by se říci, že se taktéž snažím o „virtuální přeskenování“

[Ladislav Nešněra]

jasně. Jednotlivé listy jsou triviální. Já se ptal speciálně na vázané dokumenty. Očekával bych, že bude existovat buď něco tenkého, co jde přímo vložit mezi stránky nebo že snímací plocha bude tvarově přizpůsobena částečně otevřené knize.

[bl4z4]

S tímto nemám zkušenosti, ale viděl jsem pouze něco jako foťák na stojánku, což mi nepřišlo moc praktické. Jinak na webu jsem našel super článek s video prezentací, jak takový automatický skener na digitalizaci knih vypadá a pracuje. Je to tak, jak si předpokládal.

[Bilbo]

Videl jsem scanner, ktery ma na jedna strane snimaci plochu temer az k okraji, ktery je trochu upraven (pulka knihy je zastrcena ve scanneru, druha pulka z nej visi ven pod uhlem cca 95 stupnu), takze knihu tam lze vlozit tak, ze scanovana stranka je rovna a oscanuje ji to az ke kraji, aniz by vzniklo typicke zakriveni, ztmaveni a rozmazani ktere se jinak objevuje u hrbetu.

Asi neco jako tohle: http://images.macnn.com/macnn/news/0906/plustek-a3scanner-18.jpg

Je to porad manualni scanovani, ale leze z toho lepsi predloha :)

[Ladislav Nešněra]

Po tomhle řešení už jsem se také poohlížel, ale nenarazil jsem na žádný scanner s dostatečně malým okrajem. Díky za tip.

[moira]

U dokumentů se používají specializované dokumentové skenery...
A u knih napr. toto. Samozrejme, ze domu si to nikdo neporidi...

[Ladislav Nešněra]

podle těch videí by se našlo víc lidí, co by ten scanner při práci dokázali celé hodiny pozorovat

[Heron]

Dobrý článek. Na scan používáme komerční programy (njn. dotace), ale takový návod se vždy hodí.

Snímáme černobíle v rozlišení 200 dpi; vyšší rozlišení pro naše potřeby nemá valného smyslu

Proč ne? Při vyšším DPI by písmenka vyšla mnohem silnější (a po převodu do šedé vyhlazenější) a okolní šum by naopak zůstal jedno pixelový, čímž by šel snáze odstranit. Nebo je tam jiný problém?

[Jiří Poláček]

Primárním výstupním zařízením digitalizovaných knih by měla být obrazovka, proto si vystačíme s menším DPI (které též znamená menší velikost souboru a rychlejší zpracování). Zkoušeli jsme i 300 dpi, ale kvalitativně jsme v tom neviděli zásadní rozdíl – čímž samozřejmě netvrdím, že pro někoho jiného ten rozdíl nemůže být podstatný.

[Heron]

Primárním výstupním zařízením digitalizovaných knih by měla být obrazovka, proto si vystačíme s menším DPI

To jo, na výstupu. Proces zpracování by mohl probíhat třeba na 600 DPI a na konci by se to zmenšilo na 200 DPI. Dělají to tak běžně zvukovky (interně pracují v 32b rozlišení), profesionální grafika se také tvoří v mnohem větším rozlišení než je konečný výstup. Dělá se to k vůli chybám, které proces zpracování do signálu stejně vnáší.

[Marztin]

Co to je za šílenosti? Připadám si jak v době t602. Není lepší koupit nějaký dobrý komerční OCR balík (Fine Reader) a neřešit?

Proč se radši budu šťourat levou rukou v pravém uchu na Linuxu, místo rychlého splnění úkolu na Windows? Nechápu fanatika, který týden ladí postup s nevhodnými programy a to jen proto, že to má na Linuxu...

[dad]

asi Vas jako radu ostatnich zmatlo to slovo 'digitalizovanych' v nadpisu a prestal jste dal cist. Jinak byste zahledl to slovo 'retusovani' . Ale takovou vadu ma rada lidi, nekteri kdyz slysi 'uspech', tak si predstavi 'podnikatel' a jdou hodit listek ODS.

[kolemjdoucí]

Možná jste si nevšiml titulku článku: "Automatizované retušování digitalizovaných textů." A asi se budete divit, ale jsou lidé, které zajímá jak zpracování obrazu vlastně funguje a rádi se dívají věcem "pod pokličku".

 

[Tomáš Pelc]

Ono je totiž celé kouzlo ukryto ve slůvku "automatizované". Fine Reader je výborný program (mám jej), ale na desítky knih o různých formátech je to jako "levou nohou za pravým uchem" - prostě nevhodné. Je mnohem časově i finančně úspornější několk hodin/dní ladit skript a pak jej mnoho měsíců používat. Na jednoúčelovky je samozřejmě FR vhodnější.

Navíc zatím moc o OCR řeč nebyla. Co když dokumenty jen potřebuji zdigitalizovat a posléze se rozhodnout zda tisk nebo OCR? V tomto směru je skriptování téměř nezastupitelné (včetně šifrování, archivace apod.)

[Ash]

Práci strojům... S Fine Readerem je to v podstatě ruční práce. Nic proti, můžete na to za malé peníze najmout nějakého asiata a "neřešit", jak říkáte, ale v Linuxu existuje levnější a efektivnější řešení (uvedeno v článku, doporučuji přečíst).

[Hobil]

Rucni prace s Fine Readerem neni nutna. Korporatni verze umi vybirat soubory ze zadaneho adresare a automaticky je prevadi a vyhazuje vysledky v pozadovanem formatu (trebas zde zminovane pdf). Moznych nastaveni je hafo, lze vytvaret ruzne adresare pro soubory s ruznymi parametry atd atd. Sekretarka se pak s ocr vubec nepotka, po naskenovani dokumentu se k ni dostane  jen prislusny pdfko k zalozeni.

FR samozrejme umi "narovnavat" ohnutte radky od hrbetu knih, lze nastavovat vzory pro ruzne typy souboru, zminovane vzorce se prevadeji jako obrazky, uroven rozpoznani je natolik vysoka, ze tech par ojedinelych "preklepu" v x-strankovem dokumentu fakt nehraje roli. Pri slusne predloze nemivame 100% uspesnost precteni stranky v jednom pripade ze 30-40 stran. To znamena ze se na te chybove strance neprecte jeden znak spravne.

H.

[analfabet]

Ja sam jsem naskenoval celkem dost knih. Unpaper mne prisel naprosto tragicky. Nejlepsi efektivity i vysledne kvality jsem dosahl v ruskem programu (podle vseho freewaru) ScanKromsator, originalne pro windows, bezi ale bez problemu pod wine. Pri googleni pozor, nejnovejsi (a nejlepsi) mne znama verze je 5.91. Umoznuje mj. automaticke (ale kvalitni!) rozrezani stranek na dve poloviny, kvalitni vyrovnani naklonu, sumu v obrazcich, etc. Je to dost sofistikovany program. Jedine, co mi neni jasne, je jeho status, resp. proc pri jeho kvalitach neni daleko znamejsi a nema nejakou slusnou webovou stranku.

 

Programem, jenz miri ke stejnemu cili, ale zatim u nej zdaleka neni je ScanTailor, rovnez rusky program. Na rozdil od ScanKromsatora je open-source a ma peknou stranku http://scantailor.sourceforge.net/ Tesim se, ze z nej vzejde program kvality ScanKromsatora, ovsem bez te obskurity.

[Petr]

 Na prevod pdf do obrazku pbm nebo jpeg pouzivam program pdfimages. Ten vytahne obrazky v puvodni kvalite, takze neni treba nastavovat rozliseni ani nic dalsiho.

 

[Bilbo]

Uzitecny nastroj. Nesmi se ovsem zapomenout na parametr -j

Jinak dotycny tool ma mozna malou mouchu: "nepodporuje" JPEG2000 - resp. obrazky v PDF komprimovane pomoci JPEG2000 zapise jako PBM (at zije rekomprese ...)

[Jiří Poláček]

pdfimages je stejně jako pdftoppm součástí poppler, takže se dá očekávat stejný výsledek při extrakci obrázků (samozřejmě při správném DPI u druhého programu). Ale jinak díky ta tip.

[Yokotashi]

Pred nekolika lety jsem se timto problemem take zabyval. Snazil jsem se pripravit text, aby:

1. se dobre zpracoval OCR

2. dobre skladoval (male soubory => malo sumu)

3. dobre cetl

4. zmizely prostredni sede pruhy (polozime-li rozevrenou knihu na scanner, pismenka uprostred jsou na sedsim podklade a deformovana - tento problem autor zjevne neresi)

Dospel jsem ke zcela opacnemu postupu, nez autor: nascannovat to na 300dpi ve stupnich sedi, pote udelat vsechny transformace a nakonec to pripadne prevest do dvou stavu (cerna/bila) a nizsiho rozliseni.

 

Rucnim cistenim jsem dospel k zaveru, ze neni treba prevadet do dvou stavu a nizsiho rozliseni, protoze vycisteny text je velmi dobre komprimovatelny a temer nic se tim neusetri (nicmene to jde zcea snadno).

 

Diky menici se barve pozadi jsem zacal "derivaci" a orizl vse pod 5 (sum - puvodne bylo 255 urovni), cimz z pismen zbyly jen obrysy. Tecka nad  i mela cca 10x10px (skripta z FELu). Normalni pismena mela hranu obrysu sirokou 2-4px, ale u pismen blizko hrbetu (nechtel jsem knihy nicit) to byl 1-2px a sem  tam se obrys i prerusil, coz byl problem. Pak jsem vyhazel vsechny souvisle objekty mensi, nez cca 25px.

 

Pak melo nasledovat vybarveni obrysu, ale tim, ze se pismena u hrbetu rozpadala, zacal jsem resit, jak je opravit  a nakonec jsem to vzdal z casovych duvodu. Za predpokladu spojitych obrysu je vybarveni pomerne snadne - nahodny pixel, ktery neni soucasti obrysu se vybarvi jednou barvou a od nej se barva rozlije vsude. Pak se najde rozhranni, kde je z jedne strany vybarveny a z druhe nevybarveny pixel a hned za nim se to vybarvi druhou barvou. Opakujeme, dokud neco  takoveho existuje. Pak se hleda rozhranni druhe barvy a niceho a za nej se da prvni barva. a porad dokola (nektera recka pismena potrebuji 3 cykly pri optimalni volbe prvniho bodu). Barva, ktere je vice, je bila. hrany se linearne interpoluji do sede.

[Jiří Poláček]

4. zmizely prostredni sede pruhy (polozime-li rozevrenou knihu na scanner, pismenka uprostred jsou na sedsim podklade a deformovana - tento problem autor zjevne neresi)

Při černobílém skenování samozřejmě pruh uprostřed není šedý, ale v černobílém ditheringu, který bezpečně odstraní například filtry unpaperu (o tom se zmiňuji v druhém díle návodu). V případě skenování v odstínech šedé pruh uprostřed odstraní pgmdeshadow, jak ukazuje příklad v textu.

Co se týče deformace písmenek, tak to je skutečně nepříjemný problém, který nicméně opravdu neřeším, neboť si ani nedokážu představit, jak by to automatizovaně šlo udělat Naštěstí jsem se ještě nesetkal s takovou deformací, že by to už nešlo přečíst.

[Bilbo]

Pokud se udela derivace a orizne sum, tak by mohlo stacit to zpetne "zintegrovat". Problem bude, ze tim vyhlazovanim sumu se nekdy vyhladi vice kladnych hran nez zapornych, takze by pak i pozadi bylo sede, ale pokud se derivace vynasobi treba 2x a udela se clipping po kazdem pixelu do (0,255), tak by to mohlo fungovat celkem dobre (velkych derivaci by bylo stale "dost" aby pismo vycernily a stranku vybelily).

[Pavel Čejka]

Možná jsem to přehlédl ... ale existuje velmi jednoduchý způsob, jak se zbavit prosvítajícího textu z protilehlé stránky. Prostě stránku přiklopit černou plochou, nikoli víkem s plochou bílou. Výsledkem je o něco tmavší (nepatrně) obrázek bez prosvítajícího tisku na rubu, ten se pak dá snadněji doladit (jas, kontrast, gama). Některé staré scannery Microtek měly černá víka, ale u nových jsem to už dlouho neviděl.