ICC Farbprofile von TIFFs prüfen

Kaputte ICC Einbettung in TIFFs

Bei einigen TIFFs sind uns Fehler aufgefallen, weil die Größenangaben des ICC Profils nicht mit denen des TIFFs übereinstimmten.

Aus diesem Grunde hatten wir checkit_tiff eine Prüfroutine für die ICC-Header verpasst.

Hier ein Beispiel einer Ausgabe:


$ ./checkit_tiff -c /tmp/00000056.tif ../example_configs/cit_tiff6_baseline_SLUB.cfg

'./checkit_tiff' version: master     revision: 85 licensed under conditions of libtiff (see http://libtiff.maptools.org/misc.html) cfg_file=../example_configs/cit_tiff6_baseline_SLUB.cfg tiff file=/tmp/00000056.tif check if all IFDs are word aligned check if only one IFD exists check if tags are in ascending order check if all offsets are used once only check if all offsets are word aligned check if tag 306 (DateTime) is correct check if tag 34675 (ICC Profile) is correct ==> tag 34675 (ICC Profile) should have value pointing to valid ICC profile, but has value (values or count) preferred cmmtype ('APPL') should be empty or (possibly, because ICC validation is alpha code) one of following strings: 'ADBE' 'ACMS' 'appl' 'CCMS' 'UCCM' 'UCMS' 'EFI ' 'FF  ' 'EXAC' 'HCMM' 'argl' 'LgoS' 'HDM ' 'lcms' 'KCMS' 'MCML' 'WCS ' 'SIGN' 'RGMS' 'SICC' 'TCMM' '32BT' 'WTG ' 'zc00' check if tag 256 (ImageWidth) has value in range 1 - 4294967295 check if tag 256 (ImageWidth) has valid type check if tag 257 (ImageLength) has value in range 1 - 4294967295 check if tag 257 (ImageLength) has valid type check if tag 258 (BitsPerSample) has these 3-values: 8, 8, 8 check if tag 258 (BitsPerSample) has valid type check if tag 259 (Compression) has value check if tag 259 (Compression) has valid type check if tag 262 (Photometric) has value in range 0 - 2 check if tag 262 (Photometric) has valid type check if tag 273 (StripOffsets) exists check if tag 273 (StripOffsets) has valid type check if tag 277 (SamplesPerPixel) has value check if tag 277 (SamplesPerPixel) has valid type check if tag 278 (RowsPerStrip) has value in range 1 - 4294967295 check if tag 278 (RowsPerStrip) has valid type check if tag 279 (StripByteCounts) has value in range 1 - 4294967295 check if tag 279 (StripByteCounts) has valid type check if tag 282 (XResolution) has value in range 300 - 1200 check if tag 282 (XResolution) has valid type check if tag 283 (YResolution) has value in range 300 - 1200 check if tag 283 (YResolution) has valid type check if tag 296 (ResolutionUnit) has value check if tag 296 (ResolutionUnit) has valid type check if tag 254 (SubFileType) has value check if tag 254 (SubFileType) has valid type check if tag 266 (FillOrder) has value check if tag 266 (FillOrder) has valid type check if tag 271 (Make) has  value matching regex '^[[:print:]]*$' check if tag 272 (Model) has  value matching regex '^[[:print:]]*$' check if tag 274 (Orientation) has value check if tag 274 (Orientation) has valid type check if tag 284 (PlanarConfig) has value check if tag 284 (PlanarConfig) has valid type check if tag 305 (Software) has  value matching regex '^[[:print:]]*$' check if tag 306 (DateTime) has  value matching regex '^[12][901][0-9][0-9]:[01][0-9]:[0-3][0-9] [012][0-9]:[0-5][0-9]:[0-6][0-9]$' check if tag 34675 (ICC Profile) exists check if tag 34675 (ICC Profile) has valid type check if forbidden tags are still existing found 1 errors

Extraktion und Weitergehende Analyse  des ICC-Profils

Für eine weitergehende Analyse kann man ff. Vorgehen wählen:

• Mit dem Werkzeug "exiftool" das ICC-Profil extrahieren:
  exiftool -icc_profile -b -w icc /tmp/kaputt.tiff
• Mit dem ICC Profiler "profiledump" das extrahierte ICC-Profil "/tmp/kaputt.icc" laden und validieren:
  Windows: wxProfileDump.exe
  Linux: wine wxProfileDump.exe 

Hier die Beispielausgabe:

Warum "AIPUpdate" notwendig ist

In der Diskussion mit Archivaren ist mir in letzter Zeit immer wieder aufgefallen, dass diese mit dem Begriff "AIPUpdate" nichts anzufangen wissen und daher auch nicht verstehen, warum aus der Sicht von Bibliotheken das Thema "AIPUpdate" in der Überarbeitung des OAIS Referenzmodells mit aufgenommen werden sollte.

Klassische Archive

Ein klassisches Archiv arbeitet nach dem Provinienzprinzip, d.h. Archivalien werden nach ihrer Herkunft bzw. Entstehung geordnet. Meist erfolgt diese Ordnung in Form von Akten durch die schriftgutbildende Behörde. Wenn dieses Schriftgut an das Archiv übergeben wird, so handelt es sich dabei um abgeschlossene Dokumente.

Aus Sicht der klassischen Archive sind Änderungen am Archivgut nicht mehr zu erwarten. Diese Überzeugung hat sich auch im Bereich der digitalen Langzeitarchive erhalten.

Bibliotheken und Museen

Anders die Situation in den Bibliotheken und Museen. Diese arbeiten in aller Regel nach dem Pertinenzprinzip, d.h. der Ordnung nach Sachgruppen. Durch die damit einhergehende unterschiedliche Erschließung nach Sachgruppen können Dokumente zu unterschiedlichen Zeiten unterschiedlich gut tiefenerschlossen sein. Die Erschließung ist auch nicht immer perfekt, weil für viele Quellen bestimmte Informationen erst nach und nach durch die Geschichtswissenschaften ermittelt werden können.

Hinzu kommt, dass durch die schiere Menge von Digitalisaten allein im Projekt VD18 Fehler in der Digitalisierung entstehen, die nicht immer sofort auffallen.

Außerdem müssen Bibliotheken und v.a. auch Museen digitale Dokumente (z.B. elektronische Installationen) schon heute noch während der eigentlichen Lebenszeit langzeitarchivieren.

All diese Punkte führen dazu, dass im Gegensatz zu Archiven die Langzeitarchivierung in diesem Bereich mit teilweise unvollständigen, sich noch ändernden Dokumenten oder Dokumententeilen zu tun hat.

Mit dem AIPUpdate ist es möglich, zu einem bereits im Langzeitarchiv gesicherten Stand nachträglich eine vergessene Seite hinzuzufügen, einen Fehler zu korrigieren oder Metadaten zu ergänzen.

Prinzipien AIPUpdate

Damit AIPUpdate funktioniert, bedarf es in Langzeitarchivsystemen der Einhaltung folgender Prinzipien:

1. Saubere Verwaltung eines persistenten Identifiers für die korrekte Zuordnung des Update zu im Langzeitarchiv befindlichen Vorgang
2. Versionsverwaltung der AIPs im Langzeitarchiv
3. Verbot der Löschung von "alten" AIPs (damit alle Versionen nachvollziehbar bleiben)

Da ein AIPUpdate immer auch eine Belastung für das Langzeitarchivsystem darstellt (z.B. Schreib-Lesevorgänge auf Bandspeichern, aber auch durch das Processing), sollten solche Operationen möglichst gebündelt ausgeführt werden.