Biblioteka 2.0 on Facebook
Biblioteka 2.0 Strona Główna

Biblioteka 2.0
Forum społeczności czytelników i bibliotekarzy cyfrowych

FAQFAQ  SzukajSzukaj  UżytkownicyUżytkownicy  GrupyGrupy  StatystykiStatystyki
RejestracjaRejestracja  ZalogujZaloguj  AlbumAlbum  DownloadDownload

Poprzedni temat «» Następny temat
Lepszy OCR w plikach DjVu
Autor Wiadomość
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-01-29, 15:12   Lepszy OCR w plikach DjVu

Temat pojawiał się już w różnych kontekstach, ostatnio tutaj, ale chyba warto go w końcu umieścić w osobnym wątku i stopniowo gromadzić pomysły, opinie i doświadczenia.

Istnieje dość proste i eleganckie rozwiązanie problemu jakości warstwy tekstowej w plikach DjVu, niestety nie bez wad, o których niżej.

    1. skany można wsadowo OCR-ować za pomocą FineReader Engine, który daje możliwość zapisywania wyników do formatu XML z zachowaniem oryginalnej skali skanu i z dokładnością do słowa (tzn. w pliku XML zapisywany jest tekst i koordynaty określające położenie każdego słowa)

    2. XML z FR Engine da się za pomocą procesora XSLT (np. xsltproc) i odpowiedniego arkusza XSLT konwertować na XML spacyficzny dla formatu DjVu. Można to oczywiście robić w sposób zautomatyzowany.

    3. djvuxmlparser z DjVuLibre pozwala importować przygotowane w p. 2 pliki DjVu-XML do dokumentów DjVu.

Jeśli założyć, że wszyskie fazy przetwarzania będą zautomatyzowane - OCR, konwersja i import XML, a także samo tworzenie dokumentów DjVu (Enterprise) - to cała procedura może być też bardzo wydajna.

Teraz o wadach.

FineReader Engine, to koszt rzędu 4500 euro netto. To jest opłata za narzędzia programistyczne, które pozwalają stworzyć odpowiednią linię produkcyjną (wykorzysta się przy tym oczywiście tylko ułamek możliwości bogatego API, bo chodzi jedynie o zapis OCR do XML z precyzją "word"). Do tego należy doliczyć klucze licencyjne dla użytkowników końcowych. Ceny tych kluczy w zależności od produktywności i dodatkowych modułów (np. zapis do PDF, eksport do XML itp.) są bardzo zróżnicowane - od 170 euro netto do ponad 8000 euro netto.

Można też zamówić rozwiązanie oparte na FineReader Engine "szyte na miarę", tzn. gotowy produkt tworzący odpowiedni XML. Wtedy płaci się za przygotowanie narzędzia, za jego utrzymanie/serwisowanie i za licencje RTL użytkowników końcowych, ale odpada koszt licencji samego FR Engine.


ABBYY Recognition Server (który od biedy też daje się wykorzystać, choć zapisuje w XML tylko koordynaty całych linii, a nie słów) w podstawowej konfiguracji przy produktywności 25 tys. stron na miesiąc kosztuje ok. 1500 euro netto. Górna granica cenowa Recognition servera - 13 000 euro netto.

Zarówno FineReader Engine, jak Recognition Server potrafią robić OCR z gotyku, ale jest to objęte odrębną licencją i płaci się za to ekstra.
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-03-06, 13:28   Re: Lepszy OCR w plikach DjVu

sk napisał/a:

Istnieje dość proste i eleganckie rozwiązanie problemu jakości warstwy tekstowej w plikach DjVu, niestety nie bez wad, o których niżej.

    1. skany można wsadowo OCR-ować za pomocą FineReader Engine, który daje możliwość zapisywania wyników do formatu XML z zachowaniem oryginalnej skali skanu i z dokładnością do słowa (tzn. w pliku XML zapisywany jest tekst i koordynaty określające położenie każdego słowa)

    2. XML z FR Engine da się za pomocą procesora XSLT (np. xsltproc) i odpowiedniego arkusza XSLT konwertować na XML spacyficzny dla formatu DjVu. Można to oczywiście robić w sposób zautomatyzowany.

    3. djvuxmlparser z DjVuLibre pozwala importować przygotowane w p. 2 pliki DjVu-XML do dokumentów DjVu.

Jeśli założyć, że wszyskie fazy przetwarzania będą zautomatyzowane - OCR, konwersja i import XML, a także samo tworzenie dokumentów DjVu (Enterprise) - to cała procedura może być też bardzo wydajna.

Teraz o wadach.


Właśnie skończyliśmy pomyślnie testy trochę innego rozwiązania opartego o bardziej standardowe klocki. Klocki to:
FineReader 9.0 - tu był Prof. Trial, ale do masówki potrzebny byłby Corporate (w cenie 789 zł netto dla edukacji - łapiemy się wszyscy) oraz
DjVU Enterprise.
Niestety FR Prof. Trial nie robi wielostronicowych PDF.

Efekty składanki można zobaczyć w załącznikach. Wejściowy TIFF jest za duży do pokazania.

Procedura:
Zakładamy, że:
1) TIFFy to pliki wejściowe.
2) nie będziemy korygować ręcznie OCR by uzyskać efekt max. automatyzacji procesu.

Więc tak:
Etap I
Uzyskanie dobrego rozpoznanego tekstu i zapisanie do XML:
1. FR-em robimy z TIFFa plik PDF z "czystą" czcionką, bez wciągania obrazu "dokumentalnego" skanu. FR zapisując PDF zachowuje pozycję słów. (Plik 1.)
2. Za pomocą Ent. konwertujemy ten PDF do "pośredniego" obrazka DjVu z rozpoznaniem OCR (tryb Elektronic Enterpise'a) - i dostajemy "pośredni" DjVu z "czystą" czcionką jako wastwą OCR. (plik 2)
3. Za pomocą Ent. ekstrahujemyz tego DjVu z wykonanym OCR sam tekst - zapisując go w pliku XML (plik 7). W tym celu można zaznaczyć opcję w Ent. albo użyć polecenia djvutoxml

Uwaga: Plik DjVu z tego etapu jest do wyrzucenia, bo chodziło tylko o ten XML.

Etap II:
Klejenie OCR do dobrego DjVu:
4. Robimy Ent. z TIFFa plik DjVu dobrej jakości bez OCR.
5. Wciągamy do tego DjVu za pomocą Ent. plik XML uzyskany w I etapie - polecenie djvuparsexml

Etap III:
No i mamy DjVu z dobrym OCR z FR.

Dla porównania same pliki DJVU:
Plik 3. - to DJVU zrobiony po staremu motorem z Enterprise'a.
Plik 4. - to DJVU zrobiony powyższą procedurą, z wykorzystaniem FR.
w plikach .doc (5. i 6.) zapisany jest tekst pobrany narzędziem tekstowym pluginu DjVu z obu plików DJVU (3. i 4.)


To procedura prototypowa, "na piechotę" i na jednym pliku. Żeby z tego zrobić taśmę trzeba by mieć FR Corporate, który wg informacji od dystrybutora ma funkcję "Hot Folder & Scheduling". I kolejne efekty procesu można by wrzucać wsadowo Enteprise'owi.
Jeśli te wsadowe procedurki zadziałałyby na zbiorach plików - można to umasowić, tylko potrzebny byłby jakiś scriptmaker.

PS. Fajnie, że Śpiechu i Grzegorz Bednarek lubią kombinować różne sztuczki. ;-)

XML-histref.zip
7. Plik XML z tekstem i jego pozycjonowaniem na stronie
Pobierz Plik ściągnięto 1221 raz(y) 10.67 KB

6.OCR-motor-FR.doc
6. Warstwa tekstowa z pliku DJVU motorem FR (z pkt. 3)
Pobierz Plik ściągnięto 1142 raz(y) 27.5 KB

5.OCR-motor-DJVU.doc
5. Warstwa tekstowa z pliku DJVU motorem Enterprise'a (z pkt. 4)
Pobierz Plik ściągnięto 1171 raz(y) 28.5 KB

4.histref_ENTERPRISE_OCR.djvu
4. DJVU z warstwą OCR uzyskaną z Enterprise'a bezpośrednio z TIFF'a (czyli jak zwykle) - dla porównania z poz. 3.
Pobierz Plik ściągnięto 1182 raz(y) 43.15 KB

3.histref_FR_OCR.djvu
3.DJVU z warstwą OCR uzyskaną z FR
Pobierz Plik ściągnięto 1189 raz(y) 41.63 KB

2.histref_przejsciowy.djvu
2. DJVU "przejsciowy" uzyskany z PDF za pomocą Enterprise'a rozpoznany motorem DJVU z warstwą OCR
Pobierz Plik ściągnięto 1190 raz(y) 18.17 KB

1.hist-reformacji-1-0108.pdf
1. PDF uzyskany z TIFF za pomocą FR z rozpoznaniem tekstu.
Pobierz Plik ściągnięto 1067 raz(y) 31.57 KB

_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
Ostatnio zmieniony przez relis 2009-03-09, 09:42, w całości zmieniany 1 raz  
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-03-06, 15:30   

relis napisał/a:
Właśnie skończyliśmy pomyślnie testy trochę innego rozwiązania opartego o bardziej standardowe klocki. Klocki to:
FineReader 9.0 - tu był Prof. Trial, ale do masówki potrzebny byłby Corporate (w cenie 789 zł netto dla edukacji - łapiemy się wszyscy) oraz
DjVU Enterprise.
Niestety FR Prof. Trial nie robi wielostronicowych PDF.

Efekty składanki można zobaczyć w załącznikach. Wejściowy TIFF jest za duży do pokazania.

Procedura: (...)

Nie wiem, czy prościej, ale trzeba przyznać, że na pewno taniej! Jeśli chodzi o Enterprise'a, to nasza załoga z pracowni digitalizacji dopiero go obmacuje z myślą o zakupie. Dobrze wiedzieć, że i w ten sposób da się go wykorzystać.

Inna sprawa, że znajdujemy się wszyscy w dość kiepskim położeniu, jeśli chodzi o format DjVu. Od oprogramowania, ża które płaci się ciężkie pieniądze, można by oczekiwać, że zrobi swoją robotę dobrze od początku do końca, a tymczasem trzeba wymyślać jakieś dziwne ciągi technologiczne, bo jeden program nie radzi sobie zadowalająco z OCR, drugi nie wspiera DjVu, a o jakiej-takiej kompatybilności, tzn. żeby umiały w naturalny sposób współpracować, nie ma mowy.
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-03-26, 13:17   

Kwestie techniczne to jedno. Niebawem będziemy mieli FR Corporate i uruchomimy lepszy OCR. Na pewno wydłuży to proces publikacji. Dopóki nie będzie on wystarczająco krótki i robiony automatem, myślimy nad kryteriami wyboru publikacji do tego lepszego OCR. Na pewno warto robić tak książki adresowe, wydawnictwa encyklopedyczne i słownikowe, oraz rzeczy faktograficzne (niektóre gazety, opracowania monograficzne, etc.).

Drugi problem to kwestia konwersji już opublikowanych rzeczy do postaci z lepszym OCR. Zamiar jest taki: wydaje się tu pożyteczna wskazówka statystycznego użytkowania zasobu w BC (najczęściej otwierane). Mówiąc krótko patrzymy w listę najpopularniejszych publikacji i przerabiamy im warstwę OCR na podstawie zachowanych masterów, podmieniając starą treść prezentacyjną.
Myślę, że kwestia takiej "retrokonwersji" stanie się ważna dla wszystkich BC, które robiły OCR IRIS-em z DjVu lub nie robiły go wcale. Jak to znajdujecie?
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-03-26, 14:51   

relis napisał/a:
Kwestie techniczne to jedno. Niebawem będziemy mieli FR Corporate i uruchomimy lepszy OCR. Na pewno wydłuży to proces publikacji.

Dlatego właśnie w pierwszym poscie snułem marzenia o rozwiązaniu umożliwiającym całkowitą (no, prawie) automatyzację. Ale nie ma czego zazdrościć, my pewnie jeszcze długo pozostaniemy z manufakturą Document Express i namiastkowym OCR. Kiedy pełna i wydajna automatyzacja okaże się nieosiągalną mrzonką, choćby ze względów finansowych, przyjdziemy do was po nauki :-)

relis napisał/a:
Dopóki nie będzie on wystarczająco krótki i robiony automatem, myślimy nad kryteriami wyboru publikacji do tego lepszego OCR. Na pewno warto robić tak książki adresowe, wydawnictwa encyklopedyczne i słownikowe, oraz rzeczy faktograficzne (niektóre gazety, opracowania monograficzne, etc.).

W zasadzie chyba zgoda, choć etcetera też jest czasem warta zainteresowania ;-) . Decydują po prostu prawa rynku, czyli zainteresowanie czytelników? Czy jeszcze coś, co nie przyszło mi do głowy?

relis napisał/a:
Drugi problem to kwestia konwersji już opublikowanych rzeczy do postaci z lepszym OCR. (...) Myślę, że kwestia takiej "retrokonwersji" stanie się ważna dla wszystkich BC, które robiły OCR IRIS-em z DjVu lub nie robiły go wcale. Jak to znajdujecie?

Trudno nie przyznać racji. Bez przyzwoitego rozpoznania tekstu nasze szanse na ewolucyjny sukces znacznie maleją. Dobrze będzie, jeśli skończy się na "retrokonwersji" OCR (cały czas w końcu ważą się też losy używanego przez większość bc formatu DjVu, który jeśli porównać np. z PDF-em czy Flashem, jest marketingowo i technicznie dość zaniedbany).
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-03-26, 15:14   

sk napisał/a:
relis napisał/a:
Kwestie techniczne to jedno. Niebawem będziemy mieli FR Corporate i uruchomimy lepszy OCR. Na pewno wydłuży to proces publikacji.

Dlatego właśnie w pierwszym poscie snułem marzenia o rozwiązaniu umożliwiającym całkowitą (no, prawie) automatyzację. Ale nie ma czego zazdrościć, my pewnie jeszcze długo pozostaniemy z manufakturą Document Express i namiastkowym OCR. Kiedy pełna i wydajna automatyzacja okaże się nieosiągalną mrzonką, choćby ze względów finansowych, przyjdziemy do was po nauki :-)


Eee, a ja myślałem, że rzucimy receptę w publiczność i ktoś to podejmie, oskryptuje i potem nas nauczy :lol:
Jak już FR Corporate będzie, zobaczymy na ile się to da połączyć - zapewne za pomocą jakichś "katalogów komunikacyjnych". Enterprise zaczyna mielić jak mu się kończy zapisywać wsad, to można to traktować jako taki API-owy "process signal ".
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-04-01, 13:49   

Tu jest pierwsza nowa pozycja z FineReader'owym OCR - Kwartalnik Historyczny t. XV. Ponadto zrobiliśmy retrokonwersję i podmianę treści starszego tomu - IV. Trochę to trwa ale trafność rozpoznania jest blisko 100%.

Zauważyliśmy że FR radzi sobie także dobrze z drobną, czy wyblakłą czcionką, nawet przy 300 dpi. Zatem robienie w 600 pod FR to lekka perwersja.

Stwierdziliśmy też, że te pozycje z lepszym OCR warto jakoś widocznie zaznaczać, szczególnie pod katem wyszukiwania treści do przyszłej retrokonwersji. Na razie daliśmy "FR-OCR" w polu "Opis".
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-04-02, 07:06   

relis napisał/a:
Tu jest pierwsza nowa pozycja z FineReader'owym OCR - Kwartalnik Historyczny t. XV. Ponadto zrobiliśmy retrokonwersję i podmianę treści starszego tomu - IV. Trochę to trwa ale trafność rozpoznania jest blisko 100%.

Rzeczywiście, błędów jest bardzo mało, wyekstrahowany tekst da się po prostu czytać. I tak właśnie to powinno wyglądać!

Jak to wypada, jeśli chodzi o czas i nakład pracy w porównaniu ze "zwykłym" cyklem przetwarzania? Dwa razy dłużej? Więcej? Mniej?
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-04-02, 16:42   

Jak na razie trudno to oszacować, nawet specjalnie tym się nie zajmowaliśmy, bo procesy były robione na różnym sprzęcie i nierównolegle. Warstwa OCR w KH, to póki co handmade z wykorzystaniem FR wersji Home (bez wsadów). Rozpoznanie było robione na notebooku ;-) więc ok. 800-stronicowy dokument pochłaniał ok. 3 godz. czasu samego rozpoznania. Wydaje się też, że (przynajmniej) ta wersja ma ograniczenie do OCR dla 1000-str. dokumentu, bo taki też próbowałem i było przepełnienie bufora. Potem kolejny handmade pt. przeróbka PDF na DJVU, ekstrakcja XML i podklejanie go do normalnie skompresowanego DjVu - to już po kilkanaście minut na silnej maszynie - kolejne procesy uruchamiane na piechotę.

Niestety zakup FR Corporate się przeciągnął, bo udowodnienie z pomocą różnych papierów że jesteśmy EDU zajmuje czas.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-04-03, 08:47   

relis napisał/a:
Jak na razie trudno to oszacować, nawet specjalnie tym się nie zajmowaliśmy, bo procesy były robione na różnym sprzęcie i nierównolegle. Warstwa OCR w KH, to póki co handmade z wykorzystaniem FR wersji Home (bez wsadów). Rozpoznanie było robione na notebooku ;-) więc ok. 800-stronicowy dokument pochłaniał ok. 3 godz. czasu samego rozpoznania. Wydaje się też, że (przynajmniej) ta wersja ma ograniczenie do OCR dla 1000-str. dokumentu, bo taki też próbowałem i było przepełnienie bufora. Potem kolejny handmade pt. przeróbka PDF na DJVU, ekstrakcja XML i podklejanie go do normalnie skompresowanego DjVu - to już po kilkanaście minut na silnej maszynie - kolejne procesy uruchamiane na piechotę.

Dopiero po przeczytaniu tego postu uświadomiłem sobie jasno, jaki to ogrom roboty. Cała nadzieja, że da się tę procedurę zautomatyzować.

Nie jestem pewny, czy wszystko dobrze zrozumiałem, bo nie chce mi się wierzyć, że Enterprise na silnej maszynie potrzebuje na eksportowanie i import warstwy tekstowej w XML po kilkanaście minut... Sprawdziłem, jak szybko idzie to u mnie za pomocą narzędzi djvulibre. W przypadku tomu IV dostałem wyniki 43 sek. (ekstrakcja) i 3 min. 38 sek. (wklejanie).

Cytat:
sk@skok: test$ time djvutoxml _KH-IV.djvu out.xml

real 0m43.270s
user 0m29.738s
sys 0m10.489s

sk@skok: test$ time djvuxmlparser out.xml

real 3m37.056s
user 3m28.437s
sys 0m6.352s


Test na tomie XV zakończył się błędem w 24 sekundzie.

Cytat:
sk@skok: test$ time djvutoxml _Kh-XV.djvu out.xml
*** [1-10100] Text layer hierarchy is corrupt"
*** (DjVuText.cpp:290)
*** 'void DJVU::DjVuTXT::Zone::decode(const DJVU::GP<DJVU::ByteStream>&, int, const DJVU::DjVuTXT::Zone*, const DJVU::DjVuTXT::Zone*)'


real 0m24.159s
user 0m15.569s
sys 0m5.196s

Albo coś z tą hierarchią warstw rzeczywiście nie tak, albo moje narzędzie zbyt prymitywne.
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-04-03, 11:29   

No dobra, może trochę przesadziłem, ale jak napisałem na czasy nie zwracaliśmy specjalnej uwagi, poza tym robiliśmy na tej maszynie nie tylko to, no i w manufakturze czas płynie inaczej. Pomierzymy laboratoryjnie jak dojedzie w końcu FR Corporate.
Niemniej samo rozpoznanie jest dość długotrwałe i tu trzeba by szukać optymalizacji (unikając manufaktury na ile się da w innych częściach procedury). Nie mam żadnych doświadczeń z nim, ale jak poobserwowałem pracę FR to jest ona zależna oczywiście od wielkości dokumentu. Także od "czystości" tekstu wsadu, bo jak występują jakieś tabelki, elementy graficznie, FR "zastanawia się" chwilę, co z tym zrobić. Ale trzeba sprawdzić czy wielkość plików do rozpoznania ma wpływ - zapewne tak. (My robiliśmy ja na oryginalnych masterach.) Wówczas warto byłoby pomyśleć o wygenerowaniu z masterów jednobitowej, lekkiej wersji wsadu (obrazki można zniszczyć) dla OCR, która prawdopodobnie byłaby przetwarzana szybciej. I uzyskany stąd XML podklejać do prezentacyjnego DjVu, pozyskanego z masterów-masterów.

Procedura wyglądałaby orientacyjnie tak i zależałaby od tego co można jednocześnie robić:
1. Skanowanie i mastery
2. Fork na:
A. | B.
kompresja DjVu do prezentacji ->DjVu prezent. (Ent.) | rozpoznanie OCR-> PDF (FR)
czeka | konwersja PDF -> pośredni DjVu (Ent.)
czeka | ekstrakcja tesktu -> XML (Ent.)
3. Zlepienie efektów A. i B. (Ent.) -> DjVu z FR OCR.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
Ostatnio zmieniony przez relis 2009-04-03, 17:51, w całości zmieniany 1 raz  
 
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-04-03, 17:49   

Robienie wsadu bitonalnego pod OCR jednak nie ma sensu. OCR starej gazety (6 str.) trwa odpowiednio 7 min, (cz-b) i 8 min 50 sek (kolor). Różnica malutka, a wsad cz-b ma łącznie 14, 2 MB, a kolorowy 301 MB. OCR na kolorze jest trafniejszy, bo przy bitonalu zabrudzenia zostały zaliczone do czerni, zniekształcając rozpoznanie. Poprawiłem procedurę.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-04-07, 23:08   

Kolejna podmianka - Amtliches Adressbuch der Provinz Niederschlesien für Industrie, Handel, Gewerbe 1927. Trzeba było to rozbić na trzy części (po 500 stron) i sklejać na poziomie ostatecznego DjVu. Trafność też bardzo dobra, mimo niekiedy małej czcionki. Przy wyszukaniu fraz można zauważyć, że pozycja podklejonego tekstu nie zawsze odpowiada precyzyjnie pozycji obrazu słowa. Są drobne różnice. Związane to z lekkim przekrzywieniem obrazu mastera. Djvu kompresuje jak jest, natomiast FR przy rozpoznaniu prostuje obraz strony wg poziomej orientacji linii tekstu i tak zapisuje pozycje słów. Po sklejeniu więc widoczne są różnice.

Niestety denerwujące jest to, żeby płynnie i szybko szukać w rozbitym pliku, najlepiej ściągnąć go na swój komputer.
Czy może na którymś etapie M[?] rozwoju dLibry pojawi się skojarzenie zapytania z wyświetleniem podświetlonej frazy na właściwiej, otwartej stronie publikacji? 8-)
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-04-08, 11:33   

relis napisał/a:
Kolejna podmianka - Amtliches Adressbuch der Provinz Niederschlesien für Industrie, Handel, Gewerbe 1927. Trzeba było to rozbić na trzy części (po 500 stron) i sklejać na poziomie ostatecznego DjVu. Trafność też bardzo dobra, mimo niekiedy małej czcionki. Przy wyszukaniu fraz można zauważyć, że pozycja podklejonego tekstu nie zawsze odpowiada precyzyjnie pozycji obrazu słowa. Są drobne różnice. Związane to z lekkim przekrzywieniem obrazu mastera. Djvu kompresuje jak jest, natomiast FR przy rozpoznaniu prostuje obraz strony wg poziomej orientacji linii tekstu i tak zapisuje pozycje słów. Po sklejeniu więc widoczne są różnice.

Ten lekki zezik aż tak bardzo nie razi, ubytek urody kompensowany jest w dwójnasób przez dużo bogatszą warstwę tekstową. Niestety znowu przy wyszukiwaniu i ekstrahowaniu tekstu do XML pojawia się u mnie komunikat o błędzie w dokumencie:
 
     
Spiechu 


Wiek: 38
Dołączył: 16 Sie 2007
Posty: 27
Skąd: Biblioteka Śląska
Poziom: 3
HP: 0/44
 0%
MP: 21/21
 100%
EXP: 9/9
 100%
Wysłany: 2009-04-09, 08:21   

Trudno wyczuć dlaczego tak się dzieje. Enterprise wyraźnie ma problemy z publikacjami powyżej 1000 str. Podczas łączenia plików XML z djvu a następnie scalania w 1 djvu nie wyrzucało żadnych błędów.
 
 
     
Wyświetl posty z ostatnich:   
Ten temat jest zablokowany bez możliwości zmiany postów lub pisania odpowiedzi
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
Nie możesz załączać plików na tym forum
Możesz ściągać załączniki na tym forum
Dodaj temat do Ulubionych
Wersja do druku

Skocz do:  

Powered by phpBB modified by Przemo © 2003 phpBB Group
Biblioteka 2.0 : Forum społeczności czytelników i bibliotekarzy cyfrowych [Dokument elektroniczny] - Tryb dostępu http://forum.biblioteka20.pl
Korzystanie z portalu oznacza akceptację naszej polityki prywatności.
Strona wygenerowana w 0.13 sekundy. Zapytań do SQL: 10