Schädlingsbekämpfung ist ein immerwährendes Problem in Bibliotheken und Archiven. Silberfischchen, Papierfischchen und andere Übeltäter laben sich an den Beständen und richten dabei beträchtliche Schäden an.
Da die Schädlingsbekämpfung nicht als explizite Aufgabe im OAIS-Referenzmodell aufgeführt ist, haben einige digitale Langzeitarchive hier bisher deutliche Defizite. Inzwischen spüren aber auch diese Einrichtungen immer deutlicher, dass die Schädlingsbekämpfung nicht vernachlässigt werden darf.
Angelockt von umfangreichen digitalen Beständen nisten sich Bitfischchen und Käfer (in der Fachsprache "Bugs" genannt) in Kabelhaufen ein und vermehren sich dort ungestört. Das Nahrungsangebot durch den reichlich vorhandenen Kabelsalat ist gut, und so wachsen die Populationen schnell an. Reste von Junk sowie Binärmüll-Krümel verschärfen das Problem zusätzlich.
Nicht nur die Anzahl der Fischchen, sondern auch ihre lange Lebensdauer ist ein Problem. Viele von Ihnen werden acht bis zehn Jahre alt, Microfichechen sogar noch deutlich älter.
Im moderigen Milieu vieler digitaler Archive fühlen sich auch Magnetbandwürmer wohl, die sich vor allem an den Daten auf WORM-Tapes laben. Daten, die nicht von den kleinen Plagegeistern zerstört werden, zerfallen in der fauligen Umgebung durch den Bitrot zu unlesbarem Datenkompost, der die Datenleitungen verstopft und so die Verarbeitung stört.
Eine gute Seite hat die neue Plage allerdings: findige Informatiker haben herausgefunden, dass Bitfischchen hervorragend zur Herstellung von Bitfett geeignet sind. Sie nutzen es, um Leitungsverbindungen zu schmieren und so die Reibung bei der Datenübertragung zu reduzieren, was wiederum positiv auf den Durchsatz auswirkt.
Posts mit dem Label qualität werden angezeigt. Alle Posts anzeigen
Posts mit dem Label qualität werden angezeigt. Alle Posts anzeigen
Montag, 1. April 2019
Freitag, 5. Oktober 2018
Here's a tool, make it work!
In the last post you may have already noticed it. To analyze the hits of DROID signatures I wrote a small Perl script which converts Droid signatures into Perl Regular Expressions and writes the matches into tag files of the hex editor wxHexEdit so that you can see which signatures were used where in a file.
From this small script a bigger Perl module called "File::FormatIdentification::Pronom" was created. It should not replace Droid, Fido or Siegfried. It only serves to analyze which patterns can be optimized and gives statistics about how to improve the Pronom database in the future.
In the following a statistic of the current Droid signature is shown, so that you get a feeling, what is possible.
I would be pleased about feedback. The code is available under http://andreas-romeyke.de/software.html#_file_formatidentification_pronom .
Have fun!
From this small script a bigger Perl module called "File::FormatIdentification::Pronom" was created. It should not replace Droid, Fido or Siegfried. It only serves to analyze which patterns can be optimized and gives statistics about how to improve the Pronom database in the future.
In the following a statistic of the current Droid signature is shown, so that you get a feeling, what is possible.
perl -I lib/ bin/pronom_statistics.pl ../DROID_SignatureFile_V94.xml
Statistics of file ../DROID_SignatureFile_V94.xml
=======================================
Countings
---------------------------------------
Count of PUIDs: 1670
internal IDs: 1441
regular expressions: 1730
file endings: 1167
PUIDs with file endings only: 503
(56,76,167,168,169,194,195,212,594,681,682,683,684,691,717,760,780,879,996,1435)
orphaned internal IDs: 20
(56,76,167,168,169,194,195,212,594,681,682,683,684,691,717,760,780,879,996,1435)
Quality of internal IDs
---------------------------------------
1-best quality internal ID (PUID, name): 110 (fmt/75, Drawing Interchange File Format (ASCII)) -> 4.882;3.135
combined regex: (?=((\x0A)|(\x0D\x0A)(0))SECTION((\x0A)|(\x0D\x0A)(\x20\x202)((\x0A)|(\x0D\x0A)(HEADER)((\x0A)|(\x0D\x0A))))((\x0A)|(\x0D\x0A)(9))\$ACADVER((\x0A)|(\x0D\x0A)(\x20\x201)((\x0A)|(\x0D\x0A)(AC1009)((\x0A)|(\x0D\x0A))))((\x0A)|(\x0D\x0A)(0))ENDSEC((\x0A)|(\x0D\x0A)))(?=(((\x0A)|(\x0D\x0A)(0))EOF((\x0A)|(\x0D\x0A)))\Z)
2-best quality internal ID (PUID, name): 105 (fmt/70, Drawing Interchange File Format (ASCII)) -> 4.736;2.833
combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC((1001)|(2\x2E21)|(2\x2E22)(\x0D\x0A))0
ENDSEC
)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
3-best quality internal ID (PUID, name): 104 (fmt/69, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC2\x2E10\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
4-best quality internal ID (PUID, name): 103 (fmt/68, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC1\x2E50\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
5-best quality internal ID (PUID, name): 102 (fmt/67, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC1\x2E40\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
1-worst quality internal ID (PUID, name): 1299 (fmt/950, MIME Email) -> -1.993;-2.91;-2.776;-2.776;-2.29
combined regex: (?=\A.{0,16384}(((V)|(v)(\x2D)((IME)|(ime)(M)))ersion: 1\.0))(?=\A.{0,16384}(To\x3A\x20))(?=\A.{0,16384}(From\x3A\x20))(?=\A.{0,16384}(Date\x3A\x20))(?=\A.{0,16384}(Content\x2DType\x3A\x20))
2-worst quality internal ID (PUID, name): 527 (fmt/358, Internet Data Query File) -> -2.806;-2.743;-2.629;-2.981
combined regex: (?=\A.{0,3424}(\x5BQuery\x5D).*(((S)|(s)(i)((C)|(c)))cope=))(?=\A.{0,3424}(\x5BQuery\x5D).*(((C)|(c)(i)((C)|(c)))olumns=))(?=\A.{0,3424}(\x5BQuery\x5D).*(((T)|(t)(i)((C)|(c)))emplate=\/))(?=\A.{0,3424}(\x5BQuery\x5D).*(((R)|(r)(i)((C)|(c)))estriction=.?(\x25)))
3-worst quality internal ID (PUID, name): 532 (fmt/363, SEG Y Data Exchange Format) -> -3.351;-4.196
combined regex: (?=\A.{0,320}(\x40{22}))(?:(?=\A.{3200}(\x00\x00.{15}([^\x00])|(?=\A.{3600}(\x00\x00.{15}([^\x00])).{3}([^\x00])(.{2}(\x00[\x01-\x08])|.{2}(\x01\x00))))
4-worst quality internal ID (PUID, name): 533 (fmt/363, SEG Y Data Exchange Format) -> -3.351;-4.196
combined regex: (?=\A.{0,320}(\x40{22}))(?:(?=\A.{3200}(\x00\x00.{15}([^\x00])|(?=\A.{3600}(\x00\x00.{15}([^\x00])).{3}([^\x00])(.{2}(\x00[\x01-\x08])|.{2}(\x01\x00))))
5-worst quality internal ID (PUID, name): 835 (fmt/532, Drawing Interchange File Format (ASCII)) -> -3.614;-3.842
combined regex: (?=\A.{1,3}((0).{1,2}SECTION.{1,2}(\x20\x202).{1,2}(HEADER)).+((9).{1,2}\$ACADVER.{1,2}(\x20\x201).{1,2}(AC1027)).+((0).{1,2}ENDSEC))(?=((0).{1,2}EOF).{1,3}\Z)
Regular expressions
---------------------------------------
Count of multiple used regular expressions: 67
common regex group no 0:
regex='(((\x0A)|(\x0D)|(\x0D\x0A)(0))EOF).{0,2}\Z'
internal IDs: 111,112,113
[…]
I would be pleased about feedback. The code is available under http://andreas-romeyke.de/software.html#_file_formatidentification_pronom .
Have fun!
Montag, 26. Februar 2018
Valid TIFFs need love, too.
(english version below)
Außerdem wurden noch einige weitere Versionen des TIFFs erzeugt, bei denen einige andere Tags verändert, hinzugefügt oder entfernt wurden (Make, Model und Software).
Über einen Kollegen haben wir ein interessantes TIFF erhalten. Es hatte alle Validierungen bestanden und zeigte keine strukturellen Fehler in tiffinfo/tiffdump, ließ sich aber trotzdem im Vorschaubetrachter des Workflowtools nicht anzeigen. Außerdem war es ca. dreimal so groß wie alle anderen Scans aus dem gleichen Vorgang. Er bat uns, das TIFF zu untersuchen.
Im Gegensatz zu ihm habe ich keine Probleme damit gehabt, das TIFF überhaupt zu öffnen; der Windows-Bildbetrachter, IrfanView, MS Paint, Paint.NET und XnViewMP stellten alle das Bild dar. Allerdings war es in der Horizontalen stark gestreckt, d.h. deutlich breiter als erwartet. Große Teile des Bildinhaltes (eine gescannte Zeitschriftenseite) fehlten, und der rechte Rand war nicht sichtbar.
 |
| kaputte Anzeige des TIFFs |
In tiffinfo sahen wir, dass das TIFF ein Grayscale-Image ist:
Bits/Sample: 8
Samples/Pixel: 1
Auffällig war, dass die Listeneinträge für StripByteCounts genau um Faktor 3 größer als die ImageWidth waren (4302 * 3 = 12906); das erklärte die Streckung des Bildes in X-Richtung. Man sah außerdem, dass die StripOffsets in Schritten von 12906 Bytes anwuchsen; vermutlich war der Viewer deswegen überhaupt in der Lage, irgendein Bild anzuzeigen. Die ImageLength stimmte mit der Anzahl der Einträge in StripByteCount überein (6020), deshalb gab es hier keine Verzerrung.
Image Width: 4302
Image Length: 6020
StripByteCounts (279) LONG (4) 6020<12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 ...> StripOffsets (273) LONG (4) 6020<8 12914 25820 38726 ...>
In Okteta konnten wir sehen, dass die Bilddaten für jedes Pixel dreimal identisch gespeichert waren. Das deckt sich der Aussage des Kollegen, dass das Bild ca. dreimal größer war als alle anderen Scans im gleichen Vorgang. Außerdem haben wir gesehen, dass das IFD0 am Dateiende stand und Hinweise auf Bearbeitungen mit IrfanView enthielt.
 |
| normales RGB-TIFF |
 |
| defektes TIFF mit zwei Bytes redundanten Grayscale-Daten je Pixel |
Nachdem wir das Problem verstanden hatten, haben wir Reparaturmöglichkeiten diskutiert:
- Man könnte die Redundanz der Pixel entfernen und die StripOffsets (und wahrscheinlich noch andere Offsets) anpassen. Das wäre wahrscheinlich die sauberere Lösung, müsste aber definitiv mit Softwareunterstützung getan werden.
- Man könnte die SamplesPerPixel auf "3" setzen, um die drei duplizierten Bytes je Pixel als RGB-Kanäle zu interpretieren und damit drei Bytes zu einem Pixel im Bild zusammenzufassen. Das haben wir getan, und es hat funktioniert; zumindest war das Bild anzeigbar, nicht gestaucht und nicht in ausgefallene Farben getaucht.
Zur Ursache des Fehlers gab es nun zwei Theorien:
- Es könnte einen Bitflip gegeben haben, bei dem SamplesPerPixel beschädigt wurde: der Weg von "00 11"B ("0 3" D) zu "00 01"B ("0 1" D) ist nicht weit und würde das Fehlerbild erklären.
- Es könnte einen Fehler bei der Konvertierung eines RGB-Scans von einer Grayscale-Vorlage gegeben haben, bei dem die überzähligen Bytes pro Pixel nicht entfernt wurden. Das SamplesPerPixel Tag wäre dabei korrekt und absichtlich gesetzt worden.
Als erstes haben wir nun also SamplesPerPixel im Hex-Editor auf "3" gesetzt, um den TIFF-Viewer anzuweisen, die Bilddaten als RGB-Bild zu interpretieren. Schon diese kleine Änderung bewirkte, dass sich das Bild fehlerfrei anzeigen ließ. Der Umstand, dass das Bild ungewöhnlich groß war (wir hatten erwartet, dass es ähnlich groß wäre wie die anderen Scans aus der gleichen Zeitschrift), blieb aber vorerst ungeklärt.
 |
| defektes Grayscale-TIFF, als RGB interpretiert |
 |
| korrekte Anzeige des TIFFs |
Wir erwägen, eine Plausibilitätsprüfung für diesen Fehlertyp in checkit_tiff zu implementieren, sofern man davon ausgeht, dass innerhalb eines Bildes alle Strips gleich lang sind. Dazu verwendet man die Formel: "StripByteCounts / SamplesPerPixel / RowsPerStrip = ImageWidth". Am einfachsten funktioniert das mit TIFFs, bei denen RowsPerStrip = 1 ist; andernfalls müssen zusätzlich komplexere Prüfungen durchgeführt werden, weil bei mehrzeiligen Strips, deren Bytelänge nicht ohne Rest ganzzahlig durch die Zeilenanzahl teilbar ist, kein Padding angefügt wird. Dadurch können Rows entstehen, die kürzer sind als die vorderen Rows eines Strips.
Zusätzlich denkbare Plausibilitätsprüfungen wären:
- Die Höhe des Bildes ist genau so lang wie das Produkt aus RowsPerStrip und Anzahl der Strips: ImageLength = RowsPerStrip * StripOffsets.Count
- Jeder StripByteCount muss so groß sein wie die Differenz der dazugehörigen StripByteOffsets: StripByteCounts[0] = StripOffsets[1] - StripOffsets[0] (bzw. allgemeiner StripByteCounts[n] = StripOffsets[n+1] - StripOffsets[n])
- Jeder Strip muss gleich lang sein: StripByteCounts[0] = StripByteCounts[1] = StripByteCounts[2] = ... = StripByteCounts[n]
Diese Möglichkeiten haben wir im größeren Kreis diskutiert, was Andreas neugierig gemacht hat. Er hat also sein neues Tool zum Finden möglicher ehemaliger IFDs in TIFFs um einige weiche Suchkritierien erweitert und es genutzt, um IFDs aus früheren Dateiversionen zu finden. Außerdem hat er ein ganz neues Tool geschrieben, das eine TIFF-Datei und eine Adresse in Hex-Notation einliest und den Inhalt an dieser Adresse so interpretiert, als wäre dort ein IFD gespeichert. Auf diese Weise konnten wir insgesamt sechs frühere IFDs ermitteln, die auf ältere Versionen der Datei hinweisen, und den Inhalt dieser IFDs in Augenschein nehmen. Die Tools sind unter https://github.com/SLUB-digitalpreservation/fixit_tiff/tree/master/src/archeological_tools im Quellcode verfügbar; sie sind Teil des bekannten Tools fixit_tiff.
 |
| Pointer zum ursprünglichen IFD0, wie er in der ersten Version der Datei stand |
Die Ausgabe möglicher IFD-Adressen sieht so aus:
# adress,weight,is_sorted,has_required_baseline
0x4a184b0,2,y,y
0x4a241aa,2,y,y
0x4a2fea4,2,y,y
0x4a3bbb0,2,y,y
0x4a478d0,2,y,y
0x4a535ea,2,y,y
Diese Adressen der IFDs haben wir mittels Hex-Editor als IFD0-Offset in die TIFF-Datei eingetragen und so in einer Art TIFF-Archäologie schrittweise die alten Versionen der Datei wieder hergestellt. Dabei bestätigte sich die Annahme, dass der Scan ursprünglich in RGB abgespeichert worden war. Danach wurde wohl eine fehlerhafte Grayscale-Konvertierung durchgeführt, bei der nur die Tags PhotometricInterpretation (min-is-black) und BitsPerSample (1) verändert wurden. Ob dabei auch die Bilddaten selbst verändert wurden, lässt sich nicht mehr genau rekonstruieren.
# adress,weight,is_sorted,has_required_baseline
0x4a184b0,2,y,y
0x4a241aa,2,y,y
0x4a2fea4,2,y,y
0x4a3bbb0,2,y,y
0x4a478d0,2,y,y
0x4a535ea,2,y,y
Diese Adressen der IFDs haben wir mittels Hex-Editor als IFD0-Offset in die TIFF-Datei eingetragen und so in einer Art TIFF-Archäologie schrittweise die alten Versionen der Datei wieder hergestellt. Dabei bestätigte sich die Annahme, dass der Scan ursprünglich in RGB abgespeichert worden war. Danach wurde wohl eine fehlerhafte Grayscale-Konvertierung durchgeführt, bei der nur die Tags PhotometricInterpretation (min-is-black) und BitsPerSample (1) verändert wurden. Ob dabei auch die Bilddaten selbst verändert wurden, lässt sich nicht mehr genau rekonstruieren.
In der vermutlich ersten Version des IFD0 sieht man mit tiffinfo noch die Angaben zum RGB-Bild:
Photometric Interpretation: RGB color
Samples/Pixel: 3
Die späteren Fassungen dagegen enthalten die Werte:
Photometric Interpretation: min-is-black
Samples/Pixel: 1
Außerdem wurden noch einige weitere Versionen des TIFFs erzeugt, bei denen einige andere Tags verändert, hinzugefügt oder entfernt wurden (Make, Model und Software).
Der Fehler war überhaupt nur aufgefallen, weil es eine intellektuelle Prüfung gab und der Bearbeiterin der Anzeigefehler auffiel (und sie ihn dann auch gemeldet hat!). Weil außerdem die MD5-Summen erst am Ende der Bearbeitung generiert werden und damit zum Fehlerzeitpunkt noch keine Prüfsumme existierte, wäre der Fehler nicht durch einen Fixity-Mismatch aufgefallen. Die einzig saubere Lösung wird nun wohl sein, die Seite neu zu scannen. Trotzdem ist es aber sehr eindrucksvoll zu sehen, welche Möglichkeiten das TIF Format bietet, kaputte Dateien wiederherzustellen.
frühere Artikel zu diesem Thema (also available in English):
-------------------------------------------------------------------------------------------------------------------
english version
Also, there have been later files versions where some other tags have been added, altered or deleted (Make, Model and Software).
frühere Artikel zu diesem Thema (also available in English):
- Restaurierung von kaputten TIFF-Dateien
- repairing TIFF images - a preliminary report
- Some thoughts about risks in TIFF file format
- Image File Directories reparieren
-------------------------------------------------------------------------------------------------------------------
english version
A few days ago, a colleague gave us an interesting TIFF. It had successfully completed all validation attempts and didn't show any signs of structural issues in tiffinfo/tiffdump. However, it was not possible to display the image in the preview of the workflow tool used. Also, it was about three times the size of the other scans in the same intellectual entity. Our colleague asked us to have a closer look at that TIFF, so we went at it.
In contrast to our colleague, I didn't have any problem in displaying the TIFF altogether; the Windows Image Viewer, IrfanView, MS Paint, Paint.NET und XnViewMP all displayed the image correctly. However, it was significantly stretched horizontally, which means that it was a lot wider than expected. Large parts of the scanned newspaper page were missing, and the rightmost part of the image was not visible.
|
| broken display of the TIFF |
In tiffinfo, we saw that the TIFF is a grayscale image:
Bits/Sample: 8
Samples/Pixel: 1
Particularly striking was the fact that the list entries for StripByteCounts was exactly by faktor 3 larger than the ImageWidth (4302 * 3 = 12906), which explained the stretch we saw in the image. Also, you could see that the StripOffsets grew in steps of 12906 Bytes; presumeably that's why the viewer was able to display a picture in the first place, regardless of the final quality. The ImageLength matched up with the number of entries in StripByteCount (6020), which is why there was no stretch in vertical direction.
Image Width: 4302
Image Length: 6020
StripByteCounts (279) LONG (4) 6020<12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 12906 ...> StripOffsets (273) LONG (4) 6020<8 12914 25820 38726 ...>
We could see in Okteta that the image data for each pixel were saved identically three times in a row. That explains our colleagues information about the filesize being three times larger than the other files in that IE. Also, we noticed that the IFD0 was written to the end of the file and contained information about an editing step in IrfanView.
| ||
normal RGB-TIFF
|
After having understood the problem, we discussed possible ways to repair the file:
- We could remove the redundant pixels and adapt the StripOffsets (and quite possibly all other ofsets in that file). While this is the more proper solution, software support for this kind of work would be imperative.
- We could set SamplesPerPixel to"3" to interpret the three duplicate pixels each as three RGB channels, thus summarizing three Bytes into one pixel. We actually did that, and it worked like a charm; at least we could display the image without getting any stretching or funky colors.
Now we had two theories about the origin of this error:
- There might have been a bit flip that damaged SamplesPerPixel. It's not a long way to go from "00 11"B ("0 3" D) to "00 01"B ("0 1" D), and it would explain the error we're seing.
- There could have been an error during a conversion of an RGB scan that was made from an analog grayscale template, during which the unnecessary pixels have not been removed. During this conversion, the SamplesPerPixel tag would have been rightfully set to a new value.
In a first test we set SamplesPerPixel to "3" using a Hex editor in order to command the TIFF viewer to interpret the image data in an RGB fashion. This little change alone caused the image to be displayed without any errors. The puzzle, however, that the image was uncommonly large (we expected it to about ad big as the other scans from the same newspaper) remained unsolved.
|
| defective grayscale TIFF, interpreted as RGB |
|
| TIFF displayed correctly |
We contemplated implementing plausibility checks for this type of error in checkit_tiff, which would be easily feasible assuming that all Strips in an image are of the same length. The following formula could be used: "StripByteCounts / SamplesPerPixel / RowsPerStrip = ImageWidth". This works best for TIFFs with RowsPerStrip = 1 set; other TIFFs would have to undergo more complex checks, because multiline Strips with byte counts that cannot be divided by the row number without modulo may not contain any padding. Due to this, there may be Rows that are shorter that the previous Rows in the same Strip.
Other possible plausibility checks include:
- The image height is exactly as large as the multiplication product of RowsPerStrip and number of Strips: ImageLength = RowsPerStrip * StripOffsets.Count
- Each StripByteCount must be equally large as the difference of the neighboring StripByteOffsets: StripByteCounts[0] = StripOffsets[1] - StripOffsets[0] (or more general StripByteCounts[n] = StripOffsets[n+1] - StripOffsets[n])
- Each Strip needs to be equally long: StripByteCounts[0] = StripByteCounts[1] = StripByteCounts[2] = ... = StripByteCounts[n]
We discussed these possibilities in a larger group, which made Andreas curious, so he sat down to enhance his tool for finding candidates for former IFDs in TIFFs by some soft search criteria. Furthermore, he created an entirely new tool reads a TIFF and interprets the contents at a given address in a way that ressembles the IFD structure. This way, we were able to identify six former IFDs that hint to older versions of this file and inspect these IFDs a little further. The tools are available at https://github.com/SLUB-digitalpreservation/fixit_tiff/tree/master/src/archeological_tools in source code, they are part of the established tool fixit_tiff.
|
| Pointer to the original IFD0, just like it was stored in the 1st file version |
The list of possible IFD addresses as given by our tools looks like this:
# adress,weight,is_sorted,has_required_baseline
0x4a184b0,2,y,y
0x4a241aa,2,y,y
0x4a2fea4,2,y,y
0x4a3bbb0,2,y,y
0x4a478d0,2,y,y
0x4a535ea,2,y,y
We inserted these IFD addresses into the file's IFD0 offset pointer using a Hex Editor. Step by step, using this method, we were able to recreate older versions of the file in an archaeology style of work. In the course of the work we could confirm that the scan was originally saved in RGB. Later, there must have been an error in a grayscale conversion where only the tags PhotometricInterpretation (min-is-black) and BitsPerSample (1) were changed. We were not able to find out if the image data had been altered as well.
# adress,weight,is_sorted,has_required_baseline
0x4a184b0,2,y,y
0x4a241aa,2,y,y
0x4a2fea4,2,y,y
0x4a3bbb0,2,y,y
0x4a478d0,2,y,y
0x4a535ea,2,y,y
We inserted these IFD addresses into the file's IFD0 offset pointer using a Hex Editor. Step by step, using this method, we were able to recreate older versions of the file in an archaeology style of work. In the course of the work we could confirm that the scan was originally saved in RGB. Later, there must have been an error in a grayscale conversion where only the tags PhotometricInterpretation (min-is-black) and BitsPerSample (1) were changed. We were not able to find out if the image data had been altered as well.
Ttiffinfo shows these information from the preusmeable 1st IFD0 version of the RGB image:
Photometric Interpretation: RGB color
Samples/Pixel: 3
Later versions, however, contain the values:
Photometric Interpretation: min-is-black
Samples/Pixel: 1
Also, there have been later files versions where some other tags have been added, altered or deleted (Make, Model and Software).
The error was only even discovered because intellectual checks were in place and the human operator noticed the error in displaying the TIFF (and because she decided to inform our colleague of this oddity!). Also, because checksums are only generated after the processing workflow is completed, we wouldn't have noticed the error by a fixity mismatch. We simply didn't have any checksums yet to compare the image against. In the end, the only proper solution will be a rescan of that newspaper page. However, it's still impressive to see the possibilities that TIF offers to repair seemingly broken images.
former articles on this subject (also available in English):
Montag, 12. September 2016
Die schlechten ins Kröpfchen, die guten ins Töpfchen
(english version below)
Diese Woche wurde die Bitte an uns herangetragen, uns zu überlegen, wie wir mit invaliden Dateien umgehen, für die wir im Rahmen einer Dienstleistung die Langzeitarchivierung anbieten.
Die Frage kam auf, weil mit dem Dienstnehmer gerade die Übernahmevereinbarung verhandelt wird und wir für unsere eigenen Workflows strenge Validitätskriterien ansetzen.
Zuerst waren wir verunsichert. "Ja, man müsste die validen und invaliden Dateien ja im gleichen Speicher zusammenhalten", aber auch "wenn, dann müssten wir diese Dateien aber als valide oder invalide markieren".
Oder auch: "Die Submission Application könnte doch validieren und je nach Ergebnis die Daten in den einen oder anderen Workflow schieben".
Wir beide haben uns hingesetzt, nochmal unser LZA-System angeschaut und uns intensiver Gedanken dazu gemacht.
Unsere Software erlaubt es nicht, invalide Dateien in das LZA zu lassen. Man muss sich vorher für einen Workflow die Qualitätsparameter überlegen. Wenn wir eigene Validatoren benutzen, können die Qualitätsparameter (Policies) frei gewählt sein. Wir könnten jeden Mist durchlassen oder eben nur streng definierte Qualitätsperlen.
Für diesen Workflow wird all das Material ins Archiv gelassen, das diese erfüllt.
Sind die Anforderungen nicht erfüllt, landen die SIPs beim 'technical analyst', der nur die Wahl hat zwischen
Eine Mischung von "validen" und "invaliden" Dateien bleibt aber auch nach längerer Überlegung nicht sinnvoll:
Die strikte Trennung der Workflows in unserem Archivsystem dient ja gerade dazu, die IEs à la Aschenputtel "die schlechten ins Kröpfchen, die guten ins Töpfchen" zu sortieren.
Damit steigt die Grundqualität in den jeweiligen Workflows und, dies ist entscheidend, man hat im Falle der Formatmigration weniger Fehlerfälle und geringeren Aufwand.
Durch eine, wie auch immer geartete, Markierung, die in unserem System aber nicht direkt möglich ist, würden wir die Einhaltung unserer eigenen Policies gefährden.
Dies führte dann auch dazu, dass man sich von der Maxime leiten ließe, "später (wenn wir mehr Personal/Zeit/bessere Technik haben) können wir das ja vielleicht mal reparieren". Dass dieser Ansatz funktionieren soll, konnte uns bisher kein Archiv zeigen.
Eine Validierung innerhalb der Submission Application ist genauso wenig sinnvoll. Sie soll weder jetzt noch zukünftig die Aufgaben des Archivsystems übernehmen. Dies würde sonst dazu führen, dass man Teile des bestehenden LZA-Systems selbst nachbauen würde.
Gegenüber dem Dienstnehmer würden wir so argumentieren, dass dieser ja bei uns die Dienstleistung "Langzeitarchivierung" einkauft. Wir werden bezahlt, ihre Qualität hochzuhalten, oder in Prosa: "Der regelmäßige Tritt in den Hintern des Dienstnehmers führt zu Glücksgefühlen und ist ihm viel Geld wert."
Wer das nicht für sinnvoll erachtet, dem dürfte ein einfacher Sicherungsdienst ausreichen. Dafür gibt es genügend Anbieter am Markt.
Damit würden all die IEs, die valide sind weiter in den Langzeitspeicher wandern und wären bestens langzeitarchiviert.
Und all jene IEs, die nicht vollumfänglich valide sind, landen im Speicherbereich des 'technical analyst' und würden bei Reparatur oder nach spätestens 10 Jahren dort gelöscht. Dieser Speicherbereich sichert dann dem Dienstnehmer nur 'bitstream preservation' zu und für diesen bleibt das Risiko und der Reparaturaufwand transparent.
Der Druck die IEs sauber ins LZA-System einzuliefern kommt durch die deutlich höheren Speicherkosten für den Zwischenspeicherbereich zustande, da dieser auf auf Festplatten und nicht auf Band basiert.
Our software does not allow invalid data into the permanent repository. The quality parameters for each workflow have to be concepted in advance. If we use our own validators, the policy for the quality parameters can be chosen freely. We either could allow any crap or just maticulously chosen pearls of quality through to our permanent repository. For the workflow that will be configured, all material that complies with whatever policy we set up will be let through to the permanent storage. If the requirements aren't met, the SIPs end up with the 'technical analyst', who now has to choose between:
The 'technical analyst' cannot move the SIP between workflows.
In conclusion, mixing "valid" and "invalid" files doesn't seem sensible. The strict workflow separation in our preservation system is there for the sole purpose of sorting the SIPs like Cinderella dit with the lenses: "The good must be put in the dish, the bad you may eat if you wish." This increases the basic quality level for corresponding workflow and, this is very important, lowers the efforts and number of error cases in case of a format migration.
By using whatever kind of flagging (which isn't possible with our current system), we would endanger the enforcement of our own policies. This would make us follow the maxime that "we can fix this later, once we have more personnel/time/better technology". However, until now, no archive could show us proof that this concept actually worked.
Running the validation inside of the Submission Application isn't sensible, either. It's not the Submission Application's job to take over any tasks from the preservation system. Memory institutions generally will want to avoid re-implementing parts of the preservation system.
In a discussion with our customer we would argue that they are paying us for the service of preserving their content and keeping it useable over long time periods. We are paid to keep their quality high, or to paraphrase: "Kicking the customers' bottoms is part of the service that you are paying us a lot of money for and is useful for both sides alike." Any institutions that don't think this is necessary will be better off using one of plenty of normal backup services available on the market.
 |
| Quelle: Wikisource, public domain |
Die Frage kam auf, weil mit dem Dienstnehmer gerade die Übernahmevereinbarung verhandelt wird und wir für unsere eigenen Workflows strenge Validitätskriterien ansetzen.
Zuerst waren wir verunsichert. "Ja, man müsste die validen und invaliden Dateien ja im gleichen Speicher zusammenhalten", aber auch "wenn, dann müssten wir diese Dateien aber als valide oder invalide markieren".
Oder auch: "Die Submission Application könnte doch validieren und je nach Ergebnis die Daten in den einen oder anderen Workflow schieben".
Wir beide haben uns hingesetzt, nochmal unser LZA-System angeschaut und uns intensiver Gedanken dazu gemacht.
Unsere Software erlaubt es nicht, invalide Dateien in das LZA zu lassen. Man muss sich vorher für einen Workflow die Qualitätsparameter überlegen. Wenn wir eigene Validatoren benutzen, können die Qualitätsparameter (Policies) frei gewählt sein. Wir könnten jeden Mist durchlassen oder eben nur streng definierte Qualitätsperlen.
Für diesen Workflow wird all das Material ins Archiv gelassen, das diese erfüllt.
Sind die Anforderungen nicht erfüllt, landen die SIPs beim 'technical analyst', der nur die Wahl hat zwischen
- "Reject", also Zurückweisung mit Option des erneuten Ingests
- "Decline" als generelle Abweisung oder
- direkte Reparatur innerhalb der 'technical analyst'-Workbench
Eine Mischung von "validen" und "invaliden" Dateien bleibt aber auch nach längerer Überlegung nicht sinnvoll:
Die strikte Trennung der Workflows in unserem Archivsystem dient ja gerade dazu, die IEs à la Aschenputtel "die schlechten ins Kröpfchen, die guten ins Töpfchen" zu sortieren.
Damit steigt die Grundqualität in den jeweiligen Workflows und, dies ist entscheidend, man hat im Falle der Formatmigration weniger Fehlerfälle und geringeren Aufwand.
Durch eine, wie auch immer geartete, Markierung, die in unserem System aber nicht direkt möglich ist, würden wir die Einhaltung unserer eigenen Policies gefährden.
Dies führte dann auch dazu, dass man sich von der Maxime leiten ließe, "später (wenn wir mehr Personal/Zeit/bessere Technik haben) können wir das ja vielleicht mal reparieren". Dass dieser Ansatz funktionieren soll, konnte uns bisher kein Archiv zeigen.
Eine Validierung innerhalb der Submission Application ist genauso wenig sinnvoll. Sie soll weder jetzt noch zukünftig die Aufgaben des Archivsystems übernehmen. Dies würde sonst dazu führen, dass man Teile des bestehenden LZA-Systems selbst nachbauen würde.
Gegenüber dem Dienstnehmer würden wir so argumentieren, dass dieser ja bei uns die Dienstleistung "Langzeitarchivierung" einkauft. Wir werden bezahlt, ihre Qualität hochzuhalten, oder in Prosa: "Der regelmäßige Tritt in den Hintern des Dienstnehmers führt zu Glücksgefühlen und ist ihm viel Geld wert."
Wer das nicht für sinnvoll erachtet, dem dürfte ein einfacher Sicherungsdienst ausreichen. Dafür gibt es genügend Anbieter am Markt.
Fazit
Manchmal braucht es ein paar Minuten nochmal über die eigene Rolle als Langzeitarchivar nachzudenken. Und es ist gut, wenn wir uns auch unter Druck diese Zeit nehmen.Nachtrag
Eine weitere Möglichkeit wäre, in unserem Langzeitarchivsystem den Speicherbereich, in dem die Fälle des 'technical analyst' landen, stärker abzusichern (zB. durch 3-fache Kopien).Damit würden all die IEs, die valide sind weiter in den Langzeitspeicher wandern und wären bestens langzeitarchiviert.
Und all jene IEs, die nicht vollumfänglich valide sind, landen im Speicherbereich des 'technical analyst' und würden bei Reparatur oder nach spätestens 10 Jahren dort gelöscht. Dieser Speicherbereich sichert dann dem Dienstnehmer nur 'bitstream preservation' zu und für diesen bleibt das Risiko und der Reparaturaufwand transparent.
Der Druck die IEs sauber ins LZA-System einzuliefern kommt durch die deutlich höheren Speicherkosten für den Zwischenspeicherbereich zustande, da dieser auf auf Festplatten und nicht auf Band basiert.
The good must be put in the dish, the bad you may eat if you wish.
Just this week we were asked to develop a stretegy for treating invalid data that we provide a digital preservation service for. The question arose because we currently are in the negotiations of the transfer agreement with our customer and we set a very strict quality policy for our own workflows. At first, we were a little uneasy. "Yes, valid and invalid data would need to be kept in the same storage.", but also "if we do this, then we'd have to flag valid and invalid files to keep them apart." Or in other words: "The Submission Application could run the validation and move the data through different workflows, depending on the validation result." So we both sat down, took a deeper look into our preservation system and contemplated a little longer on this problem.Our software does not allow invalid data into the permanent repository. The quality parameters for each workflow have to be concepted in advance. If we use our own validators, the policy for the quality parameters can be chosen freely. We either could allow any crap or just maticulously chosen pearls of quality through to our permanent repository. For the workflow that will be configured, all material that complies with whatever policy we set up will be let through to the permanent storage. If the requirements aren't met, the SIPs end up with the 'technical analyst', who now has to choose between:
- "Reject"ing the ingest with optional re-ingest
- "Decline"ing the ingest and disallowing re-ingest
- immediate repair inside of the 'technical analyst' workbench
The 'technical analyst' cannot move the SIP between workflows.
In conclusion, mixing "valid" and "invalid" files doesn't seem sensible. The strict workflow separation in our preservation system is there for the sole purpose of sorting the SIPs like Cinderella dit with the lenses: "The good must be put in the dish, the bad you may eat if you wish." This increases the basic quality level for corresponding workflow and, this is very important, lowers the efforts and number of error cases in case of a format migration.
By using whatever kind of flagging (which isn't possible with our current system), we would endanger the enforcement of our own policies. This would make us follow the maxime that "we can fix this later, once we have more personnel/time/better technology". However, until now, no archive could show us proof that this concept actually worked.
Running the validation inside of the Submission Application isn't sensible, either. It's not the Submission Application's job to take over any tasks from the preservation system. Memory institutions generally will want to avoid re-implementing parts of the preservation system.
In a discussion with our customer we would argue that they are paying us for the service of preserving their content and keeping it useable over long time periods. We are paid to keep their quality high, or to paraphrase: "Kicking the customers' bottoms is part of the service that you are paying us a lot of money for and is useful for both sides alike." Any institutions that don't think this is necessary will be better off using one of plenty of normal backup services available on the market.
Conclusion
It sometimes might take a few extra minutes to contemplate one's own role as a digital preservationist. And it's good to take this time even and especially when we're under pressure.Adendum
Another alternative of solving this issue could be to further secure the storage area of our preservation system that is reserved for SIPs that end up in the 'technical analyst' workbench, i.e. by providing three copies on storage layer. All valid IEs would keep going directly to the permanent repository and be cared for perfectly. All those IEs that are not fully valid would end up in the 'technical analyst's storage, where they could be stored for no longer than 10 years before being deleted. For this storage area, we'd only guarantee 'bitstream preservation', with the risk and the effort needed for repair operations being transparent for the customer. A further incentive to ingest "clean" IEs only into the preservation system is generated by the considerabely higher cost of for this storage area, as it is based on hard disk drives instead of the cheaper tape storage.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:
- digitale Objekte verschwinden schnell und dann vollständig, während Bücher nur ganz, ganz langsam zu Staub zerfallen
- 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.
Abonnieren
Posts (Atom)