Intérêt du 16 bpc au-lieu de 8 bpc (bits par couche)

Intérêt du 16 bits au-lieu de 8 bits par couche ?

Hello !

Je me demandais si on gagnait quelque chose à bosser en 16 bits par couche pour traiter du DV ?
En fait, je ne vois pas des masses l'intérêt du 16 bpc quel que soit le cas, d'ailleur...

Si quelqu'un a une théorie, ou mieux: la réponse, ça m'intéresserait !

Merci et à +,
Jeum.

 

ze linear floating point !

Voilà un cas où par exemple:
http://www.repaire.net/forums/showthread.php?s=&threadid=67028

Julien l'explique très biens

(Le sujet est abordé à partir du sixième messsage)

 

En fait, coder chaque composante avec 16 bits n'implique pas qu'elles soient encodées linéairement.

Comme tout le monde le sait, en DV, chaque composante est codée sur 8 bits. Cela signifie que chaque composante peut prendre une valeur entière entre 0 et 255 (bornes comprises). On ne peut rien changer à cela.

Cependant, un autre facteur entre en jeu: le stockage temporaire. Si, après chaque calcul, la composante est arrondie et stockée sur 8 bits, ou si elle est arrondie et stockée sur 16 bits, plus ou moins d'informations seront perdues. Regardons ceci avec un exemple concret.

Soit une composante ayant comme valeur 123.
Imaginons que nous voulons diminuer la luminosité de l'image de 50%, c'est à dire multiplier chaque composante par 0.5, c'est à dire diviser chaque composante par 2:

123.0 / 2.0 = 61.5

Comme vous le voyez, on a fait le calcul avec des nombres réels. Cependant, on ne va pas stocker le résultat comme un réel (32 bits), mais comme un entier sur 8 bits. Donc on l'arrondi et on le stocke.

round(61.5) = 62

Maintenant, ajoutons un nombre, 2 par exemple, et multiplions par 2:

(62.0 + 2.0) * 2.0 = 128.0

Comme avant, on calcule avec des nombres réels, puis on arrondi et on stocke le résultat comme un entier sur 8 bits.

round(128.0) = 128

Est-ce la bonne réponse? Non!

(123 / 2 + 2) * 2 = 127

Nous avons deux moyens de règler ce problème.
Le premier est de travailler sur 16 bits, c'est à dire sur un éventail d'entiers allant de 0 à 65535. Nous allons rééchantillonner notre image sur 16 bits, c'est à dire multiplier chaque composante par 255.

Si nous reprenons notre exemple...

123.0 * 255.0 = 31365.0 = 31365

Divisons par deux:

31365.0 / 2.0 = round(15682.5) = 15683

Ajoutons 2 * 255:

15683.0 + 510.0 = 16193.0 = 16193

Et multiplions par 2:

16193.0 * 2.0 = 32386.0 = 32386

Retournons à 8 bits en divisant par 255:

32386.0 / 255.0 = round(127.003) = 127

Cette fois-ci, la réponse est correcte!

Ce qui est important de constater, c'est que dans les deux cas, les calculs sont fait avec des nombres réels, puis arrondis et stockés comme des entiers de 8 ou 16 bits.
Pourquoi arrondir? C'est une question de taille. Calculer avec des entiers ou des réels, finalement, ça ne change pas grand chose dans le temps de calcul (la plupart des opérations demandent des nombres réels de 0 à 1, de toute façon). Par contre, STOCKER une image avec seulement des réels demande 4 (32 bits au lieu de 8 bits) fois plus de place!

Cependant, comme on l'a vu, stocker une image avec plus de bits permet de perdre moins d'informations lors des arrondissements. Il faut donc choisir entre qualité et taille.

Il y a encore une autre possibilité, c'est de stocker l'image sous forme de nombres réels (floating point) sur 32 ou 64 bits. Ca demande beaucoup plus de place, mais alors on n'a plus besoin d'arrondir. C'est donc la méthode qui donne le résultat le plus correct.
Travailler avec des réels offrent une autre possibilité: on peut stocker des nombres allant de moins l'infini à plus l'infini. Comme, généralement, on défini le noir comme 0 et le blanc comme 1, on remarque vite que l'on peut stocker énormément plus de valeurs. C'est le principe d'une image HDR.

Je peux encore préciser que eLin permet de travailler en HDR sur des entiers de 16 bits. En fait, il faut spécifier combien de bits en dessus de blanc on veut allouer, et, au lieu de multiplier l'image par 255, on l'a multiplie par 200 (par exemple). Le blanc sera donc à 255 * 200, et les valeurs en dessus seront considérées comme plus blanc que blanc, ce qui nous permet donc de considérer l'image comme une image HDR.

Maintenant, on se qui concerne la linéarité de l'image, c'est une autre question. La seule chose à savoir, c'est que transformer une image sRGB en une image linéaire puis revenir à une image sRGB demande beaucoup d'arrondissements. De le faire en 8 bits feraient perdre pratiquement 75% des informations de l'image. C'est pour cela qu'on associe souvent cette notion avec le fait qu'elle demande des images "floating point" (ou, au moins, codées sur 16 bits).

After Effects ne permet pas de travailler avec des réels.

 

Julien is back !

plutôt de passage si j'ai bien compris.

 

Hello !

Depuis quelques temps, je me suis converti à Color Finesse (de Synthetic Aperture) pour faire de l'étalonnage.
Et si j'ai bien lu ce qu'ils mettent sur leur site, depuis la dernière version (la 1.5.3) ce plugin travaille en 32 bits linear floating point.

Seulement, je ne comprends plus bien à ce niveau. Cet argument voudrait donc dire que dès lors qu'on effectue des corrections avec Color Finesse, un rééchantillonnage intervient pour décrire l'image par valeurs réelles sur 32 bits, avant d'arrondir au moment du rendu (et ainsi revenir en 8 ou 16 bits, selon le choix qu'on a fait dans ses paramètres de projet) ?

C'est vrai que j'avais l'impression que les corrections faites avec color finesse étaient moins destructrices pour l'image que celles utilisant les effets d'AE, mais je ne peux pas le garantir.

A +,
Jeum.

EDIT: dans ce .pdf : http://www.synthetic-ap.com/products/cf/cfdatasheet.pdf , Synthetic Aperture explique dès le début que Color Finesse bosse en 32 bits par couche soit 96 bits au total...

 

Je suppose que Color Finesse travaille dans une fenêtre séparée?
Je mettrais ma main à couper que tout les calculs sont fait indépendamment de l'API d'After Effects. En gros, Color Finesse récupère l'image sous After Effects, la modifie de son côté, et quand il a fini, l'a renvoit à After Effects.
Au moment de renvoyer l'image à After Effects, il est obligé de reconvertir l'image à 8 ou 16 bits. Mais tant qu'il travaille de son côté, il fait ce qu'il veut, donc travailler en 32 bits.

eLin ne peut pas faire la même chose. Il faudrait que toutes les manipulations entre la linéarisation et la délinéarisation soient faites ailleurs, ce qui est bien entendu pas possible.

Je ne sais pas pourquoi After Effects ne permet pas de travailler nativement avec des réels. Peut-être parce que, avant d'être un logiciel de compositing, il est un logiciel d'animation.
Disons qu'il est également plus dur de gérer la mémoire en travaillant en 32 bits. Shake et Digital Fusion le font très bien.

 

Hello !

Très bonne intuition (déduction ?... ) mon cher Lock !...

En effet, Color Finesse travaille dans une fenêtre séparée, ce qui est galère à mon goût, car on est obligé de basculer entre ce plug et AE quand on veut étalonner un bout de calque (découpé par un masque) posé sur un autre calque: Color Finesse n'affichant dans sa fenêtre moniteur que le calque sur lequel il s'applique...

Mais si comme tu le penses, il travaille en 32 bits quand on est dans la fenêtre Color Finesse et revient en 8 bits dès qu'on en sort, que se passe-t-il si on fait plusieurs allers-retours entre la fenêtre Color Finesse et AE ? Y'a-t-il arrondi puis rééchantillonnage à chaque retour sous CF, ou bien le plugin est suffisamment bien conçu pour reprendre les valeurs réelles qu'il avait calculées dès qu'on y revient (je suis assez clair ?... ).
En gros, je pense que si l'on arrondit à chaque retour sous AE, on perd de l'info par approximation d'un résultat et chaque manip introduit une nouvelle approximation, peu pratique si l'on fait de très légères modifications à chaque fois, jusqu'à trouver le bon réglage.

On dirait que d'entrevoir un peu mieux le fonctionnement du codage des infos me pose plus de questions que ça ne m'amène de réponses...
Mais d'un point de vue intellectuel, on se sent un peu moins ignare devant la machine... Merci !

A +,
Jeum.

 

Hello Jeum,

d'apres ce que dis Julien, j'ai l'impression que Color Finess fait son propre rendu (donc en 32 bits)... Mais bon je ne suis sur de rien, je me pose beaucoup de questions tout comme toi...
J'ai cru remarquer moi aussi que Color Finesse dégrade moins l'image que le fait par exemple l'outil courbes classique...

Psychotage ou réalité...?

 

Comme dit plus haut, c'est justement du au fait qu'il travaille en 32 bits.

 

8 ou 16 bcp

bonjour a tous j ai une question assez bete mais je viens de m'apercevoir que tous mes projets sont en 8bits par couche alors qu on peut les mettre en 16 bits. je suppose que cela engendre une perte de qualité. je voulais donc savoir si vous travaillez en 8 ou 16 bit. autre question : certain effet comme caustique ne prennent pas en compte le 16 bits pourquoi?


merci

 

Bonjour mat321$


J'ai recollé ta discussion dans ce sujet sur le 16 bpc, j'espère que ça t'aidera. Tu peux continuer à poser tes questions sur ce sujet à la suite.

Merci