WebP Dateiformat im Offsetdruck

onkelotti

Hallo in die Runde,

wir arbeiten gerade an einem Upgrade unseres DAM-Systems. Aktuell bereiten die Migration der Daten vor und konzipieren unser Datenhandling.

Bislang hatten wir freigestellte Produktbilder immer als TIF, PSD oder PNG vorliegen und es gab die Option, diese beim Export aus dem DAM in JPG oder PNG zu konvertieren.

Nun ist mittlerweile mit WebP ja ein (relativ) neues Dateiformat am Start, das nach und nach die Formate JPG und PNG ablösen könnte.

Die Frage, die ich mir stelle, ist: Kann man eigentlich beim Layout in InDesign und anschließendem Export ins PDF-Format für den Offsetdruck auch mit WebP-Dateien statt JPG/PNG/TIF/PSD arbeiten oder sorgt das im Prepress- und/oder Druckprozess für Probleme/Qualitätsverlust?

Wenn nicht, wäre es dann eigentlich sinnvoll, WebP statt der großen Formate (vor allem PSD+TIF) als universelles Downloadformat für unsere Bilddaten zu nutzen und damit auch Druckdaten zu schreiben.

Hat jemand hiermit Erfahrungen oder sitzt da tief genug im Kaninchenbau, um mir bei der Entscheidungsfindung zu helfen?

Vielen Dank und einen guten Wochenstart!

Thomas_Richard

WebP bringt in Sachen Kompression nur Vorteile gegenüber JPEG bei sehr starken Kompressionsraten – die wirst du sicherlich nicht für Druckdaten in Betracht ziehen.

Ein tatsächlicher Vorteil gegenüber JPEG ist die verbesserte Kompression von kontrastlosen bis gänzlich kontrastfreien Bildbereichen (z.B. Logos die auf Weiß stehen oder überwiegend aus Text oder feiner Lineart bestehen, werden als JPEG gerne wolkig mit Kompressionsartefakten um die hochkontrastigen Bereiche – das soll bei WebP besser sein, ein schneller Test hier mit Photoshop lässt mich aber keine gravierenden Gewinne in _sinnvollen_ Kompressionsstufen erkennen.

onkelotti

Hi Thomas,

schon mal vielen Dank für Dein Feedback.

JPGs haben ja auch hohe Kompressionsraten, wenn die Qualität aber auf "Maximal" gespeichert wird, sieht man hierbei ja keine Qualitätsverluste im Druck gegenüber z.B. TIFF-Dateien.

Daher die Frage: Sieht man wirklich optische Qualitätsunterschiede, wenn man ein webp anstelle eines JPG, PNG oder TIF in die Druckdaten einbettet?

Thomas_Richard

Versuch macht kluch – schau’s dir halt mal an.

ich hab hier gerade mal ein problematisches Logo und ein schwer komprimierbares Foto (81MB, RGB, frontale Aufnahme eines Teppichs) mit gleichen Dateigrößen als jpeg und WebP gesichert und die Ergebnisse verglichen. Bei starken Kompressionen ist WebP in der tat deutlich überlegen, bei niedrigen Kompressionsraten kann ich keine gravierenden Unterschiede in der Ansicht erkennen – aber das Arbeiten mit der Photoshop’schen Implementierung verlangt schon einiges an Langmut vom Benutzer – aber das ist eben Adobe, bei Verwendung der gleichen Parameter im Terminal mittels cwebp.

tom@Toms-Mac-Pro bin % ./cwebp -q 98 -z 6 -mt -metadata all -progress -v /Users/tom/Desktop/117815_8bit.tif -o /Users/tom/Desktop/117815cwebp2.webp 

Warning: EXIF extraction from TIFF is unsupported.

Time to read input: 0.273s

Saving file '/Users/tom/Desktop/117815cwebp2.webp'

Time to encode picture: 13.620sbit.tif]:  94 %      

File:      /Users/tom/Desktop/117815_8bit.tif

Dimension: 6720 x 4480

Output:    19096610 bytes Y-U-V-All-PSNR 49.83 52.30 52.31   50.51 dB

           (5.07 bpp)

block count:  intra4:      19729  (16.78%)

              intra16:     97871  (83.22%)

              skipped:         0  (0.00%)

bytes used:  header:           1288  (0.0%)

             mode-partition: 113706  (0.6%)

 Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total

    macroblocks:  |      35%|      39%|      26%|       0%|  117600

      quantizer:  |       2 |       1 |       0 |       2 |

   filter level:  |       0 |       0 |       0 |       0 |

Metadata:

  * ICC profile:    1992 bytes

  * XMP data:      15351 bytes

Bemerkenswert finde ich, dass das webp die Farbsensor typischen Farbsäume sogar noch im Vergleich zum RAW/TIF wegbügelt:
[inline Bildschirmfoto-2025-02-10-um-17.07.51.jpg]
links TIF, rechts WebP

Je nach Ausgangsmaterial der Altbestände könnte das:

ein absoluter Showstopper sein.

onkelotti

Das sind ja zum einen optische Feinheiten, die bei einem normal eingesetzten Bild zwischen 200 und 300 dpi niemandem auffallen würden. Zum anderen spricht das ja noch mehr für die Verwendung von WebP, wenn ich Dich richtig verstehe.

Also noch mal die Frage: Gibt es gravierende Nachteile, wenn wir z.B. zukünftig unsere freigestellten Produktbilder als WebP statt TIF oder PNG speichern, entsprechend in InDesign verknüpfen und daraus Druck-PDFs erstellen?

Mit "gravierend" meine ich z.B. deutliche Farbschwankungen beim Umrechnen in den CMYK-Farbraum während des Exports oder "zerschossene" Bilder oder Freisteller? Also etwas, dass auch dem Laien sofort auffallen würde.

Thomas_Richard

Das wirst du für deinen konkreten Einsatzzweck wohl selbst herausfinden müssen? Wie handelt ihr Metadaten in den Bildern, wie sind eure freigestellten Produktabbildungen freigestellt?

Hier verschwindet z.B. nicht nur das Attribut Freistellungspfad sondern sämtliche Pfade komplett.

Ebenso bleiben keine Ebenen übrig - alles was zuvor sichtbar war landet in Ebene 0.

Die Transparenz ist auch futsch (könnte auch an meinem Parametersatz für cewbp liegen, beim sichern aus PS bleibt sie erhalten.) …

Aber nochmal, 80MB RGB Bild aus PS als jpg oder Tif auf dem Server sichern findet unterhalb der Wahrnehmbarkeitsschwelle statt, bei web p vergehen dafür schon 15 Sekunden, bei Photoshop reden wir von 30 Sekunden bis überhaupt erstmal der Einstellungsdialog erscheint.

onkelotti

Wie gesagt: Die Idee ist schlicht Speicherplatz sparen, damit zum einen die Kapa der Cloud unseres neuen DAM-Systems nicht so schnell ans Limit kommt, zum anderen der Download der Daten aber auch schneller erfolgen kann. Gleichzeitig sollten die Daten aber immer noch drucktauglich sein und hier fehlt mir mit webP die Erfahrung.

Dass bei freigestellten Bildern (mit einem Transparenz-Alphakanal) die Ebenen wegfallen: geschenkt. Dass Pfadinformationen wegfallen, ließe sich auch verkraften, denn wir stellen in der Regel nicht via Beschneidungspfad frei, sondern über den Alphakanal/Transparenz.

Die Idee ist, weiterhin Mockups oder Retuschevorlagen als TIFF zu speichern, um die Ebenen und alle Funktionen zu erhalten, finalisierte Bilder dann aber eben als PNG oder webP zu speichern, um die Bildgröße zu minimieren.

Heißt: Mir geht es weniger darum, wie lange der Speicherprozess dauert, sondern wie ich minimale Dateigrößen mit bestmöglicher Qualität (Transparenzerhalt) und Nutzbarkeit (u.a. für den Offsetdruck) hinbekomme.

Dass bei webP die Transparenz futsch ist, wie Du schreibst, wäre natürlich fatal.

Ich muss gerade mal checken, wieso ich aktuell aus Photoshop (v.26.3.0) kein webP speichern kann...

Thomas_Richard

Antwort auf:
Heißt: Mir geht es weniger darum, wie lange der Speicherprozess dauert, sondern wie ich minimale Dateigrößen mit bestmöglicher Qualität (Transparenzerhalt) und Nutzbarkeit (u.a. für den Offsetdruck) hinbekomme.

Dass bei webP die Transparenz futsch ist, wie Du schreibst, wäre natürlich fatal.

Ich muss gerade mal checken, wieso ich aktuell aus Photoshop (v.26.3.0) kein webP speichern kann...

In aktuellen PS Versionen geht es nur als 'Kopie speichern' …

ich habe gerade noch mal mit einer PS 2025 Version (26.2.0) getestet, hier wurde das Export-Modul wohl deutlich überarbeitet zu meiner 2021 Arbeits-Version: Jetzt bleiben Ebenen und Pfad erhalten, sogar der Status 'Beschneidungspfad' hat den Weg über WebP überlebt.

Bleibt der Pferdefuss der absurd langen Speicherzeit, auch hier wieder deutlich über 30 Sekunden bis ein 80MB RGB auf 19MB mit 98%iger Qualität entstanden ist – ein in Vergleichbarer Qualitätsstufe gesichertes jpeg Komprimiertes TIF braucht wie gesagt keine wahrnehmbare Zeit - die Datei ist einfach gleich da.

Wenn du jetzt Speicherplatz sparen möchtest, bist du quasi gezwungen auszubaldowern mit welcher Qualitätseinstellung bei JPG und WebP noch keine erkennbaren Qualitätsverluste auftreten und dann überlegen, ob das neue Format dahingehend Vorteile in der Dateigröße liefert.