seb-65

Comment déterminer le Gain et Offset d'un capteur ?

Messages recommandés

Bonjour,

 

Je cherche à connaitre quelle valeur utiliser concernant le Gain et Offset d'une caméra ZWO 1600MM Pro (mono).

 

En regardant l'image de la caméra suivante, a première vue le Gain optimal pour le capteur de la 1600 serait de 139 :

1600-Gain-RN-DR-FW-vs-gain1-e15087520072

 

De votre côté comment procédez-vous pour configurer le Gain et Offset de votre capteur ?

 

Merci :)

Partager ce message


Lien à poster
Partager sur d’autres sites

Pour ma part, j'avais trouvé ce fil d'info https://www.cloudynights.com/topic/573886-sub-exposure-tables-for-asi-1600-and-maybe-qhy163/

Et j'avais regardé au niveau du NarrowBand - Fullmoon pour faire du SHO dans mon environnement très pollué par la lumière

Le résultat est plutôt bon.

 

Christophe -BF-

Modifié par Christophe BF

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 02/10/2022 à 11:40, seb-65 a dit :

De votre côté comment procédez-vous pour configurer le Gain et Offset de votre capteur ?

 

Sur une caméra comme celle ci, avec une courbe de bruit de lecture qui descend régulièrement sans marche ni plateau, il n'y a pas vraiment de gain optimal.

Ça va plus dépendre de l'utilisation que tu en fais : temps de pose unitaire, filtres, cible, pollution lumineuse...

- si tu fais du Narrow bande, tu auras peu de signal, peu de dynamique, un fond de ciel bien sombre (en Ha et SII du moins) donc pas besoin de beaucoup de dynamique, par contre ils est très important de baisser le bruit de lecture. Donc tu vas augmenter le gain, typiquement le entre 200 et 300.

- en Luminance par contre il faudra plus de dynamique et le bruit de lecture est moins critique. Là on va diminuer un peu le gain. Donc 100-200, voir moins sur certaines cibles à grosse dynamique, mais c'est rare. Donc le gain à 139 pourquoi pas,

 

A vrai dire dire sur sa cousine la QHY163, je mettais souvent le gain à 200, ça va bien pour le Narrow bande et luminance.

Mais j'avais aussi des darks pour 300 et pour 100.

 

De toutes les façons la caméra ne sort que 12bits. Donc tu a intérêt à avoir une dynamique autour de 10,5 à 11 bits

Modifié par olivdeso
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Offset pas critique du tout :tu règle pour avoir un niveau moyen de 300 à 1000 ADU. Il faut que les pixels les plus sombres soient moins à 250 ADU. Mais que tu aies 250 ou 1250 ça ne change rien, ça décale juste l'histogramme mais sans le changer

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, olivdeso a dit :

Offset pas critique du tout :tu règle pour avoir un niveau moyen de 300 à 1000 ADU. Il faut que les pixels les plus sombres soient moins à 250 ADU. Mais que tu aies 250 ou 1250 ça ne change rien, ça décale juste l'histogramme mais sans le changer

au pire tu integre un pedestal de 1000 ADU au traitement avec pix 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à tous,

 

Merci @aubriot pour le lien !

 

J'utilise l'ASI1600MM avec les filtres "normaux" pas de H-alpha, O III et S II dans ma roue à filtre. Je n'utilise pas Pix mais Siril pour le traitement...

 

L'usage de cette caméra est d'imager le ciel profond et du transit d'exoplanète.

 

Seulement je suis perdu dans le bon réglage que je dois faire dans PRISM et Muniwin:(

 

L'ASI1600MM est une caméra 12 Bits ADC, le logiciel PRISM référence les images capturées en Dynamique camera 16 bits.

Dans PRISM > Configuration des Cameras, est-ce que la case "Forcer la dynamique réelle de la caméra (12/14 bits) doit être cochée ?

 

Dans Muniwin dans l'onglet Source frames :

- Max. pixel value il faut que je passe la valeur 65535 (16 Bits) à 4095 pour être en 12 Bits ?

- Camera Readout noise et ADC gain je ne sais pas remplir !

Si je pars du principe que j'utilise le gain optimal de la caméra à savoir 139 le Redout noise sera de 17 et le ADC gain  sera de 1 ?

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 09/10/2022 à 11:23, seb-65 a dit :

Si je pars du principe que j'utilise le gain optimal de la caméra à savoir 139 le Redout noise sera de 17 et le ADC gain  sera de 1 ?

 

la valeur 139 n'a rien d'optimal, c'est juste le réglage auquel le gain est de 1, ce qui en pratique...ne sert strictement à rien ! Le fait que ça apparaisse sur les courbes a toujours été un mystère pour moi...O.o  Le rendement quantique (le vrai) serait autrement plus utile !

 

 

Modifié par Thierry Legault

Partager ce message


Lien à poster
Partager sur d’autres sites

J'avais pris note en 2020 de cet article pdf sur la caméra QHY :

https://www.qhyccd.com/file/repository/PDF/Setting GAIN and OFFSET on cold CMOS camera for deep sky astrophotography.pdf

 

Voici l'extrait pour le gain :

 

GAIN setting

If you haven’t used a cold CMOS camera before, we recommend that you set the gain to “unit-gain” in the beginning. Unit-gain

means the gain of which 1 electron per ADU ( 1e/ADU ). In general we give you this number. For example, QHY168C the unit-gain

is 10, QHY367C is 2800. You don’t need to bother much about this value, increase or decrease a bit doesn’t make a big

difference.

*Attention: Setting the unit-gain is not the best setting. It is only a beginning

Then we increase or decrease the gain value according to the condition. In general if your optics is a fast one, low F-ratio

between F2.2 to F5, long exposure for more than 5 minutes and not using narrowband filters, then you can decrease the GAIN

value to achieve a higher dynamic range and make better use of full well capacity. Doing so will avoid overexposure of the stars.

You will see overexposed stars as bloated and loss of color saturation.

If you use narrowband filter on a slow optical system between F6 – F10, and short exposure time, then the number of photons

received will be lower. In this case you can increase the GAIN value to make better use of characteristics of low read-out noise in

high GAIN value. This will increase the signal to noise level of your target

 

-----------------------------------------------------------------

 

Si cela peut aider.....

 

Marc.

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci pour les réponses, mais pour le coup je ne suis pas plus avancé sur quoi faire :P

 

Quand on farfouille sur Google il est préconisé avec Muniwin de bien renseigner les valeurs Max. pixel/Readout noise !

ET pour simplifier le truc j'ai une caméra 12 Bits et ne sais pas s'il faut la configurer comme tel dans PRISM afin de répliquer cette valeur dans Muniwin...

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 09/10/2022 à 11:23, seb-65 a dit :

- Max. pixel value il faut que je passe la valeur 65535 (16 Bits) à 4095 pour être en 12 Bits ?

 

Ben non, les données sont bien en 16 bits avec un décalage de de 4 bits vers la gauche. Donc le max value est bien 65535.

Partager ce message


Lien à poster
Partager sur d’autres sites

OK @olivdeso  donc il y a une petite nuance sur laquelle il faut faire attention alors...

Pour Muniwin j'ai vu "si vous avez une caméra 12 Bits, veuillez modifier la valeur Max. pixel value" xD

 

En gros si le logiciel d’acquisition enregistre bien au format 16 bits (comme le fait Prism) il ajoute automatiquement un décalage dès lors que l'on utilise une caméra 12 bits ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, seb-65 a dit :

En gros si le logiciel d’acquisition enregistre bien au format 16 bits (comme le fait Prism) il ajoute automatiquement un décalage dès lors que l'on utilise une caméra 12 bits ?

 

En fait c'est la caméra qui sort les 16bits. (Ou son driver?). Ça arrive déjà en 16 bits dans les logiciels de capture quels qu'ils soient.

 

Mais avec les 4 bits de poids faible à une valeur fixe,  0 en général

 

Donc en fonction la valeur max est peut être 65535 - 15 = 65520.

 

Mais dans certains drivers on peut aussi ajouter un "pedestal" i.e. une constante pour remonter l'histogramme, 

 

Il suffit d'essayer sur un flat saturé et de voir combien d'ADU on a. 

Modifié par olivdeso

Partager ce message


Lien à poster
Partager sur d’autres sites

Alors pourquoi ne pas diviser les brutes par 16 si de toute façon les 4 bits de poids faibles sont toujours à zéro ? Cela permet de garantir que les poids forts satureront 16x moins vite ! Mais je raisonne en planéteux, peut être qu'en CP il y a quelque chose qui m'échappe à vouloir perdre 4 bits de dynamique ?

 

Marc

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Ben si tu divises par 16, tu aura les 16bits de poids fort à 0. Tu auras juste décalé ton histogramme à droite, mais pas ton point de saturation ni ta dynamique qui reste sur 12 bits au mieux.

  • J'aime 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