La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: vivien le 20 février 2021 à 10:38:24
-
AVIF, AV1 Image File Format est un format d'image comme jpeg, mais qui permet une qualité très nettement supérieure pour un poids identique ou un poids plus faible pour une qualité identique.
(https://lafibre.info/images/format/webp_avif_support.webp)
Navigateurs supportant le format d'image AVIF :
- Google Chrome pour Windows, macOS, Linux depuis la version 85, publiée le 25 août 2020
- Vivaldi depuis la version 3.3, publiée le 7 septembre 2020 (image fixe uniquement)
- Opera depuis la version 71, publiée le 15 septembre 2020
- Google Chrome pour Android depuis la version 89, publiée le 2 mars 2021
- Samsung Internet depuis la version 14, publiée le 16 avril 2021
- Mozilla Firefox (Windows, macOS, Linux et Android) depuis la version 93, publiée le 5 octobre 2021. Cf Firefox 93 release notes (https://www.mozilla.org/en-US/firefox/93.0/releasenotes/).
- Vivaldi depuis la version 4.2, publiée le 15 septembre 2021 (ajout support image animée)
- Mozilla Firefox ESR mis à jour avec la version Firefox 102.3, publiée le 20 septembre 2022
- iOS : Safari / Chrome / Firefox / MS Edge depuis la version iOS 16, publié le 12 septembre 2022
- iPadOS : Safari / Chrome / Firefox / MS Edge depuis la version iPadOS 16, publié le 12 septembre 2022
- Safari depuis la version macOS 13 Ventura, publié en octobre 2022
- Microsoft Edge : pas de support d'AVIF
Système d'exploitation supportant le format d'image AVIF :
- Microsoft Windows 10 depuis la version 19H1, publiée le 21 mai 2019
- Linux à partir du second semestre 2020 (en fonction des distributions)
- Android depuis la version 12, publiée le 4 octobre 2021
- macOS depuis la version 13, publié en octobre 2022
-
Voici un site qui permet de comparer la qualité des différents formats d'image (https://jakearchibald.com/2020/avif-has-landed/demos/compare/?show=f1&img=/c/f1-match-ff75e344.jpg).
Cliquer sur les images pour les voir en grand et voir la forte dégradation en Jpeg et WebP.
Image JPEG 1920x1080 de 23 129 octets :
(https://lafibre.info/images/format/202102_image_test.jpg)
Image WEBP 1920x1080 de 22 148 octets :
(https://lafibre.info/images/format/202102_image_test.webp)
Image AVIF 1920x1080 de 18 180 octets : (si l'image ci-dessous ne s'affiche pas, c'est que votre navigateur web ne supporte pas le format AVIF)
(https://lafibre.info/images/format/202102_image_test.avif)
-
Je vois peu très d'informations sur HiFiC. Cela semble plus au stade de la recherche que du protocole implémenté dans les navigateurs et les systèmes d'exploitation.
Il serait intéressant d'avoir une comparaison avec AVIF.
-
En ce qui concerne les applications photos par défaut sur smartphone, elles enregistrent en jpeg (je fais référence aux Xiaomi) sans laisser le choix. Quelles applications photos tierces sur android supportent l'enregistrement en AVIF ?
Un autre point qui n'a pas été évoquée c'est le support dans les langages de développement comme Php (la bibliothèque GD dans Php dispose du support de webp mais d'autres formats modernes)...
-
AVIF va arriver avec Android 12, donc pour l'instant aucune app de photo ne le proposent.
Comme toujours les nouvelles techno / codec mettent du temps à être disponible partout.
-
Ce passage de jpeg à autre chose de plus performant me rappelle vaguement IPv6 dans un autre domaine (qui reste malgré tout informatique). Tout le monde en parle depuis des années, tout le monde sait que ce ne serait pas du luxe de passer à autre chose de plus performant, mais dans 30 ans on sera encore en jpeg ;D ;D ;D
-
Ce n'est pas comparable.
IPv6 il n'y a aucun gain immédiat, cela ajoute de la maintenance en plus de l'IPv4 qui doit être maintenu tant que l'IPv6 ne sera pas assez déployé par tout le monde.
Les codec vidéo ou d'image, à l'inverse il y a un gain en efficacité qui est immédiat pour tout ce qui le supporte. Par contre il y a quand même le problème de maintenir deux formats (ou plus) tant que tout le monde n'est pas compatible. Par exemple pour Youtube, si 50% des usagés sont compatible avec un format qui compresse mieux la vidéo, cela fait déjà une différence significative sur l'utilisation de la bande passante et la charge réseau des serveurs.
Si on regarde le domaine de la vidéo, VP9 et H.265 ont déjà en grande majorité remplacé le H.264.
HEIF a déjà remplacé jpeg pour les photos prises par les iPhone. Webp a déjà remplacé en partie certaines images sur le web. AVIF suivra donc cette tendance.
-
J'attends de voir. JPEG suffit depuis 30 ans à la quasi totalité des personnes qui prennent une photo pour la regarder, maintenant, sur un écran de 5" (et avant sur un 10x15 issue d'une imprimante jet d'encre) et pour les autres il y a le RAW et le post-traitement.
Le format iPhone c'est bien, mais c'est illisible par beaucoup d'appareil. J'ai repassé le mien en JPEG par défaut pour être sur que mes fournisseurs/clients reçoivent bien les photos que j'envoie.
-
AVIF pourrait arriver très rapidement en moins d'un an : les navigateurs web sont régulièrement mis à jour et il y a relativement peu de personnes avec un navigateur obsolète. Il faut par contre que Apple accepte de supporter AVIF et ça cela peut prendre des années :-[. Apple va a reculons pour certaines technologies comme le VP8 et le VP9, supporté dans des cas bien précis, cf Support du codec VP9 chez Apple (https://lafibre.info/tv-numerique-hd-3d/support-du-vp9-chez-apple/).
IPv6, cela ne peut pas être mis en place par une mise à jour uniquement du navigateur : il faut toute la chaîne de compatible, le navigateur, le système d'exploitation, le réseau,les transitaires, l’hébergeur, le serveur et le logiciel serveur plus le logiciel utilisé et le DNS.
Le rapport de l'Arcep sur IPv6 expliquait que le problème était que Microsoft n'avait pas prévu de proposer IPv6 pour Windows 95/98/Me le système d’exploitation populaire de l’époque (alors qu'IPv6 est disponible via un pack logiciel avec Windows NT 4.0 et Windows 2000 Pro la nouvelle branche de Windows qui aboutira à Windows XP). Depuis les années sont passées, on est passé d'IPv6 ready avec Windows NT, Windows 2000 et Windows XP à IPv6 activé par défaut avec Windows Vista et plus récent. Aujourd'hui la migration des système d'exploitation peut être considérée comme terminée (>98% des internautes ont IPv6 activé sur leur système d'exploitation), mais pas le reste de la chaîne n'a pas suivit. Coucou SFR sur le fixe et Free sur le mobile.
-
Je me souviens du JPEG2000 , en 2000. 21 ans plus tard, on est toujours au JPEG.
J'attends de voir ...
Quand tous les appareils photos numériques et tous les téléphones feront du AVIF (et par défaut hein, s'agit pas de régler quelque chose pour le commun des mortels), alors on aura peut-être une chance, sinon ca va rester très marginal d'utilisation.
-
Ben Apple avec le HEIC c'est déjà comme ça il me semble
-
Je me souviens du JPEG2000 , en 2000. 21 ans plus tard, on est toujours au JPEG.
JPEG2000 a été reconnu par l'ISO en mai 2015, c'est là le début de sa vraie vie. Je viens de le rajouter dans la liste des format dans mon premier message.
JPEG 2000, fichiers en .jp2 (part1) ou .jpx (part2 datant de 2004) est reconnu par l'ISO / CEI et l'UIT-T sous le code ISO/IEC CD 15444 en 2015. Le JPEG 2000 permet une légère augmentation des performances de compression par rapport à JPEG (+20%, il est clairement moins bon que WebP, HEIF et AVIF).
Le principal avantage offert par JPEG 2000 est le fait que le flux codé après compression est de nature évolutive, ce qui signifie qu'il peut être décodé de plusieurs façons. En tronquant le flux codé en tout point, on peut obtenir une représentation de l'image à une résolution inférieure, sans avoir a le recompresser.
Cependant, en raison de cette flexibilité, JPEG 2000 nécessite des codecs qui sont complexes et exigeants en termes de calcul (certains logiciels utilisent le GPU pour accélérer la compression en JPEG 2000). Ce codec n'est donc pas adapté pour les appareils photos.
JPEG 2000 fournit à la fois une compression sans perte (comme le PNG) et avec perte (comme le JPEG).
JPEG 2000 n'est pas pris en charge par les navigateurs, sauf Safari. Je pari sur le fait que cela ne va pas évoluer, seulement 20% de gain par rapport au JPEG d'origine, c'est faible pour en faire une nouvelle référence sur Internet, surtout qu'il est bien moins bon que les nouveaux formats.
Les bonnes applications pour JPEG 2000 sont les grandes images, les images avec des bords à faible contraste - par exemple, les images médicales. JPEG2000 est utilisé dans les archives, c'est vraiment étonnant.
Je copie / colle la partie de Wikipédia traitant du positionnement de JPEG 2000 (https://fr.wikipedia.org/wiki/JPEG_2000) :
Malgré d’excellentes caractéristiques et performances pour le codage d'images numériques ainsi qu'un usage exclusif depuis 2005 comme codec pour la vidéo dans le cinéma numérique (Digital Cinema Package ou DCP), JPEG 2000 peine à se développer.
Différentes raisons sont évoquées, dont :
- JPEG 2000 n'est pas pris en compte par les navigateurs - hormis Safari et la plupart des navigateurs sous Linux ;
- JPEG 2000 est incompatible avec le format JPEG ;
- Il est considéré comme complexe à mettre en œuvre
- L’encodage de fichiers JPEG 2000 nécessite un processeur intensif, ce qui peut surcharger les serveurs et ralentir les choses.
L'usage du standard JPEG 2000, format ouvert se déploie progressivement:
- Le PDF/A-2, une des normes PDF pour l'archivage à long terme, basé sur la norme ISO 32000-1, accepte la compression JPEG2000
- DICOM, un standard international pour la gestion informatique des données issues de l'imagerie médicale intègre JPEG 2000 depuis 2004
- L’IGN (Institut national de l’information géographique et forestière, France) fournit depuis 2015, les fichiers d’images au format JPEG 2000
- Il est intégré aux recommandations concernant les fichiers de préservation pour la numérisation d'enregistrements audio et vidéo et de films cinématographiques au Canada
- Plusieurs bibliothèques nationales ont intégré ce format à leurs recommandations (Bibliothèque du Congrès (USA), British Library (UK), Bibliothèque royale (Pays-Bas), etc. ); la Bnf a retenu pour les formats de fichier image depuis 2014, le format JPEG2000 issu des normes ISO 15444-1 et 15444-2 et leurs correctifs et compléments
La partie vidéo, Motion JPEG 2000 (extension .mj2 ou .mjp2) incluant également du son basé sur le format MP4/QuickTime est définit par la RFC 3745 mais a peu de chance d'être utilisé. Contrairement à MPEG, MJ2 n'implémente pas le codage inter-trame : chaque trame est codée indépendamment en utilisant JPEG 2000. Cela permet de commencer une vidéo à n'importe quel point, alors que en MPEG-2, il faut avoir une image de référence (image i) pour décoder (c'est le cas dans les autres codecs vidéos performants). Motion JPEG 2000 est donc très gourmand en bande passante, bien plus que le MPEG-2.
Motion JPEG 2000 est donc une évolution de Motion JPEG (vidéo constituée d'images JPEG) qui est principalement utilisé pour les images de vidéo surveillance avec des besoins de très faible latence - la RATP utilisait du Motion JPEG, je ne sais pas si cela a évolué :
(https://lafibre.info/images/presse/200210_stage_RATP_08.jpg)
-
Ben Apple avec le HEIC c'est déjà comme ça il me semble
Il y a désormais des appareils photos Canon et Sony qui prennent des photos en HEIF.
J'attends de voir. JPEG suffit depuis 30 ans à la quasi totalité des personnes qui prennent une photo pour la regarder, maintenant, sur un écran de 5" (et avant sur un 10x15 issue d'une imprimante jet d'encre) et pour les autres il y a le RAW et le post-traitement.
Le problème du RAW c'est qu'il n'y a pas de standard.
-
Quand je dis que pour les autres il y a RAW et le post-traitement, je parle des photographes bien entendu.
Le problème qui a été soulevé un peu plus haut c'est qu'Apple va vouloir promouvoir son format HEIF alors que le reste d'une partie du monde va vouloir passer à AVIF. Une partie non négligeable des appareils va faire un truc non lisible par l'autre partie non négligeable, et inversement, et au final il restera le JPEG qui est lisible par tous.
D'autant que la différence entre un JPEG de bonne qualité et un AVIF ou un HEIC va se voir sur un zoom relativement élevé, pas sur un smartphone ou sur une tablette. Et pour compenser ces problèmes de compression à la prise de vue, la solution palliative trouvée par les fabricants n'a t-elle pas été d'augmenter la résolution (et la taille ou la quantité pour certains) des capteurs photos ?
Mon iPhone prend des JPEG à 2+ Mo par photo ce qui me permet de zoomer largement assez pour l'utilisation sans pertes monumentale de qualité et mon vieil APN (FZ1000 de 2015) sait prendre des photos en JPEG de 10+ Mo, ce qui donne de quoi faire des posters géants sans pixellisation.
A quoi va servir AVIF dans ces cas là ? Limiter la taille des images tout en gardant la même qualité ? A l’heure ou les espaces de stockage ne coûtent plus rien et sont quasiment illimités je n'en vois pas vraiment l'utilité.
Mais bon, je suis un vieux qui n'aime pas le changement ;D ;D ;D
-
Le problème du RAW c'est qu'il n'y a pas de standard.
Il y a le DNG qui s’en rapproche.
-
A quoi va servir AVIF dans ces cas là ? Limiter la taille des images tout en gardant la même qualité ? A l’heure ou les espaces de stockage ne coûtent plus rien et son quasiment illimité je n'en vois pas vraiment l'utilité.
Mais bon, je suis un vieux qui n'aime pas le changement ;D ;D ;D
Il me semble que les espaces de stockage et la bande passante sont loin d'être illimités... Sinon on n'aurait pas toutes ces compressions automatiques un peu moches sur whatsapp et consorts. Et nombreux sont les serveurs mails qui rejettent des messages entrants faisant plus d'une dizaine de Mo.
Plus généralement c'est un principe d'économie global, car le stockage et la transmission de données numériques consomment des ressources qui sont bien réelles.
Mais il est vrai que l'on pourrait considérer que la problématique de l'image est secondaire à celle de la vidéo, compte-tenu des volumes de données mis en jeu. Quoiqu'ici, autant pour le HEIF que l'AVIF, on fait bien une pierre deux coups puisque ce sont des algorithmes utilisés pour la compression des keyframes d'une vidéo.
Il y a le DNG qui s’en rapproche.
C'est vrai, c'est intéressant - je ne connaissais pas trop ce format, qui apparemment se rapproche du TIFF. En tout cas je ne l'ai jamais rencontré dans un contexte "industriel".
-
C'est vrai, c'est intéressant - je ne connaissais pas trop ce format, qui apparemment se rapproche du TIFF. En tout cas je ne l'ai jamais rencontré dans un contexte "industriel".
Certains Leica et iPhone récents de mémoire
https://en.wikipedia.org/wiki/Digital_Negative
-
Je comprends mal pourquoi Apple, qui est membre de l'Alliance for Open Media, le consortium à but non lucratif qui pousse le format vidéo AV1 qui a la particularité d'être ouvert, gratuit et performant pousse clairement H.265/HEVC dans ses produits.
Cela fait une séparation qui rend plus difficilement interopérable les produits Apple et conçus pour Apple avec le reste de l'industrie.
Vu le retard dans l'implémentation des protocoles ouvert (VP8, VP9 et AV1 ne sont toujours pas disponibles sur Safari que ce soit sur MacOS ou iOS si on exclut les quelques exceptions prés où cela fonctionne)
C'est volontaire ?
Je pense que oui et c'est bien triste de la part d'Apple de provoquer et entretenir des divisions de format de fichiers.
-
- 2019 : AVIF (AV1 Image File Format) est un format d'image qui utilise l'algorithme de compression pour les images clés de l'AV1.Il commence à être supporté par quelques navigateurs : Chrome 85, Firefox 86, Opera 71. Il est pris en charge également par les systèmes d’exploitation récents ou qui vont sortir (par exemple à partir d'Android 12).
Pour firefox 86 qui doit sortir le 23/02, le support d'AVIF n'est pas totalement fini :( https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#avif_image
Firefox 86 provides basic support for AVIF images. More advanced features are still in development — including animated images and colorspace support (bug 1682995 (https://bugzilla.mozilla.org/show_bug.cgi?id=1682995)).
Firefox 77 to 85 require the preference image.avif.enable set true
-
C'est volontaire ?
Je pense que oui et c'est bien triste de la part d'Apple de provoquer et entretenir des divisions de format de fichiers.
Je pense que c'est lié au fait que la majorité (tous ?) des produits vendus ces 5 dernières années ont des accélérations Hardware pour H265, et pas pour AV1
Donc ils poussent le format le plus efficient possible sur leurs machines. Logique non ?
-
C'est aussi l'explication qui me venait à l'esprit, H.265 est déjà encodé / décodé en hardware depuis un moment, alors que l'AV1 / l'AVIF non.
Il sera intéressant de voir si cela va changer avec la génération de 2021.
-
pour info: https://squoosh.app/ est application/demo des technos web (wpa, wasm) qui permet de convertir et comparer 'cote a cote' ces formats d'images.
Les conversions se font entierement dans le navigateur.
L'app utilise du code C (par exemple https://github.com/AOMediaCodec/libavif pour AVIF) non spécifique au web et le compile pour tourner dans un navigateur grace a WebAssembly (https://webassembly.org/)(wasm).
il y a une version ligne de commande aussi.
-
C'est aussi l'explication qui me venait à l'esprit, H.265 est déjà encodé / décodé en hardware depuis un moment, alors que l'AV1 / l'AVIF non.
Il sera intéressant de voir si cela va changer avec la génération de 2021.
C'est supporté par certaines puces Dimensity de Mediatek et en décodage uniquement sur l'Exynos 2100 et certaines puces d'Amlogic supportent le décodage. Qualcomm semble bouder l'AV1...
-
On parlait là du choix d'Apple d'utiliser du HEIF pour les photos au lieu de l'AVIF. Donc il faudra surtout voir si les futures A15 et M2 seront capable d'encoder AV1 en hardware.
Du côté des autres constructeurs pour l'instant oui c'est surtout le décodage (que ce soit les puces ARM ou les gpu pour PC) qui est implémenté, je n'ai pas encore vu d'encodage hardware.
-
WebKit est le moteur de rendu de pages Web de Safari (comme Chromium pour Chrome).
WebKit est utilisé dans Safari mais aussi une poignée de navigateurs alternatifs.
Pourquoi WebKit prend en charge AVIF mais pas Safari
WebKit a ajouté la prise en charge du format d'image AVIF en avril 2021, mais il n'est toujours pas disponible dans Safari. Son absence est due au fait qu'Apple a choisi une méthode non conventionnelle pour décoder les images dans son navigateur.
Il a fallu dix ans à Apple pour ajouter le support WebP - le successeur des formats d'image JPEG et PNG - à son navigateur Safari. Le refus d'Apple d'ajouter la prise en charge de WebP a retardé son utilisation par les webmasters, les concepteurs et les développeurs, principalement parce que Safari est le navigateur dominant sur les appareils mobiles.
S'il était techniquement possible de diffuser des images WebP avant que Safari ne les prenne en charge, ce n'était pas pratique. Les concepteurs et développeurs Web devaient soit créer plusieurs types d'images pour la même image, soit payer un service comme Cloudflare pour changer automatiquement les images JPEG et PNG avec des images WebP pour les navigateurs prenant en charge WebP.
Nous entrons maintenant dans un territoire familier avec un nouveau format d'image appelé AVIF . AVIF est supérieur à WebP, et il a un support précoce de Chrome et Firefox , mais il est visiblement absent, encore une fois, dans Safari.
En avril 2021, ChangSeok Oh (https://twitter.com/shivamidow), un contributeur de WebKit, a ajouté la prise en charge d'AVIF à WebKit , donnant l'espoir aux concepteurs et développeurs Web que Safari obtiendrait bientôt la prise en charge d'AVIF. Lorsque la nouvelle version bêta de Safari est sortie des mois plus tard, la prise en charge d'AVIF manquait.
J'ai contacté Philippe Normand (https://twitter.com/_philn_), un autre contributeur de WebKit qui a travaillé sur la fonctionnalité AVIF, et lui ai demandé pourquoi Safari ne supportait toujours pas AVIF. Normand m'a dit que bien que le support AVIF ait été ajouté à WebKit, il n'était fonctionnel que dans les ports WebKitGTK (le moteur de navigation de Gnome) et WPE (un navigateur pour les appareils intégrés), pas les ports Apple Safari.
En communiquant avec Normand, je suis tombé par hasard sur un épisode de podcast intitulé, "Safari est-il le nouvel IE ?". Les hôtes du podcast étaient Surma (https://twitter.com/dassurma), Web Platform Advocate chez Google, et Jake Archibald (https://twitter.com/jaffathecake), Developer Advocate chez Google, et ils ont utilisé l'épisode pour partager leurs frustrations collectives sur la façon dont Apple aborde le développement de WebKit.
Parmi les plaisanteries amusantes, Surma a mentionné que Safari prend en charge WebP, mais ce n'est en fait pas dans Safari. Il a dit que c'était dans le système d'exploitation et que Safari s'accrochait au système d'exploitation. Il a poursuivi en déplorant qu'il pense que c'est une délégation inutile et que tous les autres navigateurs gèrent le décodage des images dans le package du navigateur.
Le 11 août 2021, la délégation du décodage des images à l'OS pour Safari a été confirmée par Sam Sneddon , un ingénieur logiciel chez Apple qui travaille sur WebKit. Sneddon a ajouté un commentaire au ticket WebKit AVIF et a expliqué pourquoi AVIF n'est pas encore pris en charge dans Safari. Ils ont confirmé que le décodage des images n'est pas effectué par le navigateur, mais par le système d'exploitation.
Les ports Apple utilisent les capacités de décodage d'image fournies par le système ; il est peu probable que nous nous en écartions ici, donc toute prise en charge d'AVIF dépend de la prise en charge du système d'exploitation sous-jacent. Je ne peux pas dire si les futures versions du système d'exploitation prendront en charge AVIF.
Commentaire de Sam Sneddon sur le ticket de support de décodage WebKit AVIF
La raison pour laquelle Safari ne prend pas en charge AVIF est qu'Apple n'a pas ajouté la prise en charge d'AVIF à iOS, iPadOS et macOS.
L'une des plaintes de Surma et Archibald à propos de Safari était qu'Apple ne publie que deux mises à jour majeures avec de nouvelles fonctionnalités par an, et qu'elles coïncident avec les mises à jour du système d'exploitation, tandis que Chrome et Firefox publient des mises à jour toutes les 6 à 8 semaines. Les versions bêta actuelles de macOS 12 (Monterey) et iOS 15 ne prennent pas en charge AVIF, ce qui signifie que Safari ne prend pas en charge AVIF. Si les nouveaux systèmes d'exploitation sont livrés sans prise en charge d'AVIF cet automne, cela pourrait signifier que nous devrons attendre au moins six mois avant que Safari ne prenne en charge AVIF, ou beaucoup plus longtemps.
Source : coywolf.news (https://www.coywolf.news/webmaster/why-webkit-supports-avif-but-safari-does-not/) Jon Henshaw, le 12 aout 2021, traduit par Google
-
WebKit est le moteur de rendu de pages Web de Safari (comme Chromium pour Chrome).
pas tout a fait.
Chrome n'est pas dérivé de Chromium. Ce sont 2 logiciels utilisant les mêmes sources mais 'build et packagé' différemment notamment pour les codecs audio et vidéo ( voir ceci (https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md) )
L’équivalent de Webkit pour Chrome/Chromium est Blink (https://www.chromium.org/blink/). Ce dernier est issue de Webkit (du moins une partie de Webkit) lui même issue de KHTML (de l'environnement KDE, navigateur Konqueror). D'ailleurs avant ce fork, Google était le plus gros contributeur a Webkit donc indirectement a Safari...
-
Il a poursuivi en déplorant qu'il pense que c'est une délégation inutile et que tous les autres navigateurs gèrent le décodage des images dans le package du navigateur.
Venant de Google, ce n'est pas étonnant : dans Chromium il y a plein de forks de librairies, ce qui complique d'ailleurs la tâche pour les distributions qui veulent utiliser les librairies système ("unbundling").
WebKitGTK et WPE utilisent les librairies système par défaut : libpng, libjpeg, libwebp, libavif, ...
-
Finalement, Apple devrait bien supporter AVIF dans tous ses systèmes d'exploitation dans 2 jours.
Voici un petit comparatif du support de l'AVIF par navigateur.
Désolé, l'image est un peu grande et en anglais, mais le but est de l'utiliser sur twiiter pour secouer Microsoft sur la prise en charge de l'AVIF : Microsoft Edge est le dernier à ne pas prendre en charge l'AVIF, une honte.
(https://lafibre.info/images/format/webp_avif_support.webp)
-
Réponse d'un développeur Microsoft Edge :
L'équipe évalue les options en ce moment. Nous informerons certainement tout le monde lorsqu'un plan se concrétisera.
Source : @patrickbrosset (https://twitter.com/patrickbrosset/status/1571059122816299008), le 17 septembre 2022
-
Si AVIF est un format de fichier, censé remplacer les formats JPEG / PNG / GIF / WebP qui fait son chemin (pris en charge sur presque tous les navigateurs modernes), toutefois, deux autres formats d'images prometteurs devaient arriver bientôt : JPEG XL et WebP 2.
Quelles différences de JPEG XL et WebP 2 avec AVIF ?
AVIF a une résolution maximale de 65536 x 65536 pixels. En tant que format d'image basé sur une image vidéo, la limite de résolution est parfaitement logique. Il est possible de dépasser cette limite grâce au carrelage. Les tuiles codées indépendamment peuvent ensuite être placées sur une grille pour créer une résolution maximale théorique de 2 147 483 647 x 2 147 483 647 pixels ou 2 500 mégapixels. Cependant, lorsque vous utilisez cette méthode, vous obtenez des artefacts sur les bords de chaque mosaïque encodée, ce qui rend AVIF globalement inadapté aux images à ultra haute résolution.
JPEG XL répond à cette problématique comme étant un format aussi efficace que AVIF, mais avec une dimension maximale de 1 152 921 502 459 mégapixels ou plus de 1 milliard de pixels de chaque côté d'une image. AVIF a une profondeur de couleur maximale de 12 bits avec un nombre maximal de canaux de trois. AVIF prend également en charge une plage dynamique élevée (HDR) et inclut la prise en charge de larges gammes de couleurs. La profondeur de bits maximale de JPEG XL peut pousser jusqu'à 24 bits entiers ou couleurs vraies, ou 32 bits flottants. Mais en réalité, pour les images, la précision des couleurs sur 12 bits est suffisante et il est peu probable la prise en charge de la profondeur de bits élevée de JPEG XL soit utilisée. Le support de JPEG XL est introduit dans GIMP 2.10.32 en juin 2022.
WebP 2 est un format d'image ouvert et libre de droits développé par Google. Il offre une compression avec perte plus efficace ~ 30% meilleure que WebP, aussi proche que possible d'AVIF. L'objectif principal de ce nouveau format est d'atteindre des taux de compression similaires à AVIF, tout en restant plus rapide à encoder et à décoder. WebP 2 supporte le HDR avec représentation des couleurs 10 bits, il propose une compression plus efficace des informations de transparence que WebP, la prise en charge complète de l'animation, le décodage incrémental (couche par couche avec plus de détails à chaque étape, permettant de générer très rapidement une vignette pour l'aperçu), encodage / décodage multi-threads, minimisation de la dégradation visuelle à de faibles débits de bits et un mode de compression sans perte amélioré par apport à WebP.
Mais des nuages viennent assombrir l'horizon de JPEG XL et WebP 2 :
JPEG XL : Google à décider de supprimer le support expérimental de JPEG XL dans Chrome (il devait être activé avec le drapeau enable-jxl, il n'était pas activé par défaut)
Nous supprimerons le code et l'indicateur JPEG XL de Chromium pour les raisons suivantes :
- les drapeaux et le code expérimentaux ne doivent pas rester indéfiniment ;
- il n'y a pas assez d'intérêt de la part de l'ensemble de l'écosystème pour continuer à expérimenter JPEG XL ;
- le nouveau format d'image n'apporte pas suffisamment d'avantages supplémentaires par rapport aux formats existants pour justifier son activation par défaut ;
- en supprimant le drapeau et le code dans M110, cela réduit la charge de maintenance et nous permet de nous concentrer sur l'amélioration des formats existants dans Chrome.
Pour WebP 2, il n'est pas encore disponible avec un support expérimental, mais Google annonce que WebP 2 ne sera pas publié en tant que format d'image, mais est utilisé comme terrain de jeu pour les expériences de compression d'image.
Bref, il n'y aura probablement pas de WebP 2 ou JPEG XL disponible rapidement, ce qui va laisser le champ libre à AVIF dont la prise en charge est presque complète (il manque Edge).
-
La partie vidéo, Motion JPEG 2000 (extension .mj2 ou .mjp2) incluant également du son basé sur le format MP4/QuickTime est définit par la RFC 3745 mais a peu de chance d'être utilisé. Contrairement à MPEG, MJ2 n'implémente pas le codage inter-trame : chaque trame est codée indépendamment en utilisant JPEG 2000. Cela permet de commencer une vidéo à n'importe quel point, alors que en MPEG-2, il faut avoir une image de référence (image i) pour décoder (c'est le cas dans les autres codecs vidéos performants). Motion JPEG 2000 est donc très gourmand en bande passante, bien plus que le MPEG-2.
Motion JPEG 2000 est donc une évolution de Motion JPEG (vidéo constituée d'images JPEG) qui est principalement utilisé pour les images de vidéo surveillance avec des besoins de très faible latence - la RATP utilisait du Motion JPEG, je ne sais pas si cela a évolué
En fait, le Motion JPEG2000 est utilisé pour les flux de contribution que s'échangent les chaines TV entre elles, pour alimenter les JT et chaines d'infos. Par ex, ARTE a des caméras qui filment en permanence 24/7 certains endroits (comme le Parlement Européen), et dès qu'il se passe un truc, boom, tout le monde peut basculer sur ces images. C'est leur peering à eux.
Si pet, il vaut mieux perdre une image plutôt que 25 (ou tout un GOP), et effectivement les bitrates sont plus importants (une 100taine de Mbps par flux).
-
Intéressant le jpeg2000, j'aurais plutôt pensé à un flux H.264/XAVC intra-trame. Genre comme ce que demande TF1 pour les programmes.
Pour moi c'était plutôt jpeg2000 = DCP
-
Oui, pourquoi ne pas utiliser un flux vidéo avec un GOP de 1 ?
-
Essentiellement parce que le critère est le coût des régies dans les rédactions.
Décoder du h264/hevc en live (et avec une bonne résilience en cas de dégradation) ça a un coût : j'ai vu qq baies de décodeurs hardware destinés qu'à ça (car les régies travaillent avec des flux décompressés), et donc plutôt réservés à réceptionner des images de journalistes terrain (qui eux, ont une contrainte de bande passante).
Et donc claquer un décodeur à chaque flux de contrib pour des images qui ne servent que 1% du temps et où la bande passante n'est pas un problème... certaines chaines n'en ont pas toujours les moyens tout simplement. Maintenant j'ignore s'il y a des flux qui sont effectivement en h264, mais c'est certain que le mjp2 est encore utilisé.
C'est comme le son : aujourd'hui tout le son est en mp2, alors que toutes les TV en France ont du Dolby sous le capot, et les telcos utilisent de l'AAC pour leur box (les boxs opérateurs n'ont pas forcément la licence Dolby). Tout le monde reprend le signal en mp2, car tout le monde sait le gérer sans problème, et personne n'a envie de se casser les dents à imposer un format plus récent.
-
Tenez, même l'INA travaille avec du JPEG2000 :)
https://www.youtube.com/watch?v=70zZPcMZETE
-
Ah oui, on parle d'un flux vidéo à 450Mb/s !
-
Je me demande s'ils ont une autre solution pour l'UHD (ou s'ils n'archivent pas dans cette qualité).
Parce que avec 8 fois plus de pixels (sans compter la profondeur de couleur)...
-
Microsoft Edge, le seul navigateur à ne pas supporter AVIF, devrait avoir le support qui arrivera plus tard dans l'année.
AVIF n'est pas encore entièrement implémentée et il faut passer en ligne de commande pour activer cette fonctionnalité : --enable-features=msEdgeAVIF
On a de bonnes chances de voire arriver AVIF dans la version stable d'Edge dans environ 6 mois.
Source de l'information : @Leopeva64 (https://twitter.com/Leopeva64/status/1623387417414606850)
-
La FSF n’est pas fan de la décision « politique » de supprimer le JPEG-XL au profit de l’AVIF.
https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats
Whether it's through the millions of dollars Google has funneled into development and advertising or the "convenience" that it offers users in exchange for freedom, the fact remains that Google Chrome is the arbiter of web standards. Firefox, through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold. Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally.
Part of Google's official rationale for the deprecation is the following line: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG-XL." Putting aside the problematic aspects of the term "ecosystem," let us remark that it's easy to gauge the response of the "entire ecosystem" when you yourself are by far the largest and most dangerous predator in said "ecosystem." In relation to Google's overwhelming power, the average web user might as well be a microbe. In supposedly gauging what the "ecosystem" wants, all Google is really doing is asking itself what Google wants. If we take their contribution in turning the web into the "WWWorst App Store" seriously, then we understand what Google really wants. Google wants to do what's best for its own predatory interests, not what's best for the web.
Voir aussi une comparaison des deux formats :
https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
-
Traduction en Fançais :
Que ce soit grâce aux millions de dollars que Google a consacrés au développement et à la publicité ou à la "commodité" qu'il offre aux utilisateurs en échange de la liberté, il n'en demeure pas moins que Google Chrome est l'arbitre des normes Web. Firefox, à travers des distributions éthiques comme GNU IceCat et Abrowser, peut affaiblir cette emprise. L'abandon par Google du format d'image JPEG-XL en février au profit de son propre format AVIF breveté ne mettra peut-être pas fin au Web dans le grand schéma des choses, mais il met en évidence, une fois de plus, le contrôle inquiétant qu'il exerce sur la plate-forme en général. .
Une partie de la justification officielle de Google pour la dépréciation est la ligne suivante : "Il n'y a pas assez d'intérêt de la part de l'ensemble de l'écosystème pour continuer à expérimenter avec JPEG-XL." Laissant de côté les aspects problématiques du terme « écosystème », remarquons qu'il est facile de mesurer la réponse de « l'ensemble de l'écosystème » lorsque vous êtes vous-même de loin le prédateur le plus grand et le plus dangereux dudit « écosystème ». Par rapport à la puissance écrasante de Google, l'internaute moyen pourrait tout aussi bien être un microbe. En mesurant soi-disant ce que veut « l'écosystème », tout ce que Google fait en réalité, c'est se demander ce que Google veut. Si nous prenons au sérieux leur contribution à transformer le Web en "WWWorst App Store", nous comprenons alors ce que Google veut vraiment. Google veut faire ce qui est le mieux pour ses propres intérêts prédateurs, pas ce qui est le mieux pour le Web.
AVIF est un format d'image ouvert et libre de droits et il n'a pas été crée par Google, je ne comprends pas les critiques de la FSF.
JPEG-XL est clairement supérieur à l'AVIF sur de nombreux points et je trouve aussi dommage, c'était une occasion d'avoir le même format sur internet et sur les appareils photos.
Car si l'AVIF va probablement s'imposer sur internet, l'AVIF n'est pas un format adapté pour les appareils photos :
- 2019 : AVIF (AV1 Image File Format) est un format d'image ouvert et libre de droits qui utilise l'algorithme de compression pour les images clés de l'AV1. Il commence à être supporté par quelques navigateurs : Chrome 85, Firefox 86, Opera 71. Il est pris en charge également par les systèmes d’exploitation récents ou qui vont sortir (par exemple à partir d'Android 12).
AVIF supporte :
- Des espaces de couleur multiples HDR, SDR ou avec l'indication de l'espace de couleur par des profils CICP ou ICC
- La compression sans perte ou la compression avec pertes
- Le canal alpha qui indique le degré de transparence de chaque pixel de l'image
- Des annimations (il remplace done le GIF)
- Une profondeur de couleur de 8, 10 ou 12 bits par couleur primaire
- Les couleurs monochromes
- Le sous-échantillonnage de la chrominance 4:2:0, 4:2:2, 4:4:4 qu'il manque à WebP et le RGB
- Compatible avec la granularité des films photo
- 2021 ou 2022 : JPEG XL est un format ouvert et libre de droits qui permet la compression d’images fixes avec ou sans pertes. JPEG XL est conçu pour être plus efficace que les formats existants, et vise à les remplacer pour tous les usages courants. AVIF a une résolution maximale de 65536 x 65536 pixels. En tant que format d'image basé sur une image vidéo, la limite de résolution est parfaitement logique. Il est possible de dépasser cette limite grâce au carrelage. Les tuiles codées indépendamment peuvent ensuite être placées sur une grille pour créer une résolution maximale théorique de 2 147 483 647 x 2 147 483 647 pixels ou 2 500 mégapixels. Cependant, lorsque vous utilisez cette méthode, vous obtenez des artefacts sur les bords de chaque mosaïque encodée, ce qui rend AVIF globalement inadapté aux images à ultra haute résolution. D'autre part, JPEG XL a une dimension maximale de 1 152 921 502 459 mégapixels ou plus de 1 milliard de pixels de chaque côté d'une image. AVIF a une profondeur de couleur maximale de 12 bits avec un nombre maximal de canaux de trois. AVIF prend également en charge une plage dynamique élevée (HDR) et inclut la prise en charge de larges gammes de couleurs. La profondeur de bits maximale de JPEG XL peut pousser jusqu'à 24 bits entiers ou couleurs vraies, ou 32 bits flottants. Mais en réalité, pour les images, la précision des couleurs sur 12 bits est suffisante et il est peu probable la prise en charge de la profondeur de bits élevée de JPEG XL soit utilisée. Le support de JPEG XL est introduit dans GIMP 2.10.32 en juin 2022.
À noter qu'en compression sans perte, avec GIMP, j'obtiens toujours des fichiers plus petits avec WebP que AVIF (dans les deux cas en sélectionnant la compression sans perte).
-
AVIF est un format d'image ouvert et libre de droits et il n'a pas été crée par Google, je ne comprends pas les critiques de la FSF.
AVIF vient d'AV1 qui vient de VP9 donc a l'origine de Google.
et JPEG-XL vient aussi en partie de Google.
ils disent "breveté" (patented) ce qui n'empêche pas "royalty-free licensing model".
Le problème des patents d'AVIF est qu'il y a des "prétentions" en dehors de l'alliance AOM (cf Sisvel (https://avif.io/blog/faq/avif-patents/)).
JPEG-XL n'aurait pas ce "potentiel" souci mais rien n'est garanti tellement le système de brevets US est complexe.
Apres rien n'est définitif , Chromium est open source donc Microsoft par exemple peut resupporter JPEG-XL dans Edge s'ils le veulent. Safari et Firefox peuvent le supporter sans l'aval de Google... Et Google peut revenir sur sa décision d'ici quelque temps.
Apres la FSF fait de la rhétorique FSF...
-
Apres la FSF fait de la rhétorique FSF...
Oui en effet. Mais quand un navigateur contrôle plus de 60% du marché, tu conviendras que l'adoption d'un nouveau format dépend fortement du bon vouloir de l'éditeur de ce logiciel.
-
Même 15% de part de marché, tu bloques l'écosystème Internet.
Je pense aux navigateurs sur iOS, Apple bloque beaucoup de technologies et de nombreux acteurs attendent ce support pour bouger.
J'espère que pour iOS17, il sera enfin possible d'utiliser un autre moteur de rendu que celui imposé par Apple, afin d'avoir une vraie concurrence de navigateurs sur iOS et iPadOS.
J'espère aussi voire arriver les codecs Opus, VP9, AV1, AVIF et bien d'autres dans iOS 17.
-
Oui en effet. Mais quand un navigateur contrôle plus de 60% du marché, tu conviendras que l'adoption d'un nouveau format dépend fortement du bon vouloir de l'éditeur de ce logiciel.
Je parlais pas de ca mais de l'histoire des patents/royalties free. "FSF fait de la rhétorique FSF" ca veut dire qu'elle en fait trop en disant des trucs pas vrai ou exagéré au détriment de son message principale (bref un peu comme les écolos quoi :))
Pour ce qui est de l'adoption ou pas de jpeg-xl, je ne pense pas que la pdm de Google y soit pour quelque chose dans la décision.
-
J'espère que pour iOS17, il sera enfin possible d'utiliser un autre moteur de rendu que celui imposé par Apple, afin d'avoir une vraie concurrence de navigateurs sur iOS et iPadOS.
Avec le risque non négligeable d'assoir un peu plus l'hégémonie de Google avec Chrome et son moteur de rendu. Pas certain que ce soit une bonne idée.
Pour ce qui est des codecs je suis d'accord.
-
La rumeur de l'arrivé des autres moteurs de rendu sur iOS n'est toujours pas confirmé ou démenti. Pour l'instant, y'a une expérience (https://bugs.chromium.org/p/chromium/issues/detail?id=1411704) sous Chromium, officiellement a des fins de mesures de perfs.
Certains disent que c'est en préparation de la réglementation EU (DMA-Digital Markets Act) qui va forcer Apple a ouvrir iOS a la concurrence.
De ce coté la, rien n'est joué encore, ca débute en mai 2023 (https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en#what-are-the-next-steps) et il y a un process de 4 mois pour désigner les "gatekeeper" et SI Apple est désigné gatekeeper alors ils auront ensuite 6 mois pour se mettre en règle. Donc pas avant 1 an au mieux.
Perso je ne vois pas cela comme un problème. Si Apple interdit les autres moteurs ce n'est pas par altruisme mais pour protéger son Store (tout comme quand ils ont interdit Flash au lancement d'iOS sous de faux prétexte de sécurité/performance pour imposer leur Store). C'est tout le but du Digital Markets Act.
Apres on peut voir Chrome comme hégémonique ou au contraire considéré Chromium comme "le standard open source" et Chrome juste un des nombreux produits utilisant Chromium.
D'autant plus depuis l'arrivée d'Edge basé sur Chromium et l'intégration de Chromium dans Windows 11 avec webview2.
Faire un moteur de rendu qui supporte tous les standards du W3C c'est juste quelque chose d'énorme a maintenir, d'autant qu'il n'y a pas de marché de licence derriere cela. Si un gros comme MS en arrive a jeter son propre moteur c'est clairement symptomatique.
L'idéal aurait été que MS choisissent Firefox et pas Chromium mais ce sont les devs de MS qui ont choisi: ils sont regardé les sources des 2 moteurs et ont quand meme choisi Chromium ca en dit long sur Firefox...
-
Mies à jour de mon comparatif, avec le support de AVIF qui arrivera cette année dans Edge (au second semestre 2023).
Il est possible de l'utiliser pour le moment uniquement sur le canal Microsoft Edge Canary en activant AVIF en rajoutant dans la ligne de lancement du navigateur --enable-features=msEdgeAVIF
(https://lafibre.info/images/format/webp_avif_support.webp)
-
Firefox 113, qui est sorti aujourd'hui, prend désormais en charge les fichiers au format d'image AV1 contenant des animations (AVIS), améliorant ainsi la prise en charge des images AVIF sur le Web.
Avant Firefox 113, le format d'image AVIF était pris en charge (depuis Firefox 93) uniquement pour les images fixes : Les séquences d'images animées (type GIF mais au format AVIF) n'étaient pas prises en charge.
Les autres navigateurs web qui ont mis en place AVIF l'on fait directement avec les images animées. Il ne reste donc plus que Microsoft Edge pour avoir un support complet dans tous les navigateurs récents.
-
Après l'abandon par Google de l'expérimentation JPEG XL, aujourd'hui supporté par aucun navigateur, Apple annonce un support complet avec la prochaine version d'iOS et de macOS.
Apple serait en avance sur le reste de l'écosystème ?
- 2020 : Apple ajoute, 8 ans après Google, le support du format d'image WebP dans iOS 14 et macOS 11
- 2022 : Apple ajoute, 2 ans après Google, le support du format d'image AVIF dans iOS 16 et macOS 13
- 2023 : Apple ajoute, avant tous les autres navigateurs, le support du format d'image JPEG XL dans iOS 17 et macOS 14.
Si Apple se rattrape bien coté image, coté vidéo et audio, c'est toujours la catastrophe (VP9, AV1 et Opus ne sont pas supportés dans iOS 17).
JPEG XL : Google à décider de supprimer le support expérimental de JPEG XL dans Chrome (il devait être activé avec le drapeau enable-jxl, il n'était pas activé par défaut)
Nous supprimerons le code et l'indicateur JPEG XL de Chromium pour les raisons suivantes :
- les drapeaux et le code expérimentaux ne doivent pas rester indéfiniment ;
- il n'y a pas assez d'intérêt de la part de l'ensemble de l'écosystème pour continuer à expérimenter JPEG XL ;
- le nouveau format d'image n'apporte pas suffisamment d'avantages supplémentaires par rapport aux formats existants pour justifier son activation par défaut ;
- en supprimant le drapeau et le code dans M110, cela réduit la charge de maintenance et nous permet de nous concentrer sur l'amélioration des formats existants dans Chrome.
Pour WebP 2, il n'est pas encore disponible avec un support expérimental, mais Google annonce que WebP 2 ne sera pas publié en tant que format d'image, mais est utilisé comme terrain de jeu pour les expériences de compression d'image.
Bref, il n'y aura probablement pas de WebP 2 ou JPEG XL disponible rapidement, ce qui va laisser le champ libre à AVIF dont la prise en charge est presque complète (il manque Edge).
La version 17 d’iOS arrivera à l’automne prochain. Elle a été annoncée lors de la WWDC du 5 juin 2023.
Toutes les nouveautés iOS 17
Et comme pour chaque nouvelle version d’iOS, se pose la question suivante : est-ce que mon iPhone peut l’installer ? En règle général, si votre machine n’est pas plus vieille que 4 ou 5 ans, vous ne risquez rien. Mais Apple apprécie les exceptions, avec parfois, des mises à jour majeures d’iOS qui ne changer rien à la liste des iPhone compatibles. Est-ce le cas pour iOS 17 ? Réponse ci-dessous.
iOS 17 : quels iPhone sont compatibles
Voici la liste des iPhone compatibles avec iOS 17 :
- 2022 : iPhone SE 2022 (Commercialisation 18 mars 2022) et iPhone 14 (Commercialisation 16 septembre 2022)
- 2021 : iPhone 13 (Commercialisation 24 septembre 2021)
- 2020 : iPhone SE 2020 (Commercialisation 24 avril 2020) et iPhone 12 (Commercialisation 23 octobre 2020)
- 2019 : iPhone 11 (Commercialisation 20 septembre 2019)
- 2018 : iPhone XS (Commercialisation 21 septembre 2018)
Voici la liste des iPad compatibles avec iPadOS 17 :
- 2022 : iPad de 10e génération, iPad Air de 5e génération et iPad Pro de 6e génération
- 2021 : iPad de 9e génération et iPad mini de 6e génération et iPad Pro de 5e génération
- 2020 : iPad de 8e génération, iPad Air de 4e génération et iPad Pro de 4e génération
- 2019 : iPad de 7e génération, iPad mini de 5e génération et iPad Air de 3e génération
- 2018 : iPad de 6e génération et iPad Pro de 3e génération
- 2017 : iPad Pro de 2e génération
-
peut-etre a cause de leur future casque VR qu'ils ont annoncé récemment ou si j'ai bien compris la qualité d'image / conso cpu / taille stockage sera un critère important pour cet appareil.
Apple fait toujours des choses si ca sert les intérêts d'Apple ;)
-
JPEG XL est un format intéressant qui pourrait remplacer le JPEG dans les appareils photos, contrairement à AVIF est un surtout fait pour internet.
Apple pourrait peut-être l'utiliser pour les photos de l'iPhone.
Depuis iOS 11 le format d'image par défaut pour les photos est HEIF, un format pris en charge par aucun navigateurs web
=> https://support.apple.com/fr-fr/HT207022
HEIF ne permet pas des trop grandes photos, la réalité virtuelle demanderait des photos plus grandes ?
JPEG XL est bien meilleur que HEIF, en termes de performances ou caractéristiques.
-
Puisque le HEIF est utilisé pour les photos, le AVIF pourrait l'être (à condition d'avoir les bons blocs HW).
Mais le seul réel avantage serait la compatibilité (les navigateurs, etc...), et ce n'est clairement pas ce qui peut motiver Apple.
https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4 donne AVIF comme légèrement supérieur à HEIF.
Mais attention, on ne peut pas comparer deux formats de manière indépendante des encodeurs (contrairement au décodage, il y a des choix à faire au moment d'encoder).
-
J'ai demandé à GPT-4 (intégré dans Edge) :
Fait moi un argumentaire pour convaincre Microsoft de prendre en charge le format d'image AVIF dans le navigateur web Microsoft Edge, et d'activer ce format par défault, afin que tous les utilisateurs puissent l'utiliser.
Voici la réponse :
Bonjour! Merci pour votre question. Je suis heureux de vous aider à convaincre Microsoft de prendre en charge le format d’image AVIF dans le navigateur web Microsoft Edge.
Selon une réponse sur Stack Overflow, AVIF est le format d’image le plus efficace qui existe, offrant une qualité d’image étonnante à des tailles de fichier incroyablement petites (lien 1). Cela peut aider à économiser de la bande passante et à accélérer les sites Web intensifs en images. Les navigateurs tels que Chrome et Firefox prennent déjà en charge AVIF depuis un certain temps (lien 1). Cependant, Microsoft Edge ne prend pas en charge AVIF pour le moment (lien 2). Cela signifie que les utilisateurs de Microsoft Edge ne peuvent pas profiter des avantages d’AVIF.
Je recommande de contacter Microsoft Edge directement pour leur faire part de votre demande. Vous pouvez envoyer vos commentaires directement à l’équipe Microsoft Edge en utilisant la fonctionnalité “Envoyer des commentaires” dans le navigateur (lien 1). Vous pouvez également exprimer votre frustration sur les forums de support Microsoft Edge (lien 2). Plus il y aura de demandes pour prendre en charge AVIF, plus il sera probable que Microsoft Edge l’activera par défaut.
J’espère que cela vous aidera. N’hésitez pas à me poser d’autres questions si vous en avez.
Les liens proposés :
- 1 : https://stackoverflow.com/questions/75459594/why-doesnt-edge-support-avif-images
- 2 : https://learn.microsoft.com/en-us/answers/questions/809434/avif-format-not-supported-in-microsoft-edge
- 3 : https://www.frandroid.com/marques/microsoft/1666489_microsoft-edge-va-charger-les-photos-plus-vite-et-ce-nest-pas-trop-tot
- 4 : https://answers.microsoft.com/en-us/microsoftedge/forum/all/support-for-avif-image-format-in-microsoft-edge/7dd10bd3-d227-46b1-8f1e-3abf4c85d041
(https://lafibre.info/images/format/202311_gpt4_support_avif_microsoft_edge.webp)
-
Toujours pas de chargement des images en avif avec Edge 120.0.2210.61 :(
Quand je vais sur https://avif.io/ avec Edge c'est indiqué que le support d'avif est présent ???
Chez https://avif.io ils ne répondent pas : https://github.com/justinschmitz97/avif.io/issues/119
-
Microsoft travaille toujours sur AVIF.
J'espère que le support des vidéos AV1 arrivera en même temps.
(https://lafibre.info/images/format/202310_edge_avif_support.webp)
Source : Mastodon (https://toot.cafe/@slightlyoff/111326151941641420)
-
JPEG XL est un format intéressant qui pourrait remplacer le JPEG dans les appareils photos, contrairement à AVIF est un surtout fait pour internet.
Dans l'absolu, pourquoi pas, le JPEG XL remplacera peut-être à terme le JPG dans les APN, mais je ne vois pas les APN ouvrir le bal là-dessus, à part peut-être une ou deux marques ou quelques modèles anecdotiques en terme de PdM. En effet, le JPG aujourd'hui sur les APN est plutôt un héritage de compatibilité lié au passé, à l'habitude (les premiers APN un peu corrects il y a 20 ans faisaient du JPG en éventuellement du TIFF). Il a donc pour lui son historique et sa compatibilité universelle. Les gens qui ont un APN peuvent être catégorisées en 2 groupes principaux (qui feront que les formats disponibles au niveau des APN suivront une logique identique):
- soit les gens qui se contentent de l'image faite par le boitier, pour l'avoir immédiatement, avec une compatibilité universelle, tant sur les ordis, tablettes, smartphones que sur les plateformes en ligne, ne nécessitant aucune conversion et avec un choix de qualité suffisant (LOW/MED/HIGH comme souvent sur les boitiers) ; pour ces gens le JPEG est le format parfait
- soit les gens qui veulent faire de la retouche photo, exploiter leur APN au mieux, développer les fichiers brut et dont la compatibilité universelle n'est pas dans un premier temps essentielle ; pour ces gens c'est les fichiers RAW qui doivent être post-traités
Le JPEG XL ne rentre dans aucune de ces catégories, du moins pour le moment : il n'a ni la compatibilité universelle du JPEG, ni les possibilités de post-traitement du RAW. Dans le monde la photographie, il sera sûrement d'abord utilisé comme format d'export des RAW, car il permet de stocker sans perte les photos retouchées dans une taille de fichier moindre que les RAW ou TIFF... Mais on garde finalement toujours les RAW car l'amélioration constante des dématriceurs et des algo notamment de débruitage par IA permet parfois de développer de manière très qualitative des RAW difficilement récupérables il y a 2, 3, 5 ans.
Donc pour un fabriquant d'APN, se fatiguer à ajouter le support du JPEG XL, ça n'apporte rien directement aux clientèles cibles (du moins ce qu'il en reste) des APN... Peut-être, comme je le disais plus haut, que certains boitiers les géreront rapidement, mais je crois guère à l'intérêt (coût, développement, puissance nécessaire pour gérer la compression/décompression et donc impact sur l'autonomie, etc. pour peu de plus-value directe pour l'utilisateur final).
Apple pourrait peut-être l'utiliser pour les photos de l'iPhone.
Depuis iOS 11 le format d'image par défaut pour les photos est HEIF, un format pris en charge par aucun navigateurs web
=> https://support.apple.com/fr-fr/HT207022
Apple peut effectivement avoir une force de frappe large pour imposer le JPEG XL vu la base d'appareils iOS/iPadOS, mais faudrait pour cela se dépêcher de le faire, voire (mais on peut toujours rever) ajouter le support aux anciennes version d'iOS... Néanmoins, le JPEG XL n'a pas non plus un support très large des navigateurs (depuis le retrait de Chrome), et Apple n'a pas réussi à faire changer les choses en 10 ans avec le HEIF...
Mais je suis d'accord pour dire que le JPEG XL aurait bien sa place dans ces boitiers/photo-phones au côté du JPEG (toujours la nécessité de compatibilité universelle), mais faut que le support des plateformes en ligne suivent aussi sur le JPEG XL (vu que ça passe par des applications, la compatibilité peut être améliorée directement via ces applications).
-
Apple n'a pas réussi à faire changer les choses en 10 ans avec le HEIF...
Un format d'image avec des brevets, c'était perdu d'avance.
-
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.
-
Pour moi, HEIF demander de payer des royalties :
Ozer : Y a-t-il une redevance sur HEIF ? Si tel est le cas, savons-nous de quoi il s’agit ou s’agira-t-il d’un cauchemar comme HEVC ?
Gill : HEIF est un sous-ensemble de HEVC, car il contient une seule « image clé » ou « image I » HEVC. Il s'agit d'images qui sont codées dans leur ensemble et non prédites à partir d'autres images. Par conséquent, seuls les brevets HEVC qui couvrent le codage d'images fixes sont pertinents pour HEIF, et non les brevets qui traitent des prédictions d'images, de l'estimation et de la compensation de mouvement, des modes temporels, etc.
Les pools de brevets actuels ne font pas de distinction entre les brevets « images fixes » et le reste des brevets HEVC, il n’est donc pas clair comment obtenir une licence HEIF, autre que le paiement de l’intégralité des redevances HEVC. Il est logique que si le format d'image devient populaire, les pools de brevets offriraient des frais de licence réduits « HEIF only ».
Cela dit, je ne vois pas beaucoup d’entreprises qui utiliseront uniquement HEIF et non HEVC, car aujourd’hui les flux de travail d’image et de vidéo sont étroitement liés. Les fournisseurs d'appareils photo tels que Canon, Nikon et Sony fabriquent tous des appareils photo qui prennent à la fois des images fixes et des vidéos, les fournisseurs de logiciels tels qu'Adobe créent des logiciels d'image et de vidéo, et la plupart des services photo en ligne tels que Flickr, Snapfish, Shutterfly, etc. prennent en charge à la fois la photo et la vidéo. Dans tous ces exemples, les fournisseurs qui autorisent HEVC pour leur flux vidéo obtiendront la licence HEIF « gratuitement ».
Source : Apple Endorses New Image Format, HEIF (https://www.linkedin.com/pulse/apple-endorses-new-image-format-heif-jan-ozer/), le 12 juin 2017 par Jan Ozer - traduit de l'anglais.
Dans Windows 10, le support des images HEIF a comme pré-requis l'achat d'une licence HEVC (soit fourni par le matériel, soit acheté à 1€ sur le microsoft Store) :
(https://lafibre.info/images/format/202312_microsoft_extension_image_heif.webp)
-
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...
-
On parle du format d'image qui sera utilisé dans 10 ans, sachant qu'il y a forcément 10 ans entre la création et la mise en ouvre à grande échelle.
Les formats WebP ou AVIF ont des limitations qui font qu'ils resteront principalement des formats liés au web (même s'il WebP est pris en charge par la plupart des logiciels, même Microsoft Paint de Windows).
Jpeg a aussi des lacunes : Pas de HDR, limitation à 8 bits par couleur, pas de gestion de la transparence, pas de compression sans perte, pas possible d'avoir des images animées...
Bref, Jpeg doit être remplacé à moyen terme et Jpeg XL semble une piste qui coche toutes les cases.
-
Par rapport au royalties de HEIF... que penses-tu de la page Wikipedia (https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format) 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.
-
Techniquement je ne dis pas le contraire, je l’ai déjà souligné. Je souhaiterais même que le JPEG XL soit déjà à la place du JPEG. Mais il n’est pas du tout certain que le JPEG XL soit autre chose qu’un format de niche comme le fut le JPEG 2000 il y a 20 ans et qui était aussi une tentative de correction des défauts du JPEG. A l’époque les besoins d’universalité et la dépendance au JPEG était moins grande qu’ajd (réseaux sociaux, messageries, APN, photo phone…) et pourtant le JPEG2000 a raté son coup.
Plus on laisse le JPEG hégémonique et s’incruster plus ses potentiels successeurs auront du mal à passer, à mon avis le retard est déjà trop grand il ne fait pas penser à 10 ans dans le futur mais dans le passé. Si on veut que le JPEG XL passe faut que les GAFAM le supportent tous et partout, et qu’ils ajoutent son support dans les versions de leur OS et logiciels des 3 voire 5 dernières années et qu’il soit mis comme format par defaut a la place du JPEG.
-
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.
-
En effet Apple ne semble pas très constant sur le label de ce format... sur une photo prise par un iPhone, extension HEIC mais description HEIF.
-
Une excellente nouvelle : Le support du format d'image AVIF arrive avec Microsoft Edge 121
Microsoft Edge était le seul navigateur à ne pas supporter les images AVIF, ce support va permettre l'utilisation dans un à deux ans (le temps que les utilisateurs aient tous fait la mise à jour) d'utiliser des images AVIF sans fallback vers un autre format d'image. Sur ce forum, les images AVIF devraient se généraliser dans mes reportages dans deux ans.
Toutes les versions de Edge 121 auront un support d'AVIF : Edge 121 pour Windows 11, Edge 121 pour Windows 10, Edge 121 pour Android, Edge 121 pour Linux, Edge 121 pour macOS.
Pour Edge 121 pour iOS ou iPadOS, c'est le moteur de safari qui est utilisé dans Edge. Le support de AVIF fonctionne déjà, si on a iOS 16 ou iPadOS 16.
Edge 121 sera disponible en version stable à partir du 25 janvier 2024.
En même temps que le format d'image AVIF, c'est le support du codec vidéo AV1 qui arrive en même temps.
(https://lafibre.info/images/format/avif_support.webp) (https://lafibre.info/images/tv/av1_support.webp)
-
Edge 121 est disponible en version stable avec le support du format d'image AVIF et du codec vidéo AV1 pour tous les utilisateurs d'Edge, quel que soit l'âge du terminal ou la plateforme (exception : les iPhone et iPad, vu que le moteur de rendu est Safari).
-
Je ne vais pas utiliser AVIF massivement sur LaFibre.info avant janvier 2026 (2 ans), mais j'ai mis une des images de la page d'accueil en AVIF, afin de permettre de voir rapidement si votre navigateur est compatible AVIF.
C'est l'image en bas à droite. Si elle ne s'affiche pas, votre navigateur ne gère pas AVIF.
Exemple avec Edge 120 (en haut) et Edge 121 (en bas) sous Ubuntu 20.04 : (j'ai entouré l'image en vert)
(https://lafibre.info/testdebit/linux/202401_edge120_edge121_avif.webp)
-
Une semaine que Edge 121 est disponible sur PC (Windows / Linux), mais pas sur Android.
C'est pourtant important, c'est le dernier navigateur a supporter l'AVIF.
J'ai comme l'impression que sur Android, ils ne font qu'une version sur deux (Microsoft à un Canal stable qui a toutes les versions et un Canal stable étendu ou chaque version est maintenue un mois de plus, une sorte de LTS, mais de courte durée : On passe de deux versions en deux versions : Edge 100 => Edge 102 => Edge 104 => Edge 106 => Edge 108 => Edge 110 => Edge 112 => Edge 114 => Edge 116 => Edge 118 => Edge 120 => Edge 122 => Edge 124 => Edge 126.
Si cette hypothèse est confirmée, il faudra attendre Edge 122, le 22 février 2024.
-
Certains sites comme par exemple Leboncoin n'acceptent toujours pas le format AVIF à l'upload.
Ça n'aide pas à faire la transition.
Autre exemple qui freine l'adoption d'avif : le logiciel Paint.net ne permet pas de modifier le format d'enregistrement par défaut qui est toujours le PNG en 2024 !
Il faut systématiquement penser à modifier le format d'image à l'enregistrement >:(
-
Ce n'est pas anormal : AVIF est récent.
Par contre, en 2024, on a encore des sites web refusent de le WebP (mais ils sont de plus en plus rares).
-
Si cette hypothèse est confirmée, il faudra attendre Edge 122, le 22 février 2024.
Hypothèse erronée : Edge 121 pour Android est finalement arrivé, avec pas mal de retard, le 5 février 2024.
Donc aujourd'hui, tous ceux qui ont leur navigateur à jour sur PC, Mac, Android ou iPhone ont un support des images AVIF.
(https://lafibre.info/testdebit/android/202402_edge_121_android.webp)
-
GIMP version stable ne sait exporter les images AVIF qu'avec une compression avec perte (type Jpeg).
Pour une compression sans perte (type PNG), il faut utiliser la version bêta.
Cela fait de nombreuses fois que je teste les versions beta de Gimp et je suis étonné : les images compressées en AVIF sans perte sont bien plus lourdes que celles en WebP sans perte.
Voici ci-dessous un exemple avec GIMP 2.99.18, mais c'est le cas également avec la précédente bête et pour toutes les images que j'ai testées.
Version AVIF sans perte de qualité : 31 582 octets
(https://lafibre.info/images/format/202402_gimp_fenetre_export_avif.avif)
Version WebP sans perte de qualité : 15 220 octets (habituellement WebP permet de diviser la taille par 2 à 4 par rapport à du PNG, si ce dernier n'a pas reçu d'optimisation particulière)
(https://lafibre.info/images/format/202402_gimp_fenetre_export_webp.webp)
Version PNG : 33 201 octets (le format PNG est toujours sans perte de qualité, contrairement au Jpeg qui intègre une compression avec perte de qualité)
(https://lafibre.info/images/format/202402_gimp_fenetre_export_png.png)
-
J'ai l'impression que c'est normal et que AVIF est un format mauvais format d'image en compression sans perte.
WebP fait bien mieux que AVIF de manière systématique.
AVIF sans perte est pire que WebP sans perte, parfois même pire que PNG
En fait, je suis en désaccord à 100% avec la mise en œuvre sans perte d'AVIF.
La méthode de codage de WebP sans perte consiste à utiliser une méthode de codage sans perte complètement distincte. Le format WebP avec perte est basé sur un format vidéo, et le format sans perte est meilleur pour les formats d'image. Le seul inconvénient de WebP sans perte est qu'il ne prend pas en charge le 16 bits ou le 32 bits, il ne peut donc pas être utilisé à des fins d'archivage, ce qui est décevant.
WebP a été critiqué pour être un format « fourre-tout ». C'est-à-dire que cela en fait trop, mais à cet égard, il était en fait très intelligent d'avoir une méthode de compression sans perte distincte, puisque même aujourd'hui, Lossless WebP 8bit occupe un rang très élevé parmi les formats sans perte disponibles avec un support généralisé.
AVIF utilise essentiellement un format vidéo pour la méthode avec et sans perte. Cela signifie que, par rapport à WebP sans perte, ses performances peuvent être pires, parfois même spectaculairement pires.
Non seulement cela, mais AVIF sans perte n'est même pas vraiment sans perte, car il nécessite que l'image soit convertie en yuv4:4:4 ou yuv4:2:0, ce qui signifie que si votre image est à l'origine RVB, vous subirez une conversion avec perte, simplement en passant de RVB à YUV. J'ai entendu parler de façons dont l'image peut être convertie sans perte entre RVB et YUV, mais ce n'est pas orthodoxe et je ne le recommande pas.
Ainsi, utiliser AVIF sans perte comme format d’archives est presque entièrement stupide, puisque la grande majorité du travail est effectué en RVB.
Bref, tu veux mon avis ? N'utilisez pas AVIF sans perte, sauf pour les petits fichiers. Pour la plupart des autres cas, utilisez simplement WebP sans perte. Si vous avez absolument besoin de 16 bits sans perte, utilisez simplement PNG.
J'irais jusqu'à suggérer qu'AVIF ne devrait même pas avoir de support sans perte, car il est extrêmement stupide dans sa forme actuelle, et la seule fois où vous envisagerez de l'utiliser est dans de rares situations extrêmes, et le temps passé à convertir une image à AVIF, c'est un pari de temps perdu. Si l’utilisation d’AVIF sans perte est un avantage, tant mieux. Sinon, vous avez perdu beaucoup de temps à attendre de le savoir. Je m'éloigne du sujet, il vaut mieux s'en tenir à WebP sans perte pour le contenu 8 bits et PNG pour 16 bits.
Source : GitHub AVIF (https://github.com/AOMediaCodec/av1-avif/issues/111), traduit de l'anglais.
-
Officiellement AVIF semble être mauvais en compression sans perte.
Voici les propos d'un développeur qui travaille sur AV1, pour lui le format d'image du futur c'est Jpeg XL, pas AVIF :
Non? Même si de nombreuses améliorations des performances intra ont été obtenues grâce à des améliorations ciblées pour le tout intra et intra uniquement, les performances sans perte ne devraient pas être réellement ciblées.
Il y a des points bien plus importants pour améliorer les encodeurs AV1, et par ordre d'importance décroissante, à savoir :
Optimisations psycho-visuelles vidéo (je travaille principalement là-dessus et sur quelques autres développeurs) > Améliorations inter-codage ≥ Améliorations intra-codage ≥ Améliorations de la vitesse > Améliorations de la documentation > Sans perte.
Je préfère que le développement se concentre sur tout sauf la compression sans perte.
En outre, des améliorations ont été apportées au codage sans perte depuis fin 2020. Elles étaient mineures, mais suffisantes pour rendre AVIF toujours meilleur que PNG en sans perte. Il se situe désormais carrément entre WebP et PNG. N'oublions pas qu'en tant que format, AV1 est limité en termes de compression sans perte en raison de choix de conception délibérés, il sera donc pratiquement impossible d'obtenir des performances sans perte comparables à celles de WebP en 8b et JXL.
Il est toujours éclipsé par JXL, notamment dans les images photographiques en termes de performances sans perte.
AV1 a d'abord été conçu sur le codage vidéo et le format de codage intra général, et non comme un format d'image pur.
Si vous souhaitez un format d'image pur pour l'avenir, utilisez plutôt JPEG-XL.
Utilisez AV1 pour la vidéo et JPEG-XL pour la compression générale des images :D
Source : Reddit (https://www.reddit.com/r/AV1/comments/rkcx0o/we_need_to_rethink_avif_lossless_mode/), traduit de l'anglais.
-
J'ai rajouté l'information de la médiocre efficacité de AFIF en mode sans perte sur ce tableau :
Cliquer sur l'image pour zoomer :
(https://lafibre.info/images/format/format_image.webp) (https://lafibre.info/images/format/format_image.pdf#page=2)
-
Vivien, ce n'est qu'un détail, mais je pense que dans un certain nombre de tes tableaux des couleurs pourraient être remplacées pour que ce soit plus facile à comprendre pour un non-initié (c'est bien leur but).
Deux exemples:
- Support vert foncé, vert clair ou jaune en fonction de la date de support. A mon sens dès que le support est total il devrait être vert foncé et et s'il est partiel il devrait être jaune. La date d'introduction est une information intéressante mais il me semble que la prendre en compte n'a pas beaucoup de sens d'un point de vue synthèse finale. C'est vrai que pour les terminaux mobiles ça peut donner une indication du parc accessible (pour les anciens appareils qui ne peuvent plus être mis à jour), mais dans ce cas le code couleur devient un peu arbitraire... ex vert pour 2021 mais jaune pour 2022.
- Codecs vert foncés si le codec est "sans redevance" ou vert clair si le codec a ses brevets expirés. Ici aussi je ne pense pas qu'il y ait vraiment de différence pratique entre les deux situations qui mérite une différence de couleurs. On pourrait même arguer que les vieux codecs aux brevets expirés sont plus "sûrs" que les nouveaux codecs sans redevance avec patent pool et accords de partage, parce qu'il y a toujours la menace toute relative des brevets sous-marins. Exemple ici (https://www.sisvel.com/licensing-programmes/audio-and-video-coding-decoding/video-coding-platform-av1/#tab-introduction).
-
Merci pour tes conseils Cochonou.
Si tu vides le cache de ton navigateur pour charger la dernière version, tu pourras voir les évolutions.
J'ai supprimé le vert clair (passage de 4 niveaux à 3 niveaux) dans les colonnes suivantes :
- Navigateurs web
- Clients mail
- GIMP
- Profondeur maximale de couleur
- Taille maximale de l'image
- Type de licence
J'ai gardé le vert clair pour la performance de compression et les fonctionnalités.
Il y a maintenant 2 colonnes de performance : une pour la performance de compression avec perte (type JPEG)= et une pour la performance de compression sans perte (type PNG).
Cela met encore plus en évidence la nécessité que JPEG XL soit pris en charge par les navigateurs. JPEG XL est la demande la plus populaire parmi les développeurs lors de « Interop 2024 » – un projet créé pour promouvoir l’interopérabilité entre moteurs de navigateur. En tant que fonctionnalité la plus demandée lors d’Interop 2024, JPEG XL serait un candidat parfait pour cette nouvelle utopie d’interopérabilité. Les développeurs web sont très intéressés par l’utilisation du format JPEG XL, mais les membres du projet Interop ne vont pas jusqu’au bout. L’organisation a expliqué qu’elle avait rejeté la proposition JPEG XL parce que ses membres ne parvenaient pas à s’entendre sur son inclusion.
-
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)
(https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.webp) (https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.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.
(https://lafibre.info/images/format/202106_comparaison_des_formats_image_sans_perte.webp)
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.
-
Encore plus intéressant, j'ai trouvé un ensemble de 300 copies d'écran, de différentes tailles, encodées en PNG, WebP et AVIF.
J'ai trié ces copies d'écran par taille et j'ai regardé l'efficacité de la compression par paquet de 50 copies d'écran.
100% c'est la compression PNG, la référence.
Quand on a 200%, c'est que le fichier fait le double du fichier PNG, donc compression catastrophique.
Quand on a 50%, c'est que le fichier prend deux fois moins de place que le PNG.
Je vous laisse découvrir les résultats, c'est très intéressant et cela confirme que AVIF n'est pas bon sauf sur de très grandes images en mode "lossless".
Comparaison de l'efficacité de la compression sans perte de qualité entre PNG, WebP et AVIF : tests sur des captures d'écran de 4 ko à 12 Mo
(cliquez sur l'image ci-dessous pour ouvrir le document au format PDF)
(https://lafibre.info/images/format/compression_sans_perte_png_webp_avif.webp) (https://lafibre.info/images/format/compression_sans_perte_png_webp_avif.pdf)
-
je suis vraiment impressionné par le JPEG XL, on peut voir sa domination sans partage sur tous les autres formats dans toutes les catégories : https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
-
(https://lafibre.info/images/format/lossless_compression_png_webp_avif.webp) (https://lafibre.info/images/format/lossless_compression_png_webp_avif.pdf)
Oui, Jpeg XL est vraiment impressionnant sur de nombreux aspects.
C'est le format qui devrait remplacer tous les autres.
Je ne comprends pas sa suppression de Chrome et sa non-réintégration malgré de très nombreuses demandes (cf https://issues.chromium.org/issues/40270698 )
Et même une vidéo :
https://www.youtube.com/watch?v=VJaa1Le4W7c
-
C'est le format qui devrait remplacer tous les autres.
Je ne comprends pas sa suppression de Chrome et sa non-réintégration malgré de très nombreuses demandes (cf https://issues.chromium.org/issues/40270698 )
C'est politique, c'est une perte d'influence de Google sur le Web, son terrain de jeu. Le JXL ne vient pas de lui, n'en maitrise pas les tenants juridiques éventuels, etc. donc Google profite de sa domination sur le Web via Chrome (et sûrement via son moteur de recherche) pour tuer JPEG XL et imposer ses travaux (en espérant avoir le temps de les améliorer).
L'usage de codecs vidéos pour enregistrer des images a toujours donné de mauvais résultats, c'est évident. Je comprend pas que bcp s'entêtent dans cette voie. Enregistrer une vidéo dont les différentes images qui la composent sont interdépendantes ça n'a rien à voir avec enregistrer une image fixe... Donc vouloir mutualiser les codecs sur ce point est une hérésie : ça marche mal car au final la compression obtenue en vidéo est souvent obtenue avec du multiplexage, des systèmes d'images clé espacées, etc. Systèmes inapplicable et non efficient sur une image fixe...
-
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)
(https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.webp) (https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.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.
Je remets ici les résultats de mes tests fait ici avec Lightroom à partir d'un RAW de 20,4 MPix: https://lafibre.info/tv-numerique-hd-3d/liste-formats-image/msg1039076/#msg1039076
Le JPEG XL avec perte (qualité 80) fait mieux de 35% (SDR) à 47% (HDR) que le JPEG à qualité identique. Le sans perte n'existe pas sur le JPEG (même à qualité 100).
Sur le sans perte, JPEG XL fait mieux de 33% que le PNG en 8 bits/coul et de 29% que le PNG en 16 bits/coul.
Je ne parle même pas du TIFF zippé ou sans compression.
et je rajoute que l'AVIF SDR génère des fichiers environ 30% plus gros que le JPEG XL (avec perte, même réglage). À noter que JPEG XL sans perte vs. AVIF qualité 100 en SDR donnent des fichiers légèrement plus gros pour JPEG XL, mais je pense que AVIF qualité 100 n'est pas réellement du sans perte dans ce cas, que c'est plutôt (comme pour le JPEG) la compression minimale.
-
L'usage de codecs vidéos pour enregistrer des images a toujours donné de mauvais résultats, c'est évident. Je comprend pas que bcp s'entêtent dans cette voie. Enregistrer une vidéo dont les différentes images qui la composent sont interdépendantes ça n'a rien à voir avec enregistrer une image fixe... Donc vouloir mutualiser les codecs sur ce point est une hérésie : ça marche mal car au final la compression obtenue en vidéo est souvent obtenue avec du multiplexage, des systèmes d'images clé espacées, etc. Systèmes inapplicable et non efficient sur une image fixe...
Tout de même dans une vidéo des images "i" qui sont de véritables images.
Maintenant, il y a l'espace colorimétrique qui n'est pas le même (YUV en vidéo et RGB pour la plupart des images).
-
Le JPEG XL avec perte (qualité 80)
Je ne suis pas à l'aise pour la compression avec perte avec un paramètre de qualité : le paramétrage de qualité change selon le format d'image.
La qualité 80 du Jpeg équivaut à la qualité 82 du WebP et la qualité 64 de AVIF : (si tu as un comparatif avec JPEG XL, je suis preneur)
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), le 20 février 2021
-
Vivien, ce n'est qu'un détail, mais je pense que dans un certain nombre de tes tableaux des couleurs pourraient être remplacées pour que ce soit plus facile à comprendre pour un non-initié (c'est bien leur but).
Pour que cela soit plus accessible, j'ai fait une version simplifiée, qui se limite aux formats les plus populaires, car cela gêne les personnes d'avoir autant de formats d'images différents.
La liste complète est en page 2 du PDF (on ouvre le PDF en cliquant sur l'image).
Liste des formats d’image populaire et leurs fonctionnalités
Cliquer sur l'image pour zoomer :
(https://lafibre.info/images/format/format_image_populaire.webp) (https://lafibre.info/images/format/format_image.pdf)
-
C'est politique, c'est une perte d'influence de Google sur le Web, son terrain de jeu. Le JXL ne vient pas de lui, n'en maitrise pas les tenants juridiques éventuels, etc. donc Google profite de sa domination sur le Web via Chrome (et sûrement via son moteur de recherche) pour tuer JPEG XL et imposer ses travaux (en espérant avoir le temps de les améliorer).
On m'a soufflé dans l'oreillette que la moitié des créateurs de JPEG XL travaille chez Google (mais je n'ai pas vérifié cette information).
Cela dit même si c'est le cas, Google souffre d'un très gros syndrome NIH ("Not Invented Here"), même au sein de chaque branche, donc...
-
On m'a soufflé dans l'oreillette que la moitié des créateurs de JPEG XL travaille chez Google (mais je n'ai pas vérifié cette information).
Cela dit même si c'est le cas, Google souffre d'un très gros syndrome NIH ("Not Invented Here"), même au sein de chaque branche, donc...
Peut-être pas la bonne moitié ou pas la plus influente notamment par rapport à la branche s’occupant des codecs made in Google. Et peut-être tout simplement qu’on les a embauchés avec pour mission d’oublier JPEG XL mais de mettre à contribution ce savoir au service du made in Google exclusivement.
Google a toujours considéré internet comme son fond de commerce et son pré carré.
-
Je ne suis pas à l'aise pour la compression avec perte avec un paramètre de qualité : le paramétrage de qualité change selon le format d'image.
La qualité 80 du Jpeg équivaut à la qualité 82 du WebP et la qualité 64 de AVIF : (si tu as un comparatif avec JPEG XL, je suis preneur)
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), le 20 février 2021
L’appréciation de la qualité de l’image aussi, selon les paramètres étudiés (finesse/définition, respect des couleurs, des dégradés, des détails, etc.), on pourra dire que tel ou tel fait mieux ou moins bien avec un niveau de qualité identique.