Wielkim przełomem w naszych metodach pracy była realizacja projektu „NUKAT – autostrada informacji cyfrowej” w latach 2008-2013. Początkowo nie zakładał on jakiegoś radykalnego przełomu w sposobie digitalizacji w BUW-ie. Zarówno skanowanie jak i przetwarzanie plików do postaci prezentacyjnej miało zostać wykonane przez firmy zewnętrzne. Jednak bardzo pomyślne efekty postępowań przetargowych (i spowodowane tym oszczędności) umożliwiły poszerzenie projektu o tzw. digitalizację uzupełniającą.
Koncept ten wywodzi się w swej istocie jeszcze z czasów działalności mikrofilmowej: starano się zazwyczaj nie tyle oddać obraz jakiejś konkretnej sygnatury czasopisma, a zrekonstruować cały jego ciąg czyli: uzupełnić brakujące strony lub numery – czy to z innego egzemplarza przechowywanego w bibliotece, czy sprowadzonego z zewnątrz za pośrednictwem wypożyczalni międzybibliotecznej. Dla realizacji tego przedsięwzięcia poszerzyliśmy ze środków projektowych nasz park maszynowy kupując skanery ProServ ScannTECH 601i (umożliwiający wykonywanie skanów o rozdzielczości do 600 dpi przy powierzchni skanowania do formatów A1) i Bookeye 3 (450 dpi do formatu A2) oraz automatyczny skaner do mikrofilmów.
Digitalizacja masowa, ale dokładna
Skaner Bookeye 3 zakupiony ze środków projektu „NUKAT – autostrada informacji cyfrowej”. Fot. Monika Konarska.
Doświadczenia z masową digitalizacją (wykonanych i przetworzonych do formatu prezentacyjnego zostało ponad 3 mln skanów, proces uzupełnień, który toczy się do chwili obecnej wygenerował dodatkowo ponad 100 tys. skanów) oraz kontakt z know-how firm wykonujących nasze zlecenia zaowocowały profesjonalizacją naszej działalności. Przede wszystkim zakupiliśmy oprogramowanie umożliwiające fachową konwersję do formatu DjVu: manipulację na poziomie pojedynczej strony profilem konwersji i jego parametrami, dzięki czemu jakość plików DjVu mogła się znacząco poprawić przy niewielkim zwiększeniu ich rozmiaru. Dalszej automatyzacji uległy poszczególne procesy, dotychczas pieczołowicie wykonywane przez człowieka (np. generowanie struktury folderów czasopisma, wczytywanie warstwy tekstowej do pliku DjVu, rozmaite manipulacje na już istniejących plikach – wymiany zdestruowanych stron na ich odpowiedniki z innych egzemplarzy, łączenie i dzielenie publikacji, dodawanie lub wyodrębnianie stron). Rozpoczęliśmy również dodawanie do plików prezentacyjnych wewnętrznych metadanych, dzięki czemu nawet poza kontekstem strony naszej biblioteki cyfrowej są one w pełni identyfikowalne.
Archiwizacja
Skaner Proserv ScannTECH 601i zakupiony w ramach projektu „NUKAT – autostrada informacji cyfrowej”. Umożliwia on skanowanie w rozdzielczości do 600 dpi w 24-bitowej głębi kolorów. Fot. Monika Konarska.
Równie duże postępy odnotowaliśmy w zakresie archiwizacji długoterminowej wykonanych skanów. Dotychczas, od samych początków digitalizacji w BUW-ie, wyniki pracy przechowywane były na płytach CD-R. Niosło to ze sobą dość znaczne ryzyko – trwałość płyt wypalanych obliczana jest na 8-10 lat (przy czym zależna jest od wielu czynników i wzrasta wraz z niewłaściwymi warunkami przechowywania), co więcej mnożyło liczbę przechowywanych nośników (ogółem nagranych zostało ponad 700 płyt), przy wzrastających rozmiarach plików bazowych (większa rozdzielczość, większa głębia kolorystyczna). Rozwiązaniem tego problemu, choć nadal niedoskonałym okazało się nagrywanie zeskanowanego materiału na dyski twarde. W wyniku samego projektu „NUKAT – autostrada informacji cyfrowej” powstało 98 dysków z plikami bazowymi – wykorzystywano przy tym nośniki o pojemnościach 1, 1,5 lub 2 TB. Przyjęto przy tym model przechowywania zbliżony do zalecanego w przypadku danych cyfrowych modelu „3-2-1”, tzn. przechowywanie dwóch identycznych kopii dysków – jednej w pomieszczeniach pracowniczych BUW, drugiej natomiast w skarbcu. Do skarbca również trafiły po przegraniu na dyski twarde płyty CD-R. Do pełnej realizacji modelu „3-2-1” brakuje więc nam jedynie trzeciej („3”) kopii na drugim („2”) nośniku w innej lokalizacji (to rzeczone „1” z nazwy). Co 5 lat odbywać ma się rewizja danych przechowywanych na dyskach i ich przegranie w celu zapewnienia bezpieczeństwa długoterminowego przechowywania danych cyfrowych.
Ustalenia i powstanie ORZE
Publikacja wykonana w projekcie „NUKAT – autostrada informacji cyfrowej” (Kurjer Warszawski, R. 87, 1905, nr 15). Proszę zwrócić uwagę na 24-bitową głębię koloru i układ 1 strona na skan.
Pewnym podsumowaniem doświadczeń wyniesionych z tego ogromnego projektu digitalizacyjnego było powstanie w roku 2012 uzgodnień dotyczących technicznych ram digitalizacji. W ramach procesu skanowania zakładały one konsekwentne trzymanie się zasady „jedna strona – jeden plik”. W samym projekcie bowiem ze względów oszczędnościowych (zlecenie digitalizacyjne kalkulowane było w liczbach wykonanych skanów) część dzieł mniejszych formatów zeskanowana została na zasadzie „dwie strony (rozkładówka) – jeden plik” rodziło to jednak pewne niepożądane konsekwencje (np. pierwsza i ostatnia strona czasopisma były połowami formatu części głównej). Ustalono również bazowe rozdzielczości (300 dpi, 400 dpi, 450 dpi) oraz rozdzielczość dla zbiorów specjalnych (600 dpi). Ustalono jako obowiązujący format DjVu dla plików prezentacyjnych oraz określono ramy archiwizacji plików bazowych i plików prezentacyjnych.
HC-PDF
Ostatnią – jak dotychczas – „rewolucją” (lata 2016-2017), którą już piszący te słowa miał okazję w znacznym stopniu współtworzyć – było przejście na publikowanie plików HC-PDF zamiast plików DjVu. Co spowodowało odejście od dotychczasowej tradycji kultywowanej we właściwie wszystkich polskich, akademickich bibliotekach cyfrowych? Głównym argumentem była troska o czytelnika. Format DjVu prócz swoich licznych zalet ma obecnie jedną zasadniczą wadę – jest coraz gorzej wspierany przez współczesne przeglądarki internetowe. W wielu przypadkach zmusza to użytkownika e-bUW do misternych kombinacji. Odpowiedzią na te problemy jest format HC-PDF. Obrazowo mówiąc jest to przeniesienie wszystkich zalet pliku DjVu do kontenera PDF dzięki czemu otrzymujemy pliki o porównywalnych rozmiarach jak pliki DjVu odczytywane przez wszystkie liczące się na rynku przeglądarki internetowe. Co istotniejsze istnieje dość prosty sposób produkowania plików HC-PDF z istniejących plików DjVu. Umożliwi to w przewidywalnej przyszłości konwersji całej biblioteki z formatu DjVu do PDF.
Publikacja w formacie HC-PDF (Bolesław Koskowski – Ostatni rozbiór Turcji). Wyglądem przypomina publikację DjVu natomiast jego wyświetlanie w nowoczesnych przeglądarkach nie wymaga instalowania wtyczki.
Samo jednak wprowadzenie HC-PDF do publikowania zdigitalizowanych materiałów bibliotecznych nie było procesem bezproblemowym. W trakcie testów okazało się, że warstwa OCR co prawda jest przenoszona do nowych plików, ale jedynie w zakresie podstawowego alfabetu łacińskiego (zakodowanych w standardzie ANSI). Przy charakterystyce naszych zbiorów zawierających teksty po polsku i w innych językach słowiańskich (zapisywanych zarówno łacinką jak i cyrylicą), jak też jidysz czy po hebrajsku (z własnym alfabetem) oraz we wszystkich właściwie językach zachodnioeuropejskich znacząco zmniejszałoby to wartość informacyjną takiej warstwy tekstowej. Co więcej pojawił się również problem z niewłaściwą lokalizacją tekstu na stronie (pola tekstowe, które miały odpowiadać znajdującemu się w warstwie graficznej zapisowi słowa dość znacznie odbiegały w rozmiarze od referencyjnego obszaru). Odpowiedzią na te trudności był skrypt przenoszący warstwę tekstową w prawidłowym kształcie z plików DjVu do nowych plików HC-PDF. Rozwiązywał on również w sposób prowizoryczny problem dołączania metadanych zewnętrznych do nowych plików PDF.
Dzisiejszy proces skanowania i przetwarzania plików w znaczący sposób odbiega już od swoich początków, chociaż nadal główną metodą kompresji plików bazowych (TIFF) pozostaje zastosowanie profili konwersji DjVu. Przede wszystkim konsekwentnie stosujemy zasadę „1 strona – 1 skan”, rozcinając skany stron podwójnych (z dopuszczalnymi wyjątkami w przypadku intencjonalnie zaprojektowanych dwustronicowych rozkładówek, map, tablic lub innych podobnych materiałów). Chęć oddania w jak najszerszym stopniu informacji o oryginale doprowadziła do zasady kadrowania z uwidocznieniem krawędzi. Jeśli chodzi o przetwarzanie, profil konwersji danej strony dobierany jest indywidualnie, w zależności od jej zawartości, tak aby przy zmniejszeniu rozmiaru pliku wynikowego zachować jak najdalej posuniętą wierność oryginałowi. Następnie wykonywane jest rozpoznawanie tekstu (tzw. OCR) za pomocą programu ABBYY FineReader i za pomocą skryptów powłoki Windows warstwa tekstowa dołączana jest do plików DjVu. Kolejną fazą jest łączenie publikacji w całość, dodawanie metadanych wewnętrznych oraz opcjonalne sporządzanie interaktywnych spisów treści (tzw. mapowanie – za pomocą programu Document Express). Ostatnią fazą jest konwersja pliku DjVu do formatu HC-PDF wraz z opisywanymi wyżej operacjami dotyczącymi przenoszenia warstwy tekstowej za pomocą skryptu pythonowego. Jak widać plik DjVu pozostaje wciąż centrum procesu kompresji i wykonywania plików prezentacyjnych, natomiast nie jest już widoczny dla czytelnika.
Co dalej?
Nasuwa się naturalne pytanie: „A co dalej?” Z pewnością ogrom publikacji w formacie DjVu przy coraz większych problemach ze wsparciem każe myśleć o ich konwersji do formatu HC-PDF. Coraz większe możliwości techniczne samych komputerów oraz rozwój szerokopasmowych połączeń internetowych skłania do refleksji nad publikowaniem jakiejś formy formatu graficznego (przy czym idealną sytuacją byłaby możliwość zachowania zalet formatów „kontenerowych”, tj. DjVu i PDF: tzn. warstwy tekstowej i ściśle związanych z plikami metadanych wewnętrznych). Rozmaitość zastosowań, do jakich można użyć publikowane w bibliotekach cyfrowych materiały jest również przesłanką do realizacji idei wieloformatowości. Być może szczególnie przy materiałach o dużych rozmiarach (mapy, plansze, plany) oraz rękopisach i starych drukach wskazane byłoby zastosowanie technologii IIIF. Stałym problemem pozostaje wiarygodność rozpoznawania tekstu – choć notujemy tutaj stały postęp techniczny, związany z rozwojem algorytmów sieci neuronowych i przetwarzania sygnałów – i tak w dalszym ciągu tylko żmudne, ręczne poprawianie warstwy tekstowej mogłoby przynieść całkowicie wiarygodne rezultaty. Tego rodzaju praca jednak, nawet jeśli ograniczałaby się do sprawdzania efektów rozpoznania maszynowego, nadal wydaje się przerastać nasze możliwości. Sporo zmian czeka nas w zakresie zabezpieczenia wykonanej już pracy – ulepszenia w archiwizacji być może doprowadzą wreszcie do realizacji modelu „3-2-1”, część materiałów zeskanowanych w początkach digitalizacji w BUW-ie z pożytkiem można by zeskanować jeszcze raz w dzisiaj akceptowanych parametrach.
Pewne jest jedno, nawet dzisiejsza, mocno niedoskonała forma bibliotek cyfrowych z pewnością oszczędza wielu ludziom (zarówno badaczom jak i amatorom) czasu i kosztów związanych z dojazdem do siedziby biblioteki i umożliwia lekturę materiałów trudno dotychczas dostępnych w komfortowych warunkach domowych. Ta idea, jak mniemam, od początku przyświecała pracom nad bibliotekami cyfrowymi – i choć zmieniają się możliwości techniczne – ona jedna w naszej pracy pozostaje stała.
Na podstawie relacji Elżbiety Arcipowskiej i Grzegorza Kłębka opracował Wojciech Oczkowski, ORZE
W cyklu na 10-lecie e-bUWu pisaliśmy już o:
Dziwnych rzeczach jakie można zobaczyć na skanach.
Prawie autorskim w pracy bibliotekarza cyfrowego.
Drodze książki w procesie digitalizacji
Przepisie na publikację w e-bUW-ie
O sprzęcie fotograficznym w digitalizacji
O tym, co zmieniało się w naszej pracy przez te 10 lat, w części 1 niniejszego wpisu.
W kolejnych wpisach:
Przekażemy trochę statystyk dotyczących e-bUW-u.
A na koniec zastanowimy się nad przyszłością e-bUW-u.