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):
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..
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).
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).
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 😜
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.
Ç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:
Oui mais tu fais assez souvent, quand tu contribues à des projets open-sources, du "multi-remotes" avec le dépôt upstream et ton fork (origin). Et dès fois également les dépôts d'autres contributeurs.
Pour un auquel je contribue, j'en ai par exemple souvent au moins 5.
Quand je me suis fait cambriolé, on voyait une belle empreinte de pouce bien parfaite sur la vitre. Et bien les forces de l'ordre n'ont pas voulu passer (ni ouvrir une plainte si je me souviens bien car "il y a pas mal de vols réalisés par jour sur la commune et alentours : c'est finalement assez fréquent")
C'est la 1ère info donnée dans la vidéo de présentation dont le lien est donné juste au dessus : remote desktop, robots & drone, remote monitor et remote app.
[^] # Re: Bonne idée !
Posté par cosmocat . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 7 (+5/-0).
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.
[^] # Re: Mon expérience
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 2 (+0/-0).
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…
# L'idée me plait bien mais...
Posté par cosmocat . En réponse au journal Delta Chat 1.42 : le chiffrement de bout en bout plus simple et plus sécurisé. Évalué à 2 (+0/-0).
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):
J'avoue le 1er est plus pénible que le 2nd…
[^] # Re: Je ne comprends pas...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0).
J'avais utilisé ce script (je crois) pour faire mes tests qui donne le pourcentage à la fin:
https://codeberg.org/kylxbn/jxl-migrate
[^] # Re: Je ne comprends pas...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 3 (+1/-0). Dernière modification le 08 février 2024 à 13:48.
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 !
[^] # Re: Je ne comprends pas...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0). Dernière modification le 08 février 2024 à 10:16.
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.
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).
[^] # Re: Moche
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+3/-1).
Merci pour ces longues et détaillées explications pour des informations que j'essayais de donner succinctement.
J'aime beaucoup ce résumé:
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 5 (+4/-1). Dernière modification le 07 février 2024 à 13:48.
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…
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0).
+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 😜
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 5 (+3/-0).
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é.
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 10 (+9/-0).
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.
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.
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 5 (+3/-0).
Ce n'est ni l'avis de Cloudflare, ni celui de Facebook ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 ).
[^] # Re: L'avis de Google...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 3 (+2/-1).
Ç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…
[^] # Re: Je ne comprends pas...
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 8 (+6/-0).
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).
[^] # Re: Moche
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 6 (+4/-0).
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…)
[^] # Re: Moche
Posté par cosmocat . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 10 (+9/-0).
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
[^] # Re: C'est vendredi
Posté par cosmocat . En réponse au lien Votre PC n'est pas supporté par Windows 11 😱 ? Démarrez en 2024 avec un nouvel OS 🦸. Évalué à 5.
Mais effectivement il faut être au courant que les alternatives existent et avoir un minimum de connaissances informatique et d'envie…
[^] # Re: Futur de Subversion
Posté par cosmocat . En réponse au journal github et subversion c'est fini (ou de l'importance d'une bonne communication). Évalué à 2. Dernière modification le 14 janvier 2024 à 20:39.
Oui mais tu fais assez souvent, quand tu contribues à des projets open-sources, du "multi-remotes" avec le dépôt upstream et ton fork (origin). Et dès fois également les dépôts d'autres contributeurs.
Pour un auquel je contribue, j'en ai par exemple souvent au moins 5.
# Réponses le 24 janvier
Posté par cosmocat . En réponse au lien Des énigmes mathématiques pour entrer dans 2024 avec l’esprit aiguisé. Évalué à 2. Dernière modification le 11 janvier 2024 à 16:02.
Donc à pas commencer maintenant si vous voulez savoir si vous avez trouvé les bonnes réponses…
[^] # Re: Qui en veut ?
Posté par cosmocat . En réponse au journal De la disparition du format « pas trop grand ». Évalué à 3.
Alors qu'on sait que c'est l'Ergo-L qu'il faut utiliser :D
https://ergol.org/
# Mouler sur YT
Posté par cosmocat . En réponse au journal L'aviation a-t-elle un avenir ?. Évalué à 6.
Mouler sur invidious a quand même beaucoup plus de valeur que mouler sur YT.
https://invidious.projectsegfau.lt/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DscaFNSgo7ew
Ce qui me permet de mentionner la très bonne extension pour Firefox: libredirect
[^] # Re: Ni cache ni cookie de session
Posté par cosmocat . En réponse au journal J’ai tenté de libérer une habitation, mais l’ayant-droit nous a mis des bâtons dans les roues. Évalué à 5.
Quand je me suis fait cambriolé, on voyait une belle empreinte de pouce bien parfaite sur la vitre. Et bien les forces de l'ordre n'ont pas voulu passer (ni ouvrir une plainte si je me souviens bien car "il y a pas mal de vols réalisés par jour sur la commune et alentours : c'est finalement assez fréquent")
[^] # Re: Hors sujet
Posté par cosmocat . En réponse au journal Disparition de Jacques Delors. Évalué à 3. Dernière modification le 29 décembre 2023 à 09:45.
Y'aura-t-il une rubrique 'précrastination' également? Que l'on pourrait créer tout de suite, même si c'est mal fait: https://www.psychologies.com/Travail/Souffrance-au-travail/Stress-au-travail/Interviews/La-precrastination-cet-autre-trouble-de-l-organisation
[^] # Re: oui mais
Posté par cosmocat . En réponse au lien Kyber, le nouveau projet open source de Jean-Baptiste Kempf (VLC). Évalué à 5.
C'est la 1ère info donnée dans la vidéo de présentation dont le lien est donné juste au dessus : remote desktop, robots & drone, remote monitor et remote app.
# En parlant de base de données...
Posté par cosmocat . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Une base de données de base de données:
https://dbdb.io/