FLIF, un nouveau format d’image taillé pour le web
Le JPEG est devenu la norme de facto sur le web, on le retrouve partout et toutes les tentatives pour le remplacer ont jusque-là échoué. À part pour les images animées qui exploitent le GIF et pour celles avec transparence qui sont restées au PNG, le JPEG reste largement dominant, alors même que Google essaie depuis des années d’imposer son propre format, le WEBP.
Malgré tout, le JPEG est un format ancien et qui a mal vieilli. Les images dans ce format pèsent lourd pour une qualité moyenne et on sait faire beaucoup mieux à l’heure actuelle en matière de compression. Concrètement, les techniques existent pour réduire la taille des images à qualité égale par rapport au JPEG et cela explique pourquoi des développeurs proposent régulièrement de nouveaux formats.
Nous avions évoqué en décembre dernier le BPG, un format très prometteur. Un JPEG de 2 Mo est converti en un fichier de 150 Ko, quasiment sans perte de qualité entre les deux. Mais voici un nouveau format, encore plus performant et qui a surtout l’avantage d’avoir été pensé pour le web : le FLIF (pour Free Lossless Image Format).
Derrière ce nom étrange, un format basé sur un nouvel algorithme de compression (le MANIAC qui est une variante du CABAC). Le FLIF est un format sans perte, c’est-à-dire que la qualité d’image reste strictement la même, mais cet algorithme permet de réduire la taille des fichiers à hauteur de 10 % par rapport à ses concurrents. C’est bien, mais ce n’est pas son meilleur argument.
La force du FLIF, c’est qu’il est parfaitement adapté au web. Chaque image dans ce format contient en fait une multitude de versions de moins bonne qualité. Cette approche a deux avantages sur internet : on peut obtenir immédiatement un aperçu de qualité médiocre en attendant que l’image se charge complètement ; un même fichier de base peut servir autant d’image Retina que de version standard.
Une image FLIF affiche immédiatement un aperçu de la version finale, avant de charger la version complète en passant par plusieurs versions intermédiaires. On a ainsi plus rapidement une idée du rendu final, alors que les formats traditionnels, comme le JPEG, chargent les images progressivement, du haut vers le bas. Et si on utilise une image quatre fois plus grande pour les écrans Retina, le FLIF arrête le chargement quand on a chargé une qualité suffisante.
Une excellente idée, mais qui restera au stade du concept si les navigateurs et les sites internet n’adoptent pas ce format. C’est bien là que le bât blesse, et le créateur de FLIF a beau glisser dans sa liste « À faire » la compatibilité avec les navigateurs, rien ne dit qu’Apple, Google et les autres adopteront ce format.
Même si elle est théorique, l’expérience reste intéressante et ce format a le mérite de chercher des solutions originales. Si le FLIF vous intéresse, le code source complet est disponible à cette adresse.
Jpeg not dead!
...just smelling funny...
lel +1
Wah, ce format a vraiment de bons arguments. Espérons que ça évolue au niveau des navigateurs...
brevets ?
droits d'auteur ?
tutti quanti ?
@guigus31 :
Malheureusement... Mais c'est dommage car il existe tellement de progrès à faire face à ce vieux format.
"CABAC [...] est un type de codeur entropique utilisé dans la norme de compression vidéo H.264 ou MPEG-4 AVC." Ca sent les problèmes de brevets comme le BPG, il y a donc peu de "chance" que soit massivement implémenté dans les navigateurs web ni même ailleurs. https://fr.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
Néanmois sur le site du projet, on peut lire "Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is completely royalty-free and it is not encumbered by software patents". De plus, l'implémentation est libre sous GPLv3+. http://flif.info/
"Et si on utilise une image quatre fois plus grande pour les écrans Retina, le FLIF arrête le chargement quand on a chargé une qualité suffisante." Ce qui suppose tout de même de charger tous les qualités inférieures, l'affichage est donc progressif mais au final plus long et plus consommateur en bande passante. De plus, ce problème a été résolu au niveau du HTML avec l'attribut srcset. http://html5hub.com/srcset-attribute-solving-responsive-image-dilemma/
@RyDroid :
Le srcset est moins d'être une solution satisfaisante.... Il faut toujours l'images en plusieurs fichier de taille différence ce qui complique bien les choses ! Le FLIF semble une bien meilleure solution si adopter
Quand les écran ont pu afficher des image couleurs au lieu du moniochrome, on a pas envoyé 4 images avec des conditions d'affichage et laissé le "lecteur" se demerder pour retrouver les couleurs.
On a intégré la problématique dans le format.
C'est exactement ce que je dis depuis 2 ans... Content que quelqu'un (techniquement beaucoup plus pointu que moi) l'ai réalisé.
Et puis FLIF fonctionnera aussi en EDGE sur un écran Retina (là ou srcset est une solution batarde).
"alors que les formats traditionnels, comme le JPEG, chargent les images progressivement, du haut vers le bas"
En Jpeg entrelacé aussi on a une première version basse qualité. Mais il y a quelque chose que je n'aime pas dans ces formats progressifs, c'est qu'on n'a pas une idée claire de quand l'image est réellement entièrement téléchargée (si c'est normal qu'elle reste un peu floue, par exemple).
Bref, personnellement j'ai été super séduit par BPG et j'aimerais qu'il devienne un standard. Ou sinon, un dérivé de VP9. Le Lossless, c'est pas non plus ce qui prend le plus de place dans une page... à part des gros gifs animés, mais vu le nombre de couleurs et les sources de ces anims, lossless est un terme presque abusif.
Le jpeg2000 proposait déjà presque tout ça: lossless optionnel, progressif en chargeant d'abord une version basse résolution etc...
J'invite donc nos amis développeur C++ sur MacOS de l'implémenter dans WebKit
et dans chromium.
Si l'API de ce format est libre ce ne devrait pas être insurmontable.
Un fois la chose dans le le kit le soumettre à la communauté.
Généralement l'adoption dans le navigateur par Apple et Google se fait via la popularité dans ces versions libres. (sauf si bien sur le constructeur veut mettre sa propre techno concurrente en avant)
L'adoption du JPEG c'était faite au forcing les promoteur du format avaient eux même implémenté le format dans les navigateur ne le supportant pas soit en publiant des versions adapté pour les navigateur open sources soit via des addon pour les autres.
Il ne faut rien attendre des constructeurs. S'ils n'y voient pas une opportunité de se démarquer il ne ferons rien. et c'est typiquement le genre de truc qui ne peut les démarquer.
AJYT
Bonne initiative, mais tout bon developpeur web, s'il ne peut pas être compatible avec tous les navigateurs, cherche au moins une compatibilité de l'ordre de 80% du parc installé, vieux navigateur compris.
On commence tout juste à utiliser des normes W3C d'il y a 10 ans..
Tenter de faire adopter un format sans passer par une normalisation ?
Autant publier tout de suite.
il peut très bien être utilisé par un navigateur comme opéra qui sur mobile, créé un rendu sur leurs serveurs, compresse la page et la renvoie à l'utilisateur. Ça fait ainsi une page beaucoup plus petite et qui se charge plus rapidement. Dans ce cas, les images s'afficheraient instantanément et seraient en réalité une conversion des images originales du site dans ce format par leur proxy.