keymlinux

Si on enlève les problèmes déjà annoncés dus a l'absence de DOF, moi ce qui surprend c'est que sur un empilement de 36 images il y ait la trace d'um passage de satellite... Tu est sût de ton empilement ? De plus im me semble qu'empiler des images avec différents temps de pose/gains ce n'est pas la bonne façon de faire pour par exemple décramer le coeur d'une galaxie Normalement on fait un empilement séparé pour chaque temps de pose (donc en ayant suffisamment d'images pour chaque temps de pose), et on fusionne ensuite pour faire un semblant de HDR Un conseil, empile les 30 images de 180s gain 100 et pour le moment ignore les 6 autres Si l'image que tu pose est la version RVB alors c'est suspect, elle semble monochrome, tu a bien coché l'option debayer sous Siril ? (la camera 2600MC est une cam couleur) Cordialement

Bonjour, A une époque je me suis posé les mêmes questionnements, et je me permet de décrire ici les choix que j'ai retenus (et vous êtes libres de ne pas êtr en accord avec ce que je pense 😉) Quand j'ai commencé à pratiquer l'observation sur le terrain, je me suis contrait à ne pas utiliser de monture avec goto (ni même un simple suivi motorisé), parce que "le goto c'est la facilité" et cela ne permet pa d'apprendre le ciel. Rien ne vaut le saut d'une étoile à une autre avec un atlas sur les genoux (si vous avez l'impression que cela tient un peu de l'intégrisme anti GOTO c'est voulu 🙂 ). Et je ne regrette pas ce choix, mail il est vrai qu'il faut être motivé, car on galère pas mal à trouver l'objet tant recherché. Il st vrai que cela peut rebuter les débutants les moins passionnés (quoi, on a galère 2 heures pour trouver la galaxie tartempion et tout çà pour voir une pauvre tachouille floue ? et le matos fini sur le bon coin...) Par contre, dans le cadre d'une approche purement astrophotographique ce qui est important c'est de poser le maximum de temps pour emmagasiner du signal. Vu que la météo limite le nombre de soirées exploitables, vu que je dois faire 1h de trajet pour aller sous un ciel correct (pas exceptionnel, juste correct), vu que selon les saisons la nuit peut être courte, si je doit passer 2 heures à trouver l'objet recherché et à peaufiner le cadrage, et bien la session d'imagerie va se réduire à peau de chagrin. Et là je n'hésite pas comme certains l'on déjà exprimé ici à automatiser un maximum mon process d'imagerie. - la monture motorisée pilotée par un ordi (un raspberry pi) - utilisation de l'astrométrie pour améliorer la précision et le cadrage (pratique pour les cibles où il faut cumuler les sessions sur plusieurs nuits, pour retrouver le même cadrage) Voila, ma pratique de l'observation et de la photos sont très éloignées l'une de l'autre, cela n'empêche pas de m'éclater à pratiquer les deux note: je fais mes sorties astro photo avec un autre membre du club qui lui a commencé la photo a l'époque de l'argentique. Je l'aide sur la partie "informatique" de l'astrophoto, et lui partage sa grande connaissance du ciel Cordialement, Stephane

C'est parce qu'il y a 2 types de rejets différents, l'un qui porte sur la totalité d'une image, l'autre qui travaille sur chaque pixel individuel lors de l'empilement Le premier type de "rejet" (que je préfère appeler "filtrage" pour éviter justement la confusion), vise a ne pas prendre en compte des images jugées mauvaises, que ce filtrage soit manuel (fait par l'opérateur), soit automatique par Siril en donnant les critères tels que la FWHM, la rondeur, le nombre d'étoiles détectées, etc.... Ce filtrage vise à supprimer des images qui par exemple ont subi un problème de mise au point, de suivi (filé d'étoile), de turbulence, etc... Une trainée de satellite sur une image très piquée (fwhm basse) n'est dont pas exclue automatiquement par Siril, mais peut l'être par un opérateur humain...(à mon avis à tort) Une fois le filtrage effectué, les images retenues vont être empilée, et là c'est l'algorithme d'empilement qui va effectué un rejet des pixel deviants, et ici il ne s'agit pas d'exclure une image en totalité, mais bien d'analyser chaque pixel, de regarder la valeur qu'il a sur chaque photo à empiler, et ne retenir que ceux qui ne s'eloignent pas trop de la moyenne (par défaut l'algorithme utilisée c'est Winsorized sigma clipping). Et c'est cet algorithme qui permet de réduire le bruit et les trainées de satellites qui par nature vont éloigner la valeur du pixel de celle du signal (qui lui sera a peu près constant sur chaque image) Si tu as 100 photos, même si 50% d'entres elles ont un passage de satellite, il est très peu probable que sur les 50 photos concernées les trainées soient sur les mêmes pixels (sauf si des starlink se suivent à 30 secondes d'intervalle pile sur la même orbite !). Lorsque l'algorithme va (pour chaque pixel) calculer la moyenne des valeur sur les 100 photos, les valeurs pour les pixels contenant un passage de satellite seront très éloignés de la moyenne et la valeur aberrante sera éliminée. note: quand je parle de pixel de l'image qui sont comparés, l'algorithme tient compte du fait qu'entre chaque image on peut avoir bougé le capteur (par exemple avec du dithering), et ils se sert des décalage calculés à l'étape d'alignement (register) pour comparer les pixels à l'étape empilement (stack) Plus d'infos sur l'empilement ici: https://siril.readthedocs.io/fr/latest/preprocessing/stacking.html edit: ou encore ici https://ciel-astro-ccd.com/wp/methodes_de_compositage/

Pour la FWHM, oui, c'est bien de filtrer, et c'est normal qu'elle varie en cours de nuit, mais cela n'est pas du à la temperature du capteur (la temperature du capteur va augmenter le bruit) Elle va dépendre d'une part de l'évolution de la qualité du ciel au cours de la nuit (taux d'humidité, turbulence), et cela on ne peut pas y faire grand chose, mais d'autre part elle va aussi dépendre de l'évolution de la temperature ambiante au cours de la nuit, qui va causer une dilatation (si le temp augmente) ou une contraction du tube du telescope, et donc faire varier la mise au point. Pour limiter cet effet, il faut refaire la MAP plusieurs fois au cours de la séance (c'est plus facile avec une focuseur électrique et un soft qui automatise le process en calculant la FWHM de étoiles pour trouver la MAP optimum) Pour le filtrage des images, moi à ta place je ferais un test en faisant un empilement en conservant les images où il y a des passages avions/satellites, et en n'enlevant que celle ou il y a un éventuel défaut de suivi avec un filé d'étoile (qui peut aussi être dû à une rafale de vent), mais ce cas là devrait être filtré avec la FWHM des étoiles. Si tu as 20% des images qui sont bien nettes avec juste un passage de satellite cela serait dommage d'éliminer tout ce temps de pose alors que l'algo de rejection à l'empilement se chargera d'éliminer les pixels déviants qui contiennent les trainées, mais garder les autres pixels qui contiennent le signal si précieux et si difficile à obtenir... Cordialement

Bonjour, Belle progression, et puis comme cela cela te fait une version avec la supernova 2023ixf et une sans... 🙂 J'ai 2 questions: - pour la mise au point, tu utilises un masque de bahtinov ou bien c'est au jugé avec le live view ? (et du coup Siril te donne quoi comme FWHM pour tes brutes ?) - quand tu dis qu'il y a 20% d'image rejetée, c'est toi qui le a exclues manuellement après visualisation ?, cela me semble dommage de les exclure totalement. Je dis cela car moi je laisse les photos avec passage de satellite (sinon c'est plus de 50% que je dois jeter sur des poses de 120s ou 180s), et je compte sur l'algorithme de rejection de Siril pour éliminer ces trainées qui par definition ne se trouvent pas sur toutes les images. (mais ne suis pas sûr que mon choix soit le meilleur...) Cordialement

Bonjour, Je viens de poster dans les clubs "L'impression 3D en astronomie" et "Astronomie avec Arduino" les éléments nécessaires à la réalisation d'une roue a filtres imprimée en 3D, manuelle ou motorisée Chapitre 1: Les photos du bricolage Voici des photos de la version RF-42 5x1.25 pouces avec motorisation que j'utilise régulièrement (pilotée via Kstars/Ekos/Indi,la roue implémente le protocole des roues Quantum) En version manuelle, avec une petite trappe pour accéder à la roue et la faire tourner Le support moteur En version motorisée, la trappe est remplacée par le support moteur En version motorisée avec le boitier d contrôle (1 port 12V DC pour l'alimentation du moteur, un port USB micro pour le pilotage série) Une vue des différents éléments avant montage de la roue Une vue des elements de la motorisation Chapitre 2: Les modèles 3D Il y a 2 modèles, avec 3 déclinaison en tout 1) Le petit modèle, une seule déclinaison pour 5 filtres 1.25 pouces Le boitier dispose de filetages M42x0.75 m sur chaque face 2) Le grand modèle, avec 2 déclinaisons, soit pour 5 filtre d e3 pouces, soit pour 8 filtres de 1.25 pouces Le boitier dispose de filetages M54x0.75 M sur chaque face Les fichiers pour l'impression 3D des roues ) filtres sont disponibles ici Chacun des 2 modèles peut être actionné manuellement, ou doté d'une motorisation Pour l'impression en 3D des supports moteurs et du boitier de contrôle, c'est ici EDIT: ajout des fichiers STL pour les têtes de vis et boulons, pour manipuler les vis sans outils Tete vis et boulons.zip Important: les têtes de vis sont une création originale de Xavier DUPONT pour le projet SOLEX, les têtes de boulons sont une adaptation personnelle des têtes de vis. Chapitre 3: Motorisation, code de programmation et interface de pilotage Pour la motorisation vous aurez besoin d'un microcontroleur ESP8266 ou ESP32, d'un moteur 28BYJ-48 et de son stepper UNL2003 (le tout devrais vous couter moins de 20 euros). Le code est fourni ici (mis à jour version 1.1.1 le 19/10/2021) La roue est pilotable via le port USB du contrôleur, elle implémenta par défaut le protocole des roues à filtres Quantum --> a ce titre la roue a filtres est pilotable via Kstars/Ekos/Indi en utilisant ce driver INDI Avec un microcontroleur ESP8266 ou ESP32 (en lieu et place d'un Arduino tout simple), la roue a filtre généralement!re son propre réseau Wifi (comme une borne) SSID réseau: : mls-rf password: azerty adresse IP de la roue: 10.42.0.1 joignable en interface web: http://10.42.0.1 En parallèle du mode "borne" la roue peut aussi se connecter à un réseau wifi existant, vous pouvez modifier dans le code les éléments "reseau1", "password1", "reseau2" et "password2", la roue a filtre se connectera à l'un de ces 2 réseaux, au premier qui accepte la connexion, testés dans l'ordre... Voici quelques copies d'écran du pilotage en mode wifi (désolé j'ai l'habitude de programmer en anglais, comme au boulot, même si mon niveau d'anglais est mauvais ...) L'écran principal, on choisi le filtre et on valide (submit), la validation entraine le déclenchement du mouvement pour positionner le filtre choisi (les noms des filtres peut être modifié sur l'écran de config) Ci dessous l'écran de configuration pour nommer les filtres et leur attribuer un décalage (offset), qui sera utilisé par Ekos/Indi pour ajouter la mise au point selon chaque filtre Ci dessous la page de configuration Détail des paramètres: - nombre de filtres: accepte les valeurs de 1 à 9, mais en fait on utilise soit 5 soir 8 filtres - nombre de "pas par minutes" max lors de la rotation du moteur - nombre de "pas par minutes" initial au but de la rotation du moteur - nombre de "pas" pour le facteur d'acceleration (utilisation de la librairie AccelStepper) - nombre de pas pour faire un tour de moteur (habituellement avec un moteur 28BYJ-48 c'est 64) - nombre de dents de l'engrenage sur l'axe moteur (20) - nombre de dents sur le tour de la roue (100 pour le petit modèle, 120 pour le grand modele) Ci dessous la page pour envoyer manuellement des commandes (celles qui sont habituellement envoyées par le port série, pratique pour tester) TRES IMPORTANT: comme la roue a filtre ne dispose pas de mécanisme de "repositionnement automatique", si il y a désynchronisation, avec le roue qui s'arrête sur une position entre 2 filtres, l'ecran de mouvement manuel permet des ajustement en faisant tourner la roue (on choisi le nombre de degrés, en valeur positive ou négative selon le sens que l'on souhaite Et pour finir il y a une page "debug" qui présente les valeurs en cours des différentes variables du firmware Cordialement, Stéphane Edit 19/10/2021: suppression des images en doublon, mise à jour des copies d'écran du pilotage de la roue via son interface web Edit 23/11/2021: modification du schéma de câblage, livraison code microcontroleur v1.2.0 VERSION1.3 du 06/11/2023 Edit 06/11/2023: ajout d'une nouvelle pièce 3D "support haut hall" permettant d'ajouter un capteur a effet haut et livraison code microcontroleur v1.3.0 qui l'exploite Motifs sur le code: - Refonte graphique pour le site web embarqué et ajout d'un mode "nuit" (rouge/noir) - Ajout pilotage via driver Bluetooth Serie (testé OK sur Ekos/Indi) - Ajout pilotage via driver network (tcp port 1234)(testé OK sur Ekos/Indi) - Ajout capteur Hall + recherche automatique de la position du filtre 1 IMPORTANT: si vous avez déjà imprimé la version précédente de la roue et du support moteur vous n'avez pas besoin de tout réimprimer, vous devez seulement imprimer la pièce "support haut hall" (et éventuellement le "capot hall" pour protéger le capteur) Quelques images: Le support du capteur Hall (piece seule, et pièce installée sur la roue avec le capteur) Le support avec le capteur et son capot de protection Le type de capteur est un AZDelivery KF-035 (environ 7 euros les 3 capteurs sur la Zone....) Important: ce capteur dispose d'une LED qui éclaire en rouge, il est important de la masquer pour ne pas produire de lumière indésirable dans la roue à filtre ! Avec un contrôleur ESP8266 ou un ESP32 la roue peut être connectée en Wifi et pilotée via un site HTTP intégré La version 1.3.0 entraine une refonte graphique du site embarqué, voici quelques captures d'écran (le theme Dark est par défaut, mais on peut permuter avec le thème Light à la volée): Le nouveau plan de câblage avec le capteur Hall (dans le code on considère qu'il est connecté sur le port GPIO16, mais c'est configurable) Cordialement, Stéphane