[spip-dev] Gérer les images @2x (pour les écrans haute résolution)

fil · Septembre 15, 2012, 9:31

Salut,

je veux afficher correctement les images sur les écrans haute
résolution (par exemple l'écran Retina de l'iPad3, mais aussi le mode
"agrandissement" des images dans les ebooks). Dans le jargon c'est
"@2x".

Pour ça l'idée est d'agir au niveau de |image_reduire, en procédant en
deux passes :

1. on multiplie par deux les valeurs de taille demandée (par exemple
1000px au lieu de 500px), et on réduit

2. ensuite on réduit de nouveau l'image, mais uniquement en mode
"style='width:…'", c-à-d sans créer de vignette, à la taille voulue
(500px)

ce qui nous donne par exemple :

* en partant d'une image de 2890px :

* en partant d'une image de 756px (donc entre 500 et 2x500) :

* (bien entendu, une image plus petite que 500px passe sans modif)

A noter : vu comment le code est construit, j'ai trouvé beaucoup plus
simple d'intégrer cela directement dans le core (désactivé par défaut)
que de le faire en plugin.

=> Une question serait de savoir si on l'active par un define(), par
un réglage global du site, ou par une fonction dont le résultat peut
dépendre de l'air du temps (page demandée, nom du client, etc.). Je
n'ai pas d'avis ferme là-dessus.

=> Par ailleurs au passage je me rends compte qu'on n'a pas dans le
core de fonction |ajouter_classe{} ou |ajouter_style{} qui
permettraient de manipuler les attributs class="xxx yyy" et
style="css:truc; css2: machin;". Je pense qu'on peut les ajouter
aussi, ce sera utile pour cette fonction.

Pour en discuter je pose une proposition de patch sur la zone dans
_dev_/images_a2x/
(http://zone.spip.org/trac/spip-zone/changeset/65886) ; mais c'est
bien une modif du core que je propose. Si vous voulez tester, il
suffit de récupérer ce inc/filtres_images_lib_mini.php et de le mettre
à la place de celui du core. J'ai aussi ajouté une bordure verte sur
les images @2x, pour débugguer.

-- Fil

RealET · Septembre 15, 2012, 9:57

* Fil tapuscrivait, le 15/09/2012 11:31:

Salut,

je veux afficher correctement les images sur les écrans haute
résolution (par exemple l'écran Retina de l'iPad3, mais aussi le mode
"agrandissement" des images dans les ebooks). Dans le jargon c'est
"@2x".

Pour ça l'idée est d'agir au niveau de |image_reduire, en procédant en
deux passes :

1. on multiplie par deux les valeurs de taille demandée (par exemple
1000px au lieu de 500px), et on réduit

2. ensuite on réduit de nouveau l'image, mais uniquement en mode
"style='width:…'", c-à-d sans créer de vignette, à la taille voulue
(500px)

Le problème de cette méthode, c'est la bande passante : tout le monde reçoit la version haute résolution, et c'est le navigateur qui réduit.
Avec sur une connexion un peu lente un effet descente de rideau désagréable.
Il y a des solution avec javascript pour charger les images @2x seulement sur écran Retina.

http://retinajs.com/

Ou avec des media query :
http://anthonygthomas.com/2012/04/22/media-queries-for-high-pixel-density-devices/

Idées à piker chez WP :

De la doc :
http://webdesign.tutsplus.com/articles/general/improving-image-quality-on-the-retina-display/

fil · Septembre 15, 2012, 10:06

tout le monde reçoit la version haute résolution, et c'est le navigateur qui réduit.

oui, c'est exactement ça

Avec sur une connexion un peu lente un effet descente de rideau désagréable.

mon intérêt principal du moment étant de faire des ebooks, ce n'est
pas vraiment mon sujet

mais pour minimiser la bande passante, il est peut-être possible de
traiter la réduction avec une qualité JPEG réduite, de manière à
rentrer dans les clous en termes de taille en ko…

et ça (l'optimisation des images), ça ne me semble pas concerner que
les écrans @2x.

-- Fil

RealET · Septembre 15, 2012, 10:16

* Fil tapuscrivait, le 15/09/2012 12:06:

tout le monde reçoit la version haute résolution, et c'est le navigateur qui réduit.

oui, c'est exactement ça

Avec sur une connexion un peu lente un effet descente de rideau désagréable.

mon intérêt principal du moment étant de faire des ebooks, ce n'est
pas vraiment mon sujet

Oui, mais, du coup, tu imagines d'introduire une fonctionnalité non générique (certes désactivée par défaut), mais inutilisable pour un site web "classique".
Dans un site web, il faut envoyer au navigateur l'image dans la taille d'affichage.
D'où les scripts ou media-query pour envoyer l'image en @2x uniquement pour les navigateur concernés.

mais pour minimiser la bande passante, il est peut-être possible de
traiter la réduction avec une qualité JPEG réduite, de manière à
rentrer dans les clous en termes de taille en ko…

Un emplâtre sur une jambe de bois AMHA.

et ça (l'optimisation des images), ça ne me semble pas concerner que
les écrans @2x.

Envoyer à un écran @2x une image en haute résolution à la compression
dégradante, ça me semble un peu contradictoire avec le but visé

cerdic · Septembre 15, 2012, 12:16

Hello,

Je pense que le sujet est encore très peu mur, et les techniques proposées toutes encore expérimentales. Pour ces raisons il faudrait éviter d'ajouter cela dans le core est préférer un plugin qui laisse plus de souplesse dans le dev et les tests de variante de technique.

La comme ça en première approche je dirais qu'une solution serait de dédier un filtre spécial image_reduire_taille_virtuelle puisque la réduction s'applique a la taille virtuelle visée et non a la taille physique de l'image.
Cela oblige du coup a renommer le filtre dans tes squelettes mais comme je comprends que c'est pour un usage dédié ça me parait envisageable.
Alternativement, je vais regarder comment ajouter des points d'entrée pour modifier le comportement d'un filtre image. De ce que je comprends il faudrait soit pouvoir le surcharger, soit pouvoir prendre la main en entrée pour modifier le comportement (arguments voire fonction appelée) et/ou en sortie pour modifier le résultat.

Cedric

Julien_Lanfrey · Septembre 15, 2012, 1:37

Salut,

Les histoires de retouches photos m’intéressent un peu. Notamment, un site collaboratif où j’ai plus de 40 000 photos (spip 2.1)…
J’ai abandonné l’idée de sensibiliser les internautes à redimensionner leurs photos avant upload…
Et me suis heurté à quelques pbs quand j’ai voulu mettre en place une retaille automatique. Je n’ai pas su où me brancher (pas de pipeline ??) pour intervenir directement suite à l’upload. Et ait donc du faire une petite interface qui me permet de faire ça après coup. Ce qui n’est pas le top car nécessite une intervention manuelle, de plus ça n’étale pas assez les retailles dans le temps et je sens que c’est limite niveau ressources sur certains serveurs mutualisés… En fonction du trafique (supposition), la retaille part parfois en vrille et j’obtiens une jolie photo toute noire de temps en temps… (ça n’arrive pourtant jamais à SPIP avec ses vignettes… faut que j’étudie comment il fait ça !).

Je me pose aussi la question des images uploadées d’une taille correcte mais dont la résolution est inutilement élevée (!=72dpi) pour un usage écran et qui occupe de la place inutilement sur l’hébergement.
Rien vu de simple pour tester la résolution. J’envisage de faire la lecture de ce paramètre à la mano qd j’aurais un moment.

Niveau tailles photos sur le disque, je suis récemment parti pour autoriser du 1600 max en largeur et 900 de haut (paysage) ou 1200 (portrait).
ça me paraissait un bon compromis par rapport à mes stats écrans, compte tenu aussi des barres d’outils navigateur et des marges du site et player photos. J’ai en effet choisi de négliger ceux qui ont des écrans “hors normes” dans mon cas !! Pour des histoires de confort des temps de chargement pour la majorité des internautes. Mais ce sont des paramètres que j’ajuste avec le temps et l’évolution techno.
Je gère aussi quelques exceptions comme la non retaille des panoramas au dessous d’un certain poids…

Branchement pour agir sur les photos uploadées.
Tests de résolution d’image. (réenregistrer avec gd provoque un passage en 72dpi)
Le plugin hashdocument ou équivalent intégré à la distrib. (déjà un système équivalent pour la répartition des fichiers de cache…)
La problématique des logos

J’adore SPIP en ce qui concerne sa facilité de gestion des images (je retaille et recadre à tout va !), sa gestion des vignettes en caches, etc.
Je connais un autre CMS. Une usine à gaz qui va très très loin fonctionnellement mais où SPIP le bat à plates coutures sur les aspect gestion d’images…

Ciel ! je me rends compte que je viens de pourrir le sujet initial…

c’est le : “Vu comment le code est construit, j’ai trouvé beaucoup plus simple d’intégrer cela directement dans le core (désactivé par défaut)
que de le faire en plugin.”

…qui m’a fait remonter des choses en mémoire.
et notamment : pouvoir se brancher, pour intervenir suite aux uploads via des plugins…

Les astuces Jquery retina, ou via mediaquery sont intéressantes. Mais de mon côté, ça me paraitrait difficile de me dire que je stocke au moins 2 versions de l’image en grande taille. ça me ferait doubler l’espace disque occupé… Bon, peut être que ce n’est pas si grave après tout… Je ne sais pas trop.

Julien

lspeciale · Septembre 15, 2012, 8:39

Au cas où, je ne sais pas si t'as vu ça

http://adaptive-images.com/

A +

fil · Septembre 16, 2012, 5:44

Merci pour tous les liens et les commentaires, en effet tout ça n'est
pas mûr

Je vais faire un plugin avec mon code, ce qui permettra d'explorer un
peu plus les différentes possibilités.

Notamment, je crois que ce serait pas mal d'avoir un filtre
image_reduire qui produise le cas échéant DEUX images, @1x et @2x, et
renverrait par exemple un tag du type <img src="version @1x"
data:a2x="version @2x" /> quand c'est pertinent.

Pour ce qui est du point d'entrée, il me semble qu'il faudrait
permettre de surcharger la fonction process_image_reduire, utilisée
aussi bien par image_reduire que par image_passe_partout.

-- Fil

lspeciale · Septembre 16, 2012, 6:53

Je croyais que adaptive-images le faisait déjà, et à la volée, mais ce n'est peut-être pas le cas. Et il n'y pas besoin de 2 images, tout est fait avec GD, non ?

klaus · Septembre 17, 2012, 7:24

Salut,

mais pour minimiser la bande passante, il est peut-être possible de
traiter la réduction avec une qualité JPEG réduite, de manière à
rentrer dans les clous en termes de taille en ko…

Un emplâtre sur une jambe de bois AMHA.

Non, svp ne le faites pas: Quand la taille en octets d'une image surdimensionnée est réduite par une compression forte la quantité de couleurs et de niveaux de gris est réduite. En conséquence l'image subit une perte de qualité visible. Lorsque la taille en pixels de cette image est réduite par le moteur du brouteur afin d'obtenir la taille inititiale, d'autres effets néfastes se rajoutent qui sont dûs à la faible qualité de ces traitements graphiques.

On additionne deux procédés dont on peut éventuellement tolérer le rendu individuel mais dont la combinaison risque de créer des dégâts considérables.

klaus++

lspeciale · Septembre 17, 2012, 9:20

En tout cas le résultat que j'obtiens avec adaptative-images est plus que correct. Si vous voulez tester rapidement, voici ma cuisine.
Vous prenez un layout fluide, nous sommes d'accord.

Puis faut mettre la boucle comme src
<div id="imga">
<BOUCLE_back-img(MOTS){id_mot}>
<img src="[(#LOGO_MOT|extraire_attribut{src})]" />
</BOUCLE_back-img>
</div>

Leur donner un widht

#imga{width:100%;z-index:0;position:absolute;bottom:0;right:0;}

#imga img {width:65%;background:#FFF;position:absolute;bottom:0;right:0;z-index:10;}

Puis c'est tout

A +

cerdic · Septembre 17, 2012, 11:08

Hello,

J’ai introduit 2 pipelines qui pourraient permettre de prendre la main au moment où l’on ecrit la balise http://core.spip.org/projects/spip/repository/revisions/19917
(reportable en 2.1 si cela nécessaire)

je ne suis pas sûr que cela suffise, mais à la reflexion je pense que l’on peut faire autrement, et j’ai mis rapidement un proto de principe dans le dossier de a2x :
http://zone.spip.org/trac/spip-zone/changeset/65950

Et encore après je me dis que cette approche sera quand même limitée car on peut automatiser à la volée la prise en charge d’un traitement comme image_réduire, mais ça peut être plus compliqué sur d’autres comme image_recadre, image_passe_partout etc…
Je me demande si en fait le squelette ne devrait pas produire à la source une image x2 (écriture des filtres image en dimension doublée dans le source) et automatiser ensuite la production de la balise img réduite/2 quand nécessaire (tout le temps, ou avec double référence des deux resolutions etc…). Car c’est plus simple de produire une image réduite par 2 en fin de chaine, et sans erreur, alors que la production de l’image x2 en fin de chaine est plus hasardeuse et incertaine…

Bref, à tester/murir/…

Cédric

9aa2aa68144b2781ac02 · Octobre 1, 2012, 10:33

Hello,

J’ai introduit 2 pipelines qui pourraient permettre de prendre la main au moment où l’on ecrit la balise
http://core.spip.org/projects/spip/repository/revisions/19917
(reportable en 2.1 si cela nécessaire)

je ne suis pas sûr que cela suffise, mais à la reflexion je pense que l’on peut faire autrement, et j’ai mis rapidement un proto de principe dans le dossier de a2x :
http://zone.spip.org/trac/spip-zone/changeset/65950

Et encore après je me dis que cette approche sera quand même limitée car on peut automatiser à la volée la prise en charge d’un traitement comme image_réduire, mais ça peut être plus compliqué sur d’autres comme image_recadre, image_passe_partout etc…
Je me demande si en fait le squelette ne devrait pas produire à la source une image x2 (écriture des filtres image en dimension doublée dans le source) et automatiser ensuite la production de la balise img réduite/2 quand nécessaire (tout le temps, ou avec double référence des deux resolutions etc…). Car c’est plus simple de produire une image réduite par 2 en fin de chaine, et sans erreur, alors que la production de l’image x2 en fin de chaine est plus hasardeuse et incertaine…

Sympa de voir ce genre de choses bien pénibles s’outiller dans SPIP.

Ce serait top que ça génère un code compatible avec ce qui s’annonce comme potentiel futur standard de gestion des images en Responsive Web Design ET pour les écrans haute densité, et pour lequel un quasi polyfill est dispo : https://github.com/scottjehl/picturefill