fweissenberger
New Creator

JPG to Webp Konvertierung

Hallo,

 

unsere Redakteure würden ihre Bilder gerne im Webp-Format auf die Homepage bringen.

 

Da der Pflegeaufwand, alle bereits vorhandenen/hochgeladenen Bilder im .jpg-Format erneut in .webp hochzuladen riesig wäre folgende Frage:

Bietet der SiteArchitect eine Möglichkeit, aus bereits vorhandenen Bildern eine .webp-Kopie zu erstellen?

 

Beste Grüße

Fabio Weissenberger

7 Replies
hoebbel
Crownpeak employee

Hallo Fabio,

für Auflösungen ist das problemlos möglich, siehe beispielsweise 
https://docs.e-spirit.com/odfs/vorlagenentwick/vorlagensyntax/anweisungen/cms_ref/index.html
(dort einfach mal nach ImageWriteParam suchen)

Für die ORIGINAL-Auflösung geht das so aber nicht - da wäre der Lösungsansatz, eine Auflösung, die nicht skaliert zu verwenden.

ABER die Änderung greift nur für neu berechnete Auflösungen. Für bereits erzeugte Auflösungen hätte dies keinen Effekt. Diesbezüglich kann man aber ein Skript laufen lassen, dass die bereits berechneten Auflösungen aus dem Projekt entfernt. Bitte wende dich diesbezüglich an den Customer Support (das Skript ist ein Repository Viewer Skript, dass die Daten direkt aus dem Repository löscht).

Und eine weiterer Stolperstein sind gegebenenfalls SEO URLs. Ist für eine Auflösung bereits eine SEO URL vergeben worden würde die erst einmal nicht neu vergeben werden. Das Webp Bild würde dann also gegebenenfalls mit der Endung jpeg erzeugt werden (das spielt aber normalerweise keine Rolle, kann aber bei der Prüfung irritierend sein 😉

Ich hoffe, ich konnte Dir weiterhelfen,
Holger

f_koenig
Returning Observer

Hallo zusammen,

wir haben gerade eine Konvertierung aller Bilder von jpg nach webp in unserem Projekt durchgeführt.

Ergänzend zu Holgers Ausführungen sind wir dabei auf das Problem gestoßen, dass das erwähnte Skript nur für automatisch berechnete Auflösungen greift.

Manuell zugeschnittene Bilder werden damit nicht neu berechnet. Das gilt auch für das in Version 2023.9 eingeführte Feature, das Auflösungen nach Änderungen der ImageWriteParams einmalig neu berechnet werden.

Um auch die manuell zugeschnittenen Bilder unter Berücksichtigung der veränderten ImageWriteParams neu zu berechnen, habe ich ein eigenes Skript geschrieben (siehe unten).

Zusammenfassend waren folgende Schritte nötig, um die Konvertierung vorzunehmen:

1.) ImageWriteParams im Projekt setzen:

project = context.getProject();
project.lock();
properties = new java.util.LinkedHashMap();
properties.put("default.targetType", "webp");
project.setCustomProperties("ImageWriteParam", properties);
project.save();
project.unlock(); 

2.) Bei den entsprechenden Bildern die SEO-URLs zurücksetzen.

3.) Für die automatisch berechneten Auflösungen das von Holger erwähnte Skript im Repository Viewer laufen lassen. Dieses erhält man problemlos beim Customer Support.

4.) Für die manuell zugeschnittenen Auflösungen folgendes Skript ausführen. Dieses iteriert über alle Auflösungen der Bilder und schneidet diese unter Verwendung der bestehenden Crop-Daten neu zu und speichert diese im Medium. Bei diesem Neu-Zuschnitt werden die neu gesetzten ImageWriteParams berücksichtigt.

import java.awt.geom.Rectangle2D;
import de.espirit.firstspirit.store.access.mediastore.PictureCropImage;
import de.espirit.firstspirit.store.access.mediastore.ImageOrientation;

lang = context.getProject().getMasterLanguage();

rewriteImages(media) {
    // nur medien
    if(media.getClass().getName().toString()=="de.espirit.firstspirit.store.access.mediastore.MediaImpl") {
        print(media.uid);
        
        // write lock
        media.setLock(true);
        
        // bild holen
        picture = media.getPicture(lang);

        // über alle auflösungen iterieren
        for(resolution:picture.getChildren().iterator())
        {
            print(resolution.getResolution());
            
            // daten des bestehenden zuschnitts holen
            cropData = resolution.getCropData();
            // falls bild nicht manuell zugeschnitten, existiert keine zuschnittsdaten
            if (null != cropData) {
                // informationen zum zuschnitt: auswahl, spiegelung & drehung
                selection = cropData.getSelection();
                flipped = cropData.isImageFlipped();
                rotation = cropData.getImageRotation();

                // orientierung des zuschnitts bestimmen
                orientation = ImageOrientation.NORMAL_0;
                if (flipped) {
                    if (rotation == 0) {
                        orientation = ImageOrientation.FLIPPED_0;
                    }
                    if (rotation == 90) {
                        orientation = ImageOrientation.FLIPPED_90;
                    }
                    if (rotation == 180) {
                        orientation = ImageOrientation.FLIPPED_180;
                    }
                    if (rotation == 270) {
                        orientation = ImageOrientation.FLIPPED_270;
                    }
                } else {
                    if (rotation == 0) {
                        orientation = ImageOrientation.NORMAL_0;
                    }
                    if (rotation == 90) {
                        orientation = ImageOrientation.NORMAL_90;
                    }
                    if (rotation == 180) {
                        orientation = ImageOrientation.NORMAL_180;
                    }
                    if (rotation == 270) {
                        orientation = ImageOrientation.NORMAL_270;
                    }
                }
                
                // auflösung neu zuschneiden, mit der gleichen auswahl, spiegelung & drehung wie bisher
                cropImage = PictureCropImage.of(media, picture, resolution.getResolution());
                cropImage.store(selection, orientation);
            }
        }
        // neue revision speichern
        media.save("webp migration");
        // write lock
        media.setLock(false);
    }
}

// über alle medien in diesem ordner iterieren
for(elem:e.getChildren().iterator())
{
    rewriteImages(elem);
}

 

Falls es für dieses Vorgehen ein besseres oder anderes Verfahren von FirstSpirit-Seite gibt, wäre ich daran sehr interessiert. Das Skript, was ich geschrieben habe benutzt nämlich Methoden die nicht aus der API stammen.

Viele Grüße
Fabian

 

hoebbel
Crownpeak employee

Hallo Fabian,

für manuell zugeschnittene Bilder wird die Funktionalität (unter der internen ID "CORE-14293") wahrscheinlich mit 2023.10 verfügbar sein. Änderungen der ImageWriteParams wirken sich dann auch auf manuelle Skalierungen der Bilder aus. 

Viele Grüße
Holger

P.S. Das Feature wurde in 2023.9 noch zurückgehalten, da es in seltenen Fällen Probleme gab, wenn das Originalbild ausgetauscht wurde, nachdem der Zuschnitt gesetzt wurde (bei Nutzung der Archivierung bzw. beim Transport der entsprechenden Bilder). 

0 Kudos
f_koenig
Returning Observer

Hallo Holger,

kannst du mir sagen, ob die von dir angesprochene Funktionalität  (interne ID "CORE-14293") mittlerweile umgesetzt wurde und verfügbar ist?

Viele Grüße
Fabian

0 Kudos
hoebbel
Crownpeak employee

Hallo Fabian,

ja, die Funktionalität ist seit der Version 2023.10 verfügbar.

Die Funktionalität bewirkt, dass bei der Auslieferung von Auflösungen (entweder mit Zuschnittinformationen [also manuell oder mit Smart Cropping zugeschnittene Bilder] oder bei automatisch skalierte Bilder) geprüft wird, ob das Bild mit den aktuellen ImageWriteParams Parametern erzeugt wurde. Wenn nicht, wird das Bild neu berechnet.

Das hat in der Praxis folgende Auswirkungen:

* Wenn ImageWriteParams gesetzt sind, werden alle Auflösungen einmalig neu berechnet (da die Information, mit welchen Parametern berechnet wurde, nicht zur Verfügung steht)
* Wenn ein Bild neu zugeschnitten wird, so wird es nun erst berechnet, wenn die Auflösung angefordert wird. Bisher wurden die beim Zuschnitt sofort neu berechnet, was dazu führen konnte, dass für Redakteure Wartezeiten nach der Zuschnittaktion entstanden. Diese Berechnungszeiten sind nun auf die Zeit vor der erstmaligen Auslieferung der Auflösung verschoben worden. (das ist üblicherweise entweder eine Vorschau bzw. Generierung oder das Betrachten des zugeschnittenen Bildes).

Viele Grüße
Holger

0 Kudos
StefanS
Returning Observer

Hey Holger,

nur zur Sicherheit, damit ich das auch richtig verstehe: Durch die Änderung in 2023.10 ist auch ein manuelles Zurücksetzen der berechneten Auflösungen über das ominöse RepoViewer-Skript nicht mehr erforderlich. Stimmt das so?

In den Release-Notes habe ich dazu irgendwie nichts gefunden.

Dank und Gruß
Stefan

0 Kudos
hoebbel
Crownpeak employee

Hallo Stefan,

korrekt. Die bereits berechneten Auflösungen brauchen nicht mehr gelöscht zu werden, wenn die ImageWriteParams geändert werden. 
Man sollte aber auf den Fallstrick achten, dass die SEO URLs potentiell gespeichert sind. Wenn man also den Dateityp ändert, kann es sinnvoll sein, die SEO URLs für die Medien zurückzusetzen (ansonsten könnten beispielsweise webp Bilder mit der Endung jpg generiert werden, wenn bei der Vergabe der SEO URL für die Auflösung noch jpeg erzeugt wurde).

Die Ankündigung in den Release Notes erfolgte bereits mit 2023.9 (Kapitel 9.1). Ich vermute, dass liegt daran, dass die Änderung in dieser Version bereits vorhanden war, aber über einen Feature-Switch dort noch deaktiviert wurde (aufgrund eines Folgefehlers, der "erst" mit 2023.10 behoben werden konnte)

Viele Grüße
Holger