Aktualisierung functions.api.images.php

Fragen zur Installation von CONTENIDO 4.10? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Aktualisierung functions.api.images.php

Beitrag von bodil » Fr 10. Jul 2020, 11:38

Liebe Gemeinde!
Seit einiger Zeit spiele ich mit dem Gedanken, einen Ersatz für die functions.api.images.php zu schaffen. Ich finde sie im Einsatz unhandlich und sehe darin, dass sie moderne Bildformate (webp) nicht unterstützt, einen großen Nachteil. Für die aktuelle Anforderung, dass ich ein Bild zum Beispiel in einem <picture>-Element in 5 Größen und sowohl als webp wie auch als jpg brauche, ist sie nicht gedacht.
Eigentlich schwebt mir eine Klasse vor, die mit dem Bild, das ich verwenden will, einmal initialisiert wird und die mir dann Bilder in beliebigen Größen und Datenformaten zur Verfügung stellt.
Die Idee, wie die functions.api.images.php Bilder cacht finde ich gut, was ich aber nicht verstehe ist die eingesetzte Cache Time, die eine Zeitangabe in Minuten erwartet. Erinnert sich jemand an den Sinn dessen? Es geht ja nicht um Speicherplatz. »Abgelaufene« Bilder im Cache werden ja nicht gelöscht, sie werden nur überschrieben, falls sie nach Ablauf der Cache-Zeit erneut angefragt werden.
Nach meinem Verständnis ist dieses Überschreiben aber nur dann sinnvoll, wenn das Originalbild geändert wurde (und dabei seinen Dateinamen beibehalten hat).
Und da wäre es meiner Meinung nach sinnvoller, in der Tabelle con_upl zu jedem Medium den Dateihash (md5_file($filename)) zu pflegen und den bei der Erstellung des Hash-Namens der Cachedatei mit einzubeziehen. Der müsste beim Upload der Bilder (und bei allen anderen Gelegenheiten, bei denen Bilder in die DB geschrieben werden) ermittelt und eingetragen werden.
Ein Nachteil ergäbe sich dann, wenn Dateien häufig durch namensgleiche Dateien überschrieben werden, dann liefe der Cache voll. Wäre aber hinnehmbar, denke ich.
Was meint ihr? Oder bietet Contenido längst eine Lösung für webp, die ich nur noch nicht kenne?
Grüße!
Bodil

Update: Ich stelle gerade fest, dass mit jedem Generieren des Hashs für die Cache-Datei ein md5_file() auf das Originalbild gemacht wird. Das löst mein Problem im Prinzip. Es klingt aber auch etwas inperformant, oder?
Das größte Bild im Upload-Bereich eines zufällig ausgewählten Kunden hat 450 kB. Den Hash zu erzeugen dauert 1,5 ms. Jedes mal?

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » Fr 10. Jul 2020, 15:54

Hi!
Ich hatte auch schon den Tag, als ich dachte, ich müsse auch webp einführen und fand in diesen Funktionen nichts.
Ja, die functions.api.images.php könnte man erweitern aber praktisch gab es keinen Nutzen für webp.
Ein Bild, das mein Grafikprogramm nicht versteht und damals auch nicht alle Browser?
Wozu, wenn sinnvolle Bildgröße und jpeg oder png noch bestens funktionieren? Sogar gif ist hin und wieder gut.
Ich denke, webp wird sich nicht so recht durchsetzen, wie kW gegen PS, zumindest sieht es nicht danach aus.
Praktisch brachte es mir Nutzen, die Einstellungsmöglichkeiten der Contenido-Funktionen zu nutzen.

Aber der Vollständigkeit halber wäre es gut, wenn es in der api drin wäre:
https://www.php.net/manual/de/function.imagewebp.php
Da hängt halt ein Rattenschwanz hinten dran, der dann auch bearbeitet werden müsste.

Kann man auch selbst einbauen im eigenen Modul.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von bodil » Fr 10. Jul 2020, 19:47

Hi Faar!
Da gibt es einerseits die Frage nach dem praktischen Nutzen von webp-Bildern. Den halte ich für gering, auch wenn außer Safari inzwischen alle Browser webp-Bilder unterstützen.
Andererseits gibt es Tools wie das hier von Google
https://developers.google.com/speed/pagespeed/insights/
das Vorschläge macht, wie die Ladezeit verbessert werden kann. Auch die Webconsole (https://search.google.com/search-console) (auch von Google) suggeriert im Prinzip: Dauert das Laden deiner Seite zu lang, wirst du schlechter gerankt. Besser wärs, du bietest Browsern auch webp-Versionen (eine Google-Erfindung) deiner Bilder an.
Und wenn das Ranking dann mies ist und das der Mitbewerber blendend, stellt sich zwangsläufig die Frage nach webp-Bildern.
Ich fand es übrigens nicht einfach, die so nachzurüsten, dass die auch sauber gecacht werden.

Aber um noch mal auf die andere Frage zurückzukommen: weiß jemand, welchen Sinn Bilder-Cache-Zeiten im Minutenbereich haben?
Dank und Gruß!
Bodil

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von xmurrix » Fr 10. Jul 2020, 22:18

Das Erweitern der functions.api.images.php um die Unterstützung weiterer Bildformate wie Webp oder SVG halte ich für eine sinnvolle Idee, das sollte auch einfach zu realisieren sein.

Aufwendiger wird es mit dem picture-Element. Hier sollte man einen eigenen CMS-Typ hinzufügen, das sehr ähnlich wie CMS_IMG funktioniert. Bildelemente, also picture- und img-Tags um mehrere Sourcen, sizes- und srcset-Attribute zu erweitern, ist auch etwas aufwendig. Irgendwo sollte man mehrere Sets konfigurieren können um diese bei der Konfiguration der CMS-Typen auszuwählen. Dabei sollte man jedes der einzelnen Bilder bei Bedarf aus dem upload-Verzeichnis auswählen können.

Natürlich kann man auch die Funktionen in functions.api.images.php komplett überarbeiten, aber da gibt es weitaus wichtigere Punkte, wie Bugs, die zuerst behoben werden sollten.

Dass jedes Mal der Hash der Datei ermittelt wird, ist nicht ideal, man könnte als Alternative den Hash aus dem vollen Pfad zur Datei + Dateigröße + Datum der letzten Änderung ermitteln. Das sollte eindeutig genug und viel schneller sein.

Grüße
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » Sa 11. Jul 2020, 09:05

bodil hat geschrieben:
Fr 10. Jul 2020, 19:47
Andererseits gibt es Tools wie das hier von Google
https://developers.google.com/speed/pagespeed/insights/
das Vorschläge macht, wie die Ladezeit verbessert werden kann.
Das ist mit Vorsicht zu genießen.
Google möchte dies und das und ich möchte auch viel und meine Kunden noch mehr.
Nicht alles, was Google möchte oder vorschlägt, ist gut.
Auch die Webconsole (https://search.google.com/search-console) (auch von Google) suggeriert im Prinzip: Dauert das Laden deiner Seite zu lang, wirst du schlechter gerankt.
Lang ist ein dehnbarer Begriff. Kunden wollen einen Vollbildslider in bester Qualität mit vielen Bildern?
Kein Problem, also 4000 x 1200 Pixel Bilder (bester Qualität) rein, und damit das auch schön läuft, gleich alle Bilder vorladen.
Wenn ich dann am Bilddateiformat optimiere, betreibe ich bestenfalls Kosmetik.

Code: Alles auswählen

Besser wärs, du bietest Browsern auch webp-Versionen (eine Google-Erfindung) deiner Bilder an.
Und zufällig hat mir Pagespeed und Search-Console das vorgeschlagen?
Und wenn das Ranking dann mies ist und das der Mitbewerber blendend, stellt sich zwangsläufig die Frage nach webp-Bildern.
Ranking hängt von vielen Faktoren ab.
Die Bildladezeit ist ein sehr kleiner davon, außer bei lahmen Leitungen und Trafficbremse im Mobilfunk.
Witzig ist, dass jene die mit webp etwas optimieren wollen, dafür Bootstrap, hundert Schriftarten und große Javascript-Frameworks einsetzen.
"Hey, da ist ein Fliegenschiss, der muss weg." - "...und der Kackhaufen in der Ecke?" :?
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » Sa 11. Jul 2020, 09:33

xmurrix hat geschrieben:
Fr 10. Jul 2020, 22:18
Das Erweitern der functions.api.images.php um die Unterstützung weiterer Bildformate wie Webp oder SVG halte ich für eine sinnvolle Idee, das sollte auch einfach zu realisieren sein.
Sinnvoll ja, auf jeden Fall aber bei SVG habe ich doch Fragen, wie das funktionieren soll?
SVG ist keine Bitmap-Grafik sondern Vektoren in einer Art XML beschrieben (ähnlich wie eine alte CAD oder Plottersprache).
Eine webp Funktion dazubauen ist fast wie copy&paste aber ich meine den Rattenschwanz hinterher.
In wie vielen Dateien ist gif,tiff,jpeg und png schon enthalten und müsste erweitert werden?
Auch im Uploadprogramm usw.
Aufwendiger wird es mit dem picture-Element.
Ja. Hierfür habe ich sonst fertiges HTML eingesetzt und vielleicht sogar ein Modul gebaut, mit dem man die Bilder einzeln auswählen kann.
Hier sollte man einen eigenen CMS-Typ hinzufügen, das sehr ähnlich wie CMS_IMG funktioniert.
Ja.
Bildelemente, also picture- und img-Tags um mehrere Sourcen, sizes- und srcset-Attribute zu erweitern, ist auch etwas aufwendig. Irgendwo sollte man mehrere Sets konfigurieren können um diese bei der Konfiguration der CMS-Typen auszuwählen. Dabei sollte man jedes der einzelnen Bilder bei Bedarf aus dem upload-Verzeichnis auswählen können.
Ok, aber bei Slidermodulen die manuelle Auswahl haben, muss das ja auch so sein.
Die Teaser-Module sind da nahe dran.

Wie wäre die Idee, auch ein img-map Modul zu bauen?
Natürlich kann man auch die Funktionen in functions.api.images.php komplett überarbeiten
Gute Idee. :)
...aber da gibt es weitaus wichtigere Punkte, wie Bugs, die zuerst behoben werden sollten.
Es gibt noch Bugs? :shock:
Dass jedes Mal der Hash der Datei ermittelt wird, ist nicht ideal, man könnte als Alternative den Hash aus dem vollen Pfad zur Datei + Dateigröße + Datum der letzten Änderung ermitteln. Das sollte eindeutig genug und viel schneller sein.
Wird tatsächlich der Hash der Datei selbst ermittelt? Ich war der Meinung, dass es nur Dateiname ist?
Also eher so, wie von dir vorgeschlagen.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von bodil » Sa 11. Jul 2020, 17:22

Vielen Dank für das umfangreiche Feedback! Weil es hier um viele verschiedene Aspekte geht, versuche ich meine Antwort zu gliedern:

Technische Relevanz von webp
Da stimme ich Faar voll zu. Der Nutzen (den es tatsächlich gibt) rechtfertigt den zusätzlichen Aufwand nicht. Aber da gibt es zum einen Google. Und die sagen: Wir bauen den populärsten Browser, wir betreiben die relevanteste Suchmaschine. Und wenn du willst, dass du gut gerankt wirst, dann benutz gefälligst das Bildformat, das wir uns auch ausgedacht haben, egal ob das technisch sinnvoll ist. Da ist bei Googles Marktmacht schwer gegen anzustinken.
Und wenn man dann noch Kunden hat, die die Tools nutzen, die Google ebenfalls zur Verfügung stellt, ist es schwierig zu argumentieren. Nach meiner Wahrnehmung forciert Google das gerade. Unterseiten, die zu langsam laden, werden in der Search Console (Abschnitt »Core Web Vitals«[!]) als »schlechte URLs« bezeichnet.

Hash-Bildung
Gleich die erste Funktion in der functions.api.images.php bildet den Hash und nutzt dabei md5_file() – falls die Funktion zur Verfügung steht. Mir gefällt Xmurrix' Idee, den Hash anders zu generieren.

Klasse oder Funktionssammlung?
Bei Verwendung der functions.api.images.php bekomme ich für jedes Bild, das ich »oben reinstecke« genau ein Bild »unten raus«. Das war mal sinnvoll, ist aber dann nicht mehr zeitgemäß, wenn man zu einem Originalbild zehn Versionen generieren will. Denn das bedeutet, zehn mal dasselbe Bild einzulesen und dann zu verarbeiten. Mit einer Klasse hätte ich die Möglichkeit ein Objekt pro Originalbild zu bilden (mit allem was dazu gehört: Größe ermitteln, Hash bestimmen, Dateiformat ermitteln, ggf. zuschneiden ...) und mir davon beliebig viele Versionen generieren zu lassen. Daher finde ich das Konzept der bestehenden Api-Datei nicht mehr zeitgemäß.

SVG-Dateien
sind eine ganz andere Baustelle. Sie haben ja den Vorteil, dass sie nicht skaliert werden müssen, insofern muss eine Bilder-Api mit ihnen nicht umgehen können.

Grüße!
Bodil

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von xmurrix » So 12. Jul 2020, 07:44

Faar hat geschrieben:
Sa 11. Jul 2020, 09:33
...Sinnvoll ja, auf jeden Fall aber bei SVG habe ich doch Fragen, wie das funktionieren soll?...
die Funktionen in functions.api.images.php kennen SVG nicht, daher wird der Aufruf mancher Funktionen mit einem SVG nicht den Pfad zum SVG zurückliefern, sondern false. Die sollten nichts machen und einfach das SVG zurückliefern.
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » So 12. Jul 2020, 10:55

xmurrix hat geschrieben:
So 12. Jul 2020, 07:44
Faar hat geschrieben:
Sa 11. Jul 2020, 09:33
...Sinnvoll ja, auf jeden Fall aber bei SVG habe ich doch Fragen, wie das funktionieren soll?...
die Funktionen in functions.api.images.php kennen SVG nicht, daher wird der Aufruf mancher Funktionen mit einem SVG nicht den Pfad zum SVG zurückliefern, sondern false. Die sollten nichts machen und einfach das SVG zurückliefern.
OK, das macht dann Sinn. :)
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » So 12. Jul 2020, 11:43

bodil hat geschrieben:
Sa 11. Jul 2020, 17:22
Wir bauen den populärsten Browser,
Das war der IE von MS auch einmal.
Google Chrome ist einfach überall mit drin, daher angeblich populärster Browser und ich nutze ihn nicht.
Und wenn du willst, dass du gut gerankt wirst, dann benutz gefälligst das Bildformat, das wir uns auch ausgedacht haben, egal ob das technisch sinnvoll ist.
Das habe ich nie und dennoch waren meine SEO Aufträge recht bald sehr weit oben, also ganz oben.
Sollte heraus kommen, dass Google nach Bildformat aussortiert, ist Google fertig als Suchmaschine.
Eine Suchmaschine macht nur so lange Sinn, wie sie etwas findet.
Das weiß Google auch.
Da ist bei Googles Marktmacht schwer gegen anzustinken.
Wenn man es nie tut, wird es auch so sein.
Ich habe aber nicht das Gefühl, dass all zu viele hier Google folgen.
Und wenn man dann noch Kunden hat, die die Tools nutzen,
Doof, ne? Andere Kunden suchen.
Mir hat vor gut 10 Jahren mal einer was weiß machen wollen, der auch mit Tools hantierte.
Man sollte halt auch wissen, was so ein Tool macht und was das Ergebnis aussagt.
Ich habe dann gemacht, was ich für richtig hielt und hatte damit vollen Erfolg.
Das Tool konnte er weg werfen, wollte er aber nicht.
Irgendwann war ich diesen Kunden los und das war gut so.
die Google ebenfalls zur Verfügung stellt, ist es schwierig zu argumentieren.

So ein Zufall, dass Google Tools auch gleich Google Technik empfehlen.
Vielleicht ist WebP gut, dann wird es sich durchsetzen, oder es ist eine Seifenblase.
Nach meiner Wahrnehmung forciert Google das gerade.
Umso mehr sollte man dagegen halten.
Firefox und Co. haben auch SSL forciert und am Ende macht es nichts als Ärger, weil SSL immer noch nicht alltagstauglich ist.
Gerade frisch gemeldet, sollte man seine Zertifiakte überprüfen, weil wieder eine ganze Latte als ungültig erklärt wurde.
SSL für Shops, Banken und Formulare, ok, aber für reine "ich bin auch im Web"-Seite ist das quatsch.
Unterseiten, die zu langsam laden, werden in der Search Console (Abschnitt »Core Web Vitals«[!]) als »schlechte URLs« bezeichnet.
Dann sollte man sich fragen, warum die so langsam laden. Ein großes Bild das am Stück übertragen wird, braucht nicht so lange.
Wenn man da ein paar Prozent weniger Dateigröße hat, macht es den Braten nicht fett.
Kleinere Bildgröße dagegen wirkt Wunder.
Im Zweifel ein anderes Tool benutzen.

Bei Verwendung der functions.api.images.php bekomme ich für jedes Bild, das ich »oben reinstecke« genau ein Bild »unten raus«. Das war mal sinnvoll, ist aber dann nicht mehr zeitgemäß, wenn man zu einem Originalbild zehn Versionen generieren will. Denn das bedeutet, zehn mal dasselbe Bild einzulesen und dann zu verarbeiten. Mit einer Klasse hätte ich die Möglichkeit ein Objekt pro Originalbild zu bilden (mit allem was dazu gehört: Größe ermitteln, Hash bestimmen, Dateiformat ermitteln, ggf. zuschneiden ...) und mir davon beliebig viele Versionen generieren zu lassen. Daher finde ich das Konzept der bestehenden Api-Datei nicht mehr zeitgemäß.
Also, man kann Funktionen so schreiben, dass sie viele Parameter übernehmen können und Arrays, statt nur einem Bild.
Eine Klasse macht das intern nicht anders, sie hat solche Funktionen im Bauch.
Eine Klasse, die nur je ein Bild verarbeiten kann, ist dann auch nicht besser als die derzeitige Funktion, braucht aber vermutlich mehr Speicherplatz.
Alles was Du da beschreibst, macht eine Funktion auch, nur eben kein Objekt.
Hat mit Zeitgemäß nichts zu tun, sondern mit Effizienz.

Jetzt komme ich und erzähle mal was von zeitgemäßen Dateigrößen.
Wie groß könnte ein 24 Megapixel großes Bild sein? Also in Megabyte.
Ganz Schlaue kommen dann und erzählen etwas von Kompression, weil jpeg und webp.
Aber im Rechenspeicher zu Bildbearbeitung ist das Bild immer dekomprimiert, also so wie ein Bitmap oder unkomprimiertes Tiff.
Kann ein Bild schnell mal 50 bis 100 Megabyte groß sein.
Wenn ich nun zehn Bilder reinstecke und davon je zehn Versionen generieren, habe ich wie viele Bilder dieser Größe im Rechenspeicher?
Nicht zu vergessen, dass bei Bearbeitung die Bilder meistens gecashed werden, also noch eine weitere Version vorhanden ist.
Und nun soll so eine Klasse auch noch aus jeder Bildversion ein Objekt machen, das zusätzlich noch alles aufbläht?
Zuschneiden und den richtigen Ausschnitt finden soll die Klasse auch noch können?

Also, wenn ich mit Photoshop arbeite, lade ich meistens nur ein einziges Bild rein und bearbeite das.
Ich habe einen schnellen Rechner aber würde ich gleichzeitig mehrer Fotos bearbeiten, hätte ich keinen schnellen Rechner mehr.
Bei einem Fotografen ist das Grafik Plugin abgestützt, weil es die Originalfotos nicht bearbeiten konnte, dazu reichte der Serverplatz nicht aus.
Die meisten Serverplätze reichen nicht für solche Bildverarbeitung aus.
Wenn man sowas in den Griff kriegen will, muss man mit Stapelverabeitung und intelligentem Cashen anfangen, am besten über einen Cronjob, der ein Bild nach dem anderen durchnudelt.
Machbar ist sowas schon, nur ist sehr viel Programmiererei nötig, damit das läuft.
Das lohnt sich nicht, außer jemand will explizit sowas haben.
Aber dann richtet man ihm auch einen eigenen Server für sowas ein.
Bildportale gibts ja genug, die haben sowas sicher.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von bodil » So 12. Jul 2020, 14:29

Und nun soll so eine Klasse auch noch aus jeder Bildversion ein Objekt machen, das zusätzlich noch alles aufbläht?
Nein. Eben nicht. Ich brauche von einem Bild 10 Varianten. Dafür reicht mir ein Objekt. Dafür muss ich einmal das Originalbild einlesen und aus dem generiere ich (in dem einen Objekt) die zehn Varianten. Der Jetztzustand ist, dass ich zehn mal dasselbe Originalbild einlese und das dann jeweils bearbeite. Der Rechenaufwand verringert sich mit dem Objekt also um neunmal Bildeinlesen.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von Faar » Di 14. Jul 2020, 18:53

Ich glaube, da verringert sich nichts.
Aber vielleicht hat noch jemand eine Meinung oder Wissen dazu.

Zu WebP gibts aktuell eine Aussage, leider nur auf Englisch:
https://siipo.la/blog/is-webp-really-better-than-jpeg

Die neuere JPEG Komprimierung ist demnach besser als WebP.
Wozu also sich mit WebP noch abgeben?
Nur weil Google es so will?
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von bodil » Mi 15. Jul 2020, 14:48

Gut!
Andere Frage:
Die functions.api.images.php benutzt ImageMagick, falls vorhanden und gewünscht. Jetzt geht es in der Api um nichts Weltbewegendes: Bilder werden verkleinert und gespeichert. Welchen Vorteil bietet da ImageMagick? Geht das schneller? Macht das hübschere Bilder?
(Und falls noch jemand einfällt, warum da mit Cache-Zeiten in der Größenordnung von Minuten operiert wird: würde mich auch interessieren.)
Dank und Gruß aus dem hohen Norden!
Bodil

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von xmurrix » Mi 15. Jul 2020, 22:07

bodil hat geschrieben:
Mi 15. Jul 2020, 14:48
...Welchen Vorteil bietet da ImageMagick? Geht das schneller? Macht das hübschere Bilder?...
Laut Google ist ImageMagick zwar langsamer als PHP GD, dafür macht es hübschere Bilder. Vermutlich wird man den Unterschied nicht erkennen können.

ImageMagick kann sehr viel mehr als die PHP GD, allerdings wird in CONTENIDO keines dieser Features benutzt, von daher kann man auch bei PHP GD bleiben.

Gruß
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.

bodil
Beiträge: 340
Registriert: Fr 7. Okt 2011, 04:10
Kontaktdaten:

Re: Aktualisierung functions.api.images.php

Beitrag von bodil » Do 16. Jul 2020, 13:45

Das klingt vernünftig! Vielen Dank!

Antworten