J'ai fait un nouveau commentaire cet après-midi sur le bug Chromium qui demande sa prise en charge : https://issues.chromium.org/issues/40270698
J'espère que Google va changer d'avis.

Dans les réponses qui sont arrivées juste après, ça parle de surface d'attaque. Le non-support de JPEG XL viendrait de la volonté de limiter les surfaces d'attaque. C'est vrai que plus il y a de codec, plus il y a de potentielles failles dans l'implémentation.
On l'a vu avec webp qui a deux implémentations, une avec perte et une sans perte, les algo étant complètement différents, cela fait deux surfaces d'attaques sur un seul format d'image...

Maintenant on a aussi des solutions pour limiter ces risques, les outils d'analyses de code sont de plus en plus poussé et on a des langages qui permettent d'écrire du code performant et sécurisé comme le Rust. La solution pourrait venir de ce dernier, dans les commentaires ils parlent du projet jxl-rs, un décodeur JPEG XL implémenté en Rust.

    Good news! The jxl-rs project (a safe and fast JPEG XL decoder implementation in Rust) is progressing well. We are currently on track to deliver the following milestones:

        End of February 2025: Initial decoding capabilities and a preliminary API.
        April 2025: Aiming for a conforming decoder implementation, fully compliant with the JPEG XL specification.
        July 2025: Critical code paths fully SIMDified and with a finalized API. This anticipated timeline should allow jxl-rs to be ready for browser integration in alignment with Interop 2025 goals.

Les choses vont peut-être bouger d'ici à cet été.

Le support de tous ces codecs par les navigateurs c'est très bien, mais sait-on combien de sites webs dans le monde les utilisent vraiment ?
je vois la 10enes d'alternants au marketing chez nous qui ne connaissent rien d'autre que ce que leur pond leur application Adobe ou Canva, à part jpeg et png pour avoir un fond transparent, ils ne connaissent strictement rien. Avec des bac+3 a +5.
J'en ai une qui a découvert l'existence de webp en utilisant l'outil d'analyse de site web de google, qui lui a suggéré d'utiliser ce format pour réduire la taille des fichiers jpeg en qualité 8 ou 10 qu'elle utilisait sur ses pages web.

Tous les sites qui vendent des trucs ET dont les gens qui s'en occupent sont un peu consciencieux, s'ils peuvent ils le font. Parfois c'est chiant en terme de dev, mais bon, pour que google vois ton site d'un bon œil, faut y passer meme si personne ne vois la difference a la fin.

Tous les navigateurs web devraient prendre en charge JPEG-XL en 2026 avec l'implémentation en Rust.

La question que je me demande : Est-ce que cela met en danger AVIF et qu'il pourrait être retiré des navigateurs ou c'est trop tard et les navigateurs auront AVIF et JPEG-XL ?

C'est uniquement pour la vidéo SVT-AV1, non ?

Sur ce sujet, c'est pour parler des images AVIF.

Pour les images AVIF, on utilise systématiquement le codeur AOM, non ?

MaxLebled, je ne sais pas si tu as fait des tests, mais c'est normal qu'on obtienne des fichiers plus petits quand on encode une image (originellement en 8 bit / canal) en 10 ou 12 bit / canal ?

J'ai lu que pour la vidéo "Il est plus sûr de faire un codage final 10 bits que 8 bits, même si vous convertissez une vidéo source 8 bits en un résultat 10 bits. Il y aura presque toujours moins d'anomalies avec un codage final 10 bits. Le codec passe à une précision de 10 bits, ce qui signifie que les erreurs d'arrondi dans le codec seront moins visibles / non visibles."

Je n'ai jamais fait de tests concernant ça moi-même pour la photo, mais a priori, oui, en effet, alors même que cela semble complètement contre-intuitif, le fait d'utiliser le mode 10-bit permettrait, selon les dires de beaucoup, de baisser la taille à qualité équivalente par rapport au mode 8-bit, et ce même si la source est en 8-bit.

https://old.reddit.com/r/handbrake/comments/13r4apr/why_do_people_say_10bit_files_are_smaller_than/

Et un PDF venant d'Ateme : https://yukisubs.wordpress.com/wp-content/uploads/2016/10/why_does_10bit_save_bandwidth_-_ateme.pdf (répliqué en pièce jointe, au cas où)

Pourquoi un encodeur AVC/H.264 10 bits est-il plus performant qu'un 8 bits ?

Lors de l'encodage avec l'outil 10 bits, le processus de compression est effectué avec une précision d'au moins 10 bits, contre seulement 8 bits dans le cas contraire. au moins 10 bits, contre seulement 8 bits autrement. Il y a donc moins d'erreurs de troncature, en particulier dans l'étape de compensation du mouvement, ce qui augmente l'efficacité de la compression de compensation de mouvement, ce qui augmente l'efficacité des outils de compression. Par conséquent, il est moins nécessaire de quantifier pour obtenir une
de quantifier pour atteindre un débit binaire donné. Le résultat net est une meilleure qualité pour le même débit binaire ou, inversement, un débit binaire moindre pour la même qualité : entre 5% et 20% sur des sources typiques.

La spec AV1 stipule que le décodage matériel 10-bit fait partie du profil principal. Mais alors pourquoi YouTube font-ils quand même du 8-bit ? (Trop de bugs de décodage matériel dans la nature ?)

Pour ce qui est du mode 12-bit, par contre, c'est facultatif, et je ne m'y aventurerais personnellement pas.

Issue ouverte pour que GIMP rajoute cet encodeur AVIF : https://gitlab.gnome.org/GNOME/gimp/-/issues/12961

Bien vu !

Malheureusement, c'est comme le WebP ; ce qui fait que ce format est principalement délaissé (et souvent haï par les utilisateurs lambda), c'est le manque d'intégration en dehors des navigateurs...