Rumeur de Nikon Z 61 Mpixels / 16 bits

[Verso92]

Si t'avais tout de suite parlé de la mise à la masse des 2 bits de poids faible, on n'aurait pas tourné en rond.

Cela n'a aucun rapport : ce n'est qu'une option de configuration (on aurait pu tout aussi bien les mettre à "11", cela n'aurait rien changé au propos).

Mais, ça n'enlève rien à ce que je j'ai expliqué qui reste vrai. Ici, on n'ajoute pas 2 bits, ils y sont déjà, mais on les positionne toujours à la même valeur.

Rien à voir avec le passage de 14 bits à 16 bits.

Cela ne change rien : quand on ajoute des bits, ce sont toujours des LSB* (je ne comprends pas ton entêtement...).



*à savoir de la précision. Comme on est forcément en pleine échelle (sinon, bonjours les dégâts !), les MSB sont calés à gauche.

Reste à prouver que c'est bien la pratique chez Nikon et qu'ils seront bien sur un bus de 16 bits.

En fait, aucune importance : comme déjà expliqué, les calculs se font en 16 bits dans l'EXPEED depuis de nombreuses années. Que les deux bits de poids faibles soient reliés ou pas aux processeurs éventuels en aval ne doit pas avoir une grande importance, AMHA...

[Ergodea]

Ben... en ce qui me concerne, quand on me dit de consulter Google pour des trucs que je maitrise professionnellement (on n'est pas dans le domaine de la photo, où je suis un modeste amateur qui n'y connait pas grand chose, au bout du compte), ça me fait un peu drôle, quand même !

;-)

Cela ne fait pas de doute ; )
Et il est clair que ce n'est pas très agréable. Mais je ne pense pas qu'il s'agit de remettre en question tes compétences vu que j'imagine qu'il ne les connaissait pas, et  parfois on part dans une logique qu'on croit juste alors que ce n'est pas le cas, mais on pense être dans le vrai. Après, il est clair que j'admire ta patience  )

Bref, tout cela me fascine bien que je crois n'avoir pas compris grand chose ; ) et quand c'est comme ça, j'attends la conclusion, c'est plus simple ; )

[Recto38]

Le problème, c'est que tu as la tête dans tes circuits et que t'es incapable d'en sortir.

Ca c'est un peu fort de café pour Verso, je pense surtout que TOI tu as un peu trop la tête dans tes bits !

Procéder ainsi t'évite d'avoir ensuite à faire des décalages de bits vers la gauche pour aligner la pleine échelle de convertisseurs de résolution différente. Tout les électroniciens du monde entier procèdent ainsi, parce que c'est juste du bon sens !
Verso fait comme ça sur ces cartes, nous faisons comme ça sur nos cartes et Nikon fait bien entendu de même sur ces cartes.

[Verso92]

Peu importe, le fait est qu'on neutralise les 2 bits de poids faible dans un mot de 16 bits (si c'est bien ça que fait Nikon, dans ton métier, je veux bien y croire). On ne les fait pas disparaître et on ne passe pas sur 14 bits.

Le problème, c'est que tu as la tête dans tes circuits et que t'es incapable d'en sortir. je t'ai démontré plusieurs fois que quand tu augmentes le nombre de valeurs, tu ajoutes des bits de poids fort. Si tu veux passer de 255 à 256, tu es obligé de rajouter un bit de poids fort, pas faible.

Écoute, moi je n'ai rien à prouver, ici (surtout professionnellement)... alors, je vais lâcher le morceau.


Chacun a, désormais, les billes en main pour se faire sa propre opinion.

[Recto38]

Wharf, j'ai déjà vécu exactement ce même sketch du calage des ADC du coté LSB ou MSB il y a une vingtaine d'années avec mes collègues informaticiens en passant de chaines d'acquisitions vidéo 16 bits "lente" à des chaines en 14 bits rapide (pas encore d'ADC 16 bits à architecture SAR rapide à l'époque).
En ne récupérant plus qu'un quart de la dynamique, ils ont fini par comprendre le problème ! 

[big jim]

En gros, une banane ça a deux extrémités et une longueur donnée. Et même si on utilise plus de bits, elle ne s'allonge pas. (On peut replacer banane par un autre mot encore plus explicite    )
J'ai bon ? 

[Verso92]

Wharf, j'ai déjà vécu exactement ce même sketch du calage des ADC du coté LSB ou MSB il y a une vingtaine d'années avec mes collègues informaticiens en passant de chaines d'acquisitions vidéo 16 bits "lente" à des chaines en 14 bits rapide (pas encore d'ADC 16 bits à architecture SAR rapide à l'époque).
En ne récupérant plus qu'un quart de la dynamique, ils ont fini par comprendre le problème ! 

Je n'ai jamais vécu pareille expérience : c'était moi le hardeux et les softeux arrivaient après et n'avaient, fort heureusement, pas leur mot à dire...  ;-)

En gros, une banane ça a deux extrémités et une longueur donnée. Et même si on utilise plus de bits, elle ne s'allonge pas. (On peut replacer banane par un autre mot encore plus explicite    )
J'ai bon ? 

https://www.youtube.com/watch?v=mYosWxn9h4k


Vous avez compris ?

(putain, j'adore Devos...  ;-)

[Recto38]

On commence à envisager de la conversion A/D sur 18 bits et je sens qu'on va encore bien rigoler ! 

[big jim]

Ouaip, on n'est pas au bout de nos peines... 

[Dub]

En gros, une banane ça a deux extrémités et une longueur donnée. Et même si on utilise plus de bits, elle ne s'allonge pas. (On peut replacer banane par un autre mot encore plus explicite    )
J'ai bon ? 

... Mais elle a meilleur gout... 

[restoc]

je t'ai démontré plusieurs fois que quand tu augmentes le nombre de valeurs, tu ajoutes des bits de poids fort. Si tu veux passer de 255 à 256, tu es obligé de rajouter un bit de poids fort, pas faible.

Partons  en 8 bits donc 256 valeurs. Si je veux 257 valeurs je dois passer à 9 bits , c'est OK.  Mais si je ne fais varier que le bit 9 supplémentaire, celui ne va faire varier la totalité du compte que de 256 s'il est à 0 (et ts les bits autres à 1)  , à 257 au maximum s'il est à 1 . Son poids est donc de 1/257 eme au maximum . C'est bien le LSB Less Significant Bit.

A l'inverse pour le MSB , si tous les bits d'un mot de 8 bits sont à 1 , on a 265 valeurs et si le MSB pase à 0 on a 128 valeurs.

qui sur 8 bits selon sa valeur va faire tomber  le maximum du compte possible ( tous les bits à 1) de 256 au max à 128 s'il est à 0
Son poids est donc de 50 % de la totalité du compte . C'est bien le poids le plus fort.

En rajoutant des bits on ne rajoute qu'une "quantité"  de plus en plus marginale. On n'y peut rien mathématiquement.Par contre cette quantité marginale du point de vue mathématique peut parfaitement contenir une information trés utile... si elle sort du bruit. Et là c'est pas gagné.

[doppelganger]

A l'inverse pour le MSB , si tous les bits d'un mot de 8 bits sont à 1 , on a 265 valeurs et si le MSB pase à 0 on a 128 valeurs.
gagné.

255 ?

[Jinx]

255 ?

256 (de 0 à 255)

[MFloyd]

Verso92 a juste et Christophe est PL. Et je ne suis pas informaticien, ni électronicien, ni pilote. 

[Verso92]

Verso92 a juste [...]

Heu... mon prénom, c'est Fabrice !

[namzip]

La phrase est si tous les bits sont à 1...
Il n'y a qu'une seule valeur et c'est 255.
Enfin si l'on veut connaître ce que les 8 bits peuvent indiquer, c'est bien toutes les valeurs comprises entre 0 et 255, soit 256 valeurs.
Enfin c'est la réponse d'un non diplômé.

[MFloyd]

Heu... mon prénom, c'est Fabrice !

Bien noté 

mais tu es photographe et tu postes des photos , tu es confirmé dans ta compétence 🤗

Merci.

Ceci étant dit, j'ai quand même quelques MS à mon actif 

[doppelganger]

256 (de 0 à 255)

256 valeurs oui, mais j'étais sur la valeur de 1111 1111 = 255

[Verso92]

Tu confonds nombre de valeurs et valeur des bits.

Reprenons, tu as tous tes bits à 1 sur un octet, ça te donne 255. Tu veux passer à 256, tu ajoutes un neuvième bit de poids fort, c'est le MSB. Tous les autres bits sont à zéro et ton neuvième bit vaut 256.

Maintenant, si tu passes tous tes bits à 1. Ton neuvième bit a un poids de 256/511. C'est le bit le plus significatif.

c'était le sens de mon propos.

Je te parle de calcul binaire, pas de bidouilles sur des cartes électroniques.

Ne perds pas de vue que la discussion tourne autour du passage de 14 à 16 bits...

Et, que tu le veuilles ou non, les 14 bits actuels, quand ils sont cadrés dans 16 bits, sont calés sur le MSB, à gauche (pour garder la pleine échelle).

L'ajout de deux bits se fera donc forcément à droite (LSB)...

[doppelganger]

Tu confonds nombre de valeurs et valeur des bits.

Reprenons, tu as tous tes bits à 1 sur un octet, ça te donne 255. Tu veux passer à 256, tu ajoutes un neuvième bit de poids fort, c'est le MSB. Tous les autres bits sont à zéro et ton neuvième bit vaut 256.

C'est pourtant pas compliqué :

0000 1111 1111 = 255
0001 0000 0000 = 256
0001 1111 1111 = 511

[MFloyd]

Est-ce que je résume correctement que passer de 14 à 16 bits ajoute du pouvoir discriminant, cependant, ne changeant rien à la plage dynamique, qui est dépendant du capteur ?

Accessoirement, pour le développement de nouveau capteurs, l'extension de la plage dynamique est plutôt à chercher dans le haut, vu qu'en bas on atteint déjà des niveaux quantiques.

[doppelganger]

Donc, en 14bits seuls 14 sur les 16 sont significatifs

1111 1111 1111 1100 ou 0011 1111 1111 1111

Au final, qu'ils se trouvent à gauche ou à droite n'a pas d'importance sur le nombre de combinaisons possibles 14 bits = 2^14 = 16384.

Par contre j'insiste sur le fait que sur mon compte en banque, je préfère quand les zéro se trouvent à droite 

[doppelganger]

C'est exactement ce que je dis. Quel est le sens de ton message ?

C'était pour appuyer tes propos

[Verso92]

Oui, j'ai compris ce point. Mais restoc reprenait mon propos qui se plaçait dans un contexte général sans préciser ce point.

Ce type de câblage est une "astuce" qui reste un bidoullage  qui n'a rien à voir avec la logique binaire. On n'est pas dans l'ajout de 2 bits puisqu'il sont déjà présents dans les 16 bits, mais bien dans le fait de les rendre les 2 bits de poids faible "signifiants".

On ne peut pas parler de passage de 14 à 16 bits puisque dans les faits, on est déjà à 16 bits.

Illustration avec du blanc :

Quand le calage est fait à gauche, l'OS lira "1111 1111 1111 1100", soit 65 532, soit du blanc à un pouillème près (ce qui est le but, puisque 16 383 c'est du blanc en 14 bits).

Si le calage était fait à droite, l'OS lirait "0011 1111 1111 1111", soit 16 383, donc du gris en calage 16 bits...

[Jinx]

256 valeurs oui, mais j'étais sur la valeur de 1111 1111 = 255

Ah pardon, j'avais pas lu le début de la phrase et j'étais resté sur le nombre de "valeurs".
En effet 11111111 c'est bien 255 (ou 0xFF)