🚲 Tanguy Ortolo a écrit 12196 commentaires

Oui, c'est conçu pour ça. Et je viens d'essayer, sur une image JPEG de 1,9 Mio, j'obtiens une image JPEG XL de 1,5 Mio sans perte supplémentaire.

C'est le gros intérêt du JPEG XL, la fonctionnalité qui semble anecdotique mais qui tue, en fait : on peut prendre une ensemble de millions de photos en JPEG, et bourrinement transcoder tout ça en JPEG XL sans risquer d'avoir des remords.

Mieux encore, JPEG XL est capable de se transcoder vers JPEG, toujours sans perte. Voire même, encore mieux, à condition d'avoir stocké les métadonnées d'origine, de reconstruire exactement le JPEG d'origine ! Évidemment, le résultat est plus gros, mais ça permet de servir du JPEG à ceux qui ne savent pas lire le JPEG XL.

Personnellement, je ne suis pas du tout surpris qu'il faille prendre des précautions lorsqu'on utilise un format d'image compressée pour stocker quelque chose qui n'est pas une image.

Les formats d'image sont faits pour permettre de restituer une image de façon à ce que nous la percevions de façon acceptable (avec perte), indiscernable de l'originale (avec pertes imperceptibles), ou identique à l'originale (sans perte perceptible ni mesurable).

Si on commence à utiliser ça pour autre chose que des images, c'est du détournement de la fonction du format, et on commence à devoir travailler contre ses optimisations.

À noter que WebP dispose carrément d'un mode « presque sans perte », qui applique des modifications mineures aux couleurs des pixels, censément imperceptibles, pour que ça se compresse mieux.

Conserver l'intégralité de l'image numérique est une priorité quand on travaille dans l'Art,

Quand on travaille dans l'art, sans majuscule. Travailler dans l'Art, c'est le domaine des artiseurs dans l'œuvre de Robin Hobb. :-)

Pour TIFF, c'est compliqué.

Pour XCF, ce n'est pas à proprement parler un format d'image raster, c'est un format de fichier de travail de logiciel de traitement d'image raster. En particulier, il permet de stocker des calques et des modes de superposition de ces derniers : c'est une fonctionnalité qui n'a aucun intérêt pour stocker simplement une image, mais qui est indispensable pour stocker sans perte un travail graphique matriciel.

Le format XCF n'est aucunement en concurrence avec PNG, JPEG et compagnie. En revanche, il existe un format standard, ouvert, qui peut être considéré pour un stockage interopérable de travaux graphiques : OpenRaster.

Certainement. Pour obtenir un truc facile à distribuer, on repassera en revanche.

Oui alors forcément, à part JPEG et PNG, on n'aura jamais de format vraiment universel, si on entend par là supporté par absolument tout.

Par contre, WebP est suffisamment répandu pour qu'on puisse s'attendre à :

• un support par tous les navigateurs, tous les afficheurs et outils de traitement d'image ;
• pouvoir ouvrir des bugs pour les logiciels qui ne le supporte pas, et que ces bugs ne soient pas immédiatement fermés parce que c'est un format exotique dont tout le monde se moque.

Bon, vous auriez un exemple, histoire qu'on puisse comparer sérieusement ?

Pour info, avec une image de 16×16, toute transparente avec quelques traits de noir pur, j'obtiens :

• un PNG optimisé de 1 kio ;
• un GIF de 767 octets ;
• un WebP de 62 octets.

Ouille, ça pue ça. Je me demande quel est l'intérêt de Google là-dedans. Espérons qu'ils y reviendront si tout le monde s'y met.

Après tout, Mozilla a mis trois ans avant de considérer l'ajout de WebP à leurs logiciels. Là, Google ont foncé pour intégrer JPEG XL dans Chrome, puis ont fait marche arrière. Au moins, ils sont techniquement prêts à le remettre.

Alors non, pas pour des icônes toutes petites. Du SVG, ça reste du XML, assez verbeux.

Comparé à une image matricielle assez grande, c'est imbattable. Mais pour une icône, on prend moins de place en matriciel correctement compressé en fait.

Tiens, j'avais oublié la chronologie. HEIF a mis huit ans pour convaincre Apple, quelques fabricants d'appareils photo et zéro acteur du Web. AVIF a mis quatre ans pour convaincre tout le monde logiciel. JPEG XL a mis moins d'un an pour commencer à convaincre une partie du monde logiciel, à un rythme qui rappelle celui de WebP.

Après, qui gagne, on s'en moque un peu. Lorsqu'on a un choix de format à faire, la seule question à se poser, c'est : quel format répond à mes besoins et a le plus de chances d'être toujours lisible dans dix ans. Et actuellement, la réponse, c'est généralement WebP (pris en charge partout), AVIF (presque partout), peut-être JPEG XL (sera sans doute pris en charge partout, mais pas encore), mais certainement pas HEIF qui n'est pas lisible et ne le sera peut-être jamais sur certains systèmes.

Le fait de pouvoir lire du HEIF, c'est très bien, surtout quand on a un appareil photo qui sort ce format-là. Mais ce n'est pas la même chose lorsqu'on est amené à choisir volontairement un format pour une image qu'on vient de produire ou qu'on veut stocker à long terme.

Ça ne me dit rien, mais ça a l'air cousin de la compression par ondelettes de JPEG 2000. Parce que contrairement à JPEG qui compresse par blocs, la compression basée sur une transformée en ondelettes travaille sur l'image entière, avec des fonctions qui n'ont de valeur significative que localement. En conséquence, il me semble qu'il n'y a pas vraiment de notion de pixel dans ce contexte théorique.

Exact, j'avais oublié. Et d'ailleurs, PNG permet aussi de faire du gris ou du RGBA sur 16 bits par canal. Si un modérateur a le temps de corriger :

Publié en 1996 par le W3C, le format PNG a été conçu pour remplacer GIF, qui souffrait de limitations techniques et de problèmes de brevets. Il permet de compresser sans perte une image avec une palette de 8 ou 256 couleurs, en niveau de gris sur 1 à 16 bits ou en RVB sur 8 ou 16 bits par canal, avec une transparence optionnelle par canal alpha sur 8 ou 16 bits.

C'est peut-être une niche, mais je ne sais pas si d'autres formats sont sur cette niche et font mieux que le PNG là-dedans.

Est-ce que WebP ne pourrait pas faire mieux ? Même sans palette, une image avec très peu de couleurs pourrait être très efficace à compresser. Je n'ai pas essayé, mais ce serait intéressant à vérifier. Si ce n'est pas le cas, clairement, une image avec peu de couleurs gagnerait à rester en PNG.

Ton avis sur HEIF me parait assez radical et infondé

Infondé, et puis quoi encore ? Alors, voyons un peu les fondements en question.

HEIF est :

• miné de brevets problématiques ;
• pris en charge par aucun navigateur ;
• pris en charge par certains outils d'affichage et de traitement d'image.

AVIF est :

• libre de brevets problématiques ;
• pris en charge par tous les navigateurs ;
• pris en charge par certains outils d'affichage et de traitement d'image.

JPEG XL est :

• conçu et promu comme successeur de JPEG à long terme ;
• libre de brevets problématiques ;
• pris en charge par certains navigateurs (c'est tout jeune, ça commence à peine) ;
• pris en charge par certains outils d'affichage et de traitement d'image (dont la liste est déjà plus longue que celle de HEIF).

Je m'avance peut-être, mais HEIF a l'air clairement d'être promu à un avenir aussi radieux que la connectique Thunderbolt. Il a peut-être convaincu quelques acteurs, mais côté navigateurs, c'est très, très mal parti, aucun n'a suivi. En face, on a un concurrent qui a déjà réussi à s'imposer (AVIF, bon courage pour le rattraper vu ce qui arrive ensuite). Je doute qu'HEIF réussisse à percer dans quelques années, puisqu'il y en a un autre qui débute et est bien parti pour s'imposer encore plus (JPEG XL, qui est vraiment conçu avec ce qu'il faut pour remplacer JPEG à long terme).

En matière de conseil de formats, je maintiens qu'aujourd'hui, il n'y a aucune raison, lorsqu'on enregistre une image après création ou retouche, de choisir ce format, AVIF est juste mieux, parce qu'il est lisible partout. Et si donc, vous avez enregistré une image en AVIF, et que dans deux ans, HEIF s'impose (et que JPEG XL échoue, ce qui m'étonnerait beaucoup), ça n'aurait aucune importance, AVIF restera lisible.

Eh bien, BitTorrent, tout simplement. Pas besoin de traqueur si les fichiers en question sont publics, la DHT fait bien l'affaire. Tout ce qu'il te faut, c'est un client BitTorrent initial, qui dispose du fichier et qui reste en service. Il servira de fournisseur initial, et dès que le fichier sera disponible ailleurs, il deviendra juste un fournisseur du fichier comme les autres.

Je comprends.

Mais le paiement avec une redirection vers le site de la banque pour confirmation permet aussi bien de vérifier que la transaction est bien du montant attendu, vers le bon marchand, et qu'on est bien en train de valider avec la banque et non avec un intercepteur.

L'argument selon lequel l'application bancaire serait le seul moyen pour l'utilisateur de vérifier que le paiement est bien conforme à ce qu'il attend est juste faux. C'est un choix de la banque, mais certainement pas la seule option disponible.

Certes, n'empêche que le changement peut être imposé par d'autres acteurs que le parlement européen.

Je viens seulement de me rendre compte d'une subtilité. Le fait de considérer que le handicap vient de la non-adaptation de l'environnement et de la société, c'est très bien. Mais ça ne plaide pas spécialement pour une tournure comme « en situation de handicap » : « personne handicapée », c'est déjà très bien !

Une personne handicapée, c'est comme une personne discriminée, une personne ignorée, maltraitée ou ce qu'on veut : c'est quelqu'un qui subit un problème. On ne parle pas de personne en situation de discrimination, n'est-ce pas ?

S'il y a bien un terme que j'évite déjà, c'est de parler d'un handicapé, ce qui pour le coup le réduit pas mal à son handicap.

Pas forcément, on a un précédent avec 3-D Secure.

En fait c’est très souvent refusé par le marchand et pour une bonne/mauvaise raison

Aucune importance, ce genre de cas, c'est super facile à gérer par les acteurs en position de force (les banques, les intermédiaires de paiement et les législateurs) : il suffit d'imposer la bonne solution. Les marchands peuvent s'adapter, et s'ils râlent il suffit de les laisser râler, le monde continuera à tourner.

Je trouve ahurissant que les banques acceptent l'intégration de leurs systèmes de paiement par iframe, et le fait que les marchands le demandent n'explique rien du tout. En matière de paiement en ligne, les demandes de la sécurité informatique devraient être considérées comme des ordres non négociables, prioritaires sur tout le reste.

Tous les agrégateurs dignes de ce nom supportent l'importation et l'exportation de listes de flux en OPML.

Mais accessoirement, ça pourrait être une bonne occasion de passer à une agrégation centralisée, avec un service d'agrégation installé sur un serveur, auquel tu accéderais depuis le terminal que tu veux.

Le plus connu est TinyTinyRSS, mais personnellement j'utilise FreshRSS, qui a l'avantage de ne pas nécessiter de faire tourner un serveur de base de données (c'est une vraie maladie des développeurs Web ça, utiliser presque systématiquement un serveur de base de données…).

Les alternatives à l'iframe ne se résument pas à avoir un site marchand qui demande tout et fait lui-même des requêtes à un prestataire de paiement hein.

Il y a aussi une dernière alternative, la seule qui tient la route à mon avis : rediriger le client vers le prestataire de paiement, qui une fois le paiement effectué redirige le client vers le site marchand avec des paramètres qui permettent à ce dernier de vérifier que le paiement a été effectué.

Avec un iframe, c'est juste pareil en terme de fonctionnalité sauf qu'en plus on s'assure que le client n'a aucun moyen de vérifier qui est le prestataire de paiement et si la frame de confirmation de paiement est bien celle de sa banque plutôt qu'un phishing. C'est pour cela que je suis sidéré que les banques permettent cela.

Merci pour les explications, c'est très intéressant. Mais c'est quoi le truc avec le prénom Camille au juste ? C'est pratique comme prénom, c'est épicène, mais au point de l'utiliser comme synonyme de « gens », tout de même…

Bon, euh, le problème des iframe, ça vient des banques. Ça pourrait facilement être interdit, il suffit d'ajouter un en-tête HTTP pour interdire l'intégration d'une page dans un cadre ou dans un cadre flottant.

Il est ahurissant que cette pratique ait été tolérée au départ, mais ça peut très bien se résoudre, c'est juste une question de volonté de la part des banques et des intermédiaires de paiement. Et la volonté, ça se fabrique très bien à coup de règlement européen.

Disons que c'est un facteur de possession. Il en faut toujours un autre, par exemple un code secret ou une empreinte digitale.

Tu rentres ton mot de passe bancaire ordinaire, puis le code reçu par SMS. Mais ça marcherait aussi bien avec n'importe quel second facteur potentiellement indépendant d'un téléphone, genre un TOTP ou une grille de codes.