Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Kommentar: Dateiname in der Prüfsummendatei ist jetzt egal

...

Sonderfall: Wenn bereits Prüfsummendateien vorhanden sind und diese aktualisiert werden sollen, ist es nicht praktikabel einzeln hunderte TIFF-Dateien (aber nicht die MD5-Dateien) auszuwählen. Stattdessen alle Dateien auswählen und im Feld zum Dateinamensfilter (blaue Markierung) mit *.tif (bzw. *.jpg) die Verarbeitung auf TIFF- (bzw. JPEG-)Dateien einschränken.

FreeCommander erstellt die Dateien als .tif.MD5 (Großbuchstaben). Deshalb alle Dateien auswählen, Multirename starten, im Feld Dateiendung md5 (Kleinbuchstaben) eingeben und auf *.md5 einschränken. Das Feld Groß-Kleinschreibung sollte hier auf "No change" stehen; FreeCommander ändert die Dateiendung trotzdem auf Kleinschreibung. (Mit Multirename können auch Großbuchstaben im Dateinamen "verkleinert" werden. Das muss dann aber vor der Berechnung der Prüfsummen erfolgen!)

Image RemovedImage Removed

Die Prüfsummendatei für Die Prüfsummendatei für xyz_abc_xxx_12345_001_s.tif muss xyz_abc_xxx_12345_001_s.tif.md5 oder xyz_abc_xxx_12345_001_s.md5 heißen, d.h. mit Endung .tif.md5 oder .md5 und komplett in Kleinbuchstaben (alternativ mit .jpg, wenn das Bild eine JPEG-Datei ist – nicht empfohlen wegen Qualitätsverlust). Die Prüfsummendatei darf keinen Pfad enthalten und der Dateiname in der Prüfsummendatei muss dem Namen der Bilddatei entsprechen. Folgende Datei würde beispielsweise abgelehnt:

Image Removed

Korrekt ist die Angabe nur mit Dateinamesollte nur eine einzelne Prüfsumme enthalten. Empfohlen ist die Angabe ohne Pfad und mit dem korrekten Dateinamen, z.B. eine Prüfsummendatei Prüfsummendatei bsz_dok_screenshot_00001_001_s.tif.md5 (oder bsz_dok_screenshot_00001_001_s.md5) für bsz_dok_screenshot_00001_001_s.tif:

...

Der oben gezeigte Prozess erstellt Dateien, die diesen Anforderungen genügen, sofern die eigentlichen Dateien und nicht der beinhaltende Ordner ausgewählt werden.

Bei bereits vorhandener Prüfsummendatei: Darauf achten, dass

...

Hinweis: Seit 12.08.2025 sollten Prüfsummendateien mit abweichendem Dateinamen ebenfalls angenommen werden, sofern sich in der Prüfsummendatei nur eine einzelne Prüfsumme befindet (der übliche Fall). An dieser Stelle ist daher ein Schritt zur Umbenennung entfallen.

Dateien hochladen

Bild- und Prüfsummendatei auf SFTP-Server hochladen (Ordner upload für Produktion, test für Test). Die Dateien müssen direkt in upload bzw. test sein und nicht in Unterordnern davon! Dateien in Unterordnern werden ignoriert (insbesondere auch Dateien in invalid).

...

Feierabend machen. Der Import läuft über Nacht (ab 19:00), ab 21:00. Das bedeutet, dass der Upload um 21:00:00 abgeschlossen sein muss, besser 20:50, weil ansonsten unvollständig hochgeladene Dateien verarbeitet werden können.

Abgelehnte Dateien korrigieren

...

Dateien, deren Name nicht der Dateinamenskonvention entspricht oder die schon vorhanden sind, lokal entsprechend umbenennen, Prüfsummen neu berechnen und erneut hochladen. Wenn nur die Prüfsumme inkorrekt war, entfällt das Umbenennen natürlich.

Dateien sollten nicht können auf dem Server umbenannt werden, weil dann der Dateiname in der Prüfsummendatei nicht mehr mit dem Dateinamen der Bilddatei übereinstimmt. Außerdem besteht das Risiko, sie versehentlich im . Dann ist aber darauf zu achten, sie wieder aus dem Ordner "invalid" zu belassen, was dann zu Verwirrung führt wenn sie nicht importiert werdenheraus zu verschieben. (Der Inhalt des Ordners "invalid" wird beim Import ignoriert.)

Der Ordner upload\invalid (bzw. test\invalid) kann gelöscht werden, wenn die Dateien darin erneut hochgeladen wurden (oder anderweitig nicht mehr benötigt werden). Dann zeigt die Existenz des invalid-Ordners, dass Dateien abgelehnt wurden. Alternativ die entsprechende Bilddatei darin löschen, wenn erneut hochgeladen, und den Ordner regelmäßig auf abgelehnte Dateien überprüfen.

Korrekturlieferungen

  • Wenn

...

  • nur

...

  • Wenn nur eine der Dateien (Master oder Submaster) ersetzt werden soll, die andere (Submaster bzw. Master) von expo.medoa media herunterladen, wenn lokal nicht mehr vorhanden.
  • Die bestehende Aggregation auf expo.media löschen. Wenn sie dort nicht vorhanden ist, weil ihre Verarbeitung gescheitert ist (und nur dann!), kann auf diesen Schritt verzichtet werden.
  • Optional aber empfohlen: Vorhandenes Medienobjekt in imdas pro vor Upload löschen, auch wenn nur eine der Versionen (Submaster oder Master) ersetzt werden soll.
  • Danach die aktuelle(n) Datei(en) für diese Aggregationen hochladen, wie bei einer normalen Lieferung. Wenn nur eine davon (Master oder Submaster) ersetzt wurde, muss trotzdem die andere (Submaster bzw. Master) neu mit hochgeladen werden.

Der Rest des Vorgangs ist identisch zu einer normalen Lieferung. (Korrekturlieferungen sind nichts anderes als eine Löschung gefolgt von einer normalen Lieferung.)

Wenn eine Datei (Master/Submaster) ergänzt werden soll, handelt es sich nicht um eine Korrekturlieferung! Stattdessen nur die zu ergänzende Datei mit korrektem Dateinamen gemäß dem normalen Prozess hochladen. Sie wird dann automatisch zur bestehenden Aggregation hinzugefügt.

Vorgehen bei falschen Prüfsummen

...

Pro Lieferung sind folgende Limits einzuhalten. Wenn noch unverarbeitete Daten im upload-Ordner liegen sollten, ist von einem Verarbeitungsfehler auszugehen und von einer erneuten Lieferung abzusehen, bis diese Dateien verarbeitet wurden (normalerweise am nächsten Abend).

LimitMaximumAnmerkungen
Datenmenge gesamt55GB

Bei Lieferung aus einem Backlog zu liefernder Dateien sollten pro Tag ca. 50GB geliefert werden, also ziemlich dicht am Limit.

Anzahl BilddateienTBD

(1000)

Wenn für eine Aggregation Bei Lieferung von Master + Submaster geliefert werden, zählt pro Aggregation nur der Submaster.das nur als eine Bilddatei.

Realistisch gibt es hier kein Limit, weil die maximale Datenmenge zuerst erreicht wirdAktuell einfach so viele Dateien liefern, bis die Datenmenge erreicht ist.

Auflösung Einzelbild

16-bit: 65Mpx

8-bit: >80Mpx

130Mpx

Auflösung = Breite × Höhe. DBreite×Höhe, d.h. 65Mpx = nicht größer als 8000x8000, 6000x11000, 4000x16000, 2000x33000 .wären alle kleiner als 65Mpx.

Größere Dateien sind dem BSZ vorab anzukündigen, um die Resourcen auf dem Server besser planen zu könnenGenaues Limit für 8-bit ist noch zu ermitteln.

Dateigröße Einzelbild

(16-bit: 400MB800MB)

(8-bit: >240MB400MB)

Ausschlaggebend

Eigentlich kein Limit; ausschlaggebend ist nur die maximale Auflösung.

Unkomprimierte

Bilder

TIFFs brauchen aber bei 16-bit 6 Byte pro Pixel und bei 8-bit 3 Byte pro Pixel

, d

. D.h.

, aus der Dateigröße ergibt sich meistens die Auflösung

die Dateigröße ist ein guter Indikator ob das Bild von der Auflösung her nicht zu groß ist.

Ende des Uploads1921:00:00

Der Ingest-Job startet pünktlich um 1921:00 Uhr. Dateien, die zu diesem Zeitpunkt noch nicht vollständig auf den SFTP-Server übertragen warenwurden, können beim Ingest korrumpiert werden (der noch nicht übertragene Teil kann fehlen).

...

werden mit hoher Wahrscheinlichkeit auch unvollständig ins LSDF kopiert. (Der Kopiervorgang vom SFTP ins LSDF ist sehr schnell.)

Solche unvollständigen Dateien führen wahrscheinlich zu Format-Meldungen von JHOVE:

INFO: JHovePipe: Datei ... nicht valide; Status: Not well-formed
INFO: JHovePipe: ERROR: Premature EOF

(Leider meldet JHOVE manchmal auch Fehler in Dateien die ok sind, deshalb wird trotzdem versucht die Dateien zu verarbeiten.)