Montag, 20. Juli 2015

Konfigurierbarer TIFF-Validator in Arbeit…

Die bestehenden TIFF - Validatoren/Extraktoren, wie JHove und Co. sind zwar ganz nett, allerdings ist es schwierig unsere Policy abzufragen, sprich, welche Tags mit welchen Werten erlauben wir, welche sind Pflicht.

Dies war die Geburtsstunde für einen konfigurierbaren Validator. Die Regeln werden in einer einfachen Abfragesprache formuliert, die der Validator übersetzt und danach das TIFF entsprechend auswertet.

Es liegt noch etliche Arbeit vor uns, und einiges an Funktionalität fehlt noch. Dennoch möchten wir Euch auf das Tool hinweisen, damit ihr uns vlt. schon frühzeitig Rückmeldungen geben könnt.

Den Quellcode gibt es hier: https://github.com/SLUB-digitalpreservation/fixit_tiff/tree/master/checkit, der Code steht unter der gleichen Lizenz, wie der der LibTIFF (sh. http://www.libtiff.org/)

Hier ein Beispiel für eine einfache Abfrage:

# tag; required; values
#
# works as whitelist
# * tag: any tag number in TIFF
# * required: mandatory | optional | depends( $tag.$value ) 
# * values: range($start, $end) | logical_or( $a, …) | only($a) |any

# This defines a sample config for baseline tiffs
# Remember, because it works as whitelist for each required tag we need an
# entry here

#####
# Required Baseline Tags
#####

# 256 0100 ImageWidth The number of columns in the image, i.e., the number of pixels per row.
256; mandatory; range(1, 4294967295)

# 257 0101 ImageLength The number of rows of pixels in the image.
257; mandatory; range(1, 4294967295)

# 258 0102 BitsPerSample Number of bits per component.
##########################258; mandatory; logical_or(8,16)
# Bitonal is optional, grey & RGB is mandatory. If 262 AND 258 exist, then the values need to be in the specified range.
258; depends(262.2); only(8,8,8)
258; depends(258.any); logical_or(4, 8)

# 259 0103 Compression Compression scheme used on the image data 
### (1 means no compression)
259; mandatory; only(1)

# 262 0106 PhotometricInterpretation The color space of the image data.
### 2 means RGB, 0 and 1 means bilevel or grayscale, 0 is unusual, 3 is Palette Color (FORBIDDEN), 4 is Transparency Mask (FORBIDDEN)
262; mandatory; range(0, 2)

# 273 0111 StripOffsets For each strip, the byte offset of that strip.
273; mandatory; any

# 277 0115 SamplesPerPixel The number of components per pixel.
### if RGB then 3 else 1
### Even though Baseline TIFF allows for SamplesPerPixel>3, we do NOT allow this for long term archival.
277; depends(262.2); only(3)
277; depends(262.1); only(1)
277; depends(262.0); only(1)

# 278 0116 RowsPerStrip The number of rows per strip.
278; mandatory; range(1, 4294967295)

# 279 0117 StripByteCounts For each strip, the number of bytes in the strip after compression.
279; mandatory; range(1, 4294967295)

# 282 011A XResolution The number of pixels per ResolutionUnit in the ImageWidth direction.
282; mandatory; range(300, 1200)

# 283 011B YResolution The number of pixels per ResolutionUnit in the ImageLength direction.
283; mandatory; range(300, 1200)

# 296 0128 ResolutionUnit The unit of measurement for XResolution and YResolution. 1 = No absolute unit of measurement. 2 = Inch. 3 = Centimeter. Default: 2
296; mandatory; only(2)


Sonntag, 31. Mai 2015

Digital(isiert)e Dokumente sind lebende Daten – Nachlese zum 104. Bibliothekartag


Quelle: openclipart, public domain

Digital ist anders


Auf dem Bibliothekartag in Nürnberg blieb mir ein Vortrag besonders im Gedächtnis, da er den Finger in die Wunde legte. Klaus Kempf von der Bayrischen Staatsbibliothek München stellte in seinem Vortrag "Data Curation oder (Retro)Digitalisierung ist mehr als die Produktion von Daten" die berechtigte Frage "Jetzt haben wir alles digitalisiert – und dann?".

Der Unterschied zwischen alten Büchern, die in den Regalen von Bibliotheken die Zeiten verschlummern und digital(isiert)en Dokumenten zeigt sich in zwei wesentlichen Punkten:

  1. digitale Objekte verschwinden schnell und dann vollständig, während Bücher nur ganz, ganz langsam zu Staub zerfallen
  2. digitale Objekte erlauben einen unvorstellbaren Mehrwert durch ihre digitale und damit verknüpfbare und reinterpretierbare Identität

Digital ist billiger


Durch die Loslösung des Inhalts vom Medium können Bücher in völlig neue Kontexte gesetzt werden. Wurde im ersten Schritt das Buch digitalisiert, sprich als Bilddatei zugänglich gemacht, so erreichte man eine Schonung des Originals durch die beliebig oft und in unveränderter Qualität ermöglichte digitale Kopie. 

Auch wenn die Digitalisierung und die damit verbundenen Aufwände der sicheren Speicherung anfangs kostenintensiver als die klassische Bestandsbewahrung von totem Baum ist, Kempf erwähnte Kostenfaktor von 1:8, so zeigen die Nutzungszahlen der Digitalisate, daß diese Kosten mehr als gerechtfertigt sind. Denn vorher war der Zugriff auf das gedruckte Exemplar schlicht nicht zu stemmen, von den Beschädigungen des Originals bei derart hohen Zugriffen nicht zu reden.

Wenn 2014 zB. knapp 3 Millionen Zugriffe auf die Digitalen Sammlungen der SLUB Dresden gezählt werden zeigt dies, wie sich der Zugriff auf die Digitalisate mittlerweile etabliert hat. Für Wissenschaftler und andere Interessierte ist es nicht mehr notwendig sich die Mühe zu machen monatelang in den Lesesälen von Archiven und Bibliotheken herumzutreiben. Sie können bequem über Internet recherchieren und direkt oder über Portale, wie die der Deutschen Digitalen Bibliothek oder Europeana auf zusammengehörige aber in Europa verstreute historische Materialien zugreifen.

Auch dies ein Vorteil, den Bibliotheken auf ihre Seite der Waagschale packen sollten.

Digital wird immer besser


Wie Kempf in seinem Vortrag gut dargestellt hat, sind digitale Medien als lebende Dokumente zu behandeln. Entweder man pflegt sie – oder sie sterben und dann dauerhaft und ohne Spuren zu hinterlassen.

Der Bereich der digitalen Langzeitarchivierung versucht, diese Daten so zu sichern, daß sie auf lange Sicht verfügbar gehalten werden können. Aber dies ist nur der eine Aspekt, vergleichbar mit modernen medizinischen Geräten, die zwar in der Lage sind, den menschlichen Körper warm zu halten und vor dem Verfall zu bewahren – nicht aber das Leben lebenswert machen (im eigentlichen Sinn)

Doch digitalen Dokumenten wohnt ein "Mehr" inne. Wie oben erwähnt, war der erste Schritt die Digitalisierung. Doch welche neuen Möglichkeiten ergeben sich, wenn man diese Scans weiter veredelt? Kommt anfangs eine OCR-Variante hinzu, kann man die Digitalisate nun volltext-durchsuchbar gestalten. Ist der Volltext vorhanden, kann man diesen Tiefenerschliessen. Aus dem Buch, welches über Jahrhunderte im Magazin schlummerte, wurde nun ein Bestseller, der die Geheimnisse seiner Zeit enthüllt. Von einem Buch zum anderen über die dort jeweils verknüpften Akteure, Orte oder Zeiten springen, oder breite statistische Untersuchungen über die Entwicklung der Sprache in bestimmten Regionen sind jetzt ganz neue Sachverhalte untersuchbar.

Data curation, aktives Managment des digitalen Bestandes und das Bewusstsein daß es sich um lebende Dokumente handelt, ist nach Kempf nunmehr vorrangige Aufgabe von (wissenschaftlichen) Bibliotheken.

Digital erfordert Qualität


Für mich bleibt daher als Fazit, es geht bei Digitalisierung nicht um Quantität, sondern um Qualität. Es nützt nichts *nur* zu Digitalisieren. Aus Digitalisierung folgt Langzeitarchivieren. Aus Langzeitarchivierung folgt Langzeitverfügbarkeit und aus Langzeitverfügbarkeit folgt Anreicherung. Und aus Anreicherung folgt Qualität. Und Qualität fängt bei der Quelle an.

Wenn ich schlecht scanne, reicht es nicht für gute OCR. Wenn ich keine gute OCR habe, reicht es nicht für gute Volltexte. Wenn ich keine guten Volltexte habe, reicht es nicht für eine Tiefenerschliessung. Wenn ich keine gute Tiefenerschliessung habe, kann ich Dokumente nicht gut anders verknüpfen…

Daher: Alles was wir aus der Digitalisierung bisher lernen konnten –  es gibt immer neue Nutzungsmöglichkeiten, die sich aber erst manifestieren, wenn man den Möglichkeitenraum öffnet.

Bibliotheken sind in dem Sinne nicht mehr nur Bücherbewahrer sondern Datenveredler und sollten sich auch dazu bekennen.

Samstag, 23. Mai 2015

Vertrauensfrage

Was ist Vertrauen?


CC-SA-3.0, von Dellex, Quelle: Wikimedia
In der Vorbereitung für einen Vortrag auf dem Bibtag2015 habe ich mich intensiv mit der Frage auseinandergesetzt, wie vertrauenswürdig unsere Technik und unsere Prozesse sind, wenn wir diesen wertvolle digital(isierte) Dokumente anvertrauen.

Immerhin, ein kleiner Fehler und ganze Bestände können vernichtet sein. Im digitalen geht das oft schneller, unbemerkter und mit deutlich fataleren Folgen, als in der materiellen Welt. Ein versehentliches "rm -Rf /" löscht dann in Sekunden mal gleich ein ganzes Dateisystem.



Vertrauen ist nicht wissen – und mehr als glauben


Wenn wir unseren Prozessen vertrauen, dann, weil unsere Erfahrung gezeigt hat, daß diese auch in Krisensituationen funktionieren. Wenn wir unserer Software vertrauen, dann weil sie sich so verhält, wie wir das erwarten.

Wenn wir anderen Personen vertrauen, dann umso mehr, je länger wir mit dem Anderen verläßlich zusammenarbeiten.

Wenn wir Neuem begegnen, dann schöpfen wir Zutrauen und mit der Zeit mehr Vertrauen durch dessen Offenheit.

Offene Personen, offene Prozesse und offene Technologie sind Katalysatoren Vertrauen schneller zu erreichen.

Aufbau von Vertrauen erfolgt also durch
  • Vorhersagbarkeit
  • Verlässlichkeit
  • langjährige Erfahrung
  • Offenheit
Im Bereich der digitalen Langzeitarchivierung spielt Vertrauen eine zentrale Rolle. Wir wollen ja gerade unsere wertvollen Dokumente für kommende Generationen nutzbar halten und sind auf vertrauenswürdige Archive angewiesen.

Vertrauenswürdige Software

Da ein digitales Langzeitarchiv mehrere Komponenten umfasst, müssen wir all diese Komponenten bezüglich ihrer Vertrauenseigenschaft untersuchen.

Eine zentrale Rolle in digitalen Langzeitarchiven nimmt das Thema Software ein. Dies reicht von Betriebssystem, über Zugriffskomponenten, Datenbanken bis hin zur Steuerungssoftware (Archivsoftware) für die Realisierung der OAIS-Funktionalitäten.

Auch hier gelten og. Punkte:

  • Verhält sich die Software konsistent?
  • Ist die Software sicher? Und tut sie, was sie soll?
  • Ist sie über die Jahre stabiler geworden?
  • Wird sie weiterentwickelt?
  • Können wir "hineinschauen"?

Freie Software hat hier den Charme, daß sie durch ihre Offenheit ermöglicht, daß wir die Arbeitsweise besser verstehen, Fehler finden und ggf. beseitigen können.

Doch reicht unser Blick? Ist es ausreichend auf unsere Erfahrung mit der Software zu vertrauen? Sollten wir es lieber auch mal prüfen, wenn die Software meldet, sie hätte erfolgreich etwas ins Archiv gesichert? Ist frei einsehbarer Quellcode genug?

Nach einiger Erfahrung hier im Team, müssen wir diese Fragen mit einem klaren Nein! beantworten (auch bei Verwendung freier Software nicht, dies hat ua. auch mit dem Stichwort Komplexität zu tun).

Es ist notwendig, über kleine Helferlein stichprobenartig nachzuprüfen, daß unsere Erwartungen an Software erfüllt sind.

Wir haben im Laufe der Zeit einige Hilfsprogramme entwickelt, die unabhängig von der Archivsoftware Prüfungen vornehmen, zB.:

  • Hat jedes Archivpaket auch alle Dateien?
  • Sind wirklich alle Kopien identisch?
  • Funktioniert die Web-Schnittstelle nach dem Update noch wie erwartet?
  • Landen alle Archivpakete tatsächlich auf Band?
  • Wurde die Prüfsumme korrekt berechnet? Oder ist das Programm fehlerhaft?

Vertrauenswürdige Hardware


Auch bei der Hardware ist es sinnvoll, unabhängige Pfade und Prüfungen einzubauen.
Wie schnell kann ein Treiberproblem Teile des Archivs gefährden? Was, wenn das Netzwerk ausfällt? Was wenn Puffer voll laufen?

Auch hier haben wir im Laufe der Zeit Helfer gebaut und uns notiert, was wir bei der nächsten Hardwareablösung anders konzipieren würden:
  • Mindestens ein Kopienpfad über alternative Hardware (Storage)
  • Stete Mitspeicherung spezieller Monitoringdateien parallel zu den Archivpaketen um frühzeitig Fehler zu entdecken
  • Anbindung an Monitoring-Systeme
  • Prüfung von Checksummen nach jedem Kopiervorgang

Vertrauenswürdige Archive

Ein Archiv ist dann umso vertrauenswürdiger, wenn es sich dem Prinzip Offenheit und Peer Review (durch andere LZA-Kundige) verpflichtet fühlt.

Die bestehenden Zertifizierungsangebote Data Seal of Approval und nestor-Siegel unterstützen dieses Prinzip, da sie über ihren Kriterienkatalog eine Offenlegung der Dokumentation über Organisation, Prozesse, Umgang mit den digitalen Objekten und Technologien des jeweiligen Archives verlangen und damit Archive vergleichbarer machen.


Dienstag, 9. Dezember 2014

Verlustfreie Videocodecs in der Langzeitarchivierung – Ein Vergleich

Verlustfreie Videocodecs haben den Charme, daß man zum einen sein Videomaterial für die digitale Langzeitarchivierung normalisieren kann und zum anderen, daß bei Formatmigrationen eine automatische, pixelgenaue Inhaltsprüfung die korrekte Migration vereinfacht.

Hinzu kommt, daß sich das digitale Videomaterial bei den Formatwandlungen nicht weiter verschlechtert.

Für den Test habe ich den Trailer zum Film "Sentinel" verwendet. Der Film von der Blender Foundation ist frei unter Creative Commons erhältlich und ermöglicht daher jedem die Testergebnisse zu verifizieren und an eigene Tests anzupassen.

Der Trailer war zum Zeitpunkt des Testes nur als DivX-HD verfügbar, so daß die y-Auflösungen von 1080 Pixeln mit Vorsicht zu genießen sind, da das Ursprungsmaterial dabei hochskaliert wurde.

Im folgenden die Ergebnisse (auf Megabytes gerundet):


Codec Auflösung



1080 720 576
Orig DivX_Plus 27


FFV1 v1
402 228 160
FFV1 v3 2pass 333 198 139
FFV1 v3
360 215 153
h264lossless 432 240 168
h264
20 11 7,3
mjp2000
463 261 183
mpeg2
24 11 7,2

MPeg2 läuft außer Konkurrenz mit, da nach der Kodierung deutliche Artefakte sichtbar sind.

Hier nochmal die Werte normiert auf den jeweils besten Kompressionswert:


Codec Auflösung



1080 720 576
Orig DivX_Plus 27


FFV1 v1
20 21 22
FFV1 v3 2pass 17 18 19
FFV1 v3
18 20 21
h264lossless 22 22 23
h264
1 1 1
mjp2000
23 24 25
mpeg2
1 1 1

Wie man erkennt, brauchen die Lossless Codecs im Schnitt die 20-fache Speichermenge, wobei sich das Verhältnis bessert, je höher die Auflösung des Quellmaterials wird. Im Test ist außerdem aufgefallen, daß Motion Jpeg2000 (mjp2000) mit Abstand die höchste Rechenzeit an den Tag legte, während FFV1 das Videomaterial nahezu in Echtzeit kodierte.

In meinen Augen sollten sich die Langzeitarchive bemühen, die Kodierungseffizienz der lossless-Codecs durch Förderung fähiger Entwickler zu steigern. Wenn man zB. FFV1 v1 mit FFV1 v3 vergleicht, so wurde die Kodierungseffizienz um nahezu 10% gesteigert.

Trotz des um ca. Faktor 20 höheren Speicherplatzverbrauchs von lossless Codecs gegenüber verlustbehafteten Verfahren würde ich erstere bevorzugen. Auch wenn noch Tests notwendig sind, die die Bitfehleranfälligkeit der verschiedenen Codecs miteinander vergleichen, so kann man festhalten, daß zumindest die Entwickler von FFV1 sich bereits Gedanken dazu gemacht haben, wie man die Auswirkung dieser Fehler begrenzen kann

Script


Das Script für den Test ist relativ schnell geschrieben:

#!/bin/bash
# tests some codecs and reduced screen sizes
# orig is: Sintel_Trailer.1080p.DivX_Plus_HD.mkv
# from  http://download.blender.org/durian/trailer/
orig=Sintel_Trailer.1080p.DivX_Plus_HD.mkv
for scanlines in 576 720 1080; do
 call="ffmpeg -i $orig -acodec copy -vf scale=-1:$scanlines -y "
 codec=ffv1; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=ffv1; variant=v3slices; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 # ffmpeg -i  -threads 8 -an -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 1 -passlogfile my_passlog 
 #ffmpeg -i  -threads 8 -acodec copy -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 2 -passlogfile my_passlog 
 # 
 codec=ffv1; variant=v3slices2pass; $call -an -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 1 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 rm -f Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=ffv1; variant=v3slices2pass; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 2 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=mpeg2video; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=dirac; variant=standard; $call -threads 8 -g 1 -c:v libschroedinger -qscale:v 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=h264lossless; variant=standard; $call -threads 8 -g 1 -c:v libx264 -preset fast -qp 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=jpeg2000; variant=standard; $call -threads 8 -g 1 -c:v libopenjpeg Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=h264lossy; variant=standard; $call -threads 8 -c:v libx264 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
done
rm -f log.*.log


Weiteres


* Infos zu Vor- und Nachteilen von FFV1 und Motion JPeg2000: https://groups.google.com/forum/#!topic/archivematica/HulV96gJ0go
* Evaluation von FFV1: http://web.archiveorange.com/archive/v/4q4BhyAYa6Fk89AqurTY
* Weiterer Vergleich von FFV1: http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ffv1_sizediff-mthk-yuv.html

Dienstag, 7. Oktober 2014

Statt robuster, einfacher Dateiformate, lieber starke Kompression und Vorwärtsfehlerkorrektur?

Gezielte Redundanz?

Quelle: Dt. Fotothek


Auf der DV-Tagung der Max-Planck-Gesellschaft 2014 kam während eines Vortrages eine interessante Frage auf: „Warum nicht bestmögliche Kompression verwenden und das komprimierte Objekt dann mit gezielter Vorwärtsfehlerkorrektur behandeln?

Die Idee hat was. Hier ein paar der gesammelten Argumente pro und contra:

Pro

  • Spart Plattenplatz zumindest bei stark redundanten Dokumenten, wie zB. Videomaterial
  • An den Schutzgrad anpassbare Fehlerkorrektur. Wenn Material plötzlich besonders gesichert werden muss, dann kann man den Schutzgrad individuell erhöhen
  • Gerade für Objekte, für die nur Bitstream Preservation in Frage kommt, kann individuellerer Schutzgrad festgelegt werden
  • Zahl der Kopien kann ggf. auf zwei reduziert werden
  • Redundanz wird zielgerichtet ausgenutzt

Contra

  • erhöhter Aufwand beim Erstellen und Prüfen der Vorwärtsfehlerkorrektur
  • es ist immer "Auspacken" notwendig um auf die Inhalte zuzugreifen
  • Das Verpacken ist eine zusätzliche Fehlerquelle
  • Kompression und Vorwärtsfehlerkorrektur sind sehr rechenaufwändig
  • Funktioniert nur, wenn sich durch Kompression mehr an Bits einsparen lässt, als für die angestrebte Fehlerkorrektur notwendig ist
  • Für die richtige Auswahl des Schutzes sollte Bitfehlerverteilung bekannt sein
  • Komplexität erschwert das Verständnis des Inhaltes

Eine kleine Rechnung


Nehmen wir mal als Beispiel einen klassischen Buch-Scan in 300dpi. Als unkomprimiertes Bild (mit 1717x1027 Pixeln) im TIFF 6.0 baseline belegt es 31MB.

Mit jpeg2000 baseline ist das Bild auf 17MB (verlustfrei) eingedampft (PNG 18MB). Damit stünden 31-17=14MB für künstliche Redundanzen zur Verfügung.

Unter Verwendung von vdmfec wäre es beispielsweise möglich, diese Redundanzen hinzuzufügen. Mit den Default Werten von n=18 und K=14 und der  eingestellten Blockgröße von 1024*1024Bytes=1MB würden n=18 Blöcke für jeden der K=14 Eingabeblöcke geschrieben, es könnten also n-K=4 aus jeder der n-Blöcke verloren gehen.

Für das obige Bild würden sich dann 22MB Speicherplatz für die gesicherte Fassung ergeben.

In dem Fall ließe sich eine Ersparnis von 31-22=9MB erzielen und das Bild wäre trotzdem gegen Blockverluste geschützt.

Leider kodiert vdmfec nicht die Parameter bei der Erstellung der fehlerkorrigierten Datei mit. Welche Vorwärtsfehlerkorrekturprogramme bzw. -formate sinnvoll wären,  wäre dann aber einen eigenen Beitrag wert.

Montag, 1. September 2014

Dateiformat-Explosion

Vorwort


Zum Bibliothekartag 2014 gab es im Nachtrag zu unserem Vortragsblock eine rege Diskussion darüber, ob es sinnvoll ist, erst einmal alle Dateien in ein Langzeitarchiv aufzunehmen und sich später Gedanken darüber zu machen, wie man deren Langzeitverfügbarkeit z. B. durch Formatmigration sicherstellt.

Ich habe viel recherchiert, aber wenig belastbare Zahlen gefunden. Ein guter Indikator könnten die Signaturen für DROID sein, einem Programm zur Ermittlung des Datenformates unbekannter Dateien.

Auf Pronom findet man 77 Versionen von 08-2005 bis 07-2014, von ehedem 766 bis heute 1.459 von DROID unterstützten Signaturen.

Alternativ könnte man die Datenbanken des Unix-Befehls file (http://www.darwinsys.com/file/) heranziehen. Auf ftp://ftp.astron.com/pub/file/ findet man Versionen von 08-2008 bis 06-2014.

Eine andere Möglichkeit wäre, die bei der IANA registrierten MIME-Types (zur Zeit 1.087 verschiedene Signaturen) heranzuziehen: http://www.iana.org/assignments/media-types/media-types.xhtml

Außerdem wurde ich noch auf http://fileformats.archiveteam.org/wiki/Main_Page aufmerksam gemacht.

Leider gibt es zu den letzten beiden Links keine auswertbare Timeline.

Was uns 'file' verrät


Wir können annehmen, dass sowohl bei 'file' als auch bei DROID, die Signaturen in gewisser Weise die Dateiformate enthalten, die auch weit verbreitet sind. Wie stark wissen wir nicht, aber wenn sie total unbedeutend wären, hätte sich keiner die Mühe gemacht, für diese Signaturen zu erstellen.

Wir können ferner annehmen, dass nach einer gewissen Einschwingzeit die Zahl der Dateiformate in diesen Signatur-Datenbanken der Anzahl der tatsächlich verbreiteten Dateiformate entspricht.

Im Folgenden das Diagramm der Entwicklung der Dateiformate basierend auf der file Magic Bytes Datenbank von Ende 1999 bis Mitte 2014.

Count of different fileformats based on magic bytes database of file, 08/2014, Andreas Romeyke

Als Grundlage für das Diagramm diente das GIT-Repository von file, genauer das Verzeichnis 'magic/Magdir'. Über die Tags extrahierte ich alle Versionen des Verzeichnisses und ließ das folgende Script die dem Diagramm zugrunde liegende CSV-Datei erstellen:


#!/bin/bash
echo "#version, date, group, count"
for version in *;do
  for sub in $version/magic/Magdir/* ; do
    group=$(basename $sub); 
    count=$(cat $sub | grep "^0" | wc -l);
    date=$(cd $version; git log --name-status --date=raw \
    --pretty='format:commit,%ae,%ai,%ce'| cut -d "," -f 3| head -n 1|\
    cut -d " " -f 1)
    echo "$version, $date, $group, $count"; 
  done ;
done


Sehr überraschend für uns war der nahezu lineare Verlauf der Formatvielfalt. Um auszuschließen, dass dies andere Ursachen hat, war es notwendig, eine zweite, von file unabhängige Quelle heranzuziehen.

DROID/Pronom als Quelle


Die Entwickler von DROID haben, wie oben bereits angedeutet, ihre Signaturfiles von Version 1 bis zur aktuellen Version 77 online angeboten.

Pronom hat als Projekt das Ziel, für Langzeitarchive eine verlässliche Quelle für Dateiformate, Signaturen und zugeordnete Programme bereitzustellen. DROID übernimmt als Programm die Aufgabe der Identifikation unbekannter Formate.

Durch den strukturierten Aufbau der Signaturdateien ist eine automatische Auswertung möglich.

Im Folgenden ist die Anzahl der verschiedenen Dateiformate über die Zeit zu sehen:


Count of different fileformats based on DROID signatures, 08/2014, Andreas Romeyke
Auch hier ergibt sich ein nahezu linearer Zuwachs, spätestens ab Mitte 2010.

Da erst in späteren Signaturen ab ca. 2009 auch MIME-Types hinterlegt wurden, sieht die Entwicklung der einzelnen Kategorien im folgenden Diagramm etwas anders aus:

Count of different fileformats per category, based on DROID signatures, 08/2014, Andreas Romeyke

Hier noch das Shell-Script:

#!/bin/bash
echo "#version, date, application, text, images, audio, video"
for i in droid/DROID_SignatureFile_V*.xml; do
  version=$(echo $i |sed -e "s/.*_V\([^.]\+\).*/\1/" );
  date=$(cat $i | grep -m 1 "DateCreated=" |\
  sed -e "s/.*DateCreated=\"\(....-..-..\).*/\1/" );
  echo -n "$version, $date,"
  for category in application text image audio video; do
    count=$(xmlstarlet sel -t -v\
    "//_:FileFormat[contains(@MIMEType, \"$category/\")]/@Name" $i| \
    sort | uniq | wc -l)
    echo -n "$count,"
  done;
  echo
done | sort -n 

Wenn pro Jahr also 90 neue Dateiformate…


Die Anzahl der  Dateiformate wächst nahezu linear. Pro Jahr kommen im Schnitt 90 neue Dateiformate hinzu, die immerhin eine solche Verbreitung erfahren, dass sie in den Signatur-Datenbanken Widerhall finden.

Wenn wir in Zeiträumen von 50 Jahren denken, haben wir knapp 5000 Formate zu behandeln.

Wer alles in sein Langzeitarchiv hineinkippt, was ihm seine Nutzer anbieten, wird daher in Zukunft kaum die Ressourcen haben, Spreu und Weizen zu trennen und eine Langzeitverfügbarkeit sicherzustellen.

Die Entwicklung zeigt, dass dringend eine Spezialisierung der Langzeitarchive notwendig ist, um Wissen über Formate aufzubauen und sich gegenseitig zu unterstützen.

Es zeigt auch weiterhin, dass Nutzer der Archive über die Problematik aufgeklärt werden müssen.

Freitag, 15. August 2014

Was vom Buche übrig blieb

Diese Frage stellt sich, wenn ein digital archiviertes Buch nach Jahrzehnten der Aufbewahrung hervorgeholt wird.

Old book bindings.jpg
"Old book bindings" by Tom Murphy VII - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

 

Leidvolle Erfahrung


Vor einigen Jahren war es üblich, Scans aus Speicherplatzgründen ausschliesslich in s/w abzuspeichern. Als dann die Archive und Bibliotheken diese Digitalisate wieder hervorholten, um diese einer OCR-Erkennung zuzuführen, mussten sie feststellen, dass das pure Speichern als unbereinigte s/w-Grafik zwar noch reichte, damit ein Mensch den Text erkennen konnte. Doch die Qualität reichte nicht aus, um mit OCR-Programmen vernünftige Ergebnisse¹ zu erzielen.

Wer heutzutage digitalisiert, kann von diesen leidvollen Erfahrungen profitieren. Die Deutsche Forschungsgemeinschaft hat die best-practices gesammelt und Empfehlungen für die Digitalisierung herausgegeben.

¹(sh. http://www.landesarchiv-bw.de/sixcms/media.php/120/Werkheft_Staatl_Archiv.pdf, Artikel "Automatische Texterkennung bei digitalisiertem Archiv- und Bibliotheksgut", von Thomas Fricke und Gerald Maier, S.201ff.)

Langzeitarchivierung, für wen eigentlich?

Langzeitarchivierung ist ebensowenig ein Selbstzweck, wie es die Digitalisierung von historischen Beständen ist. In beiden Fällen ist der Zweck, die historischen Beständen den Nutzern zur Verfügung zu stellen. Nicht umsonst wird zunehmend statt von Langzeitarchivierung eher von Langzeitverfügbarkeit gesprochen.

Ein notwendiger Blick in die Glaskugel


Um sicherzustellen, dass archivierte Dokumente tatsächlich für die Nutzer nutzbar sind, muss bereits vor dem ersten Einstellen der Dokumente ins Langzeitarchiv überlegt werden, welche möglichen Nutzungsszenarien für diese in Frage kommen könnten.

Aus dem einleitenden Beispiel wird klar, dass bestimmte Eigenschaften eines Dokumentes für bestimmte Nutzungsarten eine signifikante Rolle spielen. Für die Möglichkeit der OCR-Nutzung wären dies bei den Scans hinreichender Kontrast, ausreichende Auflösung (300-400dpi) und die Unterscheidbarkeit zwischen eigentlicher Schrift und irgendwelchen Flecken.

Wir haben bei der Bestimmung dieser notwendigen Eigenschaften erst durch den Blick aus der Nutzerperspektive auf ein bestimmtes Nutzungsszenario herausgefunden, dass wir die eine oder andere Eigenschaft beinahe übersehen hätten.

Für unsere Scans historischer Schriften haben wir im Moment folgende Nutzungsarten gefunden, die vielleicht für den Einen oder Anderen eine erste Anregung darstellen können:

  • (optische) Lesbarkeit
  • visuelle Zuordnung zum Original
  • originalgetreue Reproduktion
  • (re-)OCR
Die (optische) Lesbarkeit ist nichts Anderes, als dass der Nutzer den Text des Scans entziffern kann. In dem Fall würde oft eine Auflösung von 100dpi reichen, der Scan könnte in s/w vorliegen und Farbe dürfte keine Rolle spielen.

Die visuelle Zuordnung zum Original meint, dass man irgendwie einschätzen kann: "Ah, das ist Fraktur, die Grafiken sind barocke Kupferstiche und das Wappen sieht irgendwie sächsisch aus." In dem Fall muß man nicht unbedingt die Schrift entziffern können. Man könnte sich ein Vorschaubildchen zu einem Buch vorstellen, welches einen ersten Eindruck vermittelt.

Die originalgetreue Reproduktion sollte das Buch bestmöglich wiederherstellbar machen. Für Drucke ist eine Auflösung von mindestens 600dpi notwendig, die Farben und die Abmessungen sollten dem Original entsprechen und Vergrößerungen eventuell möglich sein.

Für OCR wäre es dagegen sinnvoll, Auflösungen zwischen 300 und 400 dpi zu haben und eine Farbabbildung, die ein digitales Entfernen von Flecken und anderen Störungen ermöglicht.

Wenn man für die einzelnen Nutzungsszenarien die damit einhergehenden Eigenschaften bewertet, gegeneinander abwägt und nach den Punkten
  • unbedingt zu erhalten,
  • möglichst zu erhalten,
  • nice to have,
  • nicht erhaltenswert
sortiert, erhält man eine Liste der signifikanten Eigenschaften.

Diese Eigenschaften sollten bei Erhaltungsmaßnahmen, wie zB. Formatmigration (zB. von TIFF nach JPEG2000) entsprechend berücksichtigt werden.