Discret68

Le résultat est prometteur. Je parlais justement de la capture en poses courtes sur ciel profond à un astram qui veut faire du planétaire et possiblement, du CP. Tes images tombent à pic. Question : qu’est-ce qui fait que la moitié des poses n’ont pas été retenues ?

Sur le site HEAVENS ABOVE, tu peux revenir sur les jours passés. Tous les satellites ne sont pas disponibles, mais il y a les plus lumineux. J’ai fait un test en mettant la date au 30 septembre et le tableau s’est mis à jour : https://www.heavens-above.com/AllSats.aspx?lat=48.0811&lng=7.3604&loc=Unnamed&alt=0&tz=CET Il faudra que tu mettes à jour les coordonnées de ta localisation et la date recherchée.

Salut @laurent5213 Je partage tout à fait les propos de Ney. Juste quelques compléments par rapport à tes dernières questions. Sur le site de Christophe Pellier, tu t'inscris sur cette page https://www.planetary-astronomy-and-imaging.com/reussir-images-planetaires/ et tu pourras charger un ouvrage qui apporte des éléments concrets sur le planétaire. Notamment par rapport à la question que tu poses sur la taille des photosites de la caméra. Tu découvriras dans ce document qu'il y a une relation entre taille des pixels de la caméra. En pratique, il faut viser un rapport f/d global de 5 fois la taille des photosites. Pour une caméra qui a des pixels de 2,9 microns, la rapport f/d global doit être de 2,9 x 5 soit 14,5. Pour en avoir discuté avec Christophe Pellier, lorsqu'on arrive pas exactement au bon rapport f/d, il est plutôt préférable de retenir un rapport f/d supérieur. Mais bon, ce n'est pas ça qui va faire basculer d'une manière drastique la qualité des images. Du moment qu'on se situe dans la zone, c'est tout bon ! Dans ton cas, il est préférable de faire du planétaire avec le newton, plus l'ouverture est grande, meilleure sera la résolution de l'image. Il est possible également d'en faire avec ta lunette. Sur une monture équatoriale, c'est plus facile pour faire du suivi qu'avec le dobson ! Et avec ta barlow actuelle de 2x, ça ira très bien avec une caméra ayant des photosites de 2,9 microns. Avant d'investir dans une barlow 3x, tu peux très bien faire des essais avec ton newton et ta barlow 2x. Tu verras si tu arrives à suivre la cible avec le dobson. Ton newton a un rapport f/d de 1200/254 soit 4,7. Avec ta barlow de 3x, tu arrives à rapport f/d global de 4,7 x 3 = 14,1. En appliquant la recommandation de Christophe Pellier, la taille préconisé pour les photosites serait de 14,1/5 soit 2,82 microns. La taille approchante est 2,9 microns, comme l'ASI224MC que cite Ney. je te laisse faire le calcul pour ta lunette. Coté choix, il n'y a pas que ASI, il y a d'autres constructeurs. Si tu regardes par exemple chez Player-One https://player-one-astronomy.com/planetary-camera/ , il y a le modèle Neptune C-II qui est certes un peu plus chère que l'ASI224MC, avec des photosites de 2,9 microns, mais qui offre de meilleures performances. Un capteur plus grand et surtout, une vitesse d'acquisition accrue. La taille de ce capteur est intéressante pour faire de l'imagerie lunaire. La surface captée est plus importante qu'avec l'ASI224MC. Pour du planétaire, il est possible de réduire la taille de l'image (du ROI comme on dit : Region Of Interset). On peut par exemple passer la taille des acquisitions de la taille du capteur (2712×1538) à une taille très réduite (640x480 par exemple), ce qui permet d'augmenter d'une manière très importante la vitesse de capture des images. Il faut aussi l'ordinateur qui permette de suivre la cadence. De toute façon, en planétaire, vu les instruments qu'on utilise, on n'a guère besoin d'un capteur de grande taille. Néanmoins, pour faire du CP, c'est mieux d'avoir un capteur plus grand afin de disposer d'un champ plus important. Je viens justement de commander une Neptune C-II directement chez Player-One. Elle est à 329$ et elle est arrivée en 5 jours, et sans frais annexes (douane, ...). Sinon, il y a également le modèle Mars C-II qui est à 299$ et qui est l'équivalent coté capteur de l'ASI662MC avec une même taille de photosites (2,9 microns) et un capteur un peu plus petit (1920 x 1080 au lieu de 2712 x 1538 pour la Neptune C-II, ce qui fait une surface double de la Mars C-II, intéressant en ciel profond). L'intérêt que je vois avec une caméra de ce type (non refroidie et d'un tarif "raisonnable") est de pouvoir faire un peu de ciel profond en utilisant la technique dite de Lucky Imaging (capture ciel profond en poses courtes). Je te laisse le soin de faire quelques recherches sur le sujet si cela t'intéresse. Ah ça, tu vois, je n'y crois pas beaucoup 😃. Je pense au contraire que tu viens d'ouvrir la boite de Pandore. Les questions vont fuser !😉 JP

Pour tout ce qui est satellites (y compris l’ISS), tu as ce site riche en information temps réel et à venir : https://www.heavens-above.com

Effectivement, j'ai fait l'amalgame entre tes propos de la page 1 de la discussion sur les filtres et les 2 scripts de Siril « Couleur_Extraction_Ha » et « Couleur_Extraction_HaOIII » qui comme leur nom l'indique permettent d'extraire le Ha et le OIII pour faire principalement du HOO. D'où la 1ère question que je m'étais posé vis-à-vis du NB3 et de l'extraction du SII. Avec quoi l'extraire ? C'est en regardant la longueur d'onde du SII que je me suis rendu compte qu'elle est très proche du Ha. La 2ème question que je m'étais posé, c'est comment fonctionne le script « Couleur_Extraction_Ha », et est-il compatible avec l'extraction du SII ? Je me disais bien que ce script ne pouvait que séparer les 3 couleurs de base RVB. Je ne connais pas de process informatique qui permettent d'extraire une longueur d'onde au choix. Donc, en décortiquant les 2 scripts Siril avec la documentation à disposition, j'ai vu qu'une des commandes utilisées avait bien pour objectif d'extraire les couches R et VB. Ma conclusion première était finalement de dire que le script Ha permet également l'extraction du SII ! Mais je souhaitais en avoir la confirmation. Je ne sais pas ce que tu en penses, mais il serait peut-être intéressant que dans ta conclusion de la page 1, tu mettes une petite phrase concernant le mode d'extraction des différentes couleurs pour faire du HOO et du SHO. En quelque sorte, une rapide synthèse de ce que tu as écrit en début de page 9 👍

J'ai lu le post, mais pas forcément l'intégralité des commentaires. C'est d'ailleurs par rapport à ce que tu as écrit en début de discussion que je pose ma question car à ce moment, tu faisais bien référence au HOO sur une base caméra couleur, mais pas sur du SHO. En relisant le poste depuis la fin vers le début, j'ai effectivement trouvé ta réponse en début de page 8 sur la construction du SHO 👍 OK, je ferai attention. Et par rapport à l'autre voie qui est de pré-traiter séparément les 2 séries d'images faites avec les filtres correspondant et en faisant une extraction RVB sur chaque pour composer les différentes couches SHO, qu'en penses tu ? Cette solution me paraissant optimale (à priori) pour utiliser la totalité des pixels disponibles .

Suite à divers questionnements d'astrams désirant motoriser le toit de leur abri, j'avais mis ces explications justement pour expliquer comment dimensionner une motorisation pour toit roulant. Entre ceux qui veulent installer un moteur de 3kw et ceux qui pensent qu'un moteur de jouet peut aller, il est bon à mon sens, d'apporter une méthode simple qui peut éviter les déconvenues 😚

Pour la bonne et simple raison que ça ne faisait pas partie de la question posée. De plus, Gérard ayant fait clairement le choix du moteur à utiliser et de son mode de pilotage, inutile de revenir sur la détermination de la motorisation puisque c'est acté. Et comme toutes les questions que j'ai posé n'ont amené aucune réponse, inutile pour moi de poursuivre sur ce sujet pour lequel effectivement, je n'ai absolument pas répondu à la question initiale.

Tu aurais pu mettre directement le lien pour la méthode que j'avais présenté : http://astrowick.fr/index.php/observatoire/motorisation-toit 😜 Il faut juste un renvoi supplémentaire par rapport à la rotation de la coupole.

Bon, Gérard, tu peux constater qu'on a bossé sur ton sujet avec Ney 😎

L’encodeur absolu, c’est bien car il n’y a pas d’équivoque pour la position dans laquelle il se trouve. la problématique se situe au niveau de son positionnement dans la coupole. Cette dernière ne dispose pas d’un axe central comme une monture. On ne peut pas fixer l’encodeur directement à la coupole. Il faudrait le positionner en périphérie, mais il y a la nécessité de faire une réduction pour obtenir une rotation d’encodeur pour une rotation de coupole. Pas simple. Lorsque je parlais de codeur simple, je pensais à un capteur photoélectrique avec un disque à trous qui permet d’encoyer des impulsions selon la rotation.. Par exemple, ce système mais avec un disque possédant moins de trous : https://fr.aliexpress.com/item/32841368348.html Si on part sur une coupole de 2,50m de diamètre, cela nous fait une périphérie de 7,85m. Vu que le moteur à Gérard a un pignon de 9 dents pour chaine de 1/2 », la chaine qui serait fixer en périphérie de la coupole aurait 785/1,27 soit 618 maillons. Sur la base du pignon de 9 dents, il faut 618/9 soit 69 tours de pignon pour une rotation complète de la coupole. Si on prend un disque avec 6 trous, cela nous donne 414 impulsions pour un tour de coupole soit une résolution de 0,87° par pas. La Terre faisant 1° toutes les 4 mn, il faut faire tourner le moteur de 1/6 de tour toute les 4 minutes. Vu que la vitesse de rotation est de 309tr/mn soit 5,15 tours par seconde à la tension nominale, il faut le faire tourner pendant 1/5,15/6 soit 0,03 secondes. Impossible avec un moteur tournant à cette vitesse, sachant qu’il faut attendre l’impulsion pour arrêter le moteur. A minima, il faut faire chuter la vitesse de rotation pour pouvoir disposer d’un minimum de temps pour faire tourner le moteur et gérer son arrêt. Je ne sais pas jusqu’à combien on peut descendre en vitesse de rotation en diminuant la tension d’alimentation. Avec une alimentation en PWM, il se pourrait qu’on puisse descendre assez bas. Mais est-ce que ça sera suffisant, je n’en sais rien. J’aurais donc tendance à dire que ce moteur n’est pas vraiment adapté pour la coupole.

Pétard !!!! Je sais le faire sur un ordi via les drivers ASCOM, mais si Gérard veut un système autonome avec l'arduino, c'est râpé ! je ne le pense pas car même si on envoie des impulsions via un pont en H au moteur, on ne maitrise pas la vitesse. Le moteur peut tourner trop ou pas assez vite, et au bout d'un moment, Gérard risque de faire des darks 🤕. Ce n'est pas la même chose (plus facile) que d'envoyer des impulsions sur un moteur pas à pas. En tout cas, moi je ne sais pas comment faire. Je réfléchis à voix haute car une autre solution existe et est totalement autonome. Je m'appuie sur le fonctionnement de la motorisation des fourches MEADE (j'ai un RCX400 10"). Sur les 2 axes, c'est un moteur à courant continu qui est utilisé (eh oui !). A priori, ce n'est pas précis du tout ! Sauf qu'en bout de chaque moteur, il y a un codeur qui permet de mesurer précisément l'angle de rotation. L'alimentation du moteur est régulée en fonction de l'analyse des impulsions venant du codeur. Donc, pour la coupole, on peut imaginer un codeur simple (et pas cher, placé au niveau du pignon du réducteur) qui permet d'envoyer des impulsions sur une entrée de l'arduino ou un encodeur qui permet par exemple de définir 16 positions pour un tour de pignon. En fonction du comptage des impulsions ou de la mesure de position angulaire du pignon, on peut calculer la position de la coupole par rapport à une position park et réguler la vitesse du moteur ou l'angle de rotation en mode suivi. Il faut bien sûr connaitre la réduction du système de transmission complet pour étalonner la boucle d'asservissement.

Ca peut ne pas être nécessaire. Si le cimier a une ouverture suffisamment large, la coupole peut opérer une rotation d’un angle donné tous les X temps qui dépend de la différence de largeur du cimier par rapport au diamètre du télescope. Cette solution permet d’éviter l’asservissement direct en vitesse de la coupole. Quelque soit la solution retenue, il faut arriver à synchroniser (en permanence ou périodiquement) la rotation de la coupole. C’est un peu le problème avec un moteur à courant continu dont on ne maîtrise pas avec précision la vitesse de rotation. Récupérer les coordonnées de pointage de la monture.n’est pas trop difficile, puis une conversion des coordonnées en altaz pour récupérer l’azimut, c’est facile. Le problème à mon sens est de récupérer la valeur de l’azimut du cimier pour synchroniser le tout. Bref, j’aurais plutôt tendance à proposer une motorisation à base de moteur pas à pas avec une transmission ad’hoc et un driver qui peut cette fois ci se piloter avec précision par un arduino. Et là, oui, rotation continue. Question complémentaire pour Gérard : Souhaites tu que l'arduino soit totalement autonome pour piloter la coupole ou peut-on ( ou doit on) imaginer que l'arduino est lui même piloté par un programme sur ordi ?

Salut Gérard. Hormis la mise en route et l’arrêt du moteur, veux tu également pouvoir modifier la vitesse par l’Arduino ? Dit d’une autre façon, admettrais tu de régler la vitesse par potentiomètre et enclencher/arrêter le moteur et son sens de rotation par Arduino ? En regardant les caractéristiques du moteur, si j’ai bien compris, la vitesse de rotation du moteur en sortie de réducteur est de 309 tr/mn (3000/9,7). C’est bien cela ? Quel est le diamètre de la coupole ? Concernant la variation de vitesse, quelle plage souhaites tu ( min et Max) pour le moteur ou pour la coupole ? Vu que c’est un pignon pour chaîne en sortie de moteur, une chaîne est fixée sur la coupole ? Ou alors, il va y avoir un autre système de transmission ?

Tu as raison, mais je voulais y aller par petites étapes 😃 Ça rentre dans ce que j'appelais vignettage mécanique en début de discussion, sachant qu'une bague M42 fait 37 ou 38mm de diamètre intérieur, on "mesure" bien l'impact de ce diamètre par rapport à la diagonale du capteur FF. Les flats dont je présentais l'analyse CCDi avaient été réalisés avec des bagues M48 (diamètre intérieur 43mm). Le vignettage mécanique est de fait un peu réduit, mais quand même présent. Mais à la base, c'est surtout la physionomie de la perte de lumière sur les bords longs du capteur qui m'interpelle, d'autant que ce n'est probablement pas dû au montage des bagues car on pourrait visualiser ce problème d'une manière concentrique sur le flat.

Ah oui !! Bon, de loin, c'était vraiment dur de voir ce que c'est. Pour tes flats, l'analyse CCDi montre la même courbe que précédemment : Il y a toujours les bords longs qui ont un drôle d'aspect. Je te propose un nouveau petit test complémentaire. Tu prends ton boitier seul (sans accessoire monté, pas de bague T ni le reste). Tu prends une photo d'une zone blanche (feuille de papier, plafond, ...) en ne saturant pas l'image. Comme ça, on pourra voir si cette problématique est du coté APN ou coté accessoires astro.

La difficulté à mon sens est que le collage tienne dans le temps. Avec les variations de température et d'hygrométrie, pratiquement tout ce que je colle .... finit par se décoller avec le temps. Je fais surtout allusion aux pattes de fixation avec adhésif pour y fixer les câbles. Quel que soit le modèle et la provenance, ça finit par se décoller rapidement. Au début je passais chaque fil sur le chant d'une branche d'araignée et je l'avais fixé par une bande de scotch noir sur toute la longueur de chaque branche et ça tenait pas mal. 2 branches sont finalement équipées. Pour les profilés en H (noir ou blanc), on en trouve dans certains magasin de bricolage. Des modèles de plus petites sections sont utilisés en modélisme sous la marque Evergreen. La solution à retenir peut aussi dépendre de l'épaisseur des branches d'araignée.

Bonjour à tous Je me pose quelques questions concernant le fonctionnement des scripts « Couleur_Extraction_Ha » et « Couleur_Extraction_HaOIII » dans Siril. Ces 2 scripts sont notamment utilisés pour la construction d’images HOO à partir d’une image couleur. Avant de poser mes questions, voici ce que j’ai compris du fonctionnement de ces scripts, ce qui a tendance à confirmer ce que je pensais notamment de l’extraction de couches sur des images prises avec des filtres multibandes. Dans ces 2 scripts, il y a une phase de pré-traitement des brutes que je laisse volontairement de coté pour ne m’intéresser qu’à la phase primordiale ; l’extraction proprement dite des couches Ha et de l’OIII. Ces 2 scripts font appel aux commandes globales « seqextract_Ha pp_brute » et « seqextract_HaOIII pp_brute ». En consultant la documentation Siril, ces 2 commandes s’appuient sur les commandes « extract_Ha » et « extract HAOIII » A la lecture de leur définition et sur la base du positionnement de ces 2 gaz sur le spectre des couleurs , je comprend que l’extraction s’effectue sur la base du pixel rouge de la matrice de bayer pour le Ha et sur une extraction des 3 autres pixels (le bleu + les 2 verts) pour l’OIII. Pour cette dernière extraction, une moyenne des 3 couleurs est effectuée. Je ne vois effectivement aucun autre moyen informatique permettant de discriminer les couleurs en fonction de la longueur d’onde des différents gaz. Ces 2 scripts fonctionnent bien sur la base de l’utilisation (par exemple) de filtres IDAS NB1 et NB2. Si on souhaite réaliser des images HOO, on peut s’arrêter à cette étape. Jusque là, ais-je une vision correcte des choses ? Par contre, pour construire une image (pseudo) SHO, il faut récupérer la couche du soufre. En complément d’un filtre NB1, j’ai monté un NB3 dans ma RAF. Ce filtre permet d’extraire le OIII et le SII. Vu que la longueur d’onde du SII est très proche de celle du Ha, j’en déduis que l’utilisation du script « Couleur_Extraction_HaOIII » peut s’appliquer au NB3 pour en extraire l’OIII et le SII. En fait, ce script pourrait également se nommer « Couleur_Extraction_SIIOIII » pour un filtre NB3. Les 3 gaz étant séparés, il devient manifestement possible de créer une image SHO. Dans une deuxième réflexion, je me dis que si les scripts font de l’extraction de couleurs RVB, pourquoi ne pas partir d’images pré-traitées sur la base respective des filtres NB1 et NB3 pour faire une extraction RVB sur chaque image. J’associe ensuite les différentes couches des 2 filtres en fonction de la longueur d’onde des gaz pour obtenir les 3 couches qui vont être affectées aux RVB pour obtenir du SHO. Bien évidement, il faut ré-aligner les différentes couches en provenance des différents filtres et ajuster les niveaux. L’avantage à première vue de cette méthode est de récupérer la totalité des pixels des images des 2 filtres : le Ha provient des pixels rouges du NB1, le OIII des pixels verts et bleus des NB1 et NB3 et le SII des pixels rouge du NB3. Est-ce que ce scénario tient la route ? Il y a peut-être des effets « pervers » auxquels je ne pense pas. Merci à vous JP

Chez moi non plus, je ne vois pas de trame sur l'image téléchargée de 139Mo et j'ai balayé l'image complète à l'échelle 1. C'est vrai qu'en grand, cette image est superbe ! Il y a plein de "petites" choses à découvrir. Ce doit être la conversion en JPG qui met le brin !

Une solution que j’ai adopté sur mon newton est d’isoler électriquement 2 branches d’araignée afin d’y faire passer la tension d’alimentation de la résistance chauffante du secondaire. De cette façon, aucun câble ne passe dans le champs. Autre solution, utiliser 2 conducteurs simples (fil isolé) de faible diamètre, car l’intensité qui passe est faible, qu’on maintient au niveau d’une branche d’araignée à l’aide d’un profilé en plastique en forme de H. On trouve ces profilés dans certains magasins de bricolage. On coupe le profilé à la longueur de la branche d'araignée, on l’encastre sur la branche d’araignée et on passe les 2 fils dans la 2ème gorge. Pour la section des fils, si on part sur une résistance de 5W sous 12V, ça fait une intensité de moins de 0,5A. Une section de fil de 0,2mm2 est suffisante. Rien n’empêche de prendre un peu plus gros pour que ça serre dans la gorge pour assurer le maintien des fils.

L’image est belle avec un bon rendu des couleurs, mais il y a une trame verticale qui est légère mais visible, notamment au niveau des zones lumineuses.

Dans cette guerre de religion qui n’en est pas une, si vous aviez testé Astro Pixel Processor, vous ne seriez pas en train de vous « déchirer » entre Siril et PI pour le pré traitement Surtout pour l’extraction du gradient que je trouve le plus performant des 3 logiciels. Bon, aller, soyez rassuré, j’utilise aussi Siril et PI 👍

@julienESP n'étant pas moi-même un cador dans le traitement des images, je vais en profiter pour tester tes "directives" sur mes images 🤕

Merci de nous prévenir, j'ai réactivé l'antivirus sur mon ordi, des fois que tes messages soient contaminés 😃 Perso, je pense que c'est suffisant. Entre 1/2 et 3/4, ça va le faire ! On peut penser que ton miroir secondaire n'est pas correctement centré par rapport au PO. Il y a en fait 2 centres à prendre en compte au niveau du miroir secondaire. Le centre géométrique, qui correspond au centre mesuré du grand axe et du petit axe du miroir et il y a le centre optique, qui est décalé par rapport au centre géométrique d'une cote qui dépend du rapport f/d du télescope : http://serge.bertorello.free.fr/calculs/posplan.html Dans ton cas, il doit être de 5mm. Si le secondaire n'est pas optiquement correctement centré, tu peux avoir un décalage de la plage de luminosité des flats .... et des brutes ! Un défaut de collimation ou une présence de tilt peuvent également générer un défaut de centrage de la plage de lumière. Ce qui me gêne plus sur l'image de l'analyse CCDi, c'est la forme du vignettage sur les bords longs du capteur. La courbe de luminosité est complètement perturbée et perd sa concentricité. Je ne vois pas d'où cela peut provenir, d'autant que tu n'as pas de filtre. Ça pourrait être le cas avec un filtre "clippé" dans le boitier de l'APN, mais tu n'as pas de filtre ! Et on retrouve bien cet assombrissement sur tes brutes. Vu que cette zone est bien parallèle au bord du capteur, je pense que c'est au niveau du boitier qu'il faut chercher le coupable. Par acquis de conscience, tu pourrais tourner ton APN d'un angle quelconque (sauf 180° !) pour voir si ce défaut évolue. Mais vu "l'excellence" du parallélisme actuel, ça serait vraiment étonnant que ça bouge. Sur la photo de ton tube (un peu petite pour voir précisément le montage), je vois quelque chose de cylindrique juste en dessous de l'APN. Qu'est ce ? Pourrais tu mettre une photo du train optique (du PO à l'APN) assez grande de manière à bien voir le montage ? En tout cas, ton image de M31 a quand même gagné en qualité 👍

Pour compléter le choix plus adapté d'un capteur de plus petit format (APS-C pour une 2600), voici une comparaison du vignettage entre capteur FF et APS-C derrière un correcteur 2" : Pour le capteur FF, la perte de luminosité est de 68% dans les angles, valeur très proche de celle qu'on mesure sur tes flats réels. Par contre, pour le capteur APS-C, la perte tombe à 18%. Valeur beaucoup plus facile à corriger. Le cercle pleine lumière (dans une configuration correcteur 2") est de 22mm (2 x fois l'offset - la distance par rapport au centre du capteur). Mais avec la taille du capteur FF, la pente est longue et rude ! Soit dit en passant, cet exemple n'a pas pour but de te faire acheter un autre capteur, mais juste pour te montrer à quel point, un capteur FF n'est pas évident à gérer sur un newton avec correcteur 2". Comme joker0247, j'avais monté l'A7S, mais sur mon newton avec correcteur 2", c'était pareil qu'avec l'ASI2400 d'aujourd'hui, un bon 50% de perte dans les angles. Pour cette raison, j'ai passé toute la partie train optique en 3", ça va beaucoup mieux. Mais dans ton cas, ce n'est surement pas la bonne solution car cela te couterait beaucoup plus cher que le télescope lui-même.