Bonjour 'nal
Tu te souviens de Øyvind Kolås ? Mais si le mainteneur de GEGL, le moteur de GIMP. Mainteneur que tu peux soutenir par là. En 2019, il avait fait le buzz notamment avec l'image ci-dessous :
Image qui est principalement en niveaux de gris. Mais si ! Il y a un filet avec de la couleur mais c'est principalement sans couleur. Ensuite, notre cerveau colorie l'ensemble de la photo.
Moi, je trouve cela rigolo. Et puis, je me disais, que cela devait réduire le poids des images vu que pour une grande partie de l'image, on réduit drastiquement le nombre de couleur. Ce qui se confirme quand je regarde l'analyse colorimétrique.
Mais en fait, j'ai tort. En tout cas, avec GIMP, quand j'exporte l'image modifiée ainsi, j'obtiens des fichiers images plus imposants que cela soit avec AVIF ou WebP.
J'ai un peu joué avec GIMP et j'obtiens le même type de comportement avec la postérisation et le tramage. Une partie de l'explication vient du fait que quand tu sauves ainsi l'image, tu l'exporte vers un des ces formats et puis que tu les ouvres; l'image a un profil colorimétrique bien plus important que le nombre de couleur après le traitement de l'image. Proche de l'initial. Donc, ces formats d'image n'exploitent donc pas le faible nombre de couleurs dont l'image est constitué. Mais ce n'est qu'une partie de l'explication. Pour le reste, je n'en sais rien.
Je me demandais si tu pouvais mieux m'expliquer ce qui se passait. Et puis, je me demande s'il y a quand même moyen d'utiliser la grille d'assimilation des couleurs pour réduire le poids de mes images. Images que je comptes utiliser sur l'internet, par exemple sur mon blog.
# Séparation chroma/luma
Posté par Ph Husson (site web personnel) . Évalué à 10.
En fait ce que cette image montre, c'est que le cerveau est beaucoup plus intéressé par la luminance (= la luminosité d'un pixel), que par la couleur d'une zone. La couleur reste intéressante, mais par grosse tache disons.
Mais ça, on le sait depuis très longtemps. Donc tous les algos de compression d'image/vidéo depuis très longtemps séparent la luminance de la couleur, et mettent plus de bits dans le fichier pour stocker la luminance que pour stocker l'image, c'est pour ça qu'il n'y a pas de gain à avoir. Pour comprendre pourquoi c'est en fait bien pire, faut entrer un peu dans les détails.
Pour avoir cette notion de "couleur par grosse tache", on utilise deux outils:
Le premier, c'est un bête down-sampling. La très grande majorité des vidéos (mais plus rarement les images) ne stockent que un quart de la résolution sur la couleur: Une vidéo 1920x1080 aura 1920 * 1080 valeurs de luminance, mais seulement 1920 x 540 valeurs de couleurs (ou 960 x 540 vecteurs de couleur, vu qu'une seule valeur n'est pas suffisante pour définir une couleur).
Le deuxième est du filtrage fréquentiel (principalement par transformée de Fourier ou équivalent). Ça va nous permettre des filtrer les "taches" par taille (aussi bien la couleur que la luminosité). Pour choisir quelle est la plus petite taille d'objets on va garder, les algos de compressions utilisent des méthodes "psycho-visuelles" pour déterminer. Ici, il serait très visible si on perdait les informations de couleur de la taille de la grille. L'algo décide donc de filtrer à des tailles du "fil" de la grille. Ce qui va exiger une précision vachement plus petite que la taille qu'il va choisir pour l'image d'origine. Ça va donc prendre bien plus de stockage.
On pourrait aussi voir cette question d'un point de vue entropique: la couleur apporte globalement peu d'information, et peu se déduire de la luminance. La grille est plus difficile à prédire vu le contexte.
[^] # Re: Séparation chroma/luma
Posté par Zenitram (site web personnel) . Évalué à 4.
En l’occurrence l'image est ici en sans perte, donc l'encodeur ne va rien décider de prioriser, il va faire comme il peut suivant la complexité des couleurs, et ce sans downsampling ni filtrage fréquentiel qui sont avec de la perte ;-).
(plein d'autres choses vont être utilisées pour optimiser, dont la séparation luminance de la couleur qui elle marche dans tous les cas)
[^] # Re: Séparation chroma/luma
Posté par tisaac (Mastodon) . Évalué à 3.
C'est effectivement quelque chose que j'imaginais comme piste d'explication.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Séparation chroma/luma
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Lors de mes cours d'optique, j'avais fait le calcul de la sensibilité de l'oeil. J'étais autour de 24 bits pour la luminosité (pas seulement pour les détails mais aussi le min et le max) et 2x7 bit pour le U et le V.
Le cerveau peut différencier des milliards de couleur côte à côte mais à peine un millier dans la même image.
"La première sécurité est la liberté"
[^] # Re: Séparation chroma/luma
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Selon les sources, la sensibilité dynamique de l’œil est d’environ 24 bits/stops/IL – plein de façons de dire qu’entre la plus grande et la plus petite lumière qu’on peut percevoir il y un rapport d’environ 224
Par contre c’est pas en instantané : la sensibilité de l’œil sur une scène unique est très difficile à évaluer, les sources vont de 12 à 17 IL. Rien qu’en un coup d’œil ça peut bouger de de 2 à 4 IL, et en dix minutes d’adaptation changer de plus de 10 IL.
Pour la couleur c’est encore pire, le champ n’est pas du tout homogène (il ne l’est déjà pas à la sensibilité lumineuse). La fovea est très sensible aux couleurs et très peu à la luminosité ; par contre hors de cette tache particulière la sensibilité aux couleurs baisse très vite et est à peu près nulle sur les bords du champ de vision.
En fait, un être humain en bonne santé voit une tache étroite, nette et en couleurs ; et plein de flous en gris/mauvaises couleurs autour. Et il y au trou en plein dans le champ (la tache aveugle). Et le cerveau passe son temps à la fois à imaginer des trucs (les détails et les couleurs du champ élargi) et à ignorer des trucs (à commencer par le nez).
Donc, forcément, quand on essaie de comparer ça à un système optique de type photographique, ça devient compliqué :D
La connaissance libre : https://zestedesavoir.com
[^] # Re: Séparation chroma/luma
Posté par barmic 🦦 . Évalué à 2.
On m'avait expliqué que le cerveau réécrit même l'histoire. Il construit un mouvement continue de notre regard alors que nos yeux font des sauts.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Séparation chroma/luma
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a un article qui est passé sur twitter avec une IA qui reproduisait les perf de la vision humaine. En gros, la rétine n'envoie que des différences (8) avec des prédictions : prédiction de mouvement rectiligne, mouvement local (objet devant un fond mouvant), cycle et fréquence qui change,…
"La première sécurité est la liberté"
[^] # Re: Séparation chroma/luma
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
La vision périphérique est aussi plus rapide et sensible au mouvement.
Qui se rappelle des CRT que l'on voyais vibrer si on les regardait de coté ?
"La première sécurité est la liberté"
# Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 30 août 2023 à 23:49.
Ben en fait, si.
Euh… Si.
En pratique ça passe de RGB à YUV (luminance + 2x delta de couleur) avant de compresser, et les 2 canaux de delta de couleur se compressent un max.
J'ai testé avec GIMP, ouvert le fichier, modifié 1 pixel pour être sûr que la compression doit bien être refaite, et :
- Export WebP sans perte : même taille que l'original à peu prêt (456 Kio)
- Export AVIF presque sans perte : réduction à 355 Kio (aucune idée de la destruction dans le "presque", je ne peux pas dire ce qui vient de la génération plus moderne du format et ce qui vient de la perte)
Je ne vois pas de quel "plus imposant" tu parles, je ne peux reproduire.
[^] # Re: Chez moi ça marche
Posté par tisaac (Mastodon) . Évalué à 4.
Je ne suis pas certain de bien avoir expliqué ce que je fais:
Le fichier obtenu en 4 a une taille plus importante que celui obtenu en 2.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Chez moi ça marche
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Et qu'est ce que ça donne en sauvegardant d'un coté l'image en niveaux de gris et de l'autre seulement la trame de couleur ? N'arrive-t-on pas à gagner un peu de place ainsi ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 4.
En séparant en 2 fichiers, le fichier luminance (niveau de gris) de l'image du journal fait 30% du contenu total, le fichier couleur 70%.
Cette énorme différence alors que la couleur est très faible vient sans doute du fait que la couleur est ajoutée artificiellement et que donc pas facile de trouver une cohérence naturelle.
Pourquoi on gagnerai ainsi ? Séparer ne change rien à la quantité de contenu à stocker, c'est juste stocker la même information.
[^] # Re: Chez moi ça marche
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
J'imaginais possible de définir un format adapté pour enregistrer une grille arbitraire à défaut que du png ne fasse l'affaire : à vue de nez, la matrice colorée contient de l'ordre de 1% des pixels de l'image complète, même avec deux canaux au lieu d'un, ça ne devrait pas peser bien lourd si la compression est appropriée.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 31 août 2023 à 09:03.
Passer la partie couleur de WebP à PNG augmente la taille de 30%.
Encore une fois, ce que tu vois n'est pas ce que la machine voit et la machine n'a ici pas le droit de détruire ce que tu ne vois pas en sans perte, et perso je ne connais pas d'algo sans perte qui s'en sorte avec ces couleurs en biais et avec dégradés.
Tu vois 1%, la machine voit 67% et essaye de compresser comme elle peut cette quantité de données complètement artificielles.
[^] # Re: Chez moi ça marche
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Le format d'image est inadapté assurément.
Ma compréhension de l'interrogation initiale diffère probablement de la vôtre. Si l'objectif est d'utiliser uniquement deux formats matriciels classiques, il ne semble guère y avoir de solution évidente. Si l'objectif est de réduire drastiquement les informations colorimétriques en enregistrant deux des canaux uniquement sur une grille diagonale et qu'on s'autorise à programmer, il paraît aisé d'imaginer un format pour enregistrer ça de manière appropriée (sur une base d'onde planes ou d'ondelettes par exemple). Même en incluant un code pour retransformer en image matricielle ça ne devrait pas peser besef.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Chez moi ça marche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 31 août 2023 à 09:06.
C'est ce que j'allais dire. La plupart des formats (tous?) ne permettent pas d'avoir certains pixels en niveaux de gris, et certains pixels en couleur. Donc avoir une telle image principalement en niveaux de gris avec juste quelques pixels (la grille) en couleur en revient juste à avoir une image entièrement en couleur. Simplement beaucoup de ces couleurs seront "grises", ce qui dans la pratique va le plus souvent signifier que 2 composants sur 3 seront "inutiles". Par exemple si les pixels sont en RGB, chaque composant (rouge, vert et bleu) seront simplement identiques (donc 2/3 de l'info est redondante). En Y'UV, seule la luma sera utile (et beaucoup d'autres modèles de couleurs séparant la luminance, ce sera similaire avec le seul composant luminance utile).
Alors comme dit plus haut, ça doit pouvoir se compresser très bien, mais bon… c'est sûr qu'avec presque 2/3 de données inutiles, idéalement plutôt que compresser cette partie, on aimerait pouvoir s'en débarrasser tout simplement.
Je vois 2 solutions:
Notons pour cette seconde solution que séparer la grille en format vectoriel, par ex. SVG, (plutôt qu'un quelconque format raster) même serait encore mieux (des lignes droites avec des aplats de couleur, c'est du vectoriel idéal donc taille probablement encore plus faible), laquelle pourrait tout aussi bien être composité sur l'image en niveaux de gris (comme dit plus haut, soit dans un format d'image unique qui est capable de contenir plusieurs types d'images différentes, soit à l'affichage en HTML/JS).
Ensuite clairement la solution 2 images + HTML/JS rajoute de la complexité au système (même si cela pourrait être scripté pour n'avoir qu'à donner une image en couleur, puis des scripts généreraient la version en niveaux de gris, la grille de couleur en vectoriel et le code HTML/CSS automatiquement). Disons que je joue le jeu d'essayer de trouver la solution qui permettrait la plus faible taille de fichiers, mais ce n'est pas forcément la solution la plus simple malheureusement. Et puis faudrait tester pour vérifier l'intuition. Sait-on jamais si vraiment la compression ne fait pas des merveilles, comparée à 2 images avec tout l'overhead que cela implique.
Donc j'imagine très bien que ce ne sera pas la solution choisie. 😉
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 4.
Aucune utilité, car en pratique les algos font le taf automatiquement (RGB vers YUV), et les composantes couleurs avec du "noir" ont autant (voire plus) de performance qu'un flag par pixel pour dire si couleur ou pas.
La conversion auto RGB vers YUV supprime cette redondance.
Tu y gagneras rien, cf mes autres commentaires.
Tu y gagneras rien, cf mes autres commentaires.
Ici (image du journal), la grosse différence entre couleur et gris est que les couleurs sont du artificiel par facile à coder.
Tes "bidouilles" imaginées ne touchant pas à cette problématique, tu ne gagneras rien.
Faut pas imaginer les développeurs de formats pour des idiots, ils essayent des choses, la tu n'inventes rien que quelqu'un n'aura pas déjà essayé ;-) et mis à la poubelle car n'apporte rien.
[^] # Re: Chez moi ça marche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Ben si c'est justement exactement ce que propose mon commentaire, relis. Je propose de coder ces couleurs en vectoriel car on voit bien que ce ne sont que des lignes droites colorées qui sont au contraire extrêmement simples à coder en vecteur, et cela fera un fichier de faible taille.
Et là il n'y a plus aucun des problèmes que tu mentionnes dans d'autres commentaires, à savoir de trouver un algo qui trouve une "cohérence" pour compresser ces couleurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 31 août 2023 à 09:55.
A condition que tu ais la source en vectoriel.
Mais admettons que tu ais la source en vectoriel, du coup du peux utiliser SVG : stockage de l'image en gris dans une balise "image" et ajout des info vectorielles par dessus, SVG sait faire.
Donc je ne vois pas ce qui te manque dès aujourd'hui dans le cas où tu as la source des ajouts en vectoriel, et si pas le cas je ne vois pas ce que ça apportera, le vectoriel étant plus gros que la compression sans perte des pixels de couleurs même si toi tu vois des lignes (la machine ne vois pas ça et tes lignes doivent stocker chaque niveau de dégradé sauf si par grosse chance il arriverai à retrouver le vectoriel initial mais la où est dans le tellement spécifique que pas intéressant).
[^] # Re: Chez moi ça marche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 31 août 2023 à 12:10.
Mais de quoi tu parles? Tu as lu le post d'origine? 😜
Le cas d'usage évoqué est celui de quelqu'un qui crée cette grille de couleur à partir d'une image en couleur. La source en vectoriel, il n'y a pas besoin de "l'avoir", c'est toi qui la crées à la base.
Il n'a jamais été question de travailler sur des images avec grilles de couleur pré-existantes. Tu te fais des nœuds au cerveau pour rien. 😝
Ensuite, c'est un peu de travail (mais pas énorme non plus; l'algorithme est tellement simple que n'importe quel développeur pourrait le réimplémenter super rapidement pour générer du vectoriel) et je ne suis pas sûr que ça vaille le coup, comme je disais dans mon commentaire. Ensuite à chacun de voir.
En tous cas, c'était pour répondre à l'exercice de pensée proposé:
Et sinon pour ton commentaire:
C'est vrai. C'était ma solution 1 avec un format qui embarque les 2 données dans des calques/objets séparés. CQFD.
Je pensais à PDF au début mais ce n'était pas adapté pour de l'affichage d'image au milieu de contenu web. J'avais pas pensé au plus simple, SVG, qui serait pour le coup un très bon choix, effectivement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi ça marche
Posté par tisaac (Mastodon) . Évalué à 3.
Oui mais non. Je ne sais pas si tu connais, mais j'utilise GIMP (un super logicielle avec une équipe de développement où la compétence semble concurrence la sympathie). Et avec GIMP, je n'ai pas l'impression que l'on puisse générer la grille et la sauvegarder indépendamment du reste de l'image. Mais c'est vrai que j'apprécie beaucoup GIMP mais que je le maîtrise assez mal pour ne pas dire pas du tout.
Malheureusement, je ne suis absolument pas programmeur. Donc, je ne pourrai pas vérifier si cela vaut le coup.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Chez moi ça marche
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
Tu as une notion de calques dans GIMP qui permet ce genre de choses. C'est fait pour.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Chez moi ça marche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 01 septembre 2023 à 15:39.
tisaac:
😜
Ah ça, j'ai pas dit que c'était du click'n play à la portée de tous. Il faut clairement mettre les mains dans le code. J'étais juste dans l'exercice de pensée: il est faisable de modifier le code pour générer une grille séparée en vectorielle et d'exporter l'image en nuances de gris avec une grille vectorielle en couleur par dessus. Et ça pourrait être une façon d'avoir une image plus petite, puisque c'est le but évoqué (à tester pour voir à quel point ça vaudrait le coup ou non, bien sûr).
Ysabeau:
Oui. Ensuite pour implémenter au mieux l'idée que j'évoque, il faudrait qu'on ait des calques vecteurs. Cela devrait être possible dans une version peu après la sortie de GIMP 3, puisqu'on a déjà un patch en instance de revue pour cela. Mais j'attends l'après-GIMP 3 pour faire cette revue de code (voir les calques de type non-destructive dans notre feuille de route).
Une fois qu'on aura ça, il devrait être possible d'implémenter l'export avec des parties en raster et d'autres en vectoriel (dans les formats qui permettent cela).
En attendant, ça reste possible, mais faut faire un peu plus de bidouillage.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi ça marche
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ça doit pouvoir se faire avec gif non?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Chez moi ça marche
Posté par barmic 🦦 . Évalué à 3.
Une image gif a une seule palette de couleur pour l'ensemble de l'image pas plusieurs palettes qui sont appliquées à certains pixels et pas à d'autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chez moi ça marche
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 01 septembre 2023 à 08:30.
Prépare toi à prendre une gifle : https://en.wikipedia.org/wiki/GIF#True_color
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Chez moi ça marche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Ce que ton lien indique, c'est qu'on peut diviser une image en blocs et avoir plusieurs tables de couleur (une par bloc), ce qui permet de ne pas être limité à 256 couleurs. Mais ça reste quand même super limité, ou alors faut faire de très petits blocs (possiblement 16×16 pixels si chaque pixel a une couleur différent, ce qui serait courant dans une photo; et c'est probablement ce que cette image que tu donnes fait même si j'ai pas vérifié l'image).
Ensuite le problème n'est pas qu'il y a une ou plusieurs palette de couleur. On pourrait imaginer par exemple qu'il pourrait être autorisé d'enregistrer certaines couleurs en RGB et d'autres en gris dans la palette. En fait, le vrai problème est que GIF ne semble même pas prendre en charge les couleurs en niveau de gris du tout. Ça fait un bout de temps que j'avais pas relu la spéc, alors je viens de jeter un rapide coup d'œil (GIF 89a est la dernière version): https://www.w3.org/Graphics/GIF/spec-gif89a.txt
Regarde les sections 19 et 21 en particulier. Les tables de couleur n'attendent que du RGB.
Donc la réponse est: non, ce n'est pas possible en GIF.
De toutes façons, GIF n'est absolument pas adapté pour les photos avec les attentes de qualité modernes et la taille du fichier exploserait avec le genre d'astuce que tu pointes. Donc on serait loin d'une solution au problème évoqué même si GIF permettait d'indexer des couleurs en nuances de gris.
Ensuite, soyons francs, GIF est un format tellement basique que tu trouveras très peu de cas d'usage moderne où la réponse à une question sera: "oui, GIF le permet contrairement aux autres formats" 😛
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi ça marche
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
J'ai dit que c'était possible, pas que c'était une bonne idée :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Chez moi ça marche
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 01 septembre 2023 à 18:51.
GIF permet de discuter longuement de comment on le prononce, contrairement à d'autres formats modernes.
[^] # Re: Chez moi ça marche
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Gif-sur-Yvette est la clé.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Chez moi ça marche
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Tifeu ? Té hi effe ?
Pet Haine Jet? Pi Haine Ji ? Ping ?
Ji pègue ? Ji Pet Jet ? Ji Pi Ji ?
Web pet ? Web pi ?
A vif? Avé hi effe ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Chez moi ça marche
Posté par jnanar (site web personnel) . Évalué à 7.
C'est facile,le g se prononce comme dans garage.
[^] # Re: Chez moi ça marche
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Tu triches Gilles Giver :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Chez moi ça marche
Posté par orfenor . Évalué à 2.
Et tout betement en JPEG en séparant luminance et chrominance?
[^] # Re: Chez moi ça marche
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 31 août 2023 à 08:45.
J'ai essayé ton fichier WebP du journal et je me retrouve avec un fichier de 325 Kio, soit -30% en taille. Cohérent avec plus bas car c'était déjà artificiel et la couleur artificielle est encore plus réduite avec le filtre.
Et après tu la modifies avec du coloriage artificiel, tu casses donc les algos qui visent des ressemblances "naturelles" dans les pixels adjacents, tu mélanges de tout (naturel et artificiel), les algos doivent alors faire un peu dans tous les sens, l'image est complètement différente et ça doit quand même stocker sans perte (ça serait très différent si tu acceptes de la perte), complètement normal que la taille soit plus grosse, tu compares 2 images n'ayant pas grand chose à voir du point de vue informatique (la ressemblance visuelle de l'humain est peu intéressante ici car pas de perte autorisée donc pas possible d'applique des filtres, avec perte, de ressenti humain).
[^] # Re: Chez moi ça marche
Posté par tisaac (Mastodon) . Évalué à 3.
En fait, je ne l'ai pas bien explicité et tu as fais l'hypothèse que je fais du sans perte mais ce n'est pas le cas. En fait, j'ai testé aussi sans perte mais j'ai fais beaucoup plus de tests avec perte, et cela ne change pas qualitativement la comparaison du poids des différentes images.
Comme tu l'as dit (et d'autres) plusieurs fois, ce qui compte, ce n'est pas ce que l'on voit mais ce que voit la machine. En simplifiant, je vois des nuances de gris à beaucoup d'endroit, la machine voit surtout qu'il y a encore des couleurs; je vois une structure simple (quadrillage), la machine voit une structure qui n'a pas de cohérence avec le reste de l'image.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Chez moi ça marche
Posté par Moonz . Évalué à 2.
Essaie avec une grille horizontale/verticale plutôt qu’en diagonale ?
# PNG et QOI
Posté par tuxmain (site web personnel) . Évalué à 2.
PNG filtre l'image pour ne garder que les contours des aplats unis (en gros) et laisser le rester en noir. Ensuite il fait une bête compression deflate. L'image devrait donc prendre plus de place avec les lignes qu'avec des aplats colorés. La postérisation devrait aider dans ce cas.
QOI fait un peu la même chose mais dans une fenêtre glissante qui rend les répétitions d'une même couleur moins coûteuses. Il opère linéairement, un pixel n'est pas relié à son voisin de la ligne supérieur (alors que c'est le cas pour PNG).
On pourrait imaginer une variante de QOI qui passe en nuance de gris (1 octet) régulièrement sur une proportion donnée des lignes, et en couleurs (3 octets) sur le reste des lignes. La compression sera moins bonne aux transitions entre les modes de couleurs mais l'image sera plus légère dans les lignes grises.
Par rapport à la grille, peut-être stocker l'image en nuances de gris, et stocker la grille de couleurs sous forme d'une liste de polygones formés par des points (avec une couleur associée à chaque polygone), puis générer la grille et la superposer à l'image côté client.
Sinon il existe Yoga Image Optimizer qui est libre et qui optimise les images avec perte dans plein de formats y compris JPEG et WebP.
# Effet loupé
Posté par Strash . Évalué à 6.
Je suis le seul à ne pas être berné par l'illusion voulue ? Je ne vois pas du tout une image colorée, mais une image en niveau de gris et une grille colorée par dessus. Est-on sensé avoir l'illusion d'une image colorée "normale" ? Mon cerveau a-t-il un défaut logiciel ?
[^] # Re: Effet loupé
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
On a le même cerveau peut-être. Parce que pareil en ce qui me concerne.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Effet loupé
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Pour moi ça dépend de la distance de vision de l’image et surtout des couleurs. Le vert fonctionne plutôt bien, le orange des visages très mal, et le reste dépend. Par contre, sans mes lunettes, c’est très efficace :D
La connaissance libre : https://zestedesavoir.com
[^] # Re: Effet loupé
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Je tempère un peu : ça passe bien sur le pull "bordeaux" de l'homme juste à côté de la femme en premier plan. Mais pour les autres la grille se détache plus.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Effet loupé
Posté par Strash . Évalué à 3.
Pour moi cette grille rouge ressort très bien et ne colore pas du tout le pull. C'est marrant de voir les différences de perception.
L'illusion fonctionne un peu si je plisse les yeux au point de voir l'image complètement floue.
[^] # Re: Effet loupé
Posté par Tit . Évalué à 2. Dernière modification le 31 août 2023 à 09:59.
Pour moi il y a juste le violet (d'un pull) qui fonctionne ;)
edit: j'avais pas vu le dernier message d'Ysabeau, donc pareil qu'elle (sauf que je'ai appelé violet ce qu'elle appelle bordeaux, mais c'est une autre histoire)
[^] # Re: Effet loupé
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Le bordeaux est un rouge violacé donc c'est bon des deux côtés. 🙂
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Effet loupé
Posté par GaMa (site web personnel) . Évalué à 5.
Chez moi aussi, je vois bien le gris sur l'image du journal.
Par contre, dans l'article d'origine (https://www.patreon.com/posts/color-grid-28734535), ça marche assez bien (je suppose parce que l'image est plus petite).
Et la vidéo est assez bluffante.
Matthieu Gautier|irc:starmad
[^] # Re: Effet loupé
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 31 août 2023 à 10:02.
C’est amusant parce que pour moi la vidéo ne fonctionne pas du tout.
Visiblement il y a une grande variabilité interpersonnelle dans ce genre d’expérience – sans parler des différences dues aux différents rendus des différents écrans utilisés, en particulier ceux des portables qui ont la sale habitude « d’améliorer » l’image en la saturant à mort.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Effet loupé
Posté par tisaac (Mastodon) . Évalué à 7.
En effet. Et comme dit par ailleurs, cela dépend aussi de la taille de l'écran/image.
Évidemment, cela dépend aussi de la finesse de la grille que l'on utilise.
Perso, j'aime les situations comme l'image ci-dessus où en regardant rapidement, on ne va pas voir directement la spécificité de l'image mais on sent quand même assez vite qu'il y a un truc un peu particulier.
Sur la photo ci-dessous, je trouve qu'on voit rapidement la grille à certains endroits et des trucs un peu particulier par ailleurs mais perso, je ne sens pas l'image en niveau de gris qui se cache derrière. En fait, j'ai du mal à y croire, je me dis que je dois m'être planté dans la manipulation mais quand je zoom, je tombe bien sur des niveaux de gris.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Effet loupé
Posté par alberic89 🐧 . Évalué à 4.
En effet, c'est comme pour les tableaux du pointillisme.
De près, les points sont grossiers et évidents.
Mais de loin, l'illusion agit.
Essayez de regarder la page citée dans le commentaire précédent en dézoomant et en vous éloignant un peu de votre écran. L'effet est saisissant.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Effet loupé
Posté par devnewton 🍺 (site web personnel) . Évalué à -1. Dernière modification le 31 août 2023 à 17:50.
Moi je vois juste une fille nue sur cette image, c'est normal?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Effet loupé
Posté par barmic 🦦 . Évalué à 4.
En fait ça dépend de beaucoup de choses, tout le monde est en mesure de voir la grille, c'est juste une question de niveau de concentration. Si on fait défiler 10 images 1/2s par image et à la fin on te demande la quelle avait se traitement, il est possible que tu ai bien plus de mal à répondre qu'avec une image fixe.
Les illusions d'optiques viennent de post traitement de le cerveau fais pour assembler une image aussi cohérente que possible à partir de ce que lui fournissent les yeux (assembler 2 images en une, supprimer les points aveugles,…)1. Bien sûr tout le monde n'est pas identique avec les images en "3D relief" ne marche pas sur tout le monde par exemple. Il existe aussi des troubles, la persistance rétinienne permet de regarder des vidéos et pas des suites d'images, mais la palinopsie est un trouble de la persistance rétinienne qui peut te retourner la vue (momentanément tu vois le haut en bas et le bas en haut).
en fait ce n'est pas si cloisonné cerveau/œil l'ensemble travail conjointement (et peut évidement se servir des autres sens) ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
Quand on veut compresser des images (avec pertes), il y a parfois des effets qui sont étonnants en première approche (et qui s’avèrent logiques une fois qu’on a réfléchi au problème).
Il y a quelques semaines, j’ai acheté un manga en version électronique, et me suis retrouvé avec un fichier gigantesque : l’éditeur y a enregistré ses images en qualité « impression » (je peux prendre mon manga et l’imprimer en 600 dpi, j’obtiens quasiment la taille d’impression réelle) et en PNG.
Autant dire que les images sont énormes, et images de couverture et les pages en couleur avec leurs dégradés sont gigantesques.
J’ai voulu les retailler (à largeur de l’image = largeur de l’écran) et recompresser, et pour ça j’ai choisi le format AVIF, qui est très efficace (quoique très lent à compresser, mais c’est un autre débat).
Et là, surprise ! Les images couleur sont extrêmement bien compressées ; les images noir et blanc sont bien compressées, mais prennent beaucoup plus de place que les images couleur. Pourtant, il y a des couleurs en plus, donc ça devrait prendre plus de place ?
Eh bien non. AVIF est capable de compresser très efficacement les dégradés, et les images couleurs contiennent finalement assez peu de détails fins (il n’y a pas d’effets de textures ou autre). Elles contiennent donc assez peu d’information (au sens de la théorie de l’information), et correspondent bien aux modèles d’approximation utilisés pour la compression avec pertes dans AVIF, donc se compressent très bien.
Les images noir et blanc, par contre, ont des trames, donc énormément de minuscules détails. Pire : par nature, ces détails sont contenus dans la luminosité de l’image, donc ce que l’algorithme de compression se refuse à trop détruire pour conserver la qualité perçue de l’image. Donc, les pages en noir et blanc se compressent très mal, et donnent des fichiers beaucoup plus gros que les images couleurs.
Maintenant je rêve d’un algo de compression AVIF efficace : pour de la compression avec pertes, c’est un format beaucoup plus efficace que JPEG (y compris pour le noir et blanc décrit plus haut), sensiblement meilleur que WEBP (et avec moins d’artefacts parasites sur les dégradés, un vrai problème avec WEBP ou JPEG) et bien supporté un peu partout (pas comme JPEG XL que personne ne sait lire par exemple). Mais c’est vraiment l’horreur à compresser.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par mahikeulbody . Évalué à 4. Dernière modification le 31 août 2023 à 19:31.
Gimp, digikam, IrfanView, darktable, XViewMP, Image Magik, Firefox nightly, Exiftool et sans doute d'autres le supportent. Alors certes, ça reste notoirement peu (surtout coté navigateurs) mais dire qu'aucun logiciel ne sait le lire est une contre-vérité de nature à nuire à ce format qui me paraît pourtant plus intéressant que AVIF (si j'en juge mes lectures sur le sujet, je ne suis pas un expert), notamment grâce à sa retro-compatibilité avec le Jpeg.
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 01 septembre 2023 à 01:27.
Aucun navigateur Internet en version stable (pour une utilisation sur le web), aucun lecteur de mangas électroniques de ceux qu j'ai utilisé, sur PC comme sur mobile (le cas d'usage que je décrivais). Idem pour les visionneuses d'images des personnes à qui je pourrais envoyer des photos.
Lire le format AVIF par contre ne m'a posé aucun vrai problème (seul Edge ne supporte pas encore par défaut, à ma grande surprise).
C'est bien de pouvoir produire ces images, mais si c'est pour se priver de la plupart des cas d'usage, ben c'est un format inutile. On ne reparlera quand le support de JPEG XL sera actif là où j'ai besoin d'afficher les images et là où j'ai besoin que les gens les voient. Et cette remarque est indépendante des qualités intrinsèques du format.
Et franchement, mon avis dans un commentaire sur ce site pourrait "nuire au format" ? Je ne pense pas avoir cette influence.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par mahikeulbody . Évalué à 3.
Certes (ceci dit, je ne connais pas ton influence sur d'autres sites moins obscurs que linuxfr ;-). Mais ce que je voulais dire, sans doute maladroitement, c'est que si tout un chacun dit qu'un format "ne peut être lu par personne" alors personne ne cherchera à en savoir plus sur ce format et par contre coup moins d'éditeurs éprouveront le besoin de le supporter. Il faut une boucle vertueuse et donc être un peu moins radical que "personne", ne serait-ce que pour rendre grâce aux logiciels qui ont fait l'effort d'amorcer cette boucle.
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par BAud (site web personnel) . Évalué à 2.
et donc tu as envoyé des patchs et ouvert des demandes pour que cela soit pris en compte aux endroits opportuns ? :p
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par mahikeulbody . Évalué à 4. Dernière modification le 01 septembre 2023 à 16:15.
Je n'ai pas envoyé de patchs parce que je n'ai pas la compétence pour ce faire. Mais j'ai effectivement ouvert une demande à l'endroit où ça me semblait opportun à moi (je ne me sens pas légitime à faire une demande pour Photoshop, par exemple, sachant que je ne l'utiliserais sans doute jamais).
Il semble d'ailleurs que Adobe bouge de son coté.
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par orfenor . Évalué à 3. Dernière modification le 02 septembre 2023 à 00:56.
ce sera dans la prochaine version de Safari et dans tous les logiciels Apple ; voir le blog de Jon Sneyers.
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par moteuchi . Évalué à 2.
Tachiyomi sur android supporte le Jpeg XL.
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par tisaac (Mastodon) . Évalué à 3.
J'imagine que c'est des phénomènes similaires qui se passent quand je postérise ou trame les images.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Les effets insoupçonnés (?) de la nature de l’image elle-même
Posté par moteuchi . Évalué à 3.
En attendant, JPEG XL compresse l'image de l'article en 297ko (en lossless) et 68ko (en near lossless, ie. distance = 1). Pour un original de 466ko en webp.
La popularité du jpeg xl ne demande qu'à croitre, mais ses performances répondent bien à toutes les problématiques actuelles (et il permet la conversion sans perte des jpeg existants :))
# Et ?
Posté par arnauld . Évalué à 1.
Comment puis-je obtenir une image comme celle de l'article à partir de mes photos ?
arnauld
[^] # Re: Et ?
Posté par ls_odyssee . Évalué à 2.
Cf le commentaire de tissac
donc dans Gimp, menu "Outils", puis "Action GEGL…"
dans la boite de dialogue choisir Color Assimilation Grid, modifier ou pas les paramètres et valider
[^] # Re: Et ?
Posté par arnauld . Évalué à 1.
Merci.
arnauld
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.