Bardzo ucieszyła mnie informacja o starcie projektu archiwistycznego mającego w założeniu opierać się na otwartych rozwiązaniach. Kudos!
Chciałem dorzucić do dyskusji kilka swoich uwag.
mikmach postawił bardzo słuszne pytanie o format, w którym będą przechowywane dane. bla z kolei zauważył, że bardzo ważną rzeczą jest kategoryzacja tych danych. Łącznie z głosem dPeS uważam te głosy za podstawowe dla całości przedsięwzięcia.
Dane są przecież w tym projekcie najważniejsze i odpowiedni dobór strategii ich digitalizacji umożliwi korzystanie z nich niezależnie od trendów w dziedzinie tworzenia oprogramowania. Sam dobór narzędzi programistycznych i aplikacji, które mają zostać przy ich pomocy stworzone jest już, śmiem to tak nazwać, wtórny po opracowaniu dokładnej specyfikacji działania cyfrowego systemu archiwalnego. IMHO specyfikacja ta powinna zawierać opis:
1. Struktury i formy gromadzonych danych (podstawowe dla dalszych działań).
2. Przewidywanych dróg obiegu danych (umożliwia zaplanowanie odpowiednich aplikacji klienckich i serwerowych).
3. Sposobu przeprowadzania digitalizacji (bardzo ścisły – określający możliwy do zastosowania sprzęt, parametry, z którymi należy dokonywać digitalizacji, sposób formułowania ewentualnego opisu).
4. Protokołów używanych w cyfrowych kanałach przetwarzania danych (umożliwia implementację niezależnych narzędzi do korzystania z zasobów archiwalnych).
5. Dokumentów zewnętrznych, na których opiera się specyfikacja, a które nie zostały włączone w jej treść aby uniknąć ich dublowania.
Wydaje mi się, że te kilka punktów wpasowuje się w ogólny plan działania zaproponowany przez dPeS.
Tyle tytułem pomysłów na ogólny kształt systemu, chciałbym się natomiast odnieść do propozycji użycia formatu png do gromadzenia zeskanowanych danych.
Pewne jest, że skanowanie będzie podstawą systemu.
png jest bardzo obiecujący jako format nieobarczony patentami niemniej jednak podobnie jak pozostałe formaty graficzne (pomijając możliwości stosowania takich czy innych przestrzeni kolorów, masek alfa itd.) służyłby do jednej rzeczy – przechowywania płaskiego obrazu strony fizycznego dokumentu. To oznacza, że aby w zeskanowanym dokumencie umieścić jego opis, czy np. jego tekst pozyskany np. metodą ocr należy użyć odpowiedniego formatu tzw. metadanych. Co do „słabego radzenia sobie png'a z danymi drukarskimi” uważam, że nie ma to najmniejszego znaczenia. Dla dzisiejszych skanerów (nie zanosi się na zmianę tego w najbliższej przyszłości) naturalną modelem kolorów jest model RGB. W przypadku większości skanerów model ten ograniczony jest przestrzenią zdefiniowaną profilem sRGB (niestety, jako, że jest to nieco „przyciasna” przestrzeń jak dla RGB). Dla „druku” z kolei przyjazny jest model CMYK (przestrzeń kolorów znów określona odpowiednim profilem) oraz modele wynikające z zastosowania poszczególnych farb drukarskich odpowiedniego systemu np. PANTONE. Konwersja z RGB do np. CMYK w przypadku przechowywania skanowanych dokumentów mijałaby się jednak z celem, gdyż taka konwersja mogłaby pociągnąć za sobą porzucenie lub degenerację części informacji o kolorze. Dlatego uważam, że przestrzeń RGB jest odpowiednia do przechowywania zeskanowanych danych.
Drugą sprawą, którą należy rozważyć poza otwartością danego formatu jest też jego ekonomiczność w porównaniu z pozostałymi formatami. Bardzo ważna jest przestrzeń, którą te same dane zajmują w pamięci masowej w różnych reprezentacjach. Do wyboru mamy formaty stratne i bezstratne. Główną zaletą bezstratnych jest dokładność, a wadą rozmiary. Odwrotnie jest w przypadku formatów stratnych. Z moich doświadczeń wynika, że do przechowywania zeskanowanych obrazów jak najbardziej nadają się formaty stratne o ile tylko próg określający odrzucanie części informacji jest odpowiednio ustawiony. Świetnie radzi sobie w takim wypadku np. JPEG2K, czy w ogóle formaty oparte na kompresji falkowej.
W końcu należy pamiętać, że często dokumenty archiwalne są wielostronicowe. To oznacza, że należy zachować przy digitalizacji również informację o stronach. Można ją umieścić w metadanych, można również wykorzystać natywne możliwości formatu. Możliwość przechowywania dokumentów wielostronicowych posiadają np. TIFF, PDF czy DjVu. TIFF jest formatem bezstratnym i potencjalnie wymagającym rozmiarowo. Poza tym umieszczanie w nim np. hiperlinków jest problematyczne. Z tej trójki PDF i DjVu mogą reprezentować wielostronicowe dokumenty, zawierać hiperlinki, spisy treści itp. Obydwa posiadają otwarte specyfikacje. Ich podstawową różnicą jest to, że PDF został stworzony przede wszystkim jako kontener dla poligrafii natomiast DjVu od początku był pomyślany jako format archiwizacyjny. Istotnie posiada on wiele zalet predestynujących go do takich zastosowań.
Nie chcę już przedłużać tego i tak długaśnego postu, ale konkludując chciałbym zaproponować właśnie DjVu jako format przechowywania zeskanowanych materiałów. Robię to tym chętniej, że istnieją narzędzia na licencji GPL pozwalające na tworzenie dokumentów DjVu i korzystanie z dobrodziejstw tego formatu.
