d800 12 14 bits lightroom

[Unan kozh]

à Gild :  Je sais bien que c'est pas méchant ma réponse est :c'est comme avec les enfants à un moment faut savoir dire  STOP !

Haaaa Jean Bart et tous ses enfants.... toute un époque de carnaval .... Wiche Wiche ...Dunkerque longue vie à toi .
Jean Bart ! Jean Bart ! La voix de la Patrie redit ta Gloire et ton nom immortel

Et la citée qui te donna la vie,

Erigera ta statue en autel ! Erigera ta statue en autel !

Jean Bart salut, Salut à ta mémoire, de tes exploits tu remplis l'univers !

Ton seul aspect commandait la victoire

Et sans rival tu régnas sur les mers  ......................

[restoc]

Il y a plus de nuances entre le 12 bits et le 14 bits (c'est un fait), maintenant si l'écran n'est pas à même de les afficher ...

des preuves  !!!  
Non ce n'est pas un fait , mais une possibilité théorique ou marketing selon.
Depuis que le D300 est sorti personne dans le monde n'a mis en évidence de façon intontestable une telle affirmation. Pas davantage sur le D800 pour le moment malgré les progrés.

Ceci dit c'est compris dans le prix du boîtier et il n' ya pas de contre indication médicale au 14 bits si on a le temps et de la mémoire !

Ce qu'espère Gild D est trés vrai : il existe déjà depuis longtemps  des techniques de récupération d'information faibles utiles,  dans un bruit épouvantable, trés sohistiquées qui peut être seront mises au service de la photo dans les 5 à 10 ans .  ( Pb de puissance de calcul ) Demandez aux spécialistes du sonar des sous marins, ils ont tout ce qu'il faut en techniques ... sauf que çà va mettre le prix de Photoshop et la puissance du calculateur à des tarifs ...abysssaux. Pour le moment.

 

[Will95]

des preuves  !!!  
Non ce n'est pas un fait , mais une possibilité théorique ou marketing selon.
Depuis que le D300 est sorti personne dans le monde n'a mis en évidence de façon intontestable une telle affirmation. Pas davantage sur le D800 pour le moment malgré les progrés.

Ceci dit c'est compris dans le prix du boîtier et il n' ya pas de contre indication médicale au 14 bits si on a le temps et de la mémoire !

Ce qu'espère Gild D est trés vrai : il existe déjà depuis longtemps  des techniques de récupération d'information faibles utiles,  dans un bruit épouvantable, trés sohistiquées qui peut être seront mises au service de la photo dans les 5 à 10 ans .  ( Pb de puissance de calcul ) Demandez aux spécialistes du sonar des sous marins, ils ont tout ce qu'il faut en techniques ... sauf que çà va mettre le prix de Photoshop et la puissance du calculateur à des tarifs ...abysssaux. Pour le moment.

 

La terre tourne, tu demandes des preuves aussi ?

Il y a plus de nuances de couleurs avec un codage 14 bits que 12 bits (2^14 contre 2^12).
Après, as tu les moyens de faire la différence ? Visiblement non ...
Ceci dit, peu de monde finalement fait la différence, car soit le tirage n'est pas assez fin pour reproduire le dégradé, soir l'écran ne sait pas l'afficher. On peut donc se dire "à quoi bon", mais en aucun cas remettre en cause ce qu'on n'est pas à même de voir.

[Verso92]

Il y a plus de nuances entre le 12 bits et le 14 bits (c'est un fait), maintenant si l'écran n'est pas à même de les afficher ...

Il n'y a pas de rapport direct entre la profondeur de quantification d'un fichier RAW et celle qui caractérise l'affichage d'un écran, voyons, Will...
(mais bon, je sais que tu le sais... enfin, je pense !)

[Will95]

Il n'y a pas de rapport direct entre la profondeur de quantification d'un fichier RAW et celle qui caractérise l'affichage d'un écran, voyons, Will...
(mais bon, je sais que tu le sais... enfin, je pense !)

Il y a un rapport indirect : ta chaine graphique doit être homogène et à même de restituer l'ensemble des informations de ton fichier.
Il y a plus d'informations dans un Raw 14bits que dans un 12bits, de même dans un 16bits d'un MF. Cette différence permet d'aller plus loin dans le traitement de l'image, en la dégradant moins. Après reste à savoir qui a vraiment besoin de ça ? Si c'est pour faire de jpeg de base sans trop de retouche, et afficher ses photos sur un écran TN 6 bits .... on s'en fout ... Mais tout le monde n'est pas dans ce cas.

[Bernard2]

Il y a un rapport indirect : ta chaine graphique doit être homogène et à même de restituer l'ensemble des informations de ton fichier.
Il y a plus d'informations dans un Raw 14bits que dans un 12bits, de même dans un 16bits d'un MF. Cette différence permet d'aller plus loin dans le traitement de l'image, en la dégradant moins. Après reste à savoir qui a vraiment besoin de ça ? Si c'est pour faire de jpeg de base sans trop de retouche, et afficher ses photos sur un écran TN 6 bits .... on s'en fout ... Mais tout le monde n'est pas dans ce cas.

On tourne en rond..
pas besoin de limiter au jpg et à un écran bas de gamme pour valider l'argument.
même en RAW sur un écran correct calibré et en retouche fine, il n'y a rien à voir. Et comme cela a encore moins de chances de se voir en tirage... où cela se voit il? On ne parle pas de théorie mais de pratique et de réalité.

[Recto38]

Recto va nous sortir les chiffres comparatifs de dynamique en 12 et 14 bits respectivement, et on pourra se faire une idée plus précise...

J'aimerai bien, j'aimerai bien  , mais je pense qu'il faut plutôt demander à Mr DxOMark de nous faire une petite caractérisation comparative en 12 et 14 bits.
Maintenant, comme tu l'écris également, j'applique aussi le principe de précaution (et je fais de même avec les OGM  ) malgré les avis de certains "experts" !

[Verso92]

J'aimerai bien, j'aimerai bien  , mais je pense qu'il faut plutôt demander à Mr DxOMark de nous faire une petite caractérisation comparative en 12 et 14 bits.

Je pense qu'ils ne le proposeront pas.
Je suis même intimement convaincu que les deux bits supplémentaires n'apportent quasiment rien de plus en dynamique...

[PinkFish]

Non, bien sûr.

A priori le but de l'opération est de garder des valeurs sur l'ensemble de l'intervalle 0_65535 (ou 32767 dans PS), donc si je dirais bien lsb... le fait est qu'il s'agit d'une très simple multiplication par 4 et pas d'une interpolation.
[...]

Petit exercice de calcul binaire. 65535 s'écrit 1111111111111111 (16 fois le chiffre 1). Il faut donc 16 bits minimum pour encoder cette valeur.
Le MSB d'une représentation binaire est le bit de poids fort (Most Significant Bit). Il a un rôle particulier car dans la notation en complément à 1 ou 2, il sert de bit de signe. En tout cas, c'est toujours le bit de plus grande valeur (celui de gauche dans notre écriture traditionnelle) : dans l'exemple donné, le MSB correspond au 1 mis en gras.
A l'opposé, le LSB est le bit de poids faible, soit le plus à droite (toujours dans notre écriture traditionnelle). Dans l'exemple donné, c'est le 1 souligné.

Maintenant, si je veux écrire la même valeur 65535 en utilisant une représentation binaire sur 17 bits, quelle sera la valeur du nouveau MSB ? 0 ou 1 ? Ceux qui ont répondu 1 devront changer de calculatrice. Car sur 17 bits, cela donne 01111111111111111. Le MSB est maintenant le 0.
Et sur 18 bits, on ajoute 2 bits à 0 à gauche de l'écriture initiale. Cela provient de la magie de la multiplication par 0 (2^n * 0) !
Pour ceux qui sont plus habitués à la base décimale, je rappelle que 100 peut aussi s'écrire 00100 (mais pas 10000).

Pour en revenir aux propos erronés de Nikojorj et de Verso, si on avait mis à 0 le LSB en passant de l'écriture 16 bits à 17 bits, nous aurions eu au choix (car ils ne disent rien pour les nouveaux bits introduits)
01111111111111110 soit 65534 en base 10
ou
11111111111111110 soit 131068 en base 10

Non messieurs, je crains que vous ne fîtes fausse route. Étendre une représentation binaire de k à k+p bits revient simplement à insérer à gauche de la représentation initiale p bits à 0. Ces p bits ajoutés forment les nouveaux MSB de la représentation sur k+p bits. En aucun cas, les LSB (qui restent les mêmes bits) ne sont modifiés.

PinkFish

[Verso92]

Petit exercice de calcul binaire. 65535 s'écrit 1111111111111111 (16 fois le chiffre 1). Il faut donc 16 bits minimum pour encoder cette valeur.
Le MSB d'une représentation binaire est le bit de poids fort (Most Significant Bit). Il a un rôle particulier car dans la notation en complément à 1 ou 2, il sert de bit de signe. En tout cas, c'est toujours le bit de plus grande valeur (celui de gauche dans notre écriture traditionnelle) : dans l'exemple donné, le MSB correspond au 1 mis en gras.
A l'opposé, le LSB est le bit de poids faible, soit le plus à droite (toujours dans notre écriture traditionnelle). Dans l'exemple donné, c'est le 1 souligné.

Maintenant, si je veux écrire la même valeur 65535 en utilisant une représentation binaire sur 17 bits, quelle sera la valeur du nouveau MSB ? 0 ou 1 ? Ceux qui ont répondu 1 devront changer de calculatrice. Car sur 17 bits, cela donne 01111111111111111. Le MSB est maintenant le 0.
Et sur 18 bits, on ajoute 2 bits à 0 à gauche de l'écriture initiale. Cela provient de la magie de la multiplication par 0 (2^n * 0) !
Pour ceux qui sont plus habitués à la base décimale, je rappelle que 100 peut aussi s'écrire 00100 (mais pas 10000).

Pour en revenir aux propos erronés de Nikojorj et de Verso, si on avait mis à 0 le LSB en passant de l'écriture 16 bits à 17 bits, nous aurions eu au choix (car ils ne disent rien pour les nouveaux bits introduits)
01111111111111110 soit 65534 en base 10
ou
11111111111111110 soit 131068 en base 10

Non messieurs, je crains que vous ne fîtes fausse route. Étendre une représentation binaire de k à k+p bits revient simplement à insérer à gauche de la représentation initiale p bits à 0. Ces p bits ajoutés forment les nouveaux MSB de la représentation sur k+p bits. En aucun cas, les LSB (qui restent les mêmes bits) ne sont modifiés.

PinkFish

Heu... tu pourrais m'expliquer le rapport avec la question initiale ?
Qui t'a parlé d'une d'extension binaire de k à k+p bits ?

[Verso92]

Comment une composante est-elle convertie d'un codage sur 14bits à un codage sur 16bits ?

Il y a une manip assez simple, je pense, pour en être quasiment sûr à 100% : il suffit d'ouvrir sous Capture Nx2* (par exemple) un fichier NEF codé sur 14 bits, et ensuite de l'enregistrer en TIFF 16 bits.
En ouvrant le fichier TIFF avec un éditeur hexadécimal, on verra si les mots contenus dans les champs "données" (2 x 8 = 16 bits) se terminent par les bits "00" (ils sont multiples de 4 : le mot se termine donc par le digit 0, 4, 8 ou C exclusivement) ou commencent par les bits "00" (le premier digit du mot sera donc 0, 1, 2 ou 3, à l'exclusion de toute autre valeur).

Illustration :
1 - exemple de données avec ajout de deux "00" en LSB :

0A F4 2F B0   FE E8 9D 64   7E A0 FD 9C   FD C4 0E F8
2 - exemple de données avec ajout de deux "00" en MSB :

0A F4 2F B3   3E E7 0D 61   1E AF 2D 9B   3D C4 2E F3
*ou avec LR4, mais je ne connais pas les possibilités d'export/enregistrer sous en TIFF 16 bits...

[Recto38]

Je pense qu'ils ne le proposeront pas.
Je suis même intimement convaincu que les deux bits supplémentaires n'apportent quasiment rien de plus en dynamique...

En tout cas pour mesurer plus de 12 bits ( [at] 100 et 200 iso) sur leur courbe de dynamique, ils devaient bien être en RAW 14 bits, non ?
Hormis des pixels a revendre, une autre des qualités présentée du D800 est sa dynamique améliorée. Je ne vois pas comment on peut l'exploiter sans aller chercher au moins le 13ème bit. Maintenant, que ces 1.2 bits de dynamique de plus ne soit pas très visible à l'écran ou sur un tirage, j'en conviens. Par contre, pour déboucher une zone sombre au développement du RAW ?? (et à quoi bon faire du 16 bits en MF!)

[jepomat]

Quelqu'un sait-il si le traitement du moiré est affecté par le fait que l'image soit à 14 bits plutôt que 12 ? Y a-t-il, pour faciliter le traitement du moiré dans Lr, avantage à générer des images 12 ou 14 bits ?

Pas vu de mention de cela dans le dernier Ci, mais l'auteur avait-il regardé cette question ?

Merci.

[Recto38]

C'est là que cela peut jouer à condition que l'information sur ces deux bits de poids faible ne soit pas noyée dans du bruit.

Certes, mais pour mesurer 13.2 IL de dynamique, il doit bien y avoir de l'info autre que du bruit dans ces 2 bits, sinon ils ne mesureraient que 12 IL de dynamique !

[Verso92]

Quelqu'un sait-il si le traitement du moiré est affecté par le fait que l'image soit à 14 bits plutôt que 12 ?

Les 12 ou 14 bits caractérisent la profondeur de couleur (2^12 ou 2^14 valeurs possibles respectivement pour chaque pixel) : pas de rapport direct, donc, avec l'échantillonnage spatial réalisé par le capteur, qui peut occasionner le moiré dans certaines circonstances (dès que la fréquence spatiale du signal à reproduire dépasse la moitié de la fréquence d'échantillonnage, en théorie).

[PinkFish]

Toujours pas 

Longue démonstration inutile et vaine.

Le but n'est pas d'avoir la même valeur binaire pour des représentation en 14 bit et 16 bit mais de quantifié la même étendue en 14 bit et en 16 bit c'est le pas de quantification qui va changer et donc les valeurs des deux mots ne seront pas les même sauf a considérer que la quantification sur 16 bit codera une composante jusqu'a une valeur de 400% 

Si tu veux que ta composante rouge qui était 100% codée en 14 bit par 3FFF soit toujours a 100% codée sur 16 bit elle devra prendre la valeur FFFF.

Le passage d'une quantification en 14 bit vers une quantification en 16 bit d'une même étendue se fait bien par décalage a gauche, les deux bits de poids faible sont bien à 0.

Le 100% sur 14 bits donnera un 99,9954% en 16 bits du fait de la présence de ses deux bits de poids faible à 0 dont on ne peut estimer la valeur.

Ok je vois de quoi vous voulez parler. Je me suis référé à la phrase initiale de nikojorj "ce n'est pas une extrapolation que de passer de 12 ou 14 à 16 - les 2 LSB sont mis à zéro épicétou." qui sous-entend (à mes oreilles) que la valeur initiale sur 14 bits est simplement "étendue" sur 16 bits en effaçant les 2 bits de poids faible. Sur le plan calcul binaire, c'est inexact.
Par contre, dire que le passage sur 16 bits s'obtient en décalant la valeur initiale sur 14 bits de 2 bits sur la gauche (i.e multiplication par 4) est effectivement plus en conformité avec le principe de "conservation" (entre quotes car partielle) du codage d'une quantification. Le fait que les LSB nouvellement introduits soient à 0 n'est qu'une conséquence du décalage à gauche.

Question complémentaire à laquelle je n'ai pas de réponse de suite : le passage d'une quantification sur 14 bits à une quantification sur 16 bits est-elle réalisée par une simple multiplication par 4 ? Parce que cela revient à faire une mise à l'échelle, n'est-ce pas ? Or dans ce cas, le ratio n'est plus 4 mais un tout petit peu plus (65535/16383) - tout dépend si les calculs sont faits en haute précision ou pas. Ce qui éviterait de passer d'un rouge 100% à un rouge 99.9954% (j'ai la flemme de vérifier votre calcul, je vous fais confiance sur ce coup  ).
Même si au final, je vous l'accorde à tout le moins pour l'exemple du rouge pur, la différence sera difficilement visible (pour le bleu pur, j'ai un doute  )

PinkFish

[Fanzizou]

Je pense qu'ils ne le proposeront pas.
Je suis même intimement convaincu que les deux bits supplémentaires n'apportent quasiment rien de plus en dynamique...

En dynamique c'est sur et certain. La quantification est indépendante de la capacité du capteur dans ce domaine.

Sur le D3, Tonton c'était amusé à remonter des ombres de 5IL pour essayer de trouver une différence. Avec de l'imagination on voyait peut être une petite différence, mais il y avait même débat, c'est dire si c'était ténu.... Et puis l'intérêt de remonter des ombres de 5IL....

[Verso92]

Il y a une manip assez simple, je pense, pour en être quasiment sûr à 100% : il suffit d'ouvrir sous Capture Nx2* (par exemple) un fichier NEF codé sur 14 bits, et ensuite de l'enregistrer en TIFF 16 bits.
En ouvrant le fichier TIFF avec un éditeur hexadécimal, on verra si les mots contenus dans les champs "données" (2 x 8 = 16 bits) se terminent par les bits "00" (ils sont multiples de 4 : le mot se termine donc par le digit 0, 4, 8 ou C exclusivement) ou commencent par les bits "00" (le premier digit du mot sera donc 0, 1, 2 ou 3, à l'exclusion de toute autre valeur).

Illustration :
1 - exemple de données avec ajout de deux "00" en LSB :

0A F4 2F B0   FE E8 9D 64   7E A0 FD 9C   FD C4 0E F8
2 - exemple de données avec ajout de deux "00" en MSB :

0A F4 2F B3   3E E7 0D 61   1E AF 2D 9B   3D C4 2E F3
*ou avec LR4, mais je ne connais pas les possibilités d'export/enregistrer sous en TIFF 16 bits...

Bon, je viens de faire l'essai à l'instant, en transformant un NEF en TIFF 16 bits avec ViewNx2, sans réussir à retomber sur un cas ou sur l'autre.
Une chose est sûre, les deux MSB ne sont pas systématiquement mis à "00" dans le TIFF 16 bits. Les deux LSB non plus, mais peut-être le logiciel Nikon se sert-il des deux bits de poids faible pour faire ses arrondis de calcul lors du développement/dématriçage du NEF quand on demande un fichier de sortie sur 16 bits ?

[Verso92]

En dynamique c'est sur et certain. La quantification est indépendante de la capacité du capteur dans ce domaine.

Elle est indépendante, c'est sûre... mais elle a été choisie en fonction de la dynamique du capteur : les bits supplémentaires sur les CAN coûtent chers, donc autant ne pas les implémenter s'ils ne servent à rien.

[Recto38]

En dynamique c'est sur et certain. La quantification est indépendante de la capacité du capteur dans ce domaine.

Sur le D3, Tonton c'était amusé à remonter des ombres de 5IL pour essayer de trouver une différence. Avec de l'imagination on voyait peut être une petite différence, mais il y avait même débat, c'est dire si c'était ténu.... Et puis l'intérêt de remonter des ombres de 5IL....

Ben là http://www.nx101.com/12vs14.html c'est moins ténu et c'est avec un D300 !
Si un heureux propriétaire de D800 (les E sont aussi acceptés  ) veut nous refaire la manipe et poster les 2 NEF, ça pourrait être intéressant !

[Recto38]

Bon, je viens de faire l'essai à l'instant, en transformant un NEF en TIFF 16 bits avec ViewNx2, sans réussir à retomber sur un cas ou sur l'autre.
Une chose est sûre, les deux MSB ne sont pas systématiquement mis à "00" dans le TIFF 16 bits. Les deux LSB non plus, mais peut-être le logiciel Nikon se sert-il des deux bits de poids faible pour faire ses arrondis de calcul lors du développement/dématriçage du NEF quand on demande un fichier de sortie sur 16 bits ?

C'est très certainement ça car après plusieurs traitements et troncatures ça fini par faire mal !
Le pb est bien connu en audio numérique avec les 1er softs de traitement qui travaillaient sur 16 bits. Un soft audio digne de ce nom fait tout ses calculs intermédiaires sur 24 bits puis arrondi à 16 bits en final.

[astrophoto]

La terre tourne, tu demandes des preuves aussi ?

Il y a plus de nuances de couleurs avec un codage 14 bits que 12 bits (2^14 contre 2^12).
Après, as tu les moyens de faire la différence ? Visiblement non ...
Ceci dit, peu de monde finalement fait la différence, car soit le tirage n'est pas assez fin pour reproduire le dégradé, soir l'écran ne sait pas l'afficher. On peut donc se dire "à quoi bon", mais en aucun cas remettre en cause ce qu'on n'est pas à même de voir.

Ca me donne l'occasion de m'auto-citer (à la manière de vous-savez-qui  ) :
"Olivier fait bien de rappeler qu'il y a le bruit de photons, il ne faudrait pas l'oublier celui-là. Dans les HL et même dans les ML, c'est lui qui limite la dynamique, et pas le nombre de bits (petit calcul vite fait : avec 10000 électrons, le bruit de photons moyen est de 100 électrons, soit une dynamique -au sens Dxo- de 100 c'est à dire...à peine 7 bits : s'il n'y avait que des HL on pourrait se contenter d'une numérisation en 8 bits sans qu'aucun crénelage ne soit visible car il est noyé dans le bruit). Le ou les derniers bits ne servent qu'à gratter dans les ombres, là où le bruit de lecture (et l'éventuel banding...) commence à pointer son nez. Dit autrement : le discours "avec 14 bits vous avez 16384 niveaux alors qu'avec 12 bits vous n'avez que 4096 niveaux" est mathématiquement vrai mais physiquement faux"

Le surplus de 2 bits ne peut se voir que si on tire sur les ombres, et non pas dans les dégradés en général (justement si on parle de preuves...j'aimerais bien voir des preuves que les 2 bits en plus se voient sur des dégradés à tous les niveaux de lumière, et autrement que par effet placebo  ) Et encore, il faut un capteur qui tienne plus de 12 IL de dynamique, donc pas franchement chez Canon, ni chez Nikon dès qu'on monte en iso (le nombre de bits utiles et la dynamique -au sens Dxo- sont intimement liés et on peut dire en bonne approximation qu'avec une dynamique de N IL il n'est pas utile d'avoir plus de N bits).

Le corollaire est que l'affirmation "il y a plus de nuances avec un MF 16 bits" n'est pas forcément juste, elle est même fausse si on regarde les mesures de dynamique de Dxo sur les Hasselblad, qui plafonnent à 12,5 IL. J'avais d'ailleurs l'année dernière fait une manip de suppression de bits dans des fichiers MF, et on n'arrivait pas à distinguer les images en 16, 15, 14 et 13 bits, même en tirant comme des malades sur les ombres (petite remarque en passant par rapport à vos histoires de bits, j'avais viré les bits en faisant des divisions par 2, 4 etc. dans le fichier hexa).

[Verso92]

(petite remarque en passant par rapport à vos histoires de bits, j'avais viré les bits en faisant des divisions par 2, 4 etc. dans le fichier hexa).

Il y a quand même des ingés en électronique/informatique de tout premier plan, sur ce fil...  ;-)

[astrophoto]

vi, et même qu'ils arrivent à insérer des smileys qui ressemblent à quelque chose   

[Verso92]

L'opération ne montre pas grand chose, c'est le résultat du dématriçage pas le codage de l'information dans le RAW.

L'algo doit transformer dés le départ les information contenu dans le RAW dans le format de codage qu'il utilisera pour les calculs

C'est à la fois plus simple et beaucoup plus efficace 

Oui, bien sûr...
(mon hypothèse de départ était trop simpliste)