Freitag, 2. Februar 2018

Restaurierung von kaputten TIFF-Dateien

(English version below)

Kaputtes TIFF, erste Analyse


Ein Kollege schickte uns dieser Tage eine TIFF-Datei, die sich nicht öffnen liess. ImageMagick meldete:

display-im6.q16: Can not read TIFF directory count. `TIFFFetchDirectory' @ error/tiff.c/TIFFErrors/564.
display-im6.q16: Failed to read directory at offset 27934990. `TIFFReadDirectory' @ error/tiff.c/TIFFErrors/564.

Das Tool tiffinfo gab diese Fehlermeldung zurück:

TIFFFetchDirectory: Can not read TIFF directory count.
TIFFReadDirectory: Failed to read directory at offset 27934990.

Ein Blick mit dem Hexeditor Okteta und aktiviertem TIFF-Profil (welches im Übrigen unter https://github.com/art1pirat/okteta_tiff zu finden ist) zeigt, dass das der Offset-Zeiger, der auf das erste ImageFileDirectory (IFD) verweisen sollte, eine Adresse außerhalb der Datei enthält:

Screenshot Okteta, TIFF mit defektem Verweis auf erstes IFD
Faktisch ist das TIFF damit kaputt. Doch bestimmte Eigenschaften dieses Dateiformates erlauben es, eine Restaurierung zu versuchen.

Nebeneinschub

Für eine gut lesbare Einführung in den Aufbau von TIFF-Dateien sei auf den Blogeintrag "baseline TIFF" verwiesen. In "baseline TIFF - Versuch einer Rekonstruktion" wird auf einige manuelle Plausibilitätsprüfungen eingegangen.

Einen kurzen Überblick liefert auch "nestor Thema: Das Dateiformat TIFF" (zu finden auf http://www.langzeitarchivierung.de/Subsites/nestor/DE/Publikationen/Thema/thema.html)

Finden von IFDs


TIFF bringt ein paar Eigenschaften mit, die den Versuch einer Restaurierung erleichtern. So müssen laut Spezifikation Offsets immer auf gerade Adressen verweisen. Damit halbiert sich schon einmal der Suchraum.

Desweiteren können wir annehmen, dass ein IFD mindestens 4 Tags (oft deutlich mehr) enthält, in der Regel Subfiletype (0x00fe), ImageWidth (0x0100), ImageLength (0x0101) und BitsPerSample (0x0102).

Da ein IFD nach den Tags als letzten Eintrag ein NextIFD Feld enthält, welches entweder auf 0 gesetzt ist oder auf ein weiteres IFD verweist, haben wir bereits einiges an wertvollen Hinweisen zusammen.

Auch die Tageinträge innerhalb des IFD selber folgen einer Struktur. Jeder Eintrag besteht aus 2 Bytes TagId, 2 Bytes FieldType, sowie 4 Bytes Count und 4 Bytes ValueOrOffset (sh. Tag-Aufbau, Artikel "baseline TIFF" auf http://art1pirat.blogspot.de).

In der TIFF-Spezifikation sind für FieldType 12 mögliche Werte definiert, die libtiff kennt 18 Werte. Wir können also für jedes angenommene Tag prüfen, ob die Werte im Bereich 1-18 liegen.

Neben diesen harten Kriterien könnten wir, falls die Notwendigkeit besteht, noch weitere hinzuziehen, zum Beispiel:

  • Prüfe, ob bestimmte Pflicht-Tags vorhanden sind
  • Prüfe, ob alle Tags, wie von der Spezifikation gefordert, aufsteigend sortiert sind und keine Dubletten enthalten
  • Prüfe, ob ValueOrOffset ein Offset sein könnte und damit auf eine gerade Adresse verweist

Sicherlich ließen sich noch weitere Kriterien finden, doch in der Praxis zeigt sich, dass die og. harten Kriterien in der Regel schon ausreichen.

Um die Suche nach diesen nicht händisch vornehmen zu müssen, besitzt das Tool fixit_tiff seit kurzem das Programm "find_potential_IFD_offsets".

Wenn man es mit:

$> ./find_potential_IFD_offsets test.tiff test.out.txt

aufruft, spuckt es in der Datei "test.out.txt" eine Liste von Adressen aus, die potentiell ein IFD sein könnten. Für unsere Datei lieferte es den Wert "0x0008", sprich: das IFD müsste an Adresse 8 anfangen.

Mit Okteta die Datei geladen und geändert, voila!, es sieht gut aus:

Screenshot Okteta, TIFF mit repariertem Verweis auf erstes IFD





Auch tiffinfo ist jetzt etwas glücklicher:


TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and calculating from imagelength.
TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x0)
  Image Width: 4506 Image Length: 6101
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6101
  Planar Configuration: single image plane
  Color Map: (present)
  Software: Quantum Process V 1.04.73


Und ImageMagick zeigt sich nun gnädiger:

Ansicht des TIFFs mit repariertem Offset auf IFD





Wie man sieht, ist noch nicht alles repariert, schliesslich meldet auch ImageMagick noch Probleme:

display-im6.q16: Bogus "StripByteCounts" field, ignoring and calculating from imagelength. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
display-im6.q16: Read error on strip 4075; got 2706 bytes, expected 4506. `TIFFFillStrip' @ error/tiff.c/TIFFErrors/564.

Doch sollte vorliegend gezeigt werden, dass eine Restaurierung von kaputten TIFF-Dateien durchaus möglich ist.

---------------------------------------------------------------------

Broken TIFF, a first analysis


A colleague recently sent us a TIFF file that he couldn't open. ImageMagick reported:

display-im6.q16: Can not read TIFF directory count. `TIFFFetchDirectory' @ error/tiff.c/TIFFErrors/564.
display-im6.q16: Failed to read directory at offset 27934990. `TIFFReadDirectory' @ error/tiff.c/TIFFErrors/564.

The tool tiffinfo returned the following error:

TIFFFetchDirectory: Can not read TIFF directory count.
TIFFReadDirectory: Failed to read directory at offset 27934990.

A quick investigation in the Hex editor Okteta with the TIFF profile activated (to be found at https://github.com/art1pirat/okteta_tiff) revealed that the offset pointer, which should be pointing to the first ImageFileDirectory (IFD), points to an address that is beyond the end of the file:

screenshot Okteta, TIFF with defective pointer to the 1st IFD
Given that, the TIFF is de facto broken. However, we can leverage certain properties of this file format to try a restoration.

Side note

For a well-readable introduction into the structure of TIFF files, pleases refer to the blog post "baseline TIFF". The article "baseline TIFF - Versuch einer Rekonstruktion" describes some manual plausibility checks.

Another short overview is provided by "nestor Thema: Das Dateiformat TIFF" (to be found at http://www.langzeitarchivierung.de/Subsites/nestor/DE/Publikationen/Thema/thema.html)

Finding IFDs


TIFF comes with a few properties that facilitate restoration attempts. According to the specification, offsets must point to even addresses, which already cuts the search space in half.

Also, we can assume that an IFD contains at least four tags (often significantly more), usually Subfiletype (0x00fe), ImageWidth (0x0100), ImageLength (0x0101) and BitsPerSample (0x0102).

As an IFD's last entry after all the tags is a pointer to the NextIFD, which is either set to 0 or points to another IFD, we already have some useful hints to work with.

The tag entries  inside of the IFD follow a strict structure as well. Each entry consists of 2 Bytes TagId, 2 Bytes FieldType, 4 Bytes Count and 4 Bytes ValueOrOffset (also see Tag-Aufbau, Artikel "baseline TIFF" auf http://art1pirat.blogspot.de).

The TIFF specification defines 12 possible values for the FieldType, libtiff knows 18 values. Following that, we can check for each chunk of Bytes that might be a tag if the value is between 1 and 18.

Additionally, we could add some soft criteria to these hard criteria that we already have:

  • check if certain mandatory tags can be found
  • check if all tags are sorted in an ascending order and don't contain any duplicates as required by the specification
  • check is ValueOrOffset can be an actual offset by checking if it points to an even offset

We could think up even more criteria, but practical experience shows that the hard criteria are already sufficient for most of the cases.

In order to avoid having to search for potential IFDs in the files manually, the tool fixit_tiff now comes with the program "find_potential_IFD_offsets".

If it is invoked like:

$> ./find_potential_IFD_offsets test.tiff test.out.txt

it will spew out a list of addresses to the file "test.out.txt" that might potentially mark the beginning of an IFD. For the file from our colleague, it gave us only one value, which was "0x0008". In other words, the IFD should start at address 8.

Now load up the file in Okteta change the pointer to the first IFD right after the TIFF header to the correct address, et voila!, it looks good:

screenshot Okteta, TIFF with repaired pointer to 1st IFD





tiffinfo is now a little happier as well:


TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and calculating from imagelength.
TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x0)
  Image Width: 4506 Image Length: 6101
  Resolution: 300, 300 pixels/inch
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6101
  Planar Configuration: single image plane
  Color Map: (present)
  Software: Quantum Process V 1.04.73


And even ImageMagick is now a little more gracious:

Ansicht des TIFFs mit repariertem Offset auf IFD





As you can see, not everything has been repaired yet, and ImageMagick is still reporting some problems:

display-im6.q16: Bogus "StripByteCounts" field, ignoring and calculating from imagelength. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
display-im6.q16: Read error on strip 4075; got 2706 bytes, expected 4506. `TIFFFillStrip' @ error/tiff.c/TIFFErrors/564.

However, we were able to show that a restoration of broken TIFFs is indeed feasible, and even though some of the data is lost, we still can see a part of what has been a magazine scan.

Mittwoch, 6. September 2017

Hinweis auf interessantes Interview zu FFV1

Ein äußerst interessantes Interview von Jürgen Keiper mit Peter Bubestinger zur Entstehung und Motivation von Matroska/FFV1 als langzeitarchivfähiges Datenformat für audiovisuelle Medien.

Es ist besonders interessant für Archivare, die wissen wollen, warum FFV1/Matroska ihre Probleme lösen kann. Peter schafft es Sachverhalte einfach und anschaulich zu erklären und kommt (fast) ohne technisches Vokabular aus.

Prädikat: Sehenswert!

Hier der Link zum Video:

https://www.memento-movie.de/2017/08/die-geschichte-eines-codecs-ffv1-in-der-archivwelt/

Dienstag, 30. Mai 2017

Bibtag - und 'ne Kleinigkeit gelernt

Heute hatte ich einen Abstecher zum Bibliothekartag 2017 nach Frankfurt am Main gemacht. Zum einen, um etliche Ex-Kommilitonen zu treffen, zum anderen war ich am Workshop von Yvonne Tunnat von der ZBW zur Formatidentifikation interessiert.

Yvonne hat eine wunderbare, pragmatische Art komplizierte Sachverhalte zu erklären. Wer sie kennenlernen möchte, der nestor-Praktikertag 2017 zur Formatvalidierung hat noch Plätze frei.

Zwei Dinge, die ich mitnehme. Zum einen kannte ich das Werkzeug peepdf noch nicht. Es handelt sich um ein CLI-Programm um eine PDF-Datei zu sezieren und kommt ursprünglich aus der Forensik-Ecke.

Zum anderen gibt es mit Bad Peggy ein Validierungstool um JPEGs zu analysieren.

Eine Diskussion, die immer wieder auftaucht ist die, wie man mit unbekannten Dateiformaten umgeht. IMHO sind diese nicht archivfähig, und wie Binärmüll zu betrachten. Dazu bedarf es aber mal eines längeren Beitrags und einer genaueren Analyse, ob und unter welchen Bedingungen solche Dateien vernachlässigbar sind, oder der long-tail zuschlägt.

BTW., wer am Mittwoch noch auf dem Bibtag ist, schaue mal beim Vortrag unserer Kollegin Sabine zu den Ergebnissen der PDF/A Validierung vorbei.

Dienstag, 16. Mai 2017

Über die Idee, ein Langzeitarchiv vermessen zu wollen

OpenClipart von yves_guillou, sh. Link
OpenClipart von yves_guillou, sh. Link im Bild
Irgendwann gerät man in einer Organisation an den Punkt, an dem man auf Menschen trifft, die sich den Zahlen verschrieben haben. Menschen, die als Mathematiker, als Finanzbuchhalter oder als Controller arbeiten. Das ist okay, denn Rechnungen wollen bezahlt, Ressourcen geplant und Mittel bereitgestellt werden.

Omnimetrie


Problematisch wird das Zusammentreffen mit Zahlenmenschen dann, wenn diese die Steuerung der Organisation bestimmen. Wenn es nur noch um Kennzahlen geht, um Durchsatz, um messbare Leistung, um Omnimetrie.

Schon Gunter Dueck schrieb in Wild Duck¹: "In unserer Wissens- und Servicegesellschaft gibt es immer mehr Tätigkeiten, die man bisher nicht nach Metern, Kilogramm oder Megabytes messen kann, weil sie quasi einen 'höheren', im weitesten Sinn einen künstlerischen Touch haben. Die Arbeitswelt versagt bisher bei der Normierung höherer Prinzipien."
  

Zahlen lügen nicht


Schauen wir uns konkret ein digitales Langzeitarchiv an. Mit Forderungen nach der Erhebung von Kennzahlen, wie:
  • Anzahl der Dateien, die pro Monat in das Archiv wandern, 
  • oder Zahl der Submission Information Packages (SIPs), die aus bestimmten Workflows stammen, 
demotiviert man ein engagiertes Archivteam. 

Denn diese Zahlen sagen nichts aus. Digitale Langzeitarchive stehen auch bei automatisierten Workflows am Ende der Verwertungskette. Es wäre in etwa so als würde man den Verkauf von Würstchen an der Zahl der Besucher der Kundentoilette messen wollen.

In der Praxis ist es so, dass Intellektuelle Einheiten (IE), die langzeitarchiviert werden sollen, nach dem Grad ihrer Archivfähigkeit und Übereinstimmung mit den archiveigenen Format-Policies sortiert werden.

Diejenigen  IEs, die als valide angesehen werden, wandern in
Archivinformationspaketen (AIP) eingepackt in den Langzeitspeicher. Die IEs, die nicht archivfähig sind, landen in der Quarantäne und ein Technical Analyst (TA) kümmert sich um eine Lösung oder weist die Transferpakete (SIP) mit diesen IEs zurück.

Wenn wir einen weitgehend homogenen Workflow, wie die Langzeitarchivierung von Retrodigitalisaten, betrachten, so sollte der größte Bestandteil der IEs ohne Probleme im Langzeitspeicher landen können. In dem Fall kann man leicht auf die Idee kommen, einfach die Anzahl der IEs und Anzahl und Größe der zugehörigen Dateien zu messen, um eine Aussage über den Durchsatz des Langzeitarchivs und die Leistung des LZA-Teams zu bekommen.

Ausnahme Standardfall


Doch diese Betrachtung negiert, dass nicht der Standardfall, wo IEs homogenisiert und automatisiert in das Archivsystem wandern, zeitaufwändig ist, sondern der Einzelfall, in dem sich der TA mit der Frage auseinander setzen muss, warum das IE anders aufgebaut ist und wie man eine dazu passende Lösung findet.

Formatwissen


Was die einfache Durchsatzbetrachtung ebenfalls negiert, ist, dass das Archivteam Formatwissen für bisher nicht oder nur allgemein bekannte Daten- und Metadatenformate aufbauen muss. Dieser Lernprozess ist hochgradig davon abhängig, wie gut die Formate bereits dokumentiert und wie komplex deren inneren Strukturen sind.

Organisatorischer Prozess


Ein dritter Punkt, den ein Management nach der Methode Omnimetrie negiert, ist die bereits im Nestor-Handbuch² formulierte Erkenntnis, dass digitale Langzeitarchivierung ein organisatorischer Prozess sein muss.

Wenn, wie in vielen Gedächtnisorganisationen, die Retrodigitalisate produzieren, auf Halde digitalisiert wurde, und das Langzeitarchivteam erst ein bis zwei Jahre später die entstandenen digitalen Bilder erhält, so kann von diesem im Fehlerfall kaum noch auf den Produzenten der Digitalisate zurückgewirkt werden. Die oft projektweise Abarbeitung von Digitalisierungsaufgaben durch externe Dienstleister verschärft das Problem zusätzlich. Was man in dem Falle messen würde, wäre in Wahrheit keine Minderleistung des LZA-Teams, sondern ein Ausdruck des organisatorischen Versagens, die digitale Langzeitverfügbarkeit der Digitalisate von Anfang an mitzudenken.

Natürlich ist es sinnvoll, die Entwicklung des Archivs auch mit Kennzahlen zu begleiten. Speicher muss rechtzeitig beschafft, Bandbreite bereitgestellt werden. Auch hier gilt, Augenmaß und Vernunft.

¹ Gunter Dueck, Wild Duck -- Empirische Philosophie der Mensch-Computer-Vernetzung, Springer-Verlag Berlin-Heidelberg,  (c)2008, 4. Auflage., S. 71
² Nestor Handbuch -- Eine kleine Enzyklopädie der digitalen Langzeitarchivierung, Dr. Heike Neuroth u.a., Kapitel 8 Vertrauenswürdigkeit von digitalen Langzeitarchiven, von Susanne Dobratz und Astrid Schoger, http://nestor.sub.uni-goettingen.de/handbuch/artikel/text_84.pdf, S.3

Samstag, 29. April 2017

FFV1 - some compression results

In a pilot we got some retrodigitized films and videos in Matroska/FFV1 format. In the following table I summarized the results:


n/a
film/video12345
description8mm, positive, b/w8mm, positiv, b/w16mm, positive, b/w35mm, combined, color35mm, combined, color
width25002500204840964096
height15241524152034602976
bits per pixel4848484848
pxfmtgbrp16legbrp16legbrp16legbrp16legbrp16le
duration in s121211,4592,52,5
fps2424242424
frames2882882756060
original size658368000065836800005136682844,1651019776004388290560
compressed size38619438803790690517368077971939084753443576745774
compression ratio1,7041,7361,3951,3051,226
(DPX size)65841592326584159232513684160051020774404388390400
(h264 lossless)n/a n/a n/a n/a n/a
(h265 lossless)35734203093559442475275650424730150538222992764833
(jp2k lossless)45898863414534014321373255553938696659163514687046
with audionnnyn


n/a
film/video678910
description35mm, combined, colorvhs, colorbetacam, colorbetacam, colorDigi-beta, color
width4096720720720720
height3200576576576576
bits per pixel4820202020
pxfmtgbrp16leyuv422p10leyuv422p10leyuv422p10leyuv422p10le
duration in s1088,042280280280280
fps2425252525
frames261137000700070007000
original size20536105107467257600000725760000072576000007257600000
compressed size15754151756113565437155383850093434493722804451325952
compression ratio1,3032,0351,8902,1041,630
(DPX size)
2053653333632
17472217728174298880001742988800017429888000
(h264 lossless)
n/a
n/a n/a n/a n/a
(h265 lossless)12480312926343659828688377252225734427392594323623225
(jp2k lossless)15171175605753300899483347043417731507270814022908822
with audionyyyy

All files are encoded with FFV1v3 with slices, slice-crc, GOP=1. If audio exists, it is (lin. PCM 48kHz, 16bit) included in compression-size, but not in original size, because original size is calculated by width*height*pits_per_pixel*frames and compression-size is equivalent to filesize. The count of frames is calculated with the duration value of the MKV-files. The files 1 to 5, and 7-10 are first parts of the movies (each 4GB splits).

Hint: Once the project is completed, rights must be clarified. If possible, I will publish the sources.

Update 2017-06-09

  • added file size for DPX after using "ffmpeg -i input.mkv DPX/frame_%06d.dpx"
  • added file size for h264 after using "ffmpeg -i input.mkv -c:v libx264 -g 1 -qp 0 -crf 0 output.mkv" (RGB without lossy conversion to YUV not supported yet)
  • added file size for h265 after using "ffmpeg -i input.mkv -c:v libx265 -preset veryslow -x265-params lossless=1 output.mkv"
  • added file size for openjpeg2000 after using "ffmpeg -i input.mkv -c:v libopenjpeg output.mkv
Update 2017-06-29

  • added sizes for film no 6
  • in general, the processing time of h265 and jp2k is one magnitude greater than for ffv1

Interpretation


The files 1-3 are all originally b/w. It seems to be that the codec does not decorrelate the color channels. Also the material 1-6 is retrodigitized from film and are noisy. The file 1 is very special. In decoding the FFV1 produces a very high load on the CPU (eight cores at 100%). The most decoding time is spent in method get_rac(). The original film has the highest noise level in contrast to the other files.

I think the compression-ratio difference between video- and film files comes from the different pixel format. A ratio between 1,5 - 2 was expected, but 1,3 is a surprise.

Update 2017-06-09

The reason for high CPU load was, that the digitization service provider has created a file with a framerate of 1000 fps, but the scanner has provided 24 or 25 fps. Therefore 42-40 equal frames  was encoded on block.



Donnerstag, 30. März 2017

Nestor - DIN - Workshop "Digitale Langzeitarchivierung", Nachlese

Gestern fand in den Räumen des DIN e.V. ein Workshop des Kompetenznetzwerkes digitale Langzeitarchivierung nestor und der DIN statt. Dies soll nur eine kleine Zusammenfassung für die Zuhausegebliebenen sein und erhebt keinen Anspruch auf ein objektives oder gar vollständiges Protokoll :)
Falls Fehler vorliegen bitten wir um eine Email mit Korrekturhinweisen ;)

Arbeiten des NID 15 Ausschuß


Im Kern ging es  im Workshop um die Frage, welchen Standard wollen wir in der digitalen Langzeitarchivierung in den nächsten 5-8 Jahren haben und wie kommen wir dahin?

Mit dieser Frage startete Prof. Keitel den Workshop und skizzierte nachfolgend die Ausgangslage von 2005.

  • abstraktes Thema "digitale Archivierung"
  • DIN 31646/31644/31645 aus Nestor "Dunstkreis"
  • DIN 31647 "Beweiserhaltung kryptograf. signierter Dokumente"
  • Rücklauf, ob Norm in Praxis verwendet werden ist schwierig zu erkennen
  • beziehen sich auf OAIS (ISO14721)
  • zeigen, ob man sich noch im Rahmen der digitalen LZA bewegt.

Aktuell ergänzen praktische Erfahrungen diese frühen theorethischen Überlegungen. Die Frage ist daher, ob es Bereiche gibt, wo sich die Ausgangsthesen mittlerweile überholt haben?

Es gilt, so Prof. Keitel,
  •  Schwerpunkte, die sich zur Standardisierung eignen, herauszukristallisieren
  •  Mitarbeitern zu finden, die sich in der Normierungsarbeit in den neuen Feldern einbringen wollen

Ob man für Normungsarbeit geeignet sei, läßt sich launisch an folgenden Kriterien festmachen (Zitat):
  • Lange auf Stuhl sitzen
  • Verbessere gern Geschriebenes anderer Leute
  • bei genauen terminologischen Definitionen verstehe ich keinen Spaß und mache keine Kompromisse
  • ich lese gerne Dokumente mit Titelen, wie...
Im Anschluss wurde die Schwierigkeit angesprochen, Feedback zu bestehenden DIN Normen zu erhalten.

PDF Standardisierung


Olaf Drümmer von der callas software GmbH skizzierte einführend die Geschichte von PDF und wies auf die neue Version 2 hin:

  • 1993-2006 Adobe PDF 1.0 -> 1.7
  • 2008 ISO: PDF 1.7 als ISO 32000-1
  • 2017 ISO: PDF 2.0 als ISO 32000-2 (im nächsten Quartal, >1000 Seiten)
    • neue kryptografische Verfahren
    • tagging überarbeitet
    • Problemfeld im Normungsprozess waren Farben
    • Namespaces wurden eingeführt, zB. um Tags aus HTML 5 einbinden
Er ging dann auf die PDF-Spezialisierungen ein:

  • 2001 PDF/X Übermittlung von Druckvorlagen
  • 2005 PDF/A Archivierung, ISO Reihe 19005
    • entstanden aus Notwendigkeiten der US Courts, Library of Congress
  • 2008 PDF/E ISO 24517, Engineering (CAD), noch nicht stark verbreitet, Ende des Jahres auch 3D Modelle
  • 2010 PDF/VT ISO 16612-2 + PDF/VCR ISO 16612-3, variabler Datendruck (großvolumige Rechnungen, Serienbriefe)
  • 2012 PDF/UA ISO 14289 Reihe, Barrierefreiheit
Die Bedeutung der Normung ergibt sich nach Drümmer allein schon aus der
Verbreitung von PDF Dokumenten:
  • Anzahl PDF Dokumente weltweit, mind. Billionen (10¹²), davon 6 Millionen allein beim US Court
  • Lebenserwartungen pro PDF: Stunden bis Jahre
Weiter ging er auf die Herausforderung Variantenvielfalt ein:
  • PDF/X, 8 Normteile, insgesamt 12 Konformitätsstufe
  • PDF/A Normenreihe, 3 Normteile, insgesamt 8 Konformitätsstufen
  • Unübersichtlich, mangelnde Trennschärfe?
  • Flexibilität bzw. Mächtigkeit
  • offener Charakter
  • breite Abdeckung
Wie es mit der Normierung ab 2017 weitergehen soll skizzierte er anschliessend:
  • PDF2.0 weitgehend rückwärtskompatibel, keine Validierung bei Veröffentlichungen vorgesehen
  • Projekt "Camelot2" soll klassische PDF-Dokumentenwelt und Open Web Platform zusammenbringen, mehr Infos zu PDF Days Europe 2017, Berlin, 15.-16. Mai 2017
  • PDF/A4 als Ziel: keine Konformitätsstufen
  • PDF/E erlaubt interaktive Elemente (JS), PDF/E-2 soll eher eine Archivausprägung weniger eine Arbeitsdokumentausprägung bekommen
  • XMP kann im PDF an *allen* Stellen angebracht werden, so dass man darin auch Quellen oder zB. UUIDs dafür hinterlegen kann
  • PDFA/3 kann auch alternative Verknüpfung zum Inhalt beliebiger Dateien hinterlegen, Problem: nicht verpflichtend und muss über Policy geregelt werden

nestor


Prof. Keitel skizzierte kurz die Arbeit von nestor:

  •  …ist auf jeden Fall Kooperationsnetzwerk
  • stellt AGs vor

Vertrauenswürdige Archive

  • * 2004-2008 Nestor Kriterienkatalog
  • * 2008-2012 DIN31644
  • * 2013-… nestor Siegel

Submission Information Packages - Überarbeitung der Ingest-Standards


Dr. Sina Westphal und Dr. Sebastian Gleixner (Dt. Bundesarchiv) regten in einem Impulsvortrag die Normierung des Ingestvorgangs und der SIPs an.

  • Bundesarchiv 4PB/Jahr Zuwachs
  • Anreiz zur allmählichen Angleichung der Systeme
  • vereinheitlichte Metadaten
  • verbesserter Datenaustausch
  • vereinheitlichte Schnittstellen
Konsequenzen:
  • Vereinheitlichung bestehender SIPs (ggf. auch AIPs/DIPs)
  • Vereinheitlichung bestehender digitaler Archivsysteme

Zwei Teilbereiche:
  • Standardisierung des SIP (konkret)
    • Struktur
    • Metadaten
    • Primärdaten
    • vgl. E-ARK, e-CH, EMEA
  • Standardisierung des Ingest-Prozesses (abstrakt)
    • Verbindung zum Erschliessungstool
    • Validierung
    • Ingest
    • Umgang mit Primärdaten

Fragen:
  • Vereinheitlichung möglich?
  • Ist Standardisierung AIPs/DIPs und der damit verbundenen Prozesse notwendig?

Im Anschluss erfolgte eine Diskussion über Abgrenzung und konkrete Austauschverfahren mit ff. Ergebnis:

  • Trend geht hin zu abstrakter Modulbeschreibung
  • konzeptioneller Rahmen erwünscht
  • Festlegung welche Module verpflichtend, welche optional sind
  • empfohlener Einstiegspunkt für Automatisierung

Videoarchivierung als neue Herausforderung, Langzeiterhaltung audiovisueller Medien jenseits von Film- und Fernsehen


In diesem Impulsvortrag von Alfred Werner, HUK Coburg wurde die Problematik der Langzeitarchivierung von Videos skizziert.

  • Bandbreite Außenstelle 5-15MBit/s
  • wandeln in Multipage-TIFF monochrom (kleine Dateien) und in JPG um,
  • Videos erwünscht,
    • 2011 5 Videos/Tag
    • 2016 20 Videos/Tag (im Gegensatz zu 10.000 Schadensfälle pro Tag)
    • 2021 100?/1000? Videos/Tag
  • Dashcam-Videos seit diesem Jahr erlaubt

Problem: unterschiedlichste Formate, Tendenz steigend, es wird nicht besser (3D, HDR, 4k, 2 Objektive, Spezialsensoren)

mögliche Lösung: Konvertierung in ein Langzeitarchivformat für Videos

Anforderungen:
  • Standard für die nächsten 50 Jahre
  • Lizenzfrei
  • bestmögliche Qualität
  • geringer Speicherplatz
  • gute Antwortzeiten auch bei geringer Bandbreite

dann noch Funktionen für Sachbearbeiter, wie:
Zoomen, Sprungmarken setzen, Extrahieren Einzelbilder, Schwärzen, Szenen extrahieren.

In der anschliessenden Diskussion wurde das Problem deutlich, dass man sich im Spannungsfeld zwischen Robustheit und originalgetreuer Wiedergabe einerseits und Ressourcenbedarf (Speicher, Bandbreite, Processingzeit) andererseits befindet.

Anmerkung: Dazu wurde auf der nestor-ML ein ergänzender Beitrag verfasst.


Digital Curation


Auch hier hielt Prof. Keitel ein Impulsreferat. Ich hoffe, ich kann den Inhalt korrekt wiedergeben:

Unterschied Data Curation zu Langzeitarchivierung nach OAIS: wir reden nicht mehr von Einrichtungen/Organisationen, sondern von Techniken. D.h., fehlen der organisatorischen Verantwortung.

OAIS goes Records Managment, dh. wie kann man Anforderungen der digitalen LZA an Produzenten bringen (durch digital curation), AIP liegt quasi beim Produzenten.
Wie harmonieren die von OAIS/PREMIS genannten Erhaltungsfunktionen mit den Rgelungen des Records Managment? Welche Elemente/Gruppen müssen wir aus Erhaltungsgründen unterscheiden?

Keitel: "Wir gingen bisher immer von einem Kümmerer aus, der Dinge auf Dauer bewahrt. Digital Curation setzt vorher beim Producer an"

Zusammenfassung


Aus unserer Sicht sollte der Ingest versucht werden besser zu standardisieren. Nur so wäre es möglich, dass man Produzenten Werkzeuge in die Hand geben kann, die nicht archivspezifisch sind. Der Weg dorthin ist steil, zumal allein schon die Wege die Archive und Bibliotheken einschlagen sehr unterschiedlich sind.

PDF ist und bleibt leider ein Minenfeld. Weder wurden mit PDF2 bestehende Ambiguitäten ausgeräumt, noch vereinfacht sich der Standard. Besonders nachteilich dürfte sich die fehlende offizielle Validierung erweisen. Hinzukommt dass der Formatzoo rund um PDF weiter anwächst und Mischformen von Dokumenten möglich sind, d.h. ein PDF kann sowohl PDF/E als auch PDF/A sein.

Der Bedarf nach langzeittauglichen Videoformaten ist vorhanden. Eine Normierung könnte helfen, die Unterstützung durch Hersteller zu forcieren. Am Thema Video wurde deutlich, dass die digitale Langzeitarchivierung Kosten verursacht, die nicht leicht zu vermitteln sind. Datenkompression, insbesondere die verlustbehaftete führt zu einem höheren Schadensrisiko bei Bitfehlern. Die Diskussion über das Spannungsfeld Robustheit/Qualität vs. Kosten muss in der Community geführt werden, ist aber außerhalb von Normungsbemühungen anzusiedeln.

Data Curation ist eine Aktie für sich. Es gibt Lücken, die entstehen, wenn Dokumente Lebenszyklen von mehreren Jahrzehnten aufweisen. Mein Bauchgefühl sagt mir, dass dies ebenfalls unter Langzeitverfügbarkeit subsummiert werden kann, da wir in der Langzeitarchivierung ja die Dokumente auf unbestimmte Zeiten nutzbar halten wollen. Data Curation scheint mir demnach nichts anderes als der Sonderfall zu sein, als das Produzent und Archiv als Rolle zusammenfallen.

Montag, 13. Februar 2017

Where have all the standards gone? A singalong for archivists.

Recently, we noticed that the specification for the TIFF 6 file format has vanished from Adobe's website, where it was last hosted. As you might know, Adobe owns TIFF 6 due to legal circumstances created by the acquisition of Aldus in 1994.

Up until now, we used to rely on the fact that TIFF is publicly specified by the document that was always available. However, since Adobe has taken down the document, all we have left are the local copies on our workstations, and we only have those out of pure luck. The link to http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf has been dead for several months now.

This made us think about the standards and specifications themselves. We've always, half jokingly, said that we would have to preserve the standard documents in our repositories as well if we wanted to do our jobs right. We also thought that this would never be actually be necessary. Boy, were we wrong.

We're now gathering all the standard and specification documents for the file formats that we are using and that we are planning to use. These documents will then be ingested into the repository using separate workflows to keep our documents apart from the actual repository content. That way, we hope to have all documents at hand even if they vanished from the web.

From our new perspective, we urge all digital repositories to take care of not only their digital assets, but also of the standard documents they are using.

The TIFF user community just recently had to take a major hit when the domain owners of http://www.remotesensing.org/libtiff/ lost control of their domain, thus making the libtiff and the infrastructure around it unavailable for several weeks. Even though the LibTIFF is now available again at their new home (http://libtiff.maptools.org), we need to be aware that even widely available material might be unavailable from one day to another.