Dieses Thema, das wohl kaum jemand auf dem Schirm haben dürfte, hat mir Werner nahegebracht, Autor von WPMeta. Da ich in dem Thema im Gegensatz zu Werner absolut nicht drinstecke, habe ich Werner gebeten, doch mal einen Artikel dazu zu schreiben.
Teil 1: Überblick der Neuerungen:
„Exchangeable image file format“(Exif) was ist das? Es ist eine Metadaten-Struktur die nützliche Informationen zum Bild enthält. Dabei steht der technische Aspekt im Vordergrund, weniger die Veröffentlichung. Dafür sind andere Standards zuständig (IPTC/IIM (International Press Telecommunications Council/Information Interchange Model), IPTC for XMP Core und Extension, XMP(Extensible Metadata Platform) mit Dublin Core Metadata Initiative (DCMI) etc.). Nun gab es im Mai das finale Update für 3.0, wie es auch auf der IPTC-Webpräsenz am 1. Juni 2023 bekannt gegeben wurde.
Warum dort? Weil IPTC jetzt enger mit JEITA und CIPA zusammen arbeitet und es im vergangenen Jahr größere Konferenzen gab, wo Wünsche und Probleme aufgezeigt werden sollten.
Probleme bei Exif, echt? Ja gibt es. Eines der größten Probleme, neben den MakerNotes-Wildwuchs (Jede Kamerafirma bastelt eigene Notizen in die EXIFs und dokumentieren da nichts.) , sind die Text-Tags (Tag ist die kleinste Informationseinheit und Verzeichniseintrag und gleichzeitig die Kennzahl für diese Informationseinheit).
Historisch bedingt, wurde früher an Platz gespart, wo es ging. Beim Datum (Jahrtausendkrise), aber auch beim Zeichensatz.
JEITA und CIPA gehen jetzt den Weg, einen neuen Datentyp einzuführen, der neben dem Typ ASCIIZ für Text nun auch UTF-8 fest unterstützt und dem Exif-Editor die Wahl lässt, welchen Datentyp er schreiben möchte, dazu mehr in Teil 2.
Dazu werden auch einige neue Text-Tags (Werte) eingeführt: ImageTitle(42038), PhotographerName(42039), ImageEditor(42040), CameraFirmware(42041), RAWDevolopingSoftware(42042), ImageEditingSoftware(42043), MetadataEditingSoftware(42044). Damit will man den Inhalt mehr strukturieren und die Felder Artist(315) und Software(305) entrümpeln.
Das nächste Problem: Die Bilder werden immer größer. Panoramen überschreiten die 64K Marke bei Seitenlängen. Flux wird da die Datenbreite von strukturwichtigen Feldern gelockert und wahlweise von 2 Byte Ganzzahl (Integer) auf wahlweise 4 Byte Integer geändert, oder auch nicht. Das bleibt dem Programm überlassen. Betroffen davon sind ImageWidth(256), ImageLength(257), und wichtig für alle TIFF-Bilder und Strukturen, StripOffsets(273), RowsPerStrips(278), StripByteCounts(237), PixelXDimenstion(40962)(Hinweis: Bild-Originalgröße), PixelYDimension(40963).
Auch ganz wichtig jetzt: Der ab 2.30 eingeführte Wert ImageUniqueID(42016) ist nun zwingend in Version 3.0 vorgeschrieben. Wird einmal vergeben und darf nie verändert werden. Grundlage für die 128-Bit UUID ist ISO/IEC 9834-8 in der Version 1 oder bevorzugt 4. Panorama aus mehreren Bildern mit Originaldaten? Dann darf die ID nicht geändert werden,…. oder doch? Grauzone. Zitat: „…the recorded ID shall not be updateted or erased by any subsequent editing.“
Fest gelegt wurde nun auch, was nie geändert, bei Bedarf geändert, was gelöscht werden darf oder sollte und was nicht.
Leichte Kost zwischendurch: Eine GPS-Definition wurde angepasst auf den neuen Satelliten-Standard. Zudem sind in DeviceSettingDescription(41995) diverse Kameradaten abgelegt. Jetzt gibt es neben UTF-8 auch noch UTF-16….
Weiter zu den größeren Änderungen. Es wird empfohlen, wenn größere Vorschaubilder benötigt werden, diese im erweiterten JPEG-Format MPO (Multi Picture Object) zu speichern. Das ist ein Format, das hauptsächlich für Stereobilder bekannt wurde. In der Baseline-Version können 2 Vorschaubildgrößen darin gespeichert werden und hat da noch die Endung *.JPG. In der erweiterten Version, dann Endung *.MPO, können auch Versionen eines Bildes, Blickwinkel, Panorama-Einzelbilder wie in Tiff-Seiten abgelegt werden. Das aber nur zur Info, da das Format kaum jemand kennt und es sehr empfindlich ist. (Die Olys, die 3D-Bilder erzeugen konnten, z.B. die E-M5, schrieben MPO-Dateien.)
Weitere große Neuerung: Es wird in JPEG-Dateien ein neuer Marker eingeführt, der Exif zugeschrieben wird: APP 11 (JPEG: Application Marker Segment 11). Das sind maximal 64K – 4 Bytes große Datenbereiche innerhalb JPEGs. Hier wurde an die Zukunft gedacht. Wie bei XMP-Segmenten kann der Datenbereich sich über mehrere APP-Segmente erstrecken. Codiert wird der Marker als Box im „JPEG Universal Metadata Box Format“, kurz JUMBF (ISO/IEC 19566-5:2019). Es können darin Bereiche angelegt werden, die ähnlich wie in MWG(Metadata Working Group)-Bereich des XMP abgelegt sind. Gesichtserkennung, Autofokus-Felder etc. in den unterschiedlichsten Formen: Punkte, Linien, Rechtecke, Kreise, Ellipsen (mit Winkel), Polylinien und Polygone. Das „Interessante“ dabei: Es kann sogar in 2 Beschreibungssprachen angelegt werden: XML(Extensible Markup Language) und JSON-LD (JavaScript Object Notation für verLinkte Daten). Näheres dazu in Teil 4
Wir müssen uns auf jedem Fall auf Einiges gefasst machen. Es wird zu Datenverlusten im Austausch mit alten Programmen kommen. Beim Aufruf also Exif sichern und dann anschließend wieder zurück schreiben. Wie schon bei Programmen, die überhaupt kein Exif konnten oder schon immer falsch schrieben. Noch können wir hoffen, dass die Umsetzung dauert. Denn wenn es los geht, dann wird es auch genützt. In Kraft gesetzt ist es schon.
Teil 2: Zeichensatz: Vom Chaos ins Chaos? Quo vadis Exif?
Der älteste Computer-Zeichensatz ist ein 7-Bit-ASCII-Zeichensatz (128-Zeichen), der für PCs und andere Rechnersysteme in den 1980ern auf 8-Bit erweitert wurde. Jetzt gibt es international aber mehr Zeichen als 256 Zeichen, wobei mindestens 27 für Steuerzeichen schon reserviert sind. Jeder Text wurde damals in 8-Bit kodiert. Damit man alle Länder bedienen konnte, wurden sogenannte Codepages eingeführt, um die Texte entsprechend lesen zu können. Dazu kam, dass jeder OS-Hersteller noch sein eigenes Süppchen kochte. Auf den neueren Betriebssystemen kam zudem dann Unicode mit Little Endian und Big Endian Notierung von Zahlen. Little Endian nützt man auf PCs, die kleinste Informationseinheit ist links, Big Endian auf Motorola Rechnerstrukturen, die kleinste Informationseiheit in einem Byte-Stream ist rechts. Das zieht sich durch wie ein Rattenschwanz durch die EDV und schlägt sich auch in TIFF und Exif nieder, dessen Struktur auf TIFF (Tagged Image File Format) aufbaut.
Exif unterstützte nativ eigentlich nur 7-Bit-ASCII-Text außer im UserComment. Da aber niemand „ä“ in „ae“ usw. konvertieren wollte, wurde einfach mit dem Landeszeichensatz Werte geschrieben. Wenn ein Programm das nicht machte, war es altbacken. Innerhalb eines Landes und eines OS (Betriebssystem) keine Problem. Aber es gibt ja den Austausch über Rechnerstrukturen und Länder hinweg. IPTC hat das schon lange erkannt, auch in Mails und Webseiten werden verschiedene Zeichensätze unterschieden und in jedem Dokument festgelegt. Auch für Textdateien gibt es BOMs (Byte Order Mark) für die Kodierung. Sehen wir meist gar nicht!
Mit der MWG-Richtlinie 2.0 von 2010 wurde festgelegt, dass in die Textfelder mit UTF-8 geschrieben werden soll. Wurde mehr oder weniger umgesetzt. Man findest es so oder so.
Mit Version 3.0 sagen CIPA und JEITA dem Chaos den Kampf an. (Asiaten habe da noch ganz andere Probleme wie wir!) Sie führen einen neuen Strukturtyp ein.
Seit 1992 festgeschrieben sind: UNKNOWN(0), BYTE(1), ASCIIZ(2), SHORT(3), LONG(4), RATIONAL(5), SBYTE(6), UNDEFINED(7), SSHORT(8), SLONG(9), SRATIONAL(10), FLOAT(11), DOUBLE(12) und vielleicht noch SUBIFD(13) (Tiff 6 Extension)
Und jetzt kommt: Tadaaa: UTF8(129). Wird im Prinzip gehandelt wie ASCIIZ mit nullterminiertem Text, nur mit der UTF-8 Codepage. Fix. So weit so schön.
Praktisch, nicht?! Man weiß sofort, was für eine Codepage angesprochen wird. Ohne BOM oder sonst irgendwelchen Auszeichnungen. Wäre Tiff nicht schon in der jetzigen Form 31 Jahre alt und Exif 28 Jahre, wäre es die perfekte Methode.
So wird es dann ein Problem für ältere, aber gute Programme, die damit nicht umgehen können. Im besten Falle ignorieren sie den Tag beim Lesen und schreiben ihn ohne Datenbereich. Es meckert vielleicht, weil es eine unbekannte Datenstruktur gefunden hat, die ja eigentlich mit ASCIIZ verbunden wird. Der Exif 3.0 konforme Reader, der das dann ließt, bekommt merkwürdige Zeichen zu sehen. Im schlimmsten Falle zerlegt es das alte Programm wegen Nullverweisausnahme. Für den Typ gibt es keine Rückgabe, womit man nicht rechnet. Ältere Metadatenreader können nicht damit umgehen und man muss sich was Neues suchen etc….(Sind wir ja von OM-System ja schon gewöhnt, also warum auch nicht wegen Exif auf gute alte Tools verzichten).
Meiner Meinung nach wäre es eine bessere Lösung gewesen, wie bei IPTC/IIM, MAPI, TNEF, HTML und diverse andere Beschreibungsstrukturen einen Codepage-Tag einzufügen. Abwärtskompatibel und Nachrüstbar auch für alte Strukturen. So schießt man mit Kanonen auf Spatzen. Mehr dazu im Teil 3.
Stay tuned – morgen geht’s weiter.
Das Nette an UTF-8 ist ja, dass es weitgehend zu einer “ASCIIZ”-Repräsentation einer Zeichenkette kompatibel ist. Tatsächlich geht alles, was (7-Bit-)ASCIIZ ist, automatisch auch als UTF-8 durch. Zeichen mit ISO-10646-Codes von 128 und mehr (also alles, was früher in einem länderspezifischen 8-Bit-Code ausgedrückt worden wäre, plus alles andere – Griechisch, Kyrillisch, Chinesisch, Koreanisch, Japanisch, …) werden zerlegt in mehrere einzelne Oktette, bei denen das 8. (höchstwertigste) Bit gesetzt ist, wobei sich Sequenzen von 2-6 Oktetten ergeben können (man kann immer am ersten Oktett so einer Sequenz sehen, wie viele Oktette noch kommen). Big-Endian und Little-Endian spielen hier keine Rolle, weil wir nur über Oktette reden, nicht über 16-Bit- oder gar 32-Bit-Worte.
Das heißt, wenn man sich eine UTF-8-Zeichenkette, die solche ”ungewöhnlichen” 8-Bit-oder-mehr-Zeichen enthält, in einem Programm anschaut, das nur ASCIIZ mit einer länderspezifischen 8-Bit-Codepage (etwa ISO-8859-15) unterstützt, dann sieht man für jedes der ungewöhnlichen Zeichen eine Folge von (typischerweise) 2 oder 3 “Sonderzeichen” aus der Hälfte der Zeichentabelle jenseits von 127. Das sieht nicht schön aus und ist auch nicht besonders leserlich, sollte aber grundsätzlich funktionieren in dem Sinne, dass es gelesen und geschrieben werden kann, ohne dabei kaputtzugehen. (Wobei Programmierer natürlich wie üblich in der Lage sind, trotzdem jede Menge Mist zu bauen.)
Wir können jedenfalls hoffen, dass Programme wie “exiftool” bald lernen, die verschiedenen Geschmacksrichtungen von EXIF ineinander zu übersetzen.
Hi,
ganz ehrlich? Ich schreibe in Exif nicht mehr viel rein. Vollautomatisch Eigentümer, ein paar Werte aus den Makernotes in die Standardfelder und Copyright. Fertig. Privat kommt der Rest in IPTC/IIM. Für Veröffentlichungen in der Zeitung noch mit IPTC Core for XMP synchronisiert, Kontaktdaten und Gesichtsrahmen mit Text nach MWG. Aus die Maus. Man könnte zwar die Microsoft Tags in Exif zwar auch noch nützen, ist aber mit der weiten Verbreitung von IPTC und Betriebssystem Einbindung nicht mehr nötig. IIM ist zwar ein wenig eingeschränkt, aber seit Lösung des Zeichensatz Problems vor ca. 15 Jahren sauberer und schneller als XMP Metadaten. Ich finde es gut, dass das Council das Format wieder aktiv unterstützt. Der Rest ist Schnickschnack für Presse-Datenbanken.
Schönen Gruß
Werner
PS: Habe schon einige Umcodierungsläufe über die Jahre hinter mir. Kreuz und quer durch alle Metadaten Anbieter. Zeichensätze von 1252 nach ISO 8859-15 nach UTF-8. Ohne Kommandozeile oder dessen Frontends.
Bin mal gespannt ob die PHP-Funktion exif_read_data die neueren Exif-Informationen auslesen kann. Oder wann diese in der PHP-Funktion entsprechend angepasst wird.
“Gesichtserkennung, Autofokus-Felder etc. in den …”
Das wäre nicht schlecht und da dürfte Zusatztools für das Anzeigen der Autofokus-Felder in einigen Jahren Geschichte sein.
Interessantes Thema, was ich vor Jahren auch mal durchforsten musste und festgestellt habe, dass die “orientation tags” von vielen Programmen nicht vollständig, richtig, oder gar nicht gehandhabt wurden. Man kann sich vorstellen, was passiert, wenn man das Bild dann durch verschiedene Programme bearbeitet. Leider handelte es sich um mikroskopische Aufnahmen, denen man die Orientierung nicht wirklich auf Anhieb ansieht. Will man dann aber Panoramen daraus zusammensetzen oder stacken oder man möchte sich gern bei Serienaufnahmen einfach nur zurechtfinden, sollte es schon stimmen. Die meisten wissen gar nicht, dass es nicht vier, sondern 8 Tags gibt (normal + gespiegelte). Welch hübsche Konstellationen es bei der Drehung ergibt, kann man sich hier: “https://sirv.com/help/articles/rotate-photos-to-be-upright/” ansehen. Allein die seltsamen Bezeichnungen sorgen schon für reichlich Verwirrung.