Ajout du retaillage coté client #issue_4538 #4865

Bonjour,

Pourquoi une configuration et pas simplement tenir compte des constantes existantes :

https://www.spip.net/fr_article4645.html _IMG_MAX_WIDTH
https://www.spip.net/fr_article4646.html _IMG_MAX_HEIGHT
https://www.spip.net/fr_article5451.html _LOGO_MAX_WIDTH
https://www.spip.net/fr_article5452.html _LOGO_MAX_HEIGHT

Ce qui pose au passage la question de que faire si _LOGO et _IMG n'ont pas les mêmes valeurs...

l'interet de ne pas s'appuyer sur les constantes, c'est de pouvoir garder le retaillage coté serveur mais pas coté client, comme actuellement.

Mais quel intérêt d'avoir deux fois retaillage différent du coup ? Si le truc a déjà été retaillé côté client (quand le client sait le faire) bah pas besoin de le faire côté serveur, et inversement si ça n'a pas marché côté client, ya le serveur en fallback… Si on décide qu'on veut pas plus de 2500px de large maximum pourquoi est-ce qu'on ne voudrait pas que ce soit fait côté client dès lors que le client sait le faire ?

Je ne vois pas pourquoi, dans quel cas, on voudrait désactiver l'un ou l'autre : soit on veut des tailles max, soit pas, peu importe la (les) méthode.

à l'heure actuelle (tant que tous les tests et cas d'usages ne sont pas faits) ça permet de pouvoir débrayer le retaillage côté client en cas de problème ponctuel : en ne mettant aucune valeur dans les champs largeur et hauteur, bigup fonctionne en "legacy"

Autre point à considérer : la modification d'une constante peut ne pas être à la portée du webmestre (pas d'accès en écriture sur le serveur, pas les compétences pour créer un mes_options.php, pas la possibilité d'installer le plugin Couteau Kiss pour gérer...)

Et tant qu'on y est de discuter, on peut aussi poser la question dans l'autre sens : si le webmestre configure Bigup avec des limites de taille, ne faudrait il pas les utiliser aussi pour le retaillage en PHP ? (en priorité sur les constantes ?)

Bah c'est justement tout l'objet de la question, faut pas inventer des configs si elles existent déjà et qu'elles veulent bien dire la même chose, que c'est vraiment pour le même besoin (peu importe les choix techniques derrière, mais même besoin côté utilisateur).

Et généralement c'est l'inverse : les constantes sont toujours prioritaires et si elles sont définis on n'affiche pas de form de config (ou disabled), et inversement si vide là on permet parfois de les configurer par interface.

Mais pour chaque besoin (et donc là en l'occurence celui de la taille max des images) il faut se demander si c'est un choix de l'hébergeur ou un choix éditorial des admins ?

D'aucun pourrait considérer que les tailles max sont bien uniquement un choix des webmestres qui installent/hébergent, car c'est eux qui sont censés faire correspondre ce qui sera stocké à long terme (dans IMG) et les capacités en disque ou CPU de là où est le site (càd que si pas machine de guerre, on veut stocker à long terme des images plus petites à la fois pour les octets que pour moins avoir de chauffe quand il faut recadrer/retailler dans les squelettes, par rapport à des images de 10Mo).
Et que donc c'est pas du tout un choix éditorial des admins.

(C'est à débattre hein, je donne des arguments dans un sens)

Proposition / refléxion :

Si :
les constantes : _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT sont présntes
et la coche Générer automatiquement les miniatures des images => est cochée (car c'est elle qui permet le retaillage coté serveur)
Alors dans le formulaire de config de bigup, on affiche simplement à titre informatif ces valeurs qui seront donc utilisées. Mais non modifiable

Sinon :
on affiche les inputs pour choisir un width et height

"et la coche Générer automatiquement les miniatures des images => est cochée"
attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et toutes leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori.

Que ce truc soit coché ou pas, SI ya une lib d'image, ça doit pouvoir travailler dessus, c'est sans rapport avec cette case (là ici on parle pas de miniatures mais du retaillage des images sources directement qui seront gardées en base).

J'ai fait quelques essais avec cette version issue_4538 sur un SPIP 4.2-dev du jour en php 8.1.8
Avec des images au départ de plus de 7Mo et de dimensions 4896x3672 j'ai demandé
Largeur 1920
Hauteur 1200
et au départ je n'ai pas touché à la valeur par défaut de qualité.
Ca marche déjà bien !

L'image est bien réduite

Mais comme je trouvais que 775ko c'était encore un peu beaucoup j'ai cherché à jouer sur la compression. Avec la même image que je mette en "qualité" 0.8, 1 ou 0.1 le poids de l'image reste inchangé

Par ailleurs avec cette version de php j'ai un warning et un deprecated dans l'affichage dans la liste des plugins dans SVP lorsque je clique sur "plus d'infos"
Warning: Undefined array key "... wie der Name schon sagt ..." in /home/jack31/www_rumeur/ecrire/src/Texte/Collecteur/Multis.php on line 204
Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/jack31/www_rumeur/plugins-dist/textwheel/typographie/en.php on line 42

image.png

9.6 KiB

petit test avec la qualité de 0.1 et 0.9

Ca fonctionne bien maintenant

image.png

41 KiB

Merci c'est impeccable, d'ailleurs maintenant avec la valeur de compression par défaut 0.8 la taille de l'image est réduite presque de moitié par rapport à mes premiers essais. Et avec 0.1 ça tombe à environ 10% comme on pourrait s'y attendre (83ko contre 775ko)

Un détail, chez moi pour que le changement de valeur de compression soit pris en compte il faut fermer l'article en rédaction et le ré-ouvrir.

Concernant les warnings et deprecated je vais ouvrir un autre ticket dans bigup ce n'est pas directement lié à cette évolution.

"et la coche Générer automatiquement les miniatures des images => est cochée"
attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et toutes leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori.

Dans la doc de _IMG_MAX_xxx ça dit que si apparemment :

Si l’image est trop grande :

si l’option ’Générer automatiquement les miniatures des images’ a été activée, SPIP recadre l’image à la taille maximum autorisée.

si l’option ’Générer automatiquement les miniatures des images’ n’est pas activée, SPIP refusera l’image

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

Alors oui clairement l'explication ne convient pas/plus !

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

cf spip/spip#5390 donc... (merci pour le ticket :) )

Maintenant, la configuration prend en compte la presence des constantes _IMG_MAX_WIDTH et _IMG_MAX_HEIGHT et utilise _IMG_GD_QUALITY pour pour la qualite de compression.

Si les constantes sont presentes :

Si les constantes sont absentes :

Attention, pour les tests, la qualité n'est plus comprise en 0 et 1 mais 0 et 100 comme celle de _IMG_GD_QUALITY

image.png

36 KiB

image.png

31 KiB

Ça a l'air cool !

Sinon, je n'arrive pas à trouver s'il y a des valeurs par défaut qui sont proposées. Tout ce que je trouve, ce sont des valeurs dans les exemples de spip.net, ou dans les copies d'écran ci-dessus.

Et ce qui me chiffonne, c'est que toutes ces valeurs sont invraisemblablement basses, comme si on faisait encore du Web comme en 2000, et comme si SPIP n'avait pas des outils de redimensionnement des images.

Je vois des exemples de valeurs à 500 pixels, et encore 600 pixels dans la plus récente copie d'écran. Je pense qu'il ne faut surtout pas conseiller de faire tourner un site avec de telles valeurs. Même 1024 pixels c'est très peu.

Un écran d'iPhone 4, sorti en 2010, c'est déjà une largeur de 640 pixels et une hauteur de 960 pixels.

Le problème des images trop petites, car taillées pour une époque donnée et une maquette donnée, c'est que ça pourrit complètement les possibilités d'évolution du site. Quand je reprends un site Web, et que toutes les images font 600 pixels, je suis vraiment vraiment emmerdé, parce qu'il n'y a pas grands chose à faire pour le faire évoluer avec une maquette moderne.

Alors dans 5 ans…

=> D'où ma suggestion de commencer à donner des exemples et des valeurs par défaut correspondant à un site moderne et qui pourra évoluer facilement, en prenant bien en compte (voire en promouvant?) le fait que SPIP a des fonctions de traitement des images qui servent exactement à ça.

Perso mes recommendations pour les sites que je fais, c'est d'essayer de travailler avec des images qui font 2400 pixels dans leur plus grande dimension.

ces copies d'écrans, sont le résultats de tests, et c'est plus parlant avec des valeurs basses. Elles ne sont pas destinées à de la documentation ;-)

Si on regarde le code, pour activer le retaillage coté serveur il faut :

activer la generation des vignettes
ET
avoir au moins 1 constante presente _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT

75a5903176

Cette évolution me semble aussi importante que l’amélioration de l'interface privée en 4.0
Ca serait bien que ce soit dans la prochaine release et même en 4.1

Parce que sinon il faut continuer à expliquer aux gens comment réduire les images avant, et ils oublient une fois sur deux.

Euh bah non @jack31 comme expliqué dans ce thread même, quand tu actives les limites de taille max (largeur OU hauteur), bah ton SPIP va les retailler dès la source et donc sans apprendre à tes rédacs à retailler, et ça sera bien enregistré en 2500px max de largeur dans IMG ensuite. Sans cette fonctionnalité ça le fait déjà, côté serveur (et comme c'est un par un, et qu'ensuite ça reste à l'infini avec la bonne réduc dans IMG ça va très bien déjà).

Attention la valeur par défaut est restée à 0.8 pour le champ "Qualité" au lieu de 85 attendu maintenant dans formulaires/configurer_bigup.html

#SET{name,client_quality}#SET{obli,''}#SET{defaut,0.8}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}

Je me suis permis de rebaser / fixup / éditer les messages de commit.

Je me demande s’il ne faudrait pas conditionner

$scripts[] = 'lib/load_image/load-image.all.min.js';

Plutôt que de charger systématiquement 26Ko de plus de JS ?

A priori, ça fonctionne, c’est déjà bien :)

Je me demande s’il ne faudrait pas conditionner
$scripts[] = 'lib/load_image/load-image.all.min.js';
Plutôt que de charger systématiquement 26Ko de plus de JS ?

C'est une bonné idée !

Un question qui reste en suspend, pour l'instant, est l'activation automatique du retaillage. Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global create_preview qui elle, est indispensable pour activer le retaillage coté serveur.
Je pense que ce n'est pas necessaire.
Qu'en pensez vous ?

c'est très cool !
Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : _LOGO_MAX_WIDTH et _LOGO_MAX_HEIGHT.

S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ?

Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global create_preview qui elle, est indispensable pour activer le retaillage coté serveur.

A mon avis l'activation de la génération des vignettes et l'activation du retaillage (côté navigateur ou serveur) sont 2 choses différentes et il faut arrêter des les confusionner.
Je suis pour ne pas tenir compte de la globale create_preview dans le retaillage.

Pour mémoire, on retombe (partiellement) sur le problème soulevé par spip/spip#5390

Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : _LOGO_MAX_WIDTH et [_LOGO_MAX_HEIGHT]

S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ?

ha ha ! tu as démasqué tofulm : tel que codé pour l'instant, le retaillage côté navigateur considère que ces 2 constantes seront dépréciées d'ici pas longtemps :)

A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2...

A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2...

Effectivement, la taille max des logo peut être commune avec celles des images.

Par contre, en termes de direction artistique (clien d'œuil à ARNO), pouvoir avoir une taille minimum des logos différente de celle des images, c'est bien.

neat !

En rapport avec les préconisations d’@arno on pourrait peut être compléter la phrase actuelle

Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur

Par par exemple

Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur. Il est conseillé de conserver une taille minimale suffisante (par exemple 2400px) pour satisfaire les besoins graphiques actuels et ultérieurs du site.

QQc comme ça ?

J’envoie déjà ça !

Ajout du retaillage coté client #issue_4538 #4865

Reviewers