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
Gazety lub inne czasopisma, czyli DjVu
Autor Wiadomość
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-01-29, 14:04   Gazety lub inne czasopisma, czyli DjVu

Niedawno spadła mi na głowę praca testowa konwersji skanów gazet i czasopism sprzed 100 lat do formatu DjVu. Zarówno EBIB jak i inne fora temat ten podejmowały ale, albo nie potrafię szukać, albo kwestia digitalizacji czasopism i gazet (trwale zszytych w roczniki) nie była podejmowana od technicznej strony samego problemu. Owszem, kierunki koniecznych działań takie jak sugestie dotyczące rozdzielczości, głębi barw skanów, życzenia co przydatności postaci cyfrowej pod kątem automatycznego rozpoznania OCR odnaleźć, to nie kłopot. Ale ...
Interesowała mnie kwestia weryfikacji jakości. Dla przykładu, mamy wyświetloną postać cyfrową jednej strony gazety. Skąd wiemy, że to co widzimy zostało zrobione najlepiej jak tylko można lub, że może zrobiono to fatalnie i digitalizację należy powtórzyć. Przecież nie można biegać co chwilę po półkach, szukać podejrzanego rocznika, w nim podejrzanej gazety, wreszcie podejrzanej strony i dopiero sprawdzić jakość konwersji. Problem ten polega na tym, że nawet - nazwijmy to - idealna digitalizacja strony o znacznym stopniu zniszczenia nie będzie prezentować się tak, by zaparło dech w piersiach. Jednak względem oryginału papierowego, z którego powstała będzie to majsterszyk. I na odwrót "zawalenie" pewnego etapu digitalizacji dla strony o jakości porównywalnej z jakością gazety dziś kupionej w kiosku, doprowadzi do postaci cyfrowej o jakości co najwyżej przeciętnej. Brnąc w temacie opracownia takiego sposobu digitalizacji, który uwzględni wszystko co tylko się da i będzie odpowiadać "modelowi dokumentacyjnemu" Relisa, zebrałem spostrzeżenia z przeprowadzonych prób i testów i poskładałem je w artykulik o digitalizacji czasopism. Opisana w artykule digitalizacja gazet i czasopism (na bazie skanów otrzymanych dzięki uprzejmości Biblioteki Jagiellońskiej) dotyczy rozdzielczości 300, 450 i 600 dpi dla skanów 24-bit color oraz 8-bit grayscale. Otrzymałem m.in. może nie do końca przewidziany przez Tomka i Relisa wynik. Najwięcej kłopotów z idealną segmentacją jest przy rozdzielczości plików Tiff - 600 dpi, a niemal "z ręki" idealną segmentację tekstu od tła prowadzi się dla rozdzielczości 300 dpi, co jest istotnym wnioskiem dla osób, które chcą się podjąć rozpoznania tekstu dla zdigitalizowanych stron (skanów bitonal uwaga ta nie dotyczy, bo ten tryb jest zaprzeczeniem modelu dokumentacyjnego i żadnej próby nie wykonałem). Różnic pomiędzy jakością DjVu 300, 450 i 600 wielkich nie ma (bo ustawiłem sobie wszędzie taką samą rozdzielczość dla obiektów w warstwie treści). Zatem poszukując digitalizacji, która ułatwi w przyszłości OCR może okazać się, że 600 dpi to "za dużo". Przy okazji, dla w/w kwestii weryfikacji jakości opracowałem sobie prywatną metodę "na łysego pana" (opisałem ją w artykule). Może inne spostrzeżenia lub wnioski (dotyczące różnych sposobów i kłopotów pojawiających się podczas digitalizacji dokumentów o niskiej gramaturze) osób zajmujących się takimi archiwizacjami rozwiną ten wątek w całkiem obszerny temat lub udzielą jednoznacznej odpowiedzi na pytanie "mikrofilmować czy digitalizować".
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
Ostatnio zmieniony przez Tomasz Kalota 2008-01-29, 18:47, 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: 2008-01-29, 22:43   

Grzegorz B. napisał/a:
Niedawno spadła mi na głowę praca testowa konwersji skanów gazet i czasopism sprzed 100 lat do formatu DjVu. Zarówno EBIB jak i inne fora temat ten podejmowały ale, albo nie potrafię szukać, albo kwestia digitalizacji czasopism i gazet (trwale zszytych w roczniki) nie była podejmowana od technicznej strony samego problemu. Owszem, kierunki koniecznych działań takie jak sugestie dotyczące rozdzielczości, głębi barw skanów, życzenia co przydatności postaci cyfrowej pod kątem automatycznego rozpoznania OCR odnaleźć [podkreślenie moje, tj. relisa], to nie kłopot. Ale ...
Interesowała mnie kwestia weryfikacji jakości. Dla przykładu, mamy wyświetloną postać cyfrową jednej strony gazety. Skąd wiemy, że to co widzimy zostało zrobione najlepiej jak tylko można lub, że może zrobiono to fatalnie i digitalizację należy powtórzyć. Przecież nie można biegać co chwilę po półkach, szukać podejrzanego rocznika, w nim podejrzanej gazety, wreszcie podejrzanej strony i dopiero sprawdzić jakość konwersji. Problem ten polega na tym, że nawet - nazwijmy to - idealna digitalizacja strony o znacznym stopniu zniszczenia nie będzie prezentować się tak, by zaparło dech w piersiach. Jednak względem oryginału papierowego, z którego powstała będzie to majstersztyk. I na odwrót "zawalenie" pewnego etapu digitalizacji dla strony o jakości porównywalnej z jakością gazety dziś kupionej w kiosku, doprowadzi do postaci cyfrowej o jakości co najwyżej przeciętnej.


Kwestia weryfikacji jakości jest faktycznie pomijana w naszych dyskusjach, jednakże dlatego, że jak dotąd traktujemy zasób cyfrowy dość utylitarnie - ma być coś widać, ma być małe, a jak da się trafnie zOCRować to już ekstra. Pytanie, jak to co widzę na ekranie ma się do oryginału, i czy skanerzysta lub grafik nie zepsuli czegoś lub przeciwnie, wirtuoz Photoshopa wycisnął z nędzy złoto - jest w pewnych sytuacjach na miejscu.
Sądzę, że najprostszą metodą pokazania jakość skanów jest wstrzelenie w nie jakiegoś reprograficznego "targetu", np. Kodaka. Prawdę mówiąc winna wystarczyć tzw. "szara karta", by móc wiele powiedzieć o jakość skanu. Inne paski mogą powiedzieć właściwie wszystko o dynamice matrycy zastosowanego skanera (mają oznaczone gęstości), tego jak wylicza końcówki kanałów, czy braku szumów. Taki "obraz kontrolny" można w końcu każdemu wyświetlić i może być także podstawą kalibracji monitora czy drukarki.
Podkreślam, iż mówię o jakości skanu (w co uwikłana jest jakość sprzętu, jego sterowniki, oświetlenie, pozycjonowanie oryginału), a nie obrazu przygotowywanego do jakichś celów, np. OCR.

Grzegorz B. napisał/a:

Brnąc w temacie opracownia takiego sposobu digitalizacji, który uwzględni wszystko co tylko się da i będzie odpowiadać "modelowi dokumentacyjnemu" Relisa, zebrałem spostrzeżenia z przeprowadzonych prób i testów i poskładałem je w artykulik o digitalizacji czasopism. Opisana w artykule digitalizacja gazet i czasopism (na bazie skanów otrzymanych dzięki uprzejmości Biblioteki Jagiellońskiej) dotyczy rozdzielczości 300, 450 i 600 dpi dla skanów 24-bit color oraz 8-bit grayscale. Otrzymałem m.in. może nie do końca przewidziany przez Tomka i Relisa wynik. Najwięcej kłopotów z idealną segmentacją jest przy rozdzielczości plików Tiff - 600 dpi, a niemal "z ręki" idealną segmentację tekstu od tła prowadzi się dla rozdzielczości 300 dpi, co jest istotnym wnioskiem dla osób, które chcą się podjąć rozpoznania tekstu dla zdigitalizowanych stron (skanów bitonal uwaga ta nie dotyczy, bo ten tryb jest zaprzeczeniem modelu dokumentacyjnego i żadnej próby nie wykonałem). Różnic pomiędzy jakością DjVu 300, 450 i 600 wielkich nie ma (bo ustawiłem sobie wszędzie taką samą rozdzielczość dla obiektów w warstwie treści). Zatem poszukując digitalizacji, która ułatwi w przyszłości OCR może okazać się, że 600 dpi to "za dużo". Przy okazji, dla w/w kwestii weryfikacji jakości opracowałem sobie prywatną metodę "na łysego pana" (opisałem ją w artykule). Może inne spostrzeżenia lub wnioski (dotyczące różnych sposobów i kłopotów pojawiających się podczas digitalizacji dokumentów o niskiej gramaturze) osób zajmujących się takimi archiwizacjami rozwiną ten wątek w całkiem obszerny temat lub udzielą jednoznacznej odpowiedzi na pytanie "mikrofilmować czy digitalizować".



Co do samego modelu dokumentacyjnego, to jego idea jest nieco inna - w skrócie - nie chodzi w nim o przygotowanie obrazków do dobrego OCR. Wręcz przeciwnie - zasób taki ma być bardzo nadmiarowy z punktu widzenia różnych zastosowań, po to m.in by mogły być rozmaite - a w zestawieniu do oryginału ma być 1:1. Jeśli oryginał jest wypłowiały, taki ma być na skanie w zasobie dokumentacyjnym. A jego wierność winna być udowodniona zawartym w obrazie "targetem".
Oczywiście także OCR docelowo wchodzi w grę, jednakże nic nie stoi na przeszkodzie by zasób dokumentacyjny, właśnie dzięki nadmiarowości dało się dalej obrabiać na różne sposoby, bowiem daje on wielkie pole manewru manipulowania bogatym obrazem np. w przypadku OCR właśnie poprzez dopasowanie rozdzielczości, skali tonalnej, "wyczyszczenia" z wtrętów, zafarbów, etc. Gdy mamy kolorowego TIFF-a wysokiej rozdzielczości możemy zrobić z nim bardzo dużo, 1-bitowy obrazek o rozdzielczości 100 dpi nie daje nam takiej szansy.

Twoje testy są świetne i popychają sprawę zasobów cyfrowych bardzo do przodu. Być może właśnie opracowałeś optymalną procedurę przygotowania zasobu pod OCR, która rozwiąże nam wiele problemów, a i w przyszłości, jeśli będą powstawać dokumentacyjne BC, będzie wskazane zaprojektowanie wsadowego procesu "profil OCR", który zasób masterów przetworzy do postaci surowca dla OCR.

Zastanawia mnie wyjaśnienie tej lepszej niższej rozdzielczości - choćby w kontekście tych dwóch obrazków. Oryginał ma słabo bite czcionki:

- 1200 dpi
i
- 300 dpi (x 4)

Tak na oko 1200 winno dawać trafniejszy OCR. Oba były skanowane w szarościach i przetworzone do obrazka 1-bitowego przy identycznym progu.
_________________
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
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-01-30, 21:54   

relis napisał/a:
Sądzę, że najprostszą metodą pokazania jakość skanów jest wstrzelenie w nie jakiegoś reprograficznego "targetu", np. Kodaka. Prawdę mówiąc winna wystarczyć tzw. "szara karta", by móc wiele powiedzieć o jakość skanu. Inne paski mogą powiedzieć właściwie wszystko o dynamice matrycy zastosowanego skanera (mają oznaczone gęstości), tego jak wylicza końcówki kanałów, czy braku szumów. Taki "obraz kontrolny" można w końcu każdemu wyświetlić i może być także podstawą kalibracji monitora czy drukarki.
Podkreślam, iż mówię o jakości skanu

Taka metoda stosowana jest chyba powszechnie. Rzeczywiście, położenie na skanowanej stronie dokumentu "wzorca" (czy to będą dziesiątki kwadracików z różnymi odcieniami szarości, czy to będą różnej wielkości litery - oceny ostrości, albo w/w szara karta) w prosty sposób udziela odpowiedzi na pytanie jak działa nasz tandem - skalibrowany skaner i odpowiednio ustawiony poziom wyświetlania obrazu na monitorze. Tyle, że to jest punkt kontrolny etapu znacznie wcześniejszego w procesie digitalizacji. Nazwijmy go "pomiędzy papierem a tiff'em". Może nieładna nazwa, ale coś tam wyjaśnia. Metoda, której szukałem, była mi potrzebna dla jakościowej kontroli etapu - nazwanego już przez analogię "pomiędzy tiff'em a DjVu". Ale skoro tak, to moglibyśmy powiedzieć, że metoda "szarej karty" i "łysego pana" pozwoli nam przejąć kontrolę nad dwoma etapami digitalizacji. A uciekając się już do próby określenia co też może oznaczać termin "pełna kontrola digitalizacji", dodajmy trzeci punkt kontrolny, który byłby odpowiedzialny za to, by w elektronicznej publikacji nigdy pojawiła się sytuacja typu "strona nr 1 jest sukcesorem strony nr 3, strony 15 brak w ogóle". Wtedy poniższa uwaga
relis napisał/a:
Kwestia weryfikacji jakości jest faktycznie pomijana w naszych dyskusjach

straci na aktualności. Zaproponowany sposób może zostać przyjęty lub zmodyfikowany, ale - co ważne - zaistnieje jako mechanizm odpowiadający nie na pytanie "czy już zrobione", ale "jak zrobione".
relis napisał/a:
wirtuoz Photoshopa wycisnął z nędzy złoto - jest w pewnych sytuacjach na miejscu.

Z moich doświadczeń wynika, że powyższa uwaga nie jest błaha. Pracujemy m.in. dla Biur Projektów i UM (np. digitalizacje materiałów do ogłaszanych przetargów, wbrew pozorom materiałów dość obszernych). Kwestie wiarygodności w tego typu dokumentach elektronicznych stanowią priorytet, zatem : brak jednokładności i transformacji kształtu (prosto można powiedzieć, "musi być 1:1, choćby brzydko"), zabawa z kolorami na rysunku technicznym (np. rozjaśnienie brzydkiej czerwieni w ładny ciemnopomarańczowy) spowodowała by pewnie moją dekapitację, gdyż dla czytającego rysunek każdy kolor ma ściśle określone znaczenie. Zatem te "w/w pewne sytuacje zamiany w złoto" mogą zapewne dotyczyć jedynie niektórych operacji spośród dostępnych w dobrych programach graficznych.
relis napisał/a:
Gdy mamy kolorowego TIFF-a wysokiej rozdzielczości możemy zrobić z nim bardzo dużo, 1-bitowy obrazek o rozdzielczości 100 dpi nie daje nam takiej szansy.

relis napisał/a:
wyjaśnienie tej lepszej niższej rozdzielczości - choćby w kontekście tych dwóch obrazków

To prawda, że z plikiem Tiff w wysokiej rozdzielczości robić można dosłownie cuda (abstrahując od tego, że pewnie znów Śpiechu przypomni o ile wzrośnie w MB zasób i jaką dodatkową ilość czasu to pochłonie :-D ). Kolorowy Tiff nie tylko udostępnia treść zawartą w dokumencie papierowym ale pokazuje również jakim ten dokument jest (lub był w momencie skanowania) naprawdę. Podobnie - jak wspomniałem w artykule - digitalizacja dokumentów papierowych dobrej jakości może być prowadzona poprzez pliki bitonalne i to w rozdzielczości jakiej sobie życzy osoba skanująca.
Natomiast kwestia "lepszej niższej rozdzielczości" dotyczy kilku aspektów samej konwersji i może opiszę to tak.
Po pierwsze, jeżeli "zawalimy" segmentację podczas konwersji i co druga sylaba będzie w warstwie tła, to rozdzielczość nawet 2400 dpi nie pomoże (w rozpoznaniu OCR dla pliku DjVu), bo nie będzie co rozpoznawać.
Po drugie - chyba to, o co zapytałeś - użytkownikom DocumentExpress będzie znacznie łatwiej uzyskać lepszą segmentację dla plików Tiff o niższej rozdzielczości (czyli 300 dpi lub 450 dpi) niż w przypadku konwersji plików Tiff o rozdzielczości wyższej (zatem 600 lub 1200 dpi).
Przez "łatwiej uzyskać" chciałem powiedzieć, że może wystarczyć jeden spośród standardowych profili konwersji (dostarczanych z programem DocumentExpress), a nawet gdyby nie wystarczył, to indywidualnie pisany profil dla 300 dpi nie wymaga tyle wysiłku co profil dla 600 dpi (a przesiedziałem przy profilach .... godzin). Zaś przez lepszą segmentację zawartości konwertowanego pliku Tiff rozumiem : umiejscowienie w warstwie treści strony DjVu dwóch składowych strony : wszystkich (w miarę możliwości) czytelnych liter i znaków, choćby każdej literze - jak pokazałeś na przykładach - brakowało około 5% jej kształtu oraz wszystkich nawet mało dostrzegalnych znaków i części znaków, które brakują (czyli te - nazwijmy to - 5%). To ten sam zamysł, co w Twojej metodzie. Skanowałeś w odcieniach szarości, aby "nie wylać dziecka z kąpielą", czyli nie zgubić części tekstu (lub wypłowiałych fragmentów liter) jak dzieje się to podczas skanowania bitonal dla "podniszczonych czasem" dokumentów (w moim artykule można to obejrzeć). Kolejnym krokiem Twojej metody jest być może lekkie podniesienie kontrastu i konwersja do bitonal. A ponieważ rozdzielczość była bardzo wysoka, pewnie umożliwiła "wyłapanie" wszystkich "wypłowiałości". U mnie brak już kolejnego kroku, ponieważ rozpoznanie OCR nie zależy od kolorystyki znaków w warstwie treści strony DjVu, zatem czy litera jest czarna, czy też czarna w 95% a pozostałe 5% ma np. beżowy lub brązowy ogonek dla rozpoznania nie jest ważne. Ważne, by litera była jak najbardziej kompletną.
Po trzecie - aby zachować jak najwyższą jakość dla liter w warstwie treści pliku DjVu, profile konwersji dokonały pewnej żonglerki dzielnikiem. Dla Tiff'a 300 dpi dzielnik wynosił 2, więc litery w DjVu powstały dla rozdzielczości 150 dpi, dla 450 - dzielnik wynosił 3, i znów litery w DjVu posiadały 150 dpi, jak łatwo się domyślić dla Tiff 600 ustawiłem 4 i 150 dpi po raz trzeci (w artykule ustawianie dzielnika przedstawiłem w tabeli). Tym mechanizmem mogłem dokonać oceny obiektywnej "jak wpływa rozdzielczość pliku wejściowego (czyli Tiff) na jakość pliku skonwertowanego (czyli DjVu), przy założeniu, że nie działamy starą metodą - duże wejście to i duże wyjście. Tu, jak pokazałem jest metoda różne wejście - określone i niezmienne wyjście.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
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: 2008-01-31, 00:24   

Grzegorz B. napisał/a:

Natomiast kwestia "lepszej niższej rozdzielczości" dotyczy kilku aspektów samej konwersji i może opiszę to tak.
Po pierwsze, jeżeli "zawalimy" segmentację podczas konwersji i co druga sylaba będzie w warstwie tła, to rozdzielczość nawet 2400 dpi nie pomoże (w rozpoznaniu OCR dla pliku DjVu), bo nie będzie co rozpoznawać.


Grzegorz B. napisał/a:
Zaś przez lepszą segmentację zawartości konwertowanego pliku Tiff rozumiem : umiejscowienie w warstwie treści strony DjVu dwóch składowych strony : wszystkich (w miarę możliwości) czytelnych liter i znaków, choćby każdej literze - jak pokazałeś na przykładach - brakowało około 5% jej kształtu oraz wszystkich nawet mało dostrzegalnych znaków i części znaków, które brakują (czyli te - nazwijmy to - 5%).


Grzegorz B. napisał/a:
Kolejnym krokiem Twojej metody jest być może lekkie podniesienie kontrastu i konwersja do bitonal. A ponieważ rozdzielczość była bardzo wysoka, pewnie umożliwiła "wyłapanie" wszystkich "wypłowiałości". U mnie brak już kolejnego kroku, ponieważ rozpoznanie OCR nie zależy od kolorystyki znaków w warstwie treści strony DjVu, zatem czy litera jest czarna, czy też czarna w 95% a pozostałe 5% ma np. beżowy lub brązowy ogonek dla rozpoznania nie jest ważne. Ważne, by litera była jak najbardziej kompletną.


To co zaprezentowałem wyżej opierało sie na paru założeniach - związanych z moim wyobrażeniem jak działa kompresor DjVu, który dokonuje dalej OCR. A wyobrażenie, wzięte z banalnej obserwacji jego pracy, jest takie:
1. Wciągniecie pliku wejściowego, np. TIFF
2. Segmentacja do warstwy tła i warstwy znaczącej (umownie "tekst") i kompresja - tu można operację zakończyć jak chcemy obrazek DjVu lub
3. Ewentualny OCR, gdzie następuje rozpoznanie w oparciu o warstwę "tekst" przy jednoczesnym pominięciu tła które jest i tak zmasakrowane.
4. Wygenerowanie rozpoznanego DjVu.

Mój eksperyment z rozdzielczościami tego samego fragmentu tekstu dotyczył symulacji działania w pkt. 2, tj. segmentatora kompresora DJVU, w kontekście (jak zrozumiałem) tezy o "wyższości", a przynajmniej "obojętności" niższej rozdzielczości. Otóż jego zadaniem jest w istocie wykonanie analogicznej operacji jak konwersja bitonalna - umownie "1" - zaliczenie do warstwy tekstu oraz umownie "0" - zaliczenie do warstwy tła. Oczywiście nieistotna jest tu kwestia kolorów i szarości obrazu - one też są kierowane do różnych warstw na takiej samej zasadzie. Można progiem wrażliwości segmentatora manipulować, podobnie jak w przypadku konwersji bitonalnej, jednakże zawsze możemy poruszać się tylko w zbiorze tych dwóch wartości i - konsekwentnie - każdy z punktów obrazu segmentator zaliczy albo do tła albo do tekstu.
Jeśli powyższa intuicja jest OK, to eksperyment ten pokazuje, że sama operacja segmentacji przeprowadzona na różnych rozdzielczościach skutkuje otrzymaniem różnych jakości obrazów - oczywiście niższa rozdzielczość wejściowa daje obraz obiektywnie niższej jakości - w tym więc konkretnie wypadku przejście do bitonalu działa jak segmentator DjVu w trakcie kompresji.
Zatem tu segmentator przy obu rozdzielczościach zaliczyłby do "tła" to co widać jako biel w bitonalu - co przy 300 dpi oznacza większe straty w warstwie "tekst".
Zatem segmentacją możemy zawalić na dwa sposoby - identycznie jak w bitonalu - poprzez zły próg segmentacji, jak i poprzez zbyt niską rozdzielczość segmentowanego pliku wejściowego.

Generalnie może w tym nic groźnego nie ma, bo względy wielkości, "gotowości" profilu, stratności przy zapewnieniu czytelności są do istotne przy masowej obróbce. A w efekcie i tak się dostaje obrazki niewiele różniące się jakością, co można ocenić przy dużych powiększeniach. Trzeba też pamiętać, cele prezentacyjne (oglądanie) rządzą się zasadą perspektywy i odległość z jaką czytamy tekst zależy od jego wielkości.

Grzegorz B. napisał/a:
Przez "łatwiej uzyskać" chciałem powiedzieć, że może wystarczyć jeden spośród standardowych profili konwersji (dostarczanych z programem DocumentExpress), a nawet gdyby nie wystarczył, to indywidualnie pisany profil dla 300 dpi nie wymaga tyle wysiłku co profil dla 600 dpi (a przesiedziałem przy profilach .... godzin).

Tak zapewne jest i jest to chyba związane ze statystyką użytkowania "firmowego" profilu. Zapewne klienci DjVu zazwyczaj skanują do 300 dpi, więc dostali bardziej dopracowany profil.
Grzegorz B. napisał/a:
Tym mechanizmem mogłem dokonać oceny obiektywnej "jak wpływa rozdzielczość pliku wejściowego (czyli Tiff) na jakość pliku skonwertowanego (czyli DjVu), przy założeniu, że nie działamy starą metodą - duże wejście to i duże wyjście. Tu, jak pokazałem jest metoda różne wejście - określone i niezmienne wyjście.

Przy założeniu że "jakość skonwertowanego pliku" oceniamy poprzez wygodę wizualnego użytkowania pliku przy normalnej lekturze gazety na ekranie, czy wydruku. Istotnie w obu wypadkach jest ona praktycznie identyczna.

Z przykładów z Twojego artykułu - 300 dpi:

i 600 dpi


Różnice są widoczne, lecz wychodzą dopiero przy szczegółowej sekcji bitów. ;-)
_________________
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
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-01-31, 07:57   

Również szukałem odpowiedzi na Twoje pytanie
relis napisał/a:
jak działa kompresor DjVu, który dokonuje dalej OCR.

Producent się tym nie chwali (zresztą niby po co), więc aby się tego dowiedzieć wykonałem inny test.
1. w folderze umieściłem kilka tiff'ów (5÷6)
2. Uruchomiłem konwersję pod Enterprise najprościej jak się da (profil scanned-300, zrób jeden plik, start job). Powstał plik DjVu bez OCR.
3. Obok okienka Enterprise'a otworzyłem okienko eksploratora z folderem gdzie były tiffy i 1-szy testowy plik DjVu.
4. W oknie Enterprise dodałem dodałem tylko opcję "zrób OCR-Polish" (te same tiffy), zmieniłem nazwę pracy i start job. Gdy w eksploratorze pojawiła się ikona pliku djvu a w okienku Enterprise'a napis "Starting OCR" szybko kliknąłem ikonkę powstałego pliku DjVu po czym Ctrl-C, Ctrl-V. Stworzyłem tym samym plik DjVu "Kopia Jakaś_nazwa.djvu". Po paru sekundach, gdy Enterprise skończył, rozmiar pliku "Jakaś_nazwa.djvu" wzrósł (oczywiście o rozmiar powstałej warstwy tekstowej).
5. Porównałem Plik z punktu 2 z plikiem "Kopia Jakaś_nazwa.djvu" (Pkt 4). Oba były identyczne.
6. Plik djvu z 2-ego punktu wskazałem w Enterprise jako plik do przetworzenia i zaznaczyłem jedynie "zrób OCR-Polish". Gdy powstał plik bogatszy o warstwę OCR, porównałem go z plikiem "Jakaś_nazwa.djvu" (pkt 4). Oba były identyczne.
Zatem uważam, że w Twoim algorytmie punkt 3 i 4 należy wzajemnie zamienić miejscami.
Enkoder tworzy najpierw kompletny plik djvu (warstwy treści, warstwy tła, plik słowników). OCR (kilku metodami, w zależności od źródła), watermark czy miniaturki tworzone są dla gotowego djvu.

relis napisał/a:
Zatem segmentacją możemy zawalić na dwa sposoby - identycznie jak w bitonalu - poprzez zły próg segmentacji, jak i poprzez zbyt niską rozdzielczość segmentowanego pliku wejściowego.

Tu pełna zgoda, choć mogę dodać, że bezmyślnie wybrany profil robi podobne spustoszenia jak w/w 2 sposoby (jest jeszcze kilka innych parametrów w profilu, które dobrane niewłaściwie powodują efekt, o którym piszesz - zawalenie).

relis napisał/a:
tezy o "wyższości", a przynajmniej "obojętności" niższej rozdzielczości.


Sądzę, że nie wziąłeś pod uwagę jednej kwestii. W przeciętnej książce "duża" litera może się trafić raz lub dwa na jeden rozdział jej treści. Zatem bez obaw można założyć, że : skanujemy jedynie w 600 dpi lub 1200 dpi, bo skan będzie jednocześnie najwyższych lotów a enkoder umieści w warstwie treści 100% liter bo są "małymi" obiektami rzędu 6÷10 punktów drukarskich (no, może nie "zauważy" tych paru dużych liter, czyli odnajdziemy je w warstwie tła). Z kolei silnik OCR rozpozna tekst wydajnie i osiągniemy pożądany rezultat. Problem, na który się natknąłem przy gazetach, nie dotyczył absolutnie "małych" liter na stronach gazety (nie mówimy póty co w ogóle o jakości). W przeciętnej stronie gazety "duże" litery tytułów i śródtytułów trafiają się co 10 linijek i to w każdej szpalcie.
Im większa była rozdzielczość konwertowanego pliku Tiff (i tym samym jakość jego zawartości) tym łatwiej enkoder (a jak nie on, to włączający się po nim silnik OCR) podejmował decyzję, że to co analizuje nie jest literą tylko "obszarem" wypełnionym jednolicie kolorem (bo duże) i przenosił mi "dużą" literę do warstwy tła. Tym samym dekompletował mi warstwę treści uważając, że świetnie zrobił, bo w warstwie tła ta litera-obszar zajmie może 40 bajtów mniej a ja powinienem być wdzięczny. Dlatego tak precyzowałem profile, by umieściły w warstwie treści "małe" litery (i tu praca szła płynnie) oraz "duże" litery (tu zaś, im rozdzielczość tiff'a była wyższa, tym ideał segmentacji - ilościowej względem liter na stronie - coraz bardziej odległy). Dopiero wtedy, gdy ułożyłem profile jak najlepiej, uzupełniając je o czułość na wypłowiałe fragmenty słów i skonwertowałem tiffy, mogłem się zająć jakością liter umieszczonych w warstwach treści. Ponieważ we wszystkich DjVu (300, 450 i 600 dpi) warstwy treści kazałem utworzyć identycznie (dla 150), ocena jakości, którą pokazałeś na 2 fragmentach jest obiektywna i łatwa była do przewidzenia.
relis napisał/a:
Różnice są widoczne, lecz wychodzą dopiero przy szczegółowej sekcji bitów

Jakość liter musi być i jest nieco lepsza, gdy konwertujemy plik tiff o wyższej rozdzielczości. Ale co z tego, że użytkownicy DocumentExpress rozpoczną masowe skanowanie dla np. 1200 dpi, skoro 80% liter "dużych" umieszczonych będzie w warstwie tła? Owszem, artykuliki w każdej szpalcie będą super jakości i zarazem umieszczone w warstwie treści, ale nie będzie tytułów tych artykulików, lub pozostaną po nich 2-3 litery (w warstwie treści). Dlatego sygnalizowałem, że 600 dpi może być za dużą wartością mając głównie na uwadze kompletność warstwy treści (czy też w miarę możliwości umieszczenie wszystkich liter w tej warstwie).
Podsumowując :
1. Niższa rozdzielczość Tiffa względem wyższej ma tą przewagę, że o wiele prościej jest podczas konwersji przenieść do warstwy treści wszystkie litery konwertowanej strony.
2. Wyższa rozdzielczość Tiffa względem niższej ma tą przewagę, że przeniesione podczas konwersji litery do warstwy treści mają wyższą jakość.
3. Być może "panaceum" na taką sytuację w przypadku czasopism, a zatem możliwie największa ilość liter różnych wielkości i grubości o możliwie najwyższej jakości tkwi w wypróbowaniu rozdzielczości 450 dpi.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
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: 2008-01-31, 15:26   

Grzegorz B. napisał/a:
pewnie znów Śpiechu przypomni o ile wzrośnie w MB zasób i jaką dodatkową ilość czasu to pochłonie

Nie jestem aż taki straszny :-)

Powiem tak: nie przekona się mnie po co robić brzydką, szarą (żółtą) książkę w kolorze, w której jest tylko tekst na białym tle. Możemy w SPD robić masowo kolor tylko wtedy, gdy dostanę takie polecenie służbowe :-P
Obecnie stosujemy taką metodę, że mapy i fotografie robimy w kolorze (mapy w 600dpi). Efekt (na stronie 2) można zobaczyć np. tutaj. Mapę można swobodnie powiększać ile się chce. Wszystko jest dokładne.
Jeżeli np. czasopismo jest naładowane fotografiami (tak jak "Oberschlesien im Bild") - to całość w kolorze.

Myślę, że to rozsądne rozwiązanie.
 
 
     
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: 2008-01-31, 17:10   

Grzegorz B. napisał/a:

Sądzę, że nie wziąłeś pod uwagę jednej kwestii. W przeciętnej książce "duża" litera może się trafić raz lub dwa na jeden rozdział jej treści. Zatem bez obaw można założyć, że : skanujemy jedynie w 600 dpi lub 1200 dpi, bo skan będzie jednocześnie najwyższych lotów a enkoder umieści w warstwie treści 100% liter bo są "małymi" obiektami rzędu 6÷10 punktów drukarskich (no, może nie "zauważy" tych paru dużych liter, czyli odnajdziemy je w warstwie tła). Z kolei silnik OCR rozpozna tekst wydajnie i osiągniemy pożądany rezultat. Problem, na który się natknąłem przy gazetach, nie dotyczył absolutnie "małych" liter na stronach gazety (nie mówimy póty co w ogóle o jakości). W przeciętnej stronie gazety "duże" litery tytułów i śródtytułów trafiają się co 10 linijek i to w każdej szpalcie.
Im większa była rozdzielczość konwertowanego pliku Tiff (i tym samym jakość jego zawartości) tym łatwiej enkoder (a jak nie on, to włączający się po nim silnik OCR) podejmował decyzję, że to co analizuje nie jest literą tylko "obszarem" wypełnionym jednolicie kolorem (bo duże) i przenosił mi "dużą" literę do warstwy tła. Tym samym dekompletował mi warstwę treści uważając, że świetnie zrobił, bo w warstwie tła ta litera-obszar zajmie może 40 bajtów mniej a ja powinienem być wdzięczny.


Teraz chciałbym tylko dorecyzować jedną rzecz - która instancja enkodera za co odpowiada.
Kompresja DjVu z OCR ma dwa zasadnicze etapy: segmentację oraz OCR.
1. Segmentator działa na zasadzie podziału obrazu na "tło" i "treść" i podział ten zależy od progu stanowiącego liczbę określającą "wrażliwość" segmentatora.
2. Jeśli tak jest, to segmentator nie ma zdolności rozpoznawania wielkości liter i zaliczania ich z tego względu do tła lub treści, bowiem operuje on tylko na bitmapach. Jedyne co robi to zalicza, bez względu na wielkość plam - pewne do tła, pewne do treści.
3. Jeśli tak, to "odpowiedzialnym" za nierozpoznanie dużych napisów jest motor OCR, pomimo, że znajdują się one w warstwie treści, w której umieścił je segmentator.
4. Nierozpoznanie dużych napisów przez OCR spowodowane jest zapewne firmowym ograniczeniem do plam o określonej wielkości (wysokości, szerokośći? - to pewnie można sprawdzić którą wielkość jeszcze chwyta).
5. Wniosek: efekt pracy segmentatora jest zależny m.in. od rozdzielczości. W przypadku skanowania z wysoką rozdzielczością spora litera oryginału zostaje zapisana w "plamie" o wielkiej ilości punktów znaczących i umieszczona w warstwie treści. Nierozpoznanie tej wielkiej litery następuje nie ze względu na przesunięcie jej do tła przez segmentator, lecz przez wielkościowe ograniczenie znaków "znaczących" dla OCR i jest zależne od motoru OCR.

W celu zweryfikowania tej teorii (i doprecyzowania sprawy) zrobiłem eksperyment.
1. Utworzyłem dwa identyczne czarno-białe TIFFy z dwoma napisami: "ala" o wysokości 10 pkt. oraz "ala" o wysokości 200 pkt. Wąska tonalność miała zapewnić bezsprzeczne zaliczenie napisów przez segmentator do określonych warstw.
2. Wrzuciłem oba pliki do profilów "OCR-polish" i "bez OCR".
3. Po konwersji wyświetliłem oba pliki w warstwach tła i treści oraz (w pliku poddanym OCR) dokonałem wyszukania frazy "ala".

Wyniki:

Plik bez OCR: oba napisy zostały zaliczone do warstwy treści i żaden z nich nie został umieszczony w tle. Zatem nie jest tak, że nadmierna wielkość liter powoduje zaliczenie do warstwy tła.

Plik z OCR: oba napisy zostały zaliczone do warstwy treści,

lecz tylko mały napis "ala" został rozpoznany, zaś ponowienie wyszukiwania daje komunikat "nie znaleziono" - czyli duży napis nie został poddany rozpoznaniu, mimo, że znajduje się w warstwie "treść". Taki sam efekt (zaznaczenie tylko małego opisu) daje użycie narzędzia tekstowego.
_________________
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
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-01-31, 19:57   

Spiechu napisał/a:
nie przekona się mnie po co robić brzydką, szarą (żółtą) książkę w kolorze, w której jest tylko tekst na białym tle

Może nawet kiedyś sam się przekonasz, gdy będziesz mógł myszką kliknąć na dwie postaci - bitonalną i kolorową - dla prawdziwego skarbu czy też zbioru specjalnego, niech to będzie rękopis z XIII lub XIV w. a może jakieś unikatowe wydanie np. Mickiewicza. Pracowałem kiedyś nad rękopisem "Codex..." z XIV w. i było w nim 655 żółtych kartek oraz brzydka okładka, ale ten urok koloru .... nie, no tu nigdy mnie nie przekonasz. Zgodzę się natomiast, że zbiór zadań Grigorija Bermana z analizy matematycznej potraktujesz tak : wybierasz zgrabny bitonal, wyważoną rozdzielczość - i będzie na pewno super. Tylko nie wrzucaj na jedną półkę jakościową wszystkich zbiorów. Poza tym szaraczek nigdy nie zobaczy jak skarby wyglądają naprawdę, bo przed jego oczami (i rękoma) są schowane. Zatem kolorowy świat internetu to dla szaraczka (takiego jak ja) jedyna możliwość, by zobaczyć coś i pięknego i interesującego.

relis napisał/a:
Teraz chciałbym tylko dorecyzować jedną rzecz - która instancja enkodera za co odpowiada.
Kompresja DjVu z OCR ma dwa zasadnicze etapy: segmentację oraz OCR.
1. Segmentator działa na zasadzie podziału obrazu na "tło" i "treść" i podział ten zależy od progu stanowiącego liczbę określającą "wrażliwość" segmentatora.

Chyba stąpamy po tych samych śladach, lub też napotykamy na te same pytania do których brak w literaturze odpowiedzi. Kompresja DjVu - wg mnie - posiada więcej etapów ale na pewno żadnym z nich nie jest OCR. Dlaczego tak sądzę ? Gdy wydajemy polecenie "Enkoder, zrób mi plik DjVu" rozpoczyna się praca nazwijmy to analizatora powierzchni strony konwertowanego pliku. Strona dzielona jest jak szachownica na "podsekcje", w każdej z nich analizator dokonuje oceny jaki by tu algorytm najlepiej zastosować, wybiera 2, może 3 kandydatów, po czym ogląda jakie życzenia postawił użytkownik (czyli jakim parametrom w profilu jakie przypisano wartości). Z tych dwóch źródeł danych wyłoniony zostaje algorytm kompresji zwycięzca. Prawdopodobnie w tym momencie rozpoczyna się etap segmentacji (i tak dla każdej podsekcji), po czym aktywuje się etap zapisu czy też wykreowania poskładanych w całość warstw treści i warstw tła i powstaje plik DjVu z nienaruszalnymi już co do zawartości fragmentami - producent nazywa je chunks. I tak powstaje chunk DJVM lub DJVU (nagłówek), chunk INFO (geometria, rozdzielczość, gamma, obroty), chunk FG44 (warstwa treści), 1 do kilku płatów (a zarazem kilku chunk'ów) BG44 (łącznie warstwa tła) i to jest święte niczym read-only. Nie wiem gdzie aktywuje się etap inteligencji DjVu (falki, ...) ale wtedy powstaje np. słownik kształtów zapamiętanych z analizowanych podczas konwersji podsekcji, więc po rozpoznaniu nie jest to już jak piszesz "...bowiem operuje tylko na bitmapach..." lecz operuje także na rozpoznanych obiektach o pewnych tam kształtach a nie tylko matrycy bitmapowej zapełnionej 1 i 0.
A teraz OCR. Przy okazji - nie było go w ogóle do wersji 4.1, a pliku DjVu były.
Tu wiem na pewno, że do gotowego pliku DjVu powstaje plik tekstowy zawierający koordynaty słów (ściśle zależne od rozdzielczości warstwy treści) oraz same słowa. Następnie aplikacja kompresuje ten plik algorytmem Burrows-Wheeler'a i zapisuje (dokleja) w pliku DjVu jako chunk Txtz (compressed text). Jeżeli użytkownik potrafi (producent to wycofał, ale mogę Ci coś podesłać, bo to czasem robię) to ten plik "przylepić" mozna do DjVu bez kompresji jako chunk Txta (plain text). Tylko nie wiem po co to robić.
Analizator potrafi jeszcze ocenić, czy coś jest obszarem - dla niego jednorodnym - i poleci algorytmowi wrzucić to do treści zapamiętując nr koloru wypełnienia wewnątrz obrzeży (Twoja ala), czy coś jest jakimś tam obszarem (np. kleks) i wrzuci to do tła, czy też sam nie wie no co napotkał i wtedy przydaje się pomoc użytkownika w postaci parametru treshold (obiekty niejednoznacznie rozpoznane - ambiguous objects)

relis napisał/a:
Nierozpoznanie dużych napisów przez OCR spowodowane jest zapewne firmowym ograniczeniem do plam o określonej wielkości (wysokości, szerokośći?
relis napisał/a:
tylko mały napis "ala" został rozpoznany, zaś ponowienie wyszukiwania daje komunikat "nie znaleziono" - czyli duży napis nie został poddany rozpoznaniu, mimo, że znajduje się w warstwie "treść". Taki sam efekt (zaznaczenie tylko małego opisu) daje użycie narzędzia tekstowego.
Oczywiście, tak właśnie jest.

relis napisał/a:
Wniosek: efekt pracy segmentatora jest zależny m.in. od rozdzielczości
Oczywiście, tak właśnie jest.

relis napisał/a:
W przypadku skanowania z wysoką rozdzielczością spora litera oryginału zostaje zapisana w "plamie" o wielkiej ilości punktów znaczących i umieszczona w warstwie treści.
I tak i nie. Twój wywód oparty o bitmapę jest jak najbardziej słuszny. Jednak gdy rozszerzysz go o ambiguous objects, znajdziesz odpowiedź dlaczego część liter ogromniastych relatywnie względem innych liter, jest w treści a część w tle.

relis napisał/a:
Nierozpoznanie tej wielkiej litery następuje nie ze względu na przesunięcie jej do tła przez segmentator, lecz przez wielkościowe ograniczenie znaków "znaczących" dla OCR i jest zależne od motoru OCR.
Gdy litera trafi do tła, dla silnika OCR po prostu nie istnieje. Ograniczenie wielkościowe znaków - oczywiście, tak właśnie jest.

relis napisał/a:
Zatem nie jest tak, że nadmierna wielkość liter powoduje zaliczenie do warstwy tła.
Oczywiście, gdy analizujesz wygenerowany elektronicznie plik elektroniczny lub skan "ślicznego" wydruku z laserówki i nie, gdy analizujesz digitalizowany obraz (drogą skanowania) gazety powstałej 100 lat temu.

Pozwolę sobie również wkleić obrazki, które chyba bardzo fajnie pokażą jak wzbogaca się "tło", gdy rozdzielczość Tiffa ucieka z 300 przez 450 do 600 dpi. oczywiście jest to jednoznaczne z zubażaniem warstwy treści o grube-duże litery.

_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-02-01, 07:21   

relis napisał/a:
Zastanawia mnie wyjaśnienie tej lepszej niższej rozdzielczości

Doszedłem do wniosku, że pytania, które postawiłeś mogą nurtować innych czytelników artykułu, albo po prostu nie wszystko w artykule opisałem do końca. Dlatego uaktualniłem w artykule wnioski a przede wszystkim dopisałem ocenę konwersji "Głosu Narodu", która była pracą prostszą od "Ilustrowanego Kuryera Codziennego". Wstępnie nie chciałem "zbyt mieszać" dwoma różnymi ocenami i chociaż z grubsza ich uzasadnieniem. Problem digitalizacji uważam i tak za trudny oraz poważny, zwłaszcza dla "nie-informatyka" lub "nie-matematyka", więc język liczb i sformułowań informatycznych może nie być dla każdego komunikatywny. Chociażby opis zdarzeń (myślę, że zrodził niedomówienie) "precyzja segmentacji". Przewiduję, że odczytałeś to jako przede wszystkim jakość liter osadzonych w warstwie treści, ja zaś chciałem opisać ilościowe przeniesienie liter (co do jednej) z obrazu tiff do warstwy treści w DjVu. Może teraz artykuł jest bardziej kompletnym i jasnym.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
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: 2008-02-01, 11:19   

Grzegorz B. napisał/a:
relis napisał/a:
Zastanawia mnie wyjaśnienie tej lepszej niższej rozdzielczości

Doszedłem do wniosku, że pytania, które postawiłeś mogą nurtować innych czytelników artykułu, albo po prostu nie wszystko w artykule opisałem do końca. Dlatego uaktualniłem w artykule wnioski a przede wszystkim dopisałem ocenę konwersji "Głosu Narodu", która była pracą prostszą od "Ilustrowanego Kuryera Codziennego". Wstępnie nie chciałem "zbyt mieszać" dwoma różnymi ocenami i chociaż z grubsza ich uzasadnieniem. Problem digitalizacji uważam i tak za trudny oraz poważny, zwłaszcza dla "nie-informatyka" lub "nie-matematyka", więc język liczb i sformułowań informatycznych może nie być dla każdego komunikatywny. Chociażby opis zdarzeń (myślę, że zrodził niedomówienie) "precyzja segmentacji". Przewiduję, że odczytałeś to jako przede wszystkim jakość liter osadzonych w warstwie treści, ja zaś chciałem opisać ilościowe przeniesienie liter (co do jednej) z obrazu tiff do warstwy treści w DjVu. Może teraz artykuł jest bardziej kompletnym i jasnym.


Wbrew pozorom - opisywanie i robienie BC od środka to nauka ścisła i inżynieria ;-) i niestety trzeba tu odróżniać popularyzację od (maniakalnego? ;-) ) dociekania dlaczego dlaczego coś jest takie a nie inne.
Oczywiście - nie zakładałem "inteligencji" segmentatora, poza zdolnością do progowego podziału na warstwy całego obrazu. Wygląda na to że pracuje on inaczej, lecz sądzę że można kontynuować doświadczenie dalej. Ów "Głos Narodu" i jego niknące duże litery sprawę komplikuje. Niemniej można by zbadać (idąc tropem gęstości jako głównej determinanty zaliczania do warstwy tekstowej) jak i czy w ogóle zastosowana rozdzielczość wpływa na średnią gęstość obrazu liter. Jeśli to nic nie da - być może wchodzi w grę proporcja gęstości liter do gęstości tła - co dałoby się sprawdzić kontrastując obraz i dokonując kompresji. Najbardziej skomplikowany byłby przypadek przypadek, jeśliby segmentator po wstępnym wyróżnieniu elementów obrazu ważył probabilistycznie ich wzajemne relacje ze względu na wielkość plam, gęstość, proporcje wielkości i /lub gęstości do innych obiektów (np. drobnego tekstu) i dopiero decydował o metodzie zaliczania do warstw. To z kolei można sprawdzić ordynarnie wycinając napis "jak przeżyła Anglia" (a więc pozbawiając go kontekstu odniesienia do innych elementów obrazu) i kompresując w tych samych warunkach na różnych rozdzielczościach - ciekawe czy efekt byłby taki sam.

Moim zdaniem warto iść w tym kierunku by znaleźć owe determinanty i "zrozumieć" działanie kompresora, np. tak by grafik przygotowujący skany do kompresji za pomocą weryfikacji kilku parametrów mógł dobrać profile kompresji i biorąc pod uwagę OCR. Inaczej jesteśmy skazani na ciągłe powtarzanie tych samych eksperymentów przed rozpoczęciem kompresji jakichś oryginałów, co w laboratorium na małych próbkach jest do zrobienia, lecz utrudnia sprawę masowej digitalizacji.

Niestety to jest zadanie dla jakichś zespołów badawczych, wiem, że Politechnika Śląska już parę lat temu rozpracowywała ten format, i to co pokazywali świadczyło, że w dużej mierze odtworzyli algorytm działania segmentatora. Poza tym zajmowali się metodą wstępnej redukcji szumów obrazów, co w efekcie dawało wyjątkowo dobre pliki wejściowe dla kompresora DjVu.
_________________
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
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-02-02, 22:00   

relis napisał/a:
kompresując w tych samych warunkach na różnych rozdzielczościach - ciekawe czy efekt byłby taki sam.

Nie wiem, ale mogę wskazać podobny naturą przykład tego, co już kilkakrotnie zaobserwowałem. Mam na myśli kadrowanie. Otóż, gdy zostanie napisany i sprawdzony profil dla publikacji, w której na każdej stronie widać "fragment" podkładu, na którym leżała skanowana publikacja, wykonamy konwersję tiff'ów, po czym zdecydujemy, że wypada je kadrować i ponownie "skadrowane" tiffy poddamy konwersji tym samym profilem, kilka stron skonwertowanych będzie inaczej (oczywiście pomijając w ocenie obcięte podczas kadrowania obrzeża). W IKC na 14 stron taka sytuacja (bardzo łatwo widoczna) zdarzyła się 1 raz - na drugiej stronie. Ilekroć szukałem odpowiedzi, dochodziłem do wniosku, że podział obszaru strony "niczym szachownica" (pisałem o tym poprzednio), tuż przed segmentacją powoduje to, że zmiana rozmiaru tiff'a jest przyczyną "ulokowania" fragmentu strony z obiektem zachowującym się odmiennie w innym segmencie, zaś włączający się później algorytm segmentacji dokonuje odmiennej klasyfikacji obiektu, który jest już w "innym" sąsiedztwie. Czy mój wniosek jest błędny czy trafny, nie potrafię wykazać. Może akurat ograniczenie ilości kolorów analizowanej strony (odpadł po kadrowaniu podkład od skanera) jest przyczyną bardziej precyzyjnej segmentacji. Może ...
Przyczyny takiego zachowania się enkodera nie szukam. Jedynie wiem z doświadczenia, w których sytuacjach taka sytuacja może się pojawić i wiem czego szukać pisząc profil lub przygotowując kolekcję plików tiff. Poniżej : IKC 300 dpi konwersja podstawowa, obok IKC 300 dpi konwersja kadrowanego tuiif'a (oba dostępne w artykule).


Zauważ, że mówimy o tej samej rozdzielczości, o tym samym fragmencie tiff'a. Gdyby kadrować jpg'i, można snuć różne wnioski (np. o jego kompresji stratnej). A w przypadku tiff'a - no powinno być tak samo, a nie jest.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
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: 2008-02-02, 23:08   

Grzegorz B. napisał/a:
Ilekroć szukałem odpowiedzi, dochodziłem do wniosku, że podział obszaru strony "niczym szachownica" (pisałem o tym poprzednio), tuż przed segmentacją powoduje to, że zmiana rozmiaru tiff'a jest przyczyną "ulokowania" fragmentu strony z obiektem zachowującym się odmiennie w innym segmencie, zaś włączający się później algorytm segmentacji dokonuje odmiennej klasyfikacji obiektu, który jest już w "innym" sąsiedztwie. Czy mój wniosek jest błędny czy trafny, nie potrafię wykazać. Może akurat ograniczenie ilości kolorów analizowanej strony (odpadł po kadrowaniu podkład od skanera) jest przyczyną bardziej precyzyjnej segmentacji. Może ...
Przyczyny takiego zachowania się enkodera nie szukam. [...]
Zauważ, że mówimy o tej samej rozdzielczości, o tym samym fragmencie tiff'a. Gdyby kadrować jpg'i, można snuć różne wnioski (np. o jego kompresji stratnej). A w przypadku tiff'a - no powinno być tak samo, a nie jest.


Jeśłi dobrze rozumiem ten przykład, to patrząc na to w kategoriach "co się zmieniło" można powiedzieć, że zmieniła się (prócz wielkości TIFFa po skadrowaniu - jak czytam na tym polegała operacja) średnia gęstość obrazu oraz stał sie on bardziej jednorodny tonalnie, tj. wyleciała nie licząc drobnego marginesu cała ta żółta plama z prawej strony lewego obrazka.
Skoro w tym wypadku czynnik rozdzielczości został zneutralizowany, to można gdybać, iż segmentator analizując obrazek pierwszy uznał go za przypadek obrazu niejednorodnego, tj. takiego, który zawiera, prócz statystycznie dużej przewagi drobnego tekstu jakieś dodatkowe obiekty niewarte zaliczenia do treści. I w obecności tegoż pionowego sporego obszaru zażółcenia, zaliczył równie okazały obiekt (wielkie litery) do tła. Na drugim, bardziej "czystym" (niższa gęstość obrazu i brak "gęstości pośrednich" sporych plam) zaliczył ten napis do warstwy tekstowej.
Wydaje mi się że tu gdzieś leży pies. Podobne znaczenie mogą mieć różne inne "fabryczne" tryby kompresji typu "manuscripts", "maps", które mogą ważyć te czynniki, przyjmując charakterystyki takich obiektów, etc.

Mam też pomysł na to zaliczanie dużych napisów do tła w związku z wyższą rozdzielczością (no może dość karkołomny ale zawsze). Otóż, wyższa rozdzielczość może powodować swoistą perforację dużego napisu (często jeszcze podkolorowanego), w przeciwieństwie do niższej, która poprzez "zaokrąglanie" gęstości próbek daje obszary bardziej jednolite tonalnie. Na tym napisie "Odol" widać, że te widoczne perspektywicznie "boki" liter stanowią faktycznie czarno-szaro-białą mozaikę. Podwyższenie rozdzielczości może uwyraźnić bardziej tę niejednorodność i taki napis wypada w porównaniu z resztą drobnego druku mniej oczywiście "tekstowo' a bardziej "obrazkowo".

Zrobiłem mały test na identycznym fragmencie obrazka kolorowego gazetowego:
Rozdzielczość 300 dpi dała 390843 kolory (wg XnView) i historiogram


a 1200 dpi - 984483 kolory i historiogram:
_________________
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
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 56
Dołączył: 23 Lis 2007
Posty: 44
Skąd: Zabrze
Poziom: 5
HP: 0/81
 0%
MP: 38/38
 100%
EXP: 6/13
 46%
Wysłany: 2008-02-04, 15:01   

relis napisał/a:
zmieniła się (prócz wielkości TIFFa po skadrowaniu - jak czytam na tym polegała operacja) średnia gęstość obrazu oraz stał sie on bardziej jednorodny tonalnie

Też tak sądzę. Poza tym, że moje spostrzeżenia są zbieżne, wynika z nich praktyczny wniosek. Poddając przed konwersją skany kadrowaniu (jedną z propozycji, jak dobrze pamiętam na EBIB podał dr Kolasa) mamy realną szansę podnieść precyzję segmentacji tekstu od tła. Tyle, że podobnie jak inne działania - typu skanowanie strony o niskiej gramaturze z podłożonym czarnym arkuszem - wymaga pewnego nakładu dodatkowej pracy, a to z kolei spowalnia o jakiś tam procent "masowość digitalizacji". Jeżeli chciałbyś temat drążyć dalej, może pomocnym będzie skanowanie w trybie koloru indeksowanego (256 kolorów). Dla moich przykładów z artykułu, "Głos Narodu" byłby dobrym kandydatem do testu, ponieważ zawiera treść, o którą walczymy i tło, które jest, bo jest. Zatem 256 barw może taki dokument "obsłużyć" zadowalająco, zaś powstały skan powinien ułatwić enkoderowi DjVu w znaczący sposób, podejmowanie decyzji, co gdzie umieścić.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
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.14 sekundy. Zapytań do SQL: 9