Merci à tous pour vos réponses. J'ai bien la version 0.9.12 mais honte à moi, je n'avais pas noté la présence de ce champ dans l'onglet séquence... (pourtant, quand on passe dessus, il y a effectivement bien l'info bulle) Du coup, j'affichais la liste des images de la séquence dans l'image en N&B d'où ma remarque sur la place occupée à l'écran. En effet, la navigation depuis l'onglet séquence est assez pratique à l'usage et permet de faire le blink. Merci beaucoup pour cette découverte (enfin pour moi...). Bien cordialement,

En pratique, le "compositage cométaire calculé" s'opère ainsi : 1°) On registre déjà les images sur les étoiles (çà Siril le fait très bien) 2°) Il faut bien sûr connaître : * les paramètres astrométriques des images (ou du moins l'échantillonnage des images en Arcs/pixels et l'orientation du capteur via par exemple le PA de la 1ère colonne) * et le déplacement apparent de l'astre (saisi par l'utilisateur, faisons simple) concrètement des arcs/minute vers une direction (1) 3°) L'algorithme consiste alors à rajouter un deltaX et un deltaY calculés à partir des heures de prise de vue des images aux deltaX et deltaY obtenus par la registration stellaire pour chaque image (sauf l'image de référence) et à faire alors l'empilement sur cette base. Et le tour est joué ! Ce doit être proche de l'algorithme actuel, sauf que les translations supplémentaires à appliquer aux valeurs obtenues en registration stellaire ne sont pas calculées actuellement mais déduites du pointage du noyau de la comète par l'utilisateur sur la première et la dernière image de la série. J'avoue avoir pensé à bidouiller manuellement le contenu du fichier.seq où sont stockées les paramètres de registration pour que Siril fasse l'empilement souhaité, mais à la main c'est vite inextricable et source d'erreurs... Le problème avec le compositage cométaire actuellement implémenté est qu'il nécessite que la comète soit bien visible sur les images individuelles. C'est sans souci pour les objets brillants, déjà délicats sur les objets un peu faiblards où le centre sera mal défini et totalement impossible sur les comètes vraiment faibles qui ne sont visibles qu'après empilement et totalement indétectables sur les poses individuelles. Un immense merci d'avance en tout cas si cette fonction peut être implémentée. (1) renseignement donné par exemple sur le site de l'UAI : https://cgi.minorplanetcenter.net/cgi-bin/mpeph2.cgi Voici un exemple concret (deux dernières colonnes): 249P/LINEAR Epoch 2020 May 31.0 TT = JDT 2459000.5 T 2020 June 29.4983 TT Rudenko q 0.496747 (2000.0) P Q n 0.2147216 Peri. 65.6071 +0.5621090 +0.8175002 T = 2459029.99828 JDT a 2.761969 Node 239.1775 -0.8018435 +0.5015087 q = 0.4967475 e 0.820147 Incl. 8.3971 -0.2026832 +0.2831651 Earth MOID = 0.04497 AU P 4.59 Perturbed ephemeris below based on elements from MPEC 2020-P19. 0249P Date UT R.A. (J2000) Decl. Delta r El. Ph. m1 Sky Motion h m s "/min P.A. 2020 08 10 000000 06 00 35.9 +25 33 34 1.298 0.966 47.5 50.6 15.9 1.18 100.6 2020 08 11 000000 06 02 38.0 +25 28 22 1.308 0.981 48.0 50.1 16.0 1.16 100.8 2020 08 12 000000 06 04 38.5 +25 23 07 1.317 0.996 48.5 49.6 16.1 1.15 101.0 2020 08 13 000000 06 06 37.3 +25 17 51 1.326 1.010 49.0 49.2 16.2 1.13 101.2 2020 08 14 000000 06 08 34.4 +25 12 34 1.335 1.025 49.5 48.7 16.2 1.12 101.4 These calculations have been performed on the Tamkin Foundation Computing Network.

J'avoue que je n'ai aucune idée de comment ca marche.

On pourrait garder en mémoire les deux buffers d'images 8 bits pour accélérer le truc mais ça serait un développement spécifique à cette feature, ce qu'on évite de faire pour les choses les moins prioritaires.

Une beta sortira prochainement .... quand on aura corrigé les bugs. Avec Siril rien n'est programmé vraiment à l'avance.

Le problème du blink, pour avoir essayer de le coder. C'est que ca rame à mort avec les grosses images. Du coup je l'ai pas mis, et en l 'état il y a peu de chance qu'on le voit. Car si ca marcherait super bien avec des images de camera planétaire, ca serait l'enfer avec celle de plusieurs dizaines de millions de pixels. Le nouveau sélecteur d'images de la séquence est assez pratique ceci dit.

Génial ! Et elle arrive quand ? d'ici la fin de l'année ?

La version de siril qui arrive lit le CR3 sans soucis.

Dans la 0.9.12 il y a un bouton dans l'onglet séquence qui permet de passer de l'une à l'autre, à coté du numéro d'image, ça se fait au clavier avec les flèches haut et bas aussi je crois quand on clique dans la boite avec le numéro. Le décalage d'affichage est aussi possible avec la registration manuelle, avec les flèches ou la molette. Mais oui c'est pas idéal.

Bonjour, Oui effectivement je n'y avais pas pensé. Un peu lourd tout de même à l'usage, car outre la fabrication de la séquence dédiée au blink, il faut aussi registrer les 2 images au préalable et le passage de l'une à l'autre nécessite d'afficher la liste des images de la séquence (qui prend de la place sur l'écran...) pour double cliquer sur l'une ou l'autre de façon répétitive. Je pensais à un vrai blink, avec délai d'affichage entre les images réglable et la possibilité d'affiner le décalage de l'affichage (pour les translations sur les lignes et les colonnes) manuellement au clavier avec les flèches par exemple. Très utile en pratique pour les objets en mouvement et notamment les comètes faibles. Bon, je note que ce n'est pas prévu. Dommage 😢

Bonjour, J'envisage l'acquisition d'un APN Canon EOS Ra pour faire de l'imagerie avec un grand capteur moderne en lieu et place de mon vieux Nikon D700 défiltré... mais Canon vient de changer le format RAW de cette nouvelle génération d'APN hybrides plein format. Il s'agit du format CR3. SiriL est-il en mesure de lire & interpréter ce format pour empiler et traiter les prises de vues ? je n'ai pas su trouver l'info... Sinon, quelle serait l'alternative ? Convertir via les applis Canon les fichiers CR3 en fichier TIFF ou PNG ? NOTA : je suis sur Mac OS 10.13 (High Sierra) et SiriL 0.9.12

Bonjour, c'est pas prévu mais c'est facile a faire. Avec la version actuelle il y aune possibilité : renommer les images pour avoir la même base avec un numéro derrière, et faire détecter ça comme séquence à siril. Une fois la séquence chargée c'est facile de passer de l'une à l'autre.

Pardon pour l'abbréviation. PA pour Polar Angle, çà donne l'orientation (la queue des comètes est mesurée ainsi) : 0° = Nord 90° = Est 180° = Sud 270° = Ouest

PA ???

Bonjour, J'ai bien cherché dans les menus du logiciel, la doc et les tutos mais je ne trouve mention nul part de la possibilité de faire un blink entre 2 images. C'est très utile pour confirmer la détection d'une comète connue, voire la découverte d'un astre mobile nouveau dans ses images (on peut toujours rêver qu'il en reste 😃). Cette fonction sera t'elle disponible dans une future version ? Merci beaucoup.

Bonjour, Je découvre Siril et je l'apprécie de plus en plus. Quel chemin parcouru en 4 ans, quand j'ai commencé à m'y intéressé après avoir switché sous Linux, bravo aux développeurs ! J'ai compris à présent comment registrer une série d'images pour une comète brillante qui est visible sur les images de base. Mais serait-il envisageable dans le futur de prévoir une option compositage cométaire calculé pour celles, plus faibles, qui ne sont pas visible sur les images de base ? Ce serait très utile et a priori pas trop compliqué à implémenter en entrant juste les paramètres des images (échantillonnage et PA de la première colonne) ainsi que la vitesse et le PA de déplacement théorique de l'astre. Merci d'avance.

Ton retrait de gradient : tu fais tout en manuel dans PS ? Ou comme je l’ai fait moi : premier retrait dans Siril et retrait du Halo dans PS ?

Sacré bricolage ! Belle réalisation ! Felicitations !

Je n'ai pas vraiment toujours un halo. Sur certaines photos il n'y a rien de visible, ce qui semble indiquer un reflet ou un effet de diffusion. Peut-être le chanfrein du secondaire, qui sait? Perso ça ne me gène pas car l'étape du retrait de gradient fait partie de ma procédure de traitement, donc ça part de toute façon. Le souci c'est en cas d'image avec de faibles extensions dans tout le cadre (M42 par exemple, ou une image de la nébuleuse diffuse IFN). Dans ce cas, le retrait de gradient retire aussi le signal des extensions. Si le halo est visible, il reste la possibilité de l'estomper en créant une sélection à bords flous en forme de 'donut' et en réduisant la luminosité. Ce n'est pas très compliqué: d'abord sélectionner un disque puis sélectionner un disque plus petit en maintenant la touche 'alt' enfoncée, ce qui enlève cette nouvelle sélection de la première. Reste à commander un bord de sélection flou et à diminuer la luminosité et le contraste pour réduire le halo. Merci Cyril! Franchement, c'est pas très compliqué à faire. Le plus dur, c'est la conception dans le logiciel Newt, de façon à obtenir le maximum de lumière, le minimum de diffraction et un CC qui ne dépasse pas dans le tube.

Magnifique. Tu m'en fais un ?

Ok, bon je vais vivre avec ce défaut alors ! De toute façon ton CC est dans ton PO et ne dépasse pas dans le tube et tu as toujours le halo, c’est bien ça ? Ou as tu trouvé un moyen de le dégager une fois pour toute ? Ou le seul moyen sera de le faire dégager au traitement ? je dois reconnaître que la méthode dans PS ou Gimp est sacrément efficace. J’ai du m’y reprendre en plusieurs fois et atténuer la galaxie avant de la coller comme calque differentiel Belle réalisation ce scope !

Ah, l'image est belle, bravo! Sur un tube du commerce, le seul moyen c'est de remonter le miroir primaire vers le secondaire, mais tu vas perdre un peu en luminosité car tous les Newton commerciaux ont un diamètre trop faible. J'ai conçu mon télescope dès le début pour éviter ce genre de souci; c'est une fabrication 'maison' sur base d'un primaire GSO :

Alors, je serai tenté de dire : tout ça pour ça ? 320 prises unitaires avec une map (quasi) parfaite, 25% d'images retenues, franchement, je m'attendais à mieux. Je me fais l'impression, avec Siril, d'être aux commandes d'un avion de chasse que je suis incapable de piloter.