cmos vs ccd : la dynamique

[Nathanael 6 840]

Bonjour,

 

J'ai eu l'occasion d'échanger plus longuement avec un ami qui possède une asi183 (et qui fait de magnifiques images!) et il m'a prêté deux emplilements de 100mn que j'ai comparé avec des empilements de la qsi690. La question de départ, c'est qu'il lui semblait devoir poser plus longtemps avec son cmos que moi avec une ccd pour avoir une image correcte. D'autres avaient déjà remarqué qu'utiliser un cmos avec un ciel pollué était difficile. Quelques mesures et réflexions plus tard, voilà à quoi j'aboutis:

 

Si on admet que :

1- Si on choisit convenablement son temps de pose unitaire, on peut considérer que l'image n'est pas entachée du bruit de lecture, quelque soit la caméra. Le bruit prépondérant (au moins dans un ciel non exceptionnel) est le bruit du fond du ciel (fdc).

2- Quand on traite une image, on est dans un logiciel en 16 bits, les images en 12bits des cmos sont "étirées" en 16 bits, donc tout est multiplié par 16 (4bits d'écart).

 

Alors le gain en e-/adu, donc la dynamique,  est déterminant sur le bruit final. Prenons le cas de la qsi690 :  gain à 0.36e- pour profiter de toute la dynamique. L'asi 183 1e-/adu à gain 111, en 12 bits. Une fois en 16bits, le gain de cette dernière passe à 1/16 e-/adu soit 0.065. Cela signifie que pour un même ciel, le bruit du fdc, en adu, est 5 fois plus fort (0.36/0.065) pour l'asi que pour la qsi. s'en suit une difficulté de traitement pour avoir une image "propre" qui conduit souvent à allonger les poses. On peut étendre la réflexion à la ST10 par exemple : avec un puit de potentiel de 100000e-, les 16bits (65000 niveaux) conduisent à un gain de 1.5e-/adu. Pour un même ciel, le bruit du fdc (en adu sur l'image finale) sera 4 fois plus faible que pour la qsi, 20x plus faible que pour l'asi!

 

En fait, c'est assez simple : comme tout le monde est en 16 bits à la fin et que les caméras ont des puits de potentiel (full well) très différents, que le gain est en gros le full well divisé par les adu (65000 sur l'image finale),  le bruit du fdc en adu sur l'image finale est inversement proportionnel au full well. d'où l'intérêt d'avoir une grande dynamique.

 

Il faudrait se pencher sur la façon dont le snr évolue avec le gain aussi

 

Nathanaël

Modifié 3 octobre 2019 par T450

[Raphael_OD 1 427]

ah ben mince j'ai  0.27e-/ADU@16bits je vais acheter une ST10 ça va vendre dans les PA alors

Modifié 3 octobre 2019 par Raphael_OD

[christian_d 3 148]

Bonsoir Nathanael,

 

J'avoue, je m'y perds un peu avec tout ces electrons qui gravitent autour de nos capteurs.

Plus sérieusement, penses tu que les trames qui apparaissent sur certaines images compilées à base de Cmos à faible pose unitaire peuvent s'expliquer par cette lacune de dynamique ?

 

Christian.

Modifié 4 octobre 2019 par christian_d

[Nathanael 6 840]

Il y a 4 heures, christian_d a dit :

Plus sérieusement, penses tu que les trames qui apparaissent sur certaines images compilées à base de Cmos à faible pose unitaire peuvent s'expliquer par cette lacune de dynamique ?

Je n'en sais rien mais je n'y crois pas trop. Je pencherais plutôt pour un problème de dithering , absent ou partiel (on ne peut pas décaler à chaque pose). J'avais fait du dithering toutes les 10mn avec une caméra simulée, lorsque j'avais essayé les poses courtes, mais ça ne m'a pas empêché d'avoir des trames. Je ne m'y connais pas assez pour être affirmatif, je te donne juste mon avis parce que tu me le demandes

Nathanaël

[Nathanael 6 840]

J'ai repris les images de ngc7331 (voir ici pour les détails) pour illustrer mon propos. On voit qu'en adu, les différences du bruit du fond de ciel sont très fortes suivant la caméra et le gain utilisés.

Si j'en crois ce que Marc Jousset exposait aux RCE2010 en page 13 (ici), si on veut tomber < 10adu de bruit de fdc sur l'image composite finale, il faudrait poser  de 36mn à près de 24h(!) selon les configurations ci-dessous (le bruit diminuant comme la racine carré du nombre de poses).

Cela souligne bien l'importance du gain, donc du fullwell, dans le traitement des images.

Nathanaël

 

QSI gain 0.36e-/adu 3x3mn T250 paracorr2 échantillonnage 0.5"/p

 

QSI gain 0.16e-/adu 3x3mn T250 paracorr2 échantillonnage 0.5"/p

 

ASI183 gain 111 (1e-/adu en 12bits) 3x3mn T250 asa 0.73x échantillonnage 0.5"/p

 

ASI183 gain270 9x1mn T250 asa 0.73x échantillonnage 0.5"/p

 

[Chris277 581]

Bonjour Nathanael, 

Il semble que tes sigma évoluent quasi linéairement avec le niveau moyen de fond de ciel :

 

[patry 1 970]

Juste une question "mathématique".

Tu ne traite pas une image unique mais un empilement.

Donc ok tu va peut être faire x16 sur tes images mais si tu en accumule 2, tu aura au final un range de 17 bits qu'il faudra bien diviser par 2 ... donc x16/2 => x8 seulement.

Ou alors je rate un truc.

 

Marc

[Laurent51 2 787]

Le facteur 16 n'a aucune importance, c'est juste un placement des 12 bits dans le mot de 16 bits. Pour ma part, je divise par 16 toutes mes images avec la 1600MM, afin de recaller les 12 bits comme ils devraient etre. Dans Prism, il a meme été rajouté une option qui permet de faire cette rotation de 4 bits de l'acquisition de l'image.

 

Donc tout ce qui est ecrit la est completement faut:

"L'asi 183 1e-/adu à gain 111, en 12 bits. Une fois en 16bits, le gain de cette dernière passe à 1/16 e-/adu soit 0.065."

 

Le gain de la 183 est toujour de 1e/adu si elle a été réglé a 1e/adu. Le gain c'est un réglage électronique qui n'a rien a voir avec le fait que l'on écrire les 12 bits callé a droite ou a gauche dans le mot de 16 bits.

 

Laurent Bernasconi

Modifié 5 octobre 2019 par Laurent51

[christian_d 3 148]

Bonjour Nathanael,

 

Citation

J'ai repris les images de ngc7331 (voir ici pour les détails) pour illustrer mon propos. On voit qu'en adu, les différences du bruit du fond de ciel sont très fortes suivant la caméra et le gain utilisés.

 

Effectivement la démonstration est "parlante" en voyant les valeurs de bruit de fond. J'avais fait la même constat sur les quelques images issues d'un ASI 1600, bruit de fond très important.

Alors à ton avis, quel conseil pourrais tu donner pour obtenir une image Cmos "plus propre" ? Je me doute qu'il s'agit d'un réglage du gain.

Je reviens sur mon histoire de trames, le fait d'avoir un fond de ciel beaucoup plus bruité représente quand même un potentiel important en terme de trames, même avec de courtes poses.

 

 

Dernière tite question : tu peux régler la valeur de gain de ta QSI ? Je pensais que les parametres CCD étaient figés par le constructeur. Je me trompe ?

 

Christian

[Nathanael 6 840]

Il y a 14 heures, Chris277 a dit :

Il semble que tes sigma évoluent quasi linéairement avec le niveau moyen de fond de ciel :

Soit. Et donc?

Il y a 5 heures, patry a dit :

Donc ok tu va peut être faire x16 sur tes images mais si tu en accumule 2, tu aura au final un range de 17 bits qu'il faudra bien diviser par 2 ... donc x16/2 => x8 seulement.

Je ne comprends pas ce que tu veux dire. L'addition de 1000 images en 16 bits est en 16 bits aussi.

 

Il y a 3 heures, Laurent51 a dit :

Le facteur 16 n'a aucune importance, c'est juste un placement des 12 bits dans le mot de 16 bits.

Je veux bien des explications plus détaillées, car j'avoue ne pas trop comprendre ce qui se passe à ce niveau. Que se passe-t-il exactement quand je lis une image en 12bits sur un logiciel 16 bits? L'expérience que j'en ai, c'est que l'image est "étirée" sur 16 bits, donc que l'image est multipliée par 16.

D'aiileurs tu le dis toi-même :

Il y a 3 heures, Laurent51 a dit :

Pour ma part, je divise par 16 toutes mes images avec la 1600MM, afin de recaller les 12 bits comme ils devraient etre.

 

Il y a 3 heures, Laurent51 a dit :

Donc tout ce qui est ecrit la est completement faut:

"L'asi 183 1e-/adu à gain 111, en 12 bits. Une fois en 16bits, le gain de cette dernière passe à 1/16 e-/adu soit 0.065."

J'aurais dû écrire : une fois en 16 bits, "tout se passe comme si" le gain de cette dernière passait à 1/16 e-/adu soit 0.065e-/adu

 

Il y a 3 heures, Laurent51 a dit :

Le gain de la 183 est toujour de 1e/adu si elle a été réglé a 1e/adu. Le gain c'est un réglage électronique qui n'a rien a voir avec le fait que l'on écrire les 12 bits callé a droite ou a gauche dans le mot de 16 bits.

Encore une fois, je ne comprends pas ce que veut dire 12 bits calés à droite ou à gauche dans un mot de 16 bits.

Mais ce que je sais, c'est que 1e-/adu en 12 bits, c'est 1e-/adu sur une image de 4096 adu au total, donc 4096e- pour remplir mon pixel et que si j'ai finalement une image de 65536 adu au total (16bits) dans lesquels mes pixels sont pleins aussi, il s'est bien passé quelque chose car il n'a pas pu arriver 61440e- pendant que je traitais mes images, alors que ma caméra était rangée au fond de sa boite

 

Il y a 3 heures, christian_d a dit :

Alors à ton avis, quel conseil pourrais tu donner pour obtenir une image Cmos "plus propre" ?

Et bien je ne sais pas justement, j'essaye de comprendre

 

Il y a 3 heures, christian_d a dit :

Dernière tite question : tu peux régler la valeur de gain de ta QSI ? Je pensais que les parametres CCD étaient figés par le constructeur. Je me trompe ?

La qsi690 permet de choisir 2 gains : fort ou faible. A gain faible, on bénéficie de toute la dynamique (18000e- dans le puit), mais à gain fort non (la saturation à 65536adu correspond à 10000e-). Le snr est un poil meilleur avec le gain fort. Mais là aussi je découvre

 

Nathanaël

 

 

[olivdeso 1 860]

Il y a 3 heures, christian_d a dit :

tu peux régler la valeur de gain de ta QSI ? Je pensais que les parametres CCD étaient figés par le constructeur. Je me trompe ?

 

ça dépend des CCD. c'est effectivement très majoritairement figé en usine, mais,quelques CCD ont un gain réglable.

Sur les QSI il y a 2 niveaux de gain possible. low gain / high gain

Sur les QHY le gain est réglable en continu.

 

Mais sur les CCD, le gain ne joue que de façon marginale sur le bruit de lecture contrairement au CMOS. Donc on peut le figer à une valeur faible de manière à avoir la dynamique maximum. Éventuellement une deuxième valeur de gain plus élevée pour attraper le bruit de lecture le plus faible possible quand ça a du sens en narrow band.

 

Par exemple sur la QHY10 (capteur Sony), le gain minimum donne la dynamique maximum et un.bruit de lecture de 8e-.

Le bruit de lecture le plus faible est obtenu pour un gain de  x2.8. On obtient 7 e-.

c'est à la fois vraiment pas énorme, mais quand même suffisamment significatif pour s'y intéresser, puisque le bruit du fond du ciel est la racine carrée du signal i.e. on peut diminuer le temps de pose unitaire d'un facteur x1.3,  (8/7 au carré) ce qui est intéressant sur des poses très longue qu'un a avec une CCD en bande étroite.

[Laurent51 2 787]

"Mais ce que je sais, c'est que 1e-/adu en 12 bits, c'est 1e-/adu sur une image de 4096 adu au total, donc 4096e- pour remplir mon pixel "

 

Non absolument pas. Une camera quel soit en 8bits, en 16 bits, aller en 1234 bits:-), si le gain est réglé à 1e/ adu, ca sera toujour 1e/adu quelque soit la valeur finale.

Sur la ZWO, les 4 bits de poids faibles sont à 0. Puis les 12 bits suivant sont  les valeurs du pixels. Donc le bits 1 de valeur est sur le bits 5 du mot de 16 bits.

Mais ca pourrait etre diffèrent avec un autre constructeur. Ils ont simplement choisis de faire comme ca. Perso, je trouve ca pas extra, mais ce n'est pas grave en soit. De toute façon, toutes les images y compris flat, noir, offset sont réalisés avec ce décalage donc ca ne change rien. La valeur du 5 ieme bits changera quand 1e supplémentaire aura été recu dans le pixel dans tout les cas, et les 4 premiers bits seront toujours à 0.

A 1e/adu, comme tu l'écrit a ta façon, il te faudra en gros 4096e pour saturer le convertisseur analogique numérique du CMOS car c'est un camera 12bits. Si elle était en 16 bits et toujour réglé a 1e/adu, il faudrait 65535e pour saturer le convertisseur. C'est l'unique différence entre une camera 12bits et 16 bits. Et ca n'a rien a voir avec du CMOS ou du CCD.

 

 

"Je ne comprends pas ce que tu veux dire. L'addition de 1000 images en 16 bits est en 16 bits aussi."

La aussi ce n'est pas vrai. Tout dépend du format d'enregistrement de chaque pixel choisis dans ton logiciel. Si tu utilises en sortie un format 16 bits, alors oui, si tu additionnes 1000 images, alors tu sera sur 16 bits en sortie, et en plus tu satures ton image final!!

Si tu choisi un format de sortie par exemple en 32 bits flottant pour chaque pixel, tu pourras additionner des milliers d'images 16 bits sans probleme. Et ton nombre de sortie ne sera plus en 16 bits pour chaque pixel mais en 32 bits.

 

 

 

Amitiés,

Laurent Bernasconi

 

 

 

Modifié 5 octobre 2019 par Laurent51

[Laurent51 2 787]

Je complète par un conseil:

Diviser par 16 vos images avant toute analyse dans votre logiciel favori, ca vous évitera toute erreur dans l'analyse du résultat.

Et vous ne perdez aucune information, car les 4 bits de poids faible sont toujour à 0 sur vos images brutes.

Modifié 5 octobre 2019 par Laurent51

[Nathanael 6 840]

Il y a 4 heures, T450 a dit :

Mais ce que je sais, c'est que 1e-/adu en 12 bits, c'est 1e-/adu sur une image de 4096 adu au total, donc 4096e- pour remplir mon pixel

 

Il y a 1 heure, Laurent51 a dit :

A 1e/adu, comme tu l'écrit a ta façon, il te faudra en gros 4096e pour saturer le convertisseur analogique numérique du CMOS car c'est un camera 12bits.

 

Bon, est d'accord donc

 

il y a une heure, Laurent51 a dit :

Diviser par 16 vos images avant toute analyse dans votre logiciel favori, ca vous évitera toute erreur dans l'analyse du résultat.

Et vous ne perdez aucune information, car les 4 bits de poids faible sont toujour à 0 sur vos images brutes.

 

Je vais essayer, c'est sans doute l'élément qui me manquait pour comprendre les tenants et aboutissants du 12bits vs 16bits, merci!

Autre question : faut-il diviser toutes les images dof, brutes etc et pré-traiter ensuite ou peut-on diviser par 16 sur l'image pré-traitée et empilée?

Nathanaël

[Lucien 11 292]

il y a 3 minutes, T450 a dit :

Autre question : faut-il diviser toutes les images dof, brutes etc et pré-traiter ensuite ou peut-on diviser par 16 sur l'image pré-traitée et empilée?

 

Oui,

si c'est pour faire des calculs, c'est important de savoir comment c'est codé, 12 ou 16 bits par exemple.

 

Cependant pour les traitements, il n'y a pas besoin de faire des conversion préalables.

La plupart des logiciels spécialisés travaillent en interne en 32 bits voire en 64 bits.

 

Lucien

[Lucien 11 292]

Donc le niveau par exemple de 3047 ADU deviendra 3047,000... pour les calculs.

 

Lucien

[Laurent51 2 787]

"Autre question : faut-il diviser toutes les images dof, brutes etc et prétraiter ensuite ou peut-on diviser par 16 sur l'image prétraitée et empilée?"

 

En faite Nathanaël, l'important pour avoir un bon prétraitement, c'est  que toutes les images doivent etre sous le meme format.

- Donc soit tu restes dans le format natif de ZWO avec les 4 bits de poids faible à 0, et tu réalise toutes tes images comme ca.

- Soit tu divises toutes tes images par 16,  mais toutes, et tu réalises tes prétraitements avec se format.

 

L'avantage de la deuxième méthode, c'est que les calculs statistique et d'analyses ne sont pas trompé, biaisé. C'est plus propre, plus logique, et franchement tout le monde comprendrai bien mieux ce qu'il a en main.

C'est la raison pour laquelle sous Prism, Cyril a intégré une option qui permet de retirer les 4 bits de poids faible à zéro des l'acquisition des images. On retrouve un format classique, avec une saturation du convertisseur à 4096 car en 12 bits.

 

On va arriver à se comprendre:-)

Amitiés,

Laurent Bernasconi

 

[Lucien 11 292]

il y a 22 minutes, Laurent51 a dit :

L'avantage de la deuxième méthode, c'est que les calculs statistique et d'analyses ne sont pas trompé, biaisé. C'est plus propre, plus logique, et franchement tout le monde comprendrai bien mieux ce qu'il a en main.

 

Mouais.

C'était quand même plus simple de sortir en 16 bits et de fournir des paramètres caméra correspondants.

Là ça va être problématique le mixage de fichiers.

Quand on ouvre un fichier 12 bits il parait bien sombre.

On se demande si l'on n'a pas sous-exposé !

 

De plus en binning 2X on sort avec des niveaux 0 à 16XXX.

Vraiment pas pratique tout ça. Car ça réclame une attention particulière qui n'apporte rien au final.

Sauf des confusions possibles.

 

Lucien

[Laurent51 2 787]

Lucien, je ne sais pas quel logiciel tu utilises, mais c'est a lui de s'adapter. Le 12 bits n'a rien d'extraordinaire, c'est l'équivalent d'utiliser une camera 16 bits sans dépassé la valeur de 4096. C'est généralement le cas pour le fond de ciel, et il n'y a que les étoiles brillante, les objets brillants qui dépasse cette valeur.

Il n'y a rien de sous exposé dans tout ca.

Sous Prism par exemple, que l'on soit en 12 bits (donc les 4 derniers bits a 0) ou en 16 bits (mais avec les 4 premiers bits a zéro), c'est exactement la meme chose au niveau de l'affichage. Et c'est logique car il n'y a pas de différence physique. 

 

Quel mixage de fichier?... justement mixer des images avec un convertisseur 16 bits avec des 12 bits format ZWO (donc 4 bits a zéro en poids faible), c'est justement le genre de truc que je ne ferrai pas.

Et en bin 2, comme tu le dis, tu es en 16XXX, ce qui est tout a fait normal, car tu additionnes 4 pixels.

Si tu étais avec une camera en 16 bits, et que tu fait un bin2, tu sortiras en 4x65535 soit 256XXX, ce qui est normal aussi.

 

Autre exemple, quand on utilisait l'Audine  qui était une camera en 15 bits, et bien la valeur maxi était de 32767, et on ne décalait pas le mot pour placer le bit de poids faible à 0. (et la au passage, ce n'est pas une camera CMOS). Il y a eu aussi des camera CCD en 14 bits, meme chose.

 

Avec une image sous le format ZWO (donc avec les 4 bits de poids faible à 0), tout les calculs de statistique des images sont faux. Exemple, le bruit RMS en ADU est 16 fois plus important qu'il n'est en réalité. Donc tout le monde se plante, et ca entraine ce type de discussion.

 

Tout ca c'est juste des calculs tres simples et tout a fait normal.

 

Laurent Bernasconi

Modifié 5 octobre 2019 par Laurent51

[Lucien 11 292]

Laurent,

Oui il n'y a rien de compliqué dans tout ça.

On ne va pas faire une débat sur rien.

De toute façon les concepteurs ne m'ont pas demandé mon avis.

 

il y a 21 minutes, Laurent51 a dit :

Quel mixage de fichier?... justement mixer des images avec un convertisseur 16 bits avec des 12 bits format ZWO (donc 4 bits a zéro en poids faible), c'est justement le genre de truc que je ne ferrai pas.

Ici tout le monde ne le sait pas.

 

Mais j'ai tort peut-être à vouloir tenter de simplifier pour les autres.

C'est peut-être aux autres de faire un effort ?

 

Amitiés,

 

Lucien

[patry 1 970]

Le mieux est de se faire la main avec IRIS, c'est "antique" par rapport aux outils modernes, mais on comprend ce que l'on fait sans interférence lié au logiciel qu fait (ou pas) le décalage des données. Car entre le format de capture (8 planétaire/10/12/14 bits), ce qui est lu (16 bits ?), ce qui est traité (32 bits), et ce qui est affiché (8 bits), puis sauvegardé (8/7 bits) il y a des raisons de s'y perdre.

 

Marc

 

 

 

[Laurent51 2 787]

Le probleme de décalage de données n'est pas du au logiciel, mais au driver Ascom du constructeur. C'est lui qui a choisi de placé les 4 bits non utilisé coté poids faible du mot de 16 bits. Et franchement, c'est une erreur.

Mais d'un point de vue commercial, c'est peutetre simplement pour faire croire que c'est une camera 16 bits:-).

 

Laurent Bernasconi

[Lucien 11 292]

Il y a 1 heure, patry a dit :

Le mieux est de se faire la main avec IRIS, c'est "antique" par rapport aux outils modernes, mais on comprend ce que l'on fait sans interférence lié au logiciel qu fait (ou pas) le décalage des données.

 

Oui on peut s'en sortir si l'on connait bien les outils.

Par défaut IRIS ouvre les fits en 16 bits signés, en gros de -32000 à + 32000 ADU.

Ce qui rajoute une difficulté supplémentaire si le fichier est codé dans la plage 0 - 65000.

 

Oui, c'est le driver qui est responsable de la sortie en 12, 14 ou 16 bits.

Ce n'est pas le capteur avec son convertisseur ADC.

 

PLUS PENIBLE :

Cette sortie ici en 12 bits (fichiers à 16)  peut donner lieu à des incertitudes.

Si vous envoyez ces fichiers bruts à un collègue qui les ouvre avec IRIS (pour donner un exemple),

il va trouver toutes vos images comme sous-exposées.

Rien ne peut lui indiquer que c'est codé en 12 bits et que c'est normalement exposé !

Et ça c'est vraiment gênant.

 

Lucien

 

 

[Nathanael 6 840]

Bonjour,

 

J'ai fait la manip préconisée (avec iris justement, donc j'ai divisé par 8) et j'arrive bien à saturation à 4096 adu et le bruit du fdc redescend à 8.8adu, l'image parait sombre mais tout va bien!

 

J'ai compris cette histoire de mots de 12 et 16 bits: sortie de l'électronique, la valeur du pixel est codé 101110101101 (par exemple!) en 12 bits mais une fois dans le logiciel 16 bits il est codé 1011101011010000.

Ce qui me rassure, c'est je n'avais pas tout à fait tort en écrivant que 1e- me donnait  16adu sur l'image finale (puisque c'est le poids du 5ème bit) et que le gain inverse "apparent" est bien de 1/16 e-/adu du coup, pour remplir les 65536 adu avec seulement 4096 e-.

Mais le fait de le diviser par 16 transforme le mot de 16 bits en 0000101110101101 (d'où "le mot de 12 bits à droite ou à gauche dans le mot de 16 bits") et ce sont les bits de poids forts qui sont à zéro (sur l'image, aucun pixel ne dépasse la valeur 4096) et le gain "apparent" revient naturellement à 1e-/adu.

 

Ceci étant dit, je me pose quand même la question des implications des 12 bits sur le traitement des images, sur la base des expériences concrètes d'amis astrophotographes. J'ai bien compris que c'est indépendant du fait que ce soit en cmos ou ccd, mais à l'heure actuelle, factuellement, 16 bits c'est les ccd, 12 bits les cmos (au moins pour les caméras les plus courantes). Le fait de partir d'une image 12 bits ("étirée" en 16 bits ou pas) ne doit pas être sans conséquence sur les transformations qu'on fait subir à nos pauvres images pendant le traitement (asinh, ddp etc...). D'ailleurs, l'image finale étant visualisée en 8 bits je me dis qu'il doit bien y avoir des raisons pour que les logiciels de traitement d'images les plus connus travaillent en 32 bits plutôt que 16bits. Le nombre de bits au départ doit avoir son importance. Encore une fois, sans temps de pose très long, la plupart des images cmos paraissent plus bruitées que les images ccd. Mais peut-être que le fait de diviser par 16 les images pré-traitées, avant traitement, suffit à règler le problème? Je suis bien sûr preneur d'infos sur ces derniers points.

 

Merci pour vos divers éclairages

 

Nathanaël

Modifié 6 octobre 2019 par T450
voir ci-dessous

[olivdeso 1 860]

il y a 18 minutes, T450 a dit :

J'ai compris cette histoire de mots de 12 et 16 bits: sortie de l'électronique, la valeur du pixel est codé 101110101101 (par exemple!) en 12 bits mais une fois dans le logiciel 16 bits il est codé 0000101110101101.

 

Ah non c'est le contraire :les 4 zéro sont à droite, pas à gauche ce qui revient exactement à multiplier par 16.

 

à chaque fois que tu mets un zéro à droite et que tu décale tous les bits d'un cran à gauche, ça revient à multiplier par 2.

C'est d'ailleurs pour ça qu'on a toujours intérêt à utiliser des puissances de 2 pour les multiplications et divisions en codage sur les petits processeur et microcontrôleurs, ça va beaucoup plus vite. (sauf si on a une fpu dans le cpu/soc)

 

Donc si tu divise par 16 les données, tu décales de 4 bits vers la droite, tu retrouve exactement les 12 bits du capteur au bon endroit. Et tous les autres bits à gauche de ces 12 bits sont à 0 pour faire une donnée sur 16 ou 32 bits.

 

Il faut se rappeller que les bits sont dans le même sens qu'un chiffre "normal" : on est juste en bas 2 au lieu de base 10.

 

exemple sur 4 bits:

(base 10 à gauche, base 2 à droite)

 

1 = 0001

2 = 0010

3 = 0011

4 = 0100

5 = 0101

6 = 0110

7 = 0111

8 = 1000

 

Donc tu vois que si tu divisrs 8 par 2, tu décale d'un cran à droite pour avoir 4.

Si tu divise 4 par 2, tu retrouves bien 2 en décalant les bits du 4 à droite.

(et en mettant un 0 à gauche pour combler)

 

edit : et si tu ne te rappelle plus, utilises la calculatrice de windows en mode binaire.

Modifié 6 octobre 2019 par olivdeso