Avec des brevets ou avec des royalties ? Désolé de pinailler, mais comme je sais que c'est un de tes sujets de prédilection, je crois que la précision a de l'importance...

Par exemple AVIF est bardé de brevets, mais avec des accords de licence sans royalties qui lient tous les membres de l'alliance AOM, et qui sont censés couvrir l'intégralité des brevets en question.

Un format d'image avec des brevets, c'était perdu d'avance.

Le public s'en fiche pas mal des brevets (ou des royalties), ce qu'il veut c'est un format universel, un format suffisamment qualitatif (le JPEG convient à la plupart des gens) qui permet d'envoyer sa photo à quiconque sans se poser de question, et dont on est sûr que le destinataire l'ouvrira sans problème... 'it just works!'

Nombreux ont été les formats meilleurs que le JPEG de base et qui ont fait un flop. Donc cette caractéristique d'universalité est indispensable pour remplacer JPEG... Les gens n'ont pas envie de gérer les conversions, les 'c'est quoi ton fichier? J'arrive pas à l'ouvrir!', etc. (cf. les HEIF qui, dès qu'on sort de l'environnement Apple et des logiciels Apple, sont galère à gérer/ouvrir/convertir)

Alors oui les brevets et royalties ça peut faire suer les éditeurs (voire simplement pour des raisons politiques, ne pas trop soutenir/payer pour un format d'un concurrent féroce sur un autre marché), mais si on veut imposer un format tel que le JPEG XL, l'absence de déploiement massif ET rétroactif (ce que peu feront, mais il me paraît indispensable qu'Apple, Google et Microsoft rajoutent la compatibilité JPEG XL sur leurs systèmes antérieurs respectifs histoire d'élargir d'un coup la base d'utilisateurs et ne pas devoir attendre qu'elle se développe lentement de presque rien) est un sérieux frein ; le même type de frein qui ont tué les formats précédents... Et tant que ça sera comme ça, JPEG aura encore de beaux jours devant lui, et c'est dommage quand on voit les qualités du JPEG XL...

Par rapport au royalties de HEIF... que penses-tu de la page Wikipedia du format ?

HEIC: HEVC in HEIF
High Efficiency Video Coding (HEVC, ITU-T H.265)[13] is an encoding format for graphic data, first standardized in 2013. It is the primarily used and implied default codec for HEIF as specified in the normative Annex B to ISO/IEC 23008-12 HEVC Image File Format.

While not introduced formally in the standard, the acronym HEIC (High-Efficiency Image Codec) is used as a brand and in the MIME subtypes image/heic and image/heic-sequence. If the content conforms to certain HEVC profiles, more specific brands can be used: HEIX for Main 10 of HEVC, HEIM for (Multiview) Main profile and HEIS for (Scalable) Main (10) profile of L-HEVC.

A HEIC photo takes up about half the space of an equivalent quality JPEG file.[14] The initial HEIF specification already defined the means of storing HEVC-encoded intra images (i-frames) and HEVC-encoded image sequences in which inter prediction is applied in a constrained manner.

HEVC image players are required to support rectangular cropping and rotation by one, two and three quarter-turns. The primary use case for the mandatory support for rotation by 90 degrees is for images where the camera orientation is incorrectly detected or inferred. The rotation requirement makes it possible to manually adjust the orientation of a still image or an image sequence without needing to re-encode it. Cropping enables the image to be re-framed without re-encoding. The HEVC file format also includes the option to store pre-derived images.[15]

Samples in image sequence tracks must be either intra-coded images or inter-picture predicted images with reference to only intra-coded images. These constraints of inter-picture prediction reduce the decoding latency for accessing any particular image within a HEVC image sequence track.

The .heic and .heics file name extensions are conventionally used for HEVC-coded HEIF files.[16] Apple products, for instance,[17] will only produce files with these extensions, which indicate clearly that the data went through HEVC encoding.[2]

AVIF: AV1 in HEIF
This section is about AV1 and AVIF. For AVI, see Audio Video Interleave.
Main article: AVIF

AV1 is a video encoding format that is intended to be royalty free developed by the Alliance for Open Media (AOMedia). AV1 Image File Format (AVIF) is an image format based on this codec.[18]

The registered MIME type is image/avif for both still images and image sequences, and .avif is the file name extension.[19]

Il semblerait que strictement le container HEIF soit sans royalties, puisque même AVIF l'utilise. Par contre ce n'est pas du tout le cas de HEIC puisqu'il s'agit de l'HEVC.

Oui, le conteneur HEIF est sans royalties et est utilisé par de nombreux formats d'image :
- JPEG 2000
- JPEG XR
- JPEG XS
- WXAM
- SharpP
- AVCI (Codec AVC dans HEIF)
- HEIC (Codec HEVC dans HEIF)
- AVIF (Codec AV1 dans HEIF)
...

Ce qui demande de payer des royalties, c'est le codec HEVC utilisé avec HEIF. Normalement son nom est HEIC, mais comme Apple l'a appelé HEIF, aujourd'hui quand on parle de HEIF, c'est avec le codec HEVC et il est nécessaire de payer les royalties pour HEVC.

J'ai trouvé une source intéressante pour comparer les formats d'image sans perte

La différence de compression entre les formats me semble faible.

(cliquez sur la miniature ci-dessous - le document est au format PDF)


J'ai mis leurs données dans un tableau pour faire une moyenne des 3 types d'images analysés et classer les formats d'image en fonction de leur efficacité en mode compression sans perte de qualité.
AVIF et HEIC, les deux formats basés sur des codecs vidéos s'en sortent très mal.



Note pour WebP : Si la compression avec perte de WebP est bien issue du codage des images clé des flux vidéos VP8, la compression sans perte est complétement indépendante, qui est intégré dans le même format. On a en fait un format d'image qui embarque deux technologies : la compassion du codec vidéo VP8 pour la compression avec perte et un autre, qui est performant pour la compression sans perte. Pour AVIF et HEIC, c'est respectivement AV1 et HEVC qui est utilisé aussi bien pour la compression avec perte et sans perte.

Un an plus tard, toujours pas de changement de position de Google sur JPEG XL pour sa prise en charge dans Chrome / Chromium / Android : Google bloque la prise en charge de JPEG XL (aujourd'hui supporté uniquement par Safari ; Firefox a annoncé le prendre en charge si Google le prend en charge)

Un bug Chromium a été ré-ouvert depuis quelques semaines pour demander à Google de revoir sa positon sur JPEG XL, avec un argument fort : Apple va prendre en jarge JPEG XL dans iOS 17 et la prochaine version de macOS. Pas avec un flag expérimental, mais activé par défaut (cf Safari 17 Beta Release Notes).

Il reste à observer la position de Firefox qui est aujourd'hui neutre sur le sujet.

Personnellement, je suis convaincu que JPEG XL a des atouts pour réussir la transition et remplacer complétement les vieux formats JPEG / PNG / GIF, tache que WebP ou AVIF ne pourront pas réussir, en tant que format uniquement Web.

Oui, les performances de compression de JPEG XL sont proches de AVIF, mais pour moi, il faut reconsidérer la question AVIF : Ce format (toujours pas pris en charge par Microsoft Edge) peut être sauté et les sites web passant alors directement de WebP à JPEG XL.

Je vois les choses de la sorte pour les formats d'image Web :
- 1ʳᵉ génération : JPEG, PNG, GIF
- 2ᵉ génération : WebP
- 3ᵉ génération : AVIF, JPEG XL

On a deux formats de 3ᵉ génération et JPEG XL est meilleur que AVIF, alors pourquoi ne pas partir sur lui ?