keymlinux

Bravo, que de détails, magnifique trompe !

@Wan186 Lerci, je ne connaissais pas l’extraction du continuum @rmor51je pensais que l’option Raw16 ou RGB ne pouvait être modifié que dans le panel indi de la caméra, mais il semble que l’on peut le changer aussi dans l’onglet ekos de prise de vue. Tu devrais vérifier ta séquence d’acquisition et voir si ‘option «format» n´est pas sur RGB pour le filtre sii+hb Normalement pour le format il y a deux sélections, mono/rgb et fît/native

Si je comprend bien Kstars t'a enregistré les images en les dematriçant en RGB au lieu d'écrire un RAW sur un seul canal ? (dans ce cas les fit doivent faire 150Mo au lieu de 50Mo) Normalement ce paramètre est liée au driver indi de la camera, je ne vois pas pourquoi ce paramètre aurait changé lors d'un changement de filtre. Peux poster une brute Sii+Oiii en fit ? EDIT Sii+Oiii ou Ha+Oiii, la brute qui est détectée comme RGB par Siril (et comme l'a précisé @Ant-1 je doute qu'il y ait un filtre Ha+Sii vu que les deux sont dans le rouge) Seti Astro = SA, suite d logiciels de traitement astro: https://www.setiastro.com/seti-astros-editng-suite PCC: étalonnage des couleurs par photometrie (photometric color calibration ou un truc du genre...) SPCC: étalonnage des couleurs par spectrophotometrie PCC et SPCC sont dispo dans Siril et dans PIX

Et merci pour vos appréciations En cadeau la Rosette en HOO/SOO/SHO

Merci à tous pour vos appréciations. En cadeau, la trompe de l'éléphant...

Bonjour, C'est de saison, voici quelques photos de la Nébuleuse de la Trompe de l'Eléphant, prises lors des nuits de mi-août avec une Lune de dernier quartier. Pour rappel il s'agit d'une nébuleuse en émission située a environ 3000 AL et observable dans la constellation de Céphée. Le 15/08, prise de vue avec filtre Altaïr Ha+Oiii 4nm pour la version HOO (Lune à 64%) Le 16/08, prise de vue avec filtre Altaïr Sii+Oiii 4nm pour la version SOO (Lune à 53%) Combinaison des couches des deux sessions pour la version SHO Le 17/08, prise de vue avec filtre Altaïr L-pro pour la version RGB (one shot color) (Lune à 42%) Détail du matériel: - télescope: SW Equinox 80/500 - réducteur: TRF-2008 x0.8 - camera: Player One Poseidon-C - monture: SW AZ-EQ6 - guidage: OAG + ASI290mm - filtres Altaïr L-pro et dualband Altair Ha+Oiii et Sii+Oiii Capture via Kstars/Ekos/Indi sur Raspberry (Nafabox) Traitement: Siril et Gimp Les images: Version HOO - Lights: 75x240s gain 125 offset 25 temp -10°C - DOF: 50/50/50 Version SOO - Lights: 72x240s gain 125 offset 25 temp -10°C - DOF: 50/50/50 Version SHO Combinaison avec les couches HA et Sii ci dessus. Pour la couche Oiii utilisation des 147 Lights Version RGB (one shot color) - Lights: 80x180s gain 125 offset 25 temp -10°C - DOF: 50/50/50 Les images postées ici sont en jpeg, réduites en taille (hauteur et largeur divisée par 2) A noter que même avec le réducteur de focale, cela rentre au chausse pied, cette jolie cible mériterait un champ plus large... (la nébuleuse à une taille apparente sur le ciel de 170'x140') RGB HOO SOO SHO (bof bof, ce n'est pas ma préférée) Cordialement, Stéphane

En fait par le passé je me suis plusieurs fois fait avoir avec le cadrage, du coup maintenant je suis méfiant. Par exemple lorsque je fais le goto sur IC1848 comme cible, en fait cela cible le petit amas ouvert qui est dedans mais qui n'est pas centré dans la nébuleuse. De plus j'ai du tourner la camera de 90° pour avoir la longueur de la nébuleuse dans la longueur du capteur (et donc refaire la mise au point car mon porte oculaire à friction bouge dès qu'on le touche). Puis j'essaie de trouver une étoile à cibler qui soit au milieu du champs que je souhaite obtenir, puis goto sur cette étoile + astrométrie (j'autorise seulement 40" d'arc de précision sur l'astrométrie) Et je n'hésite pas à faire une ou deux poses de prévisualisation de plusieurs minutes pour bien voir la nébuleuse et valider le cadrage (je préfère perdre 10 minutes que regretter plus tard...)

Bonjour, Après vous avoir présenté l'année dernière une Nébuleuse de la Rosette en couleur "normales" (RGB one shot color) (voir sujet ci dessous), voici les versions HOO, SOO et SHO issues de deux nuits d'imagerie avec des filtres dualband 31/03/2025 --> Utilisation du filtre dualband Altaïr Ha+Oiii 4nm pour la version HOO 01/04/2025 --> Utilisation du filtre dualband Altaïr Sii+Oiii 4nm pour la version SOO Combinaisons des couches des deux sessions pour la version SHO Détail du matériel: - télescope: SW Equinox 80/500 - réducteur: TRF-2008 x0.8 - camera: Player One Poseidon-C - monture: SW AZ-EQ6 - guidage: OAG + ASI290mm - filtres dualband Altair Ha+Oiii et Sii+Oiii Capture via Kstars/Ekos/Indi sur Raspberry (Nafabox) Traitement: Siril et Gimp Les images: Version HOO - Lights: 90x120s gain 125 offset 25 temp -10°C - DOF: 50/50/40 Version SOO - Lights: 90x120s gain 125 offset 25 temp -10°C - DOF: 50/50/40 Version SHO Combinaison avec les couches HA et Sii ci dessus. Pour la couche Oiii utilisation des 180 Lights Les images postées ici sont en jpeg, réduites en taille (hauteur et largeur divisée par 2) HOO SOO SHO Cordialement, Stéphane

Pas en même temps, cala va dépendre des cibles Pour les nébuleuses en émission (Ha, Oiii, Sii), tu peux utiliser un filtre Dual-band Ha+Oiii ou Sii+Oiii qui est très restrictif, cela filtre aussi les UV et IR, Pour les autres cibles un filtre UV-IR qui ne filtrera que cela, indispensable si le hublot de ta camera n'est pas déjà traité pour filtrer les UV et IR Si tu image depuis un ciel avec un peu de pollution lumineuse tu peux utiliser un filtre CLS au lieu d'un UV-IR (il filtrera aussi les UV et l'IR en plus de certaines longueur d'ondes spécifiques à l'éclairage des villes) Cordialement, Stéphane

Profitant d'une rare nuit favorable au niveau météorologique et sans Lune, j'ai pu imager La Nébuleuse de l'âme. Il s'agit ici une version couleur normale (one shot color), des versions HOO et SHO suivrons, dès que la météo le permettra... Et comme cela fait un moment que je n' avais pas posté, je vais devoir rattraper le retard accumulé, je ferais d'autres posts pour vous présenter les nébuleuses de la Rosette en HOO/SHO, la Méduse et la Trompe d'éléphant que j'ai imagé depuis début 2025... Concours de circonstance, la même nuit @rmor51 traquait la même cible, voir son post ici Cible: Nébuleuse de l'Ame Nébuleuse en émission et amas ouvert, située dans la constellation de Cassiopée, à une distance d'environ 6500 AL de nous, et une taille d'environ 150 AL dans la longueur. Capture (24/08/2025): - 90 poses de 180 secondes - prises de vues à gain 125, offset 25, température 0°C (petit soucis, je n'ai pas réglé la bonne température, d'habitude de vise -10°C) - DOF 50/50/50 Le setup: - monture SW AZ-EQ6 - lunette SW Equinox 80/500 - correcteur réducteur x0.8 TRF-2008 - camera PlayerOne Poseidon-C - guidage au diviseur optique avec ASI290mini - filtre L-pro (Altaïr) - Kstars/Ekos/Indi sur un raspberry pour piloter le setup Traitements: - pre-traitement via Sirilic / Siril (retrait du gradient effectué sur la séquence lors du pré-traitement) - traitement Siril -- Retrait de gradient GraXpert (via script Siril) -- Photometrie -- Etirement Hyperbolique Généralisé -- Réduction d'étoiles (pour la version avec réduction, via script Siril/Starnet++) -- Retrait du bruit vert -- post traitement Gimp (MakeDarkSky via plugins PyGapM27, courbes) La version sans la réduction d'étoiles La version avec réduction d'étoiles La résolution astrométrique Cordialement, Stéphane

A ta place je remplacerais le Optolong L-extreme par un Optolong L-pro Il est très efficace sur la pollution lumineuse et bien moins restrictif qu'un dual-bande note: le l-pro a une épaisseur de 2mm comme ton filtre Antlia et contrairement au l-extreme qui fait 1,85mm (je dis cela pour la parafocalisation avec ta roue a filtre) moi j'ai abandonné le Optolong L-pro au profit d'un Altair L-pro pour justement avoir la même épaisseur de 1,85mm sur tous mes filtres.... 😉

Bonjour, Pour info, à cette date le problème est toujours d'actualité 1) Siril (version 1.4.0 beta2, la beta3 n'est pas disponible pour ubuntu 24.4) a une dépendance sur "libxisf0", package dispo dans le repository standard ubuntu 2) Kstars-bleeding (version 3.7.8) a une dépendance sur "libxisf", tout deux dispo sur le PPA de Jasem

Bonjour Robert, J'ai le même capteur sur une PlayerOne Poseidon-C, utilisée avec Kstars sur un PI5 (Ubuntu 24.4) J'utilise un gain 125 offset 25 (on ne peut pas vraiment comparer ces valeurs entre des camera de marques différentes, elles dépendent fortement de choix fait dans l'implémentation des firmware et drivers, plus que du capteur lui même, le plus efficace c'est de comparer les courbes fournies par le constructeur pour voir à quelle valeur de gain se déclenche l'ampli) Une option disponible avec la Poseidon-C (et que j'ai activé) c'est de faire des captures en mode "low noise", qui bénéficie d'un bruit de lecture plus faible (Player one fourni les courbes pour les 2 modes). Tu devrais vérifier si ta camera propose une telle option. Je n'ai pas vu d'autres options jouant sur la qualité de la capture. Il existe des options jouant sur le débit de transfert USB, mais a l'usage la valeur par défaut me va bien. A noter que sans rien toucher au débit USB, on réduit drastiquement le temps de récupération d'une image en passant d'une carte SD à un disque SSD, puis d'un SSD à un NVME. Le facteur limitant semblant être ici le débit d'écriture stockage plus que le débit entre la caméra et le rpi. Vu que la com est refroidie, je fais toutes mes captures à -10°C, et j'ai une bibliothèque de Bias/Darks que je renouvelle 1 fois par an. A l'usage le darks sont très propres et au traitement je vois peu de différences entre le traitement avec ou sans dark Je ne vois pas d'autre point à optimise coté caméra. En fait dans mon cas personnel, mon problème n'est pas coté caméra mais coté tube optique, ma lunette Equinox 80D devenant désormais le maillon faible de mon setup... Cordialement Stéphane

Je suis un boulet ! j'avais bien téléchargé l'image brute, mais je n'avais pas lu les détails, tout y est cible et filtre... J'avais vu dans l'en tête fit que la cible était ngc7788, mais comme je ne voyais pas d'amas sur la brute j'avais même fait une résolution astrométrique, l'amas est tout petit dans le champ couvert, et Siril ne m'indique pas la présence de LBN576... Ce n'est visiblement pas une cible facile !

Les fichiers STL Support PI5 v2.0 - bas.stlSupport PI5 v2.0 - haut.stl Tu peux aussi aller sur Tinkercad ou je partage les modèles (tu peux les cloner et les modifier pour les dimensions de ton boitier) https://www.tinkercad.com/things/k6iCjoBygar-support-pi5-v20 Avant j'utilisais un Pi4 avec un boitier disposant aussi d'un pas de vis kodak (pas trouvé d'équivalentes pour le PI5), j'avais fait un support pour le PI + disque dur externe (Samsung T5) + hub usb https://www.tinkercad.com/things/caiKp8ArGpM-support-rpi-hub-usb-dd-t5-v6 Cordialement

Je suis d'accord, mais a un détail près, c'est valable pour le capteur de l'ASi2600 qui est exempt d'ampglow, mais si il y a ampglow, le dark sert à le soustraire des brutes, et si le gain utilisé pour les brutes et les dark est différent il via y avoir sur ou sous correction de cet ampglow Je suis tout a fait d'accord l'emploi du terme Bias permet d'éviter de confondre avec l'offset de la camera. Mais si j'étais tatillon je dirais qu'en employant le terme DOF il y a une légère contradiction, car le O de DOF c'est pour Offset, on devais utiliser l'acronyme DBF (ok, je sors... 🙂 ) La cible est NGC7788, petit amas ouvert (la cible est écrite dans le fit de la brute). et oui moi aussi je trouve qu'il y a très peu de signal sur ces brutes de 300s A @transitmk1 de confirmer si il y a eu usage de filtre restrictif ou pas (mais pour une cible comme un amas ouvert, a part un filtre anti-pollution léger, je ne vois pas l'interêt d'un filtre restrictif style S, H O ou dualband) Effectivement on ne peut pas lutter avec les conditions caniculaires, la température cible était bien -10° (apparaît dans les en têtes FITS), ensuite la camera fais ce quelle peut.... Ceci étant je pense que dans ce cas là il vaut mieux viser une température de capteur plus haute, style 0° ou 5° pour éviter que la régulation thermique soit à la ramasse et cela permettra de garantir que toutes les brutes et tous les dards sont à la même température Là par contre, désolé de te contredire, mais les dark et brutes n'ont pas été faits au même gain, c'est écrit dans les en têtes FITS des images que tu as fourni. @transitmk1 Peux tu nous confirmer si lors du pré-traitement tu as juste soustrait le masterdark (dans ce cas on ne comprend pas pourquoi autant de pixels négatifs) ou bien si tu as aussi soustrait le masterbias (là par contre la soustraction des 2 expliquerais bien le pourquoi tu obtiens autant de pixels négatifs)

Salut Robert, J'utilise aussi un Pi5 avec Nvme, que j'ai installé dans un boitier Geekworm P579 Pour le fixer sur la lunette, j'ai fait un support en impression 3D Cela serait bien incroyable qu'il n'y ait personne dans ton club astro qui ne dispose d'une imprimante 3D pour te faire un support aux dimensions de ton boitier... Le PI5 a bien un RTC intégré, mais il faut lui brancher une petite batterie sur le connecteur qui va bien (pour info 6€ la batterie sur Kubii). Pour le moment je n'ai pas encore franchi le pas, je le met à l'heure avec un dongle GPS, ou manuellement si besoin Mon boitier: Le support 3D, avec une embase "mini-vixen" à fixer sur le support du chercheur de la lulu Cordialement, Stéphane

Si les brutes et darks ne sont pas au meme gain cela ne vas pas aider… Une caméra ASI2600 cela s’utilise a gain 100 ( a gain 0 dans certains cas particuliers), je ne vois pas de raison d’utiliser les valeurs 203 ou 174… lecture:

Souvent on obtiens des pixels négatifs car on soustrait les offsets et les darks (qui eux mėme contiennent l’offset) donc on soustrait l’offset 2 fois. @transitmk1lorsque tu pré traites dans Siril, fais tu un pré-traitement: (brutes-dark)/(flat-offset) ou bien (brutes-dark-offset)/(flat-offset) Si le dark contient l’offset alors il faut faire la 1ere opération et pas la deuxième

Bonjour, 1) peux tu me préciser la version de MacOS que tu utilises et si ton mac est à processeur Intel ou ARM ? note: j'utilise le plugin avec Gimp 3.0.4 sous macOS Séquoia 15.6, macbook à processeur Intel 2) peux tu vérifier que tu as bien déclaré le répertoire où tu as dézippé le plugin dans gimp. Menu "GIMP/Settings...", puis une fois dans la fenêtre "Préférences", vérifier "dossiers/greffons" Par exemple, moi de déclare "/Users/stephane/pygap-m27-gimp3/pythonfu-gimp3", à adapter selon ton cas. 3) vérifie que les fichiers du plugin n'ont pas d'attribut de quarantaine (mis par défaut sur les fichiers téléchargés depuis internet...) par exemple chez moi (à adapter avec le nom du répertoire où tu as stocké les fichiers): ls -l@ -R /Users/stephane/pygap-m27-gimp3 Si il y a un ou plusieurs fichiers qui ont l'attribut "com.apple.quarantine" alors cela peut expliquer le problème Dans ce cas il faudra supprimer cet attribut avec la commande suivante (ici aussi adapter le nom du répertoire): xattr -d -r com.apple.quarantine /Users/stephane/pygap-m27-gimp3 4) Peut tu lancer GIMP via la ligne de commande: /Applications/GIMP.app/Contents/MacOS/gimp et copier ici dans le fil de discussion les messages obtenus au lancement Pour exemple, voici ce que j'obtiens chez moi MLS-MBP:~ stephane$ /Applications/GIMP.app/Contents/MacOS/gimp GIMP is started as MacOS application GIMP was built with MacPorts (gimp:60098): Gtk-CRITICAL **: 17:12:44.797: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed /Applications/GIMP.app/Contents/MacOS/gimp: Gimp-Widgets-CRITIQUE: gimp_dialog_factory_add_foreign: assertion 'GDK_IS_MONITOR (monitor)' failed (gimp:60098): Gtk-CRITICAL **: 17:12:45.014: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed EDIT: la présence de ces messages "Gtk-CRITICAL" n'empêchent pas le bon fonctionnement Cordialement, Stéphane

Salut Robert, Le nouveau script qui remplace le précédent est "OSC_Extract_HaOIII.ssf", normalement il est inclu avec l'installation Siril (sur mon macbook il est livré avec les binaires Siril, il ne fait pas partie des scripts téléchargeables via "Réglages/scripts" et il n'est pas dans le repository: https://gitlab.com/free-astro/siril-scripts/ OSC_Extract_HaOIII.ssf note; - si en plus d'une extraction Ha+Oiii tu as aussi à faire une extraction Sii+Oiii tu peux utiliser le même script sur tes brutes faites avec le filtre Sii+Oiii, puis ensuite tu devras renommer le fichier résultat "ha" en "sii" edit: pour info, Kstars 3.7.8 viens de sortir (13/08) , je vais tester ce soir... Cordialement, Stéphane

Bonsoir, Concernant les bias, dark et light fournis, je ne vois rien de problématique (rien qui pourrait expliquer le gros "donut" sombre sur l'image finale), les paramètres de prise de vue (iso, ouverture) sont homogènes Sur les light, l'analyse de la courbe de luminosité sur la diagonale ne fait apparaitre qu'un vignétage normal, pas de gros "donut" (donc a priori pas de buée) Par contre l'analyse de la PSF (forme des étoiles) fait apparaitre du tilt. C'est bizarre car avec un APN canon et un objectif canon l'ajustement entre les deux devrait être nickel avec très peu de jeux mécaniques donc peu de tilt. Mais si ton objectif est un 70-200 à monture EF, que tu as monté sur la monture RF de ton APN, alors il y a une bague intermédiaire EF vers RF, donc des jeux mécaniques entre chaque élément qui au final sont cumulés. A noter que si l'objectif est léger, on fixe l'APN sur la monture et on laisse l'objo en "porte a faux", mais si par contre l'objoo est plus lourd que le boitier de l'APN (et il me semble que c'est le cas avec cet objectif), alors il est préférable d'utiliser un collier à pied pour l'objectif, afin que ce soit l'objectif qui soit fixé sur la monture et que ce soit le boitier qui soit en "porte a faux" Ceci étant le tilt c'est pour les puristes qui veulent des étoiles rondes et fines, mais à ma connaissance cela ne cause pas le problème de "donut" sombre que tu rencontre. Pour les master dark et bias, rien de particulier non plus. Le master bias étant très homogène avec une valeur de 2048, tu peux au lieu de faire des bias utiliser un bias synthétique dans Siril en mettant la valeur à 2048 (c'est ce que je faisais quand j'utilisais un Canon 80D, cela marche très bien) Bias synthétique, voir ici https://siril.org/fr/tutorials/synthetic-biases/ Au final, je ne vois rien dans les images fournies qui explique le résultat obtenu avec le gros "donut" sombre Ce que tu peux tenter c'est de refaire elle traitement sans les flats. si ce sont eux qui sont la cause du problème, alors les supprimer devais faire disparaître le gros donut sombre, et au pire tu aura un peu de vignétage dans les coins Petit aparté, histoire que tu te sentes moins seul, moi aussi il m'arrive d'obtenir des résultats surprenants. ci dessous M27 imagée le 11/07 avec un C8 et un filtre ha+oiii, stack de 200x60sec, traitement avec les flats, capture d'écran de l'affichage de siril en mode auto-ajustement la même traitée sans les flats (post édité pour mettre l'image avec la même orientation...) Cordialement

Bonjour, Quand j'ouvre ton flat avec les outils Canon (DPP), il me donne un histogramme qui est plutôt au milieu (note, DPP donne un histogramme sur des valeurs normalisées en 8bits, donc entre 0 et 255) Par contre quand je l'ouvre avec Siril et que je demande les statistiques de l'image j'obtiens cela Normalement ton Canon donne des images RAW en 14bitsn donc avec des valeurs entre 0 et 16385 Donc avec des valeurs moyennes à 5000 dans le vert on est pas au milieu de l'histogramme, on est plutôt a un tiers Sachant qu'en plus à 800 iso l'offset (la valeur minimum lue est probablement à 2048, à confirmer en regardant les statistiques d'un dark ou d'un bias a même iso)), je dirais qu'il me semble que ton flat est trop sombre notes 1) utiliser un iPad n'est pas rédhibitoire pour les flats (j'utilise aussi un ancien iPad 3 pour les flat fait avec une petite lunette 2) je vois dans ton raw que tu as activé la reduction de bruit a iso élevée (mode "faible") --> tu peux désactiver, et remplacer cela par des darks que siril traiteras EDIT Avec Siril, si on regarde la courbe d'intensité lumineuse sur une ligne en diagonale de ton image l'image, avec la ligne analysée La courbe d'intensité lumineuse donne cela, on y voit bien les 2 pic vers le bas lors de la traversée de l'anneau sous illuminé Par contre sur ton flat on ne vois pas la même chose (il montre un vignettage normal) EDIT 2 Jusqu'ici on est parti du principe que ce sont les flats qui n'ont pas joué leur rôle et qui ont altéré l'image (sur correction, cela arrive parfois) Mais il y a une autre possibilité pour ce type de halo central, c'est la présence de buée (rosée) qui se dépose sur la lentille frontale de l'objectif en cours de prise de vue mais si c'était le cas je pense que tu l'aurais vu Cordialement, Stéphane

Sur le montage video de @RamRam54 on voit les trainées de quelques satellites, qui a leur altitude de quelques centaines de km sont éclairés par le soleil alors que nous au sol sommes dans la nuit. Si l'objet bizarre et bien le satellite Cosmos 2564 (ce qui reste a démontrer), vu que ce satellite est sur une orbite à plusieurs milliers de km il se peut qu'il se soit trouvé illuminé par la pleine lune même si pour nous au sol elle n'était pas encore levée. D'ailleurs il se peut bien qu'il ait été a la fois éclairé par le soleil qui venait de se coucher à l'ouest et par la lune qui allait se lever à l'est Reste a savoir si ces reflets et un peu de buée donneraient le halo observé... EDIT: par contre pour des reflets de la lune directement sur la lentille d'un telescope ou objectif photo, oui là il faut que la lune soit levée pour l'observateur au sol

Plus serieusement si l'objet est "bas" comme un drone (pas bas j'entend ici dans l'atmosphère), alors vu sa vitesse de déplacement angulaire il ne doit pas avoir une grande vitesse de déplacement dans l'air, donc comment se sustente t'il si l'objet est loin (comme un satellite à 19000 km avec une période orbitale de 11h 16min), même si sa vitesse orbitale est grande son déplacement d'angulaire paraitra faible