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

[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.