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
Serwer kompresji DjVu Enterprise
Autor Wiadomość
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-16, 23:07   Serwer kompresji DjVu Enterprise

Uruchomiliśmy w SPD na dobre serwer kompresji Enterprise, automatyzując w znacznym stopniu przygotowywanie zasobu do BC. Ma on ogromne możliwości pracy wsadowej, co jest bardzo ważne np. przy przetwarzaniu czasopism. M. in. można do niego wysłać na dyski katalog zawierający rocznik czasopisma w postaci podkatalogów zawierających skany poszczególnych numerów gazety. Enterprise, po 30 s. od skończenia zapisywania do swojego katalogu, zaczyna kompresję, wyrzucając do katalogu wyjściowego taką samą strukturę katalogów przetwarzanych, ale już z plikami DJVU. Pewną niedogodnością jest fakt, że te pliki mają postać scaloną, lecz to dało się rozwiązać za pomocą skryptu (autorstwa Spiecha), który "chodzi" po tych podkatalogach i przetwarza scalone pliki DjVu do postaci "rozbitej".
Enterprise ma także możliwość elastycznego ustawiania progu zaliczania części obrazu do warstwy tła i tekstowej. W przeciwieństwie do Document Express (który ma tę wartość ustawioną na sztywno na 10), za radą producenta kompresujemy na poziomie 12 - co w efekcie daje trafniejszy OCR.

Owe "hot folders", do których zapisuje się skany do przetworzenia, a które serwer przegląda w poszukiwaniu roboty, mogą mieć różne parametry kompresji. Zatem można zdefiniować foldery typu OCR polski, OCR niemiecki, mapy, zdjęcia, itp, wiążąc z każdym z nich odpowiednie parametry obróbki, które w DocumentExpress trzeba dobierać ręcznie.
_________________
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-18, 14:20   

Dodam jeszcze kilka rzeczy:
  • Serwer w sieci lokalnej ma nazwę usunięte przez administratora (informacja nadmiarowa i bezużyteczna).
  • Pliki wrzucane na wejściu są automatycznie kasowane (jeżeli kompresja się powiedzie) lub kopiowane do katalogu errors (jeżeli coś pójdzie nie tak) - zatem należy zawsze mieć gdzieś kopię zapasową skanów (chyba nie musiałem o tym wspominać? ;-) ).
  • Nazwy poszczególnych folderów ze skanami NIE MOGĄ zawierać spacji w nazwie! Przerwy należy zastąpić najlepiej znakiem _ lub - . To ważne. Skrypt napisałem w DOSie, a nie od dziś wiadomo, ze DOS nie radzi sobie zbyt dobrze ze spacjami w nazwach folderów...
  • Dobrany profil kompresji jest możliwie optymalny dla większości kompresowanych materiałów. Pliki DjVu są nieco większe, ale zyskaliśmy trochę lepszą jakość (mniejsza kompresja warstwy tekstu - przez co literki są trochę "okrąglejsze", mapy i fotografie wyglądają dużo lepiej). W końcu parę kilo nikogo nie zbawi? :-)
  • Gotowe pliki DjVu kopiowane są do folderu dla redaktorow. Po przegraniu na swój komputer proszę je stamtąd usuwać w celu uniknięcia bałaganu.
  • Nie wiem dlaczego, ale wersja Enterprise również ma problemy z OCR - mówiąc jaśniej - czasem wiesza się. Nawet pomimo prawidłowego rozdzielenia warstwy treści od tła. Sporo kombinowałem z ustawieniami kontrastu, jasności, różnymi filtrami itd. Problemy z wersji Professional są nadal aktualne...
  • Gdyby kogoś interesowało: Można wyodrębnić rozpoznany OCR w formie pliku XML i manualnie go poprawić, po czym "wkleić" z powrotem do pliku DjVu. Jeżeli ktoś ma super-ważny/unikatowy dokument - może pokusić się o poprawki w rozpoznanym tekście.
Ostatnio zmieniony przez bib20 2007-11-26, 18:43, w całości zmieniany 1 raz  
 
 
     
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-26, 07:33   

DocumentExpress Enterprise jest nie tylko "serwerem kompresji", choć można jego działanie tylko do tych prac ograniczyć. Należy nie zapominać, że równie wydajnie działa z plikami ... DjVu. Dla przykładu, jeżeli podjęto decyzję o korygowaniu warstw tekstowych z pewnej ilości plików DjVu, można je wskazać i wybrać operację wsadowego tworzenia całej kolekcji plików xml. Inne drobiazgi to np. wyposażenie plików DjVu w znak wodny, miniatury lub rozpoznanie OCR, jeżeli "kiedyś tam" dla pewnej kolekcji plików DjVu o w/w operacjach zapomniano.

relis napisał/a:
Pewną niedogodnością jest fakt, że te pliki mają postać scaloną, lecz to dało się rozwiązać za pomocą skryptu (autorstwa Spiecha)


Tą kwestię omawiałem z Śpiechem w ŚBC. LizardTech tym celowym ograniczeniem nie dopuścił do przypadkowego zniszczenia powstałych publikacji w formacie DjVu. Publikacje DjVu zapisane sposobem rozdzielonym zawierają nie tylko pliki kolejnych stron, ale również miniatury, słowniki powtarzających się kształtów oraz pliki adnotacji. Te ostatnie najczęściej posiadają nazwę Shared_ANNO.iff, a po powstaniu publikacji nazwy tej nijak zmienić nie wolno. Gdyby dopuścić do konwersji w postaci rozdzielonej, to druga konwersja w danym folderze zniszczy przez nadpisanie plik Shared_ANNO.iff pierwszej konwersji, a trzecia zniszczy plik drugiej itd. Stąd konieczność skryptu, który rozdzielony odpowiednik postaci scalonej wyśle do "bezpiecznej" lokalizacji wskazanej przez redaktora czy też operatora Enterprise'a.

relis napisał/a:
Enterprise ma także możliwość elastycznego ustawiania progu zaliczania części obrazu do warstwy tła i tekstowej. W przeciwieństwie do Document Express (który ma tę wartość ustawioną na sztywno na 10), za radą producenta kompresujemy na poziomie 12 - co w efekcie daje trafniejszy OCR


Może słowo wyjaśnienia do powyższego cytatu. Źródło konwersji (najczęściej plik tiff) można nazwać plikiem z kompresją 1:1 (czyli jej brakiem). Gdy utworzymy z takiego pliku jpg'a, to jego zawartość będzie posiadać taką kompresję jak sobie ustawimy suwakiem i najczęściej wyrażoną w programach procentowo. Z kolei dla enkodera DjVu, mamy do czynienia z dwoma procesami konsekutywnymi.
W pierwszym procesie jest narzucana (Professional) lub wskazywana przez użytkownika (Enterprise, profile użytkownika) kompresja dla warstwy treści (jako stosunek liczb naturalnych np. 1:12) z zachowaniem wartości wybranej rozdzielczości (wyjątkiem są pliki o niskiej rozdzielczości np. 100 dpi, dla których enkoder wykona upsampling warstwy treści do 300 dpi).
W kolejnym procesie wyznaczana jest wartość rozdzielczości (nie poziomu kompresji) dla warstwy tła względem wskazanej lub "podniesionej" wartości rozdzielczości warstwy treści, również jako stosunek liczb naturalnych. Np 1:3 oznacza, że rozdzielczość warstwy tła będzie trzykrotnie niższa niż rozdzielczość warstwy treści. I teraz to, co najciekawsze. Dla warstwy treści powinien nas interesować jej poziom kompresji (w końcu mówimy o literach, krzywych czy też ogólnie o obiektach o wyraźnych obrzeżach). Stąd też posiadacze Enterprise'a mogą sobie m.in. tą wielkością manipulować. Z kolei dla warstwy tła powyższa informacja nie jest istotna, bo w tle nie ma takich obiektów, tylko wypełnienia barwne itp. Dlatego dla warstwy tła mamy do dyspozycji wartość "background quality", którą można - podobnie jak w wirtualnej drukarce - manipulować w zakresie od 0 do 100 (a w praktyce opłaca się zakres ten ograniczyć : od 70 do 95).
Gdy priorytetem tworzonej publikacji jest poprawność warstwy tekstowej, oczywiście istotnym jest, by poziom kompresji warstwy treści obniżyć, a przy okazji nie polecam takiego dzielnika, który nie prowadzi do wartości całkowitej np. skan 400 dpi i kompresja 1:6 prowadzi do wartości 400/6, czyli 66.67 dpi.
DocumentExpress Professional rzeczywiście nie pozwala manipulować kompresją warstwy treści, ale nie jest to poziom stały i równy 10. Jest to poziom stały dla danego profilu. Jeżeli się nie mylę, dla profilu Clean=5, dla profilu Scanned=12. Zatem empirycznie producent dobrał tą i wiele innych wartości wpływających na kompresję (co uprościło obsługę programu) i udostępnił te wielkości jako kilka profili o sugestywnych nazwach typu Map, Drawing czy też Manuscript.
_________________
"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.17 sekundy. Zapytań do SQL: 10