T450

cmos vs ccd : la dynamique

Recommended Posts

Posted (edited)

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

Edited by T450
  • Like 3

Share this post


Link to post
Share on other sites
Publicité
En vous inscrivant sur Astrosurf,
ce type d'annonce ne sera plus affiché.
Photographier la Lune
Guide complet pour la photographier de la Lune.
Information et commande sur www.photographierlalune.com
Posted (edited)

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

Edited by Raphael_OD

Share this post


Link to post
Share on other sites
Posted (edited)

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.

Edited by christian_d

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

sigma-fdc-qsi-lowgain-T250-3x3mn.JPG

 

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

sigma-fdc-qsi-highgain-T250-3x3mn.JPG

 

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

sigma-fdc-asi-gain111-T250-3x3mn.JPG

 

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

sigma-fdc-asi-gain270-T250-9x1mn.JPG

 

Share this post


Link to post
Share on other sites

Bonjour Nathanael, 

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

image.png.6ee1c2f13b11f53b5fa38e89b462987e.png

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Edited by Laurent51
  • Like 3

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)

"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

 

 

 

Edited by Laurent51

Share this post


Link to post
Share on other sites
Posted (edited)

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.

Edited by Laurent51
  • Like 1

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

 

Lucien

Share this post


Link to post
Share on other sites

"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

 

Share this post


Link to post
Share on other sites
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.:D

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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Edited by Laurent51
  • Like 1

Share this post


Link to post
Share on other sites

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. :D

 

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

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

 

Amitiés,

 

Lucien

  • Like 1

Share this post


Link to post
Share on other sites

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

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites
Posted (edited)

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

Edited by T450
voir ci-dessous

Share this post


Link to post
Share on other sites
Posted (edited)
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.

Edited by olivdeso
  • Thanks 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



  • Similar Content

    • By Galileo242512
      Bonjour, 
      Bon tout est dit dans le titre. 
      Je possède un Dobson 305mm GSO deluxe et aimerai essayer L'astrophoto (planétaire voir CP). J'ai un petit budget 250€ donc les CCD je peux oublier. 
      D'où ma question est ce que un Canon 360d ou 1000d serait bien sûr ce télescope ?
       
       
      Cordialement, 
      Bon ciel 
    • By eos65
      Bonsoir, 
      Comme beaucoup je suis dans l’attente, l'automne est là et le temps maussade également. Donc histoire de patienter, quelques images sur mon site de prédilection (Hautacam Hautes-Pyrénées) 
      Très bon week-end à vous tous, amicalement 
      Joel 




    • By anticythere
      Bonjour à tous...
        depuis peu, j'ai repris l'astro, dans le but de me mettre à l'astrophoto et visuel assisté.. j'ai donc fais l'achat d'un newton 200/800 skywatcher sur HEQ5 et d'une camera ASI385MC.
      je dois bien avoué que j'ai galérer un peut de passer du dobson AZ au monture equatorial.
       
        je vais vous partagez mes premiere acquisition d'image... vous noterez que je ne parle pas de photo, ça serais insultant "mdr"
      j’espère en tirez quelques bon conseil.. afin de m’améliorer et continuer à vous poster le résultat de mon apprentissage.
       
      PS: désoler, je suis sur que c'est blinder de faute d'orthographe, je m'applique, mais je suis une vrai quiche.
    • By YugnatD
      Bonsoir à tous,
       
      Dans le cadre de mon diplôme de technicien en électronique, j’ai refait toute l’électronique de gestion des moteurs de ma monture NEQ5 (avec kit de motorisation).
      J’y ai aussi intégré un système de régulation automatique (PID) pour empêcher la condensation d’apparaître sur les miroirs du télescope.
      Le projet est assez volumineux, car j’avais comme consigne de faire le projet par module (peut-être que je ferais une plaque plus petite qui contient toute l’électronique).
       
      Le tout est contrôler par deux microcontrôleurs (un pour les moteurs, et un pour la régulation de température), mais une raspberry pi est présent sur la carte, afin de contrôler la camera de guidage lors des séances de photo. Donc le suivi du ciel peut fonctionner sans la raspberry pi pour économiser de l’énergie, mais elle est nécessaire pour le guidage (avec PHD2).
       Lorsque la Raspberry pi est allumé, il est possible de contrôler la monture à distance à partir d’une page web.
       
      J’ai aussi ajouté un serveur Stellarium afin de créer un système GOTO, mais le télescope ne pointe pas au bon endroit (je ne sais pas d’où ça vient, peut-être les calculs...).
      Sur la photo du projet, il manque des boutons afin de contrôler manuellement le déplacement des moteurs (RA, DEC), le connecteur pour les boutons est bien présent sur la carte, mais je n’ai pas encore fait le câblage.
       
      Dans le PDF du projet, les moteurs fonctionnent en demi-pas, depuis je les aie passés en 1/8, ça a réduit les vibrations, et la monture fait moins de bruit.
      Au début j'avais intégrer un écran à la carte, mais je me suis rendu compte qu'il n'était pas très utile, donc j'ai décider de l'enlever. 

      J’espère que vous trouverez ce projet intéressant, si vous avez des remarques à faire n’hésitez pas.
       
      Lien GitHub : https://github.com/YugnatD/Astrophotography-Assistant
       
      Je reposte mon projet dans le forum AstroPratique comme on me l'as conseillé.
      2019_diplome_Dietrich.pdf



    • By Loup Lunaire
      Bonjour,
       
      Hier soir voilà la lune qui sort enfin des nuages, l'occasion de l'apprécier même si tardive car le travail arrive alors....
      Une image avec une nouvelle méthodologie de la couleur, le tous sous ASTROSURFACE, en expérimentation en sorte utilisant à la fois le HDR, le local contrast equalize histogram et la color saturation (sur Image Tools).
       
      Je l"a trouve resplendissante avec ses couleurs, un côté un peu vintage .
      Ne cherchez pas la résolution, elle n'est pas terrible.
       

       
      Bon ciel lunaire
  • Images