Juste au cas où pour améliorer ton explication, cette transformation m'a fait tiquer au premier abord. 2 reste 2 en 8, 9, 16, 32 ou 1 millions de bits normalement. Ici les valeurs sont réparties. On pars d'une plage de [0; 256[ et on arrive à [0;512[ on multiplie par 2 pour laisser un espace entre les couleurs.
En colorimétrie RGB, y a effectivement un min et un max car c'est un espace de couleur relatif (tout comme CMYK). Le min et le max restent le min et le max. Donc effectivement si ta plage change, tu dois simplement mettre à l'échelle tous les nombres. Les nombres en soit n'ont aucun sens colorimétrique. 2 ne veut rien dire. La couleur rouge (ou bleue ou verte) '2', ça n'existe pas. Cette valeur n'a de sens que par rapport à ce min et ce max qui sont définis de manière absolue (donc dans une échelle avec un sens colorimétrique absolue, comme l'espace de couleur CIE XYZ) et par rapport à un TRC (Tone Reproduction Curve) qui va définir comment tu progresses de la valeur min à la valeur max. C'est à ça que servent les profiles de couleurs, qui vont faire un espace de couleur à partir d'un modèle de couleur.
Ensuite y a la question du stockage mais qui est une préoccupation parallèle: typiquement est-ce que tu stockes des entiers ou des flottants? Si tu utilises des entiers sur n bits, ton min est généralement 0 et ton max 2n - 1 (par exemple [0; 255] sur 8 bits ou [0; 511] sur 9 bits). Si par contre, tu utilises des flottants, tu va généralement juste de 0 à 1.0 quel que soit la taille du flottant.
J'utilise des entiers dans mes exemples car c'est plus facile pour faire comprendre. Mais le rouge 255 en 8-bit est le même rouge que le 511 en 9-bit ou que le 1.0 en 16-bit flottant (si on utilise le même espace de couleur, donc les mêmes couleurs primaires).
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).
J'ai l'impression que cet exemple montre surtout qu'il faudrait n'appliquer les opérations qu'au moment de l'export et utiliser une résolution des opérations "intelligente".
C'est à ça que servent les calques d'effet notamment (dans le contexte de l'édition non-destructive; ce qui est un mauvais terme, d'une part parce que toute édition est destructive et constructive: on détruit et fabrique de nouvelles données; d'autre part parce que le but n'est donc pas de ne pas changer les données mais de les changer le moins possible).
Donc au lieu de modifier les données au dessus de données modifiées, on garde un graphe. Par exemple un graphe vraiment simple et linéaire:
Pixels de l'image finale
⬆️
Effet 2
⬆️
Effet 1
⬆️
Pixels de l'image d'origine intouchée
En édition classique, si on n'est pas content de l'image finale, on peut rajouter un effet, puis un autre, puis un autre (et perdre/créer des données à chaque fois). Ou bien on peut annuler les effets, mais si on n'a pas gardé une copie de l'original, c'est un problème. Et potentiellement il faut reproduire les 2 effets alors qu'on voulait en changer qu'un seul (donc perte de temps). En "non-destructif", tu vas juste éditer les paramètres de l'Effet 1 par exemple et le graphe recalcule.
Le second truc, c'est effectivement dans certains cas particulier, tu peux même combiner les effets. C'est le cas typique des transformations mathématiques classiques (rotations, redimensionnement, symétries, etc.), qui sont (comme toute personne qui a fait des maths le sait) simplement des multiplications de matrice. Or supposons que les effets 1 et 2 sont tous deux des multiplications de matrice, tu peux les combiner en une matrice unique et ne faire alors qu'une opération (tu en montrerais toujours 2 dans le graphe pour la sémantique, mais si ton système de graphe est suffisamment malin, il peut éventuellement optimiser).
Pourtant en mathématiques, c'est exactement la même chose (associativité), mais pas en informatique. Puisqu'on a vu que chaque opération fait perdre des données. Oui en manipulation raster, une rotation de 30° n'est pas la même chose (et est préférable) à 2 rotations à 15°! On peut même donner l'exemple ultime: une rotation à 90° peut être fait sans perte (cas d'exception!) alors que 2 rotations à 45° ne le sont pas et abîmeront votre image!
Donc bah voilà, tout cela pour dire que ce dont tu parles, c'est ce que les gens appellent l'édition non-destructive et c'est la raison des succès des calques d'effets, ou même en mieux de l'édition par graphe (très en vogue en 3D notamment). Ces choses arriveront dans GIMP aussi. 🙂
255 ×ばつ 2 / 2 = 128
510 ×ばつ 4 / 4 = 128
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. Mais surtout, ils sortent d'où tes 128?
En supposant que tu essayais de reproduire mes exemples où tu fais la division d'abord. Alors on a:
Mais... je vois pas pour autant ce que tu essayais de prouver. Qu'est-ce qu'on a annihilé? Je ne vois aucun problème particulier dans tes exemples. Et sûrement pas une preuve que coder avec un bit supplémentaire soit plus mauvais pour la précision, bien au contraire.
P.S.: à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2. Mais je crois pas que quiconque s'amuse à faire des mathématiques informatiques sur 9 bits. C'est plus simple de faire ça sur 16 ou 32-bit (on utilise des octets entiers, car de nos jours, c'est ainsi que sont souvent définis les types pour représenter des nombres). Je suppose que tu as bien compris cela, mais je précise juste au cas où. 🙂
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é à 7.
En colorimétrie RGB, y a effectivement un min et un max car c'est un espace de couleur relatif (tout comme CMYK). Le min et le max restent le min et le max. Donc effectivement si ta plage change, tu dois simplement mettre à l'échelle tous les nombres. Les nombres en soit n'ont aucun sens colorimétrique. 2 ne veut rien dire. La couleur rouge (ou bleue ou verte) '2', ça n'existe pas. Cette valeur n'a de sens que par rapport à ce min et ce max qui sont définis de manière absolue (donc dans une échelle avec un sens colorimétrique absolue, comme l'espace de couleur CIE XYZ) et par rapport à un TRC (Tone Reproduction Curve) qui va définir comment tu progresses de la valeur min à la valeur max. C'est à ça que servent les profiles de couleurs, qui vont faire un espace de couleur à partir d'un modèle de couleur.
Ensuite y a la question du stockage mais qui est une préoccupation parallèle: typiquement est-ce que tu stockes des entiers ou des flottants? Si tu utilises des entiers sur n bits, ton min est généralement
0et ton max2n - 1(par exemple[0; 255]sur 8 bits ou[0; 511]sur 9 bits). Si par contre, tu utilises des flottants, tu va généralement juste de 0 à 1.0 quel que soit la taille du flottant.J'utilise des entiers dans mes exemples car c'est plus facile pour faire comprendre. Mais le rouge 255 en 8-bit est le même rouge que le 511 en 9-bit ou que le 1.0 en 16-bit flottant (si on utilise le même espace de couleur, donc les mêmes couleurs primaires).
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).
C'est à ça que servent les calques d'effet notamment (dans le contexte de l'édition non-destructive; ce qui est un mauvais terme, d'une part parce que toute édition est destructive et constructive: on détruit et fabrique de nouvelles données; d'autre part parce que le but n'est donc pas de ne pas changer les données mais de les changer le moins possible).
Donc au lieu de modifier les données au dessus de données modifiées, on garde un graphe. Par exemple un graphe vraiment simple et linéaire:
En édition classique, si on n'est pas content de l'image finale, on peut rajouter un effet, puis un autre, puis un autre (et perdre/créer des données à chaque fois). Ou bien on peut annuler les effets, mais si on n'a pas gardé une copie de l'original, c'est un problème. Et potentiellement il faut reproduire les 2 effets alors qu'on voulait en changer qu'un seul (donc perte de temps). En "non-destructif", tu vas juste éditer les paramètres de l'
Effet 1par exemple et le graphe recalcule.Le second truc, c'est effectivement dans certains cas particulier, tu peux même combiner les effets. C'est le cas typique des transformations mathématiques classiques (rotations, redimensionnement, symétries, etc.), qui sont (comme toute personne qui a fait des maths le sait) simplement des multiplications de matrice. Or supposons que les effets 1 et 2 sont tous deux des multiplications de matrice, tu peux les combiner en une matrice unique et ne faire alors qu'une opération (tu en montrerais toujours 2 dans le graphe pour la sémantique, mais si ton système de graphe est suffisamment malin, il peut éventuellement optimiser).
Pourtant en mathématiques, c'est exactement la même chose (associativité), mais pas en informatique. Puisqu'on a vu que chaque opération fait perdre des données. Oui en manipulation raster, une rotation de 30° n'est pas la même chose (et est préférable) à 2 rotations à 15°! On peut même donner l'exemple ultime: une rotation à 90° peut être fait sans perte (cas d'exception!) alors que 2 rotations à 45° ne le sont pas et abîmeront votre image!
Donc bah voilà, tout cela pour dire que ce dont tu parles, c'est ce que les gens appellent l'édition non-destructive et c'est la raison des succès des calques d'effets, ou même en mieux de l'édition par graphe (très en vogue en 3D notamment). Ces choses arriveront dans GIMP aussi. 🙂
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 = 254mais(255 ×ばつ 2) / 2 = 255en calcul entier, sans perte de précision dans cet ordre!) sinon je comprends pas là où tu veux en venir. Mais surtout, ils sortent d'où tes 128?En supposant que tu essayais de reproduire mes exemples où tu fais la division d'abord. Alors on a:
Mais... je vois pas pour autant ce que tu essayais de prouver. Qu'est-ce qu'on a annihilé? Je ne vois aucun problème particulier dans tes exemples. Et sûrement pas une preuve que coder avec un bit supplémentaire soit plus mauvais pour la précision, bien au contraire.
P.S.: à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2. Mais je crois pas que quiconque s'amuse à faire des mathématiques informatiques sur 9 bits. C'est plus simple de faire ça sur 16 ou 32-bit (on utilise des octets entiers, car de nos jours, c'est ainsi que sont souvent définis les types pour représenter des nombres). Je suppose que tu as bien compris cela, mais je précise juste au cas où. 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]