Mozilla veut améliorer la compression JPEG avec mozjpeg
Mozilla lance aujourd'hui un nouveau projet baptisé mozjpeg qui vise à améliorer la compression JPEG et ainsi réduire le poids des images.
Dans un billet de blog expliquant la démarche, Josh Aas, le Senior Technology Strategist de la fondation, rappelle que les images sont les éléments qui consomment le plus de bande passante. Pour réduire la taille des fichiers, l'une des solutions consiste à mettre au point un format plus efficace, mais Mozilla souligne qu'il y a un inconvénient majeur avec ce choix.
Le JPEG est utilisé depuis plus de 20 ans, une longévité qui l'a fait devenir un format universel, pris en charge par tous les logiciels. Introduire un nouveau format d'image impliquerait qu'il faudrait refaire tout ce travail de compatibilité. Une tâche qui pourrait prendre plusieurs années, estime Josh Aas.
Mozilla attaque en creux le format WebP de Google, qui n'est pris en charge que par Chrome, Opera et le navigateur d'Android à l'heure actuelle. En octobre, la fondation avait mené une étude sur WebP dont la conclusion était que ce format n'offrait pas une amélioration significative par rapport au JPEG en matière de compression.
Plutôt que de se lancer dans l'adoption du format de Google, Mozilla a décidé d'optimiser le JPEG. C'est ainsi qu'apparaît mozjpeg, un fork de libjpeg-turbo qui comprend jpgcrush, un script perl qui permet de réduire la taille des fichiers sans perte. jpgcrush est capable de réduire de 10 % la taille d'un fichier en moyenne, d'après un test réalisé sur un échantillon de 1 500 images provenant de Wikimedia.
Y sont fatigants avec leurs guéguerres.
Bien sûr qu'une évolution est souhaitable. Si ça prend des années n'est pas en raison de cette façon quasi hormonale qu'ont les entreprises de marquer les technologies de leurs empreintes? Aujourd'hui, le .svg commence enfin à trouver sa place. Et un avenir très prometteur l'attend. Je l'espère. Le .png aussi, mais son gros problème est son poids quand il inclus la transparence (poids parfois très variable d'ailleurs selon le contenu de l'image). Revisiter le jpg sans la transparence n'est pas très actuel il me semble.
svg,
png,
jpg
couvrent des besoins différents.
Svg est vectoriel, ce n'est pas la peine, ça ne sera JAMAIS utilisé pour là où jpeg est efficace.
Png est SANS compression à perte, c'est très important, et ça justifie son existence à coté de jpeg.
Jpeg avec transparence existe, le format n'a jamais percé. Est-ce encore pour cause de brevets (avec d'autres améliorations) ou par désintérêt total de toute l'industrie ?
On va finir par des solutions à coup de masque déclaré à coté de la jpeg en CSS avant d'avoir la transparence native dans le jpeg utilisé par tous :)
-
Bon Mozilla, c'est bien gentil tout ça, mais la correction du bug 18574 pour rétablir le format qu'on attend tous: MNG ! :) ( https://bugzilla.mozilla.org/show_bug.cgi?id=18574 )
-
Jpeg n'est pas le format qu'on méritait mais c'est celui dont on avait besoin.
« Le .png aussi, mais son gros problème est son poids quand il inclus la transparence»
J'ai découvert il y a quelques temps (et je ne peux plus m'en passer) que le PNG 8 bits (très léger) gère sans problème la transparence.
Dans le détail s'agit simplement de déclarer dans la palette de couleur indexée une ou plusieurs couleurs incluant le degré de transparence. Ce n'est pas plus lourd que sans.
Heureusement, un petit logiciel fait ça très bien et sans effort: ImageAlpha (http://pngmini.com/)
Cerise sur le gateau ça permet aux développeurs web d'utiliser des images avec transparence même avec de très vieux navigateurs comme IE6 qui ne la supportaient pas.
Sinon concernant le JPEG, pourquoi son hégémonie ?
Parce que c'est le meilleur, tout simplement.
Si on l'utilise à bon escient, la perte de données est invisible, et c'est incroyablement optimisé (vitesse de traitement) ce qui explique que JPEG 2000 n'ait jamais percé (trop gourmand en ressources, trop lent à compresser/décompresser) malgré ses qualités.
Pourquoi n'as t'on rien trouvé de plus efficace que le jpeg depuis autant de temps ? En matière de compression vidéo, il semble que cela soit possible. (Mpeg2, H264,H265).
parce que tout simplement on l'a déjà fait, mieux que jpeg.
Il y a jpeg2000
il y a des formats à compressions dites en "wavelets", etc.
Mais entre les brevets, le désintérêt des éditeurs de logiciels (et des utilisateurs et designers : jpeg est efficace) et le manque de support natif dans les navigateurs/systèmes, ces formats ne peuvent pas se répandre.
Mais bien évidemment que le génie humain a pondu déjà mieux que jpeg ^_-
"il y a des formats à compressions dites en "wavelets"
Yep. Même que à l'origine c'était "ondelettes", inventé par le Français Jean Morlet et traduit ensuite en "wavelets". Cocorico.
En francais on dit ondelettes, en anglais on dit wavelets.
Utiliser Wavelet en francais est un anglicisme.
Ce qui est pénible avec la multiplication des formats de fichier, c'est que le web se morcelle. Comme au bon vieux temps d'Internet Explorer. Les acteurs du web devraient se mettre d'accord une bonne fois pour toutes pour créer des formats de fichiers universels et arrêter de nous prendre la tête. Le passage du web au Retina aurait pu être l'occasion de mettre à jour le format jpg, ou si ça a déjà été fait, de communiquer un peu plus auprès des développeurs web. Ça ne me parait pas compliqué, pour Apple, Microsoft, Google et Mozilla de trouver un terrain d'entente et dire "Ok ce format de fichier là est optimisé pour les écrans Retina donc on va tous en assurer la prise en charge dans nos navigateurs". Au lieu de ça chacun avance dans son coin... C'est risible.
Euh..
"Le passage du web au Retina"
Depuis quand le web est passé au Retina ?
Et puis c'est Apple qui à sorti son retina sans rien demander à personne.
Pour qu'au final, ce soit les devs qui se retrouve a gérer je ne sais combien de format, (entre les nav, les codecs video, et maintenant les images...)
@samshit :
Depuis que les gens qui ont un écran retina pensent que tout leur est dû :P
@samshit
Pauvre chou... Je vois que t'as absolument rien compris à mon commentaire.
Le fait est que les ordinateurs sont en train de suivre le même chemin que nos téléphones et nos tablettes, qui sont tous et toutes passées au Retina. Alors tu peux faire ta pleureuse et te plaindre parce qu'on te donne un peu de travail supplémentaire (C'est tellement intolérable de devoir gérer une instruction de plus et un format de fichier supplémentaire t'as vu). Tu peux même dire que c'est Apple qui t'as IMPOSÉ le retina si ça te chante. Mais moi j'en ai absolument rien à foutre de tes états d'âme.
Developpeur Web c'est un métier.
"Pour qu'au final, ce soit les devs qui se retrouve a gérer je ne sais combien de format, (entre les nav, les codecs video, et maintenant les images...)"
Au début d'internet, tous les sites étaient optimisés soit pour le 56K soit pour le haut-débit. Et on te posait la question avant d'entrer. Aujourd'hui t'as même plus besoin de poser la question, le navigateur répond à ta place. Dans tous les lecteurs vidéos, t'as le choix de la résolution. Le choix du Retina dans le navigateur c'est Oui ou Non. Donc arrête un peu ton cirque et remets toi au boulot.
Et si t'avais pris le soin d'essayer de comprendre mon point de vue, t'aurais peut-être réalisé que justement je ne demande qu'une seule chose c'est la standardisation des formats. Ça veut dire abandonner tous les formats parasites moins bons (libres ou pas peu importe) pour n'en garder que le strict minimum. Et tu supportes 2 codecs par media, en fonction de la qualité exigée. T'as rien besoin de plus.
J'ai même tendance à penser qu'on devrait généraliser l'uniformisation des formats de fichiers à l'ensemble de l'informatique, dans un souci d'interopérabilité absolue.
Le Web n'est pas passé au Retina. Le web passe au Retina. Donc autant se mettre d'accord le plus rapidement possible plutôt que de laisser passer le train sans réagir.
"Ce qui est pénible..."
Et attends, tu n'es pas au bout de te peines sachant qu'il y a désormais collaboration entre le W3C (standards web) et l'IDPF (standard livre numérique) en vue de prendre les problématiques des éditeurs en compte et d'adapter/compléter les standards web pour le livre numérique (EPUB étant basé sur HTML, CSS et JS).
Sachant que les spécifications EPUB sont les plus mal rédigées depuis celles de XHTML, et sachant à quel point elles morcellent les specs web avec des "interdictions" et "subsets" dans tous les sens, on va je pense bien se marrer (exemple : le positionnement absolu n'a que le droit d'être utilisé pour un type de fichiers, à la mise en pages fixe, dans la prochaine version d'EPUB, elle ne peut pas l'être pour tous les fichiers...). Je ne parle même pas de l'ontologie epub:type qui n'a même pas été pensée à la base pour pouvoir être facilement intégrable aux standards web... alors qu'elle pourrait largement y être utile.
Voilà voilà, c'est la prochaine bombe à attendre niveau web, et ça va pas être beau à voir sachant qu'Adobe et ses propositions irréalistes et complexes à en crever sont très souvent privilégiés lorsqu'il faut faire des choix sur l'évolution du standard EPUB...
@Jiminy Panoz
Je savais que le monde du ePub n'était pas tout rose. J'étais loin de me douter que c'en était à ce point !
Bon courage alors !
Pourquoi forker au lieu de simplement contribuer au projet ? Ils ne les laissaient pas faire ou quoi ?
Avec le déclin de Mozilla annoncé hier , ce projet mozpeg à un avenir assuré et tout tracé......
Le jpeg est complètement nul comme format , j'estime qu'à l'heure actuelle on a les moyen d'avoir de belles images avec de belles couleurs, sans perte aucune... Avec JPEG les couleurs sont nazes, infidèles et incomplètes et en plus on perd la majorité de l'image... Pourquoi les reflex ne prennent pas en jpeg (en général)? Ahah
Et moz veut encore enlaidir tout ça! Pfff!!!
Vive le PNG dans ce cas !
@ipaforalcus :
Le JPG change les couleurs... Tu l'as sors d'où celle-là ? o0
@Strix :
"l'as" -> "la"
@Strix
Peut être qu'il parle du nombre de couleurs codées, limite a 8bit par couche il me semble?
Ce qui me gêne plus c'est le codage par carrés de 8x8 pixel qui se fait ressentir assez vite quand on augmente le taux de compression
@ipaforalcus : Le JPG est encore le format par défaut de toutes les agences photos du monde pour envoyer des fichiers à leurs clients. Le RAW étant gardé en interne pour plus tard ...
Concernant le PNG je ne l'utilise que si j'ai besoin de transparence sur une image. Sinon le JPG est largement suffisant, et de temps en temps du GIF.
3 formats de fichiers à gérer ne me semble pas insurmontable pour créer des sites internet.
Le PNG, c'est vrai qu'il compresse en lossless... mais cela reste du 24 bit, donc ce n'est pas si différent. De toute façon, JPEG n'est pas un format d'archive, c'est juste un format final pratique pour donner à des clients où montrer sur un site web.
Et faut pas non plus mettre la compression du JPEG à 50% non plus...
@pecos et en correction à ce que j'ai écrit;
Juste après avoir commenté ici, j'ai découvert aussi imagealpha. C'est génial en effet.
Le plus amusant est que la meilleure technologie de compression d'image fixe est actuellement le H265 (c.f profil «Main Still Picture») :
http://fr.wikipedia.org/wiki/H.265/HEVC#Performances
Quel doooooÔooooommage pour MOZILLA ... ;-D