Nathanael

cmos vs ccd : la dynamique

Messages recommandés

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é par T450
  • J'aime 3

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Modifié par Raphael_OD

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par christian_d

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres 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

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour Nathanael, 

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

image.png.6ee1c2f13b11f53b5fa38e89b462987e.png

 

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par Laurent51
  • J'aime 3

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres 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

 

 

Partager ce message


Lien à poster
Partager sur d’autres 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.

Partager ce message


Lien à poster
Partager sur d’autres sites

"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é par Laurent51

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par Laurent51
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

Lucien

Partager ce message


Lien à poster
Partager sur d’autres 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

 

Partager ce message


Lien à poster
Partager sur d’autres 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

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par Laurent51
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres 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

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres 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

 

 

 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres 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

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres 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

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par T450
voir ci-dessous

Partager ce message


Lien à poster
Partager sur d’autres sites
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é par olivdeso
  • Merci 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant



  • Contenu similaire

    • Par Sauveur
      Salut
       
      Depuis le Pic comme j'avais vue Jean Luc avec ce petit engin ca ma donné envie de l'acquérir , J'ai attendue une occas et voila 
       
       Le premier Jour il m'a étonné en pointant précisément le soleil avec un posé shooté 
       

       
       

       
       
      c'est les fichier téléchargé automatiquement sur le Telephone et qu'il faut laissé a proximité et allumer
       
       
      Hi hi hi Juju en gros plan 
       

       
       

       
      Comme il m'est les brutes dans son disque dur on peut traité apres tranquillement
       
      premier essais pas beaucoup de poses
       

       

       
       

       
       

       
       
       

       
       
       

       
       
       

       
       

       
       
       

       

       
       
      Bon il y a peu de pose et un traitement un peu a la vas vite car suis plutot Juju quand même et j'en ai au four encore
       
       
    • Par Sauveur
      Oui fait au smartphone et la star aventure pour la lulu et intervallomètre DiY mais je pourrais avoir Nina pour l'astrometrie mais faudrait le défiltré et c'est assez dure mon premiere essais a été un echec
       
      21 poses de 30 secondes
       
      bon j'ai des soucis d'étalonnage des couleur du a la matrice de bayer bien différentes RYB oui oui Rouge jaune Bleu
       
      L'extrem Lulu phone au foyer sans lentilles
       

       
       

       
      NGC 884 et NGC 869_stacked 42 poses de 30 secondes
       

       
      M45_stacked 15 poses de 30 secondes
       
       
       

       
       
      J'ai retenter bon toujours pas de mes aux oignon je shootai Juju a coté
       

       
      sur le canarie pas pu faire correctement la mes j'aivais prêté mon eq6 a un copain 
       
      Bon cette matrice RYB c'est un peu con pour l'étalonnage faut que je cherche
       

       
      m13
       

       
      M51 peu de poses et le dithering bein y a pas
       

       
       
       
      @MCJC
       
      bonne journée
    • Par Gilles Pascal
      Bonjour,
       
      en 2023 j'ai réalisé une série de prises de vue de Jupiter pendant une nuit.
      Ensuite je les ai assemblées (avec PIPP) pour en faire une animation.
       
      Le résultat me plaît mais à présent je voudrais aller plus loin. L'idée serait de pouvoir superposer à chaque vue, une image tirée de la simulation de STELLARIUM.
       
      Chaque image de l'animation serait au final donc un assemblage de deux images :
      - Dans la moitié supérieure de l'image on verrait un bandeau horizontal issu de STELLARIUM
      - Dans la moitié inférieure, on verrait un bandeau réalisé à partir de l'image prise par la caméra.
       
      Le souci c'est la rotation de champ dans STELLARIUM.
       
      Pendant pas mal de temps je me suis noué le cerveau pour tenter de trouver l'angle qu'il faudrait appliquer pour réaliser la dé-rotation.
       
      Et aujourd'hui je viens de trouver une solution totalement simple et déconcertante : il suffit de mettre à "true" le booléen qui indique le mode equatorial dans STELLARIUM.
      Encore faut-il trouver la syntaxe. Qu'à cela ne tienne, une recherche rapide dans les nombreux scripts stockés dans le sous-répertoire idoine (C:\Program Files\Stellarium\scripts) permet avec Notepad++ de trouver les séquences qui contiennent la partie de texte "quatorial" (ben oui, ne sachant pas si le mot commence par un 'é' ou un 'e'...).
       
      Alors comme cela m'a pris du temps, et que ça pourrait servir à des astram, je vous livre le code complet de mon script.
      Le contenu est à enregistrer dans un fichier dont l'extension devra être .ssc
      Il suffit ensuite de double-cliquer sur le fichier, et Stellarium se lancera automatiquement en exécutant le script.
       
      La localisation est placée à la terrasse de Meudon. Mais pour vos besoins, vous changez les valeurs par celles de votre site.
       
      Bon ciel,
      Gilles
       
       
       
       
       
      include("common_objects.inc");
      // var MonDIR = "C:/Users/gpasc/Pictures/Stellarium";
      // var MonDIR = core.getEnv("STEL_SKYBOX_DIR");
      // Not finding this environment variable sets DIR to empty string to make storage into default image dir, i.e., "C:/Users/YOU/Pictures/Stellarium"
      // For technical reasons, on Linux you MUST set this variable before running the script.
      DIR=core.getEnv("STEL_SKYBOX_DIR");
      // Base name for the tile textures. Defaults to Unity, can be overridden by setting environment variable STEL_SKYBOX_BASENAME
      BASENAME=core.getEnv("STEL_SKYBOX_BASENAME");
      if (BASENAME.length == 0)
          BASENAME="Unity";
      // Output data file name. Defaults to unityData.txt, but can be overridden by setting environment variable STEL_SKYBOX_DATA
      DATANAME=core.getEnv("STEL_SKYBOX_DATA");
      if (DATANAME.length == 0)
          DATANAME="unityData.txt"
      OUTPUT_DATA=DIR + "/" + DATANAME;
      core.output("Writing images to " + DIR);
      core.output("Writing data to " + OUTPUT_DATA);
      // The following wait times (seconds) are required to arrive at scene before screenshot. Configure for your machine.
      // This must likely allow 2 frames to be drawn before screenshot is valid.
      MOVE_WAIT=0.05;
      SHOT_WAIT=0.15;
      core.setDate(
         '2023-08-21T02:27:59',
         'local'              , // or 'utc' or 'local'
          true                  // enable Delta T correction
      );
      core.setObserverLocation(
          2 + 13/60 + 59/60/60, // core.dmsToRad(2, 13, 59), // longitude
         48 + 48/60 + 19/60/60, // core.dmsToRad(48, 48, 19), // latitude
         151,                       // Altitude
         0,                       // Time to travel
         "",                       // or "Terrasse de Meudon",
         "Earth"                   // This parameter seems necessary
      );
      core.selectObjectByName("Jupiter", false);
      PData = core.getObjectInfo("Jupiter");
      StelMovementMgr.setFlagTracking(true);
      GridLinesMgr.setFlagAzimuthalGrid(false);
      StelMovementMgr.zoomTo(0.07, 1);
      core.setGuiVisible(true);
       
       
      // On force le mode equatorial pour empecher la rotation de champ :
      StelMovementMgr.setEquatorialMount(true);
       
       
      // Lister ici les instants correspondants aux prises de vues
      // Format à respecter :
      //
      //                  "AAAA-MM-JJTHH:MM:SS"
      //
      // L'ensemble des données est stocké dans le tableau ci-dessous
      // C'est le nombre d'éléments, contenus intrinsèquement dans le tableau
      // qui fournira la limite haute de la boucle parcourue plus bas dans ce script.
      //
      var Horaire_Positions = new Array("2023-08-21T02:27:59",
                                      "2023-08-21T02:33:27",
                                      "2023-08-21T02:38:56",
                                      "2023-08-21T02:44:24",
                                      "2023-08-21T02:49:53",
                                      "2023-08-21T02:55:22",
                                      "2023-08-21T03:00:51",
                                      "2023-08-21T03:06:19",
                                      "2023-08-21T03:11:48",
                                      "2023-08-21T03:17:16",
                                      "2023-08-21T03:22:45",
                                      "2023-08-21T03:27:50",
                                      "2023-08-21T03:33:18",
                                      "2023-08-21T03:38:46",
                                      "2023-08-21T03:44:15",
                                      "2023-08-21T03:49:44",
                                      "2023-08-21T03:55:12",
                                      "2023-08-21T04:00:41",
                                      "2023-08-21T04:06:09",
                                      "2023-08-21T04:11:38",
                                      "2023-08-21T04:17:07",
                                      "2023-08-21T04:22:35",
                                      "2023-08-21T04:28:03",
                                      "2023-08-21T04:33:32",
                                      "2023-08-21T04:39:00",
                                      "2023-08-21T04:44:29",
                                      "2023-08-21T04:49:57",
                                      "2023-08-21T04:55:25",
                                      "2023-08-21T05:07:56",
                                      "2023-08-21T05:13:25",
                                      "2023-08-21T05:18:53",
                                      "2023-08-21T05:24:21",
                                      "2023-08-21T05:29:50",
                                      "2023-08-21T05:35:19",
                                      "2023-08-21T05:40:47",
                                      "2023-08-21T05:46:15",
                                      "2023-08-21T05:51:44",
                                      "2023-08-21T05:57:12",
                                      "2023-08-21T06:02:40",
                                      "2023-08-21T06:08:09",
                                      "2023-08-21T06:13:37",
                                      "2023-08-21T06:19:04",
                                      "2023-08-21T06:24:32",
                                      "2023-08-21T06:30:01",
                                      "2023-08-21T06:35:29",
                                      "2023-08-21T06:40:58",
                                      "2023-08-21T06:43:35",
                                      "2023-08-21T06:52:02",
                                      "2023-08-21T06:57:30",
                                      "2023-08-21T07:02:59",
                                      "2023-08-21T07:08:27",
                                      "2023-08-21T07:13:55",
                                      "2023-08-21T07:19:23");
      // The following wait times (seconds) are required to arrive at scene before screenshot. Configure for your machine.
      // This must likely allow 2 frames to be drawn before screenshot is valid.
       
      MOVE_WAIT=0.05;
      SHOT_WAIT=0.15;
      core.setGuiVisible(false);
       
       
      // On stabilise la première position avant de lancer la boucle
      core.setDate(
                  Horaire_Positions[0],
                  'local'              , // or 'utc' or 'local'
                  true                  // enable Delta T correction
                  );
      core.output(Horaire_Positions[0] );
      // on attend 3 secondes pour bien stabiliser la première position
      core.wait(3);
      for (i=0; i<Horaire_Positions.length; i++)
      {
      core.setDate(
                  Horaire_Positions,
                  'local'              , // or 'utc' or 'local'
                  true                  // enable Delta T correction
                  );
      // Régler STELLARIUM à l'horaire pointé dans le tableau :
      core.output(Horaire_Positions );
      // Tempo pour attente de stabilisation :
      core.wait(MOVE_WAIT);
       
       
      // Capture d'écran et sauvegarde dans le repertoire BASENAME + i :
      core.screenshot(BASENAME + i, false, DIR, true);
      core.wait(SHOT_WAIT);
      }
      core.setGuiVisible(true);
      //EOF
    • Par Cyril Richard
      Bonsoir tout le monde.
      Certains le savent peut-être, mais la future grosse mise à jour de Siril contient l'étalonnage des couleurs par Spectrophotométrie. C'est une avancée majeure dans le développement et rendra obsolète l'ancien module d'étalonnage des couleurs par photométrie.
      Pour ceux qui souhaitent en savoir plus sur ce module, voici un lien sur la doc de la version en développement.
       
      Dans l'esprit du logiciel opensource, et du partage de données (philosophie prônée par Siril depuis ses débuts) nous avons mis en place une base de données des filtres et capteurs utilisée par l'algorithme. Plus cette base de données sera complète, et plus l'outil sera puissant. Et c'est là où la communauté est importante. Si vous avez envie d'aider Siril à devenir plus performant et que vous possédez des courbes de filtres, ou de capteur non pris en charge, alors c'est pour vous.
       
      La base de données se trouve ici : https://gitlab.com/free-astro/siril-spcc-database et le README (en anglais) explique comment ajouter des données. Cependant, n'hésitez pas à me contacter
       

       

    • Par FrancoisGAP
      Merveilleuse cette comète. Pas évident à traiter mais le résultat est sympa 
       
      Détail et full visible sur mon site Web : https://planetediy.fr/index.php/2024/03/14/la-fascinante-comete-12p-pons-brooks-un-veritable-spectacle/
       

       
      Détail du matériel utilisé :
      TS-ONTC HYPERGRAPH 10″ 254/1000 (Fd4)
      Correcteur Réducteur 0,85×3″ soit 863mm (Fd3,4)
      EQ8R-Pro sur Pilier Acier DIY
      ZWO ASI2600MC DUO + Optolong Clear 2″ + Optolong LExtreme 2″
      ZWO EAF
      ZWO EFW 5 positions 2″
      (25)x60s Gain=100 (-30°C)
      40 Darks Gain=100
      40 Darks Flat Gain=100
      40 Flats Gain=100
      Traitement Pixinsight
  • Évènements à venir