Aaaah. Je viens (peut-être?) de comprendre. En fait, tu voulais me parler de l'ordre inverse (tu vois, quand je disais que d'indiquer l'ordre clairement, c'est important!):
(255 ×ばつ 2) / 2 = 128
(510 ×ばつ 4) / 4 = 128
En gros, tu me dis que parce qu'on fait un overflow, on tronque à la valeur max, donc la première multiplication ne sert à rien. C'est vrai (sauf que ça fait la valeur 127 à la fin, mais c'est un détail), mais y a plusieurs probs dans ta logique:
(1) Premier problème, et le plus gros: tu ne fais pas la même opération! Pourquoi tu multiplies par 2 dans une plage et par 4 dans l'autre? Oui forcément, pas la même opération, pas la même perte, c'est sûr. Et si tu as cru que c'était la même opération parce que la plage est 2 fois plus grande, alors... non c'est pas comme ça que ça marche! 😛
Si tu dis: je multiplie par 2 toutes les valeurs, ça ne dépend pas de la plage. Pour le prouver, rien de plus simple. Prenons un cas non extrême (sans troncation). Par exemple: 10 (en [0; 255]) = 20 (en [0; 511]).
10 ×ばつかける 2 =わ 20
20 ×ばつかける 4 =わ 80
Selon ta logique, 20 et 80 devraient alors être la même couleur. Or 20 ×ばつ 2 = 40! (pas 80!) Ton opération n'est pas censée changer en fonction de la plage. Ce n'est pas ainsi que marchent les maths (pour le coup, là ce sont des maths, pas un problème de l'informatique).
Note qu'on est un peu plus précis avec la plage en 29! CQFD. 🙂
(2) Ensuite tu as tout de même raison que dans ton cas extrême, tu perds quand même énormément de couleurs. Par contre, ce problème n'existe pas en flottant puisque comme je disais, c'est un type qui nous autorise à sortir de la plage [min; max]. C'est pour cela qu'en 16 et 32-bit, on conseille d'ailleurs le stockage flottant.
Ainsi en flottant, ton exemple devient:
(1.0 ×ばつ 2) / 2 = 2.0 / 2 = 1.0
Parfait, pas de perte! C'est parce qu'après le filtre 1 (multiplication par 2), on a pu garder une valeur intermédiaire supérieure à la valeur max.
Note: au passage, je sépare tes 2 opérations mathématiques en 2 filtres parce que si ça avait été un seul filtre qui fait 2 opérations mathématiques, même en entier, on aurait pu éviter un tel écueil (suffit de pas faire un code idiot! LOL). Donc pour que ton exemple soit valide, faut supposer que le résultat de la multiplication est une valeur de résultat en sortie de filtre. Seul le travail en nombres flottants te sauve à ce moment là.
(3) Enfin, il faut voir que cela reste des exemples extrêmes que tu nous sors (de même que ceux que je sortais pour simplifier et montrer les problèmes de précision). Attention, extrême ne veut pas dire impossible (tout est possible; si on le pense, on peut le coder) mais un filtre un peu bien fait ne ferait pas juste une bête multiplication. Genre tu veux augmenter la luminosité générale de ton image, tu vas pas juste t'amuser à tout multiplier par un nombre quelconque (et après t'étonner que toutes les valeurs hautes soient tronquées au max!). Tu auras plutôt des filtres qui vont essayer de répartir mieux et plus intelligemment tes valeurs. Ensuite il y aura clairement des valeurs qui vont se perdre, etc. Forcément, si tu essaies de monter globalement les valeurs de ton image, même si un peu plus intelligemment, tu te retrouves forcément avec des couleurs identiques, voire des couleurs qui sortent du gamut (donc tronquées) etc.
Donc ton exemple, bien qu'extrême, reste en plein dans le mille et montre bien ce qu'est l'édition raster. C'est un exemple simpliste donc on perdra jamais autant de valeurs que cela avec de bon filtres (donc on relativise), mais oui il faut garder en tête que c'est bien des maths qui se passent en arrière plan. Et oui, on va perdre des valeurs/données (ou en créer, ce qui n'est pas mieux, c'est synonyme en fait dans ce contexte, perdre et créer), on va potentiellement aller hors-gamut (donc tronquer et encore perdre/créer des données, à part si on est en flottant). Ça fait partie des choses à comprendre pour s'améliorer en édition d'image.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 16 bits & EXIF
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 8.
Aaaah. Je viens (peut-être?) de comprendre. En fait, tu voulais me parler de l'ordre inverse (tu vois, quand je disais que d'indiquer l'ordre clairement, c'est important!):
En gros, tu me dis que parce qu'on fait un overflow, on tronque à la valeur max, donc la première multiplication ne sert à rien. C'est vrai (sauf que ça fait la valeur 127 à la fin, mais c'est un détail), mais y a plusieurs probs dans ta logique:
(1) Premier problème, et le plus gros: tu ne fais pas la même opération! Pourquoi tu multiplies par 2 dans une plage et par 4 dans l'autre? Oui forcément, pas la même opération, pas la même perte, c'est sûr. Et si tu as cru que c'était la même opération parce que la plage est 2 fois plus grande, alors... non c'est pas comme ça que ça marche! 😛
Si tu dis: je multiplie par 2 toutes les valeurs, ça ne dépend pas de la plage. Pour le prouver, rien de plus simple. Prenons un cas non extrême (sans troncation). Par exemple: 10 (en [0; 255]) = 20 (en [0; 511]).
Selon ta logique, 20 et 80 devraient alors être la même couleur. Or 20 ×ばつ 2 = 40! (pas 80!) Ton opération n'est pas censée changer en fonction de la plage. Ce n'est pas ainsi que marchent les maths (pour le coup, là ce sont des maths, pas un problème de l'informatique).
Donc ton exemple aurait dû être:
Note qu'on est un peu plus précis avec la plage en 29! CQFD. 🙂
(2) Ensuite tu as tout de même raison que dans ton cas extrême, tu perds quand même énormément de couleurs. Par contre, ce problème n'existe pas en flottant puisque comme je disais, c'est un type qui nous autorise à sortir de la plage [min; max]. C'est pour cela qu'en 16 et 32-bit, on conseille d'ailleurs le stockage flottant.
Ainsi en flottant, ton exemple devient:
Parfait, pas de perte! C'est parce qu'après le filtre 1 (multiplication par 2), on a pu garder une valeur intermédiaire supérieure à la valeur max.
Note: au passage, je sépare tes 2 opérations mathématiques en 2 filtres parce que si ça avait été un seul filtre qui fait 2 opérations mathématiques, même en entier, on aurait pu éviter un tel écueil (suffit de pas faire un code idiot! LOL). Donc pour que ton exemple soit valide, faut supposer que le résultat de la multiplication est une valeur de résultat en sortie de filtre. Seul le travail en nombres flottants te sauve à ce moment là.
(3) Enfin, il faut voir que cela reste des exemples extrêmes que tu nous sors (de même que ceux que je sortais pour simplifier et montrer les problèmes de précision). Attention, extrême ne veut pas dire impossible (tout est possible; si on le pense, on peut le coder) mais un filtre un peu bien fait ne ferait pas juste une bête multiplication. Genre tu veux augmenter la luminosité générale de ton image, tu vas pas juste t'amuser à tout multiplier par un nombre quelconque (et après t'étonner que toutes les valeurs hautes soient tronquées au max!). Tu auras plutôt des filtres qui vont essayer de répartir mieux et plus intelligemment tes valeurs. Ensuite il y aura clairement des valeurs qui vont se perdre, etc. Forcément, si tu essaies de monter globalement les valeurs de ton image, même si un peu plus intelligemment, tu te retrouves forcément avec des couleurs identiques, voire des couleurs qui sortent du gamut (donc tronquées) etc.
Donc ton exemple, bien qu'extrême, reste en plein dans le mille et montre bien ce qu'est l'édition raster. C'est un exemple simpliste donc on perdra jamais autant de valeurs que cela avec de bon filtres (donc on relativise), mais oui il faut garder en tête que c'est bien des maths qui se passent en arrière plan. Et oui, on va perdre des valeurs/données (ou en créer, ce qui n'est pas mieux, c'est synonyme en fait dans ce contexte, perdre et créer), on va potentiellement aller hors-gamut (donc tronquer et encore perdre/créer des données, à part si on est en flottant). Ça fait partie des choses à comprendre pour s'améliorer en édition d'image.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]