Dienstag, 9. Dezember 2014

Verlustfreie Videocodecs in der Langzeitarchivierung – Ein Vergleich

Verlustfreie Videocodecs haben den Charme, daß man zum einen sein Videomaterial für die digitale Langzeitarchivierung normalisieren kann und zum anderen, daß bei Formatmigrationen eine automatische, pixelgenaue Inhaltsprüfung die korrekte Migration vereinfacht.

Hinzu kommt, daß sich das digitale Videomaterial bei den Formatwandlungen nicht weiter verschlechtert.

Für den Test habe ich den Trailer zum Film "Sentinel" verwendet. Der Film von der Blender Foundation ist frei unter Creative Commons erhältlich und ermöglicht daher jedem die Testergebnisse zu verifizieren und an eigene Tests anzupassen.

Der Trailer war zum Zeitpunkt des Testes nur als DivX-HD verfügbar, so daß die y-Auflösungen von 1080 Pixeln mit Vorsicht zu genießen sind, da das Ursprungsmaterial dabei hochskaliert wurde.

Im folgenden die Ergebnisse (auf Megabytes gerundet):


Codec Auflösung



1080 720 576
Orig DivX_Plus 27


FFV1 v1
402 228 160
FFV1 v3 2pass 333 198 139
FFV1 v3
360 215 153
h264lossless 432 240 168
h264
20 11 7,3
mjp2000
463 261 183
mpeg2
24 11 7,2

MPeg2 läuft außer Konkurrenz mit, da nach der Kodierung deutliche Artefakte sichtbar sind.

Hier nochmal die Werte normiert auf den jeweils besten Kompressionswert:


Codec Auflösung



1080 720 576
Orig DivX_Plus 27


FFV1 v1
20 21 22
FFV1 v3 2pass 17 18 19
FFV1 v3
18 20 21
h264lossless 22 22 23
h264
1 1 1
mjp2000
23 24 25
mpeg2
1 1 1

Wie man erkennt, brauchen die Lossless Codecs im Schnitt die 20-fache Speichermenge, wobei sich das Verhältnis bessert, je höher die Auflösung des Quellmaterials wird. Im Test ist außerdem aufgefallen, daß Motion Jpeg2000 (mjp2000) mit Abstand die höchste Rechenzeit an den Tag legte, während FFV1 das Videomaterial nahezu in Echtzeit kodierte.

In meinen Augen sollten sich die Langzeitarchive bemühen, die Kodierungseffizienz der lossless-Codecs durch Förderung fähiger Entwickler zu steigern. Wenn man zB. FFV1 v1 mit FFV1 v3 vergleicht, so wurde die Kodierungseffizienz um nahezu 10% gesteigert.

Trotz des um ca. Faktor 20 höheren Speicherplatzverbrauchs von lossless Codecs gegenüber verlustbehafteten Verfahren würde ich erstere bevorzugen. Auch wenn noch Tests notwendig sind, die die Bitfehleranfälligkeit der verschiedenen Codecs miteinander vergleichen, so kann man festhalten, daß zumindest die Entwickler von FFV1 sich bereits Gedanken dazu gemacht haben, wie man die Auswirkung dieser Fehler begrenzen kann

Script


Das Script für den Test ist relativ schnell geschrieben:

#!/bin/bash
# tests some codecs and reduced screen sizes
# orig is: Sintel_Trailer.1080p.DivX_Plus_HD.mkv
# from  http://download.blender.org/durian/trailer/
orig=Sintel_Trailer.1080p.DivX_Plus_HD.mkv
for scanlines in 576 720 1080; do
 call="ffmpeg -i $orig -acodec copy -vf scale=-1:$scanlines -y "
 codec=ffv1; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=ffv1; variant=v3slices; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 # ffmpeg -i  -threads 8 -an -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 1 -passlogfile my_passlog 
 #ffmpeg -i  -threads 8 -acodec copy -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 2 -passlogfile my_passlog 
 # 
 codec=ffv1; variant=v3slices2pass; $call -an -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 1 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 rm -f Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=ffv1; variant=v3slices2pass; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 2 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=mpeg2video; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=dirac; variant=standard; $call -threads 8 -g 1 -c:v libschroedinger -qscale:v 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=h264lossless; variant=standard; $call -threads 8 -g 1 -c:v libx264 -preset fast -qp 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=jpeg2000; variant=standard; $call -threads 8 -g 1 -c:v libopenjpeg Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
 codec=h264lossy; variant=standard; $call -threads 8 -c:v libx264 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
done
rm -f log.*.log


Weiteres


* Infos zu Vor- und Nachteilen von FFV1 und Motion JPeg2000: https://groups.google.com/forum/#!topic/archivematica/HulV96gJ0go
* Evaluation von FFV1: http://web.archiveorange.com/archive/v/4q4BhyAYa6Fk89AqurTY
* Weiterer Vergleich von FFV1: http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ffv1_sizediff-mthk-yuv.html

Dienstag, 7. Oktober 2014

Statt robuster, einfacher Dateiformate, lieber starke Kompression und Vorwärtsfehlerkorrektur?

Gezielte Redundanz?

Quelle: Dt. Fotothek


Auf der DV-Tagung der Max-Planck-Gesellschaft 2014 kam während eines Vortrages eine interessante Frage auf: „Warum nicht bestmögliche Kompression verwenden und das komprimierte Objekt dann mit gezielter Vorwärtsfehlerkorrektur behandeln?

Die Idee hat was. Hier ein paar der gesammelten Argumente pro und contra:

Pro

  • Spart Plattenplatz zumindest bei stark redundanten Dokumenten, wie zB. Videomaterial
  • An den Schutzgrad anpassbare Fehlerkorrektur. Wenn Material plötzlich besonders gesichert werden muss, dann kann man den Schutzgrad individuell erhöhen
  • Gerade für Objekte, für die nur Bitstream Preservation in Frage kommt, kann individuellerer Schutzgrad festgelegt werden
  • Zahl der Kopien kann ggf. auf zwei reduziert werden
  • Redundanz wird zielgerichtet ausgenutzt

Contra

  • erhöhter Aufwand beim Erstellen und Prüfen der Vorwärtsfehlerkorrektur
  • es ist immer "Auspacken" notwendig um auf die Inhalte zuzugreifen
  • Das Verpacken ist eine zusätzliche Fehlerquelle
  • Kompression und Vorwärtsfehlerkorrektur sind sehr rechenaufwändig
  • Funktioniert nur, wenn sich durch Kompression mehr an Bits einsparen lässt, als für die angestrebte Fehlerkorrektur notwendig ist
  • Für die richtige Auswahl des Schutzes sollte Bitfehlerverteilung bekannt sein
  • Komplexität erschwert das Verständnis des Inhaltes

Eine kleine Rechnung


Nehmen wir mal als Beispiel einen klassischen Buch-Scan in 300dpi. Als unkomprimiertes Bild (mit 1717x1027 Pixeln) im TIFF 6.0 baseline belegt es 31MB.

Mit jpeg2000 baseline ist das Bild auf 17MB (verlustfrei) eingedampft (PNG 18MB). Damit stünden 31-17=14MB für künstliche Redundanzen zur Verfügung.

Unter Verwendung von vdmfec wäre es beispielsweise möglich, diese Redundanzen hinzuzufügen. Mit den Default Werten von n=18 und K=14 und der  eingestellten Blockgröße von 1024*1024Bytes=1MB würden n=18 Blöcke für jeden der K=14 Eingabeblöcke geschrieben, es könnten also n-K=4 aus jeder der n-Blöcke verloren gehen.

Für das obige Bild würden sich dann 22MB Speicherplatz für die gesicherte Fassung ergeben.

In dem Fall ließe sich eine Ersparnis von 31-22=9MB erzielen und das Bild wäre trotzdem gegen Blockverluste geschützt.

Leider kodiert vdmfec nicht die Parameter bei der Erstellung der fehlerkorrigierten Datei mit. Welche Vorwärtsfehlerkorrekturprogramme bzw. -formate sinnvoll wären,  wäre dann aber einen eigenen Beitrag wert.

Montag, 1. September 2014

Dateiformat-Explosion

Vorwort


Zum Bibliothekartag 2014 gab es im Nachtrag zu unserem Vortragsblock eine rege Diskussion darüber, ob es sinnvoll ist, erst einmal alle Dateien in ein Langzeitarchiv aufzunehmen und sich später Gedanken darüber zu machen, wie man deren Langzeitverfügbarkeit z. B. durch Formatmigration sicherstellt.

Ich habe viel recherchiert, aber wenig belastbare Zahlen gefunden. Ein guter Indikator könnten die Signaturen für DROID sein, einem Programm zur Ermittlung des Datenformates unbekannter Dateien.

Auf Pronom findet man 77 Versionen von 08-2005 bis 07-2014, von ehedem 766 bis heute 1.459 von DROID unterstützten Signaturen.

Alternativ könnte man die Datenbanken des Unix-Befehls file (http://www.darwinsys.com/file/) heranziehen. Auf ftp://ftp.astron.com/pub/file/ findet man Versionen von 08-2008 bis 06-2014.

Eine andere Möglichkeit wäre, die bei der IANA registrierten MIME-Types (zur Zeit 1.087 verschiedene Signaturen) heranzuziehen: http://www.iana.org/assignments/media-types/media-types.xhtml

Außerdem wurde ich noch auf http://fileformats.archiveteam.org/wiki/Main_Page aufmerksam gemacht.

Leider gibt es zu den letzten beiden Links keine auswertbare Timeline.

Was uns 'file' verrät


Wir können annehmen, dass sowohl bei 'file' als auch bei DROID, die Signaturen in gewisser Weise die Dateiformate enthalten, die auch weit verbreitet sind. Wie stark wissen wir nicht, aber wenn sie total unbedeutend wären, hätte sich keiner die Mühe gemacht, für diese Signaturen zu erstellen.

Wir können ferner annehmen, dass nach einer gewissen Einschwingzeit die Zahl der Dateiformate in diesen Signatur-Datenbanken der Anzahl der tatsächlich verbreiteten Dateiformate entspricht.

Im Folgenden das Diagramm der Entwicklung der Dateiformate basierend auf der file Magic Bytes Datenbank von Ende 1999 bis Mitte 2014.

Count of different fileformats based on magic bytes database of file, 08/2014, Andreas Romeyke

Als Grundlage für das Diagramm diente das GIT-Repository von file, genauer das Verzeichnis 'magic/Magdir'. Über die Tags extrahierte ich alle Versionen des Verzeichnisses und ließ das folgende Script die dem Diagramm zugrunde liegende CSV-Datei erstellen:


#!/bin/bash
echo "#version, date, group, count"
for version in *;do
  for sub in $version/magic/Magdir/* ; do
    group=$(basename $sub); 
    count=$(cat $sub | grep "^0" | wc -l);
    date=$(cd $version; git log --name-status --date=raw \
    --pretty='format:commit,%ae,%ai,%ce'| cut -d "," -f 3| head -n 1|\
    cut -d " " -f 1)
    echo "$version, $date, $group, $count"; 
  done ;
done


Sehr überraschend für uns war der nahezu lineare Verlauf der Formatvielfalt. Um auszuschließen, dass dies andere Ursachen hat, war es notwendig, eine zweite, von file unabhängige Quelle heranzuziehen.

DROID/Pronom als Quelle


Die Entwickler von DROID haben, wie oben bereits angedeutet, ihre Signaturfiles von Version 1 bis zur aktuellen Version 77 online angeboten.

Pronom hat als Projekt das Ziel, für Langzeitarchive eine verlässliche Quelle für Dateiformate, Signaturen und zugeordnete Programme bereitzustellen. DROID übernimmt als Programm die Aufgabe der Identifikation unbekannter Formate.

Durch den strukturierten Aufbau der Signaturdateien ist eine automatische Auswertung möglich.

Im Folgenden ist die Anzahl der verschiedenen Dateiformate über die Zeit zu sehen:


Count of different fileformats based on DROID signatures, 08/2014, Andreas Romeyke
Auch hier ergibt sich ein nahezu linearer Zuwachs, spätestens ab Mitte 2010.

Da erst in späteren Signaturen ab ca. 2009 auch MIME-Types hinterlegt wurden, sieht die Entwicklung der einzelnen Kategorien im folgenden Diagramm etwas anders aus:

Count of different fileformats per category, based on DROID signatures, 08/2014, Andreas Romeyke

Hier noch das Shell-Script:

#!/bin/bash
echo "#version, date, application, text, images, audio, video"
for i in droid/DROID_SignatureFile_V*.xml; do
  version=$(echo $i |sed -e "s/.*_V\([^.]\+\).*/\1/" );
  date=$(cat $i | grep -m 1 "DateCreated=" |\
  sed -e "s/.*DateCreated=\"\(....-..-..\).*/\1/" );
  echo -n "$version, $date,"
  for category in application text image audio video; do
    count=$(xmlstarlet sel -t -v\
    "//_:FileFormat[contains(@MIMEType, \"$category/\")]/@Name" $i| \
    sort | uniq | wc -l)
    echo -n "$count,"
  done;
  echo
done | sort -n 

Wenn pro Jahr also 90 neue Dateiformate…


Die Anzahl der  Dateiformate wächst nahezu linear. Pro Jahr kommen im Schnitt 90 neue Dateiformate hinzu, die immerhin eine solche Verbreitung erfahren, dass sie in den Signatur-Datenbanken Widerhall finden.

Wenn wir in Zeiträumen von 50 Jahren denken, haben wir knapp 5000 Formate zu behandeln.

Wer alles in sein Langzeitarchiv hineinkippt, was ihm seine Nutzer anbieten, wird daher in Zukunft kaum die Ressourcen haben, Spreu und Weizen zu trennen und eine Langzeitverfügbarkeit sicherzustellen.

Die Entwicklung zeigt, dass dringend eine Spezialisierung der Langzeitarchive notwendig ist, um Wissen über Formate aufzubauen und sich gegenseitig zu unterstützen.

Es zeigt auch weiterhin, dass Nutzer der Archive über die Problematik aufgeklärt werden müssen.

Freitag, 15. August 2014

Was vom Buche übrig blieb

Diese Frage stellt sich, wenn ein digital archiviertes Buch nach Jahrzehnten der Aufbewahrung hervorgeholt wird.

Old book bindings.jpg
"Old book bindings" by Tom Murphy VII - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

 

Leidvolle Erfahrung


Vor einigen Jahren war es üblich, Scans aus Speicherplatzgründen ausschliesslich in s/w abzuspeichern. Als dann die Archive und Bibliotheken diese Digitalisate wieder hervorholten, um diese einer OCR-Erkennung zuzuführen, mussten sie feststellen, dass das pure Speichern als unbereinigte s/w-Grafik zwar noch reichte, damit ein Mensch den Text erkennen konnte. Doch die Qualität reichte nicht aus, um mit OCR-Programmen vernünftige Ergebnisse¹ zu erzielen.

Wer heutzutage digitalisiert, kann von diesen leidvollen Erfahrungen profitieren. Die Deutsche Forschungsgemeinschaft hat die best-practices gesammelt und Empfehlungen für die Digitalisierung herausgegeben.

¹(sh. http://www.landesarchiv-bw.de/sixcms/media.php/120/Werkheft_Staatl_Archiv.pdf, Artikel "Automatische Texterkennung bei digitalisiertem Archiv- und Bibliotheksgut", von Thomas Fricke und Gerald Maier, S.201ff.)

Langzeitarchivierung, für wen eigentlich?

Langzeitarchivierung ist ebensowenig ein Selbstzweck, wie es die Digitalisierung von historischen Beständen ist. In beiden Fällen ist der Zweck, die historischen Beständen den Nutzern zur Verfügung zu stellen. Nicht umsonst wird zunehmend statt von Langzeitarchivierung eher von Langzeitverfügbarkeit gesprochen.

Ein notwendiger Blick in die Glaskugel


Um sicherzustellen, dass archivierte Dokumente tatsächlich für die Nutzer nutzbar sind, muss bereits vor dem ersten Einstellen der Dokumente ins Langzeitarchiv überlegt werden, welche möglichen Nutzungsszenarien für diese in Frage kommen könnten.

Aus dem einleitenden Beispiel wird klar, dass bestimmte Eigenschaften eines Dokumentes für bestimmte Nutzungsarten eine signifikante Rolle spielen. Für die Möglichkeit der OCR-Nutzung wären dies bei den Scans hinreichender Kontrast, ausreichende Auflösung (300-400dpi) und die Unterscheidbarkeit zwischen eigentlicher Schrift und irgendwelchen Flecken.

Wir haben bei der Bestimmung dieser notwendigen Eigenschaften erst durch den Blick aus der Nutzerperspektive auf ein bestimmtes Nutzungsszenario herausgefunden, dass wir die eine oder andere Eigenschaft beinahe übersehen hätten.

Für unsere Scans historischer Schriften haben wir im Moment folgende Nutzungsarten gefunden, die vielleicht für den Einen oder Anderen eine erste Anregung darstellen können:

  • (optische) Lesbarkeit
  • visuelle Zuordnung zum Original
  • originalgetreue Reproduktion
  • (re-)OCR
Die (optische) Lesbarkeit ist nichts Anderes, als dass der Nutzer den Text des Scans entziffern kann. In dem Fall würde oft eine Auflösung von 100dpi reichen, der Scan könnte in s/w vorliegen und Farbe dürfte keine Rolle spielen.

Die visuelle Zuordnung zum Original meint, dass man irgendwie einschätzen kann: "Ah, das ist Fraktur, die Grafiken sind barocke Kupferstiche und das Wappen sieht irgendwie sächsisch aus." In dem Fall muß man nicht unbedingt die Schrift entziffern können. Man könnte sich ein Vorschaubildchen zu einem Buch vorstellen, welches einen ersten Eindruck vermittelt.

Die originalgetreue Reproduktion sollte das Buch bestmöglich wiederherstellbar machen. Für Drucke ist eine Auflösung von mindestens 600dpi notwendig, die Farben und die Abmessungen sollten dem Original entsprechen und Vergrößerungen eventuell möglich sein.

Für OCR wäre es dagegen sinnvoll, Auflösungen zwischen 300 und 400 dpi zu haben und eine Farbabbildung, die ein digitales Entfernen von Flecken und anderen Störungen ermöglicht.

Wenn man für die einzelnen Nutzungsszenarien die damit einhergehenden Eigenschaften bewertet, gegeneinander abwägt und nach den Punkten
  • unbedingt zu erhalten,
  • möglichst zu erhalten,
  • nice to have,
  • nicht erhaltenswert
sortiert, erhält man eine Liste der signifikanten Eigenschaften.

Diese Eigenschaften sollten bei Erhaltungsmaßnahmen, wie zB. Formatmigration (zB. von TIFF nach JPEG2000) entsprechend berücksichtigt werden.

Donnerstag, 3. Juli 2014

Snow Byte…

In letzter Zeit haben wir ja schon über einige Formate berichtet, hier ein passendes Märchen aus dem Langzeitarchivierungslande:

Freitag, 20. Juni 2014

*grrrr* – Oder wie man mit LaTeX vielleicht ein PDF/A erzeugt

Vorwort


Dieser Beitrag ist entstanden, als ich versucht habe herauszufinden, wie ein Doktorand seine mit LaTeX erstellte Masterarbeit möglichst von Hause aus als PDF/A abliefern könnte.

Damit das nicht zum Rant ausartet, habe ich die einzelnen Punkte sachlich zusammengefasst. Wer mag kann sich ff. Szene dazu vorstellen (links).

Nach aktuellem Stand läßt sich mit LaTeX wenn überhaupt, nur valides PDF/A-1b erstellen.

Nein? Doch! Orrr.

Meine Recherchen zu PDF/A-2b haben keine Resultate erbracht. Eigene Anpassungen an den LaTeX-Paketen hyperref und ggf. hyperxmp bzw. pdfx wären dazu notwendig. Wer hier Infos hat, immer her damit. Auch sonst sind Eure Kommentare gerne gesehen.

 

Schriftarten


PDF/A erwartet, daß alle Schriftarten eingebettet sind. Dies gilt auch für die Schriftarten, die zB. in Diagrammen oder Bildern vorkommen, die unter LaTeX mit \includegraphics{} eingebettet werden.

Mit dem Befehl pdffonts (Teil von Ghostscript) kann man sich ausgeben lassen, welche Schriftarten im PDF verwendet werden und ob diese eingebettet sind (Spalte emb).  LaTeX selbst ist in den meisten Distributionen so konfiguriert, daß das Tool pdflatex Schriftarten in das Dokument einbettet.
Dies sollte man aber trotzdem für alle einzubettenden PDFs (Diagramme etc.) prüfen, da LaTeX diese quasi nur ins zu erzeugende PDF übernimmt.


$> pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
MSQLLN+URWPalladioL-Bold             Type 1            Custom           yes yes yes    480  0
ZWIRUB+URWPalladioL-Roma             Type 1            Custom           yes yes yes    481  0
[none]                               Type 3            Custom           yes no  no     493  0
BAAAAA+CMUSansSerif                  TrueType          WinAnsi          yes yes yes   1669  0
TDAPEI+Arial-BoldMT                  TrueType          MacRoman         yes yes no    1738  0
TNUBAM+Menlo-Regular                 TrueType          MacRoman         yes yes no    1739  0
CTFEKI+ArialMT                       CID TrueType      Identity-H       yes yes no    1740  0
Arial                                TrueType          WinAnsi          no  no  no    3019  0
ABCDEE+Calibri                       TrueType          WinAnsi          yes yes no    3020  0

Unter Linux kann man mit ff. Befehl die Fonts auch nachträglich in PDFs einbetten:
gs \
 -sFONTPATH=/path/to/fonts:/another/dir/with/more/fonts \
 -o output-pdf-with-embedded-fonts.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 input-pdf-where-some-fonts-are-not-embedded.pdf
Falls zB. MS Arial fehlt, das Debian-Paket ttf-mscorefont-installer installieren, die Fonts sind dann unter /usr/share/fonts/truetype/msttcorefonts/ zu finden.
Für Postscript bzw. EPS gilt dies analog.

Kurzum, für alle in ein LaTeX Dokument einzubettenden Grafiken im PDF-Format sollten wir sicherstellen, daß die Fonts eingebettet sind.

Transparenz in Grafiken


Da PDF/A-1b auf PDF Version 1.4 aufbaut, sind Transparenzen im PDF nicht gestattet. Wenn man Grafiken einbettet, sollte man sicherstellen, daß diese keinen Alpha-Channel benutzen. Für PNG etc. kann man GIMP oä. nutzen.

Wenn PDFs (zB. Diagramme etc.) als Grafiken genutzt werden kann man über ff. Kommando prüfen, ob diese Transparenzen enthalten:

$> pdfimages -list test.pdf
page   num  type   width height color comp bpc  enc interp  object ID
---------------------------------------------------------------------
  14     0 image    1762   232  rgb     3   8  image  no       670  0
  14     1 smask    1762   232  gray    1   8  image  no       670  0
  16     2 image      64    94  rgb     3   8  image  no       735  0
  16     3 smask      64    94  gray    1   8  image  no       735  0
  16     4 image      64    94  rgb     3   8  image  no       736  0
  16     5 smask      64    94  gray    1   8  image  no       736  0
  16     6 image     708   134  rgb     3   8  image  no       737  0
  16     7 image     529   135  rgb     3   8  image  no       738  0
  16     8 image     133    18  rgb     3   8  image  no       739  0

Dabei erkennt man am Type "image" gefolgt vom Typ "smask" die relevante transparente Stelle. Aus obiger Ausgabe also diese Zeile:
 
  14     0 image    1762   232  rgb     3   8  image  no       670  0
  14     1 smask    1762   232  gray    1   8  image  no       670  0
Mit ghostscript kann man diese PDFs auch umwandeln, das Ergebnis muß aber kontrolliert werden, weil sich uU. das Aussehen ändern kann:
$> gs \
  -o pdf_without_transparency.pdf \
  -dHaveTransparency=false \
  -sDEVICE=pdfwrite \
  input_with_transparency.pdf

Farbräume


Auch hier sind Vorbereitungen nötig. Da LaTeX einfach nur stumpf die Grafiken in das LaTeX-Dokument einbindet, müssen wir dafür sorgen, daß möglichst alle Grafiken nur einen Farbraum nutzen. Hier kann ebenfalls pdfimages wie oben genutzt werden. Dort ist die Spalte color relevant.

Mit folgenden ghostscript-Aufrufen kann man nachträglich die Farbräume anpassen. Dabei gehen Informationen verloren, so daß man das Ergebnis auf jedenfall durch Sichtkontrolle prüfen sollte.

Für Konvertierung nach sRGB:

$> gs \
    -o output_rgb.pdf \
    -sDEVICE=pdfwrite \
    -dBATCH -dNOPAUSE -dCompatibilityLevel=1.4 \
    -dColorConversionStrategy=/sRGB \
    -dProcessColorModel=/DeviceRGB \
    -dUseCIEColor=true \
    input_cmyk.pdf
Für Konvertierung nach CMYK:
$> gs \
   -o output-cmyk.pdf \
   -sDEVICE=pdfwrite \
   -sProcessColorModel=DeviceCMYK \
   -sColorConversionStrategy=CMYK \
   -sColorConversionStrategyForImages=CMYK \
    input_rgb.pdf
Für PDF/A-1b wäre sRGB zu empfehlen.

Dazu brauchen wir eine Farbprofildatei.  Wir können das Farbprofil von Color.org (sRGB) herunterladen und nach sRGBIEC1966-2.1.icm umbenennen.


Damit wären die wichtigsten Vorbereitungen abgeschlossen. Für  eingebettete PDFs wäre es sinnvoll, wenn diese keine Kompression nutzen würden.

 

Das eigentliche LaTeX-Dokument


Zuerst sollte man sicherstellen, daß man eine aktuelle TexLive-Distribution nutzt. Für die Erstellung der PDFs hat man die Wahl zw. Nutzung des Pakets pdfx oder einer Kombination von hyperref und hyperxmp.
Ich habe mich hier für letztere Variante entschieden.
Zuerst müssen wir das Farbprofil in das LaTeX-Dokument einbinden. Dazu reicht folgender Code im Header:
\immediate\pdfobj stream attr{/N 3}  file{sRGBIEC1966-2.1.icm}
\pdfcatalog{%
/OutputIntents [ <<
/Type /OutputIntent
/S/GTS_PDFA1
/DestOutputProfile \the\pdflastobj\space 0 R
/OutputConditionIdentifier (sRGB IEC61966-2.1)
/Info(sRGB IEC61966-2.1)
>> ]
Das Paket hyperref wird mit der Option pdfa geladen, damit in PDF/A nichterlaubte Optionen nicht aus Versehen gesetzt werden. Das hyperxmp Paket sorgt dafür, dass die für PDF/A zwingend notwendigen Metadaten im XMP Format eingebunden werden:


\usepackage[pdfa]{hyperref}
\usepackage{hyperxmp}
% Beispiel aus hyperxmp-Beschreibung, der Befehl \hypersetup fügt zusätzlich bibliographische Metadaten in das PDF ein:
\author{Albert Einstein}
\hypersetup{%
 pdftitle={%
  On a heuristic viewpoint concerning the production and transformation of light
 },
 pdfauthor={Albert Einstein},
 pdfauthortitle={Technical Assistant, Level III},
 pdfcopyright={Copyright (C) 1905, Albert Einstein},
 pdfsubject={photoelectric effect},
 pdfkeywords={energy quanta, Hertz effect, quantum physics},
 pdfcaptionwriter={Scott Pakin},
 pdfcontactaddress={Kramgasse 49},
 pdfcontactcity={Bern},
 pdfcontactpostcode={3011},
 pdfcontactcountry={Switzerland},
 pdfcontactphone={031 312 00 91},
 pdfcontactemail={aeinstein@ipi.ch},
 pdfcontacturl={%
 },
 pdflang={en},
}
Da PDF/A auf einer eindeutigen Zuordnung Glyphen zu Zeichensatz besteht, müssen dazu noch diese Paket eingebunden werden:
  • glyphtounicode.tex maps glyph names to corresponding Unicode.
  • glyphtounicode-cmr.tex does the same for cmr  fonts

\input glyphtounicode.tex
\input glyphtounicode-cmr.tex 
\pdfgentounicode=1
Nachtrag 2014-06-25: Auf der TeX-Mailingliste kam noch ff. Hinweis:

\usepackage[noTeX]{mmap}

> Even in XeTeX this requires careful use of fonts and mappings.

 mmap.sty  is designed for use with pdfTeX, not XeTeX.

> For example, the Times New Roman font has the "fi" ligature in a
> private area and does not have ligature substitution pointing to it,
> which means if you use it you are in trouble and if you don't you
> won't get your ligature.

mmap.sty  defines CMap resources for the (old) standard TeX fonts.
          More recent fonts do not need what it provides.

If you want to use Times New Roman, then sorry,  mmap  does nothing for you. But you don't want to use TNR for mathematics, do you?
It isn't designed for that.


Da bestimmte Kompression nicht erlaubt ist, ist ff. hilfreich:
\pdfobjcompresslevel=0
\pdfinclusioncopyfonts=1

Nun sollte pdflatex ein PDF/A1-b Dokument erzeugen.

Nachtrag 2014-06-25:  Ebenfalls auf der TeX-Mailingliste war unter Subject "very subtle endobj bug in latest pdftex" folgendes Problem mit pdftex in TeX Live 2014 geschildert:

> It seems that pdftex in TeX Live 2014 is copying
>
>>> \rendobj
>
>
> as
>
>>> endobj
>
>
> ignoring \r.

the problem is in pdftoepdf.cc, line 602:

        pdf_puts(">>");

This problem was in the previous versions of pdftex, too. It's not a serious problem, but yes it would prevent pdf/a validation.

However the fix is not simply to change it to

        pdf_puts(">>\n");

since it would add some unwanted blank lines. I will take a close look during the week.


Zur Validierung kann man das Online-Werkzeug von 3Heights nutzen: http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx