[forum] scaleImage() iets te snel met 'rode resize border'

[Wiethoofd]

De scaleImage() functie voor het schalen van 'te grote afbeeldingen' is iets te aggresief met het neerzetten van de randen van afbeeldingen die nog onder de 600px breed/hoog zijn. Tevens wordt de rode gestippelde rand niet getoond in het 'Bekijk bericht' voorbeeld.

Voorbeeld van het te snel zijn met het neerzetten van de rode randen: Welke film(s) heb je laatst gezien en wat vond je? [Deel 27]

Dit zijn filmposters die 250px hoog zijn en naar een 100px breedte geschaald worden (normaliter 150-160px breed), voorheen had dit geen effect op de rand/class="resized" (berichten van de vorige iteratie hebben de class niet als de afbeelding 'te groot' zou zijn).

[crisp]

De stippelrand wordt altijd neergezet wanneer de daadwerkelijke image groter is dan getoond; dus dat is correcte behaviour. Het kan best zijn dat dat voorheen stuk is geweest en juist nu gefixed

Waarom het in de preview niet goed gaat ga ik naar kijken

[Wiethoofd]

Zou de check iets minder strikt kunnen zijn voor afbeeldingen onder de 300px? Dan is het al zo'n klein plaatje en dan er een rand omheen... (helemaal met transparante afbeeldingen...)

[Wiethoofd]

Nog een foutje:

Afbeelding van 25x50 geforceerd op 18,50 wordt 'resized' naar 16,44 en voorzien van een dashed rand.
[img=18,50,,,]http://wdhd.nl/bg/s.png[/img]
<< check image doet z'n ding
<< 18,50 geforceerd.

En schijnbaar gaat hij hier niet fout, in http://gathering.tweakers.net/forum/view_message/40591158 echter wel...

[ Voor 15% gewijzigd door Wiethoofd op 21-07-2013 17:54 ]

[crisp]

Nou, ik heb al gezien dat er waarschijnlijk iets mis gaat met de loader als het plaatje nog niet gecached is.

An sich is het correct dat de breedte 2 pixels minder wordt als de rand eromheen geplaats wordt; dat is om te voorkomen dat bijvoorbeeld tables anders weer 2 pixels uitgerekt worden e.d.

Ik zit inderdaad te denken om kleine plaatjes, of plaatjes waarbij het verschil tussen wel/niet resized minimaal is voortaan maar met rust te laten.

[crisp]

Bij dat laatste zat ik trouwens te denken aan < 100px breed -> negeren. Bij bredere plaatjes waarbij de afwijking echte breedte versus getoonde breedte > 50% is wel stippellijn.

In het geval van de filmposter plaatjes is de afwijking echter meestal wel meer dan 50%. Een middel om 'm in volle grootte te tonen (en dat duidelijk te maken mbv een gestippelt randje) is dan imo ook wel nuttig...

[Wiethoofd]

100px is volgens mij wel redelijk aan de krappe kant, en ook rare aspectratios zouden genegeerd moeten worden als ze hard ingegeven worden door de user.

Tevens hebben afbeeldingen van 500px in de breedte met een grote hoogte nu dat ze naar (maximaal?) 2000px in de hoogte geschaald worden (door check images, niet in de bekijk voorbeeld preview), maar krijgt vervolgens geen randje dat deze resized is, als je naar groot wil klikken moet je dat in de img tag ingeven. Mocht er dus een link=1 staan dan zou een 'resized' border weer weggelaten moeten worden lijkt me.

Deze post in Het grote grappige plaatjes topic - Q3-13 << heeft 3 van die lange afbeeldingen, die qua breedte prima in de post zouden passen.

---

Bij die film posters is een tijdje het replacen van de dynamische hoogte/breedte in de imdb-url fout gegaan en is de default breedte van 300px afbeelding opgeslagen (ipv hoogte van 250 (die naar 200 zou kunnen)). Normaliter wordt hij gecapped op een breedte van 110px in de ubb-output (met een resulterende hoogte van ongeveer 170px) Voorbeeld: 160px x 250px (geschaald naar 110px x 172px) (45%)

[crisp]

De maximale hoogtelimiet is eigenlijk tegen grapjassen die dan een transparante pixel gaan posten met height=100000. En ja, feitelijk zou die ook een resized randje moeten krijgen.