D'abord transformons nos valeurs dans le format de travail 9-bit:
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. Comme tu le montre il faut retraduire toutes les opérations pour ce format. J'imagine que c'est pour ça qu'avec GEGL vous travaillez exclusivement en 32bits si j'ai bien compris. Comme ça les opérations n'ont pas à être implémentée pour tous les encodages possibles de couleur.
\frac{2}{2}2 = 1 \times 2 = 2
\frac{3}{2}2 = 1 \times 2 = 2
Là c'est même pire que tout, on a carrément deux opérations qui auraient dû s'annuler mais qui à la place ont juste fait perdre des couleurs. Ça veut notamment dire que tous les 3 de l'image ont d'ailleurs disparu (en fait tous les nombres impairs dans cet exemple), on a vraiment perdu en précision !
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 j'imagine très compliqué car les pixels ne sont souvent calculé en groupe. Donc chaque pixel devient non plus 3 valeurs, mais un système de 3 opérations qui sont perpétuellement recalculés pour l'affichage. Ça rend caduque toutes les formes d'optimisations classiques à coup de SIMD par exemple.
Par contre ça me pose une dernière question. Utiliser le codage 9bits que tu décris n'est pas exempte de problème. Si je reprend tes opérations, mais dans l'ordre inverse (et avec d'autres valeurs), sur 8 bits :
Sur 16 bits :
128 en 9bits donc 64bits en 8bits. Ici ce n'est même plus une perte de précision ça a annihilé la moitié de la plage de couleur. Pour gérer ce genre de cas de manière total il faudrait que les entiers soient représentés en taille arbitraire (ou à minima que ce soit le cas lorsque l'on détecte un overflow), mais ça casse encore toute optimisation... Pou mitiger un peu ces problèmes est-ce que la représentation 32bits utilise toute la plage ou est-ce que ça n'utilise pas qu'une partie ?
[^] # 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.
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. Comme tu le montre il faut retraduire toutes les opérations pour ce format. J'imagine que c'est pour ça qu'avec GEGL vous travaillez exclusivement en 32bits si j'ai bien compris. Comme ça les opérations n'ont pas à être implémentée pour tous les encodages possibles de couleur.
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 j'imagine très compliqué car les pixels ne sont souvent calculé en groupe. Donc chaque pixel devient non plus 3 valeurs, mais un système de 3 opérations qui sont perpétuellement recalculés pour l'affichage. Ça rend caduque toutes les formes d'optimisations classiques à coup de SIMD par exemple.
Par contre ça me pose une dernière question. Utiliser le codage 9bits que tu décris n'est pas exempte de problème. Si je reprend tes opérations, mais dans l'ordre inverse (et avec d'autres valeurs), sur 8 bits :
Sur 16 bits :
128 en 9bits donc 64bits en 8bits. Ici ce n'est même plus une perte de précision ça a annihilé la moitié de la plage de couleur. Pour gérer ce genre de cas de manière total il faudrait que les entiers soient représentés en taille arbitraire (ou à minima que ce soit le cas lorsque l'on détecte un overflow), mais ça casse encore toute optimisation... Pou mitiger un peu ces problèmes est-ce que la représentation 32bits utilise toute la plage ou est-ce que ça n'utilise pas qu'une partie ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll