Afmetingen van on the fly geresizede afbeeldingen bepalen

[egonolieux]

Ik ben aan het kijken om afbeeldingen on the fly te resizen bij een website, maar ik stel me de vraag wat te doen met de width/height attributes voor de <img> tags. Als de afbeeldingen on the fly geresized worden, betekent dit dat de exacte afmetingen van de aangepaste afbeeldingen niet gekend zijn tijdens het genereren van de HTML (enkel de URL). Voor afbeeldingen die exact naar bepaalde afmetingen aangepast moeten worden is dit uiteraard geen probleem, maar cropping en thumbnails of een simpele contain/cover daarentegen...

Je kan je natuurlijk de vraag stellen "Waarom per se de width/height attributes gebruiken? Ze zijn optioneel." Dat klopt, maar sinds recent is het belangrijk de correcte width/height aan afbeeldingen mee te geven i.v.m. cumulative layout shift. Nieuwere browserversies gebruiken ze om het aspect ratio op voorhand te bepalen.

Ik zie 2 voor de hand liggende "oplossingen" hier:

1. Bereken de width/height zelf op eigen server a.d.h.v. de resize methode zonder de afbeelding zelf te verwerken. (lijkt me omslachtig).
2. Resize de afbeeldingen bij upload en niet on the fly (ook niet echt wat ik wil).

Misschien zijn er nog andere opties waar ik niet van weet? Enige suggesties?

[RobIII]

egonolieux schreef op zaterdag 17 oktober 2020 @ 18:45:
Ik ben aan het kijken om afbeeldingen on the fly te resizen bij een website, maar ik stel me de vraag wat te doen met de width/height attributes voor de <img> tags. Als de afbeeldingen on the fly geresized worden, betekent dit dat de exacte afmetingen van de aangepaste afbeeldingen niet gekend zijn tijdens het genereren van de HTML (enkel de URL).

Op basis waarvan worden die afbeeldingen dan resized?

egonolieux schreef op zaterdag 17 oktober 2020 @ 18:45:
Je kan je natuurlijk de vraag stellen "Waarom per se de width/height attributes gebruiken? Ze zijn optioneel." Dat klopt, maar sinds recent is het belangrijk de correcte width/height aan afbeeldingen mee te geven i.v.m. cumulative layout shift.

Daar is niks nieuws aan; in de jaren '90 was dat zelfs al belangrijk om precies die reden: je pagina gaat springen tijdens 't laden.

egonolieux schreef op zaterdag 17 oktober 2020 @ 18:45:
1. Bereken de width/height zelf op eigen server a.d.h.v. de resize methode zonder de afbeelding zelf te verwerken. (lijkt me omslachtig).
2. Resize de afbeeldingen bij upload en niet on the fly (ook niet echt wat ik wil).

Het is vrij gebruikelijk te resizen bij upload; en dat kan 1 "target" formaat zijn of 25. Het resultaat sla je op en gebruik je bij elke pageview ((een vorm van) caching). Bij pageview kijk je of 't bestand bestaat en, zo niet (nieuw ontwerp ofzo) dan genereer je de juiste afbeelding met de nieuwe afmetingen alsnog en sla je die weer op voor later gebruik. Je wil echt niet bij elke pageview een afbeelding opnieuw gaan resizen, dat schaalt voor geen meter.

[DJMaze]

Je kan een afbeelding resizen in 1000+ maten omdat er 1000+ scherm maten zijn.
Dus welke maten hou je aan voor tiny, small, medium, large, xlarge, xxlarge, infinity and beyond 8k?

[RobIII]

DJMaze schreef op zaterdag 17 oktober 2020 @ 18:54:
Je kan een afbeelding resizen in 1000+ maten omdat er 1000+ scherm maten zijn.
Dus welke maten hou je aan voor tiny, small, medium, large, xlarge, xxlarge, infinity and beyond 8k?

Oh man. Wat een kul weer. Er zullen vast wel een aantal formaten (en permutaties daarop) zijn voor mobile, desktop etc. maar als je boven een tien, twintig formaten komt is 't veel. Dus klets niet zo, je kunt prima 'vooruit werken' en die afbeeldingen pre-resizen.

[egonolieux]

[...]

Op basis waarvan worden die afbeeldingen dan resized?

De afmetingen worden uiteraard meegegeven, maar stel nu dat de afbeelding 1000x500 is en ik wil de afbeelding beperken tot max 500x500 (behouden van aspect ratio). Ik kan die 500x500 dus niet gebruiken als width/height. Uiteraard valt dit te berekeken per resize methode (simpel in dit voorbeeld), maar het blijft omslachtig dit te doen.

[...]

Daar is niks nieuws aan; in de jaren '90 was dat zelfs al belangrijk om precies die reden: je pagina gaat springen tijdens 't laden.

Klopt, maar vroeger werd de width/height genegeerd indien deze met CSS overschreven werd, en zorgde dit voor een layout shift tot de afbeeldingen geladen werden. Dit is niet langer het geval (zie ook de CSS "aspect-ratio" property).

[...]

Uh, het is vrij gebruikelijk te resizen bij upload; en dat kan 1 "target" formaat zijn of 25. Het resultaat sla je op en gebruik je bij elke pageview (een (vorm van) caching). Bij pageview kijk je of 't bestand bestaat en, zo niet (nieuw ontwerp ofzo) dan genereer je de juiste afbeelding met de nieuwe afmetingen alsnog en sla je die weer op voor later gebruik. Je wil echt niet bij elke pageview een afbeelding opnieuw gaan resizen, dat schaalt voor geen meter.

Het is ook vrij gebruikelijk afbeeldingen on the fly te resizen (er zijn genoeg libraries/implementaties voor). Dit schaalt uiteraard niet als bij elke request de afbeeldingen opnieuw gegenereerd moeten worden. Daarom cache je ze (al dan niet met een CDN). Het is vooral veel makkelijker dan resizen bij upload, omdat je geen 20 verschillende formaten op voorhand moet bijhouden/configureren.

[ Voor 3% gewijzigd door egonolieux op 17-10-2020 19:05 ]

[RobIII]

egonolieux schreef op zaterdag 17 oktober 2020 @ 19:03:
Het is ook vrij gebruikelijk afbeeldingen on the fly te resizen (er zijn genoeg libraries/implementaties voor). Dit schaalt uiteraard niet als bij elke request de afbeeldingen opnieuw gegenereerd moeten worden. Daarom cache je ze (al dan niet met een CDN).

Nou, dan doe je dat?

Ik zie 't probleem niet zo? Optie 1 en optie 2 uit je topicstart werken prima?

[ Voor 5% gewijzigd door RobIII op 17-10-2020 19:05 ]

[egonolieux]

RobIII schreef op zaterdag 17 oktober 2020 @ 19:04:
[...]

Nou, dan doe je dat?

Ik zie 't probleem niet zo?

Zie edit, per ongeluk deel in de quote zelf geschreven

[NMe]

Ik zie geen enkele reden om niet op basis van een gelimiteerd aantal cutoff points je afbeeldingen te resizen en te cachen. Op het internet geldt sowieso: storage is cheap, speed is everything. Als je plaatjes te langzaam laden keldert je SEO-score en gooi je het kind met het badwater weg, aangezien het hele punt van verschillende afbeeldingen per resolutie nou juist is om snelheid te verbeteren...

Wat tools als de LiipImagineBundle voor Symfony bijvoorbeeld doen is alleen de eerste keer dat een plaatje wordt gerenderd even de cache vullen en vervolgens heb je dat plaatje gewoon altijd paraat. De rest is een simpele kwestie van responsive images gebruiken zodat je weet welke grootte je hebt per image.

DJMaze schreef op zaterdag 17 oktober 2020 @ 18:54:
Je kan een afbeelding resizen in 1000+ maten omdat er 1000+ scherm maten zijn.
Dus welke maten hou je aan voor tiny, small, medium, large, xlarge, xxlarge, infinity and beyond 8k?

offtopic:
Post je ook wel eens in een topic om een andere reden dan dat je het offtopic laat gaan om totaal irrelevante dingen waar niemand ooit last van heeft?

[ Voor 22% gewijzigd door NMe op 17-10-2020 19:11 ]

[RobIII]

egonolieux schreef op zaterdag 17 oktober 2020 @ 19:03:
De afmetingen worden uiteraard meegegeven, maar stel nu dat de afbeelding 1000x500 is en ik wil de afbeelding beperken tot max 500x500 (behouden van aspect ratio). Ik kan die 500x500 dus niet gebruiken als width/height. Uiteraard valt dit te berekeken per resize methode (simpel in dit voorbeeld), maar het blijft omslachtig dit te doen.

Even wat goochelen met 2 getalletjes is echt wel een stuk minder werk dan 't uiteindelijke daadwerkelijke resizen van de afbeelding. Ik zie 't probleem (nog steeds) niet zo?

egonolieux schreef op zaterdag 17 oktober 2020 @ 19:03:
Klopt, maar vroeger werd de width/height genegeerd indien deze met CSS overschreven werd, en zorgde dit voor een layout shift tot de afbeeldingen geladen werden. Dit is niet langer het geval (zie ook de CSS "aspect-ratio" property).

Het is altijd al ranzig geweest om in CSS andere afmetingen op te geven dan in je HTML; ook daar is niks aan veranderd Ongeacht wat er nu helemaal hip-en-happening is of ouwe-meuk: je afmetingen horen gewoon te kloppen

egonolieux schreef op zaterdag 17 oktober 2020 @ 19:03:
Het is ook vrij gebruikelijk afbeeldingen on the fly te resizen (er zijn genoeg libraries/implementaties voor). Dit schaalt uiteraard niet als bij elke request de afbeeldingen opnieuw gegenereerd moeten worden. Daarom cache je ze (al dan niet met een CDN). Het is vooral veel makkelijker dan resizen bij upload, omdat je geen 20 verschillende formaten op voorhand moet bijhouden/configureren.

Je configureert één keer iets, 5 minuten werk. Again: what's the problem? (En, again, heb je realistisch 20 formaten?)

[DJMaze]

RobIII schreef op zaterdag 17 oktober 2020 @ 18:55:
Oh man. Wat een kul weer. Er zullen vast wel een aantal formaten (en permutaties daarop) zijn voor mobile, desktop etc. maar als je boven een tien, twintig formaten komt is 't veel. Dus klets niet zo, je kunt prima 'vooruit werken' en die afbeeldingen pre-resizen.

En jij denkt dat iedereen zijn browser fullscreen heeft en elke mobiel de zelfde maat...

Laat TS lekker zelf beslissen wat te tonen bij retina 1, 1.5, 2.0, @media min-width, etc.
Mijn post is niks anders dan dat TS moet nadenken welke/hoeveel maten hij wil.

[RobIII]

DJMaze schreef op zaterdag 17 oktober 2020 @ 19:10:
En jij denkt dat iedereen zijn browser fullscreen heeft en elke mobiel de zelfde maat...

Dus jij genereert voor elke willekeurige breedte-hoogte ratio op elke pixel een afbeelding?
Je zegt zelf al: tiny, small, medium, large, xlarge, xxlarge en misschien nog 3 en that's it. Hou nou eens op steeds dingen gecompliceerder te doen lijken dan ze zijn. Jij begint over "1000+ (scherm)maten".

[ Voor 4% gewijzigd door RobIII op 17-10-2020 19:14 ]

[kwaakvaak_v2]

Voor een proof of concept uit de tijd dat je nog geen src-set had, heb ik een keer het principe van een stukje uit de imgix javascript gepakt om vervolgens per div waar het van toepassing was on the fly serverside een afbeelding ophalen / generen in de juiste aspect ratio.

En niet elke afbeelding voor elk formaat laten maken, maar met vastgestelde stappen, dus bijv elke 100pixels verschil in de breedte. Werkte best redelijk, maar was niet echt heel efficiënt omdat je bij elke browser resize alle afbeeldingen nagelopen werden en vervangen.

Wat beter werkte was het tweede prototype, en dan was dezelfde manier laten uitrekenen maar ipv de afbeeldingen op te halen werden de berekende waarden in een console.log geschreven en die gebruikt om max 10 verschillende afmetingen te bepalen en een wissel op die waardes via js doen.

Nu zou ik hetzelfde doen, maar dan die uitkomst gebruiken om met src-set en breakpoint rules in een keer de waardes bepalen en de browser het lekker zelf uitlaten zoeken

[Ramon]

egonolieux schreef op zaterdag 17 oktober 2020 @ 18:45:
Ik ben aan het kijken om afbeeldingen on the fly te resizen bij een website, maar ik stel me de vraag wat te doen met de width/height attributes voor de <img> tags. Als de afbeeldingen on the fly geresized worden, betekent dit dat de exacte afmetingen van de aangepaste afbeeldingen niet gekend zijn tijdens het genereren van de HTML (enkel de URL). Voor afbeeldingen die exact naar bepaalde afmetingen aangepast moeten worden is dit uiteraard geen probleem, maar cropping en thumbnails of een simpele contain/cover daarentegen...

Je kan je natuurlijk de vraag stellen "Waarom per se de width/height attributes gebruiken? Ze zijn optioneel." Dat klopt, maar sinds recent is het belangrijk de correcte width/height aan afbeeldingen mee te geven i.v.m. cumulative layout shift. Nieuwere browserversies gebruiken ze om het aspect ratio op voorhand te bepalen.

Ik zie 2 voor de hand liggende "oplossingen" hier:

1. Bereken de width/height zelf op eigen server a.d.h.v. de resize methode zonder de afbeelding zelf te verwerken. (lijkt me omslachtig).
2. Resize de afbeeldingen bij upload en niet on the fly (ook niet echt wat ik wil).

Misschien zijn er nog andere opties waar ik niet van weet? Enige suggesties?

Ik snap het probleem eigenlijk niet zo. De width/height van de img-tag hoeven niet per se overeen te komen met die van de afbeelding, het is puur de manier van weergave van de img-tag.

Als ik even wagtail als voorbeeld neem (een Django cms): daar kan ik in mijn HTML templates door middel van een template tag zeggen dat ik een bepaalde afbeelding op een bepaalde plek wil includen en wagtail zorgt dan voor het reizen, cachen van de afbeelding en het uitschrijven van de img-tag. Hoef ik dan dus verder niets voor te doen.

[egonolieux]

RobIII schreef op zaterdag 17 oktober 2020 @ 19:10:
[...]

Even wat goochelen met 2 getalletjes is echt wel een stuk minder werk dan 't uiteindelijke daadwerkelijke resizen van de afbeelding. Ik zie 't probleem (nog steeds) niet zo?

Wel, het is natuurlijk allemaal wel mogelijk om te implementeren, maar zo elegant is het nu ook weer niet. Ideaal gezien krijg je de afmetingen mee na het resizen en moet je ze zelf niet zitten "emuleren". Op dat vlak is resizen bij upload dus veel beter.

[...]

Het is altijd al ranzig geweest om in CSS andere afmetingen op te geven dan in je HTML; ook daar is niks aan veranderd Ongeacht wat er nu helemaal hip-en-happening is of ouwe-meuk: je afmetingen horen gewoon te kloppen

In theorie horen ze inderdaad te kloppen, en hoe ranzig of niet, vroeger was het nu eenmaal zo dat je content shift had met CSS omdat de width/height gewoonweg genegeerd werd. Vandaar dat in deze gevallen width/height zonder problemen weggelaten kon worden (zonder praktisch verschil).

Vroeger was het dus vaak in de praktijk geen probleem dat je niet (rechtstreeks) de afmetingen wist bij on the fly resizen. Nu dus wel (Google telt het sinds kort ook mee voor page ranks). Maar goed, dit gaat richting off-topic.

[...]

Je configureert één keer iets, 5 minuten werk. Again: what's the problem? (En, again, heb je realistisch 20 formaten?)

Het aantal formaten maakt me eigenlijk weinig uit; het concept dat je afbeeldingen on the fly kan genereren simpel met een URL en amper configuratie is zeer aantrekkelijk. Hoewel het ook zijn nadelen heeft uiteraard.

Ik vraag me eigenlijk af hoe anderen het doen me on the fly resizen. Volgens mij laten de meesten gewoon width/height weg, of zoals eerder vermeld, "emuleren" ze de afmetingen.

In dat geval lijkt me resizen bij upload de betere oplossing.

NMe schreef op zaterdag 17 oktober 2020 @ 19:10:
Ik zie geen enkele reden om niet op basis van een gelimiteerd aantal cutoff points je afbeeldingen te resizen en te cachen. Op het internet geldt sowieso: storage is cheap, speed is everything. Als je plaatjes te langzaam laden keldert je SEO-score en gooi je het kind met het badwater weg, aangezien het hele punt van verschillende afbeeldingen per resolutie nou juist is om snelheid te verbeteren...

Wat tools als de LiipImagineBundle voor Symfony bijvoorbeeld doen is alleen de eerste keer dat een plaatje wordt gerenderd even de cache vullen en vervolgens heb je dat plaatje gewoon altijd paraat. De rest is een simpele kwestie van responsive images gebruiken zodat je weet welke grootte je hebt per image.

[...]

offtopic:
Post je ook wel eens in een topic om een andere reden dan dat je het offtopic laat gaan om totaal irrelevante dingen waar niemand ooit last van heeft?

Ik heb nooit gezegd de afbeeldingen niet te cachen na de eerste keer werwerken

LiipImagineBundle lijkt me een soort van hybride oplossing. Je hebt zowel een voorgedefinieerde configuratie als de afbeeldingen die on the fly geresized worden. Ik stel me dan de vraag of deze bundle veel nut heeft; als je dan toch alles configureert kan het even goed bij het uploaden zelf, en laden je paginas initieel sneller imo.

[egonolieux]

Ramon schreef op zaterdag 17 oktober 2020 @ 19:50:
[...]

Ik snap het probleem eigenlijk niet zo. De width/height van de img-tag hoeven niet per se overeen te komen met die van de afbeelding, het is puur de manier van weergave van de img-tag.

Als ik even wagtail als voorbeeld neem (een Django cms): daar kan ik in mijn HTML templates door middel van een template tag zeggen dat ik een bepaalde afbeelding op een bepaalde plek wil includen en wagtail zorgt dan voor het reizen, cachen van de afbeelding en het uitschrijven van de img-tag. Hoef ik dan dus verder niets voor te doen.

Dit is dan ook geen on the fly resizing neem ik aan? Het probleem is dat als je afbeelding on the fly zit te resizen, is dat de afbeelding pas gekend is bij de client zelf, dus het is onmogelijk de nieuwe afmetingen te weten (tenzij je ze zelf zit uit te rekenen op voorhand). Er zijn tal van manieren om afbeeldingen te resizen, al dan niet met behoudt van aspect ratio, dus dit op voorhand te zitten doen lijkt me dubbel werk.

[NMe]

egonolieux schreef op zaterdag 17 oktober 2020 @ 20:12:
[...]

LiipImagineBundle lijkt me een soort van hybride oplossing. Je hebt zowel een voorgedefinieerde configuratie als de afbeeldingen die on the fly geresized worden. Ik stel me dan de vraag of deze bundle veel nut heeft; als je dan toch alles configureert kan het even goed bij het uploaden zelf, en laden je paginas initieel sneller imo.

Zo simpel is het niet. Wat als je site verandert en je plaatjes ineens in een andere resolutie moeten? Als je (iets met het designprincipe van) LiipImagine gebruikt hoef je alleen wat config toe te voegen en de responsive image wat aan te passen in je HTML en het werkt out of the box. Als je het in plaats daarvan bij het uploaden doet moet je echter bij zo'n resolutie-toevoeging alle plaatjes die je al hebt af om ze even uit te genereren in de nieuwe resolutie. De Liip-aanpak is wat dat betreft handiger, want tegen de tijd dat je het doet is je site allang aanwezig in Google's index en is het de Google-bot die alle image-generaties voor je triggert.

[Ramon]

egonolieux schreef op zaterdag 17 oktober 2020 @ 20:20:
[...]


Dit is dan ook geen on the fly resizing neem ik aan? Het probleem is dat als je afbeelding on the fly zit te resizen, is dat de afbeelding pas gekend is bij de client zelf, dus het is onmogelijk de nieuwe afmetingen te weten (tenzij je ze zelf zit uit te rekenen op voorhand). Er zijn tal van manieren om afbeeldingen te resizen, al dan niet met behoudt van aspect ratio, dus dit op voorhand te zitten doen lijkt me dubbel werk.

ik heb toch het idee dat je ergens iets niet begrijpt...

Als je een website maakt heb je toch een ontwerp waarin formaten van afbeeldingen vooraf gedefinieerd zijn? Dus het is een kwestie van in jouw templates de maten uit het ontwerp invoeren en gaan...

[egonolieux]

NMe schreef op zaterdag 17 oktober 2020 @ 20:26:
[...]

Zo simpel is het niet. Wat als je site verandert en je plaatjes ineens in een andere resolutie moeten? Als je (iets met het designprincipe van) LiipImagine gebruikt hoef je alleen wat config toe te voegen en de responsive image wat aan te passen in je HTML en het werkt out of the box. Als je het in plaats daarvan bij het uploaden doet moet je echter bij zo'n resolutie-toevoeging alle plaatjes die je al hebt af om ze even uit te genereren in de nieuwe resolutie. De Liip-aanpak is wat dat betreft handiger, want tegen de tijd dat je het doet is je site allang aanwezig in Google's index en is het de Google-bot die alle image-generaties voor je triggert.

Goed punt. En nu ik er over denk, waarschijnlijk het grootste voordeel is van on the fly resizen.

Ramon schreef op zaterdag 17 oktober 2020 @ 20:30:
[...]
ik heb toch het idee dat je ergens iets niet begrijpt...

Als je een website maakt heb je toch een ontwerp waarin formaten van afbeeldingen vooraf gedefinieerd zijn? Dus het is een kwestie van in jouw templates de maten uit het ontwerp invoeren en gaan...

Ik heb niet veel ervaring in de praktijk met dit soort zaken, dus misschien wel.

Misschien zit ik te veel te focusen op de specifieke implementatie van AWS en trek ik de lijn te ver door? https://aws.amazon.com/so...serverless-image-handler/

Als ik naar de implementatie kijk, definieer je niets op voorhand. Het enige wat je doet is een URL opstellen met de resize parameters.

De resize parameters zelf zijn inderdaad op voorgand gedefinieerd, maar dat wil daarom niet zeggen dat die parameters overeenkomen met de resulterende afbeelding.

Als ik bijvoorbeeld een "inside" resize doe van 500x250 en de oorspronkelijke afbeelding is 750x500 (https://github.com/lovell...master/docs/api-resize.md; AWS gebruikt sharp), dan weet ik niet wat de uiteindelijke afmetingen gaan zijn van de nieuwe afbeelding.

Tenzij... ik het "inside" algoritme zelf repliceer om enkel de width/height te berekenen.

[DJMaze]

egonolieux schreef op zaterdag 17 oktober 2020 @ 20:57:
Als ik bijvoorbeeld een "inside" resize doe van 500x250 en de oorspronkelijke afbeelding is 750x500 (https://github.com/lovell...master/docs/api-resize.md; AWS gebruikt sharp), dan weet ik niet wat de uiteindelijke afmetingen gaan zijn van de nieuwe afbeelding.

750/500 is 1.5
500/250 is 2.0

De afbeelding wordt (750/2)x(500/2) = 375x250

Je kan ook uitsnijden: (750/1.5)x(500/1.5) = 500x333.333
En dan (333.333-250)/2 = 41.6666 afsnijden boven en onder.

En dan jpeg/png omzetten naar webp voor de ondersteunde browsers.
Dan heb je elk afbeelding formaat twee keer (jpeg/png en webp).

[Wim-Bart]

Ooit, in een ver verleden, toen we alles nog zelf deden, had ik in Php altijd een image functie die afhankelijk van browser window een image tag retourneerde met hoogte en breedte. Deze functie las de eigenschappen van de image file uit en berekende de hight aan de hand van de opgegeven breedte. Hierdoor was de aspect ratio altijd goed en "sprong" de pagina niet.

Later toen mobiel meer gewoon werd was de schaling ook anders waardoor ik voor iedere image twee versies had. Versie 1 de normale en versie twee een kwart size. Dit omdat bandbreedte en verbruik van mobile data duur was.

[Ramon]

egonolieux schreef op zaterdag 17 oktober 2020 @ 20:57:
[...]


Goed punt. En nu ik er over denk, waarschijnlijk het grootste voordeel is van on the fly resizen.


[...]


Ik heb niet veel ervaring in de praktijk met dit soort zaken, dus misschien wel.

Misschien zit ik te veel te focusen op de specifieke implementatie van AWS en trek ik de lijn te ver door? https://aws.amazon.com/so...serverless-image-handler/

Als ik naar de implementatie kijk, definieer je niets op voorhand. Het enige wat je doet is een URL opstellen met de resize parameters.

De resize parameters zelf zijn inderdaad op voorgand gedefinieerd, maar dat wil daarom niet zeggen dat die parameters overeenkomen met de resulterende afbeelding.

Als ik bijvoorbeeld een "inside" resize doe van 500x250 en de oorspronkelijke afbeelding is 750x500 (https://github.com/lovell...master/docs/api-resize.md; AWS gebruikt sharp), dan weet ik niet wat de uiteindelijke afmetingen gaan zijn van de nieuwe afbeelding.

Tenzij... ik het "inside" algoritme zelf repliceer om enkel de width/height te berekenen.

Misschien moet je dan een ander soort resize doen?

Misschien kan je dit eens aandachtig lezen? https://docs.wagtail.io/en/v2.10.2/topics/images.html

Hier worden verschillende algoritmes en opties beschreven om afbeeldingen te resizen. Wij gebruiken meestal de fill-rule, omdat we daarmee gewoon de in het ontwerp beschreven afbeeldingen kunnen instellen.

[egonolieux]

Ramon schreef op zondag 18 oktober 2020 @ 16:56:
[...]
Misschien moet je dan een ander soort resize doen?

Misschien kan je dit eens aandachtig lezen? https://docs.wagtail.io/en/v2.10.2/topics/images.html

Hier worden verschillende algoritmes en opties beschreven om afbeeldingen te resizen. Wij gebruiken meestal de fill-rule, omdat we daarmee gewoon de in het ontwerp beschreven afbeeldingen kunnen instellen.

Om de documentatie te quoten:

The image tag inserts an XHTML-compatible img element into the page, setting its src, width, height and alt

De width/height wordt dus achter de schermen reeds berekend, dus in deze context maakt het toch niet uit welk soort resize je doet? Je krijgt de afmetingen hoe dan ook.

Hoe die afmetingen berekend worden achter de schermen is een andere kwestie, voor hetzelfde geld is het on the fly en berekeken ze ook hier de afmetingen op voorhand voor jou.

Maar goed, er is eigenlijk geen echt probleem dus. Mijn 2 opties zijn dus die uit mijn oorspronkelijke post. Ik wou gewoon even weten hoe anderen met dit soort zaken omgaan, en blijkbaar zat ik er zelf niet ver van.

[ACM]

Op Tweakers gebruiken we Thumbor om on-the-fly afbeeldingen te maken.

We hebben daarbij een vaste reeks formaten geconfigureerd, waarbij we via eenvoudige twig-logica dan img-tags omheen kunnen maken, die dan domweg de maten hanteert die in een configuratie staan. Daarnaast wordt een subset van die formaten beschikbaar gesteld aan onze wysiwyg-editor.

Er zijn een paar configuraties waarbij we alleen een breedte of hoogte gebruiken. En daar treedt dan inderdaad in principe dit probleem op.

Maar de belangrijkste plekken waar we dergelijke afbeeldingen gebruiken zijn weer via onze wysiwyg-editor. En die vraagt bij de tijdens het invoeren dan de afbeelding op en vult de width/height alvast voor de redacteur in. Dus in de praktijk hoeven we er geen relatief ingewikkelde oplossingen voor te maken

Mochten we ooit toch zo'n situatie krijgen, dan zou ik waarschijnlijk wel een poging doen om de volledige img-tag te laten genereren door de twig-helper. En dan inderdaad uitrekenen wat de width/heigt zou moeten worden.

[egonolieux]

ACM schreef op maandag 19 oktober 2020 @ 08:53:
Op Tweakers gebruiken we Thumbor om on-the-fly afbeeldingen te maken.

We hebben daarbij een vaste reeks formaten geconfigureerd, waarbij we via eenvoudige twig-logica dan img-tags omheen kunnen maken, die dan domweg de maten hanteert die in een configuratie staan. Daarnaast wordt een subset van die formaten beschikbaar gesteld aan onze wysiwyg-editor.

Er zijn een paar configuraties waarbij we alleen een breedte of hoogte gebruiken. En daar treedt dan inderdaad in principe dit probleem op.

Maar de belangrijkste plekken waar we dergelijke afbeeldingen gebruiken zijn weer via onze wysiwyg-editor. En die vraagt bij de tijdens het invoeren dan de afbeelding op en vult de width/height alvast voor de redacteur in. Dus in de praktijk hoeven we er geen relatief ingewikkelde oplossingen voor te maken

Mochten we ooit toch zo'n situatie krijgen, dan zou ik waarschijnlijk wel een poging doen om de volledige img-tag te laten genereren door de twig-helper. En dan inderdaad uitrekenen wat de width/heigt zou moeten worden.

In mijn geval wordt bijna uitsluitend enkel de hoogte/breedte gebruikt . Ondertussen heb ik een service gemaakte met een "resolveImage" functie die een object teruggeeft met de URL, uiteindelijke breedte en hoogte. De breedte en hoogte worden dus provisioneel berekend, of in het geval van een cover/contain worden ze rechtstreeks gebruikt.