HLe

On est d'accord 🙂 : l'offset d'Ekos est une constante ajoutée à la valeur numérisée de la charge trouvée dans chaque pixel. Ekos (voire Indi, voire le SDK de ZWO) travaille sur une plage allant de 0 à 100 et transforme la valeur saisie ... à son idée puis l'ajoute aux valeurs des pixels lues après acquisition. l'image de "niveau de base" (bias) : exposition la plus rapide sans lumière/signal en entrée. Un coup de stats Siril ou Ekos et l'on voit l'effet de l'offset saisi. Par contre, au moins avec une caméra non refroidie, je n'ai pas d'impact évident autre qu'un accroissement du "sigma" des intensités des pixels des bias en changeant la valeur du gain. J'ai vu que Robin Glover disait dans son forum procéder par acquisition de paires de bias, les soustraire, pour faire ressortir le bruit de lecture et caractériser les caméras. Il faudra un moment de désœuvrement 😒 pour voir ce que ça donne (sur une série statistiquement significative...).

Un début de piste avec cette réponse sur le BBS de Zwo : https://bbs.zwoastro.com/d/16717-courbes-camera-asi385mc. J'en comprends que les valeurs de gain de 0 à 350 correspondent au graphique publié par Zwo sur les performances de la caméra. Au delà d'un gain de 350, c'est juste une multiplication des ADU par le SDK (ou peut être le firmware) pour "faire du chiffre". Donc si la valeur saisie dans Ekos (ou AstroDMX) part sans transformation via Indi dans le SDK qui la préserve aussi ... on peut utiliser les valeurs de la doc de Zwo (ce qui serait censé...) pour caler son gain 🙂 Question partie...

Justement, l'info que je cherche est le "tel quel" précisément. C'est sûr ? Et l'interprétation que peut en faire le SDK de Zwo. Le pdf livré avec le SDK ne dit rien de l'unité du gain ou ça m'a échappé. A côté de ça Ekos normalise l'offset entre 0 et 100 (ou Indi), sans rapport avec le décalage absolu appliqué (au moins avec mon ASI). Un décalage de 0 sur ma caméra correspond à un décalage de 16 ADU par exemple (valeur imposée par Zwo, niveau firmware ou SDK, peu importe). Ce serait dommage de cibler des valeurs précises et taper à côté.

Bonjour, Je n’ai pas (su) trouver la définition de l’échelle de gain dans Ekos/INDI. Ekos propose des valeurs comprises entre 0 et 600 pour mon ASI385MC (la même échelle est disponible dans AstroDMX Capture). S’agit‑il de dixièmes de dB ? Les valeurs sont‑elles homogènes avec la documentation de ZWO, comme celle‑ci : https://i.zwoastro.com/zwo-website/manuals/ASI385_Manual_EN_V1.2.pdf ? Le réglage 135 dans Ekos correspond‑il bien au gain unitaire pour cette caméra, et 60 au passage en mode HCG (toujours pour cette caméra) ? J’ai rapidement regardé, mais le SDK de ZWO n’est pas accompagné d’une documentation très explicite non plus (ASICamera2 Software Development Kit.pdf), ce qui n’aide pas. Quelques essais rapides ne permettent pas de trancher sur l’identité des échelles, le bruit de lecture étant noyé dans les autres bruits (sur des biais). Une certitude : l’échelle des décalages/offset va de 0 à 100, sans lien direct avec les ADU. Si qqu'un détient la réponse... Merci !

Bonjour, En effet il y a écrit en gros "made in Taiwan" sur la boite du CarbonStar. Peut être un approvisionnement direct possible à la source ? L'équivalent d'un TS UNC plutôt qu'un ONTC non ? cf

Bonjour, Retour d'expérience mais pas une incitation à la prise de risques et au Darwin Award. Si le ciel est voilé, et là, de plus, le soleil sera bas, les 2 peuvent se cumuler, un filtre de densité 5 peut devenir excessif et ne laisser le choix qu'entre ne rien voir ou tenter de regarder dans un instrument, sans filtre, en mode yolo - et avaler une grosse dose d'UV ou pire au passage. Le plan B le plus sûr étant alors de regarder sur le liveview d'un APN ou la visée électronique d'un mirrorless (et pas dans la visée aérienne d'un reflex !).

Bonjour, Je pousse la porte de cet intéressant sujet 🙂 Quel TS présente ce souci ? Avec quel correcteur ? Pas de solution vissée possible ? @AstroNOTE-Guillaume La CEM 70 est généreusement dimensionnée pour un tube relativement léger, non ? En ayant un œil sur un devis de poids mini, une monture harmonique avec un contrepoids pour ramener le centre de masse au-dessus de l'axe du trépied serait-elle envisageable ? Merci !

Super, merci ! Et bravo pour la propreté de l'ensemble : documentation & appli (je n'en suis encore qu'à la surface) ! En particulier la doc 🙂, les snippets de conseils dans l'interface... (les oubliés habituellement). Sans parler du support natif de Linux. Cause trouvée : ce sont des faux raw comme dans Chez Sony, les ARW peuvent aussi contenir du JPEG (pas même d'extension différente comme chez Canon d'après le fil cité).

Ce serait dommage. Sequator est simple mais très "boite noire". Faire du stacking pour du nightscape avec Photoshop est laborieux. Oui, la plupart passent et, curieusement, ceux qui sont en 3 MPixels env non (à supposer que la définition soit la cause).

Je n'ai pas réussi à reproduire le pb sur la 1.2.6 (en clair, ça marche 😄). J'ai enchainé les traitements, parfois sans nettoyer les fichiers générés. Possible que cela provienne de ça (pas d'écrasement quand on recalcule une même séquence ?). Pour la version 1.4 faut-il ouvrir un ticket sur le gitlab ou un post ici suffit ? J'ai rencontré une autre ano : libraw qui ne parvient pas à ouvrir des fichiers Sony (ARW) (ce ne sont pas les miens, pas de partage possible sans accord préalable). Ce sont des fichiers à 25% de la résolution max d'un Sony A7 III...

Pas souvenir du confinement des étoiles dans la boite de sélection ou non avec la 1.2.6. Par contre l'alignement n'avait pas fonctionné (en utilisant la verison de Siril livrée dans une AppImage).

Sequator fonctionne en effet. Mais je voulais le faire avec Siril (plus de maitrise sur les traitements...). Je l'ai constaté sur les versions 1.2.6 et 1.4.0 (beta 1 & beta 2). 3 raw joints, les première, dernière images et celle du milieu. L'objectif était un 24 mm en fait (sur APS/C). 600D-2025-03-29_21-42-46-iso1600-10,00sec.cr2 600D-2025-03-29_21-43-30-iso1600-10,00sec.cr2 600D-2025-03-29_21-44-25-iso1600-10,00sec.cr2

La copie d'écran ne montre pas "Aligner les étoiles dans la sélection". L'option est bien cochée avant de lancer le traitement.

Bonjour, Lecteur anonyme plus que contributeur, je bute sur l'alignement de séries de photos nocturnes et passe demander conseil. J'ai une maitrise de base de Siril (essais réalisés avec les versions 1.2.6, 1.4.0 beta1 et beta2 sur une plateforme Ubuntu 24.04). J'ai connaissance de "Processing a nightscape in Siril, A basic tutorial" J'ai beau sélectionner de réaliser l'alignement sur les étoiles contenues dans la sélection, l'alignement se fait sur le paysage pour finir sur un joli sfumato. Je rencontre le souci avec un full frame + 85 mm comme un APS/C + 40 mm (exemple présenté ici). Démarche suivie dans les images en PJ (sans DOF pour simplifier). Merci ! La copie d'écran ne montre pas "Aligner les étoiles dans la sélection". L'option est bien cochée avant de lancer le traitement.

Il existe aussi ce kit https://astro-gadget.net/gadgets/control-of-telescopes/eqstarvsp-goto-eq-drive-upgrade-kit-for-vixen-super-polaris-mount-2 en espérant que la guerre leur permet de travailler - ils sont Ukrainiens apparemment (retours favorables sur la société en ligne).

Bonsoir, Réponse très tardive... J'ai réalisé en impression 3D 2 platines pour accueillir des moteurs SkyWatcher pour EQ5/NEQ5, conservé les engrenages Vixen pour garder le débrayage des axes et ça marche décemment. Faute de temps, j'en suis resté aux prototypes car cela fonctionne suffisamment pour ce que j'en attends - comme faire ce genre de chose : Je n'ai pas réalisé de carénages complets des moteurs ni surtout une impression avec un matériaux plus résistant que du PLA (le "plastique" standard des imprimantes grand public). Ça apporterait une meilleure tenue et réduirait le jeu (en fait le léger déplacement de la platine en raison de la "tendresse" du plastique désengage légèrement les engrenages).

Quand on peut toucher du doigt le ciel... ... ou juste le contempler ... (sans gants ni manteau 🙂)

<object width="420" height="315" data="https://youtu.be/GI6NZZT5DNE"> </object> Tentative d'incrustation dans le post de la vidéo... Désolé, raté, post précédent à supprimer 🥺 Ah, non, celui là en fait !

Bonjour, Ce n'est plus du live car ça date d'hier matin, 1h30 d'aurore condensées en 1 minutes, à 30 minutes de Toulouse dans le Gers. Les sangliers ont laissé faire jusqu'au bout... https://youtu.be/GI6NZZT5DNE?si=CLcrHGDbtViEpskP