Performance bei Bildgrößen

[wanst]

Ich wollte das Bildgrößen-Tool in Contao nutzen, hab mir jetzt dazu auch die Anleitung von RockSolid durchgelesen und steige jetzt auch langsam durch.

In der Anleitung ist (ganz am Ende, vorm Fazit) davon die Rede, das man mit der Performance bei kleinen Hosting-Paketen aufpassen muss und nicht zu viele Bildvarianten erstellen lassen soll. Also hab ich das mal ein bisschen getestet, und meine Seite stieg schon mit drei Bildern pro Seite aus – zwei gingen noch. Dann wird komplett gar nichts mehr angezeigt – leere Seite.

Die Einstellungen waren am Anfang recht übersichtlich: 640px breit und 0.5x,1x,2x,4x als Varianten. Die Originalbilder sind alle 2560px breit.

Also weiter probiert, woran es liegen könnte. Weniger Varianten, andere Verhältnisse etc. – es hängt offensichtlich mit der Bildgröße zusammen, die berechnet werden soll. Bei etwa 2500px und mehr als zwei Bildern ist Schluss.

Hat jemand ne Idee, wo diese Grenze herkommt (und natürlich, wie man damit umgeht)? Oder ist es einfach nur die PHP-Speicherbegrenzung, und daraus resultieren dann die Maße/Mengen?

[Spooky]

Die Einstellungen waren am Anfang recht übersichtlich: 640px breit und 0.5x,1x,2x,4x als Varianten.

Das sind ja schon sehr viele Varianten . Pro Bild, wo du diese Bildeinstellung auswählst, werden dann 4 Bilder erzeugt.

Also weiter probiert, woran es liegen könnte.

Was meinst du damit? Finde zuerst mal heraus wo das Problem liegt (über Logs bzw. Server Logs). Wenn du da sehr viele Bilder ausgeben lässt - und dann eben die vorhin erwähnte Bildeinstellung verwendest, dauert das erzeugen dieser Unmengen an Bilder vielleicht einfach zu lang und du kommst über die max_execution_time hinaus. Das Server Log wird dir dazu mehr Aufschluss geben können.

[wanst]

Das sind ja schon sehr viele Varianten . Pro Bild, wo du diese Bildeinstellung auswählst, werden dann 4 Bilder erzeugt.

Das stimmt schon, im weiteren Verlauf hab ich dann nur noch zwei oder drei Varianten erzeugen lassen. Aber klar, da kommen schon ein paar zusammen – aber was ist denn der Vorteil, ggü. selbst im Photopop erzeugten Bildern?

Was meinst du damit?

Naja, wie gesagt, ich hab versucht, mich ranzutasten, mit verschiedenen Werten für Breite und Skalierung gespielt.

Finde zuerst mal heraus wo das Problem liegt (über Logs bzw. Server Logs). Wenn du da sehr viele Bilder ausgeben lässt - und dann eben die vorhin erwähnte Bildeinstellung verwendest, dauert das erzeugen dieser Unmengen an Bilder vielleicht einfach zu lang und du kommst über die max_execution_time hinaus. Das Server Log wird dir dazu mehr Aufschluss geben können.

Ist Server-Log = /system/logs/error.log ?

Da gibts nur Archive, also error.log.1, error.log.2 etc. und da steht ein Fehler drin. Bei aktivierter $GLOBALS['TL_CONFIG']['displayErrors'] = true; bekomme ich als Fehler:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 17479681 bytes) in /.../system/modules/core/library/Contao/GdImage.php on line 112

zu wenig Speicher, wie vermutet? Aber 17479681 (try to allocate) ist doch kleiner als 67108864 (allowed) ... ich steh aufm Schlauch.

[Spooky]

aber was ist denn der Vorteil, ggü. selbst im Photopop erzeugten Bildern?

Was meinst du damit? Vielleicht verstehst du Responsive Images falsch.

Wenn du zB eine 1x und 2x Source von einem Bild hast, das eine Ausgangsgröße von 300x200 hat, dann wird auf einem Device, das eine höhere Pixeldichte als DPPX = 1 hat das 2x Bild genommen - welches ja dann 600x400 groß ist (es wird aber trotzdem in 300x200 CSS Pixel dargestellt).

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 17479681 bytes) in /.../system/modules/core/library/Contao/GdImage.php on line 112

zu wenig Speicher, wie vermutet?

Ja, viel zu wenig Speicher. Dein memory_limit liegt bei nur 64 MiB - das reicht für Bildoperationen auf großen Bildern ganz sicher nicht aus.

[wanst]

Ach ja, noch was – kann man den Bildeintrag eigentlich noch nachträglich beeinflussen? Das größte Bild ist bei mir zum Beispiel immer das Original – das müsste ja gar nicht neu berechnet werden. Aber das weiß Contao natürlich nicht. Dazu muss ich am Template rumpfuschen, gell?

[wanst]

Was meinst du damit? Vielleicht verstehst du Responsive Images falsch.

Ja, nein, also doch – schon verstanden. Du hast natürlich recht – das lässt sich ja nicht anders umsetzen. Ich meinte, der Vorteil gegenüber den drei erzeugten Bildvarianten im Photoshop. Aber deshalb habe ich die ja noch lange nicht im HTML eingebunden –*klar.

Ja, viel zu wenig Speicher. Dein memory_limit liegt bei nur 64 MiB - das reicht für Bildoperationen auf großen Bildern ganz sicher nicht aus.

Ich hab das jetzt mal bei unserem Provider auf 192 hochgesetzt. Das geht schon besser. Es bleibt die Angst, das es auf dem Webspace der Kunden dann wieder Probleme damit gibt. Dieser Speicher steht ja dann fürs Script zur Verfügung (also ggf. 20 Bilder x 3 Auflösungen), oder? Das bedeutet, wenn es ein Kunde mal übertreibt, steigt PHP wieder ohne Vorwarnung einfach aus? Hm...

[Spooky]

Genau. Du kannst dem aber mit der Einstellung Maxime GD Bildbreite/höhe entgegen wirken. Das könntest du auf einen Wert setzen, der niedrig genug ist, damit es bei zu großen Bildern nicht zu einem memory overflow kommt. Das bedeutet aber auch, dass bei diesen Bildern keine Varianten ausgegeben werden, sondern nur immer das Original.

[wanst]

Das würde dem eigentlichen Zweck ja aber diametral gegenüber stehen

Das lässt sich auch nicht errechnen, oder? Nur abschätzen.

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?

[tab]

Vielleicht? Aber wie auch immer, das bessert ja dein Problem nicht, dass der Kunde es jedenfalls nicht so machen wird. Und wenn der Cache mal geleert wird, darfst du alle deine großen Bilder wieder auf diese Art und Weise neu in den Cache bringen.

[Spooky]

Das lässt sich auch nicht errechnen, oder? Nur abschätzen.

Ja, lässt sich nur abschätzen. Ich würde mal sagen bei bspw. 6 Megapixel brauchst du mindestens 256 MiB.

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?

Nein, nicht unbedingt. Das Problem ist, dass ein einzelnes Bild schon zu groß sein könnte.

[mlweb]

Nur mal so am Rand - auch Bilder mit eine Kantenlänge von 2500px, kann man vorher fürs Web optimieren (z.B. kostenfreies Webtool TinyPNG). Dann klappt das u.U. schon deutlich besser, bei den Berechnungen.

[tab]

Sollte eigentlich nichts bringen, da das notwendige RAM für das Bild nur von der Bildgröße in Pixel abhängt, egal ob das JPG 10KB oder 10MB groß ist.

[mlweb]

Danke, wieder was dazu gelernt.

[wanst]

Ja, lässt sich nur abschätzen. Ich würde mal sagen bei bspw. 6 Megapixel brauchst du mindestens 256 MiB.

Ah, OK –*das ist doch schonmal was. Also bisher haben meine Bilder so um die 3 Megapixel. Dann sollte ich doch mit meinen 192 MB/MiB recht locker hinkommen.

Nein, nicht unbedingt. Das Problem ist, dass ein einzelnes Bild schon zu groß sein könnte.

Aber dann könnte ich ja reagieren und das Bild nicht verwenden oder von vornherein mit kleineren Abmessungen nochmal hochladen. Davon würde ja der Besucher nichts sehen. Ist 'ne Krücke, ist klar. Aber für den Fall der Fälle besser als nix.

@mlweb: das erschließt sich mir auch nicht so ganz. Die Speichermenge, die ein Rechner braucht, um ein Bild zu berechnen, hängt doch nicht von der Dateigröße ab, die das Bild in gespeichertem, komprimierten Zustand auf einem Datenträger braucht, sondern hauptsächlich von den Abmessungen (und der Farbtiefe und drei mehr). Das gute alte Photopop nennt das schon immer, glaube ich, Arbeitsgröße – im Gegensatz zur Dateigröße. [edit: warste schneller ]

[wanst]

Den hätte ich ja fast übersehen.

Vielleicht? Aber wie auch immer, das bessert ja dein Problem nicht, dass der Kunde es jedenfalls nicht so machen wird. Und wenn der Cache mal geleert wird, darfst du alle deine großen Bilder wieder auf diese Art und Weise neu in den Cache bringen.

Richtig, aber 1. nur als Notbehelf und 2. ich lass doch keinen Kunden den Cache leeren – HALLO!

[tab]

Vielleicht habe ich ja deine Bedenken falsch verstanden. Meinst du das so, dass der Kunde zuviele Bilder mit zu vielen Auflösungen haben will und du das dann notfalls mit deinem Workaround einbaust? Ich bin halt davon ausgegangen, dass es so gemeint war, dass der Kunde da selbst Bilder/Bildgrößen definiert. Jedenfalls musst du aufpassen, da Contao zwar selten, aber regelmäßig den Bildercache leert.

Es bleibt die Angst, das es auf dem Webspace der Kunden dann wieder Probleme damit gibt. Dieser Speicher steht ja dann fürs Script zur Verfügung (also ggf. 20 Bilder x 3 Auflösungen), oder? Das bedeutet, wenn es ein Kunde mal übertreibt, steigt PHP wieder ohne Vorwarnung einfach aus? Hm...

[wanst]

Vielleicht habe ich ja deine Bedenken falsch verstanden. Meinst du das so, dass der Kunde zuviele Bilder mit zu vielen Auflösungen haben will und du das dann notfalls mit deinem Workaround einbaust? Ich bin halt davon ausgegangen, dass es so gemeint war, dass der Kunde da selbst Bilder/Bildgrößen definiert.

Die Anzahl der Bilder wird schon vom Kunden bestimmt, die Auflösung von mir. Es muss ja irgendwie passen, auf Smartphones und 27" Retina iMacs. Ungeachtet dessen gibt es zwar ein konkretes Projekt, aber eigentlich will das Thema prinzipiell mal durchdringen.

Jedenfalls musst du aufpassen, da Contao zwar selten, aber regelmäßig den Bildercache leert.

Oh. Also das ist aber blöd jetzt. Dann ist die einzige Option ein fetter Server?

Nochmal zurück zu einem der ersten Posts: kann ich den Eintrag noch weiter beeinflussen? Wenn ich im Moment mein Originalbild auch verwenden will, dann muss ich das irgendwie auf die Größe mit anlegen (also bspw. bei orig. 2560px Breite, mit 640px und 4x oder 512px und 5x), und dann wird es brav mitberechnet – also neu berechnet. Kann ich dem Eintrag nicht irgendwie mitgeben, dass er diese Größe nicht berechnen soll, sondern das Original verwenden? Nur übers Template, oder?

[tab]

Hmm, also ich habe eine Installation, bei der das große Originalbild automatisch direkt ausgeliefert wird ohne Berechnung. Das ist allerdings nur die einfache Variante mit "srcset=..." ohne <picture>.

[wanst]

Hmm, also ich habe eine Installation, bei der das große Originalbild automatisch direkt ausgeliefert wird ohne Berechnung. Das ist allerdings nur die einfache Variante mit "srcset=..." ohne <picture>.

Zusammen mit anderen Bildgrößen?

Benutzt du dafür die Bildgrößen-Eingabe von Contao? Was hast du da eingestellt oder hast du dann doch das Template bearbeitet, und wie sieht das dann aus?

[Spooky]

Nochmal zurück zu einem der ersten Posts: kann ich den Eintrag noch weiter beeinflussen? Wenn ich im Moment mein Originalbild auch verwenden will, dann muss ich das irgendwie auf die Größe mit anlegen (also bspw. bei orig. 2560px Breite, mit 640px und 4x oder 512px und 5x), und dann wird es brav mitberechnet – also neu berechnet.

Sicher? Zeige mal die Einstellungen und einen Link zur Seite wo man das sieht.

[wanst]

So langsam hab ich Blut geleckt. Jetzt will ich aber auch die, in dem RockSolidThemes erwähnten, Repsonsive Bilder mit »Art Direction« –*also Bildausschnitts-»Vergrößerung« ausprobieren.

Aber bedeutet das nicht, dass für jeden Eintrag, den ich da tätige und der sich dann im Picture-Element als <source...-Eintrag wiederfindet, NOCH ein zusätzliches Bild berechnet werden muss? Perfomancemäßig ist das doch mittlerer Wahn, oder?

[Spooky]

Ja, oder sogar mehrere pro <source> Einträge

[wanst]

Sicher? Zeige mal die Einstellungen und einen Link zur Seite wo man das sieht.

Nee, nicht sicher. Aber vermutlich schon, denn:
1. das Bild für 2560w im Quelltext ist ein neu Angelegtes im Cache mit einem Namenszusatz (bspw. Dateiname-cf909a77.jpg).
2. die Performance-Probleme hingen immer an dieser Bildgröße. Wenn ich die weggelassen habe, lief alles.

Link geht im Moment leider nicht, weil ich gerade wild am Testen bin und das ständig anders aussieht. Vielleicht setze ich vor Ostern noch einen Test auf, den ich dann hier verlinken kann.

Die Einstellungen:
Bildschirmfoto 2017-04-13 um 16.12.38.png

[wanst]

Ja, oder sogar mehrere pro <source> Einträge

Zack – und schon wieder gestorben...

Schade, Mann!

[lucina]

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?

Das läuft genau einen Monat lang. Danach räumt Contao den Bildercache auf.

Du solltest ernsthaft die Hostingoptionen prüfen. Auch die des Kunden - wobei ich mir ohnehin nicht vorstellen kann, dass jemand vierstellige Summen für Webseiten ausgibt um dann am Hosting zu sparen ... ;-)

[mlweb]

wobei ich mir ohnehin nicht vorstellen kann, dass jemand vierstellige Summen für Webseiten ausgibt um dann am Hosting zu sparen ... ;-)

Ist aber gelegentlich leider die Realität. Häufig geht es aber dabei nicht vorrangig nur um den Preis. Man scheut sich aus den verschiedensten, nicht immer nachvollziehbaren Gründen vor einem Umzug.
In letzter Zeit einige Male untergekommen ist mir Dienstleister A hat Hoster X in den höchsten Tönen gelobt und dem Kunden empfohlen. Der Kunde ist gerade dahin umgezogen bzw. hat den Vertrag gerade neu abgeschlossen. Dann rede ich mir mit meiner Empfehlung den Mund fusslig, entweder weil der Kunde den Aufwand nicht noch einmal haben will, Vertragslaufzeiten einzuhalten sind (keine Doppelzahlung) oder weil der Dienstleister sein Gesicht nicht verlieren will.
Anderes mehr oder weniger häufiges Szenario Dienstleister B hostet als Reseller selbst, möchte auf seine Kunden nicht verzichten und/oder arbeitet für so etwas mit äußerst knappen Ressourcen.

[wanst]

Ok, hab doch schnell einen Test aufgesetzt:
test.larxperimente.de

Die Bilder werden neu berechnet. Das mit dem blauen Fernrohr hat original 355 kB, das im Cache 426 kB. Wahrscheinlich war das Original stärker komprimiert. Also, noml die Frage: wie bring ich dem Dingen bei, dass es das originale Bild mitbenutzen soll?

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.

[mlweb]

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.

Den besten gibt es m.E. nicht. Ist ja auch ein Unterschied ob ich einen Shop betreibe oder eine Präsenzseite für ein kleines lokal arbeitendes Unternehmen. Gute Hoster werden hier ja immer wieder genannt z.B. Allinkl, Webgo, früher auch domainfactory, Uber. Schau mal im Hosterbereich des Forums. Da gibt es einige Threads zu auch mit Vor- und Nachteilen bzw. Besonderheiten.

[lucina]

Ist aber gelegentlich leider die Realität. Häufig geht es aber dabei nicht vorrangig nur um den Preis. Man scheut sich aus den verschiedensten, nicht immer nachvollziehbaren Gründen vor einem Umzug.
In letzter Zeit einige Male untergekommen ist mir Dienstleister A hat Hoster X in den höchsten Tönen gelobt und dem Kunden empfohlen. Der Kunde ist gerade dahin umgezogen bzw. hat den Vertrag gerade neu abgeschlossen. Dann rede ich mir mit meiner Empfehlung den Mund fusslig, entweder weil der Kunde den Aufwand nicht noch einmal haben will, Vertragslaufzeiten einzuhalten sind (keine Doppelzahlung) oder weil der Dienstleister sein Gesicht nicht verlieren will.
Anderes mehr oder weniger häufiges Szenario Dienstleister B hostet als Reseller selbst, möchte auf seine Kunden nicht verzichten und/oder arbeitet für so etwas mit äußerst knappen Ressourcen.

Ja, das gibt es. Ich hatte im letzten Jahr auch so einen Fall - der Kunde sass mit an meinem Schreibtisch und verstand erst dann, was parasitäre Geschäftsmodelle sind, nachdem wir mal dreieinhalb bezahlte Stunden von mir auf einen Hoster zwecks Anlage einer Subdomain (im automatisierten Verfahren!) gewartet haben und danach noch einmal zwei Stunden auf die Anlage einer weiteren Datenbank. Der brauchte das regelrecht, dass hinterher mehr als ein halber Tagessatz auf der Uhr war. Das fand er erst dann heftig, als ich - während diese Aktion lief - seine neue CMS-Installation dreimal innerhalb von 20 Minuten auf eines meiner Hostings bei einem anderen Anbieter deployed hatte, mal aus Neugier über Twitter einen Supportfall initiiert haben und innert derselben 20 Minuten befriedigende Antwort hatten.

Das war deutlich, und so relativieren sich dann auch Kosten für frisch bezahlte Jahresverträge.

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.

Den gibt es nicht - es gibt nur Hosting, dass den Aufgabenstellungen angemessen ist oder eben auch nicht. Dabei kann es dann durchaus auch unterschiedliche Ergebnisse geben.

Beispielsweise sind Hostings mit viel RAM (und da meine ich > 1GB) sehr fein zum Entwickeln. Darunter bis minimal 256 MB finde ich es geeignet für bildlastige Seiten, bei denen ich mir Klimmzüge beim Deployment und bei Updates ersparen möchte. Darunter, mit minimaler Ausstattung von 128 MB, finde ich Hostings, die sich für Seiten eignen, die einfach nur laufen und keine grossartigen Funktionen mitbringen. Bei Installationen mit vielen Einzeldateien kann es auch beachtenswert sein, wieviele Dateien das (virtualisierte) Dateisystem des Hosters verkraftet - 100 GB Plattenplatz mit einem Limit von 500'000 Dateien kann schneller als gedacht voll sein.

Weiterhin sollte man berücksichtigen, wie schnell ein Hosting an den nächsten Knoten angebunden ist, wie schnell man auf die Datenbanken zugreifen kann - wobei ich auch schon Angebote gesehen habe, die mit SSD langsamer waren als die Konkurrenz ohne. Aus Sicherheitsgründen fallen dann alle Hostings raus, die keinen Zugriffe über SSH bieten, und wenn ich dann noch die Firmen rausrechne, die aktiv das Leben mit Let's Encrypt schwer machen und ihre Produkte nur als Bundles mit 'Inklusivleistungen' von Domains bis hin zu SEO-Coachings anbieten, dann bleibt eine recht überschaubare Anzahl vorwiegend kleinerer und mittlerer Firmen übrig.

Merksatz sollte weiterhin sein: Wer Fernsehwerbung macht und dabei komplexe Sachverhalte hinter Wortwolken versteckt, der ist IMHO nicht seriös.

[tab]

Ok, hab doch schnell einen Test aufgesetzt:
test.larxperimente.de

Die Bilder werden neu berechnet. Das mit dem blauen Fernrohr hat original 355 kB, das im Cache 426 kB. Wahrscheinlich war das Original stärker komprimiert. Also, noml die Frage: wie bring ich dem Dingen bei, dass es das originale Bild mitbenutzen soll?

Wie groß ist das Original (in Pixel)? Es wird genau dann benutzt, wenn eines der berechneten Bilder exakt die gleiche Größe in Pixel hätte. Wäre das Original also z.B. 2560*1707 Pixel groß, dann würde es auch benutzt.

[wanst]

Wie groß ist das Original (in Pixel)? Es wird genau dann benutzt, wenn eines der berechneten Bilder exakt die gleiche Größe in Pixel hätte. Wäre das Original also z.B. 2560*1707 Pixel groß, dann würde es auch benutzt.

Das Original IST genau 2560*1707 px groß und das Original wird nicht benutzt. Ich hab die letzte Größe ja extra so angelegt, dass exakt das Maß dabei rauskommt.

Damit du das vergleichen kannst, habe ich Großansicht/Neues Fenster eingestellt.

[tab]

Komisch, bei mir sieht es auf einer privaten Seite z.B. für das Headerbild in voller Breite so aus:

<img src="files/themes/theme_sf59/Ausfluege-Header.jpg" srcset="files/themes/theme_sf59/Ausfluege-Header.jpg 2560w, assets/images/1/Ausfluege-Header-562864a1.jpg 1280w, assets/images/3/Ausfluege-Header-428888c3.jpg 640w" sizes="100vw" alt="">

Hier wird ganz klar das Original hergenommen.

[wanst]

stimmt, ganz klar. Hm, erstaunlich! Einmal so, einmal anders. Kann es an der Reihenfolge liegen?

Ich probier mal was...

[wanst]

Ich hab jetzt mal den Bildercache geleert und siehe da:

Kaum macht man's richtig, schon gehts!

Irgendwann hat er wohl mal ein 2560px-Bild erzeugt und in den Cache gelegt und daraufhin immer das verwendet, anstelle des Originals. Aber warum wurde es überhaupt erst angelegt?

[wanst]

Ach so, »ich probier mal was...« war, eine weitere Bildgröße anzulegen, mit der Ausgangsgröße 2560px und den Skalierungen in umgekehrter Reihenfolge, analog zu deinem Quellcode:
test.larxperimente.de/bildgroessen-gross-zu-klein.html

[wanst]

Mist, zu früh gefreut. Nach dem Neuladen oder nach dem Aufruf über das zweite Bildformat hatter doch wieder Cache-Bilder für die 2560px angelegt. Jetzt weiß ich auch nicht mehr weiter.

[Znrl]

Also, wenn ich das ganze so eingebe wie du, komme ich auf das selbe Ergebnis.

Ein paar test (unvollständig):

Lösche ich jetzt aber die Höhe raus.
Steht also in der Bildgröße nur noch 640 breit, Höhe ist leer.

Dann bekomme das original Bild im srcset.

Es scheint hier andersrum nicht zu funktionieren, nur eine Höhe liefert auch keine Originaldatei,
außer ich geben dort die 1707 ein.

Breite und Höhe als 2560 und 1707 funktioniert auch.

Also hat das mit den Einstellungen für Höhe und Breite zu tun.

edit:
Und wenn ich das jetzt richtig seh liegt das an der Image Klasse Image.php
(3.5.25) ab Zeile 418.
Da sowohl Breite als auch Höhe angegeben sind aber nicht mit der orginalen Größe übereinstimmen ist Contao der Meinung, dass hier die Größe geändert werden muss.

Sprich:
Eines der Felder MUSS leer sein oder der Breite/Höhe des Originals entsprechen.
(Und kein Zoom.)

[Spooky]

Könnte man als Bug melden.

[Znrl]

Habs mal eingetragen:

https://github.com/contao/core/issues/8700

[wanst]

Welchen Wert lege ich als Basis bspw. bei Breite in den Bildgrößen-Einstellungen fest und wie wirkt sich das aus?

Sagen wir, ich habe ein Bild, das wie in meinen Beispielen immer fast in voller Breite dargestellt werden soll. Und angenommen, ich will vier Größen, auf die der Browser zurückgreifen kann: 320, 640, 1280, 2560 Pixel.

Das kann ich ja einmal so definieren, dass ich als Basisbreite 640px angebe und als Pixeldichten 0.5x,1x,2x,4x
oder
320px + 1x,2x,4x,8x
oder in umgekehrter Richtung
2560px + 0.125x,0.25x,.0.5x,1x.

Und ich habe das Sizes-Attribut:
(min-width:1280px) 90vw, (min-width:1650px) 85vw, 100vw.

Was ist der Unterschied zwischen den Varianten bei den Pixeldichten? Wann wird die Basisbreite verwendet?

In Erklärungen habe ich gelesen, der Browser entscheidet, welche Größe verwendet wird – aber anhand welcher Kriterien? Fließt da CSS mit ein? Falls nicht, muss ich für jede vorkommende Bildgröße im Layout diese im CSS und hier in den Bildgrößen angeben?