Tester et signaler si la librairie choisie ne sait pas traiter le webp #4815

Open
opened 1 year ago by JLuc · 29 comments
JLuc commented 1 year ago

Les documents webp n'ont pas de vignette alors que ce sont des images.

J'ai tracké ça comme "évolution" mais pour beaucoup d'utilisateurs ça sera ressenti comme une anomalie.

Les documents webp n'ont pas de vignette alors que ce sont des images. J'ai tracké ça comme "évolution" mais pour beaucoup d'utilisateurs ça sera ressenti comme une anomalie.
JLuc commented 1 year ago
Poster

C'est peut être dans "Images" que ce ticket devrait aller plutôt.

Sur contrib, les documents ajoutés ne sont pas présentés par une vignette, mais tout de même il y a bien la possibilité de créer une vignette puisque les logos webp sont présentés par des vignettes (carrée aux coins arrondis) dans les listes.

C'est peut être dans "Images" que ce ticket devrait aller plutôt. Sur contrib, les documents ajoutés ne sont pas présentés par une vignette, mais tout de même il y a bien la possibilité de créer une vignette puisque les logos webp sont présentés par des vignettes (carrée aux coins arrondis) dans les listes.
b_b commented 1 year ago
Owner

Quand tu parles de vignettes, tu veux dire que le pb est que SPIP ne génère pas de miniatures pour ces images ?

Quand tu parles de vignettes, tu veux dire que le pb est que SPIP ne génère pas de miniatures pour ces images ?
JLuc commented 1 year ago
Poster

C'est cela, dans le privé.
Exemple sur contrib : https://contrib.spip.net/ecrire/?exec=article&id_article=5288

C'est cela, dans le privé. Exemple sur contrib : https://contrib.spip.net/ecrire/?exec=article&id_article=5288
JLuc commented 1 year ago
Poster

En fait les vignettes présentes dans les listes (par exemple ici : https://contrib.spip.net/ecrire/?exec=rubrique&id_rubrique=2036) sont créées par pur HTML : img class="spip_logo" width="442" height="457" et donc ça ne dit rien de la capacité du site à gd webp, et donc peut-être contrib ne gd pas webp.
Peut être faudrait il faire pour la vignette auto des documents comme pour les vignettes des listes ?

Rq: width=442 et height=457 alors que les images font 50x50px ou 70x70px selon le zoom ! Bug ?

En fait les vignettes présentes dans les listes (par exemple ici : https://contrib.spip.net/ecrire/?exec=rubrique&id_rubrique=2036) sont créées par pur HTML : _img class="spip_logo" width="442" height="457"_ et donc ça ne dit rien de la capacité du site à gd webp, et donc peut-être contrib ne gd pas webp. Peut être faudrait il faire pour la vignette auto des documents comme pour les vignettes des listes ? Rq: width=442 et height=457 alors que les images font 50x50px ou 70x70px selon le zoom ! Bug ?
JLuc commented 1 year ago
Poster

Sur Gandi SH, OVH Pro 2010 (comme le tiens b_b) et allwaysdata mutu, gd webp est activé.

Le pb semble être que le fichier original du logo est affiché redimensionné (comme dans les listes) avec une largeur de 320px calculée et imposée par SPIP :
img src="../IMG/logo/framboise.resized.webp?1623097946" style="max-width: 320px; max-height: 320px" alt="logo_on"

Mais la colonne ne fait que 286px de large d'après l'inspecteur.

Sur Gandi SH, OVH Pro 2010 (comme le tiens b_b) et allwaysdata mutu, gd webp est activé. Le pb semble être que le fichier original du logo est affiché redimensionné (comme dans les listes) avec une largeur de 320px calculée et imposée par SPIP : img src="../IMG/logo/framboise.resized.webp?1623097946" style="max-width: 320px; max-height: 320px" alt="logo_on" Mais la colonne ne fait que 286px de large d'après l'inspecteur.
JLuc commented 1 year ago
Poster

Attention ce ticket évoque 2 type d'occurences des webp : logo et vignettes des documents.

Attention ce ticket évoque 2 type d'occurences des webp : logo et vignettes des documents.
Poster

Je sais pas de quelle manière précisément c'est en rapport mais depuis que j'ai uploadé 1 ou 2 logos webp, tout se passe bien en apparence sur le site, mais il y a des milliers d'erreurs dans les logs "FPM" de l'hébergeur gandi.
Ce sont 3 logs à la suite qui se répètent dans cet ordre en changeant (ou pas) le fichier image :

  • "convert-im6.q16: delegate failed `'dwebp' -pam '%i' -o '%o'' @ error/delegate.c/InvokeDelegate/1949."
  • "convert-im6.q16: unable to open file `/srv/data/tmp/magick-124824GtD3IK9JMJae': No such file or directory @ error/constitute.c/ReadImage/544."
  • "convert-im6.q16: no images defined `local/cache-vignettes/L213xH301/lenomdemonfichierwebp-bc12e.webp' @ error/convert.c/ConvertImageCommand/3258."
Je sais pas de quelle manière précisément c'est en rapport mais depuis que j'ai uploadé 1 ou 2 logos webp, tout se passe bien en apparence sur le site, mais il y a des milliers d'erreurs dans les logs "FPM" de l'hébergeur gandi. Ce sont 3 logs à la suite qui se répètent dans cet ordre en changeant (ou pas) le fichier image : - "convert-im6.q16: delegate failed `'dwebp' -pam '%i' -o '%o'' @ error/delegate.c/InvokeDelegate/1949." - "convert-im6.q16: unable to open file `/srv/data/tmp/magick-124824GtD3IK9JMJae': No such file or directory @ error/constitute.c/ReadImage/544." - "convert-im6.q16: no images defined `local/cache-vignettes/L213xH301/lenomdemonfichierwebp-bc12e.webp' @ error/convert.c/ConvertImageCommand/3258."
Owner

Faisons le point, chez moi en PHP 8.1.7 avec convert comme moteur de génération de vignettes, une image webp a bien un vraie vignette affichée dans la médiathèque, c'est vérifiable par ses dimensions et son chemin du style ../local/cache-vignettes/L97xH100/framboise-b9c77-c11a7.webp?1657475393.

Sachant que l'objet initial du ticket est "Les documents webp n'ont pas de vignette alors que ce sont des images", est-ce qu'il reste quelque chose à corriger/améliorer ?

Faisons le point, chez moi en PHP 8.1.7 avec convert comme moteur de génération de vignettes, une image webp a bien un vraie vignette affichée dans la médiathèque, c'est vérifiable par ses dimensions et son chemin du style `../local/cache-vignettes/L97xH100/framboise-b9c77-c11a7.webp?1657475393`. Sachant que l'objet initial du ticket est "Les documents webp n'ont pas de vignette alors que ce sont des images", est-ce qu'il reste quelque chose à corriger/améliorer ?
Poster

Quand je parlais de "vignette" c'était un terme générique pour décrire une image de taille réduite présentée par SPIP.
Donc en employant le terme "vignette" de manière profane = image de taille réduite, voici les problèmes :

logo dans page article

Le layout d'une page article est cassé quand un logo webp est un peu trop gros : https://contrib.spip.net/ecrire/?exec=article&id_article=5288

  • Le fichier original comme indiqué par SPIP fait 442px de large.
  • L'image affichée, c'est ce fichier original, mais restreint par les attributs HTML et les CSS à une largeur de 320px
  • Or dans la colonne de navigation il ne dispose que de 245px
  • Donc ça déborde. En fait ya déjà un ticket pour ça : spip/spip#4826

vignettes des logos dans les listes

Les vignettes qui présentent les articles dans les listes (par exemple ici : https://contrib.spip.net/ecrire/?exec=rubrique&id_rubrique=2036) utilisent également les images originales.
Leur poids peut être de plusieurs Mo chacune, et c'est le HTML qui en réduit l'apparence avec img class="spip_logo" width="442" height="457" . S'il y a 10 articles (une pagination) dans une liste avec chacun un gros logos de 5 ou 6 Mo comme un original de fichier photo, la page va charger 60Mo de fichier images, alors qu'avec un fichier réduit, ça ne serait que 200 ou 300ko.

De plus ces dimensions ne correspondent pas à la taille imposée par la classe : var(--spip-list-biglogo-size) qui est de 70px (ou 50px selon le zoom). Ça m'étonnerait que ça soit conforme aux recommandations.

Bilan

|image_reduire ne réduit rien du tout et renvoie le fichier webp original

Ça n'est pas visible en général car les attributs HTML et les classes CSS (fournies par les balises de SPIP) font que le rendu est quand même en général correct. Mais ya des limites (cf plus haut "logo dans page article"). Par ailleurs je l'ai aussi constaté sur un squelette qui renvoie l'attribut src d'une image réduite : car sans le html correctif des balises spip, le fichier SRC s'affichait en grand !!

PS : contrib utilise GD2 ; le site où je constate le même pb utilise convert.

Quand je parlais de "vignette" c'était un terme générique pour décrire une image de taille réduite présentée par SPIP. Donc en employant le terme "vignette" de manière profane = image de taille réduite, voici les problèmes : ### logo dans page article Le layout d'une page article est cassé quand un logo webp est un peu trop gros : https://contrib.spip.net/ecrire/?exec=article&id_article=5288 - Le fichier original comme indiqué par SPIP fait 442px de large. - L'image affichée, c'est ce fichier original, mais restreint par les attributs HTML et les CSS à une largeur de 320px - Or dans la colonne de navigation il ne dispose que de 245px - Donc ça déborde. En fait ya déjà un ticket pour ça : https://git.spip.net/spip/spip/issues/4826 ### vignettes des logos dans les listes Les vignettes qui présentent les articles dans les listes (par exemple ici : https://contrib.spip.net/ecrire/?exec=rubrique&id_rubrique=2036) utilisent également les images originales. Leur poids peut être de plusieurs Mo chacune, et c'est le HTML qui en réduit l'apparence avec `img class="spip_logo" width="442" height="457" `. S'il y a 10 articles (une pagination) dans une liste avec chacun un gros logos de 5 ou 6 Mo comme un original de fichier photo, la page va charger 60Mo de fichier images, alors qu'avec un fichier réduit, ça ne serait que 200 ou 300ko. De plus ces dimensions ne correspondent pas à la taille imposée par la classe : `var(--spip-list-biglogo-size)` qui est de 70px (ou 50px selon le zoom). Ça m'étonnerait que ça soit conforme aux recommandations. ### Bilan `|image_reduire` ne réduit rien du tout et renvoie le fichier webp original Ça n'est pas visible en général car les attributs HTML et les classes CSS (fournies par les balises de SPIP) font que le rendu est quand même en général correct. Mais ya des limites (cf plus haut "logo dans page article"). Par ailleurs je l'ai aussi constaté sur un squelette qui renvoie l'attribut src d'une image réduite : car sans le html correctif des balises spip, le fichier SRC s'affichait en grand !! PS : contrib utilise GD2 ; le site où je constate le même pb utilise convert.
Owner

logo dans page article

Chez moi ça ne déborde pas, certainement car j'ai les libs qu'il faut pour générer une vignette webp. Si je passe le moteur de vignettes en GD2 comme c'est le cas sur contrib, toujours pas de problème, j'ai bien une vignette webp générée dans local Donc, je pense que ce problème est "local" à contrib.

vignettes des logos dans les listes

Même constat que le précédent.

Bilan

|image_reduire ne réduit rien du tout et renvoie le fichier webp original

Non, image_reduire renvoie l'image réduite par le biais des attricuts HTML que si le serveur ne sait pas générer une vignette webp avec le moteur sélectionné.

Donc, à part signaler le problème dans le repo de contrib, je pense qu'on peut fermer ce ticket :)

> logo dans page article Chez moi ça ne déborde pas, certainement car j'ai les libs qu'il faut pour générer une vignette webp. Si je passe le moteur de vignettes en GD2 comme c'est le cas sur contrib, toujours pas de problème, j'ai bien une vignette webp générée dans `local` Donc, je pense que ce problème est "local" à contrib. > vignettes des logos dans les listes Même constat que le précédent. > Bilan > |image_reduire ne réduit rien du tout et renvoie le fichier webp original Non, image_reduire renvoie l'image réduite par le biais des attricuts HTML que si le serveur ne sait pas générer une vignette webp avec le moteur sélectionné. Donc, à part signaler le problème dans le repo de contrib, je pense qu'on peut fermer ce ticket :)
Poster

Autre élément du bilan

vignettes absentes

Dans la liste des images associées à un article mais non "vues" ainsi que dans la médiathèque, les vignettes des images webp ne sont pas les fichiers réduits comme dans les listes, c'est une version "réduite" de defaut.svg qui est utilisée : /local/cache-vignettes/L64xH64/defaut-e35df-2a840.svg?1656144964

cf
https://contrib.spip.net/ecrire/?exec=article&id_article=5288#portfolios et https://contrib.spip.net/ecrire/?exec=documents&media=image&extension=webp

Sur mon site par contre c'est le fichier original qui apparait là, réduit par attributs et css comme dans les listes

Autre élément du bilan ### vignettes absentes Dans la liste des images associées à un article mais non "vues" ainsi que dans la médiathèque, les vignettes des images webp ne sont pas les fichiers réduits comme dans les listes, c'est une version "réduite" de defaut.svg qui est utilisée : /local/cache-vignettes/L64xH64/defaut-e35df-2a840.svg?1656144964 cf https://contrib.spip.net/ecrire/?exec=article&id_article=5288#portfolios et https://contrib.spip.net/ecrire/?exec=documents&media=image&extension=webp Sur mon site par contre c'est le fichier original qui apparait là, réduit par attributs et css comme dans les listes
Poster

Sur mon site où je constatais le pb, si je passe de convert à gd2, alors la réduction se fait bien ! (Et ça devient blurry...)

Il semble donc que, comme tu l'écris, c'est dû à une lib manquante sur les serveurs.

Il serait bien que SPIP en fasse le diagnostic (qui dépend de la librairie graphique choisie) et avertisse le webmestre, sur la page de config avancées, là où on choisit la librairie et où est testée la taille max des images que SPIP peut traiter. Je change le titre en conséquence.

Sur mon site où je constatais le pb, si je passe de `convert` à `gd2`, alors la réduction se fait bien ! (Et ça devient blurry...) Il semble donc que, comme tu l'écris, c'est dû à une lib manquante sur les serveurs. Il serait bien que SPIP en fasse le diagnostic (qui dépend de la librairie graphique choisie) et avertisse le webmestre, sur la page de config avancées, là où on choisit la librairie et où est testée la taille max des images que SPIP peut traiter. Je change le titre en conséquence.
JLuc changed title from Vignette des documents webp to Tester et signaler si la librairie choisie ne sait pas traiter le webp 3 months ago
Owner

Si l'objet du ticket change tous les 12 commentaires on risque de se le trimballer pendant encore un an...

Je ne vois pas pourquoi on devrait afficher un avertissement au sujet des webp, on ne le fait pas pour les gifs animés par exemple, mais bon, si une personne veut y consacrer du temps, go.

Si l'objet du ticket change tous les 12 commentaires on risque de se le trimballer pendant encore un an... Je ne vois pas pourquoi on devrait afficher un avertissement au sujet des webp, on ne le fait pas pour les gifs animés par exemple, mais bon, si une personne veut y consacrer du temps, go.
Owner

jusqu'à preuve du contraire webp n'est pas un format d'image considéré comme acceptable pour contribuer des images dans SPIP (pas plus que bmp par exemple, que pourtant certains navigateurs sav(ai)ent afficher mais qui n'a jamais été standard ie universellement supporté sur le web).

Peut-être webp va atteindre ce statut un jour (il n'est est pas loin), mais peut-être pas, car comme tu pourras le lire ici
https://caniuse.com/?search=webp
"AVIF and JPEG XL are designed to supersede WebP."

Donc pour le moment seuls gif(!), png, jpg et svg sont des format d'image réellement acceptables pour contribuer des images ayant vocation à être affichées sur le site web, et pour lesquelles on doit savoir calculer une vignette.

Pour le reste en effet c'est au petit bonheur la chance.

jusqu'à preuve du contraire webp n'est pas un format d'image considéré comme acceptable pour contribuer des images dans SPIP (pas plus que bmp par exemple, que pourtant certains navigateurs sav(ai)ent afficher mais qui n'a jamais été standard ie universellement supporté sur le web). Peut-être webp va atteindre ce statut un jour (il n'est est pas loin), mais peut-être pas, car comme tu pourras le lire ici https://caniuse.com/?search=webp "AVIF and JPEG XL are designed to supersede WebP." Donc pour le moment seuls gif(!), png, jpg et svg sont des format d'image réellement acceptables pour contribuer des images ayant vocation à être affichées sur le site web, et pour lesquelles on doit savoir calculer une vignette. Pour le reste en effet c'est au petit bonheur la chance.
Owner

et pour finir d'être clair sur ce ticket : 1/ webp reste encore très partiellement supporté par les librairies graphiques (il faut une version vraiment à jour de php&gd par exemple), et même si tu as un GD tout à fait récent, on ne gère pas du tout webp dans les traitement d'image de SPIP (ni à la lecture, ni à l'écriture).

Si on doit commencer à gérer les multiscenario du genre "là j'ai une lib qui accepte tels formats mais pas tel autre", le code va devenir très compliqué.

Donc le test des librairies d'image c'est "OK la librairie marche pour les formats qu'on supporte" ou "non elle ne supporte pas les formats dont on à besoin". Donc si on intègre webp dans cette liste, on va disqualifier plein de serveur dont le GD n'est pas up et qui ne pourront plus bénéficier du tout d'aucun traitement d'image sur leur site.

et pour finir d'être clair sur ce ticket : 1/ webp reste encore très partiellement supporté par les librairies graphiques (il faut une version vraiment à jour de php&gd par exemple), et même si tu as un GD tout à fait récent, on ne gère pas du tout webp dans les traitement d'image de SPIP (ni à la lecture, ni à l'écriture). Si on doit commencer à gérer les multiscenario du genre "là j'ai une lib qui accepte tels formats mais pas tel autre", le code va devenir très compliqué. Donc le test des librairies d'image c'est "OK la librairie marche pour les formats qu'on supporte" ou "non elle ne supporte pas les formats dont on à besoin". Donc si on intègre webp dans cette liste, on va disqualifier plein de serveur dont le GD n'est pas up et qui ne pourront plus bénéficier du tout d'aucun traitement d'image sur leur site.
Poster

En effet vu que ça marche pas sur un grand nombre de combinaisons (hébergeurs, version php, g-librairie), spip ne peut pas "garantir" gérer webp.
Pourtant, webp est un quasi standard universel sur les navigateurs !

Le besoin c'est donc qu'il y ait un test et une information supplémentaire : « la g-librairie choisie permet elle le traitement correct des webp ? »
Et la proposition n'est pas du tout de changer le code actuel qui teste la présence des librairies, pour les disqualifier si elles ne gèrent pas webp.

Tel qu'évoqué simplement là, c'est une information supplémentaire apportée à l'admin pour le choix de logos bien gérés. Charge à l'admin de se servir de cette info pour choisir telle ou telle librairie, et si jamais il retient une librairie qui ne supporte pas webp, charge à lui de transmettre cette contrainte aux rédacteurs. Ça complèterait utilement l'information "taille max des images traitées" (dont je n'ai jamais eu l'usage mais qui a un rôle similaire d'information pour le bon usage des documents).

Puisque cerdic tu évoques les AVIF et JPEGXL destinés à "superseder" webp, la question se posera pour eux aussi dès que le support de ces formats sera significatif pour les navigateurs et tant qu'il ne sera pas total pour les g-librairies, c'est à dire tant qu'il y a une incertitude, comme pour webp actuellement.
Le test et les indications concernant le support de webp pourront alors être complétées par 2 autres : pour le traitement correct des AVIF et pour le traitement correct des JPEG XL.

Jusque là, je ne vois pas de "multiscénario" à gérer ni de complexification des fonctions d'images, car ça n'a pas de conséquence ailleurs que dans la page de config étendue, qui appelle le test et en montre les résultats.

Il ne sagit pas du tout non plus d'interdire une librairie parcequ'elle ne supporte pas webp. Par contre, inversement, certains webmestres pourraient vouloir interdire l'usage de webp s'ils savent que la g-librairie gère mal. Car

  • ok le fallback actuel réussit bien à donner l'illusion dans la plupart des cas (bravo !)
  • mais pas toujours : trop grands webp, accès au src non redimensionné d'un webp passé par image_reduire
    Sans toucher les fonctions d'images, lorsqu'il a été détecté que la glib ne les prend pas en chargen il me semble qu'il est possible d'arrêter de considérer les webp comme des images téléchargeables ? Ça pourrait se faire par un choix de l'utilisateur dans cette page de config ou via un plugin.
En effet vu que ça marche pas sur un grand nombre de combinaisons (hébergeurs, version php, g-librairie), spip ne peut pas "garantir" gérer webp. Pourtant, webp est un quasi standard universel sur les navigateurs ! Le besoin c'est donc qu'il y ait un test et une information supplémentaire : « la g-librairie choisie permet elle le traitement correct des webp ? » Et la proposition n'est pas du tout de changer le code actuel qui teste la présence des librairies, pour les disqualifier si elles ne gèrent pas webp. Tel qu'évoqué simplement là, c'est une information **supplémentaire** apportée à l'admin pour le choix de logos bien gérés. Charge à l'admin de se servir de cette info pour choisir telle ou telle librairie, et si jamais il retient une librairie qui ne supporte pas webp, charge à lui de transmettre cette contrainte aux rédacteurs. Ça complèterait utilement l'information "taille max des images traitées" (dont je n'ai jamais eu l'usage mais qui a un rôle similaire d'information pour le bon usage des documents). Puisque cerdic tu évoques les AVIF et JPEGXL destinés à "superseder" webp, la question se posera pour eux aussi dès que le support de ces formats sera significatif pour les navigateurs et tant qu'il ne sera pas total pour les g-librairies, c'est à dire tant qu'il y a une incertitude, comme pour webp actuellement. Le test et les indications concernant le support de webp pourront alors être complétées par 2 autres : pour le traitement correct des AVIF et pour le traitement correct des JPEG XL. Jusque là, je ne vois pas de "multiscénario" à gérer ni de complexification des fonctions d'images, car ça n'a pas de conséquence ailleurs que dans la page de config étendue, qui appelle le test et en montre les résultats. Il ne sagit pas du tout non plus d'interdire une librairie parcequ'elle ne supporte pas webp. Par contre, inversement, certains webmestres pourraient vouloir interdire l'usage de webp s'ils savent que la g-librairie gère mal. Car - ok le fallback actuel réussit bien à donner l'illusion dans la plupart des cas (bravo !) - mais pas toujours : trop grands webp, accès au src non redimensionné d'un webp passé par image_reduire Sans toucher les fonctions d'images, lorsqu'il a été détecté que la glib ne les prend pas en chargen il me semble qu'il est possible d'arrêter de considérer les webp comme des images téléchargeables ? Ça pourrait se faire par un choix de l'utilisateur dans cette page de config ou via un plugin.
Owner

Dans un monde idéal avec plein de ressources on pourrait faire plein de choses.

Mais soit on supporte le webp comme un format d'image web à part entière et il faut gérer le support par les filtres images et la detection correcte de la librairie et gérer le cas des librairies qui ne supportent que certains formats
Soit on ne le supporte pas (encore ?) car trop imparfaitement géré par les navigateurs pour le moment (oui les dernières versions de chaque navigateur supportent maintenant webp, mais il y a encore plein de gens qui ne verront pas les images webp). Donc pour webp est encore et uniquement un format d'image complémentaire, utilisable en source alternative pour les navigateurs modernes, comme le fait le plugin adaptive_images, mais pas un format d'image pour contribuer.

On pourra en reparler dans 1, 2 ou 5 ans et changer d'avis, mais là c'est vraiment pas en haut des priorités

Dans un monde idéal avec plein de ressources on pourrait faire plein de choses. Mais soit on supporte le webp comme un format d'image web à part entière et il faut gérer le support par les filtres images et la detection correcte de la librairie et gérer le cas des librairies qui ne supportent que certains formats Soit on ne le supporte pas (encore ?) car trop imparfaitement géré par les navigateurs pour le moment (oui les dernières versions de chaque navigateur supportent maintenant webp, mais il y a encore plein de gens qui ne verront pas les images webp). Donc pour webp est encore et uniquement un format d'image complémentaire, utilisable en source alternative pour les navigateurs modernes, comme le fait le plugin adaptive_images, mais pas un format d'image pour contribuer. On pourra en reparler dans 1, 2 ou 5 ans et changer d'avis, mais là c'est vraiment pas en haut des priorités
Poster

Quand tu dis "gérer le support par les filtres images et gérer le cas des librairies qui ne supportent pas certains formats", je comprends que tu veux dire « créer un code (ou utiliser une librairie en php interprêté) pour faire le boulot quand les librairies (compilées) livrées avec php ne le font pas correctement ». Effectivement ce serait l'idéal mais là c'est toi qui charge la mule des ressources avec cette hypothèse qui est énormément plus lourde que celle que je propose.

Car ma proposition est moins idéale mais beaucoup moins coûteuse : en lui fournissant les informations qui lui permettront de faire un choix éclairé, déléguer à l'administrateur du site cette bonne gestion, ou au moins lui donner les moyens de faire au mieux, en connaissance de cause.

Dans 1, 2 ou 5 ans, peut être toutes les librairies graphiques gèreront bien le webp... mais pas AVIF et JPEFXL, pour lesquels il faudra encore 5, 10 ou 15 ans... donc c'est une utilité durable.

Quand tu dis "gérer le support par les filtres images et gérer le cas des librairies qui ne supportent pas certains formats", je comprends que tu veux dire « créer un code (ou utiliser une librairie en php interprêté) pour faire le boulot quand les librairies (compilées) livrées avec php ne le font pas correctement ». Effectivement ce serait l'idéal mais là c'est toi qui charge la mule des ressources avec cette hypothèse qui est énormément plus lourde que celle que je propose. Car ma proposition est moins idéale mais beaucoup moins coûteuse : en lui fournissant les informations qui lui permettront de faire un choix éclairé, déléguer à l'administrateur du site cette bonne gestion, ou au moins lui donner les moyens de faire au mieux, en connaissance de cause. Dans 1, 2 ou 5 ans, peut être *toutes* les librairies graphiques gèreront bien le webp... mais pas AVIF et JPEFXL, pour lesquels il faudra encore 5, 10 ou 15 ans... donc c'est une utilité durable.
Owner

Car ma proposition est moins idéale mais beaucoup moins coûteuse

Quelle est-elle exactement ? Indiquer uniquement que la lib en cours d'utilisation ne sait pas générer une miniature d'un webp ou qu'elle est incapable d'appliquer tous les filtres images sur ce format ?

Si on ne mentionne que les miniatures, la surprise sera la même quand les webmestres découvriront que image_alpha ou autre n'est pas supporté...

Bref, je n'ai pas souvenir qu'on ait déjà fait des choses comme ça pour les autres formats d'images (mais je ne fais pas partie de meubles, je suis peut-être passé à côté), donc je doute sur l'intérêt de le faire pour le webp.

> Car ma proposition est moins idéale mais beaucoup moins coûteuse Quelle est-elle exactement ? Indiquer uniquement que la lib en cours d'utilisation ne sait pas générer une miniature d'un webp ou qu'elle est incapable d'appliquer tous les filtres images sur ce format ? Si on ne mentionne que les miniatures, la surprise sera la même quand les webmestres découvriront que image_alpha ou autre n'est pas supporté... Bref, je n'ai pas souvenir qu'on ait déjà fait des choses comme ça pour les autres formats d'images (mais je ne fais pas partie de meubles, je suis peut-être passé à côté), donc je doute sur l'intérêt de le faire pour le webp.
Poster

Trouver le ou les tests les plus utiles et la formulation qui va bien.

Tester |image_alpha comme tu suggères en plus de |image_reduire, si c'est utile aussi (je sais pas), et produire un diagnostic utile dans la limite de ce qu'on sait.

Par exemple, avec une classe .attention et la voix de Macha Béranger :

« La librairie $gd_ou_convert_etc actuellement activée ne gère pas correctement les fichiers images webp. SPIP fera de son mieux pour produire les résultats attendus (balises et modeles documents + filtres |image_reduire, |image_alpha...), mais il se peut que le rendu soit incorrect dans certains cas. S'il est important pour vous d'utiliser les webp, vous pourriez essayer de voir si une autre librairie graphique les gère mieux sur votre hébergerment. »
(en substance)

Trouver le ou les tests les plus utiles et la formulation qui va bien. Tester `|image_alpha` comme tu suggères en plus de `|image_reduire`, si c'est utile aussi (je sais pas), et produire un diagnostic utile dans la limite de ce qu'on sait. Par exemple, avec une classe `.attention` et la voix de Macha Béranger : « La librairie $gd_ou_convert_etc actuellement activée ne gère pas correctement les fichiers images `webp`. SPIP fera de son mieux pour produire les résultats attendus (balises et modeles documents + filtres `|image_reduire`, `|image_alpha`...), mais il se peut que le rendu soit incorrect dans certains cas. S'il est important pour vous d'utiliser les webp, vous pourriez essayer de voir si une autre librairie graphique les gère mieux sur votre hébergerment. » (en substance)
Poster

Ou plus simplement (voix de Roger et ses humains):
« Cette librairie ne gère pas correctement les fichiers images webp. Si vous en utilisez, leur rendu pourra être incorrect. »

Ou plus simplement (voix de Roger et ses humains): « Cette librairie ne gère pas correctement les fichiers images `webp`. Si vous en utilisez, leur rendu pourra être incorrect. »
Owner

j'ai dit n'importe quoi plus haut : les filtres image de SPIP savent bien traiter correctement webp (si la lib sous-jacente utilisée le sait), my bad

j'ai dit n'importe quoi plus haut : les filtres image de SPIP savent bien traiter correctement webp (si la lib sous-jacente utilisée le sait), my bad
Poster

Si le test détecte que la librairie ne traite pas les webp, en plus d'être signalé sur la page de config, ce devrait être mémorisé dans une méta pour être utilisé là où c'est utile. Par exemple ça permettrait au plugin centre_image de ne pas intégrer le webp aux types d'images sur lesquelles il active sa petite croix de choix du focus. (cf spip-contrib-extensions/centre_image#8)

Si le test détecte que la librairie ne traite pas les webp, en plus d'être signalé sur la page de config, ce devrait être mémorisé dans une méta pour être utilisé là où c'est utile. Par exemple ça permettrait au plugin centre_image de ne pas intégrer le webp aux types d'images sur lesquelles il active sa petite croix de choix du focus. (cf https://git.spip.net/spip-contrib-extensions/centre_image/pulls/8)
Owner
ça existe déjà @JLuc https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L555 et https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L577
Owner

Donc le test des librairies d'image c'est "OK la librairie marche pour les formats qu'on supporte" ou "non elle ne supporte pas les formats dont on à besoin".

Moi j'avoue que c'était un peu flou concernant le support du webp, à moins de faire des tests soi-même ou d'aller pêcher l'info quelque part (articles de release ? commits ? doc pas toujours à jour ?...)

Du coup je plussois la proposition de @JLuc à ce sujet, mais en faisant hyper simple : si on a une liste prédéfinie de formats supportés, il serait bien utile de les afficher directement à l'endroit où on configure les traitements d'images.

Mais vraiment très simple, une simple liste d'extensions.

Rapide mockup :

> Donc le test des librairies d'image c'est "OK la librairie marche pour les formats qu'on supporte" ou "non elle ne supporte pas les formats dont on à besoin". Moi j'avoue que c'était un peu flou concernant le support du webp, à moins de faire des tests soi-même ou d'aller pêcher l'info quelque part (articles de release ? commits ? doc pas toujours à jour ?...) Du coup je plussois la proposition de @JLuc à ce sujet, mais en faisant hyper simple : si on a une liste prédéfinie de formats supportés, il serait bien utile de les afficher directement à l'endroit où on configure les traitements d'images. Mais vraiment très simple, une simple liste d'extensions. Rapide mockup : ![](https://git.spip.net/attachments/0436fa5e-2a3e-47b2-8e57-1b6d83ba0ebe)
Owner

oui mais sachant que
1/ on configure une des libs ci-dessus qui sera utilisée pour les mise à l'échelle
2/ tous les autres filtres images utilisent de toute façon gd2 et uniquement gd2

Donc si tu enchaines un |image_reduire{...}|image_recadre{...} ça ne marchera que si la lib que tu as sélectionné ET GD2 supportent webp

oui mais sachant que 1/ on configure une des libs ci-dessus qui sera utilisée pour les mise à l'échelle 2/ tous les autres filtres images utilisent de toute façon gd2 et uniquement gd2 Donc si tu enchaines un `|image_reduire{...}|image_recadre{...}` ça ne marchera que si la lib que tu as sélectionné ET GD2 supportent webp

1/ on configure une des libs ci-dessus qui sera utilisée pour les mise à l'échelle
2/ tous les autres filtres images utilisent de toute façon gd2 et uniquement gd2

Au passage, ça on en a parlé il y a quelques mois dans un autre ticket (pas réussi à retrouver pour l'instant), mais ce morceau d'interface n'est vraiment pas clair et explicite. Il faudrait à minima rajouter une phrase disclaimer dans un bloc "warning" : "/!\ Attention, ce choix ne concerne que la réduction de taille des images. Toutes les autres transformations (recadrage, couleur, etc) utilisées dans les squelettes nécessitent la bibliothèque GD2."

Car même les gens dans la commu, proches, ne se souviennent pas forcément de ça, alors les simples utilisateurices…

> 1/ on configure une des libs ci-dessus qui sera utilisée pour les mise à l'échelle > 2/ tous les autres filtres images utilisent de toute façon gd2 et uniquement gd2 Au passage, ça on en a parlé il y a quelques mois dans un autre ticket (pas réussi à retrouver pour l'instant), mais ce morceau d'interface n'est *vraiment* pas clair et explicite. Il faudrait à minima rajouter une phrase disclaimer dans un bloc "warning" : "/!\ Attention, ce choix ne concerne que la réduction de taille des images. Toutes les autres transformations (recadrage, couleur, etc) utilisées dans les squelettes nécessitent la bibliothèque GD2." Car même les gens dans la commu, proches, ne se souviennent pas forcément de ça, alors les simples utilisateurices…
Owner

Car même les gens dans la commu, proches, ne se souviennent pas forcément de ça

Moi j'oublie régulièrement :)

En complétant l'explication et en faisant court :

Veuillez sélectionner la meilleure méthode de fabrication des vignettes de réduction des images en cliquant sur l’image correspondante.

Tous les autres traitements utilisent la bibliothèque GD2.

ça ne marchera que si la lib que tu as sélectionné ET GD2 supportent webp

Pour l'indication des formats supportés ça complique un peu les tests mais ça reste jouable il me semble : tester à la fois GD2 + la lib choisie dans la config.

Ça indiquerait les formats qui sont garantis de fonctionner quelque soit la combinaison de filtres.

> Car même les gens dans la commu, proches, ne se souviennent pas forcément de ça Moi j'oublie régulièrement :) En complétant l'explication et en faisant court : Veuillez sélectionner la meilleure méthode <strike>de fabrication des vignettes</strike> **de réduction des images** en cliquant sur l’image correspondante. Tous les autres traitements utilisent la bibliothèque GD2. > ça ne marchera que si la lib que tu as sélectionné ET GD2 supportent webp Pour l'indication des formats supportés ça complique un peu les tests mais ça reste jouable il me semble : tester à la fois GD2 + la lib choisie dans la config. Ça indiquerait les formats qui sont garantis de fonctionner quelque soit la combinaison de filtres.
Poster

Il se pourrait que #CONFIG{formats_graphiques} soit l'information voulue.

<p>\#CONFIG{formats_graphiques} : [(#CONFIG{formats_graphiques})]</p>
<p>\#CONFIG{gd_format} : [(#CONFIG{gd_formats})]</p>
<p>Extensions acceptees en entree : #EVAL{implode (',', _image_extensions_acceptees_en_entree())}</p>
<p>Extensions acceptees en sortie : #EVAL{implode (',', _image_extensions_acceptees_en_sortie())}</p>
<p>Formats d'image acceptables : #EVAL{implode(',', formats_image_acceptables())}</p>

Apparemment il n'y a que la config formats_graphiques qui dépend de la glib choisie, les autres ne concernent que GD. Pourtant formats_graphiques est issu d'un calcul assez théorique et ne teste pas les réelles capacités de la glib choisie : https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/configurer_reducteur.php#L65 alors je me demande si ça suffit pour refléter les variations de configuration des librairies.

Il se pourrait que #CONFIG{formats_graphiques} soit l'information voulue. ``` <p>\#CONFIG{formats_graphiques} : [(#CONFIG{formats_graphiques})]</p> <p>\#CONFIG{gd_format} : [(#CONFIG{gd_formats})]</p> <p>Extensions acceptees en entree : #EVAL{implode (',', _image_extensions_acceptees_en_entree())}</p> <p>Extensions acceptees en sortie : #EVAL{implode (',', _image_extensions_acceptees_en_sortie())}</p> <p>Formats d'image acceptables : #EVAL{implode(',', formats_image_acceptables())}</p> ``` Apparemment il n'y a que la config `formats_graphiques` qui dépend de la glib choisie, les autres ne concernent que GD. Pourtant `formats_graphiques` est issu d'un calcul assez théorique et ne teste pas les réelles capacités de la glib choisie : https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/configurer_reducteur.php#L65 alors je me demande si ça suffit pour refléter les variations de configuration des librairies.
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.