P.S.: les flottants ont aussi un gros avantage qui est de pouvoir aller sous zéro et au dessus de 1.0. Puisqu'on rappelle que le min et max sont juste un choix arbitraire, les couleurs hors de cette plage sont des couleurs tout à fait valides. Simplement elles ne sont pas autorisées dans l'espace de couleur en cours ("hors gamut"). Mais il est super intéressant de pouvoir les garder jusqu'au bout parce que — qui sait — certains effets ramèneront peut-être la couleur des pixels hors-gamut à l'intérieur. Or supposons qu'on ait tronqué les couleurs plus tôt, ben là encore, on a mis plein de couleurs à la même couleur trop tôt et donc perdu énormément de précision (i.e. bandes de couleurs, etc.). Alors que si on les garde jusqu'au bout, on a une chance de garder la précision (on ne tronque qu'au moment de l'export).
Hum en flottant la précision de tes opérations mathématiques baisse beaucoup. Tu as une approximation qui est faite à chaque opération. Pour ce qui est de la plage, je comprends donc que lorsque l'on utilise les flottants on utilise une toute petite partie on utilise de [0; 1.0] pour représenter les couleurs visibles au sein d'une plage de valeur allant de -126 à 127. Ça évite le problème dont je parlais pour d'écrasement.
C'est à ça que servent les calques d'effet notamment[...]
D'acc je comprends. J'ai pas compris si ça existe dans gimp ou si ça va exister ?
Euh... je comprends pas du tout tes maths là. Bon déjà quand on fait des maths en informatique, on perd l'associativité, donc faut mettre des parenthèses (c'est à dire que (255 / 2) ×ばつ 2 = 254 mais (255 ×ばつ 2) / 2 = 255 en calcul entier, sans perte de précision dans cet ordre!) sinon je comprends pas là où tu veux en venir.
Euh... Le numérateur se calcul avant, il n'y a pas besoin des parenthèses avec la représentation que j'utilise.
Mais surtout, ils sortent d'où tes 128?
Excuse-moi je me suis dis après coup qu'il falait que je détail et puis j'ai validé trop vite. Je vais utiliser une représentation en ligne pour m'aligner sur ta façon et détailler. On est en 8bits donc avec des valeurs de 0 à 255.
(255 * 2) / 2 = 255 / 2
Tu ne peux pas représenter de valeur au dessus de 255 donc je présume que toutes les opérations sont toutes calculées en prenant le minimum entre la résultat et la borne haute et le maximum entre le résultat et la borne basse. Si ça n'est pas le cas c'est que l'overflow est laissé tel quel est ça donne
(255 * 2) / 2 = 254 / 2 → c'est à dire 510 mod 256
Par contre il y avait une erreur dans mon calcul ça donne dans les 2 cas 127 et pas 128.
En supposant que tu essayais de reproduire mes exemples où tu fais la division d'abord.
J'ai volontairement inversé les opérations pour dépasser la borne haute sans supposer qu'il s'agissait de la même opération que toi.
Je ne vois aucun problème particulier dans tes exemples.
Mes exemples visaient à montrer que quelque si ton gammut (si j'ai bien compris) correspond aux bornes de ta représentation toute multiplication va avoir des conséquences problématiques. Tu va overflow ton entier et tomber sur une valeur que ta représentation ne sait pas représenter (je parle bien de l'aspect mathématiques). Ça n'est pas pire en 9 qu'en 8bits. Tu as répondu à cette question en parlant plus haut du codage flottant qui n'utilise qu'une toute petite parti de l'espace pour code le gammut.
à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2.
Tout à fait c'est la manière de passer du 8 bits à une autre représentation qui m'a intriguée.
[^] # Re: 16 bits & EXIF
Posté par barmic 🦦 . 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é à 3.
Hum en flottant la précision de tes opérations mathématiques baisse beaucoup. Tu as une approximation qui est faite à chaque opération. Pour ce qui est de la plage, je comprends donc que lorsque l'on utilise les flottants on utilise une toute petite partie on utilise de [0; 1.0] pour représenter les couleurs visibles au sein d'une plage de valeur allant de -126 à 127. Ça évite le problème dont je parlais pour d'écrasement.
D'acc je comprends. J'ai pas compris si ça existe dans gimp ou si ça va exister ?
Euh... Le numérateur se calcul avant, il n'y a pas besoin des parenthèses avec la représentation que j'utilise.
Excuse-moi je me suis dis après coup qu'il falait que je détail et puis j'ai validé trop vite. Je vais utiliser une représentation en ligne pour m'aligner sur ta façon et détailler. On est en 8bits donc avec des valeurs de 0 à 255.
Tu ne peux pas représenter de valeur au dessus de 255 donc je présume que toutes les opérations sont toutes calculées en prenant le minimum entre la résultat et la borne haute et le maximum entre le résultat et la borne basse. Si ça n'est pas le cas c'est que l'overflow est laissé tel quel est ça donne
Par contre il y avait une erreur dans mon calcul ça donne dans les 2 cas 127 et pas 128.
J'ai volontairement inversé les opérations pour dépasser la borne haute sans supposer qu'il s'agissait de la même opération que toi.
Mes exemples visaient à montrer que quelque si ton gammut (si j'ai bien compris) correspond aux bornes de ta représentation toute multiplication va avoir des conséquences problématiques. Tu va overflow ton entier et tomber sur une valeur que ta représentation ne sait pas représenter (je parle bien de l'aspect mathématiques). Ça n'est pas pire en 9 qu'en 8bits. Tu as répondu à cette question en parlant plus haut du codage flottant qui n'utilise qu'une toute petite parti de l'espace pour code le gammut.
Tout à fait c'est la manière de passer du 8 bits à une autre représentation qui m'a intriguée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll