Bonjour à tous.
Je me pose des questions sur le 8 et le 16bits.

Cas d'école :

1) une image 16bits
2) la même image en 8bits
3) la même image d'origine 8 bits passée en 16bits

Si je triture ces images un max, quels seraient d'après vous les résultats au final.
Il est évident que celle en 16 bits serait la moins abimée, mais qu'en serait-il pour les 2 autres?

Au premier abord j'aurais dis la 2 et la 3 identiques, mais mes tests font apparaitre pour l'instant que c'est beaucoup moins évident.

Qu'en pensez vous?

Je ne suis pas mathématicien, cependant la pratique m'a permis d'apprécier certains résultats bruts.

Une image 8 bit perd des informations par rapport à la 16 bit. Repassez-la en 16bit, et vous travaillez avec des données incomplètes. La chose est très évidente lorsque vous travaillez sur des dégradés lisses. Une perte de nuances est patente, et se matérialise par l'apparition de moiré, très sensible si vous êtes sur un gris formé des trois couleurs RGB.

PdF

sans être matheu j´essaye de répondre,
en 8 bits tu as 256 valeurs de gris, en 16bits 256x256.

Dans un monde idéal on représenterait les valeurs par un nombre réel pris entre 0 (noir) et 1 (blanc).
Il y a une infinité de nombre réel entre 0 et 1.

Si tu interpoles une image 8 bits en 16 bits, le noir et le blanc sont les nombres nimimum et maximum
representables et les gris intermédiares sont calculés.

A chaque opération sur l´image lorsqu´une nouvelle valeur réelle est calculée pour un pixel
cette valeur est remplacée par le nombre entier le plus proche. Pour un pixel représenté
en 8 bits l´erreur relative est donc comprise entre 0 et 0,5/256. En 16 bits 0,5/(256x256)

A la louche, tu pourrais tripatouiller une image 16 bits 128 fois avant d´avoir l´erreur commise en 1 tripatouillage d´une image 8bits. (Est ce bien vrai?)

Dans un monde idéal, on ne ferait que des opérations sur des nombres réels.
Un logiciel de traitement d´image devrait avoir une représentation interne de l´image
en nombre réels (ici aussi il y a encore plusieurs niveaux de précision), devrait aussi d´abord
combiner les traitements successifs en un seul avant de l´appliquer à l´image.

oui jusque là on est d'accord, mais si je passe une image de 8 bits à 16bits, je ne crée pas de matière intermédiaire, on est tous d'accord, sauf que maintenant mon info est codée sur 16bits et que si je la triture je triture une info codée EN 16bits, et c'est là que je me pose la question!!!

ce qui est important ce sont les valeurs intermediaires.
prend le cas de deux pixels adjacents de valeur 1 et 2 en 8 bits
en 16bits il auront la valeur 256 et 512

tu appliques une courbe y=x/2 les valeurs 8 bits seront 0 et 1, en 16 bits 128 et 256
tu refais y=x/2 les valeurs 8 bits seront 0 et 0, en 16 bits 64 et 128
maintenant tu remultiplies par deux en 8 bits tu auras 0 et 0, en 16 bits 128 et 256

en deux coups de cuillère à pot, on a perdu nos noirs intermédiaire en 8 bits alors qu´il sont toujours là en 16bits.

c´est un exemple approximatif bien sûr.



Modifié 1 fois. Dernière modification le 27/02/2011, 13:23 par Ron Talis.

Ron je suis d'accord avec toi, mais je reformule ma question.

Y a t-il un intérêt de passer une image en 8bits(impossible de la faire en 16bits cause scan en 8bits) en 16bits avant passage sous PS.

J'aurai eu tendance à dire non, mais maintenant j'ai un doute, le fait de passer une 8bits en 16 me donne plus d'éléments binaires pour coder mon image, même si je n'ajoute pas de tons intermédiaires, mais les opérations suivantes auront lieu sur du 16 et non du 8, donc plus de données pour moins de pertes ?????

Si après avoir fait le passage 8 -> 16 bits on fait un ré-echantillonnage (en changeant légèrement la taille), et si applique une compression identique (p.e, en mettant , dans "niveaux" le curseur du blanc sur 200 et celui du noir sur 50), l'aspect des "peignes" dans niveaux est radicalement différent sans ou avec ré-échantilonnage.
Il faut croire que pour reprendre le terme de François C, on a créé de la matière intermédiaire.

Pour les raisons évoquées par Ron, il est toujours préférable de travailler en 16 bits. En 8 bits, la moindre opération sur la luminosité ou les couleurs va aboutir à un histogramme "en peigne" à cause des erreurs d'arrondis : sur les 8 bits théoriques, on finit par n'en utiliser plus que 7 (voir moins), soit 2 fois moins de valeurs dans les dégradés. Le même phénomène se produit en 16 bits, sauf que le peigne est tellement fin que l'oeil ne le voit pas comme un peigne, mais comme une surface continue; Si on perd 2 bits sur 16, il en reste 14, soit plus de 16 000 nuances dans les couleurs, ce qui reste toujours plus que ce nos yeux sont capables de discerner.

[www.imprimart.fr] // [www.laurentmartelli.com]

Laurent, l'hypothèse de départ, c'est du 8 bits car pas possible d'avoir du 16bits

Est-ce correct de prendre pour comparaison une série de calculs qui seraient effectués avec une ou deux décimales? Dans le deuxième cas, et même si le résultat final est arrondi á une décimale, il serait différent du premier et plus juste.

Gabriel

frederic_cornu écrivait:
-------------------------------------------------------
> Laurent, l'hypothèse de départ, c'est du 8 bits
> car pas possible d'avoir du 16bits

Même si au départ on a que 8 bits, il vaut mieux passer en 16 bits et travailler en 16 bits. L'analogie de Gabriel est tout à fait juste.

Ceci-dit, tout cela reste très théorique, et les résultats pratiques peuvent varier grandement selon les traitements effectués. Et si on multiplie par un coefficient >1 des valeurs 8 bits, même en travaillant en 16 bits, on aura un effet peigne. Par exemple, prenons un dégradé doux avec 9 pixels adjacents ayant pour valeur 90,90,90,91,91,91,92,92,92. Si on multiplie par 2 les valeurs, on obtiens 180,180,180,182,182,182,184,184,184 : il y a un effet d'escalier dans le dégradé.

[www.imprimart.fr] // [www.laurentmartelli.com]

Laurent quand tu parles de multiplication, tu penses à l'extrapolation ou alors à une opération de calcul lors d'une modif quelconque sous PS?

Car pour mon raisonnement je pars sur un format qui ne varie pas.

Je parlais de multiplier la valeur de chaque pixel lors l'utilisation de l'outil de courbe pour changer le contraste ou éclaircir les ombres par exemple, pas d'interpolation lors d'un changement de taille. Sans les images pour illustrer c'est pas forcément très clair. En voici une pour illustrer mon propos : le dégradé du haut (1) va d'un gris à 39% (valeur=100 sur 8 bits) à un gris à 50% (valeur=128 sur 8 bits). On a donc 129 plages de gris . La transition est douce et imperceptible à l'oeil nu. Si on lui applique la courbe du milieu, soit un gros contraste, on obtient le dégradé 2 du dessous, qui va de 6% à 98%, mais toujours avec 29 plages de gris. A comparer avec le dégradé 3, qui comporte 236 plages de gris. Travailler en 16 bits n'apporte rien pour ce cas de figure si l'image de départ est en 8 bits.

Maintenant, imagines que l'image subisse 2 traitements : la courbe présentée ci-dessus, puis son inverse. Là encore travailler sur 16 bits n'apporte pas grand chose : tu vas retrouver l'image de départ (1) à très peu de chose près. Mais si tu pars de l'image 3, et que applique les 2 traitement en sens inverse, en 8 bits tu vas te retrouver avec l'image 2, et en 16 bits tu vas récupérer l'image 3.

Bon évidemment, c'est un cas d'école un peu stupide, et en pratique on ne s'amuse à appliquer un traitement et son inverse. Ce qui relativise donc ma première intervention.

Travailler en 16 bits peu néanmoins apporter encore plus de finesse dans les dégradés lors d'une diminution de contraste (3->1). Mais est-ce visible sur un tirage ? Je n'en sais rien.

Voilà, j'espère que je t'ai bien embrouillé avec mes réponses ;-)

[www.imprimart.fr] // [www.laurentmartelli.com]

Non Laurent c'a va j'arrive encore à suivre.

Donc je dirais en résumé, à partir d'un 8bits, on ne risque rien de passer en 16bits, sachant qu'il peut ou non y avoir un gain, mais que de toute façon on ne peut qu'y gagner et à part le poids de l'image, il n'y a pas de contraintes autres.

Que penses tu de ce résumé?

oui !

Ca me paraît être un bon résumé.

Le seul inconvénient de travailler en 16 bits est que les traitements peuvent être plus lents.

[www.imprimart.fr] // [www.laurentmartelli.com]

OK voilà une interrogation rondement menée, merci à tous et particulièrement à Laurent pour sa pédagogie.

Et salut à David qui nous a rejoint sur le tard.

A+

Dans '"La gestion des couleurs pour les photographes", Jean Delmas écrit que travailler en 8 bits dans un espace de couleurs très vaste peut avoir des effets néfastes. En effet, si l'espace de travail est beaucoup plus grand que l'espace réellement "occupé" par un image, celle-ci n'utilisera pas les 256 valeurs par canal que permettent les 8 bits mais moins.

[www.imprimart.fr] // [www.laurentmartelli.com]

Je le fais parfois, de repasser une image 8 bits en 16 bits, pour une intervention un peu musclée !
Et au niveau de l'histogramme, il y a une grosse différence.
Mais je me suis posé la même question que Frederic, pour la conversion 8 bits en 16 par rapport à 16 bits d'origine, je n'ai jamais eu la réponse. Il y a probablement une différence mais de quel ordre et est-ce quantifiable ?

Pascal Moraiz écrivait:
-------------------------------------------------------
> Je le fais parfois, de repasser une image 8 bits
> en 16 bits, pour une intervention un peu musclée
> !
> Et au niveau de l'histogramme, il y a une grosse
> différence.
> Mais je me suis posé la même question que
> Frederic, pour la conversion 8 bits en 16 par
> rapport à 16 bits d'origine, je n'ai jamais eu la
> réponse. Il y a probablement une différence mais
> de quel ordre et est-ce quantifiable ?

Quantifier est difficile pour de modestes photographes, il faut un vrai labo numérique pour quantifier.

Si l'on prend un 8 bits et que l'on le passe en 16 Bits on multiple les valeurs numériques par 256, c'est à dire que chaque valeurs va être représentée par 256 valeurs.
Personnellement je me dis que le développeur du soft qui pilote le recodage 16 bits doit plutôt être un poète qu'un ingénieur, entre 2 point en créer 255 qui serait proche de la réalité (comme on dit aujourd'hui, même pas en rêve).
Bon étape II, imaginons que c'est OK, on donc 16 bits de fichiers recodés. A quoi sert le 16 bits et quand ? Quand on étire notre histogramme, c'est à dire que l'on oblige le soft à créer à nouveau des points intermédiaires, ok ça marche. Mais ensuite quand on redescent en 8 bits, le soft reprend les points qui lui tombent sous la main, une vaste cuisine, et je ne suis pas sûr qu'elle serve l'image.
Le 16 bits natifs c'est de l'analogique sorti de capteur codé 16 bits dans le meilleur des cas, sinon c'est souvent du 14 bits voir 12 bits, mais natifs dont des vrais points.
Entre 8 et 16 bits "vrai", la différence se sent uniquement quand on besoin de créer des points intermédiaire (expansion d'histogramme), mais quand on change les valeurs du point, le 16 bits ne sert à rien.
On peut aussi dire qu'il y a 8 bits et 8 bits, certains bits sont plus plein que d'autres, certains 8 bits font penser à du 7 bits ou 6 bits.
En PdV on fait du "Brut de scan" et là il faut du 16 bits, l'histogramme se cale à postériori. Mais avec un scanner, l'histogramme se cale par anticipation, si l'on travaille ses images bien sûr, et là le 16 bits n'est pas indispensable, le gros du boulot étant fait avant le codage.

En N&B je serais plus catégorique, le 16 Bits apporte beaucoup dans la qualité du tirage, si le RIP supporte le 16 bits, mais je parle de 16 bits natif. Partir d'une valeur pour en trouver 256 me parait hautement improbable.

Quand on a un doute en numérique sur une dégradation ou un gain, il suffit non pas de faire une fois l'opération et de comparer les méthodes, mais de faire 20 fois de suite (8bits vers 16 bits, puis traitement, puis 8 bits, puis 16 bits, puis traitement, etc etc) et de comparer les méthodes, on voit vite ou sont les pertes.

-------
No Pasaran
-------

Je fais remonter la discussion parce que je me rends compte que les mathématiciens se sont largement exprimés avec de beaux calculs théoriques, mais on n'a pas encore entendu les physiciens.

Donc un physicien ouvre par curiosité la doc technique du capteur Kodak KAF-39000, 39 Mpix, chaque pixel a une surface de 6,8 microns au carré.

Voir le pdf du KAF-39000, ici, il est très instructif à tous égards.

Plus d'infos sur cette gamme de produits
http://www.kodak.com/global/en/business/ISS/Products/Fullframe/

Selon la doc le pixel sature lorsqu'il a reçu 60000 électrons environ (tableau page 12 de la doc pdf)

Parfois ces pixels sont recouverts d'un filtre bleu, ou rouge ou vert, mais le résultat quel que soit le filtrage est que la fluctuation naturelle sur un décompte de 60000 électrons c'est racine carrée de 60000, environ 250, ce qui donne un nombre de niveaux de gris discernables (en échelle linéaire en nombre d'électrons, il faudrait nuancer avec la conversion non linéaire entre le nombre d'électrons et les niveaux de gris vus par l'oeil) qui est autour de 250, proche de 256 = 8 bits.

Donc les 16 bits dont nous parlons, soit 65000 niveaux de gris "de rêve", sont effectivement un truc de pur mathématicien loin de la réalité physique, car pour qu'ils existent effectivement au départ dans le nombre de niveaux de gris discernables au niveau de l'effet photo-électrique du capteur, il faudrait une saturation non pas à 60000 électrons par pixel, mais à 65000 au carré soit ... 4,3 milliards d'électrons ... on pourra encore attendre un peu avant d'avoir cela sous la main.

On peut dire les choses différemment : 16 bits c'est 65536, distinguer 65536 niveaux de gris dans un décompte qui est au maximum de 60000 électrons, c'est être capable de discerner une fraction d'électron. Avec un bon microtome bien affûté, et un geste sûr, peut-être peut-on découper une tranche d'électron !! Ça ne semble pas faire peur aux mathématiciens, tant mieux pour eux !!

On peut néanmoins, en attendant les progrès irrésistibles de la technologie, accumuler 65000 images l'une sur l'autre (éloge de la lenteur, on aime bien ça dans le monde de l'image haute résolution) : on fait déjà cela sur galerie-photo avec les images empilées en profondeur (pour la profondeur de champ infinie), ou les images gonflées en résolution en largeur ... (voir article récent sur gépé-point-com)

Mais l'important n'est-il pas de travailler en 16 bits, même si ce ne sont que des bits de mathématiciens sans aucune réalité physique ...

E.B.



Modifié 1 fois. Dernière modification le 24/05/2011, 16:37 par Emmanuel Bigler.

imho tu mets la charrue avant les boeufs.

Kodak spécifie un capteur de 8 bits de profondeur
donc recherche la techno adéquate et
fournit un chip capable de capter 60000 e- / pixel.

S'ils avaient spécifiés 16b ils auraient fini avec une techno différente.

Dans ce fil, si j'ai bien compris (je commence à en douter), on parle de calcul.
Coe physicien tu sais qu'un calcul en réel est plus précis
qu'un calcul en entier sur un intervalle borné.

Question à MM Bigler,Kodak, De Genes, et consorts :
Comment qu'on fait pour compter pil poil 60 000 électrons ?
Et qu'en dit Mr Heisenberg ? (On ne demandera pas à Mr Einstein, car, facétieux comme il est il se moquerait de nous sans qu'on s'en aperçoive )

S'ils avaient spécifiés 16b ils auraient fini avec une techno différente.

Ron, trouvez-moi une doc avec un capteur récent qui sature à nettement plus que 60000 électrons par pixel, et on en reparle. Que ce capteur soit sur un dos silicium pour capture d'image directe ou dans un scanner, d'ailleurs, le problème est à peu près le même : qui a besoin de 16 bits = 65536 niveaux, alors qu'ils n'existent pas physiquement à l'entrée ?
Allez, c'est mon jour de bonté : 12 bits me suffiraient largement. Je précise bien : une image monochrôme, pas d'embrouille avec des tri-couleurs et autres où il y a des facteurs 3 qui se baladent dans le décompte total des octets nécessaires à l'image, plus des petites tricheries « pas vu, pas pris (pas vu, pas le même prix !!) » sur le rouge et le bleu où l'oeil n'est pas très bon à discerner les niveaux ...

Du brut de chez noir et blanc pour simplifier.

Le petit calcul est le suivant : 12 bits donnent 4096 niveaux, avec l'argument des fluctuations en racine de N, il me faut au moins (4096 x 4096) = 16,78 millions d'électrons par pixel pour pouvoir effectivement distinguer 4096 niveaux de gris bien distincts, à coder sur douze bits bien réels et bien solides physiquement. Qui me trouve la doc avec ces spécifications là ? Je suis preneur.

Comment qu'on fait pour compter pile poil 60 000 électrons ?

On les compte à la louche, à 250 près.
C'est pas comme les sous pour une déclaration au percepteur !!! (à 1 euro près ??)

E.B.

Je suis désolé de m'être laissé entrainer dans une discussion où je n'y connais rien

cependant je pensais que le 16bits existe bel et bien

les Phase One P quelque chose sont présentés comme 16b par couleur

les caméras avec capteur CCD en sortie 12/14b se trouvent sur les forums astro
(CCD Sony Exview ICX618ALA)

les capteurs CMOS embarqués sont généralement 12 ou 14 ou 16bits

Ron Talis écrivait:
-------------------------------------------------------
> Je suis désolé de m'être laissé entrainer dans une
> discussion où je n'y connais rien
>
> cependant je pensais que le 16bits existe bel et
> bien
>
> les Phase One P quelque chose sont présentés comme
> 16b par couleur
>
> les caméras avec capteur CCD en sortie 12/14b se
> trouvent sur les forums astro
> (CCD Sony Exview ICX618ALA)
>
> les capteurs CMOS embarqués sont généralement 12
> ou 14 ou 16bits

Mais c'est juste une indication de codage.

-------
No Pasaran
-------

Un peu de lecture sur wiki, mot-clé : stéganographie, m'a incité à proposer ici un jeu amusant qui devrait plaire aux mozarts de l'image traitée 16-bit-sinon-rien.

On part d'une image ordinaire, 8 bits bien entendu, et on cache une autre image dedans par un procédé simple (mais qui sera révélé un peu plus tard).

Dans une archive zip, deux fichiers tiff, images en noir et blanc, une image tiff 8 bit de départ, et la même un peu bricolée avec une autre image (en fait, un message sous forme de texte) cachée dedans

Voyez vous une différence entre les deux images extraites du fichier zip, et si oui, quelle est l'image cachée et le message secret ?

image de départ : chalet-NB.tif
image avec une autre image cachée dedans : chalet-NB+message.tif

Une petite énigme en marge de l'énigme de traitement d'images consiste à identifier le chalet.

E.B.

Je suis désolé de m'être laissé entrainer dans une discussion où je n'y connais rien

Mais non, Ron, au contraire, je trouve la discussion passionnante ; et j'avoue, une fois n'est pas coutume, que je titille volontairement nos amis qui traitent des images 16 bit toute la journée : c'est moi qui n'y connais rien, puisque je n'utilise que des images 8-bit (par couleur) que ma version du GIMP me permet de manipuler ; c'est eux qui vont nous expliquer ;-)

E.B.

L'image avec message est très dégradée, il y a deux histogrammes superposés, mais je ne vois pas comment extraire l'information.
Cela sent les techniques SF des années 70.

-------
No Pasaran
-------

Pour mettre sur la voie, deux images tiff, la même originale que précédemment et une autre à peine bricolée, mais sans message dedans : que disent les histogrammes ?

Cela sent les techniques SF des années 70.
je dirais même plus : 77 comme dans la commande suivante :
f77 decodemessagepgm.f ncar.o -o decodemessagepgm

E.B.