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
Cykl produkcyjny "gothic-djvu"
Autor Wiadomość
Tomasz Kalota 
Tomasz Kalota


Wiek: 49
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2007-11-23, 23:22   Cykl produkcyjny "gothic-djvu"

Problem publikowania książek i czasopism drukowanych czcionka gotycką nie daje mi spokoju już od dłuższego czasu. BUWr posiada dosyć dużo zbiorów tego typu i opracowanie metody produkcji plików DjVu z warstwą tekstową umożliwiającą przeszukiwanie treści drukowanej gotykiem jest dla mnie dosyć istotną sprawą. Mała dyskusja na ten temat miała już miejsce na forum EBIB w ubiegłym roku, jednak dopiero kilka dni temu pojawiła się szansa na rozwiązanie tego problemu. Grzegorz Bednarek w pierwszym podejściu przygotował publikację, która spełnia moje oczekiwania :). Trzeba jeszcze dopracować wiele szczegółów ale chyba został już odnaleziony właściwy trop.

Przykłady:
1. gothic-DjVu
2. gothic-PDF

Skrócony przepis na produkcję "gothic-djvu" przy pomocy Enterprise'a

Grzegorz Bednarek napisał/a:
(...)
1 etap. Konwersja wsadowa do djvu plików tiff wg dogłaskanego profilu.
2 etap Produkcja z takich tiff j.w. plików pdf, które zawierają tylko tekst (te białe arialowe, nieduże pojemnością)
3.etap Wsadowa konwersja powyższych pdf'ów z ekstrakcją warstw OCR jako xml i jej reeksport do plików powstałych w etapie 1.
(...)

Umówiliśmy sie z Grzegorzem, że dalej będziemy dyskutować tutaj, więc niebawem powinno pojawić się więcej szczegółów. Oczywiście zachęcam do dyskusji wszystkich zainteresowanych tym tematem.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
relis 


Wiek: 54
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: 2007-11-23, 23:44   Re: Cykl produkcyjny "gothic-djvu"

Tomasz Kalota napisał/a:


Skrócony przepis na produkcję "gothic-djvu" przy pomocy Enterprise'a

Grzegorz Bednarek napisał/a:
(...)
1 etap. Konwersja wsadowa do djvu plików tiff wg dogłaskanego profilu.
2 etap Produkcja z takich tiff j.w. plików pdf, które zawierają tylko tekst (te białe arialowe, nieduże pojemnością)
3.etap Wsadowa konwersja powyższych pdf'ów z ekstrakcją warstw OCR jako xml i jej reeksport do plików powstałych w etapie 1.
(...)

Umówiliśmy sie z Grzegorzem, że dalej będziemy dyskutować tutaj, więc niebawem powinno pojawić się więcej szczegółów. Oczywiście zachęcam do dyskusji wszystkich zainteresowanych tym tematem.

Czy z tego wynika, że PDF-owy OCR jest jakoś lepszy niż ten DJVU-owy - skoro trzeba robić to tak na okrętkę i potem dopiero sztukować tekst do 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
 
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 49
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2007-11-23, 23:56   Re: Cykl produkcyjny "gothic-djvu"

relis napisał/a:
Czy z tego wynika, że PDF-owy OCR jest jakoś lepszy niż ten DJVU-owy - skoro trzeba robić to tak na okrętkę i potem dopiero sztukować tekst do DJVU?

OCR jest FineReader-owy. Na DjVu nie da się zrobić OCRu gotyku, do tego potrzebna jest specjalna wersja FineReadr XIX. PDF służy tylko jako forma przejściowa do przeniesienia wyniku OCR i złożenia go z obrazkiem w pliku DjVu.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
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: 2007-11-24, 01:01   

Tomasz Kalota napisał/a:
Przykłady:
1. gothic-DjVu (...)

Niezły wynik. Chyba nawet lepszy, niż w przypadku OCR współczesnych druków w Document Express :-) . Łatwiej to ocenić oglądając warstwę tekstową wyłuskaną z tego dokumentu DjVu.
 
     
relis 


Wiek: 54
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: 2007-11-24, 01:24   

Jednakowoż FineReader XIX, jak mnie uświadomił Tomek, kosztuje jakieś kosmiczne pieniądze i jest w dodatku licencjonowany na ograniczoną ilość rozpoznanych skanów. :-(
To przejście przez PDF ma na celu zapewne poprawne złożenie tekstu z DJVU, bo oddaje fizyczne rozmieszczenie tekstu na stronie, dzięki czemu tekst "trafia" pod właściwy obrazek w pliku DJVU.
Sprytne ale drogie - na jakiś większy prodżekt.
_________________
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
 
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 49
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2007-11-24, 10:58   

sk napisał/a:
Tomasz Kalota napisał/a:
Przykłady:
1. gothic-DjVu (...)

Niezły wynik. Chyba nawet lepszy, niż w przypadku OCR współczesnych druków w Document Express :-) . Łatwiej to ocenić oglądając warstwę tekstową wyłuskaną z tego dokumentu DjVu.

Wynik jest dobry ponieważ na potrzeby wydawnictwa był ręcznie korygowany. Jest to dosyć żmudna i czasochłonna praca więc w przypadku masowej digitalizacji raczej odpada. Mimo to jednak jakość OCRu w FineReaderze jest dużo lepsza niż w Document Express, a ponadto FR posiada bardzo wygodne narzędzia do przeprowadzenia korekty. FR ma jednak jedna wadę, nie potrafi zapisywać wyników do warstwowego DjVu co pewnie bardziej jest podyktowane względami marketingowymi niż technicznymi. Ostatnio w FR obok PDFa pojawił się dodatkowo microsoftowy LIT, a DjVu nadal traktowany jest po macoszemu.

Wracając do korygowania to myślę, że warto zacząć poważnie myśleć o społecznościowym poprawianiu OCRu, o czym już wspominał nie raz Remigiusz. Tutaj jest przykład katalogu kartkowego , który każdy użytkownik może dowolnie poprawiać. Co ważne to działa i jakoś nie widać żeby wandale internetowi zmówili się, żeby sabotować to przedsięwzięcie. Przecież jak każdy może tam pisać co chce to pierwsza myśl jaka nam do głowy przychodzi, ze zaraz miliony użytkowników nic innego nie będą mieli do roboty tylko pisać miliony bzdur w milionach kart. Świetne zajęcie dla zabicia czasu ;-) .
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 58
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: 2007-11-24, 16:28   

Korzystając z premierowego wpisu, pozdrawiam wszystkich forumowiczów.
Tomek nie wspomniał o tym, że pliki pdf, które "produkuje" FR mają w zależności od życzeń użytkownika kilka postaci. Jedna z nich to zaledwie "wciśnięty" w nagłówek pdf zeskanowany plik tiff. Ta postać, w przypadku, gdy nie dysponuje się plikiem tiff służy do konwersji do formatu DjVu wg optymalizowanego lub standardowego profilu (np. Manuscript). I to połowa pracy nad plikiem, który Tomek ochrzcił "gothic-djvu".
Kolejna postać pliku pdf, to już - jak sądzę - standardowe podejście informatyków do problemu : "Skoro ktoś już zrobił coś, po co się męczyć, można to zagospodarować" i powstał plik, który - obrazowo tłumacząc - wygląda tak, że posiada każdą stronę publikacji zdublowaną. Pierwsza "odsłona" to zeskanowana strona publikacji. I ta zawartość wyświetlana jest czytelnikowi. Ponieważ na "obrazku" nawigację (zaznaczanie rozpoznanych wyrazów) należałoby zrobić od nowa, chłopcy pod nią umieścili "pustką kartkę", na której wg współrzędnych {x;y} oraz informacji o wysokości i szerokości rozpoznanego słowa (dane przekazuje FR) umieścili tekst strony czcionką Arial. Takie "tekstowe" pliki pdf (np. powstałe z Worda) pozwalają podświetlać i zaznaczać wyraz (lub grupę wyrazów). Mamy zatem w naszym pliku postać graficzną, pod nią postać "wygenerowaną" i oczywiście wszystkie słowa z poprawnością wg cierpliwości osoby korygującej surowe rozpoznanie FR. Co zatem zobaczy czytelnik otwierając tak poskładany plik pdf? Zobaczy zeskanowaną stronę z czcionką gotycką, na której o dziwo można zaznaczyć pojedynczy wyraz, bo w momencie zaznaczania włączają się podstawowe opcje Readera, które obsługując spodnią-wygenerowaną stronę, wyświetlają podświetlanie na stronie wierzchniej (widocznej). Sprytne, fajne, działa ale również powoduje drobne spowolnienie i niestety ucieka w górę rozmiar pliku pdf. Na całe szczęście FR pozwala również wygenerować plik pdf tylko z tą "wygenerowaną" białą kartką zapisaną czcionką Arial (i dostępnymi opcjami dla tekstu). Taki właśnie plik wykorzystałem do "wyjęcia" Enterprise'm warstwy tekstowej z pdf, po czym przeniosłem ją do pliku DjVu. Relis zauważył, że ta "okrętka" dotyczy wykorzystania pdf, który posiada informacje o fizycznym położeniu poszczególnych wyrazów na stronie. Oczywiście, bo w procesie pozyskiwania warstwy tekstowej dla graficznego obrazu strony nie jest ważna sama zawartość warstwy tekstowej ale koordynaty poszczególnych wyrazów. Dopiero wtedy można dokonywać oceny, czy prawidłowo rozmieszczony tekst zawiera nieznaczącą ilość błędów, czy też wymaga korekty. Ale będzie to ocena etapu korekty OCR zanim powstał plik pdf. Skorygowaną postać OCR przeniesiono do pdf, a z niego przeniesiono do DjVu. Celowo używam "przeniesiono", ponieważ nie jest to operacja rozpoznania, więc nie będzie żadnych przekłamań, Zatem Skarbimir nie pochwalił Enterprise'a lub Adobe Professional'a, lecz pochwalił Tomka.
Poza tym, była to produkcja na zasadzie "mam 2 godziny luzu". FR XIX generuje nie tylko (dla omawianych potrzeb gotyku) pliki pdf. Produkuje również pliki tiff, csv, xml, ponoć dbf oraz pliki "własne" frf (Fine Reader Format). Uważam, że rozpracowanie tego formatu jest drogą do najwydajniejszego tworzenia wielostronicowych publikacji DjVu z możliwie najlepiej rozpoznaną warstwą OCR. Ale póty co, powstał "gothic-djvu" na okrętkę, co oznacza, że sposób już jest, zatem czas na jego optymalizację.
_________________
"Wszystko jest trudne do czasu, gdy stanie się proste"
 
     
relis 


Wiek: 54
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: 2007-11-24, 19:17   

Jeśli tak dzielić na obrazek, z którego generuje się poprzez kolejne konwersje test i następnie kleić Enterprisem, to także be większego bólu można podnieść trafność (w jakimś stopniu rzecz zapewne) OCR dzięki skanowaniu w rozdzielczości dużo wyższej, niż ta później użyta do sklejenia.
Tomek coś wspominałeś, że do niektórych druków do OCR dajecie nawet 600 spi, schodząc za to z głębi do 1 bita.
Może przeprowadzimy zatem test - dając kompresorowi 300 spi a potem 600 i porównamy warstwy tekstowe. Jeśli będą różne - to będzie dość sympatyczna, nowa przesłanka co do rozdzielczości plików master.
Faktycznie może się to nie przekładać na wielkość masterów, bowiem przy nowszych drukach rezygnacja z kolorków, czy szarości na rzecz trafniejszego OCR jest zasadna.
_________________
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
 
 
     
Spiechu 


Wiek: 39
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: 2007-11-24, 19:47   

relis napisał/a:
Jeśli będą różne - to będzie dość sympatyczna, nowa przesłanka co do rozdzielczości plików master.

Należy przemyśleć jeszcze 2 rzeczy:

1.: Skaner w rozdzielczości 600 dpi w porównaniu do 300 dpi skanuje połowę czasu dłużej. Czy nam się to rzeczywiście opłaca? A może tylko super-ważne rzeczy robić w 600 dpi?

2.: Skany w skali szarości (nie mówiąc już o kolorze) zajmują koszmarnie dużo miejsca. Jeżeli wynik OCR rzeczywiście byłby lepszy, można by te 600 dpi używać tylko do konwersji na DjVu, a następnie przed archiwizacją (np. na DVD-R) konwertnąć w XnView do 300 dpi. W końcu wizualnie 300 dpi od 600 dpi nie różnią się aż tak bardzo, za to ilością zajmowanego miejsca - bardzo.
 
 
     
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: 2007-11-24, 22:41   

Grzegorz B. napisał/a:
(...) oraz pliki "własne" frf (Fine Reader Format). Uważam, że rozpracowanie tego formatu jest drogą do najwydajniejszego tworzenia wielostronicowych publikacji DjVu z możliwie najlepiej rozpoznaną warstwą OCR. (...)

To robią już Rosjanie (strona po rosyjsku, trzeba zajrzeć do działu katałog failow).Testowaliśmy z powodzeniem na zwykłych drukach, ale chyba powinno działać również w przypadku gotyku, o ile użyje się FR XIX. Idea jest tu nieco podobna jak w opisanej wyżej procedurze, tzn. konwertuje się DjVu na TIFF (albo bierze od razu skany, z których robiony byl DjVu), obrabia się FineReaderem, a na podstawie FRF powstaje poprawiona warstwa tekstowa "wkładana" z powrotem do DjVu.

Zaleta: program jest bezpłatny. Wygląd ma trochę garażowy, w niewielkim stopniu przypomina programy typu Super Enterprise Server Edition Millenium Pro, ale działa skutecznie. Podstawową wadą jest wydłużenie procesu powstawania gotowej publikacji cyfrowej.

Jeszcze inne podejście omawiane było na Planet DjVu. W skrócie: ABBYY Recognition Server produkuje masowo output w postaci XML, który za pomocą perla lub XSLT da się zamieniać na XML właściwy dla DjVu.
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 49
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2007-11-24, 23:10   

Grzegorz B. napisał/a:
(...)Tomek nie wspomniał o tym, że pliki pdf, które "produkuje" FR mają w zależności od życzeń użytkownika kilka postaci(...)

Dokładnie tak jest. Poniżej podaję linki do plików z samym obrazkiem i samym tekstem.
1. gothic-PDF-obrazek
2. gothic-PDF-tekst

Grzegorz B. napisał/a:
(...)Skorygowaną postać OCR przeniesiono do pdf, a z niego przeniesiono do DjVu. Celowo używam "przeniesiono", ponieważ nie jest to operacja rozpoznania, więc nie będzie żadnych przekłamań, Zatem Skarbimir nie pochwalił Enterprise'a lub Adobe Professional'a, lecz pochwalił Tomka.(...)

Skarbimir pochwalił Edytę Kotyńską, która przesiedziała wiele godzin przed monitorem żeby doprowadzić wynik OCRu z FRXIX do doskonałości :-) . W przeciwieństwie do mnie Edyta potrafi czytać gotyk i to ze zrozumieniem tekstu, co ma bardzo duże znaczenie przy tego typu pracy. To nasze małe doświadczenie z opracowaniem "Bunzlauische Monathschrift" jest jednym z wielu przykładów obalających mit o digitalizacji zabierającej pracę bibliotekarzom. Pracy przybywa tylko w innym miejscu.

Grzegorz B. napisał/a:
(...) FR XIX generuje nie tylko (dla omawianych potrzeb gotyku) pliki pdf. Produkuje również pliki tiff, csv, xml, ponoć dbf oraz pliki "własne" frf (Fine Reader Format). Uważam, że rozpracowanie tego formatu jest drogą do najwydajniejszego tworzenia wielostronicowych publikacji DjVu z możliwie najlepiej rozpoznaną warstwą OCR. Ale póty co, powstał "gothic-djvu" na okrętkę, co oznacza, że sposób już jest, zatem czas na jego optymalizację.

Przed rozpracowaniem plików FRF trzeba chyba wcześniej rozpracować licencję na FineReadera. Nie jestem pewien ale coś mi się obiło o uszy, że ABBYY nie życzy sobie rozpracowywania tych plików, ale mogę się mylić.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 49
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2007-11-24, 23:53   

relis napisał/a:
(...)Tomek coś wspominałeś, że do niektórych druków do OCR dajecie nawet 600 spi, schodząc za to z głębi do 1 bita.
Może przeprowadzimy zatem test - dając kompresorowi 300 spi a potem 600 i porównamy warstwy tekstowe. Jeśli będą różne - to będzie dość sympatyczna, nowa przesłanka co do rozdzielczości plików master.
Faktycznie może się to nie przekładać na wielkość masterów, bowiem przy nowszych drukach rezygnacja z kolorków, czy szarości na rzecz trafniejszego OCR jest zasadna.

Spiechu napisał/a:
(...)
1.: Skaner w rozdzielczości 600 dpi w porównaniu do 300 dpi skanuje połowę czasu dłużej. Czy nam się to rzeczywiście opłaca? A może tylko super-ważne rzeczy robić w 600 dpi?
(...)

Aby rozstrzygnąć te dylematy musimy wrócić do historycznego, ale jakże aktualnego wywodu Remigiusza na temat modeli bibliotek cyfrowych. Bardzo często w wielu dyskusjach przywołuję ten tekst ponieważ uważam go za fundament. Od tej pierwszej decyzji związanej z zakwalifikowaniem obiektu do konkretnego modelu biblioteki cyfrowej zależy szereg kolejnych decyzji:
jaka rozdzielczość
jaki skaner
jaka głębia kolorów
jaka konfiguracja procesu digitalizacji
jakie koszty
jaka obróbka
jakie oprogramowanie
jaka strukturyzacja treści
jak prezentacja
itd.
Zauważcie ile decyzji może zostać błędnie podjętych jeśli ta pierwsza, dotycząca wyboru modelu biblioteki cyfrowej, zostanie podjęta bez namysłu.

Odpowiadając Remkowi i Śpiechowi podam przykład:
1. Publikacja Reforma notariatu - typowy przykład modelu informacyjnego
2. Digitalizacja na kserokopiarce cyfrowej - jdnobitowo z rozdzielczością 600 dpi (około 30 stron na minutę, maszyna potrafi 40 na minutę ale nie zdążyłem tak szybko przekładać stron)
3. Pliki master - tiff z LZW średnio po kilkaset kB
4. Pliki prezentacyjne - DjVu z OCRem średnio po kilkanaście kB
Z testów wynika, ze 600 dpi umożliwia lepszy OCR niż 300. Nie jest to jakaś powalająca różnica, ale obniżenie rozdzielczości do 300 dpi nie daje żadnych wymiernych korzyści związanych z oszczędnością czasu czy miejsca, więc nie ma sensu w tym przypadku oszczędzać.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
Grzegorz B. 
Grzesiek

Wiek: 58
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: 2007-11-25, 22:20   

Już odpowiadam Tomkowi w sprawie analizowania czy też wręcz "grzebania" w plikach .frf. Praktycznie każde oprogramowanie komercyjne zawiera zastrzeżenie, by nie bawić się debuggerem lub dissassemblerem. Podobnie produkty GNU "nie lubią" być redystrybuowane w "kawałku" tylko jako pakiet pełny czy też instalacyjny. Ale żaden z tych produktów (przynajmniej tego nie spotkałem) nie zabrania mi analizować tego, co takie oprogramowanie stworzyło (np. plik doc, dwg, djvu czy też bmp lub tiff). Zatem uściślijmy - nie chodzi mi to, by zmienić zawartość plików programowych pakietu FR, lecz jego twory, a to zasadnicza różnica. A przede wszystkim sądzę, że legalna.

Cytat:
Tomek coś wspominałeś, że do niektórych druków do OCR dajecie nawet 600 spi, schodząc za to z głębi do 1 bita. Pewnikiem jest, że pomoże tylko czy tak efektywnie jak poddane pod rozwagę narzędzia?
Może przeprowadzimy zatem test - dając kompresorowi 300 spi a potem 600 i porównamy warstwy tekstowe. Jeśli będą różne - to będzie dość sympatyczna, nowa przesłanka co do rozdzielczości plików master.

Uważam, że wynik tego testu niewiele wyjaśni, ale chętnie się pomylę. Podczas skanowania z większą rozdzielczością precyzyjniej oddany zostanie zarówno czytelny fragment litery jak i jej słabo lub niewidoczny fragment. Mam tu na myśli "e", "I" lub "N" odczytywane jako "c","1" lub "IV". Dodatkowo, głębia 1 bitu nieodwracalnie usunie informacje, dzięki którym te słabo widoczne fragmenty liter można by uwypuklić. Ponieważ nie pracuję w żadnej bibliotece, chcąc zaprezentować cokolwiek na naszej stronie, pobierałem krótkie publikacje z witryn typu Archiwum Akt Nowych i takie najczęściej mocno skompresowane jpg 100dpi przetwarzałem do DjVu. Prawie syzyfowe prace. O tym, jak przebiegnie konwersja oraz rozpoznanie OCR decydowały odpowiednie zmiany kontrastu lub wartości Gamma (najczęściej 1,6÷2,5). Gdyby bez tych operacji jakość segmentacji nazwać katastrofą, byłaby to wyjątkowo delikatna ocena. Myślę, że test, do którego przymierza się Relis z Tomkiem należy przede wszystkim zastrzec, że dotyczy tylko pewnej grupy - o podobnej naturą - publikacji (np. trwale zszyte książki o lekko zażółconych arkuszach) i wniosków z testu nie stosować dla publikacji typu zeskanowane czasopisma i gazety. Poza tym, partię skanów 300 dpi/24-Bit można poddać delikatnym transformacjom kontrast/Gamma/jasność i takie krótkie serie rozpoznać względem OCR. W końcu Adobe PhotoShop posiada przetwarzanie wsadowe, więc korekcja Gamma lub kontrastu dla załóżmy 10.000 stron, to naciśnięcie guzika.
Dlatego nie faworyzowałbym z góry wartości rozdzielczości jako jedynego leku na podniesienie trafności rozpoznania, choć pewnikiem jest, że pomoże. Na pewno taki test pomógłby uporządkować lub doprecyzować listę Tomka :
Cytat:
Od tej pierwszej decyzji związanej z zakwalifikowaniem obiektu do konkretnego modelu biblioteki cyfrowej zależy szereg kolejnych decyzji:

podporządkowując ją nie tylko kolejności i rodzaju decyzji osoby digitalizującej zasób ale i uzależniającej jej zawartość od rodzaju digitalizowanego zasobu (czyli tak naprawdę szczegółowych list może być kilka).
_________________
"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.1 sekundy. Zapytań do SQL: 8