Nathanael

cmos vs ccd : la dynamique

Messages recommandés

Il y a 13 heures, jean dijon a dit :

La dynamique étant associée à la capacité de stockage qui est directement proportionnelle à la taille du pixel.

 

Précision : la dynamique n'est pas uniquement liée a capacité de stockage. c'est un des 2 paramètres.

 

 Le bruit de lecture est tout aussi important puisque la dynamique est le rapport des 2 : capacité de stockage / bruit de lecture.

 

Surtout sur une cmos au bruit de lecture très faible.

Donc petits pixels certes, mais tout petit bruit de lecture aussi et au final la dynamique est tout à fait décente.

 

 

Partager ce message


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

Donc petits pixels certes, mais tout petit bruit de lecture aussi et au final la dynamique est tout à fait décente.

Salut,

Je ne comprends pas un truc:

-plus j'augmente  mon gain plus je baisse mon bruit de lecture sur ma 290mm (par exemple) mais ma dynamique degringole en même temps.

-mais tu dis que la dynamique est un rapport entre la capacité de stockage et le bruit de lecture. 

Donc ma dynamique augmente en baissant le bruit de lecture.

?

La capacité de stockage baisse aussi avec le gain ?

 

 

 

Partager ce message


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

La capacité de stockage baisse aussi avec le gain ?

Le full well baisse avec le gain (ci-dessous)

A mon avis, ça ne veut pas dire que la capacité de stockage physique baisse avec le gain, mais plutôt qu'on atteint la saturation du CAN (4096 adu) pour un plus petit nombre d'électrons.

Nombre d'adu sur l'image = nombre d'électrons x gain (adu/e-)

Si le gain = 1adu/e- (gain 111) tu atteins les 4096 avec 4096 e-

Si gain = 2adu/e- (gain 200) tu atteins 4096 adu avec 2048 e-

Donc en fait, ta dynamique baisse quand tu baisses le bruit de lecture, car le full well diminue beaucoup plus vite que le bruit de lecture.

Nathanaël

290-readnoise.jpg

Modifié par T450
  • J'aime 1
  • Haha 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Nathanaël et moi avons échangé nos caméras pour faire des tests. Les filtres sont les mêmes pour chaque image, Ha Astrodon 5nm ici pour mon cas. les deux images ont été faites avec une Lune bien présente, à 92.2% pour celle à la QSI/lunette 102 (cette nuit) et à 97.3% pour la 80ED/ASI183 le 15/9.
Comme j'ai un petit peu de mal avec les chiffres, les conversions, les bits à gauche et ceux à droite, je mets directement les images pour vous faire un avis. La seule chose commune au deux séquences est Melotte 15. Les images ne sont pas traitées, juste un stack par Sirilic en drizzle 2 et des niveaux étirés (STF sous Pix).
Mel15_QSIvsASI_full.JPG.23fd1f01d8c41a57bd6afb3d0ff11d2d.JPG

 

Mel15_QSIvsASI.JPG.6c80cbd86c30ce35b4046304c5f9b1cd.JPG

 

Mel15_QSIvsASI_Zoom.JPG.125fb51f41a22cb59d0f2d883420f5af.JPG


> A gauche, QSI690 (3,7 µm) + lunette 102/700 avec réducteur 0.8 (560 mm @ FD/5.6), 150 minutes par subs de 600", e = 1.36"/p. On fera abstraction de la forme des étoiles sur la 102 qui a un petit soucis optique ou de tilt avec son PO bas de gamme...
> A droite, ASI183 (2,4 µm) + lunette 80/500 au foyer (FD/6.25), 420 minutes par subs de 600", e = 0.99"/p
 
C'est le rapport des ouvertures et des échantillonnage de chaque setup m'a amené à empiler 150 minutes pour la QSI/Lunette 102 et 420 minutes pour l'ASI183/80ED afin d'avoir des images à peu près équivalentes.
 
La résolution est meilleure à la 80ED + ASI183 même si le diamètre la limite normalement à 1.5". Par contre, net avantage à la CCD en terme de bruit. Je ne sais pas si on peut comparer juste comme ça mais de toutes manières, il va clairement falloir poser plus avec l'ASI183 pour arriver au même niveau.

 

A mon avis, l'avantage pour la CCD de pouvoir faire une belle image SHO ou LRVB en une nuit est quand même un sacré plus, fenêtre météo courte ou en nomade par exemple. Un tube ouvert à 4 pour l'ASI183 serait très souhaitable et il faudrait faire une nuit en Ha ou L puis une autre nuit en SII-OIII ou en RVB. Un traitement minutieux est certainement aussi à prévoir. Deux approches selon les habitudes et possibilités de chacun mais au final les images sont plutôt sympa non ?

 

Bon, je me demande bien ce que ça fait une ASI183 sur un Newton 250 à FD/3.8 en H-SO sur 2 nuits ;)

 

  • J'aime 1
  • Merci 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Les comparaisons ne sont pas faciles à faire.

 

Franchement je préfère l'image de droite : plus fine et des étoiles plus faibles, étoiles brillantes moins saturées.

Il se peut que la CMOS avec des poses unitaires de 4 ou 5 minutes aurait donné au final moins de bruit ?

Sinon la comparaison aurait été directe avec une ASI1600MM et le même instrument : même taille pixel.

 

Il se pourrait aussi que le problème optique à gauche n'a pas permis un bon alignement des images

et que ça a pénalisé la résolution de la CCD...

 

Lucien

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci pour ce retour Jean-Marc :)

Le 11/10/2019 à 15:32, Jean-Marc_M a dit :

Deux approches selon les habitudes et possibilités de chacun mais au final les images sont plutôt sympa non ?

Oui, les résultats sont quand même très proches et permettent de belles images dans tous les cas :)

Mais cela confirme ce dont nous nous doutions déjà : le résultat à la 183 est plus bruité (passons sur le piqué pour lequel tu as donné une explication). Comme on est déjà bien au delà de l'influence du bruit de lecture en cmos (poses de 10mn), je ne comprends pas ce qui peut produire cet effet. Et rien de ce qui a été écrit sur ce fil ne peut l'expliquer sauf peut-être :

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

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

Mais je n'ai pas les compétences pour quantifier ces deux phénomènes. Je jette l'éponge! Place aux images! ;)

Le 11/10/2019 à 15:32, Jean-Marc_M a dit :

Bon, je me demande bien ce que ça fait une ASI183 sur un Newton 250 à FD/3.8 en H-SO sur 2 nuits

Et bien demande à la lune et aux nuages d'aller voir ailleurs, au vent de s'arrêter de souffler comme un dément, et je vais m'y atteler! :)

Nathanaël

  • J'aime 1
  • Haha 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Hello et merci pour ces tests :)!

 

Serait-il possible d'avoir accès aux version FULL en PNG ou JPG haute qualité?

Je serai curieux de voir comment réagit (je vais regarder les coins) le capteur IMX183 avec ses petits pixels de 2.4µm sur des F/D courts genre 4 ou inférieur!

 

Et en effet le prix à payer des petits pixels de la 183 est un temps de pose total plus conséquent pour lisser le bruit (idéalement 10h par couche narrowband qui servira de luminance et la moitié tjrs en bin1X1 soit 5H pour les couches en narrowband qui serviront à la couleur).

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Les filtres Ha sont de la meme marque? de la meme bande passante?

Y a t'il eu du ditter de fait lors des acquisitions?

Je pense que la somme des images n'est surement pas suffisante pour compenser la différence de diametre puis d'échantillonnage, en plus avec la pleine lune qui vient rajouter plein de bruit de fond de ciel. De plus, la lune ne devait surement pas etre a la meme distance de l'objet car les nuits d'acquisitions semble différentes.

D'un autre coté, on a une image vraiment plus détaillé, avec plein d'information en plus.

 

 

 

Modifié par Laurent51
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 11/10/2019 à 15:32, Jean-Marc_M a dit :

par subs de 600"

 

10 minutes avec le cmos !?  c'est le point qui me fait tiquer.

 

C'est pas comme une CCD, le courant de dark est plus important et va vite devenir le facteur limitant. 

 

En bande étroite, il faut augmenter le gain pour diminuer le bruit de lecture et poser plus court.

 

Et refroidir un max comme d'habitude en bande étroite.

 

La détectivité est quand même nettement meilleure sur l'image de droite. l'optique? la turbu? le suivi? 

 

Probablement qu'avec un petit coup de lissage, tu aurais la même chose que l'autre image au final...

 

c'est joli tout ca...

Modifié par olivdeso
  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut Nathanael

 

Citation

Oui, les résultats sont quand même très proches et permettent de belles images dans tous les cas 

Mais cela confirme ce dont nous nous doutions déjà : le résultat à la 183 est plus bruité (passons sur le piqué pour lequel tu as donné une explication). Comme on est déjà bien au delà de l'influence du bruit de lecture en cmos (poses de 10mn), je ne comprends pas ce qui peut produire cet effet.

 

Ok pour cette conclusion. 

Merci également à Jean Dijon pour son intervention.

 

Amicalement

 

Christian

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à tous,

Olivier, je te réponds ici pour ne pas polluer le post de Yoann

 

Il y a 5 heures, olivdeso a dit :

c'est relou à la longue vos histoires de ccd vs cmos...que c'était bien plus mieux avant...

Ce n'est pas du tout le propos :)

 

Il y a 5 heures, olivdeso a dit :

la vérité c'est que les 2 fonctionnent et qu'on fait de nouvelles choses avec les cmos, pour un budget moindre. chaque techno a ses avantages et ses défauts.

Mais question budget, y a pas photo, pour les capteurs petits et moyens du moins. 

Perso, je ne crois jamais avoir dit le contraire.

 

Il y a 5 heures, olivdeso a dit :

Vous êtes plusieurs à essayer de vous auto persuader à longueur de forum que la CCD c'est mieux que le CMOS.

A l'origine, cet été, j'ai fait un petit test parce que précisément, c'est le contraire qu'on entendait jusqu'ici sur le forum à longueur de temps : le cmos a enterré le ccd. Et bien si on regarde les performances sur le ciel, ce n'est juste pas vrai.

 

Il y a 5 heures, olivdeso a dit :

En plus vous ne pratiquez pas le cmos et vous vous faites un jugement très approximatif basé sur des bouts d'images pêchés ça et là, de caméras qui n'ont souvent rien à voir. Forcément ca fait réagir...

Alors là, je suis presque blessé (non je blague ;)) parce que quand on prend soin de monter 2 setups différents sur le même télescope la même nuit en tenant compte de l'échantillonnage etc... pour montrer des choses, c'est un peu plus que de "pêcher" des images ici ou là qui n'ont rien à voir. Et finalement, ces deux derniers mois, j'ai plus utilisé une cmos qu'une ccd. O.o:D

 

Il y a 5 heures, olivdeso a dit :

Je le vous dis amicalement, les gars vous vous gourez.

Ça je veux bien le croire, mais j'aimerais bien des arguments, des images, des mesures qui me fassent changer d'avis. Pour l'instant, on m'oppose seulement que les conditions de l'expérience ne sont pas bonnes, à chaque fois. C'est quand même pas bien compliqué de mettre deux caméras derrière un télescope et de prendre des images qui montrent que je me trompe. C'est même ce que j'essaye de faire depuis cet été, mais j'arrive pas à me montrer que je me trompe. :D Un petit coup de main?

 

Le 13/10/2019 à 22:20, T450 a dit :

Je jette l'éponge!

C'est pas gentil de salir la table, je suis obligé de la ressortir :D

 

Enfin, pour moi, jusqu'à ce qu'on me montre que l'IMX ne fait pas des images plus bruitées que l'ICX, je reste là-dessus et je renonce à me l'expliquer.

Et bien sûr, je ne veux pas dire qu'on ne peut pas faire de magnifiques images avec l'IMX ;)

 

Nathanaël

  • Merci 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Je crois que l'essentiel est là se faire une idée. Ensuite chacun de nous peut faire ses tests. Merci pour la démarche qui je pense fût chronophage...

et aux interventions des protagonistes.

;)

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Je n'ai lu qu'en diagonale ce post, mais je voudrais revenir sur le tout début, lorsque Nathanael vous faites des comparaisons sur une image de NGC7331. Il y a un vice car vous modifiez trop de choses simultanément, en l'occurrence, la caméra bien sur (c'est le but), mais aussi le télescope (modification de la focale), ce qui complique pas mal la situation. Je préfère travailler avec le même setup, même si l'échantillonnage sur le ciel change puisque la taille des pixels change aussi (voir plus loin).

 

On peut faire comme vous le présentez aussi, et c'est un bel effort expérimental. Ce que l'on peut noter c'est que le RSB est fort proche entre les deux jeux d'images, et il y a donc une équivalence en terme de détectabilité de mon point de vu (ce n'est pas le bruit seul qui compte ici). Ce n'est pas totalement surprenant à vrai dire. A iso échantilonnage sur le ciel, ce qui va compter c'est (1) le rendement quantique, (2) le bruit de lecture.

 

Je n'ai pas d'infos sur le rendement quantique du capteur CCD employé, mais je soupsonne qu'il ne doit pas y avoir un écart considérable (tout dépend en fait de l'endroit du spectre où on se trouve : actuellement en très gros, CCD meilleur dans le rouge, CMOS meilleur dans le bleu). Le bruit de lecture : bof, ici j'ai le sentiment que c'est le bruit de signal du fond de ciel qui domine, et que donc le bruit de lecture est plutôt secondaire. Laurent Bernasconi a bien souligné l'importance entre régime de bruit de photons et régime de bruit de lecture --- source de pas mal de confusion. Et là encore, à iso-échantillonnage sur le ciel, la différence de comportement des deux capteurs est faible.

 

Pour avoir une vision du vrai impact du bruit de lecture il faut travailler avec des signaux très faibles, comme cela est rencontré en spectro ou imagerie à très faible bande passante. Je vous suggère de consulter cette batterie de tests (en particulier en bas de page pour les gens pressés) sur la ASI183MM : http://www.astrosurf.com/buil/asi183mm/

 

Les images de Jean-Marc de vendredi sont interressentes car elles montrent relativement bien l'impact de la finesse des pixels des capteurs CMOS (mais dans ces données il y a un biais à priori lié à la qualité des setup, avec surement du chromatisme quelque part). Un critère un peu plus global en terme de détectabilité doit faire apparaitre l'échantillonnage. Bien que cela puisse être discuté, un critère de performance possible est RSB x p^2, avec p la taille linéaire physique des pixels. On voit que les petits pixels sont très vite désavantagés, c'est la surface qui compte en effet.

 

Bien sur, on peut binner (par logiciel actuellement) l'image issus du CMOS. Mais on sait que c'est moins efficace qu'en CMOS  : binner 2x2 un CCD fait gagné un facteur 4 en RSB, alors que binner 2x2 fait gagner un facteur 2 seulement. Mais même ce résultat est contestable en vérité. Comme je l'ai indiqué dans un autre post, il faut être plus malin que binner à l'ancienne les données CMOS, et profiter à fond des petites pixels. C'est ce que j'ai indiqué sur un autre post, et que je rappelle ici (voir la commande CMOS_FULL) : http://www.astrosurf.com/buil/UVEX_soft/

 

En s'adaptant correctement au sur-échantillonnage, les capteurs CMOS peuvent faire au moins jeu égal avec les CCD, même sur le terrain de jeu de ces derniers. Je suis certes le premier à attendre des CMOS avec de gros pixels (et la correction de quelques autres défauts, comme le bruit télégraphique et l'électroluminescence, meilleure capacité de c charge). Mais la difficulté et le trouble que l'on peut noter dans les commentaires, est qu'à tout point de vu, les CMOS actuels changent nos habitudes, y compris en terme de traitement d'image, une chose qui ne semble pas vraiment intégrée en ce moment. Ainsi, pour revenir aux premières images de Nathanael, il serait intéressent (1) de ne pas changer le setup (même focale), (2) faire le même temps de pose, (3) ce ramener au même échantillonnage sur le ciel ("/p) par un traitement adapté qui valorise le sur-échantillonnage conféré par les petits pixels du CMOS. Le résultat sera en réalité assez voisin de celui déjà affiché , car une fois de plus, le bruit de lecture semble compter à la marge dans ce document, mais dans certaines situations, le CMOS prendra alors le dessus.

  

Christian Buil

    

Modifié par cbuil
  • J'aime 4
  • J'adore 1
  • Merci 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci à Christian pour cet état de lieux. O.o

 

Oui, la comparaison d'un seul paramètre n'a pas vraiment de sens si l'on bouge tous les autres ou presque.

Et puis même si tous les paramètres étaient identiques dans les deux set-up, il faut faire attention aux conclusions.

Par exemple si l'on choisit des poses unitaires de 10 mn ou bien de 2 minutes, on peut aboutir à des résultats globaux différents parfois.

 

D'autre part et même si le bruit final était plus important mais que la détectivité et la finesse des images étaient meilleures,

faut-il juger sur le seul chiffre du bruit ?

 

On entend souvent dire que le bruit thermique des CMOS est supérieur à celui des CCD.

Cela semble se vérifier sur quelques modèles mais j'avoue ne pas savoir si on peut généraliser à tous les CMOS.

Par pallier ce problème, on recommande de refroidir davantage les CMOS en pose longue.

Et aussi de fractionner les poses vraiment longues.

Disons par exemple : des poses unitaires de 3 mn plutôt que 10 mn, pour donner des chiffres.

Le faible bruit de lecture se prête bien à ce jeu. Moins de contraintes de guidage, moins de conséquences si l'on perd quelques images...

 

Oui, les CMOS changent nos habitudes, du moins si on en avait.

Mais pas seulement, celui du choix des instruments optiques aussi.

Personnellement j'attends avec impatience un CMOS monochrome moderne avec des pixels de l'ordre de 8 à 10 µm,

et des prix pas trop délirants.

Comme quoi les lois de la physique ne peuvent pas être outrepassées par de (trop) petits pixels.

Une caméra avec une dynamique réelle de 14 ou 15 bits et une grande capacité de charge...

 

 

Lucien

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Désolé d’être basique mais de mon point de vue et sans avoir compris les détails techniques, j’ai envie de conclure que CMOS et CCD dans l’etat actuel du matériel disponible grosso modo c’est kif kif.

 

En tout cas je n’ai rien vu qui montre une monstrueuse différence entre les deux technos si on regarde les résultats et les analyses des cadors.

 

Ce post a pour moi le grand mérite de mettre ça en lumière.

 

Jean-Marc

Modifié par JMBeraud
Typo
  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Pour les deux images de Melotte 15, le filtre Ha utilisé est le même, un Astrodon 5nm.
La Lune était à peu près à la même distance de la cible sur les deux soirées et quasiment à la même illumination (15/09 et 11/10).
Par contre, la lunette de 102 a un principalement un problème de collimation et non de tilt comme je pensais. Ca ne m'arrange d'ailleurs pas trop tout ça puisque je ne sais pas régler le problème mais c'est une autre histoire...
Le suivi était correct pour les deux sessions par contre la turbu, je ne m'en souviens pas.

 

Il y a 2 heures, JMBeraud a dit :

En tout cas je n’ai rien vu qui montre une monstrueuse différence entre les deux technos si on regarde les résultats et les analyses des cadors.

Pareil pour moi.

Plutôt que de comparer les technos aux mêmes conditions ou similaire, je préférerais qu'on les compare chacun à leur optimum, cohérence du setup, méthode d'acquisition, de traitement etc.... Le but, en tous cas le mien pour de l'astrophoto, est de parvenir à sortir une belle image tout en passant un bon moment sous les étoiles.

Merci pour vos interventions qui vont me permettre d'ajuster quelques points :)

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 4 minutes, Jean-Marc_M a dit :

Plutôt que de comparer les technos aux mêmes conditions ou similaire, je préférerais qu'on les compare chacun à leur optimum,

 

Oui et quelques chose me dit qu’au final on aura la même conclusion.

 

il y a 5 minutes, Jean-Marc_M a dit :

Le but, en tous cas le mien pour de l'astrophoto, est de parvenir à sortir une belle image tout en passant un bon moment sous les étoiles.

Voilà qui est bien dit! D’ailleurs je languis le beau temps 😄.

 

JMarc

Partager ce message


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

 

On entend souvent dire que le bruit thermique des CMOS est supérieur à celui des CCD.

Cela semble se vérifier sur quelques modèles mais j'avoue ne pas savoir si on peut généraliser à tous les CMOS.

 

globalement oui, mais il y a des grosses différence (x10) d'un cmos à l'autre

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à tous et merci pour vos avis. :)

Le 16/10/2019 à 14:38, cbuil a dit :

vous modifiez trop de choses simultanément, en l'occurrence, la caméra bien sur (c'est le but), mais aussi le télescope (modification de la focale)

Si, à l'inverse de mon approche précédente, on considère que (compte tenu de tout ce qui a été dit et redit ;)) la différence de RSB (ici) ne peut pas être due au changement de caméra, on doit pouvoir conclure que cette différence provient de l'instrument? Et comme tout est rigoureusement identique (même le ciel) sauf 1- paracorr2 / asa0.73;  2- le rapport f/d, peut-on conclure, ou tout au moins envisager, que à diamètre et échantillonnage égal, le rapport f/d puisse avoir une influence sur le rsb?

Cela pourrait expliquer le "sentiment" assez partagé que les images "cmos" sont plus bruitées que les images "ccd" (à temps de pose égal) eut égard au fait qu'ayant des pixels plus petits, à échantillonnage égal, les "cmos" sont de fait utilisés avec des F/D plus petits (ou des diamètres plus petits mais dans ce cas on comprend mieux pourquoi le rsb diminue).

J'essayerai de faire un test là-dessus, mais j'ouvrirai le cas échéant un nouveau fil avec un titre différent, moins polémique ;)

Nathanaël

Partager ce message


Lien à poster
Partager sur d’autres sites

c'est le diamètre qui fait le RSB : donc il faut comparer à même diamètre.

 

Ensuite, il faut un temps de pose total égal = même nombre de photons collectés, donc même bruit photonique.

 

Si en.plus tu as le même échantillonnage, c'est parfait.

 

Par contre il faut des temps de pose unitaire nettement plus court avec un CMOS qu'avec une CCD.

 

Dans les 2 cas il faut adapter le temps de pose untitaire au bruit de lecture de la caméra : il faut ajuster le temps de pose de manière à au moins un rapport x3.5 entre

- le bruit de lecture (à peut de choses près le bruit d'un offset non prétraité avec le master offset. mais tu peux calibrer avec le master offset pour avoir le chiffre exact)

- le bruit du fond du ciel, dans une zone sans étoile ni pixel chaud.

 

Aussi il faut monter un peu le gain en narrow band sur une cmos pour diminuer le bruit de lecture. Surtout ne pas travailler à gain minimal en narrow band avec un cmos.

 

En gros avec une CCD Sony on aura un bruit de lecture de 5 e- et 1,5e- avec la CMOS.

On a donc un rapport x3.33 sur les bruits donc un rapport x11 sur les temps de pose unitaire entre CCD et CMOS.

 

Modifié par olivdeso

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