Nathanael

cmos vs ccd : la dynamique

Messages recommandés

Ok merci! Je corrige pour que personne ne s'emmêle les pinceaux par ma faute ;)

Nathanaël

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 23 minutes, T450 a dit :

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.

 

C'était mon interrogation à l'époque de ça

Le 22/08/2019 à 16:46, Jean-Marc_M a dit :

Pour continuer sur cette voie, je me demande ce que notre oeil est capable de distinguer comme nombre de nuances de gris.

Puis, quel est l'intérêt d'avoir un capteur 12, 14 ou 16 bits puisque ça se termine très souvent par une une image jpeg en 8 bits ?

 

J'en ai conclus que pour des yeux non bioniques, 12 bits est suffisant pour restituer les différentes couleurs et leur niveaux de luminosité en imagerie du ciel profond.

 

Le bruit est un autre problème intrinsèque au capteur et très probablement conséquence des paramètres d'acquisition (gain/offset), du temps d'exposition unitaire, du nombre d'images empilées, de l'amplitude du dithering, de la qualité du ciel etc... Le CMOS a l'air moins pardonnant que le CCD.

On aura certainement l'occasion d'en reparler ;)

Partager ce message


Lien à poster
Partager sur d’autres sites

La donnée est sur 12 bits mais on stocke sur 16 ... il manque 4 bits que l'on met où on veut si c'est (logiquement) à gauche, alors 4095 sera codé 4095, tout va bien mais le logiciel peut croire que l'image est très sombre ... pour autant toutes les données y sont.

Soit on met les bits nuls à droite (poids faible), cela revient à multiplier par 2^4 = 16, donc ton 4095 devient 65520. Cool ton image est claire et ce 65520 est très brillant (comme ton 4095 sur 4096).

Maintenant on va y faire des opérations sur ces images, par exemple des accumulations. 256 images (disons toutes à 4095) vont décaler le résultat de 8 bits (2^8 = 256), et il faudra faire le calcul sur "plus de 16 bits". Tous les processeurs font nativement des calculs sur 32 (voir 64) bits en un cycle d'horloge (opération sur des entiers, addition, soustraction, multiplication et parfois même division).

Donc il est logique (et même indispensable) que les calculs soient réalisés en 32 bits, voire même si besoin en flottant. Là on perdra en dynamique (23 bits, encore très largement suffisant) mais on gagnera en valeur maximale/minimale (c'est pas antinomique, c'est la joie de l'IEEE754) avec un exposant sur 8 bits et un signe (8+1+23 = 32 le compte est bon).

 

il y a une heure, Jean-Marc_M a dit :

J'en ai conclus que pour des yeux non bioniques, 12 bits est suffisant pour restituer les différentes couleurs et leur niveaux de luminosité en imagerie du ciel profond.

 

Oui, il est difficile de distinguer clairement 256 niveaux de gris différents (8 bits), là encore c'est selon les individus, peut être 512 (9 bits) ?

 

 

Marc

 

Partager ce message


Lien à poster
Partager sur d’autres sites

affiche 64 niveaux de gris sur ton écran et si tu vois encore facilement les différences passe à 128. distinguer visuellement 256 niveaux sur les écrans courants ça me parait beaucoup.

ce qu'il y a de bien avec 4096 niveaux c'est que si tu prends la racine de ton image elle va s'afficher en 64 niveaux (en général étalés sur la dynamique de ton écran), ce qui est suffisant pour une évaluation rapide, et avec une réponse  plus proche de la vision humaine qu'un affichage linéaire.

 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

 

Il était dit :

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

16 bits c'est les ccd, 12 bits les cmos (au moins pour les caméras les plus courantes)

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

NON : ce n'est pas lié au CMOS ou la CCD !

En gros c'est lié au QE (rendement quantité)  et la surface du pixel.

Plus on capte d'électrons à convertir plus il faut de grands chiffres pour les compter !

D'ailleurs il y a des CMOS avec des convertisseurs 14 bits et des CCD avec des convertisseurs 12 bits (souvent traduits à 16).

Regardez la taille pixel.

 

 

Il était dit :

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

Puis, quel est l'intérêt d'avoir un capteur 12, 14 ou 16 bits puisque ça se termine très souvent par une une image jpeg en 8 bits ?

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

C'est de l'arithmétique : si on veut avoir des résultats précis, il faut calculer avec précision, même si on arrondit à la fin !

Et les calculs internes ne sont pas que des additions ou des multiplications : arc tangente hyperbolique...

 

 

 Il était dit :

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

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...).

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

NON : Que l'on parte d'une image 12 bits ou 12 bits étirés à 16, l'information reste la même.

Et puisque les calculs sont faits en 32 ou en 64 bits, si le programmeur n'a pas bu trop de bières, :D

le résultat des traitements sera identique.

 

 

Il était dit :

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

Encore une fois, sans temps de pose très long, la plupart des images cmos paraissent plus bruitées que les images ccd

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

On ne peut mettre dans le même sac toutes les CMOS et toutes les CCD : variété de modèles.

Néanmoins généralement les CMOS sont moins bruitées que les CCD :  si on compare à échantillonnage égal.

Ce que souvent on ne fait pas !

On change sa caméra par une à plus petits pixels, mais on en change pas la focale !

 

 

Certains disent :

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

Les CMOS ont une plus faible dynamique que les CCD. Et je sature plus vite les étoiles brillantes.

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

OUI et NON :

Les CMOS ont une forte dynamique cependant si les capteurs ont de petits pixels,

la dynamique est gagnée surtout dans les fiables signaux et pas dans les hautes-lumières.

Effectivement, on risque de saturer les objets très lumineux : Full Well Capacity

Grossièrement, ceci est lié à la taille du pixel plus qu'à la technologie CMOS ou CCD.

--  l'ASI071MC Pro avec ses pixels de 5.97µm (couleur malheureusement)  possède un FWC de 76000 électrons  et convertisseur 14 bits interne

-   l'ASI1600MM avec ses pixels de 3.8µm possède une FWC de "seulement" 20000 électrons et convertisseur 12 bits interne.

Ceci résume bien la situation, CMOS ou pas !

 

 

EN CONCLUSION :

Le point faible des CMOS est surtout qu'il manque une offre de capteurs avec des pixels de 6 à 9 µm et à des couts 'amateur".

Ceci pour les adeptes du ciel-profond surtout.

 

Souvent quand on compare CMOS v CCD, il faudrait plutôt intituler : petits pixels v gros pixels.

Ce serait plus exact de dire ainsi.

 

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

Les capteurs CCD vont ils disparaitre ?

OUI, et sauf pour certains usages très spécifiques et sans rebond technologique imprévu.

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

 

 

Bonne journée,

Lucien

  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Il était dit :

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

Encore une fois, sans temps de pose très long, la plupart des images cmos paraissent plus bruitées que les images ccd

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

On ne peut mettre dans le même sac toutes les CMOS et toutes les CCD : variété de modèles.

Néanmoins généralement les CMOS sont moins bruitées que les CCD :  si on compare à échantillonnage égal.

Ce que souvent on ne fait pas !

On change sa caméra par une à plus petits pixels, mais on en change pas la focale !

 

> Hello, 

Je crois que l'auteur de ce post est en train ce mettre en lumière cette comparaison à échantillonnage égal, rendu des forts et faibles signaux et bruit. C'est du boulot, et se fournir des diverses caméras n'est pas si simple ainsi que les acquisitions et traitements.

Mais si au moins on arrive à en sortir une analyse un peu près cohérente plutôt que "c'est mieux la CCD c'est mieux le CMOS" je pense que cela me décidera pour mes futurs achats de caméras ;)  

Je salue le geste et la démarche.

 

 

EN CONCLUSION :

Le point faible des CMOS est surtout qu'il manque une offre de capteurs avec des pixels de 6 à 9 µm et à des coûts 'amateur".

Ceci pour les adeptes du ciel-profond surtout.

 

 > Oui pourquoi pas ! mais en fonction de l'échantillonnage personnellement les 6-9µ j'en ai pas besoin, ou alors sur un RC et grande focale. 

A+

 

 

Modifié par Raphael_OD

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 7 heures, Lucien a dit :

Il était dit :

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

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...).

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

NON : Que l'on parte d'une image 12 bits ou 12 bits étirés à 16, l'information reste la même.

 

D'accord,  mais alors que penser des niveaux de fdc mesurés au début de ce post (dans les images ici), images prises avec le même instrument, le même échantillonnage (la focale est justement ajustée avec le paracorr2 x1.15 et l'asa x0.73), le même temps de pose, le même jour?

Dans un premier temps, je me dis que les images à l'asi sont plus bruitées, dans un deuxième temps, Laurent me dit qu'il faut diviser par 16 et effectivement en divisant par 16 elles sont moins bruitées (mais il y a aussi 16x moins de signal), dans un troisième temps tu me dis que ça ne change rien à l'information (donc les images à l'asi sont plus bruitées) et pour finir je n'y comprends plus rien ;)

Remarque, je préfère ne pas  comprendre que de croire que je comprends sans comprendre :D

Nathanaël

  • Haha 1
  • Confus 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 20 minutes, T450 a dit :

et pour finir je n'y comprends plus rien ;)

Remarque, je préfère ne pas  comprendre que de croire que je comprends sans comprendre :D

Nathanaël

 

Ah ok là au moins on se comprend!

  • Haha 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Ah Nathanaël, moi aussi tes posts me font bien réfléchir.

Perso je regarde les raw de mon 6D. Le CAN est en 14 bits et le fichier en 16 bits. J'ouvre en pure raw dans pixinsight. La dynamique n'est pas étirée, les étoiles saturées sont toutes à 14043 adu (ln(14043)/ln(2) = 2^13,78 ) ce qui fait pas loin de 2^14=16 384. et rien ensuite jusqu'à  65 536 adu (2^16). Pas d'étirement ni dans le Canon, ni dans pix. Alors les ASI étirent pour le fichier de sortie?

et oui laurent à raison pour comparer, il faut normaliser pour le même nombre d'adu total...

 

  • J'adore 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Avec les APN, quand on convertit leurs fichier Raw en tif ou png 16 bits,

à l'aide de logiciels dédiés,

on sort toujours avec des niveaux de 0 à environ 65000.

Et ceci même si en interne APN, le convertisseur était en 10, 12 ou 14 bits.

Et heureusement pour ceux qui vont visualiset les images !

 

Ceux qui font des calculs doivent par contre être attentifs !

 

Lucien

 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

De toutes façons, je ne connais pas de PC dont la mémoire bosse en 10, 12 ou 14 bits xD

Tout est toujours enregistré par multiple de 8 :)

Bonne soirée,

AG

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 6 heures, T450 a dit :

Laurent me dit qu'il faut diviser par 16 et effectivement en divisant par 16 elles sont moins bruitées (mais il y a aussi 16x moins de signal)

 

Oulala, bon je ne sais plus comment te l'expliquer. Il n'y a pas 16x moins de signal, je n'ai jamais dit ca!! Il y a le meme signal, car dans un cas les 4 bits de poids faible sont toujour à 0 (choix malheureux du constructeur), et dans l'autre cas, avec la division par 16, on déplace les 4 bits à 0 sur les 4 poids les plus fort du mot de 16 bits comme ca devrait etre. Et oh miracle, on a enfin des résultats juste dans les analyses statistiques.

 

Quand le convertisseur reçoit 1e (avec un gain réglé à 1e/adu), il indique en sortir le nombre 1. Il en reçoit un deuxième, il indique 2 etc...

Puis ZWO décale le résultat de 16, en plaçant 4 bits à 0 juste avant la valeur du convertisseur, donc  on trouve comme valeur envoyé par ZWO 16 au lieu de 1, puis 32 au lieu de 2, puis 48 au lieu de 3 etc.…

C'est juste completement artificiel. c'est une représentation en sortie qui est completement fausse, et plante tout les calculs statistiques. Il fait donc diviser par 16 pour retrouver les valeurs d'origine en sortie du convertisseur: 48/16=3,  32/16=2; 16/16=1

Modifié par Laurent51

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 11 heures, T450 a dit :

Dans un premier temps, je me dis que les images à l'asi sont plus bruitées, dans un deuxième temps, Laurent me dit qu'il faut diviser par 16 et effectivement en divisant par 16 elles sont moins bruitées (mais il y a aussi 16x moins de signal),

 

Il faut bien diviser par 16 pour retrouver les données originales enregistrées par le pixel et faire disparaître les 4 zéro de droite. c.f. mon post ci dessus.

 

Ce qui compte c'est le rapport signal à bruit. Et ça c'est constant que tu divise par 16 ou pas.

 

La dynamique, par définition, c'est le niveau max divisé par le bruit de lecture.

C'est ça qu'il faut comparer. En ADU ou e- peu importe.

Quel est le bruit de lecture de la QSI et son niveau max ? pareil pour la CCD et a différent gains.

 

ZWO donne d'ailleurs directement les courbes de dynamique en fonction du gain : ça diminue quand on augmente le gain.

 

Pour la QSI, tu peux partir des données QSI : full Wheel 18000 e-, bruit de lecture 3,1 e- 

-> dynamique = 18000/3,1 = 5806

 

en dB tu fais 20log (5806) = 75,3dB  

 

(pour comparaison, un kaf16803 a 81dB de dynamique et un kaf8300  71dB)

 

en bits tu fais ln (5806) / ln (2) = 12,5 bits  

 

tu vois bien que la QSI 690 a au max 12,5 bits de dynamique et pas 16. En pratique il faudra un convertisseur 14 bits pour bien exploiter ces 12,5 bits. donc un 16 bits fera le boulot.

 

Pour la 183, si tu veux la meilleure dynamique, il va falloir travailler à gain minimal. Dans ce cas le FW est de 15000 e- en gros et le bruit de lecture de 3e-. C'est dans les mêmes eaux que la QSI.

Donc pas d'intérêt de changer ta QSI pour une 183 si tu cherches plus de dynamique.

 

Les rendements quantiques sont assez similaires aussi.

 

L'intérêt de la CMOS est ailleurs : c'est la diminution du bruit de lecture quand on augmente le gain, pratique pour les objets faibles à faible dynamique, comme on a en bande étroite.

 

Et le prix évidemment

 

Et la vitesse, car une CCD doit être lue très lentement pour garder un bruit de lecture faible.

 

 

 

Modifié par olivdeso
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à tous

 

pour moi qui observe dans un site avec un fond de ciel trés important (milieu sub urbain) les CMOS (ASI 1600) me posent des problemes à cause de leur dynamique . La dynamique étant associée à la capacité de stockage qui est directement proportionnelle à la taille du pixel. Donc un des probleme (dans mon cas avec de longues focales) est liée uniquement à la taille du pixel donc capacité de stockage du puit et surechantillonnage.

Voici un graphique pour illustrer le probleme:

la courbe rose represente le remplissage du puit en electrons en fonction du temps de pose . La courbe bleu le signal utile de l'étoile la courbe verte le bruit ici dominé par le bruit de photons du fond de ciel.

La courbe rouge est le rapport S/B, l'etoile est detectée lorsqur le rapport S/B=3 

Pour le capteur 12 bits la dynamique est fixée à 100 et à 1600 pour le capteur 16 bits

on voit que le capteur 12 bit sature en 100s et n'est pas capable de detecter l'etoile alors que le capteur 16 bits la detecte en 800s de pose

 

detectivite_1.jpg.f4e71465d922fcea7aa17c49b01cebf6.jpg

 

Dans le cas d'une etoile 5 fois plus brillante le capteur 12 bits la detecte en 40s

 

detectivite_2.jpg.690c63df4e75e9d3a1f70080cebe8102.jpg

 

maintenant la question est de savoir si en accumulant 16 images 12 bits je peux detecter mon étoile dans le premier cas

c'est ce genre de manip qu'il me parait interessant de faire. Je ne sais pas à partir de quel rapport S/B on ne detecte plus rien meme en accumulant les poses

 

je n'ai pas pris en compte dans ce model le bruit fixe du CMOS qui est abscent du CCD ni le bruit de numerisation qui n'est pas completement negligeable par rapport au bruit de lecture

Malheureusement le binning ne resoud pas tout avec les CMOS (on gagne un facteur 2 sur le RSB mais pas 4 comme avec les CCD)

Sous un ciel de bonne qualité les CMOS sont trés bon

exemple M55 image gauche CMOS image de droite CCD en namibie

M55_trt_stacked.thumb.jpg.9768e0efb3689273f8e3b212802319a2.jpg

 

jean

Partager ce message


Lien à poster
Partager sur d’autres sites

@jean dijon: "maintenant la question est de savoir si en accumulant 16 images 12 bits je peux detecter mon étoile dans le premier cas "

 

Et bien c'est justement le test que tu dois faire. Tu verras qu'avec un capteur qui a 1.5e de bruit de lecture, des que tu as passé le seuil d'un bruit de fond de ciel largement supérieur au bruit de lecture, alors tu peux additionner sans probleme et tu auras ta détection.

Biensur à capteur équivalent coté QE, dimension des pixels...

Exemple avec un T520 au Chili, et une petite 1600MM, nous obtenons mag 27 sans probleme avec environ 10h de poses. Donc on détecte… et nous ne sommes pas limité par le fractionnement en poses de 5min.

 

La seule différence entre un ciel de Namibie et un ciel de ville, c'est que le seuil d'un bruit de fond de ciel largement supérieur au bruit de lecture, est diffèrent. En ville il peutetre de quelques sec, alors qu'il peut etre de plusieurs min en Namibie. Au final, si tu dois avoir 3mag e difference a cause de la polution lumineuse, elle sera toujour la quelque soit le type de capteur.

Enfin, les capteurs 12 bits vont disparaitre dans les mois et les années a venir. Sony ayant sorti des capteurs BSI en 16 bits.

 

Amitiés,

Laurent Bernasconi

 

Modifié par Laurent51
  • J'aime 2
  • J'adore 1

Partager ce message


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

avec un T520 au Chili, et une petite 1600MM, nous obtenons mag 27 sans probleme avec environ 10h de poses.

27 ! Pfiou je ne savais pas que vous montiez aussi haut. C'est impressionnant. C'est en ordre de grandeur la magnitude limite du survey LSST à terme. Bon vous n'allez pas vous taper tout le ciel alors que lui si, mais quand même ! 

  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci pour vos différents éclairages théoriques, très instructifs! :)

 

Le 09/10/2019 à 10:38, jean dijon a dit :

maintenant la question est de savoir si en accumulant 16 images 12 bits je peux detecter mon étoile dans le premier cas

c'est ce genre de manip qu'il me parait interessant de faire. Je ne sais pas à partir de quel rapport S/B on ne detecte plus rien meme en accumulant les poses

C'est noté! A diamètre et échantillonnage équivalent, ce n'est pas évident à mettre en oeuvre. Mais je l'ai déjà fait, pourquoi ne pas recommencer? ;)

 

Le 08/10/2019 à 04:44, olivdeso a dit :

Ce qui compte c'est le rapport signal à bruit.

Je me suis donc remis aux mesures sur les images de même échantillonnage, même jour, même temps de pose (elles sont ici en .fit, clic droit puis "enregistrer sous") en prenant le rapport entre la valeur moyenne d'une "nébulosité" et le bruit du fond de ciel (image ci-dessous pour bien voir de quoi on parle).

Voilà les résultats :

asi183 g0 1x9mn : rsb = 16

asi183 g111 9x1mn : rsb = 24

asi183 g111 3x3mn : rsb = 23

asi183 g270 9x1mn : rsb = 24

asi183 g270 27x20s : rsb = 20

qsi690 0.36e-/adu 3x3mn : rsb = 31

(qsi690 0.16e-/adu 3x3mn : rsb = 24) un autre soir

 

Nathanaël

rsb-neb-7331.jpg

 

 

Modifié par T450
erreur de frappe à gain 0 : 1x9mn pas 9x1mn

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, T450 a dit :

asi183 g0 9x1mn : rsb = 16

asi183 g111 9x1mn : rsb = 24

asi183 g111 3x3mn : rsb = 23

asi183 g270 9x1mn : rsb = 24

asi183 g270 27x20s : rsb = 20

Bonjour Nathanaël

tes mesures on tendance à montrer que l'empillement d'un nombre important d'images diminue le rsb, pour le gain 0 le faible rsb  provient sans doute du bruit de lecture qui est de 3e contre  2.2e pour g=111

je suis curieux de voir ce que cela donnerais avec des poses plus courtes 5s par exemple

 

Il y a 5 heures, Laurent51 a dit :

Exemple avec un T520 au Chili, et une petite 1600MM, nous obtenons mag 27 sans probleme avec environ 10h de poses. Donc on détecte… et nous ne sommes pas limité par le fractionnement en poses de 5min.

 

Bonjour Laurent,

j'ai fait tourné mon modele de CCD avec tes chiffres pour un fond de ciel mag 22.8 (qui est le minimum theorique) et une turbulence de 1" d'arc j'arrive à des chiffres tres proches de ceux que tu indiques pour une 1600MM detection de magnitude 26.5 en 10h (rsb 3)

Je pense que c'est quand meme un exploit!  un grand bravo :):)

Voila la simulation

5d9e0533b6ac5_maglimiteT520.jpg.d5c30e08e05d5da5bfa41084ec5641cc.jpg

 

jean

  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 11 minutes, jean dijon a dit :

pour le gain 0 le faible rsb  provient sans doute du bruit de lecture qui est de 3e contre  2.2e pour g=111

Oui, d'autant plus que j'ai fait une erreur de frappe, c'est 1x9mn pour gain 0 désolé! je rectifie.

Nathanaël

Partager ce message


Lien à poster
Partager sur d’autres sites

Eh bien chapeau les gars ! c'est super de pouvoir vous lire...même si ça me dépasse un peu !

Ce serait bien si de tout ça on pouvait en créer un tableau (Excel ou autre) où en insérant certains  paramètres fixes et/ou variables on pourrait en tirer des indications déduites pour tirer le meilleur compromis de chaque situation sur  différentes cibles...

jean Marc

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, jean dijon a dit :

j'ai fait tourné mon modele de CCD avec tes chiffres pour un fond de ciel mag 22.8 (qui est le minimum theorique) et une turbulence de 1" d'arc j'arrive à des chiffres tres proches de ceux que tu indiques pour une 1600MM detection de magnitude 26.5 en 10h (rsb 3)

Je pense que c'est quand meme un exploit!  un grand bravo :):)

 

Et bien, Merci pour cette analyse qui montre une belle complémentarité entre l'expérience et la théorie . Ca fait plaisir à voir!

Bravo!!!

 

Laurent Bernasconi

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 57 minutes, JML a dit :

Ce serait bien si de tout ça on pouvait en créer un tableau (Excel ou autre) où en insérant certains  paramètres fixes et/ou variables on pourrait en tirer des indications déduites pour tirer le meilleur compromis de chaque situation sur  différentes cibles...

jean Marc

bonsoir jean marc

 

voila le fichier excel tu peux t'amuser

maglimite_CCD_comparaison2.xls

 

les explications et le mode d'emplois

http://www.jeandijon.com/bruit CCD.htm#Bruit et magnitude limite des images CCD

 

jean

  • J'aime 2
  • Merci 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci jean, je vais tripoter ça moi aussi !

jean Marc

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