Traitement des webp

Un passage global sur les occurrences de code spécifiant en dur l'une ou l'autre des extension de fichiers images relève de grandes disparités non documentées.

Il faudrait peut-être faire comme dans les squelettes et se baser uniquement sur le media image non ?

@b_b a ajouté le label bug

@b_b a ajouté ce ticket au jalon spip-4.2

Ce qui donne :

$typdoc = ($image ? "docs.media='image'" : "docs.media!='image'")

La regexp ([^.]\bgif\b.*\bpng\b|\bpng\b.*[^.]\bgif\b) fournit une liste des usages de gif et png dans la même ligne (il semble y avoir d'autres cas à traiter).

Dans le plugins-dist/medias il y a, en plus de dissocier_documents cité plus haut :

action/desordonner_liens_documents.php
76 $typdoc = sql_in('docs.extension', ['gif', 'jpg', 'png'], $image ? '' : 'NOT');

formulaires/editer_document.php 
69 if (in_array($valeurs['extension'], ['jpg', 'gif', 'png', 'svg'])) {

formulaires/illustrer_document.php 
20 if (!$valeurs /*OR in_array($valeurs['extension'],array('jpg','gif','png'))*/) {

modeles/document_case.html
17 [(#EXTENSION|match{gif|png|jpg|svg}|oui) #SET{id,#ID_VIGNETTE|?{#ID_VIGNETTE,#ID_DOCUMENT}}

squelettes/contenu/document.html
23 [(#EXTENSION|match{gif|png|jpg}|oui)
26 [(#EXTENSION|match{gif|png|jpg}|non)

medias_autoriser.php  (2 usages found)
83 // lire : gif jpg png), sauf bug, ou document distant
85 in_array($document['extension'], ['gif', 'jpg', 'png'])

A priori il faut corriger tous ces cas. Et a priori on peut dans tous ces cas utiliser 'media' ou #MEDIA pour corriger. Et il faudrait voir aussi dans les autres parties de la dist.

Voir spip!5987 (comment 187036) par contre je ne sais pas quelle serait la meilleure piste pour corriger aussi dans les squelettes.

À noter, la rotation d'une image webp affiche une erreur et on retrouve ça dans les logs :

2024-07-09 18:46:01 127.0.0.1 (pid 91018) :Pub:info: rotation 90 ../IMG/webp/framboise.webp : ../IMG/webp/framboise-r90.webp 
2024-07-09 18:46:01 127.0.0.1 (pid 91018) :Pub:info: Since spip 5.0: spip_log('message') function is deprecated ; use spip_logger(). Example: spip_logger()->info('message'). in /home/bb/sites/trunk/plugins-dist/spip/medias/action/tourner.php on line 76
2024-07-09 18:46:01 127.0.0.1 (pid 91018) :Pub:ERREUR: filtre image image_oriente_selon_exif[oriente_selon_exif] sur ../IMG/webp/framboise.webp
2024-07-09 18:46:01 127.0.0.1 (pid 91018) :Pub:ERREUR: filtre image image_rotation[rot-90] sur ../IMG/webp/framboise.webp

Mmmh oui, pourquoi utiliser à plein d'endroits une liste d'extensions, alors qu'on a le type de média depuis toujours ?

Il me semble que les seuls cas où les extensions sont pertinentes, c'est quand c'est un test pour faire des traitements d'images ensuite (recadre etc), car là il faut que ce soit des formats précis reconnus par GD2. Mais tous les autres cas devraient être avec le type général de média à priori.

Là dedans il y a notamment du code mort car les images en mode image ou document ça n'existe plus, donc ça simplifiera encore plus

Là dedans il y a notamment du code mort car les images en mode image ou document ça n'existe plus

Ça, ça se discute... Le code avec un define pour est là. C'est super pratique pour distinguer ce qui est en galerie en bas de la page (Portfolio), et ce qui est éventuellement des illustrations non utilisées dans l'article, mais disponibles pour plus tard.

Je sais bien qu'on a le critère {!vu}, mais il est moins clair car plus difficilement explicable et consultable dans l'admin.

Plus le temps passe, plus je trouve que cette évolution était une erreur. Erreur basée sur la différence de comportement de <docNNN> selon que c'était ou non dans le portfolio. Alors qu'il y a l'autre usage de distinguer contenu et gallerie.

@JLuc a fait référence à ce ticket depuis !4961 Pour #4958 - gérer aussi les webp

Je trouve qu'il manque surtout une catégorisation "image web" globale. Pourquoi pas la gérer dans le core, ou au pire dans médias ?

Chaque plugin gère ça à sa sauce, avec une liste d'extensions ou de mimetypes plus ou moins heureuses, et quand il y a un ajout, c'est à patcher un peu partout.

Exemple : https://git.spip.net/spip-contrib-extensions/verifier/src/commit/852a5006039460bc30af13258004eb59d310e5d2/verifier/fichiers.php#L169

Paf, il manque webp.

Je sais bien qu'on en ajoute pas tous les jours, mais si on ajoute l'avif ou le jpeg2000 ou je sais pas quoi un de ces jours il faudra encore repasser partout.

(oh, et regardez qui vient troller : « Coucou, je suis le svg, moi aussi je suis une image web :p »)

Je sais que ça peut paraître exotique mais media='image' ça s'applique aussi aux .tiff, .bmp et autres joyeusetés, et que les rédacteurs et trices sont très créatifs à ce niveau là.

(sans parler des jpeg en quadrichromie ou des exif qui inversent les couleurs mais là c'est un cas désespéré)

Comme dans les fonctions de traitement image on avait le même genre de brin, j'avais regroupé tous les tests dans des fonctions

_image_extensions_acceptees_en_entree() https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L554
_image_extensions_acceptees_en_sortie() https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_images_lib_mini.php#L577

Toute la difficulté c'est qu'on plein de notion de "c'est une image"

ça s'affiche dans une balise <img../> sur une page web
ça peut se traiter via des filtres images
c'est intrinsèquement une image mais il faut possiblement un logiciel dédié pour l'afficher (c'est le cas de media='image')

On a aussi la globale $formats_logos https://git.spip.net/spip/spip/src/branch/master/ecrire/inc_version.php#L373

qui in fine est la plupart du temps ce qu'on cherche (et on devrait l'encapsuler dans une fonction adhoc pour éviter de continuer à utiliser une globale, et l'utiliser en entrée de _image_extensions_acceptees_en_entree() au lieu du tableau par défaut

Je viens d'envoyer une proposition en ce sens spip!5987 (merged)

Je n'y ai pour l'instant pas appliqué les renommages préconisés par @rastapopoulos à voir si ça peut se faire sans trop de casse.

@cerdic a fait référence à ce ticket depuis un commentaire de !4961 Pour #4958 - gérer aussi les webp

Ouais j'allais dire un peu la même chose : ya plusieurs (sous) groupes

toutes les images
les images web = affichables en HTML (ce qui comprend AVIF, WEBP et SVG)
les images transformables par la lib GD2… (pas SVG, mais AVIF oui à partir de PHP 8.1 par ex)

Vu que dans le lot ya le sous-groupe GD, ça concerne directement le core (et un autre plugin dist) donc à priori les fonctions d'API devraient être dans le core plutôt que dans Médias. Et pour pas disperser, si celle pour GD est déjà dans le core, alors si yen a une autre ajoutée pour "les images web affichables en HTML", c'est mieux au même endroit, par cohérence. Et si on peut en plus uniformiser les noms de fonctions… (quitte à mapper l'ancienne sur une nouvelle)

image_extensions_logos()
image_extensions_gd_entree()
image_extensions_gd_sortie()
image_extensions_web()

Je plussoie dans le sens de @rastapopoulos (et @nicod_).

Attention même pour les images affichable en HTML, se pose la question de ce qu'on accepte ou pas, et si on rend extensible (via pipeline par ex).

Allez, pour le fun, il y a JPEG-XL aussi qui arrive très sérieusement :)

https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going

Mais pas (ou pas encore) supporté par GD.

@JLuc a fait référence à ce ticket depuis un commentaire de spip-contrib-squelettes/aoto#1 Doublons dans articles du squelette Aoto

Maintenant que @cerdic a posé une roadmap, ça serait pas mal de revoir le titre du ticket pour plus de clarté non ?

Une roadmap ? tu aurais le lien ?

Je parlais de la roadmap pour ce ticket ^^ Une todolist si tu préfères :p

changed title from Oubli des webp to Traitement des webp

changed the description

Traitement des webp

Designs

Éléments enfants ...

Activité