Donnerstag, 9. Juni 2016

Formatidentifikation vs. Formatvalidierung - Wem glauben wir eigentlich?

Deutsch (english version below)


Wer in der Lage sein will, die Daten in seinem digitalen Langzeitarchiv auch in Zukunft noch durch Migrationen verfügbar zu halten, muss schon beim Ingest darauf achten, dass die eingelieferten Dateien auch den einschlägigen Standards und Spezifikationen entsprechen.

Bisher fährt man dafür einen zweistufigen Ansatz. Zuerst identifiziert man den Dateityp einer Datei (z. B. anhand der Dateiendung oder einer Signatur) mit einem Werkzeug wie DROID, dann prüft man sie mit einem Formatvalidator. Dieser Ansatz stellt den Anwender aber vor ein fundamentales Problem: was passiert, wenn eine Datei die Formatvalidierung nicht besteht? Wer hat Recht? Hat nicht gerade die Formatidentifizierung ergeben, dass man eine Datei eines bestimmten Formates vor sich hat? Warum widerspricht der Validator dann? Momentan speichert das Archivsystem das erkannte Format in den Metadaten ab, selbst wenn die Datei die Formatvalidierung nicht besteht.

Man kann also nur dann davon ausgehen, dass man z. B. eine TIFF-Datei vor sich hat, wenn der Aufbau der Datei auch der TIFF-Spezifikation entspricht. Ist das nicht der Fall, dann hat man auch kein TIFF vor sich, denn der innere Aufbau ist ja sehr eindeutig spezifiziert. Man hat also etwas vor sich, das nur ungefähr so aussieht wie eine TIFF-Datei, aber keine echte TIFF-Datei.

Eigentlich richtig wäre deshalb der restriktivere Ansatz. Die Formatidentifikation darf hier nur ein Hilfsmittel sein, um das richtige Validierungswerkzeug auszuwählen. Nur wenn die Validierung erfolgreich ist, darf auch das erkannte Dateiformat in den Metadaten festgehalten werden; die verbindliche Formatidentifikation findet also implizit bei der Formatvalidierung mit statt. Ist die Validierung nicht erfolgreich, dann könnte man noch das Formatidentifizierungswerkzeug befragen, ob evtl. eine ähnliche Signatur für einen anderen Dateityp hinterlegt ist, und dann die Validierung wiederholen. Ist das nicht der Fall, dann muss man von einem unbekannten Dateityp ausgehen und ggf. die Datei beim Ingest zurückweisen.

Zusatz für ganz Unerschrockene: viele Formate haben eingebettete Formate, Unterformate oder sind selbst Container für andere Formate. Genau genommen müsste man nicht nur das äußerste Format prüfen, sondern auch die korrekte Einbettung der Unterformate und deren eigene Validität. In das Langzeitarchiv dürften die Dateien nur dann aufgenommen werden, wenn auch alle ihre eingebetteten Dateien korrekt validiert werden können. Was das für TIFF (eingebettete ICC-Profile, XMP- & IPTC-Metadaten, ...), OpenOffice Dokumente (XML und Bilder in ZIP eingebettet), PDF (alle möglichen eingebetteten Dateiformate und Codeschnipsel, dazu Links zu externen Quellen), das Webarchivformat WARC (buchstäblich alle Formate, die auf Webseiten vorkommen können) und viele andere Formate bedeutet, mag sich jeder selbst in seinen Alpträumen von der Formathölle ausmalen. Klar ist: im Moment tun wir auch in Ermangelung geeigneter Werkzeuge viel zu wenig um sicherzustellen, dass nur valide Dateien in unsere Langzeitarchive gelangen.


Dienstag, 7. Juni 2016

Validating TIFFs with embedded color profiles

About ICC profile validation


In the last days we enhanced our baseline TIFF conformance checking tool "checkit_tiff" with support to validate TIFFs containing embedded ICC profiles.

There are two specifications of ICC profiles. The first and older one is from the year 2001 and available at http://www.color.org/ICC_Minor_Revision_for_Web.pdf. The second one (and current version) is  http://www.color.org/specification/ICC1v43_2010-12.pdf.

The ICC profile standards are very complex and do not really fit in the design of the checkit_tiff configuration files, so we decided to check only the headers of the embedded ICC profiles for now.

Because the differences between the headers of both standards are very marginal at first sight, this could be simple enough to additionally implement it in checkit_tiff.

For more detailed checks we would need a plugin system to delegate validation of embedded standards (as ICC, XMP and so on) to more highly specialized validators.

Ooops, our tool finds more broken TIFFs again


To test the validation, we ran checkit_tiff against some old tiffs from our digitization collection. As you can see in the following picture, the checkit_tiff tool detects a discrepancy between the size of the embedded ICC-profile as reported in TIFF-tag (34675) and the size reported by the ICC profile itself:





After some analysis we made an interesting observation. The given TIFF reports a size of 13691 bytes (in hex: 0x357b), but the ICC itself (tag "profile size") reports a size of 669051 bytes (in hex: 0xa357b). We thought we had a bug in our TIFF tag or ICC header decoding, but other tools (exiftool or tiffdump) also reported this difference.

As we saw in previous TIFFs, some TIFF implementations are wrong and often some information were missing because of off-by-one errors. In this case, it seems that the software "Omniscan 12.8 Build2476" does not correctly fill the Tiff-tag 34675 for ICC-profile, leaving out the most significant byte (here: '0xa').

We need your help


Anyway. Writing a conformance checker is a tough job and sometimes we introduce bugs in this kind of software as well. Therefore, please have a look at the code of checkit_tiff, test it and send us bug reports if you find any bugs.
The code can be found on https://github.com/SLUB-digitalpreservation/checkit_tiff.

Here are some open questions about ICC profiles that we have encountered:


  • We found some TIFFs which reported ICC version 4.2.0, but on http://www.color.org we only found versions 4.3.0 and 2.4.0. Could you help us to find out the differences in the headers for the different versions?



  • The meaning of the field "preferred CMM type" is unclear. We assume that the list of allowed strings is part of the document http://www.color.org/registry/signature/TagRegistry-2016-05.pdf. But we have also found a TIFF where the string 'Lino' is set for this ICC header field. Are we interpreting the document in a wrong way, or has the tag been set to an incorrect value?