Wo speichert Ihr überall die platzraubenden TIFFs?

Hallo zusammen,

als Goobi-Newbies haben wir ziemlich viele vorhandene Digitalisate in Vorsystemen (= Dateisystemen).

Wenn ich die in Goobi Workflow lade, sind die TIFFs zusätzlich dort. Wenn ich die in den Viewer exportiere, sind die TIFFs zusätzlich dort. Alle Ebenen laufen auch in unsere (Band-)sicherung. dLZA-Systeme gibt es auch noch. Das kostet ganz schön viel redundanten Platz, wenn nicht alles in einem deduplizierenden Storage ist.

Wie macht Ihr das so? Im Viewer braucht man die TIFF-Master doch vermutlich kaum, oder? Lässt es sich leicht so konfigurieren, dass die TIFFs nicht im Viewer landen?

Lasst Ihr die Vorgänge unbegrenzt lange im Workflow? Kann, sollte man auch dort auf die TIFFs verzichten? Oder ist bei den meisten Goobi Workflow die führende Ablage für TIFFs?

Gerne würde ich hören, was sich so in der Praxis für mittelgroße Einrichtungen bewährt hat.

Danke und Gruß
Heinz

Hallo Heinz,

voab: Dir geht es bei Deinen Überlegungen nur um die Bilddateien, nicht um Metadaten oder OCR etc.?

Beste Grüße, Andreas

Kannst Du euren Goobi-Workflow hier einstellen? Andernfalls auch gerne per e-mail.

Hallo,

in der Regel hält Goobi-Workflow ja zwei Sets von Tiff-Dateien vor: Die unkomprimierten “master” Dateien, und die (jpeg-)komprimierten Derivate (im “media”-Ordner). Ich meine, das wäre auch bei Euch so, Heinz. Die master-Tiffs werden eigentlich nie in den Viewer exportiert, sondern nur die komprimierten Derivate.

Beide Dateigruppen verwenden üblicherweise das Tiff-Format, das ja verschiedene Bildtypen aufnehmen kann. Das macht es für manche automatisierte Prozesse in Goobi einfacher, da die Dateiendung der Bilder immer vorausgesetzt werden kann. Allerdings lassen sich master-Dateien und Derivate dadurch nicht auf den ersten Blick unterscheiden.
Inzwischen könnten sowohl Goobi-Workflow also auch der Viewer prinzipiell mit Jpeg oder anderen Formaten als Derivate umgehen; allerdings müsste man dafür einige Workflow-Schritte und Scripte anpassen.

Schöne Grüße,
Florian

Ah, interessant, es war mir nicht klar, dass im Viewer nur JPG-kodierte TIFFs landen. Ich glaube, da hat mich das Download-Wording “Bild Master” auf die falsche Fährte gelockt. Dann ist die Redundanz ja doch kleiner, als befürchtet.

Danke für die Erläuterungen.

Bleibt noch die Frage, ob es Anwender/-innen gibt, die auch in Workflow die wirklichen Master nicht dauerhaft aufbewahren (weil diese noch woanders liegen). Oder ob das eine Schnapsidee ist.

Heinz

Hallo Andreas,
ja, mir ging es nur um die Bilddateien.
Unser Workflow ist ziemlich simpel:

  1. Export der bibliografischen Metadaten aus OpenRefine in eine Excel-Datei.
  2. Import der Excel-Datei mit dem entsprechenden Plugin in Workflow (teils gleich mit Images aus benannten Ordnern, teils werden Images via Webbrowser manuell hochgeladen).
  3. Strukturdaten erfassen wir idR. nicht.
  4. Export in den Viewer.
1 Like

Ah, interessant, es war mir nicht klar, dass im Viewer nur JPG-kodierte TIFFs landen. Ich glaube, da hat mich das Download-Wording “Bild Master” auf die falsche Fährte gelockt. Dann ist die Redundanz ja doch kleiner, als befürchtet.

Das ist allerdings wahr. Diese Bezeichnung beim Download ist etwas irrführend. Aus Sicht des Viewers sind halt die komprimierten TIffs die “master”, weil das diejenigen Bilder sind, die er bekommt. Aus Gesamt-Goobi Sicht ist das allerdings kein ideales Wording. Müssen wir mal drüber nachdenken.

Bleibt noch die Frage, ob es Anwender/-innen gibt, die auch in Workflow die wirklichen Master nicht dauerhaft aufbewahren (weil diese noch woanders liegen). Oder ob das eine Schnapsidee ist.

Ich glaube das ist sehr uneinheitlich geregelt. Es gibt bestimmt noch Goobi-Workflow Instanzen, die die master quasi permanent aufbewahren. Der bessere, und wohl auch inzwischen übliche Weg ist aber, die Dateien in irgend ein Archiv zu exportieren und nach einer Karenzzeit von einigen Wochen dann aus dem Goobi-System zu löschen. Wobei ein Archiv alles von lokal aufbewahrten Festplatten bis zu einer Rosetta-Instanz sein kann, oder auch ein S3 System.

1 Like