Bilder im Fotoarchiv standardisieren

Veröffentlicht am 6. Juli 2026 · zuletzt aktualisiert am 5. September 2026 / in Fotografie

Kurz gesagt

Das Ziel ist ein einheitliches Archiv, das zugleich webtauglich ist. Neue Fotos und Videos kommen jedoch aus Kameras, Smartphones, Messengern, Cloud-Exporten und alten Sicherungen. Ihre Dateinamen und Zeitangaben folgen selten derselben Logik.

Für die kontrollierte Vorbereitung neuer Bildbestände verwende ich das selbst entwickelte Python-Werkzeug Bilder standardisieren. Es prüft Dateien und Metadaten zunächst in einer Vorschau und bringt sie erst nach meiner Kontrolle in eine nachvollziehbare Form. Das Programm ist ein Hilfsmittel für meinen Arbeitsablauf; die fachliche Namensregel gilt unabhängig von seiner Version.

Das Werkzeug verwendet dauerhafte Identifier aus drei Buchstaben und fünf Ziffern: img01234, vid01234 oder gen01234. Ein generativ bearbeitetes reales Bild bleibt Teil seiner img-Werkfamilie und erhält die Rolle _ai. Zielnamen bleiben vollständig kleingeschrieben und deutsche Umlaute werden zuvor in ASCII umgesetzt. Eingebettetes XMP und vorhandene Sidecars werden getrennt geprüft. Echte Identitätskollisionen werden blockiert, nicht mehr durch (1) verdeckt. Das hilft im Fotoarchiv ebenso wie bei einer späteren Veröffentlichung auf einem Linux-Webserver.

Geeignet für: kontrollierte Eingangsbestände mit Fotos, Videos und XMP-Sidecars.
Nicht gedacht für: eine ungeprüfte Massenumbenennung des gesamten Archivs.

Drei Ebenen auf einen Blick

Das praktische Problem

Die Kamera liefert beispielsweise DSC_0023.JPG, ein Smartphone IMG_7421.HEIC, ein Export eine UUID und ein älteres Video nur einen kaum verständlichen Namen. Das Aufnahmedatum kann im Dateinamen, in EXIF- oder QuickTime-Metadaten oder nur als Dateisystemdatum vorhanden sein.

Würde ich solche Dateien direkt ins Archiv übernehmen, entstünde eine Mischung aus Benennungssystemen. Eine rein manuelle Bearbeitung wäre bei größeren Mengen fehleranfällig. Trotzdem darf Automatisierung nicht einfach raten, Dateien überschreiben oder Bild und Sidecar voneinander trennen.

Die verbindliche Zielregel steht im Artikel Dateibenennung im Familienarchiv. Das Werkzeug setzt diese Regel als kontrollierte Vorstufe um. Der so erzeugte Dateibestand soll nicht für das Web ein zweites Mal umbenannt werden müssen: Archivname und veröffentlichbarer Dateiname folgen derselben technischen Grundregel.

Werkzeug und Versionsstand

Der bisher in diesem Praxisbericht dokumentierte Prüfstand ist Version 1.8.1. Für Version 1.8.3 ist am 5. September 2026 die unten beschriebene formatabhängige Speicherung von PreservedFileName beauftragt. Diese Änderung ersetzt die zwischenzeitliche Sidecar-only-Regel der v1.8.2. Umsetzung und Tests der v1.8.3 sind hier noch nicht als abgeschlossen belegt.

Das Werkzeug verarbeitet unterstützte Fotoformate wie JPEG, PNG, DNG, TIFF, HEIC und HEIF sowie Videos in MOV, MP4, M4V, AVI, MTS und M2TS. Sie kann Dateien im Ausgangsordner umbenennen, in einen Zielordner kopieren oder dorthin verschieben. Beim Kopieren oder Verschieben kann die relative Ordnerstruktur erhalten bleiben.

Die wichtigsten Funktionen im Überblick:

Video-Zusatzdateien wie *_preview.jpg, *_contactsheet.jpg sowie bestimmte _org_- und _norm_-Sidecars werden nicht versehentlich als normale Fotos neu standardisiert.

Der Ablauf in der Praxis

Der Vorschaumodus ist dabei keine unverbindliche Demonstration, sondern die eigentliche Sicherheitsstufe. Das CSV-Protokoll macht nachvollziehbar, warum ein Zielname entstanden ist.

Wie Zeitstempel und Identifier entstehen

Das Ziel folgt dem Muster yyyymmdd_hhmmss_identifier[_rolle][-nn].ext.

Für den Zeitstempel stehen vier Regeln zur Verfügung:

• exif: Metadaten bevorzugen,
• name: den Zeitstempel im vorhandenen Dateinamen bevorzugen,
• earliest: den frühesten vorhandenen Wert verwenden,
• latest: den spätesten vorhandenen Wert verwenden.

Wenn Namens- und Metadatenzeit stark voneinander abweichen, erzeugt das Werkzeug ab dem eingestellten Tageswert eine Warnung.

Die fünfstellige Nummer bildet die stabile Identität beziehungsweise Werkfamilie. Ein bestätigtes _ai-Derivat übernimmt nach Möglichkeit die Nummer des zugehörigen img-Originals. Das konkrete KI-System bleibt ausschließlich in XMP/IPTC. Vor einer Fallback-Vergabe prüft das Werkzeug den einbezogenen Bestand und den Zielordner, damit ein Neustart nicht wieder still bei 00001 beginnt.

Eine reine UUID wird nicht automatisch als WhatsApp-Datei interpretiert. Eine WhatsApp-Kennung entsteht nur bei einem ausdrücklichen Hinweis. Dadurch wird aus unklarem Rekonstruktionsmaterial keine scheinbar sichere Herkunft erfunden.

KI-Klassifizierung nur mit eindeutiger Quelle

Für Bilder wertet das Werkzeug den kontrollierten IPTC-Wert DigitalSourceType aus:

Zu technischen Optimierungen zählen beispielsweise Entrauschen, Schärfen, Weißabgleich oder klassisches Hochskalieren.

Ein Eintrag wie AISystemUsed = ChatGPT genügt nicht für die automatische Einordnung. Ohne eindeutigen DigitalSourceType bleibt die vorhandene Medienklasse erhalten und das Protokoll warnt. Widersprechen sich eingebettetes XMP und Sidecar, werden beide Werte angezeigt und die automatische Umbenennung blockiert. Videos werden in dieser Version nicht automatisch als gen oder mit _ai klassifiziert.

Der standardisierte Dateiname ist eine robuste, sichtbare und technisch leicht auswertbare Kurzkennzeichnung. Er ersetzt nicht die fachliche Dokumentation in XMP/IPTC.

Warum Kleinschreibung und ASCII im Web wichtig sind

Windows behandelt Dateinamen meist ohne Unterscheidung von Groß- und Kleinschreibung. Ein Linux-Webserver unterscheidet dagegen typischerweise zwischen Bild.JPG und bild.jpg. Ein Link kann deshalb unter Windows funktionieren und nach dem Hochladen mit einem Fehler 404 enden.

Das Werkzeug schreibt daher den vollständigen Zielnamen einschließlich Endung klein. Vorher werden deutsche Umlaute lesbar umgesetzt:

Danach werden verbliebene diakritische Zeichen entfernt und der gesamte Zielname kleingeschrieben. Aus einem Identifier oder Zusatz mit Ü wird damit nicht eine wechselnd codierte URL, sondern eine robuste ASCII-Schreibweise.

Das beseitigt drei häufige Fehlerquellen:

• unterschiedliche Groß-/Kleinschreibung zwischen HTML-Link und Datei,
• uneinheitliche Behandlung von Umlauten durch Programme und Übertragungswege,
• schwer erkennbare Abweichungen zwischen Mediendatei und Sidecar.

Die Namensstandardisierung ersetzt trotzdem keine Veröffentlichungsprüfung. Nach dem Hochladen müssen die tatsächlich erzeugten Links gegen die tatsächlich übertragenen Dateinamen geprüft werden.

Webdatei und Datenbank sind nicht dasselbe

Bei einer Umbenennung sind zwei verschiedene Ebenen betroffen:

Ein Beispiel ist Excire Foto. Das Programm unterstützt Suche und Analyse, arbeitet dabei aber mit einem eigenen Katalog. Wird eine Datei außerhalb des Programms umbenannt oder verschoben, kann der Katalog noch auf den alten Ort zeigen. Je nach Arbeitsweise muss der betreffende Ordner anschließend aktualisiert, neu eingelesen oder die Datei neu zugeordnet werden. Ein vorhandenes Vorschaubild in einer Datenbank beweist nicht, dass die physische Datei unter diesem Namen noch existiert.

Für das Web gilt die umgekehrte Konsequenz genauso deutlich: Eine korrekte Zuordnung in Excire oder einer anderen Bildverwaltung repariert keinen falschen URL-Pfad. Der Webserver liefert ausschließlich die Datei aus, deren physischer Name und Pfad zum Link passen.

Deshalb gilt in meinem Ablauf:

1. Zuerst wird der physische Bestand kontrolliert standardisiert.
2. Danach werden Bildverwaltungen und Kataloge mit diesem Bestand abgeglichen.
3. Für eine Veröffentlichung werden Links aus den tatsächlichen Dateinamen erzeugt oder gegen sie geprüft.

Die Datenbank ist ein Arbeits- und Suchwerkzeug. Die dauerhaft maßgebliche Grundlage bleiben die Datei, ihr korrekter Name und ihre XMP/IPTC-Metadaten. XMP kann eingebettet oder in einem vorhandenen Sidecar gespeichert sein. Mehr dazu steht in Excire Foto im Fotoarchiv und im Grundsatzartikel Die Wahrheit liegt auf der Festplatte.

Eingebettetes XMP und Sidecars

XMP ist ein Metadatenstandard und keine zwingend separate Datei. Das Werkzeug prüft deshalb zuerst eingebettetes XMP und zusätzlich ein vorhandenes Sidecar. Ein fehlendes Sidecar ist kein Fehler und wird nicht allein wegen PreservedFileName neu erzeugt.

Ist ein Sidecar vorhanden, wird es bei allen drei Operationen zusammen mit der Mediendatei umbenannt, kopiert oder verschoben. Beide erhalten denselben Basisnamen:

20260605_190802_img00023.jpg
20260605_190802_img00023.xmp

Verbindliche Archivregel: JPG/JPEG, TIF/TIFF, PNG, DNG und HEIC/HEIF führen gepflegte XMP-Metadaten eingebettet in der Mediendatei. Proprietäre RAW-Dateien bleiben unverändert; Metadatenpflege erfolgt dort über zugeordnete XMP-Sidecars. In meinem regulären Workflow bleiben die RAW-Originale in Archiv\_Originale, während die daraus erzeugten DNG-Dateien den erschlossenen Archivbestand bilden. Vorhandene historische Sidecars werden nicht automatisch gelöscht oder zusammengeführt.

Umsetzungsstand dieses Werkzeugs: Die allgemeine Archivregel ist nicht gleichbedeutend mit einer abgeschlossenen Implementierung im Standardisierer. Dessen v1.8.3 ist weiterhin nicht abgenommen; die folgende bisher beauftragte Funktionsregel umfasst noch keine eingebetteten Schreibvorgänge für PNG und HEIC/HEIF. Der separate IPTC-AI-Metadata-Editor v1.3.0 setzt diese Formate bereits als eingebettete Ziele um und wurde mit synthetischen Dateien geprüft.

Für den beauftragten Zielstand v1.8.3 gilt ausschließlich für XMP-xmpMM:PreservedFileName:

Ein vorhandener Wert am vorgesehenen Speicherort bleibt erhalten. ExifTool darf nur dieses Feld ergänzen, keine Metadatenblöcke ersetzen. Vorhandene Sidecars werden weiterhin gekoppelt mitgeführt, auch wenn der neue Eintrag in JPEG, TIFF oder DNG erfolgt. Das Werkzeug erzeugt allein für diesen Eintrag kein Sidecar und löscht keine vorhandene XMP-Datei.

Diese Provenienzfunktion ist keine allgemeine Metadatenmigration. Die Archivregel für gepflegte Metadaten gilt daneben; Klassifizierung, getrenntes Lesen beider Quellen, Konfliktsperren und die Option „Scans überspringen“ bleiben bestehen. Für weitere Formate wird aus diesem Auftrag keine neue Einbettungsfreigabe abgeleitet.

Unter Windows benötigt bereits eine reine Änderung der Schreibweise einen Zwischenschritt. Das Werkzeug verwendet dafür einen temporären Namen und prüft dessen Verfügbarkeit. So kann beispielsweise BILD.JPG zuverlässig zu bild.jpg werden.

Kollisionen blockieren, Varianten benennen

Existiert der berechnete Zielname bereits, wird keine Datei überschrieben. Eine echte Identitätskollision wird protokolliert und blockiert. Mehrere fachlich bestätigte Derivate derselben Werkfamilie erhalten dagegen eine eindeutige Variantenkennung:

20260605_190802_img00023_ai-01.jpg
20260605_190802_img00023_ai-01.xmp

Weitere bestätigte Varianten verwenden -02, -03 und so weiter. Die achtstellige Grundkennung bleibt unverändert. Zusätze wie (1) oder (2) sind keine fachliche Variantenkennung und dürfen eine Doppelvergabe nicht verschleiern. Medium und vorhandenes Sidecar werden stets gemeinsam geprüft.

Grenzen der Automatisierung

Das Werkzeug standardisiert technische Namen. Es entscheidet nicht, welche Person auf einem Bild zu sehen ist, welches Ereignis dokumentiert wird oder ob zwei ähnlich aussehende Dateien inhaltlich Dubletten sind. Personen, Orte, Beschreibungen, Rechte und Schlagwörter bleiben Aufgaben der Metadatenpflege.

Auch das Überspringen erkannter Scans ist eine Schutzfunktion, keine Garantie. Die Erkennung orientiert sich unter anderem an Hinweisen auf Epson, NikonScan, VueScan und SilverFast. Bei einem unbekannten Bestand bleibt die Sichtkontrolle erforderlich.

Ein fehlerfreier Programmlauf beweist außerdem noch keine korrekte Veröffentlichung. Für Webdateien gehören deshalb vier Prüfungen zusammen:

1. Vorschau und CSV vor der Änderung,
2. Dateisystemkontrolle nach dem Live-Lauf,
3. exakter Abgleich von Link und Dateiname vor der Übertragung,
4. Aufruf der veröffentlichten URL nach der Übertragung.

Fazit

Das selbst entwickelte Werkzeug verbindet Automatisierung mit klaren Sicherheitsgrenzen. Es vereinheitlicht Foto- und Videonamen, erhält die fünfstellige Werkfamiliennummer, wertet eindeutige KI-Herkunft aus XMP/IPTC aus und blockiert Konflikte statt sie durch einen Ausweichnamen zu verdecken.

Die neue Kombination aus ASCII-Umlautumsetzung und vollständiger Kleinschreibung löst ein praktisches Veröffentlichungsproblem: Was unter Windows unauffällig funktioniert, kann auf einem Linux-Webserver an einem einzigen abweichenden Buchstaben scheitern. Damit ist das eigentliche Ziel erreicht: ein einheitliches Archiv, dessen Dateinamen zugleich als verlässliche Grundlage für Web-Veröffentlichungen dienen.

Weiterführend

• Dateibenennung im Familienarchiv
• Metadaten im Fotoarchiv
• KI-bearbeitete Fotos sauber ins Langzeitarchiv übernehmen
• digiKam im Familienarchiv
• Arbeitsumgebung für Fotografie, Scan und Bildverwaltung