[html/css] Plaatjes schalen lelijk terug

[_Thanatos_]

Dit onderwerp is al meerdere malen aangesneden, maar toch lijken alle gegeven oplossingen niet te helpen. Heel raar. Je zou immers zeggen dat het schalen van plaatjes elementaire functionaliteit is, zeker als die mogelijkheid geboden wordt.

Okay, ik heb een aantal hoge-resolutie plaatjes, die bedoeld zijn om scherp getoond te worden op high-dpi schermen (denk aan mobiel). Het probleem is dat ze er kotslelijk uitzien op low-dpi schermen (denk aan desktop), omdat ze sterk teruggeschaald moeten worden.

De plaatjes zijn ge-exporteerd als 300dpi PNG. Het maakt niets uit of ze 8-bits of 24-bits zijn, of dat ze wel of geen transparantie hebben. Ik heb gevogeld met de css property "image-rendering", maar die doet zo goed als niets. Ik heb ook geprobeerd de afbeeldingen als background-image te includen en dan te schalen met background-size; het resultaat is dat kotslelijk nog best netjes is in verhouding: alle vormen van antialiasing vallen weg, waar de <img> tenminste nog iets daarvan lijkt te doen (maar langenaniet genoeg).

Verder maakt het niets uit met welke property er geschaald wordt. Met de width- en height-attributen van de img-tag, met css en zonder attributen, met css en attributen op oorspronkelijke afmetingen. Enige dat ik nog niet heb geprobeerd is met een scale-transform, maar die wil ik eigenlijk koste-wat-het-kost vermijden - veel te fiddly.

Het gaat dus, voor alle duidelijkheid, om terugschalen - niet opschalen.

Iemand hier ervaring mee? Oplossing misschien zelfs?

(Ik heb er screenshots van, maar het posten van screenshots is een gedoe op GoT. Dus als je die wilt zien, zal ik die alsnog posten)

@got-dev: doe es een functie maken om een plaatje te includen in een post?

[RobIII]

_Thanatos_ schreef op woensdag 23 januari 2013 @ 16:06:
@got-dev: doe es een functie maken om een plaatje te includen in een post?

_Thanatos_ , doe eens gewoon een abo nemen wat karma spenderen

En je kunt ook op rammen

Daarbij: aan plaatjes alleen hebben we niet genoeg. Ook relevante(!) snippets code zijn hier wel heel handig. Anders maak je gewoon even een jsfiddle? Dan kun je gewoon linken naar de eigenlijke (echte) plaatjes zoals die ergens nu toch al gehost staan.

[ Voor 45% gewijzigd door RobIII op 23-01-2013 16:22 ]

[_Thanatos_]

Wat is dat voor een ding?? Ik zie alleen een kale textarea om een reply te typen.. Misschien heeft jouw admin/modder status wat meer mogelijkheden dan ik als simpele sterveling

Maargoed ik denk niet dat het includen van code veel toevoegt. Ik denk dat we allemaal wel weten hoe je een width en een height op een plaatje kan zetten, toch?
De plaatjes staan trouwens niet gehost. Ik werk lokaal.

Ik heb trouwens het acute probleem omzeilt door de plaatjes als SVG aan de browser te geven... Maarja, vroeg of laat kom ik iets tegen waarbij dat lastig of onmogelijk is.

[ Voor 17% gewijzigd door _Thanatos_ op 23-01-2013 17:00 ]

[wimvanp1]

Wat je ziet onderaan is de Quickreply. De textarea getoond door RobIII kan je verkrijgen door op de knop 'reageer' te drukken.

[Bosmonster]

Heb je de afbeeldingen wel met even afmetingen exact 50% breedte/hoogte gegeven? In dat geval zouden ze redelijk goed moeten schalen.

Anders kun je voor specifieke browsers ook nog spelen met interpolation/image-rendering css directives.

[ Voor 28% gewijzigd door Bosmonster op 23-01-2013 17:23 ]

[RobIII]

wimvanp1 schreef op woensdag 23 januari 2013 @ 17:20:
Wat je ziet onderaan is de Quickreply. De textarea getoond door RobIII kan je verkrijgen door op de knop 'reageer' te drukken.

Of door in de quickreply alvast wat te typen en dan op "Verwerk & bekijk bericht" oid. te klikken (geen idee wat "normale stervelingen" daar zien )

Bosmonster schreef op woensdag 23 januari 2013 @ 17:22:
Heb je de afbeeldingen wel met even afmetingen exact 50% breedte/hoogte gegeven? In dat geval zouden ze redelijk goed moeten schalen.

Inderdaad, proberen een beetje gunstige schalen te hanteren; 10%, 25%, 50% etc. Als je op 41,22389% gaat schalen zal 't eerder ruk zijn.

[ Voor 33% gewijzigd door RobIII op 23-01-2013 17:52 ]

[Nedra]

Misschien toch geen direct antwoord op je vraag, maar is

code:

only screen and (-webkit-min-device-pixel-ratio: 2)

geen optie?

[merauder]

Ik heb altijd geleerd dat CSS + HTML geen goede combinatie zijn wat betreft het schalen van plaatjes. Sommige CSS3 capabele browsers doen dit goed, terwijl sommige oudere browsers hier een ongekende puinhoop van maken.

Een andere optie is om meerdere varianten van het plaatje te publiceren, of dit probleem te ondervangen met Javascript.

[_Thanatos_]

@Bosmonster
50% zal nog wel redelijk werken, maar uitgaande van een bereik van 96dpi op de desktop tot bijna 400dpi op mobieltjes, heb ik gekozen voor 4x schalen ipv jouw 2x. In dit geval is dat niet zo erg, omdat het om een enkelkleurige lijntekening gaat. 4x zo groot of 2x zo groot maakte in filesize bijna geen verschil. Daarbij, 50% geeft hetzelfde probleem hoe dan ook, alleen is het minder duidelijk. Dezelfde afbeelding op 100% gebruiken is nog altijd mooier.

@RobIII
Schalen naar exact 25% geeft hetzelfde (crappy) effect als schalen naar 41,42837653%... Helaas. Misschien dat 25% minder crappy is, maar crappy is het nog altijd wel.

@Nedra
Dat is "een" oplossing, maar die webkit prefix vertelt me dat firefox (mobile en desktop) en IE (wederom mobile en desktop) er niets mee doen. Relevanter is dat het niet (altijd) om pixeldichtheid gaat, maar ook om schermgrootte. Ik wil nml ook huge-ass schermen ondersteunen (1080p op 3 meter bijvoorbeeld) en daar is (door de afstand) de pixeldichtheid voor het oog heel hoog, maar fysiek weer heel laag. Okay met afstand boeit het natuurlijk minder, maar dat kun je van high-dpi dan ook weer zeggen. Bottomline: het moet mooi schalen, ook op low-dpi

@merauder
Sommige CSS3 browsers? In dit geval alléén Chrome. Zoals gezegd schalen Firefox, Opera, IE10 en Safari allemaal crappy. En dat zijn toch hele (variërend) capabele browsers, iyam.

[ Voor 19% gewijzigd door _Thanatos_ op 25-01-2013 10:18 ]

[HuHu]

Een browser is natuurlijk geen Photoshop. Ik zou de plaatjes server-side schalen, met bijvoorbeeld ImageMagick, en die vervolgens in de browser tonen.

[_Thanatos_]

HuHu schreef op vrijdag 25 januari 2013 @ 10:18:
Een browser is natuurlijk geen Photoshop. Ik zou de plaatjes server-side schalen, met bijvoorbeeld ImageMagick, en die vervolgens in de browser tonen.

Dat lijkt heel mooi, maar ten eerste weet de server niet wat voor scherm de bezoeker heeft, en ten tweede kan het het gewoon niet in mijn geval - alles is nog statisch. En zelfs zodra het CMS eroverheen komt betwijfel ik het.

[ Voor 9% gewijzigd door _Thanatos_ op 25-01-2013 10:20 ]

[418O2]

Ben je niet op zoek naar @2x?

[HuHu]

Je kan met JavaScript de eigenschappen van de browser uitlezen en op basis daarvan een verzoek doen naar de server om het juiste plaatje te genereren.

Als je server dat niet kan (waarom niet?), dan is dit inderdaad geen optie.

[_Thanatos_]

Het moet zonder javascript werken. Ik ga echt niet de weergave van afbeeldingen afhankelijk laten zijn van scripting. Javascript wordt op een later moment geladen, of in voldoende gevallen, helemaal niet.

Waarom de server dit niet kan, is nu even niet interessant voor de discussie. Het kan niet, deal with it (ik dus )

@2x lijkt leuk, maar ik zie dat niet werken voor <img>... Bovendien is 2x96 nog geen 400 voor de ultrahigh-dpi Galaxy telefoons en weet ik wat nog meer.

Anyway.
Wat ik vooral raar vind, is waarom de image-rendering css-property hier geen oplossing voor is. Dat is toch exact waar die property voor bedoeld is

[ Voor 24% gewijzigd door _Thanatos_ op 25-01-2013 10:27 ]

[maarud]

RobIII schreef op woensdag 23 januari 2013 @ 16:15:
[...]

_Thanatos_ , doe eens gewoon een abo nemen wat karma spenderen
[afbeelding]
En je kunt ook op [afbeelding] rammen

nooit geweten dat GoT die functie had. Ik altijd maar handmatig uploaden in mijn fotoalbum en de url kopiëren.. pff
Maar ja ik gebruik ook altijd de quick reply dus het zou me ook nooit opgevallen zijn

[HuHu]

Je weergave hoeft niet afhankelijk te zijn van scripting, want je kunt altijd nog je (crappy) plaatje tonen indien JavaScript niet werkt.

Het zou trouwens wel handig zijn als je van te voren al je eisen vertelt (geen javascript, niet server-side, etc), want dan hoeven we geen oplossingen aan te dragen die je vervolgens weer afschiet.

[Digital-DNA]

Je kan proberen via canvas een afbeelding weer te geven en kijken of het dan wel goed mooi schaalt. Je kunt de gewone <IMG> er onder zetten als fallback.

Sterker nog, als het een lijntekening is kun je die ook laten tekenen, is nog beter. Illustrator heeft bijv. een plugin waarmee je canvas tekeninstructies kunt exporten.

[ Voor 36% gewijzigd door Digital-DNA op 25-01-2013 10:33 ]

[storeman]

^^ met HuHu

Dan verwacht ik dat er weinig opties over blijven voor je. Met html/css wordt het niet zo eenvoudig iets, als het al mogelijk is, je wilt geen browser-specifieke css gebruik, geen canvas. De enige optie is dan om per device een aparte pagina te maken. Wellicht kun je met meta-tags (dus js-loos) een redirect doen naar de juiste pagina, afhankelijk van het device.

Je kunt met jouw eisen al helemaal niet verwachten dat dit altijd goed werkt. Daarvoor leg je jezelf te veel beperkingen op.

[HuHu]

Ow, en image-rendering werkt niet omdat de functionaliteit nauwelijks is geïmplementeerd in browsers: https://developer.mozilla.org/en-US/docs/CSS/image-rendering

[_Thanatos_]

Ik had toch verwacht dat er heden ten dage wel iets van een oplossing voor bestond, die geen eisen stelt aan scripting of servers... Mobieltjes bestaan immers al best lang, en genoeg browsers die op alle platformen beschikbaar zijn (zelfs IE tegenwoordig!). Maar iets basaals implementeren als goed-schalende images, ho maar. De property image-rendering is nota bene door Mozilla gespecced, maar zelfs in hun eigen browser werkt het niet. Ja zou kan ik ook specs maken

Okay, genoeg gerant
Ik zie een aantal oplossingen tot dusver:

1. Een vector image. Niet geschikt voor foto's, uitermate geschikt voor logo's e.d.. Helaas worden ze niet heel mooi optimized uitgespuugd, werkt het pas vanaf IE9, en IIS heeft moeite met uitspugen van SVGZ.
2. Serverside een kleinere afbeelding genereren. En vervolgens met css het juist formaat "gokken".
3. Bovenstaande maar dan met een berg statische (dezelfde) images van verschillende groottes
4. Bovenstaande maar dan niet met css maar met javascript
5. Met javascript en canvas iets tekenen. Jammer dat Illustrator daarvoor bijzonder handig is, en niet iedereen dat heeft.
6. Met javascript de png op een canvas geschaald tekenen (niet getest, maar ik verwacht andere resultaten dan schalen met html of css).
7. Eoa javascript library die dit allemaal al kan (beetje hetzelfde als 4).
8. Wachten totdat browsers doorkrijgen dat hun image scaling crap is en het gefixt hebben.
9. Crappy images (en een ontevreden klant) maar gewoon slikken.

Dat zijn volgens mij de opties zover. Bedankt voor het meedenken
Gelukkig kon in mijn geval een SVG heel goed, maar het kan geen kwaad om hierover na te denken en te discussieren voor andere situaties.

[HuHu]

Het probleem is dat je randvoorwaarden (geen JavaScript, niet server-side) een beetje vreemd zijn. "Heden ten dage" ondersteunt iedere browser (desktop of mobiel) het gebruik van JavaScript, wat dit probleem eenvoudig oplosbaar maakt.

Wat ik eerder al zei: een browser is geen Photoshop. Het geeft perfect weer wat je aan ze voorschotelt. Wil je wat anders, dan moet je het of zelf anders aanleveren of genoegen nemen met een "best effort" poging van de browser.

[kaesve]

voor specifiek internet explorer zou je hier kunnen kijken: http://code.flickr.net/20...ient-side-image-resizing/ . In IE kun je dus wel met wat kleine hacks de qualiteit verbeteren. Op andere plaftformen bestaat er misschien wel iets vergelijkbaars, maar is het vaak ook een stuk minder nodig.

[Bosmonster]

_Thanatos_ schreef op vrijdag 25 januari 2013 @ 10:15:
@Bosmonster
50% zal nog wel redelijk werken, maar uitgaande van een bereik van 96dpi op de desktop tot bijna 400dpi op mobieltjes, heb ik gekozen voor 4x schalen ipv jouw 2x. In dit geval is dat niet zo erg, omdat het om een enkelkleurige lijntekening gaat. 4x zo groot of 2x zo groot maakte in filesize bijna geen verschil. Daarbij, 50% geeft hetzelfde probleem hoe dan ook, alleen is het minder duidelijk. Dezelfde afbeelding op 100% gebruiken is nog altijd mooier.

Het gaat niet om de ppi, maar om device pixel ratio. Voor zover ik weet is die nooit groter dan 2? Of hebben die belachelijke 4" fullhd schermpjes wel hoger dan 2 ingesteld tegenwoordig? (zou ik nog maling aan hebben overigens, aangezien je dat toch niet gaat zien als je 2 aanhoudt).

edit:
http://bjango.com/articles/min-device-pixel-ratio/
Volgens mij nog steeds niks hoger dan 2.

[ Voor 16% gewijzigd door Bosmonster op 25-01-2013 13:00 ]

[Nedra]

Is dit overigens niet iets wat je zou kunnen gebruiken?
http://retina-images.complexcompulsions.com

[de-cvd]

Dit is ook wel interessant om even door te lezen:

http://blog.netvlies.nl/design-interactie/retina-revolution/ en http://blog.netvlies.nl/d...tina-revolutie-follow-up/

[_Thanatos_]

Al die "retina" image replacement dingen die lossen maar een deel van het probleem op. Ze focussen bijna exclusief op "retina" schermen, terwijl het simpelweg schaalbaar hebben van images omwille van het scherm, compleet achterwege gelaten wordt. Er wordt veelal alleen naar de pixel-density gekeken, maar er zijn nog andere situaties waarin schaalbaarheid handig kan zijn, zoals een ontwerp dat juist *opschaalt* naar grotere schermen, maar ook high-dpi schermen die op normal ingesteld zijn (en zich dus voordoen als zo'n zelfde "groot" scherm). Denk ook aan printers.

Daarbij zie ik vooral dat er normale en dubbele plaatjes gebruikt worden. Dat betekent dus dat er geen tussenvorm kan bestaan, want die zou dan linksom of rechtsom lelijk worden.

Met foto's is dit niet zo'n probleem. Een "simpele" kwestie van de relatieve JPEG-kwaliteit omlaag gooien en de resolutie omhoog gooien. Per saldo dus de filesize gelijk houden bij een hogere resolutie. En dan dus "simpele" als in "leg dat de klant maar es uit".

Bij lijntekeningen (logo's, icoontjes) wordt het lastiger. Ja, je kunt meerdere versies serveren, maar dat is een drama in onderhoud. SVG lijkt dan de minst slechte oplossing, maar dan moet je wel toegang hebben tot de vectors... En vaak genoeg zijn SVG bestanden groter dan hun pixel-tegenhangers - ook als ze geoptimaliseerd worden. Maar zelfs bij SVG moet je je nog in een aantal onnodige bochten wringen om het in IE9 goed werkend te krijgen (zoals handmatig een viewBox toevoegen - wederom iets dat je aan de klant niet uitgelegd krijgt).

[ Voor 7% gewijzigd door _Thanatos_ op 19-02-2013 14:17 ]