Contao: generierte Bilder im Frontend größer als original

[exscorp]

Affected version(s)

4.8.2 (möglicherweise auch frühere)

Description

Bilder die im Frontend generiert werden sind von der Dateigröße um einiges größer als die original Bilder. Bei PNG fällt das besonders auf. Einige Bilder werden dann doppelt bis dreimal so groß.

z.B. dieses 4 kb Bild wird dann zu 14 kb

How to reproduce

Contao-Demo

• Textelement erstellen
• Bild hinzufügen (z.B. contao_extensions.png » 193 kb)
• Speichern
• Frontend aufrufen
• Das Bild hat jetzt 208 kb

[fritzmg]

? Wenn du keine Bildgröße angibst wird doch einfach nur das Originalbild ausgegeben.

[exscorp]

anscheinend nicht. ist ja auch in der Contao-Demo reproduzierbar.

habe es gerade in einer 4.7.7 ausprobiert. dort passiert das nicht.

[fritzmg]

Oh, wird es tatsächlich nicht. Obwohl keine Bildgröße angegeben wurde, wird das Bild offensichtlich von Contao prozessiert - und dann aber mit der selben Größe (800x600 im Fall von contao_extensions.png) wieder ausgegeben. /cc @ausi

[ausi]

Contao generiert seit Version 4.8.0 alle Bilder in der eingestellten Qualitätsstufe außer für Bildgrößen mit aktivierter Checkbox „Originalbild bei passenden Abmessungen verwenden“.

[leofeyer]

Aber die generierten Bilder sollten ja nicht dreimal so groß sein, oder?

[fritzmg]

Wie ich mit @ausi heute diskutiert habe, kann das momentane Verhalten etwas problematisch sein - also dass alle Bilder by default prozessiert werden.

Angenommen ein Redakteur hat sich ein Bild schon passend hergerichtet in der richtigen Größe und mit der für das Bild passenden JPEG Qualität von 90% (weil weniger vielleicht nicht gut aussehen würde, wenn bspw. viel Rot Anteil vorhanden ist). Dieses Bild soll dann in einem Element zum Einsatz kommen, wo keine Bildgröße verwendet wird - sondern immer das Originalbild ausgegeben wird.

In Contao 4.8 wird das Bild aber nun, by default, trotzdem prozessiert und noch dazu ein zweites mal neu komprimiert, bspw. mit der default 80% JPEG Qualität. Das ist einerseits schlecht, weil zwei mal komprimieren natürlich zu weiterem Qualitätsverlust führt - und andererseits wollte der Redakteur ja nicht, dass das Bild von Contao prozessiert wird.

Um das zu verhindern müsste man jetzt extra dafür eine Bildgröße anlegen - und diese Bildgröße dann bei _allen Elemeten_ nachträglich wieder einstellen.

Meiner Meinung nach sollte das Default Verhalten so wie früher sein - und nur auf Wunsch per in der Bildgrößen festgelegten Einstellung sollen auch Bilder prozessiert werden, die die gleichen Dimensionen wie die Ausgabegröße haben.

@ausi nebenbei gefragt: wird bei der EXIF Drehung eines JPEGs auch hier nochmal komprimiert? Oder wird verlustfrei gedreht (bin mir nicht sicher ob das bei JPEGs überhaupt geht)

Aber die generierten Bilder sollten ja nicht dreimal so groß sein, oder?

Wenn die GD lib statt Imagick verwendet wird, könnte das von GD neu erzeugete Bild weniger effizient komprimiert sein als das andere, vermutlich.

[Toflar]

Nur mal laut gedacht: Könnten wir nicht für die wenigen Fälle wo das vorkommt (ich glaube das Default-Verhalten stimmt) sowas machen wie "wenn der Dateiname mit np_ beginnt, lassen wir's aus"? np_ stünde dann in diesem Fall für "no processing" oder so.
Also im Idealfall irgend ein Präfix oder Suffix dessen Verwendung im täglichen Gebrauch höchst unwahrscheinlich ist? Oder statt np_image.jpg ggf. image.np.jpg?
Ihr wisst, was ich meine :)

[ausi]

Meiner Meinung nach sollte das Default Verhalten so wie früher sein - und nur auf Wunsch per in der Bildgrößen festgelegten Einstellung sollen auch Bilder prozessiert werden, die die gleichen Dimensionen wie die Ausgabegröße haben.

Ich würde das Default-Verhalten gerne so belassen, allerdings könnten wir eine Konfiguration contao.image.skip_if_dimensions_match hinzufügen mit der sich das Default-Verhalten ändern lässt.

wird bei der EXIF Drehung eines JPEGs auch hier nochmal komprimiert? Oder wird verlustfrei gedreht (bin mir nicht sicher ob das bei JPEGs überhaupt geht)

Es wird nochmal komprimiert, anders ist das leider nicht möglich. Eine verlustfreie Drehung wäre nur mit EXIF selbst möglich, was wir aus mangelndem Browser-Support nicht verwenden können.

[fritzmg]

ich glaube das Default-Verhalten stimmt

Naja, aber es kann doch nicht sein, dass Contao jetzt grundsätzlich ein JPEG immer zwei mal komprimiert, auch wenn es gar nicht notwendig ist, und das daher auf jeden Fall immer zu einer Qualitätsverschlechterung führt?

[ausi]

Eine Qualitätsverschlechterung tritt ein wenn die Original-Qualität höher ist, in diesem Fall kann der Effekt jedoch gewünscht sein wenn z. B. ein Redakteur ein Bild mit 100% Qualität hochlädt.

Bei gleicher oder niedriger Ausgangsqualität kann das erneute speichern zu Verlusten führen und die Dateigröße auch erhöhen.

Naja, aber es kann doch nicht sein, dass Contao jetzt grundsätzlich ein JPEG immer zwei mal komprimiert

Das war jetzt bereits immer der Fall wenn die Größe oder der Ausschnitt sich geändert hat. Das neue Verhalten hat den Vorteil, dass das Original-Bild in der Dateiverwaltung in einer sehr hohen Qualität vorliegen kann und somit bei jedem erzeugen Bild dann nur einmal der JPEG-Qualitätsverlust in Kauf genommen werden muss.

Was würde gegen eine globale Einstellung sprechen? Damit kann jemand der tatsächlich das alte Verhalten will mit wenig Aufwand umstellen.

[ausi]

Könnten wir nicht für die wenigen Fälle wo das vorkommt (…) sowas machen wie "wenn der Dateiname mit np_ beginnt, lassen wir's aus"?

Ich denke das ist zu viel Magic. Installationen können jetzt bereits Bilder mit solch einem Präfix enthalten. Zudem kann man Ausnahmen für einzelne Bilder ja bereits jetzt relativ einfach über eine eigene Bildgröße realisieren.

[exscorp]

Ich würde das Default-Verhalten gerne so belassen, allerdings könnten wir eine Konfiguration contao.image.skip_if_dimensions_match hinzufügen mit der sich das Default-Verhalten ändern lässt.

Das default-Verhalten kann ja so bleiben wenn man Ein Bild hinzufügen » Bildgröße etwas auswählt/verändert aber nicht wenn ich nur das original Bild ohne Bildgrößeneinstellungen einfüge.

Es wird gerade überwiegend über JPG geschrieben, bei PNG fällt der Dateigrößenunterschied viel deutlicher auf.

Es kann nicht sein, das ich Bilder passend für eine Site anlege/optimiere und Contao (ohne Größeneinstellungen) dann daraus einfach viel größere Datei generiert (s.o. PNG 4 KB » 14 KB).

So war z.B. eine Produktive (4.7) Seite bei 900 KB und ist jetzt (4.8) auf einmal 1.3 MB, klingt nicht nach viel aber wenn man Seiten optimiert, ist es schon einiges. Dazu meckert Lighthouse jetzt rum, das fast alle Bilder optimiert werden sollen.

[leofeyer]

Ich bin auch der Meinung, dass das Originalbild ausgegeben werden sollte, wenn keine Image-Size im Spiel ist. Bei den Image-Sizes würde ich aber "use the original image if dimensions match" weiterhin standardmäßig ausgeschaltet lassen.

[ausi]

OK. Also wenn gar keine Bildgröße angegeben ist, lassen wir das Bild ohne Konvertierung ausgeben (ausgenommen EXIF-Drehung). Wenn aber Breite/Höhe angegeben ist und das Bild genau diese Größe hat, machen wir schon die Konvertierung?

[fritzmg]

Das war jetzt bereits immer der Fall wenn die Größe oder der Ausschnitt sich geändert hat.

@ausi Ja, aber dann ist es ja auch zumindest ein neues Bild und der Redakteur weiß, dass da ein neues Bild generiert wird.

Es wird gerade überwiegend über JPG geschrieben, bei PNG fällt der Dateigrößenunterschied viel deutlicher auf.

@exscorp Im Unterschied zu JPG hast du bei PNG aber keine potentielle Qualitätsverschlechterung. Die Größenänderung bei PNG hängt wahrscheinlich damit zusammen, dass du GD verwendest, statt Imagick oder Gmagick (überprüfe das mal).

Eine Qualitätsverschlechterung tritt ein wenn die Original-Qualität höher ist, in diesem Fall kann der Effekt jedoch gewünscht sein wenn z. B. ein Redakteur ein Bild mit 100% Qualität hochlädt.

@ausi Ja, der Effekt kann gewünscht sein - aber wenn man von Contao <4.8 auf >=4.8 aktualisiert, erwartet man sich nicht, dass jetzt plötzlich alle Bilder prozessiert werden und entweder anders aussehen oder (wie im Fall von @exscorp) eine größere Dateigröße haben. Man muss sich darauf verlassen können, dass Bilder ohne angegebene Bildgröße unangetastet bleiben.

Das neue Feature ist ja toll - aber man sollte es auch dediziert einsetzen müssen :). Bspw. durch die Angabe einer Bildgröße (egal in welcher Form), so wie @leofeyer schreibt. Es sollte aber auch in der Bildgrößeneinstellung weiterhin möglich sein, das Verhalten zu deaktivieren.

[leofeyer]

Also grundsätzlich sehe ich es schon wie @ausi. Wir sollten alle generierten Bilder optimieren, auch wenn sie zufällig schon der geforderten Größe entsprechen.

Es sollte halt nur nicht so sein, dass die optimierten Bilder nachher 4 Mal so groß sind. Aber das ist ggf. ein gesondertes Problem, das man sich ansehen muss?

[ausi]

Ja, der Effekt kann gewünscht sein - aber wenn man von Contao <4.8 auf >=4.8 aktualisiert, erwartet man sich nicht, dass jetzt plötzlich alle Bilder prozessiert werden …

Alle bestehenden Bildgrößen werden im DB-Update von Contao 4.8 auch dementsprechend konfiguriert dass sie das alte Verhalten beihehalten. Es betrifft also nur Bilder ohne ausgewählter Bildgröße.

Wir sollten alle generierten Bilder optimieren, auch wenn sie zufällig schon der geforderten Größe entsprechen.

Mit der Ausnahme wenn gar keine Größe gewählt ist. Hier stimme ich zu, dass erwartet werden kann dass keine Änderung an der Datei vorgenommen wird.

Mein Lösungsvorschlag: Wenn gar keine Größe angegeben/ausgewählt ist bleibt das Bild unangetastet (Ausnahme EXIF) ansonsten bleibt das Verhalten wie bisher.
Zudem sollten wir prüfen warum die PNG-Bilder so groß werden (@exscorp dafür benötigen wir die information welche Imagelibrary bei dir zum Einsatz kommt: GD, Imagick oder Gmagick?)

[exscorp]

auf dem Server läuft PHP 7.3.9 mit GD

screenshot aus phpinfo

[ausi]

@exscorp bitte führe folgenden Command aus um zu sehen welche Bild-Library von Contao in deiner Installation verwendet wird:
vendor/bin/contao-console debug:container contao.image.imagine

[exscorp]

@ausi

// This service is a public alias for the service contao.image.imagine.JAQdgwp

Information for Service "contao.image.imagine.JAQdgwp"

Imagine implementation using the GD library.

---

Option Value

---

Service ID contao.image.imagine.JAQdgwp
Class Imagine\Gd\Imagine
Tags -
Public no
Synthetic no
Lazy no
Shared yes
Abstract no
Autowired no
Autoconfigured no

---

[ausi]

Das bedeutet in deiner Installation wird GD verwendet um die Bilder zu generieren.

Die PNG-Dateigröße kann eventuell verbessert werden wenn du die Konfiguration contao.image.imagine_options.png_compression_filter auf !php/const PNG_ALL_FILTERS und contao.image.imagine_options.png_compression_level auf 9 setzt.

[exscorp]

Ich habe auf dem Server jetzt imagick installiert, überall den cache gelöscht und alle Bilder neu generiert. Die PNG sind zwar nicht mehr 3x aber immer noch 2x so groß. (Beispielbild oben » statt 4kb » 8kb)

imagick module version 3.4.4

// This service is a public alias for the service contao.image.imagine.rl0p_o1
Information for Service "contao.image.imagine.rl0p_o1"
Imagine implementation using the Imagick PHP extension.

Option Value
Service ID contao.image.imagine.rl0p_o1
Class magine\Imagick\Imagine
Tags -
Public no
Synthetic no
Lazy no
Shared yes
Abstract no
Autowired no
Autoconfigured no

[ausi]

Für Imagick kannst du die Konfiguration
contao.image.imagine_options.png_compression_level auf 9 und
contao.image.imagine_options.png_compression_filter auf 5 oder 6 setzen.

[ausi]

Closed in favor of #755

[leofeyer]

contao.image.imagine_options.png_compression_level auf 9 und
contao.image.imagine_options.png_compression_filter auf 5 oder 6 setzen.

Sollten wir das vielleicht standardmäßig so konfigurieren?

[exscorp]

contao.image.imagine_options.png_compression_level auf 9 und
contao.image.imagine_options.png_compression_filter auf 5 oder 6 setzen.

Sollten wir das vielleicht standardmäßig so konfigurieren?

Ich habe diese Einstellungen ausprobiert.

png_compression_level 9
png_compression_filter 5

PNG war danach nur noch 5 kb (original 4 kb)

Bei png_compression_filter 6 war das PNG komischerweise 10 kb

[ausi]

contao.image.imagine_options.png_compression_level auf 9 und
contao.image.imagine_options.png_compression_filter auf 5 oder 6 setzen.

Sollten wir das vielleicht standardmäßig so konfigurieren?

Dafür müssten wir genauer untersuchen wie sich die Einstellungen (jeweils für GD, Gmagick und Imagick) auswirken und einen CompilerPass schreiben der je nach genutzter Imagine-Implementation die passenden Options setzt da es keinen einheitlichen Werte gibt die für alle Implementationen passt.

[fritzmg]

Ist es überhaupt möglich das selbe Resultat zu erzielen wie mit Tools wie optipng?

[ausi]

Ich denke mit Imagick sollte man recht weit kommen, wie gut es im Vergleich zu OptiPNG oder MozJPEG abschneidet müsste man aber testen.

[fritzmg]

Naja tools wie optipng etc. führen ja - je nach dem was man einstellt, sehr viele trials durch, bis die beste Kompression gefunden wurde (was ja je nach Bild auch lange dauern kann). Ich glaube Imagick unterstützt sowas nicht - daher wird man mit Imagick auch nie an die selbe kleine Dateigröße kommen, wie bei zuvor optimierten Bildern.