Montag, 25. Juli 2016

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:


Montag, 11. Juli 2016

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.