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
Wyszukiwanie pełnotekstowe w bibliotekach cyfrowych
Autor Wiadomość
A.Pulikowski

Dołączył: 30 Wrz 2009
Posty: 10
Poziom: 2
HP: 0/30
 0%
MP: 14/14
 100%
EXP: 0/8
 0%
Wysłany: 2009-10-03, 22:28   

Test potwierdził moje przypuszczenie. Przejście z DjVu na PDF skutkuje nieco mniejszymi plikami niż przy zapisywaniu PDFa z oryginalnych skanów. Przy okazji sprawdziłem różne możliwości zapisu niestandardowego, pozwalające na większą kontrolę. Najważniejsze by wyłączyć „poprawianie jakości obrazu”, gdyż powoduje ona znaczne wydłużenie zapisywania i, co gorsze, powiększa rozmiar pliku kilkukrotnie. Testując różne ustawienia doszedłem do optymalnego z mojego punktu widzenia: rozdzielczość – jak oryginał (by nie trzeba było zmieniać dla różnych dokumentów), format – LZW odcienie szarości lub kolor zależnie od dokumentu. Wybranie jpg z ustawieniem poziomu kompresji nie wpływa na rozmiar pliku, więc nie ma sensu rezygnować z lepszej jakości. Ustawienie niskiego współczynnika rozmywało tło do poziomu porównywalnego z DjVu. Jeśli taki efekt byłby pożądany to można z tej możliwości skorzystać, ale pamiętając, że rozmiar pliku nie ulega zmianie względem LZW. Ciekawe, że nawet zmiana rozdzielczości z oryginalnej na 200dpi nie wpływała na rozmiar wynikowego pliku. Wizualnie różnica była widoczna wyraźnie. Może wynika to z niedoskonałości sposobu generowania PDFów przez FineReadera.

Plik miał 18 stron. W formacie DjVu zajmował 514 KB. Korzystając z oryginalnych skanów (tych z których powstał DjVu), FineReader wygenerował PDFa o rozmiarze 1403 KB. Ustawienia: LZW w odcieniach szarości, rozdzielczość oryginału. Kiedy zamiast skanów załadowałem do FineReadera plik DjVu, to po rozpoznaniu zapisał się do formatu PDF (przy tych samych ustawieniach co poprzednio) w rozmiarze 1152 KB. Daje to w tym konkretnym przypadku 18% różnicy.

Tyle testów na dziś. Kolejne na pewno będę sukcesywnie wykonywał. Dziękuję za zaproszenie do pracowni. Wsparcie osób ze wspomnianymi skłonnościami na pewno się przyda :-)
 
     
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: 2009-10-03, 23:18   

Jeszcze jedno a propos plików PDF. Otóż podobnie jak pliki DjVu, jest sposób by "stronicowo" serwować pliki PDF. Wspomniałem kiedyś tutaj o tym mechanizmie. Nie pamiętam już, czy dLibra obsługuje już tę technologię, która się nazywa "byte-serve PDF". Po stronie samego pliku PDF wymagane jest zapisanie go w postaci "Optimized", która zapewne znacznikuje strony PDF. Jakiś czas temu była lista serwerów WWW, która była w stanie takie pliki faktycznie tak serwować, co zresztą wymagało odpowiedniej konfiguracji tych serwerów. Coś mi się obiło o uszy, że to już jest ale nie mogę znaleźć potwierdzenia. W każdym razie dLibra wspomniane w postach pliki audiovideo już potrafi obsłużyć.

I jeszcze jedno co do testowania: sam tekst może dać stosunkowo dobre rezultaty, ale dokumenty z informacją mieszaną (tekst + obrazki) stanowią problem, szczególnie przy gazetach. Często trzeba obniżać stopień kompresji, by było widać cokolwiek na zdjęciach. Podobnie może być z ilustrowanymi książkami.
_________________
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: 2009-10-04, 14:50   

relis napisał/a:
(...)
I jeszcze jedno co do testowania: sam tekst może dać stosunkowo dobre rezultaty, ale dokumenty z informacją mieszaną (tekst + obrazki) stanowią problem, szczególnie przy gazetach. Często trzeba obniżać stopień kompresji, by było widać cokolwiek na zdjęciach. Podobnie może być z ilustrowanymi książkami.

To też zależy od jakości ilustracji. Jeśli są to ilustracje rastrowe to skanowanie jednobitowe w rozdzielczości 600 dpi w większości wypadków sprawdza się bardzo dobrze. Przykład - http://www.bibliotekacyfr...jvuopts&page=92
Złudzenie odcieni szarości uzyskuje się dokładnie tak samo jak w przypadku druku, a skanowanie w trybie 8, 16 lub 24 bitów nie poprawia jakości ilustracji. W przypadku współczesnych publikacji, w których jakość ilustracji jest lepsza faktycznie pojawia się problem.
_________________
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: 2009-10-04, 20:54   

relis napisał/a:
sk napisał/a:

Ekstrakcja warstwy tekstowej i podsuwanie linków botom w dlibrze działa. Niemniej skutki są i pozostaną mizerne bez względu na jakość OCR. (...) Google jednak w końcu eliminuje strony z warstwą tekstową z indeksu.

A czy nie przypuszczasz, że było to właśnie związane z nędzna jakością OCR?

Jasne, też mi to przychodziło do głowy, ale nie sądzę, żeby to był jedyny czynnik. Dlaczego? Wydaje mi się, że trzeba na sprawę spojrzeć w sposób bardziej ogólny. Jakiekolwiek kryteria oceny stosuje indeks Google (syntaktyczne, powiązania z innymi stronami itd.), to ich celem jest wyłowienie dokumentów interesujących dla ludzi i eliminowanie zbędnej reszty. Tymczasem my podsuwamy w tym przypadku botom coś, co praktycznie nie nadaje się do normalnego użycia (nie tylko z powodu wad OCR), coś co faktycznie egzystuje poza normalnym "ludzkim" internetem. W konsekwencji indeks wyszukiwarki zawsze będzie dążył do pozbycia się tego, co mu na siłę wpychamy. Trzeba by więc albo stosować jekieś sztuczki SEO, żeby go oszukać albo starać się nadać warstwie tekstowej postać normalnego, wartościowego, "używalnego" dokumentu. Mam na myśli przynajmniej coś takiego. Niestety, stosunkowo dobry wygląd tego pliku jest tylko w części zasługą automatu generującego HTML, bo OCR w Palę Paryż został naprawiony "na piechotę", a to wymaga mrówczej pracy. I w ten sposób znowu jesteśmy w punkcie wyjścia :-(

relis napisał/a:
Niemniej sam pomysł umożliwienia podczepiania dodatkowych formatów pod identyfikator publikacji jest sensowny. Kto będzie mógł, podczepi, inni zrobią to później.

Z tym się w zasadzie zgadzam, choć nie bez zastrzeżeń. Dotychczasowa nieelastyczność dlibry w tej dziedzinie, cokolwiek o niej mówić, pozwala konsekwentnie trzymać się zasady "jeden dokument - jeden opis DC - jeden, jak sama nazwa wskazuje, URI". Natomiast przy dwóch/kilku formatach rzecz się komplikuje. Przydałoby się więc nieco bardziej systematyczne i krytyczne podejście do sprawy. To nie jest wyłącznie kwestia złożoności implementacji na poziomie kodu.

relis napisał/a:
Nie znam dokładnie Custom i nie wiem jak bardzo można by go "skastomizować" dla systemu. Lista odpowiedzi jest formatowane algorytmem Google, zgodnie z zasadami o których wiedzą lub domyślają się pozycjonerzy. Pozycje wylistowane ze wzgl. na metadane są wymieszane z frazami w pełnych tekstach, etc. Jeśli oczekiwalibyśmy lepszej jakość odpowiedzi z możliwością zawężania zapytań wg DC lub wskazania wyłącznie treści, należałoby skoncentrować się bardziej na zrobieniu z FBC solidnej wyszukiwarki o możliwościach wyszukiwania jak w poszczególnych BC.

To prawda. Google Custom nie jest w stanie uwzględnić wewnętrznej logiki indeksowanej witryny (dokumenty cyfrowe vs. poziom meta - opisy, nawigacja po strukturze wydawnictw ciągłych itd.) Pełne zindeksowanie treści dokumentów w formacie PDF tylko ten nieporządek zwiększy.

A.Pulikowski napisał/a:
Gdyby w bibliotekach cyfrowych pojawiły się PDFy mielibyśmy wszystko.

Nie chciałbym stwarzać wrażenia, że jestem zdecydowanym przeciwnikiem formatu PDF i stosowania go w bibliotekach cyfrowych równolegle z DjVu. Rozumiem argumenty przemawiające za takim rozwiązaniem i uważam je za bardzo ważne. Ale tak czy owak do ideału będzie daleko. Koszty, jak już pisałem, są całkiem spore. Co więcej, główne zalety PDF eksponowane w tym wątku, tzn. popularność, indeksowanie przez wyszukiwarki, okoliczność, że dobry program do OCR potrafi zapisywać pliki PDF, wcale nie wiążą się immanentnie z samym formatem. PDF jako format "prezentacyjny" w witrynach www sprawdza się słabo, o wiele lepiej nadaje się do drukowania i do "chomikowania". Wątpię, czy byte serving, o którym wspominał Remigiusz, wiele tu zmieni.
 
     
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: 2009-10-05, 10:15   

Po przeprowadzeniu kilku testów jest tak:
Źródłowe 19 Tifów zajmuje 351 MB.
DjVu zrobiony przez Enterprise z marnym OCR: 0,7 MB.
PDF zrobiony z powyższego DjVu (z parametrami sugerowanymi przez dr Pulikowskiego): 39MB.
PDF zrobiony z źródłowych tifów: 344 MB :-)

Muszę przyznać, że jakość OCR z PDFów zrobionych z DjVu nie odbiega zbytnio od tej z Tifów. Za to wielkością PDF prawie 1-10.

Załączam przykładowego sampla.

pdf_z_djvu.pdf
Pobierz Plik ściągnięto 848 raz(y) 1.83 MB

sample.djvu
Pobierz Plik ściągnięto 804 raz(y) 45.02 KB

 
 
     
mwerla 
Marcin Werla


Wiek: 41
Dołączył: 13 Lut 2007
Posty: 251
Skąd: Poznań, PCSS
Poziom: 14
HP: 0/426
 0%
MP: 203/203
 100%
EXP: 27/33
 81%
Wysłany: 2009-10-05, 12:24   

Witam wszystkich :-)
Chciałbym odnieść się do kilku spraw poruszanych w ramach tego bardzo ciekawego wątku:

1) Dyskusję pt. „’PDF’ vs ‘DjVu’ vs ‘PDF + DjVu’ vs ‘JPG + TXT’ vs …” warto chyba zacząć od zastanowienia się nad rolą danych zawartych w tych plikach. Danych, czyli zazwyczaj tekstu lub skanów, lub jednego i drugiego, z dodatkowymi metadanymi wiążącymi obydwie warstwy. Dyskutujemy w tej chwili o tzw. postaci prezentacyjnej publikacji/obiektów cyfrowych. Jak nazwa wskazuje, postać prezentacyjna służy do tego, żeby zaprezentować użytkownikowi obiekt cyfrowy. Poza tym, dane zwarte w postaci prezentacyjnej wykorzystywane są przez system m.in. do wyszukiwania w tekście publikacji.
W uproszczeniu można przyjąć schemat działania biblioteki cyfrowej od momentu skanowania do dostarczenia publikacji czytelnikowi taki, jak przedstawiony w załączniku.
W tym schemacie pracownia digitalizacji (w kroku C) dostarcza do biblioteki cyfrowej obiekty zawierające zarówno postać graficzną (skany), jak i postać tekstową (wynik działania OCR). W przypadku polskich BC najczęściej jest to DjVu, ale są też i pliki PDF. Oczywiście można też myśleć o jakimś formacie specyficznym dla konkretnego oprogramowania do budowy bibliotek cyfrowych (np. JPG czy TIFF i do tego XML z warstwą tekstową).
Biblioteka cyfrowa wykorzystuje otrzymany obiekt do wykonania takich wewnętrznych operacji jak indeksowanie tekstu. Obiekt jest również prezentowany użytkownikowi w sposób specyficzny dla danej BC. To tyle jeżeli chodzi o ten ogólny schemat.
W przypadku dLibry 4.0/5.0 i wykorzystania formatu DjVu serwer biblioteki cyfrowej kopiuje z obiektu cyfrowego warstwę tekstową i ją indeksuje. Czytelnikowi udostępniany jest obiekt DjVu w postaci identycznej do tej wprowadzonej lub też pliki JPG „wyciągnięte” z DjVu, dodatkowo robotom wyszukiwarek udostępniana jest skopiowana z DjVu warstwa tekstowa.
Zmiana interfejsu do przeglądania publikacji w dLibrze na taki jak tu:
http://newspapers.nla.gov...371?zoomLevel=3
czy tu:
http://www.archive.org/st...ge/n15/mode/2up
sprowadzi format DjVu do nośnika informacji wprowadzanych do biblioteki cyfrowej. Tzn. plik DjVu będzie wprowadzony do BC i tam na pewnym etapie zostanie rozłożony na obraz i tekst, aby umożliwić wyświetlenie ładnego interfejsu, dającego więcej możliwości niż wtyczka do przeglądania DjVu. Pierwszą przymiarką do takiego działania jest applet do przeglądania DjVu wbudowany w dLibrę od pewnego czasu oraz interfejs prezentacji plików JPG wprowadzony w wersji 5.0 (http://dlibra.psnc.pl/index.php?option=com_content&task=view&id=125&Itemid=72), który teoretycznie mógłby również prezentować publikacje w formacie DjVu po przekonwertowaniu ich na JPGi.
Podsumowując ten punkt – wg mnie nie powinniśmy zakładać, że docelowym rozwiązaniem jest wprowadzanie tych samych danych w różnych formatach. Niedoskonałości dLibry związane z prezentacją wyników wyszukiwania w tekście czy też brak wsparcia dla DjVu ze strony Google powinny zostać rozwiązane poprzez zmiany w oprogramowaniu. To oprogramowanie powinno działać w pełni automatyczne na podstawie jednokrotnie wprowadzonych danych o warstwie graficznej, tekstowej i ich powiązaniu dla danego obiektu cyfrowego. Łatanie „wyzwań” ;) technicznych poprzez duplikowanie danych (i pracy) moim zdaniem skończy się w pewnym momencie źle.
To oczywiście pewna wizja rozwiązania problemu, a nie obietnica że dLibra 5.0 rozwiąże wszystkie poruszane przez Państwa problemy :-)

2) Pliki PDF – w skutek problemów z dużymi plikami PDF (ponad 100 MB) w jednej z polskich BC dodaliśmy mniej więcej półtora roku temu wsparcie dla byte-serve PDF. Problemy z otwieraniem dużych PDFów polegały na tym, że jeżeli PDF nie był „strumieniowany” przez mechanizm byte-serve tylko pobierany do katalogu tymczasowego przeglądarki, to np. w przypadku Firefoxa nie można było otworzyć pliku większego niż 25 MB. Te 25 MB to połowa domyślnego rozmiaru folderu tymczasowego przeglądarki. Maksymalny rozmiar tego folderu to 100 MB (przynajmniej w lutym zeszłego roku), więc nawet po zmianie konfiguracji otwarcie „on-line” PDFa większego niż 50 MB było niemożliwe. Myślę, że warto o tym pamiętać jeżeli chcemy publikować PDF równolegle z DjVu. Oczywiście żeby współdziałać z byte-serve PDF musi być odpowiednio zapisany, jak już tu zostało wspomniane.

3) POLONA i dLibra – POLONA działa na podstawie dLibry w wersji 2.5 wydanej w 2006 roku (http://www.polona.pl/dlibra/oai-pmh-repository.xml?verb=Identify). Z tego co mi wiadomo, dLibra wykorzystywana jest do przechowywania i prezentacji metadanych. Za składowanie i serwowanie treści w postaci JPG odpowiedzialny jest system SZZ. Z tego co widzę teraz, to treść w formacie PDF jest składowana w dLibrze i dzięki temu działa wyszukiwanie w tekście publikacji.

A więc podsumowując w dLibrze mamy:
- dla części publikacji: metadane + treść (plik PDF + pusty dokument HTML zawierający przekierowanie właściwego adresu w SZZ)
- dla reszty publikacji: metadane + treść (jedynie pusty dokument HTML zawierający przekierowanie właściwego adresu w SZZ)

Co do linku z menu do postaci PDF, jak widzę przyjęto proste i skuteczne rozwiązanie polegające na nazywaniu wszystkich plików PDF tak samo – „ocr.pdf”. Tak więc mamy postać OCR/PDF:

http://www.polona.pl/Content/20459/ocr.pdf
i postać JPG:
http://193.59.172.16/szzz/ShowStart.do?id=31104
(otwarcie tej postaci przekierowuje do widoku pełnej nawigacji w POLONIE).

Gdyby ktoś chciał zastosować podobny wariant u siebie, nie wykorzystując SZZ to powinien wprowadzić jako pliki jednego wydania publikacji zarówno pliki DjVu jak i PDF i minimalnie zmodyfikować strukturę menu dLibry wyświetlanego na stronach WWW przy treści i opisie publikacji, aby pojawiła się dodatkowa pozycja i wskazywała na ten dodatkowy plik PDF. Stała nazwa pliku (ocr.pdf) będzie przy takiej modyfikacji sporym ułatwieniem.

Ale tak jak pisałem wcześniej wg mnie taka duplikacja danych do na dłuższą metę złe rozwiązanie. Rozumiem oczywiście, że rozwiązanie w POLONIE zostało przemyślane i są konkretne motywy jego wdrożenia (chociażby współdziałanie dwóch bardzo luźno zintegrowanych systemów informatycznych, które wg wizji twórców Polony uzupełniają się wzajemnie). Uważam, że takie podejście jest ciekawe jako tymczasowe, jednak nie powinno być traktowane jako wzorcowe czy docelowe.

4) Poeksperymentujemy z możliwościami Google custom search do wyszukiwania w tekście publikacji z poziomu FBC. Może da się zawęzić wyniki przez warunek na URL (/Content/). Oczywiście to tylko rozwiązanie tymczasowe :-)

5) Bardzo podoba mi się automat generujący XHTMLa z DjVu. Może faktycznie mógłby poprawić on widoczność tekstu z DjVu w Google, gdybyśmy go użyli zamiast obecnej formy prezentacji tego tekstu automatom. Zresztą po wrześniowych warsztatach i pomyśle Tomka Kaloty związanego z pozycjonowaniem publikacji bibliotek cyfrowych w wyszukiwarkach coś czuję że ten temat będzie teraz popularny :-)

workflow-oc.jpg
Workflow
Plik ściągnięto 293 raz(y) 33.24 KB

_________________
Marcin Werla
Zespół Bibliotek Cyfrowych PCSS
 
 
     
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.09 sekundy. Zapytań do SQL: 10