Bonjour, il y a deux questions différentes : comment utiliser des images de sessions différentes avec les mêmes paramètres de prise de vue ? Dans ce cas, il faut calibrer les images session par session si les flats sont différents, et les regrouper ensemble dans la même séquence ensuite, soit en les renommant, soit en utilisant la conversion qui pourra le faire. comment combiner des images différentes pour faire une image couleur ? Il faut faire une registration, soit avec le script RGB_Composition.ssf, soit à la main. C'est pas très pratique, mais c'est expliqué dans le tutoriel de composition RVB.

Bonjour, Je sais que le sujet a déjà été abordé ci et là, par le passé mais souvent sans conclusion, ou alors je n'ai pas vu ... Le sujet est le suivant (enfin 2 sujets connexes) : Comment gérez vous le traitement global de plusieurs sessions d'images d'un même objet ? Il peut s'agir du même périphérique d'acquisition / même couche évidemment (par exemple plusieurs sessions d'une caméra couleur, peu importe le laps de temps oui de plusieurs prises d'une caméra mono), mais aussi par exemple du cumul de poses faites avec un APN avec des poses faites avec une caméra couleur/mono. Dans le second cas (sources d'acquisition hétérogènes), je n'ai pas trouvé d'autre moyen que de faire un pré-traitement de chaque série puis de faire ensuite une conversion/séquence des deux (ou plus) images FIT résultantes pour en faire un alignement/empilement. Est-ce la bonne méthode toutefois ? Dans le premier cas par contre (plusieurs nuits d'une même source caméra), comment procédez-vous : idem ci-dessus ou alors séries séparées jusqu'au pré-traitement puis alignement/empilement général ? Dans le cas "alignement général", y a t'il un moyen d'ajouter toutes les bkg_pp_xxxxxx à une des séquences ou recréez-vous donc une séquence cumulant les fichiers du répertoire pour ensuite finaliser ? (JE suppose pour ce cas de figure des DOFs potentiellement différents vu que temps de pose/température/cadrage non identiques en postulat de base) EDIT : J'ai fait des essais avec SIRILIC pour du RGB issu d'un DSLR en cumul avec du mono issu d'une caméra. Deux images sont produites à la fin, mais rien ne se passe au niveau d'une intégration finale des deux images en auto (ce dont je me doutais). A vous lire. Julien

@Petitprost Ce qui sera peut-être corrigé c'est le problème de detection. Par contre le comportement d'extraction, lui, sera gardé.

Ca sera peut-être corrigé bientôt.

Bonjour , Cette particularité est elle provisoire du fait que c'est une version Beta ou bien il faudra l'appliquer définitivement sur toutes les versions futures ?

Ok merci

Bonjour, Il faut rajouter la ligne suivante au debut de tes scripts Il me semble que c'était déjà obligatoire avec les versions 1.0.x requires 1.0.0 Edit: je viens de regarder dans le fichier de log que tu fournis, il est fait pour les versions SiriL 0.9, il faut mettre à jour les scripts Voir la doc ici https://siril.readthedocs.io/fr/latest/Scripts.html Cordialement

Bonjour Je lance les scripts (de la meme manière qu'avec la version précédente qui fonctionnait tres bien) et j'ai ce message d'erreur en retour. 21:47:06: The "requires" command is missing at the top of the script file. This command is needed to check script compatibility. Est-ce que quelqu'un sait comment régler ce problème? je joins le log en attaché Merci d'avance 2023-03-26T19.47.09.log Probleme résolu. Dans les preferences, onglet "scripts" il faut décocher la case "requires" et ca fonctionne. Si ca peut servir.

Ah ! du coup, si je comprends bien : «Attention, un étourdi peut en cacher un autre !». 🤣 Merci, et bon week-end.

C'est tout a fait volontaire. Et ca evite que les gens, quand ils traitent le résultat de stack, relance un traitement sur toute la séquence en voulant faire juste sur une image.

Bonjour, Lors du retrait de gradient sur la séquence, la coche Appliquer à la séquence disparaît une fois que l'on clique sur Appliquer. Cela conduit à douter et se demander si l'on l'a réellement cochée ou non. Il s'agit plus d'une gêne que d'autre chose, mais s'il était possible de faire en sorte que la coche demeure lors du traitement cela éviterait des haut-le-cœur aux étourdis dans mon genre. Siril 1.20-b2 sur Ubuntu 22.04. Crdlt, J.-Luc

Désolé j'avais pas vu la date😎 Je patiente !

Bonsoir Merci d'avoir répondu aussi rapidement. Je me plonge lentement dans la documentation et noté votre prochaine présentation à l'AIP Bien cordialement Bernard

merci l equipe

Merci beaucoup ☺️

Bonjour. Ca y'est, la documentation est enfin 100% traduite. Merci aux gens qui se sont investis dans cette tâche assez ingrate. Le lien est ici : https://siril.readthedocs.io/fr/latest/ Je vous souhaite une bonne lecture.

Merci à toute l'équipe pour le boulot. Siril est désormais une tuerie. Vous m'avez fait baver au RCE. Après l'avoir maintenant utilisé, je ne peux malheureusement vous décrire ici publiquement de quel autre réaction physiologique je fais l'objet . Encore merci, c'est très agréable.

Ah ben on a parlé de ça le 11 Mars et la bêta est sorti le 12.... non c'est pas dedans J'ai pas le droit de péter la détection d'etoiles la veille d'une release. J'ai pas encore regarde d'ailleurs

Hello, On est d'accord que ce pb n'est pas réglé dans la Beta 2 ? Samuel

J'ai aussi une ASI183MM et l'amp-glow n'est pas totalement retiré par le dark maître. Il reste toujours un peu de la tachouille centrale. Avec une QHY183C je n'ai jamais eu ce souci.

Tiens, à priori suis pas le seul avec la 183... https://www.cloudynights.com/topic/860772-qhy183m-amp-glow-elimination-workflow/ Je vais voir avec les prochaines prises que j'ai fait avant-hier, avec nouveaux darks faits à T stabilisée en dehors de la sessions, bias idem et en ayant pris soin de bien checker Gain et Offset de partout... A suivre... NOTE : les deux commentaires relatant un echec de calibration uniquement avec bias et nécessitant des dark-flats m'interpellent, on verra le résultat.

C'est vrai que le problème du fill2 siril c'est qu'on est limité à un rectangle parallèle aux bords de l'image. Du coup avec mes "rayures d'étoiles" obliques, c'est pas hyper pratique finalement ... Ca donne envie de pouvoir faire une rotation du boxselect 😉 Bon ceci dit même avec le plugin photoshop sur rognemedia, je n'ai pas vraiment réussi à obtenir ce que je voulais ou que j'avais en tête. J'ai un peu laissé tombé cette comète du coup snif. Mais j'ai eu une autre idée : faire des "hyperstacks" en empilant des images consécutives (sur les étoiles), histoire d'intensifier ces mêmes étoiles (sans flouter la comète). Aligner sur la comète, puis filer ça à starnet, puis empiler. Sauf que ça marche puis puisque je vais perdre l'horodatage avec les hyperstacks ... Bon je sais pas, saleté de comète 😄

Merci beaucoup pour ces explications. Je comprends bien que ces processus ne sont pas plus linéaires que la vie en général et je comprends que le rendement domine dans le vert, en plus d'avoir une double surface dans la matrice de bayer. 1) Un petit update sur la base d'une discussion sur le forum zwo : pour les lights problématiques ont visiblement été prises sans offset, quoi qu'en dise le header des fichiers fit. L'offset effectif était à 0. Il faut suspecter un problème informatique (en particulier un soucis avec APT, que j'utilise pourtant depuis une année sans problèmes). Cela explique la moyenne à 720 et donc l'impossibilité de soustraire les darks. 2) Un autre update : si je prend un flat fait avec un filtre uv-ir cut, j'obtiens des chiffres de l'ordre R=27k, G=26k et B=6K. Si on génère la couleur on trouve ceci : Or, si éclaircie, cette couleur fait vraiment penser à la couleur de la fibre qui compose le boitier de ma boite à flat. Je vais donc ajouter une couche de noir à l'intérieur. Je crois que je progresse EDIT : l'intérieur est déjà couvert intégralement de scotch noir. Il s'agit de la couleur des LED elle-même. Elle ont doivent avoir ce blanc "chaud et jaunêtre". Il faut que je change ceci. Le picker point sur la zone floutée (i.e. moyenne de ce qui passe à travers le filtre que j'ai intercalé entre les led et le plexi translucide (qui est lui bien blanc). Si on clique sur une led éteinte, on arrive à 94, 82, 17 % pour chaque canal. Un partie du problème doit donc être là.

Si tu parles des sigma pour l'étape de calibration (seul endroit ou il peut y'avoir un affichage rouge) alors non, il faut laisser comme c'est tant que ça va. Pour la partie empilement, il est maintenant possible de générer les cartes de rejet des pixels déviants. Autant en profiter pour trouver le meilleur rejet possible.

Merci pour les remarques je regardes ça ce weekend