- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

