WebP Support

Bisher gibt es noch keine offizielle Anfrage zum Thema WebP Support. Dies würde ich gerne ändern Smiley Wink Mittlerweile unterstützen die gängigen Browser [0] fast alle WebP und WebP gehört meiner Meinung nach, mittlerweile zum guten Ton.

Weitere Anfragen zum WebP Support in FirstSpirit:

WebP image format in FirstSpirit

WebP Format in bestehende Projekte integrieren

WebP Unterstützung ab 12/2019

Kann man Bilder zusätzlich in das WebP-Format konvertieren?

[0] https://caniuse.com/#feat=webp

Tags (1)
11 Comments
hoebbel
e-Spirit employee

Hallo Michael,

Aus dieser Anfrage geht leider nicht hervor, welche Erweiterungen bezüglich des WebP Supports hier gewünscht sind. Es wäre sehr hilfreich, wenn Du den Änderungswunsch präzisieren könntest.

Momentan wäre die Antwort auf die Anfrage "FirstSpirit unterstützt WebP als Bildformat seit der Version 2019-11.", was Dir aber natürlich bereits bekannt ist Smiley Wink

Viele Grüße aus Dortmund,

Holger

mpriess
I'm new here

Hallo Holger,

ich nehme an, in FirstSpirit wird Java Image I/O verwendet. Hier sind meine konkreten Usecases:

  • Als Redakteur lade ich ein Bild als JPG hoch und definiere 5 Bildausschnitte. Neben den 5 Bildauflösungen welche FirstSpirit bisher als JPG generiert, hätte ich gerne als zusätzliches Bildformat WebP.
    • Support für PNG to webP
    • Support für JPG to webP
  • Als Entwickler würde ich gerne am Template definieren, welches Bildformat generiert wird. Dies könnte z.B. so aussehen: $CMS_REF(st_picture, resolution:"TextBildTeaser", fileformat:"webp")$.

Es gibt natürlich auch gute Gründe, so ein Feature nicht einzubauen.

Neben den bisherigen Java Image I/O reader und writer welche Java SE bereits für JPG mitbringt, werden hier zusätzliche native Bibliotheken eingebunden. Die Firma Luciad, hat ursprünglich mal eine Image I/O Implementierung geschrieben. Da das Projekt mittlerweile nicht mehr aktiv maintained wird, gibt es mittlerweile mehrere Forks auf Github. Hier habe ich aber auch auf die schnelle kein Projekt gefunden, welches aktuell aktiv maintained wird. Eventuell hat hier jemand mehr Erfahrung und kann weiterhelfen?

Findet man hier keine passende Bibliothek, müsste man hier langfristig einen eigenen Fork erstellen.

Können wir mit so einem Feature in den nächsten 24 Monaten rechnen? Alternativ würde ich unseren Kunden ein CDN empfehlen.

Gruß,
Michael

hoebbel
e-Spirit employee

Hallo Michael,

gewünscht ist also, vereinfacht gesagt, dass es möglich sein soll, bei der [automatischen & manuellen {Zuschnitt für eine Auflösung}] Bildskalierung den Typ des Bildes zu ändern. Wobei der Schwerpunkt darauf liegen soll, dies insbesondere für den Zieltyp WebP umzusetzen.

Du schreibst, dass zusätzlich webp-Bilder erzeugt werden sollen. Das würde bedeuten, dass für eine Auflösung mehrere Bilder erzeugt werden können. Also müsste sowohl die Art der Speicherung der skalierten Bilder als auch deren Auslieferung entsprechend erweitert werden, so dass irgendwie bestimmt werden kann, welches der Bilder berechnet und dann verwendet werden soll.

Einfacher (und somit deutlich weniger aufwändig) wäre es, wenn weder in der Persistenz noch in der Ausgabe etwas geändert werden müsste, sondern "nur" bei der Skalierung selber. Es also weiterhin pro Auflösung nur ein berechnetes Bild gibt.

Vorstellen könnte ich mir hier, dass

  • als Projekteigenschaft definiert wird, dass für alle [zukünftigen!] Bild-Skalierungen immer der Bildtyp WebP erzeugt werden soll
  • als Projekteigenschaft definiert werden kann, dass Bilder von Typ "XYZ" [zukünftig] zu WebP skaliert werden sollen
  • für eine Auflösung eine Option vorgesehen wird, dass als Bildtyp WebP [zukünftig] erzeugt werden soll

Bestehende Auflösungen könnte man dann durch einen Projektexport ohne berechnete Auflösungen "los werden". Oder, wenn Option 2 "Purge MEDIA_STORE_CACHED_PICTURE" von diesem Feature umgesetzt werden sollte, über diese Funktionalität.

Aussagen darüber, ob und in welcher Zeit ein Feature umgesetzt wird, kann ich nicht treffen. Das hängt davon ab, welchen Aufwand eine entsprechende Erweiterung bedeuten würde (das wird intern von den umzusetzenden Teams bei e-Spirit evaluiert) und wie der potentielle Nutzen aus Kundensicht ist. In letzteres fließt vor allen Dingen ein, wie viele Stimmen von wie viel verschiedenen Kunden/Partnern das jeweilige Feature bekommt.

Anhand dieser beiden Faktoren werden die Änderungswünsche dann intern priorisiert.

Viele Grüße,

Holger

mpriess
I'm new here

Hallo Holger,

Entwicklung

  • Heute: Als Entwickler definiere ich die Auflösungen 800x800 (Teaser-Desktop) und 400x400  (Teaser-Mobile) für das Absatztemplate "Teaser" wie bisher in den Projekteigenschaften.
  • Neu: In den Projekteigeschaften setze ich die Checkbox "Generate WebP" und wähle aus einer Liste alle Formate (JPG, PNG ...) aus, die in WebP umgewandelt werden.
  • Neu: Als Entwickler referenziere ich die gewünschten Auflösungen und das gewünschte Bildformat.
    • Dies ist notwendig, damit ich dem HTML Element Source das passende Bild übergeben kann.
    • Wenn man kein fileformat angibt, wird wie bisher das originale Dateiformat verwendet. Damit die bisherige Implementierung Abwärtskompatibilität bleibt. Dies kann eventuell bei alten Browsern zu Bugs führen, falls das referenzierte Image im Format WebP ist.

<picture>

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop", fileformat:"webp")$" type="image/webp" media="(max-width: 400px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile", fileformat:"webp")$" type="image/webp" media="(max-width: 1024px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop", fileformat:"jpg")$" type="image/jpg" media="(max-width: 600px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile", fileformat:"jpg")$" type="image/jpg" media="(max-width: 1024px)">

  <img src="$CMS_REF(st_picture, resolution:"Teaser-Mobile", fileformat:"jpg")$"> <!-- Fallback -->

</picture>

  • Heute: Als Entwickler referenziere ich die Auflösungen aus dem Absatztemplate "Teaser" wie bisher.


Redakteur

  • Heute: Als Redakteur lege ich ein neues Absatztemplate vom Typ "Teaser" an und referenziere ein Bild. Dieses Bild kann im Bildformat (JPG, PNG oder WebP) in der Medienverwaltung hinterlegt sein.
  • Heute: Als Redakteur schneide ich die Auflösungen 800x800 und 400x400 für mein Bild zu und starte die Generierung.
  • Neu: FirstSpirit generiert die Teaserbilder für mein Absatztemplate
    • 800x800.jpg
    • 400x400.jpg
    • 800x800.webp
    • 400x400.webp
hoebbel
e-Spirit employee

Hallo Michael,

dieser Wunsch bedeutet weiterhin, dass tiefgreifende Änderungen vorgenommen werden müssen bezüglich

  • der Art wie Auflösungen gespeichert werden
  • der Ausgabe von Auflösungen

Ich fürchte, dass dabei die Aufwand/Risiko/Nutzen Abwägung ergeben wird, dass dieses Feature so nicht umgesetzt werden wird [meine persönliche Einschätzung, die kann auch falsch sein]

Der gesamte neue Wunsch lässt sich doch auch so umsetzen:

<picture>

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop_webp"$" type="image/webp" media="(max-width: 400px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile_webp")$" type="image/webp" media="(max-width: 1024px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop")$" type="image/jpg" media="(max-width: 600px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile")$" type="image/jpg" media="(max-width: 1024px)">

  <img src="$CMS_REF(st_picture, resolution:"Teaser-Mobile", fileformat:"jpg")$"> <!-- Fallback -->

</picture>

Hier würden im Projekt zwei neue Auflösungen (Teaser-Desktop_webp & Teaser-Mobile_webp) definiert und mit der Option "generiere webp" versehen werden.

Die Anpassung würde ich dann "nur" auf die automatische Skalierung der Bilder und den Bildzuschnitt beziehen. Persistenz und Auslieferung wären nicht betroffen.

Was habe ich dabei übersehen, was fehlt noch?

Viele Grüße,

Holger

mpriess
I'm new here

Hallo Holger,

Der gesamte neue Wunsch lässt sich doch auch so umsetzen:

<picture>

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop_webp"$" type="image/webp" media="(max-width: 400px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile_webp")$" type="image/webp" media="(max-width: 1024px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Desktop")$" type="image/jpg" media="(max-width: 600px)">

  <source srcset="$CMS_REF(st_picture, resolution:"Teaser-Mobile")$" type="image/jpg" media="(max-width: 1024px)">

  <img src="$CMS_REF(st_picture, resolution:"Teaser-Mobile", fileformat:"jpg")$"> <!-- Fallback -->

</picture>

Der Zuschnitt der Bild wäre im Site Architect und Content Creator dann redundant? Der Redakteur müsste in diesem Fall 4 Bildausschnitte setzen. Richtig?

Gruß,

Michael

hoebbel
e-Spirit employee

Hallo Michael,

> Der Zuschnitt der Bild wäre im Site Architect und Content Creator dann redundant?

Zur Zeit wäre es tatsächlich so, dass jeweils zweimal mehr oder weniger derselbe Bildausschnitt gesetzt werden müsste, wenn das Bild nicht nur skaliert werden soll. Das hatte ich tatsächlich übersehen.

Das "kleinere" Feature wäre also nur sinnvoll, wenn das Zuschneiden deutlich einfacher geschehen würde (nur wenige Klicks für alle Auflösungen)?

Ich nehme das mal so mit.

Danke,

Holger

daniel_philippi
Returning Observer

Hallo ihr.

Für die Zuschnitte wäre ein effektiveres System eh besser, denn in der heutigen Welt in der ich jedes Bild in min. 6 verschiedenen Auflösungen (mobile, tablet, desktop, mobile 2x, tablet 2x und desktop 2x) brauche machen Zuschnitte keinen Spaß. Daher ist das Cropping Feature bei uns leider sinnlos so schön und intuitiv es auch ist.

Wäre gut, wenn die Auflösungen grundsätzlich an die neuen Gegebenheiten (responsive design) angepasst würden. Einfach nur eine weitere Auflösung für WebP anzulegen kommt meiner Meinung nach zu kurz. Im obigen Beispiel hätten wir dann 12 Auflösungen statt 6.

Hier sollte man sich grundsätzlich mal überlegen ob man das nicht besser handhaben kann.

Gruß,

Daniel

mbergmann
e-Spirit employee

Hallo zusammen,

bei der Variante „mehrere Bilder pro Auflösung” käme ja auch noch das ganze Thema URLs hinzu: Erweiterung der UrlFactories inkl. Sicherstellung dass vorhandene Implementierungen weiter funktionieren, Handling von gespeicherten URLs usw.

Da hängen schon sehr viele Dinge dran...

Viele Grüße

Michael

hoebbel
e-Spirit employee

Hallo Daniel,

ich möchte Dich diesbezüglich auf die Funktion Smart Cropping hinweisen, die seit FirstSpirit 2020-10 ausprobiert werden kann. [siehe Release Notes der Version, Kapitel 4.3].

Viele Grüße,

Holger