Aktualisierung functions.api.images.php
Aktualisierung functions.api.images.php
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?
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?
Re: Aktualisierung functions.api.images.php
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.
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.
Re: Aktualisierung functions.api.images.php
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
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
Re: Aktualisierung functions.api.images.php
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
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.
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.
Re: Aktualisierung functions.api.images.php
Das ist mit Vorsicht zu genießen.bodil hat geschrieben: ↑Fr 10. Jul 2020, 19:47Andererseits 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.
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.
Lang ist ein dehnbarer Begriff. Kunden wollen einen Vollbildslider in bester Qualität mit vielen Bildern?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.
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.
Ranking hängt von vielen Faktoren ab.Und wenn das Ranking dann mies ist und das der Mitbewerber blendend, stellt sich zwangsläufig die Frage nach webp-Bildern.
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.
Re: Aktualisierung functions.api.images.php
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.
Ja. Hierfür habe ich sonst fertiges HTML eingesetzt und vielleicht sogar ein Modul gebaut, mit dem man die Bilder einzeln auswählen kann.Aufwendiger wird es mit dem picture-Element.
Ja.Hier sollte man einen eigenen CMS-Typ hinzufügen, das sehr ähnlich wie CMS_IMG funktioniert.
Ok, aber bei Slidermodulen die manuelle Auswahl haben, muss das ja auch so sein.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.
Die Teaser-Module sind da nahe dran.
Wie wäre die Idee, auch ein img-map Modul zu bauen?
Gute Idee.Natürlich kann man auch die Funktionen in functions.api.images.php komplett überarbeiten
Es gibt noch Bugs?...aber da gibt es weitaus wichtigere Punkte, wie Bugs, die zuerst behoben werden sollten.
Wird tatsächlich der Hash der Datei selbst ermittelt? Ich war der Meinung, dass es nur Dateiname ist?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.
Also eher so, wie von dir vorgeschlagen.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.
Re: Aktualisierung functions.api.images.php
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
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
Re: Aktualisierung functions.api.images.php
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.
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.
Re: Aktualisierung functions.api.images.php
OK, das macht dann Sinn.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.
Re: Aktualisierung functions.api.images.php
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.
Das habe ich nie und dennoch waren meine SEO Aufträge recht bald sehr weit oben, also ganz oben.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.
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.
Wenn man es nie tut, wird es auch so sein.Da ist bei Googles Marktmacht schwer gegen anzustinken.
Ich habe aber nicht das Gefühl, dass all zu viele hier Google folgen.
Doof, ne? Andere Kunden suchen.Und wenn man dann noch Kunden hat, die die Tools nutzen,
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.
Umso mehr sollte man dagegen halten.Nach meiner Wahrnehmung forciert Google das gerade.
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.
Dann sollte man sich fragen, warum die so langsam laden. Ein großes Bild das am Stück übertragen wird, braucht nicht so lange.Unterseiten, die zu langsam laden, werden in der Search Console (Abschnitt »Core Web Vitals«[!]) als »schlechte URLs« bezeichnet.
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.
Also, man kann Funktionen so schreiben, dass sie viele Parameter übernehmen können und Arrays, statt nur einem Bild.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äß.
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.
Re: Aktualisierung functions.api.images.php
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.Und nun soll so eine Klasse auch noch aus jeder Bildversion ein Objekt machen, das zusätzlich noch alles aufbläht?
Re: Aktualisierung functions.api.images.php
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?
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.
Re: Aktualisierung functions.api.images.php
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
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
Re: Aktualisierung functions.api.images.php
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.
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.
Re: Aktualisierung functions.api.images.php
Das klingt vernünftig! Vielen Dank!