cosmocat a écrit 2091 commentaires

Je voulais poster ce lien mais avec un titre plutôt similaire à "jxl 0.10 : Google tend l'autre joue".

Lecture très intéressante et on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* un nouvel encodeur "jpegli" a été écrit en utilisant des avancées de jxl qui produit des jpeg de plus petite taille que webp.

Mon ressenti du seul point négatif de jxl: difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.

Le version 0.10 juste sortie est donc pour to:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

au but du protocole Gemini et son format le "Gemtext" (syntax markdown un peu simplifiée).

…car pas sûr que ça convienne mais tu n'as pas cité Mermaid pour générer des SVGs:
https://github.com/mermaid-js/mermaid
http://mermaid.js.org/#/

Qui doit pouvoir être utilisé en ligne de commande:
https://github.com/mermaid-js/mermaid-cli

Si on veut parler d'efficacité c'est dvorak et bépo qu'il faut aller regarder

Apparemment il y a mieux: "Ergo‑L est meilleur que Bépo pour le Français, meilleur que Dvorak pour l’Anglais et meilleur que Qwerty pour la programmation !"
https://ergol.org/

Oui, tapé sur un smartphone, et je m'en suis aperçu qu'après la fin du délais de possibilité de modification…

Il est le père d'Aurore Bergé.

(utilisez un ^ ou un ~ si vous êtes joueur !)

Je les utilise souvent sans souci.

Moi, j'ai eu quelques soucis ;)
Il y a 2 façons de faire la caractère ^ sur un clavier azerty.
J'avais l'habitude de le faire d'une des 2 façons et j'ai appris à la faire de l'autre façon (altgr+9) car la 1ère façon (^+espace) faisait freezer complètement (impossible de récupérer) ma machine lors du login pour une session KDE il y a quelques années. Je ne sais pas si c'est toujours le cas.

Vu que tu rajoutes un sel qui peut être déduit du site cela n'apporte aucune sécurité supplémentaire.

Oui et non ;)

Le but d'un sel est d'invalider le plus possible l'usage de rainbow table (valeurs déjà pré-calculées par l'attaquant avant de vouloir s'attaquer au craquage de ton mot de passe)

Que la valeur du sel soit connue n’empêche pas que cela invalide un bonne partie des valeurs de ces rainbows tables.

Et plus les valeurs de sels sont grandes et aléatoires, plus ça a de chance d'invalider une partie de ces rainbow tables.

C'est pourquoi outre le domaine du site web, je conseille très fortement, comme il ne peut pas générer un sel aléatoire car c'est l'opposé du but recherché par son outils, de quand même concaténer un sel constant assez long (plus il est long, mieux c'est).

Si il peut le conserver secret, c'est mieux, bien évidemment mais default il peut être publique.

Et je peux ajouter (car j'ai été suis un contributeurs de UniquePasswordBuilder. Coucou Grégory !) que sha256 est plutôt un mauvais choix pour hasher un mot de passe car cette fonction est plutôt optimisée pour utiliser le moins de ressources possibles (mémoire et cpu) et n'est pas idéale contre le brute force.

C'est pourquoi on a ajouté le support de argon2 qui lui est spécifiquement fait pour être lent et nécessiter pas mal de mémoire.

Ce retour d'expérience ne permet pas de conclure grand chose. Lossless ou lossy? Quel niveau de compression pour jxl ?
Car si c'est trop long, il faut essayer de compresser avec le niveau le plus faible pour gagner en temps et voir si la taille est satisfaisante par rapport à webp…

J'ai testé rapidement delta chat et y'a 2 "détails" que je trouve pénible et qui a fait que, même si j'aime bien l'idée, je n'ai pas poussé l'utilisation auprès de connaissances (qui n'utilisent pas forcement déjà des applications de chat):

1. Si un utilisateur n'a pas delta chat et donc utilise le mail pour répondre, les messages sont assez moches et pas très facile à lire avec dans la bulle de chaque message un lien cliquable qui est affiché "Show full message..". Je voudrais bien qu'il y ai qu'un indicateur visuel et que l'action soit possible que quand le message est sélectionné sinon c'est plutôt pénible à lire..
2. Au final, ça peut encombrer la boite mail et l faut (potentiellement) apprendre à ceux qui maîtrisent pas trop l'outil informatique comment créer une règle automatique pour classer automatiquement les message (et ne pas les laisser dans la boite de réception).

J'avoue le 1er est plus pénible que le 2nd…

J'avais utilisé ce script (je crois) pour faire mes tests qui donne le pourcentage à la fin:
https://codeberg.org/kylxbn/jxl-migrate

Mes tests avec un pool de photo nettement plus important me donnais un chiffre plutôt entre 16 et 18%.

Mais ça dépend peut-être du niveau de compression initial des photos et ma mémoire me fait peut-être également défaut…

Cependant, c'est une excellente fonctionnalité très appréciable !

Mais PNG peut aussi faire de la compression avec perte à priori.

De ce que je comprend, non PNG ne fait pas de la compression avec perte mais c'est plutôt qu'on applique des filtres qui "dégradent" l'image (donc comme avec perte) avant compression pour exploiter les spécificités de l'algo de compression de png et donc obtenir des meilleurs résultats. Le but étant, comme les algo de compression avec perte de trouver les bons filtres qui dégradent visuellement l'image le moins possible.

Est-ce qu’il n’y en a aucun et que se sont juste les progrès en mathématiques, en algorithmie ou encore en électronique qui on permis cette amélioration ?

Pour moi, oui, ce sont des avancées algorithmiques/mathématiques qui permettent l'amélioration. Il ont trouvé un manière plus futée d'encoder les données (ou de dégrader l'image pour que l'algo l'encode mieux).

Merci pour ces longues et détaillées explications pour des informations que j'essayais de donner succinctement.

J'aime beaucoup ce résumé:

L’opposition à JPEG-XL ne peut pas être technique, JPEG-XL est meilleur que les autres et de loin. Il ne reste donc que la politique et l’économie.

Ouais, on a la chance d'avoir un format ayant des avantages sur les autres (support du décodage progressif, précision suffisante pour le support HDR,…), intérêt par de nombreux acteurs (cloudflare, Facebook, Adobe,…) et tout cela bloqué par un seul acteur.

Je suis presque enclin à penser que c'est un abus de position dominante…

+100!
Et je peux ajouter que jxl, en terme de fonctionnalités, capacités (je me permet de remettre ce bon résumé https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg ) et cas d'usage est meilleur dans tous les cas que tous les formats pre-existants. Donc pour la facilité d'usage, y'a pas photo (un seul format pour tout la chaîne, tous les logiciels,…). Y'a que avif qui peut avoir un avantage dans les très fortes compressions mais ça en devient peut-être même un cas d'usage de niche. Pour tout le reste, il y a jxl 😜

Heu… Un support derrière un flag, c'est juste pour faire des tests, jamais pour que ce soit adopté. Donc c'est normal que t'en ai jamais croisé.

Je n'ai jamais vu de JPEG-XL sur le web.

Y'a une expression que j'aime bien pour illustrer cela: "On ne décide pas de construire un pont en comptant le nombre de personnes qui traversent à la nage…"

Donc t'en a pas vu pas parce que le format n'a pas d’intérêt mais plutôt car personne n'a d’intérêt à servir des jxl tant que ce n'est pas supporté par les navigateurs.

Des webp, oui en pagaille

Y'en a effectivement mais c'est tellement specifique au web qu'il y a pleins de logiciels qui ne le supporte pas contrairement au jxl qui est un format qui couvre tous les usages et donc qui pourrait être utiliser par tout les logiciels.

Ce n'est ni l'avis de Cloudflare, ni celui de Facebook ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 ).

Ça on sait que c'est un peu du foutage de gueule car le format qui est en train de se répandre dans les navigateur est avif et même si la compression est plutôt bonne, on sait que les perfs sont moins bon tout particulièrement comparé au jxl…

Jpeg XL possède 2 modes de compression: sans perte (comme png) et avec pertes (comme Jpeg).

Et on dit que jxl est à même de remplacer les 2 car dans les 2 cas, la compression est meilleure. Sans compter les autres fonctionnalités permises.

Pour les autres formats, il y a toujours des cas particuliers/de niche où png ou Jpeg est meilleur pour une raison ou une autre alors que jxl, quel que soit le critère est meilleur que ces 2 anciens formats.

Donc oui, jxl est à même de remplacer les 2 pour un usage photo ou dessin.

Je te conseille de lire le comparatif que j'ai donné dans un autre commentaire…

Par contre, autant avant avec l'extension tu pouvais savoir si c'était avec ou sans perte et beaucoup ne maîtrisent pas la notion comme tu viens de l'indiquer donc avec un seul format qui fait les 2, il va y avoir des erreurs humaines… (mais en même temps ça a aussi un côté pratique).

Oui, il y a une conversion lossless (donc bijective) du Jpeg vers le Jxl qui apport une gain de 15 à 20% environ.
Aussi, l'algo the decompression du jxl est capable de décompresser le jpeg donc il n'y aurait pas 2 algos à maintenir, celui du jxl remplaçant celui du jpeg.

Je me demande même si, une fois le support dans les navigateurs ajouté, il n'y aurait pas moyen de renvoyer automatiquement du jxl là où du jpeg est demandé pour économiser de la bande passante sans avoir à adapter les sites webs ("migration" sans avoir à rien faire…)

En terme de temps à investir pour migrer loin de l'utilisation de leur format webp, oui, ça peut être pertinent comme remarque.

En terme purement de technologie, non, ça n'a pas de sens. Avif et Jpeg Xl sont autrement meilleur que webp (conçu il y a plus de 10 ans).
Cf l'infographie "Battle of the codecs" en bas de cette page:

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg