abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
dnes 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 201 hlasů
 Komentářů: 7, poslední 19.10. 23:06
    Rozcestník

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

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

    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.

    Naskenovaná dvoustrana s příliš velkými černými okraji

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

    Originální naskenovaný obrázek ve 100% rozlišení Originální naskenovaný obrázek v přiblížení 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-minneighbors=3:

    Pročištěný obrázek s parametrem -minneighbors=2 ve 100% rozlišení Pročištěný obrázek s parametrem -minneighbors=2 v přiblížení 8:1
    Pročištěný obrázek s parametrem -minneighbors=3 ve 100% rozlišení Pročištěný obrázek s parametrem -minneighbors=3 v přiblížení 8:1

    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ší:

    Pročištěný obrázek upraveným programem pbmclean ve 100% rozlišení Pročištěný obrázek upraveným programem pbmclean v přiblížení 8:1

    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ý):

    Originální černobílý obrázek před otočením Černobílý obrázek po otočení unpaperem

    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:

    Černobílý obrázek otočený unpaperem a převedený do šedých odstínů

    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 

    Černobílý obrázek převedený do odstínů šedé programem pbmtopgm

    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 

    Originální obrázek naskenovaný v odstínech šedéStejný obrázek opravený programy pgmdeshadow a pnmnorm

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Fluttershy, yay! avatar 13.7.2009 00:11 Fluttershy, yay! | skóre: 81 | blog:
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 avatar 13.7.2009 00:22 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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 avatar 13.7.2009 01:40 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Proč nepoužít ORC?
    Věřím v jednoho Boha.
    Jardík avatar 13.7.2009 01:40 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Teda OCR :-)
    Věřím v jednoho Boha.
    Fluttershy, yay! avatar 13.7.2009 13:11 Fluttershy, yay! | skóre: 81 | blog:
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Poradí si s něčím jiným než latinkou nebo azbukou? (Kanji.)
    Jardík avatar 13.7.2009 17:16 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Proč by neporadil ... stačí to naprogramovat. Trocha té algebry, ukázat tomu pár příkladů a OCR je na světě.
    Věřím v jednoho Boha.
    Fluttershy, yay! avatar 13.7.2009 17:24 Fluttershy, yay! | skóre: 81 | blog:
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    IMHO to tak jednoduché nebude.
    21.7.2009 12:59 qk
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

    Jiří Poláček avatar 13.7.2009 08:25 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    13.7.2009 08:40 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 avatar 13.7.2009 09:44 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 …
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    13.7.2009 10:31 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 avatar 13.7.2009 11:50 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Tak to bychom měli odpověď na původní otázku – protože chci zachovat původní vzhled skenovaného dokumentu.
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    13.7.2009 12:35 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 avatar 13.7.2009 13:09 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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í.
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    13.7.2009 13:59 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 avatar 13.7.2009 16:12 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    13.7.2009 16:57 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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í.
    13.7.2009 07:46 JS
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

    13.7.2009 09:39 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 13:07 Andrej Herceg | skóre: 43
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.
    13.7.2009 18:49 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 21:11 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Přílohy:

    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.

    13.7.2009 10:02 Ladislav Nešněra | skóre: 30 | blog: ..+2
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 11:03 bl4z4 | skóre: 12 | blog: bl4z4
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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!).

    Novinář: "Má podle vás umělá inteligence budoucnost?" A. C. Clarke: "Pevně doufám, že ne jen umělá."
    13.7.2009 11:15 bl4z4 | skóre: 12 | blog: bl4z4
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

    Novinář: "Má podle vás umělá inteligence budoucnost?" A. C. Clarke: "Pevně doufám, že ne jen umělá."
    Jiří Poláček avatar 13.7.2009 11:37 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    Ano, dalo by se říci, že se taktéž snažím o „virtuální přeskenování“ :-)
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    13.7.2009 14:54 Ladislav Nešněra | skóre: 30 | blog: ..+2
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 15:51 bl4z4 | skóre: 12 | blog: bl4z4
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    Novinář: "Má podle vás umělá inteligence budoucnost?" A. C. Clarke: "Pevně doufám, že ne jen umělá."
    Bilbo avatar 13.7.2009 16:08 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 :)
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    15.7.2009 11:51 Ladislav Nešněra | skóre: 30 | blog: ..+2
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    14.7.2009 00:19 moira | skóre: 30 | blog: nesmysly
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    U dokumentů se používají specializované dokumentové skenery...
    A u knih napr. toto. Samozrejme, ze domu si to nikdo neporidi...
    Překladač ti nikdy neřekne: "budeme kamarádi"
    15.7.2009 12:00 Ladislav Nešněra | skóre: 30 | blog: ..+2
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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 avatar 13.7.2009 10:03 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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 avatar 13.7.2009 11:45 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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ý.
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    Heron avatar 13.7.2009 19:00 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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áší.

    13.7.2009 10:04 Marztin
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

    13.7.2009 10:15 dad
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 10:44 kolemjdoucí
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

     

    13.7.2009 10:50 Tomáš Pelc | skóre: 22 | blog: multimedialni_pc_k_LCD_TV
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

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

    14.7.2009 15:06 Ash | skóre: 53
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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).
    28.7.2009 12:43 Hobil
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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.

    13.7.2009 12:26 analfabet
    Rozbalit Rozbalit vše Lepsi program

    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.

    14.7.2009 14:13 Petr
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

     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 avatar 14.7.2009 15:59 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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 ...)
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    Jiří Poláček avatar 14.7.2009 20:21 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.
    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    14.7.2009 20:26 Yokotashi
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů

    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 avatar 14.7.2009 21:14 Jiří Poláček | skóre: 47 | blog: naopak | Sivice
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.

    Sudoku omrzelo? Zkuste bobblemaze! | Statistiky jsou jak bikiny. Napoví hodně, všechno ale neukážou.
    Bilbo avatar 14.7.2009 21:19 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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).
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    Pavel Čejka avatar 16.7.2009 22:42 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: Automatizované retušování digitalizovaných textů
    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.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.