Siril 0.9.0 stable

[patdut]

Je ne comprend pas ta dernière phrase. Sinon, non, Siril ne permet pas (pour l'instant) de faire du HDR. En attendant il existe l'excellent Enfuse pour faire ça sous Linux la (une interface graphique pour enfuse : Macrofusion).

 

 

 

Merci, c'est bien ce que j'entendais par faire avec les mimines, utiliser des logiciels tiers pour réaliser l'opération.

[Discret68]

Oui, il est faible.

 

Mais ce que je veux dire c'est que si chaque dark a un signal non cohérent d'une image à l'autre (donc de type bruit, et non signal thermique), il se peut que cela fasse ça. Même si le niveau de bruit est faible.

 

Pour l'AS7, je crois que même certaines personnes se passent de faire des darks. Essaye ce que je t'ai dis, et sinon tu fais un "Aucun Rejet".

 

J'ai fait l'essai avec rejet des pixels par Linear fit clipping et j'arrive à passer sous la barre des 0,5% de rejet.

 

Que penser des valeurs d'estimation du bruit sur les différents canaux ? Bon ? Pas bon ??? J'avoue que j'ai du mal à interpréter ces valeurs.

 

Effectivement, certains n'utilisent pas de darks ou de bias avec l'A7S, mais que veux tu, il faut bien que je me forge mon opinion par des tests

 

Bon, je vais passer au master dark, en espérant que tout se passe bien.

 

CR après empilement des bias :

12:00:13: Utilisation de 2048 Mo maximum pour l'empilement

12:00:13: Empilement : en cours...

12:00:13: Empiler toutes les images de la séquence (100)

12:00:16: Nous avons 57 blocs parallèles de taille 149 (+17) pour l'empilement.

12:00:16: Empiler...

12:05:34: Rejet des pixels dans le canal #0 : 0.132% - 0.303%

12:05:34: Rejet des pixels dans le canal #1 : 0.018% - 0.067%

12:05:34: Rejet des pixels dans le canal #2 : 0.053% - 0.250%

12:05:34: Intégration de 100 images :

12:05:34: Combinaison ............... moyenne

12:05:34: Normalisation ............. aucune

12:05:34: Rejet des pixels .......... Linear fit clipping

12:05:34: Paramètres de rejet ....... bas=2.500 haut=9.000

12:05:35: Fichier FITS enregistré : fichier IC1318 Bias_stacked.fit, 3 canal(aux), 4256x2848 pixels

12:05:35: Temps d'exécution : 5 min 23 s.

12:05:35: Estimation du bruit : (canal : #0) : 2.601 (3.969e-005)

12:05:35: Estimation du bruit : (canal : #1) : 1.423 (2.171e-005)

12:05:35: Estimation du bruit : (canal : #2) : 1.855 (2.830e-005)

[lock042]

L'estimation du bruit seul ne sert pas à grand chose.

Il est utile pour comparer quand on fait plusieurs tests.

 

Par exemple, tu peux comparer avec le Winsorized Sigma Clipping de tout à l'heure. Tu devais avoir beaucoup plus de bruit.

[Discret68]

L'estimation du bruit seul ne sert pas à grand chose.

Il est utile pour comparer quand on fait plusieurs tests.

 

Par exemple, tu peux comparer avec le Winsorized Sigma Clipping de tout à l'heure. Tu devais avoir beaucoup plus de bruit.

 

Avec le winsorized Sigma Clipping, j'avais ces valeurs :

10:05:10: Estimation du bruit : (canal : #0) : 2.571 (3.923e-005)

10:05:10: Estimation du bruit : (canal : #1) : 1.356 (2.070e-005)

10:05:10: Estimation du bruit : (canal : #2) : 1.674 (2.554e-005)

 

et avec le Linear Fit Clipping :

12:05:35: Estimation du bruit : (canal : #0) : 2.601 (3.969e-005)

12:05:35: Estimation du bruit : (canal : #1) : 1.423 (2.171e-005)

12:05:35: Estimation du bruit : (canal : #2) : 1.855 (2.830e-005)

 

C'est très très proche ! Une particularité de l'A7S peut-être ?

[Discret68]

Je continue mon apprentissage de Siril et me voila à nouveau bloqué

 

Les 3 masters sont créés et je me lance maintenant dans le pré-traitement des images.

 

Dans l'onglet Pré-traitement, j'ai sélectionné mes 3 masters.

 

J'ai coché la case "Activer la correction cosmétique" puis cliqué sur le bouton "Estimer".

 

Pour le Sigma "chaud", j'arrive à passer sous la barre des 10000pixels déviants (SIGMA 13 pour 6088 pixels).

 

Par contre, pour le Sigma "froid", impossible de descendre en dessous de 11873 pixels déviants même en augmentant le SIGMA au maximum (50).

 

Que faire dans ce cas de figure? Décocher le Sigma froid et ne conserver que le Sigma chaud ?

[mbnb24]

Déjà le master offset ne sert qu a pretraiter tes flats, ensuite tu l oublies

[lock042]

Dans certains cas, tu n'arrives pas a diminuer les pixels chauds (à cause du fait que les pixels négatifs ne peuvent exister). Dans ce cas, oui, décoche les pixels froids.

[Discret68]

Poursuite de mon expérience.

 

Je suis arrivé à l'empilement de mes 160 brutes pré-traitées. Au final, en utilisant l'outil statistiques et en comparant une brute avec l'image empilée, les valeurs du Sigma sur chaque couleur sont pratiquement identiques.

 

J'en déduis que le RSB n'a pas été amélioré par l'empilement

 

Dans la documentation, il est précisé qu'on peut améliorer le résultat en modifiant les valeurs de Sigma low et Sigma High. Histoire de m'éviter de partir dans tous les sens et vu le nombre d'images à empiler, dans quel sens faut il modifier ces valeurs de Sigma ?

 

La valeur du Sigma sur l'image empilée est-elle le seul critère révélateur du RSB ?

 

Merci à vous pour votre aide.

[lock042]

On ne regarde pas le gain RSB en regardant le sigma de l'image entière. Cela veut rien dire. Soit on fait le sigma d'une zone du fond du ciel soit dans le menu analyse on détermine le bruit.

[Cyp]

Pour faire les images de prétraitement maîtres sous Siril, je ne m'embête pas avec tout ça. J'utilise un bête empilement médian.

[vinvin]

Je suis bien d'accord avec Cyp.

[lock042]

Le problème de l'empilement médian c'est que le gain RSB n'est que de 0.8 x racine carré du nombre d'image. Là ou une moyenne avec rejet va froller les 1 x racine carré du nombre d'image.

 

Donc, en soustrayant un master empilé en médian on introduit un peu plus de bruit dans l'image qu'avec l'autre.

[Cyp]

Et la différence entre un empilement médian et une moyenne sans rejet ?

[lock042]

La moyenne sans rejet c'est 1 x la racine carré du nombre d'image. Donc meilleur RSB. Mais tu n'élimines pas les pixels qui peuvent être foireux comme ceux marqués par les cosmiques par exemple.

Modifié 11 octobre 2017 par lock042

[Cyp]

Disons que, pour une série de valeurs donnée, une d'entre elles — voire même deux — sont aberrantes. Elles vont « fortement » influencer une moyenne sans rejet, me semble-t-il. Alors qu'elles n'influenceront que très peu la médiane, non ?

[lock042]

Oui mais elles seront rejetés justement si on utilise un rejet. C'est pour ça que je precaunise ceci.

La moyenne avec rejet a les avantages de la moyenne en terme de RSB et ceux de la médiane en terme de rejet.

Modifié 11 octobre 2017 par lock042

[miroastro]

Bonsoir,

Tout d'abord merci pour ce logiciel, moi qui suis totalement ignare dans la programmation , je suis toujours épaté par de telle réalisation.

 

Mon Ordi fonctionne sous Windows 10 et j'ai installé hier votre logiciel Siril dont je suis avec intérêt ce post depuis sa mise en ligne.

 

Tout c'est déroulé sans accros, la première prise en main fût un peu tatillonne mais avec quelques manipulations la prise en main en fait, est plutôt sympa et assez intuitive, elle me rappelle un peu Iris mais en beaucoup plus simple et bien plus automatique, parfait pour moi, le résultat est plus que convainquant, j'ai fait un test sur une série d'images de M42 que j'ai comparé avec ce que j'avais fait avec DeepSkystacker, le résultat est plus que satisfaisant !

 

Pour moi tout fonctionne sous Windows 10 sans accrocs et sans Bug pour l'instant, je suis convaincu !

 

Bravo et merci pour tout ce travail !

 

Philippe.

[DDS]

Salut à tous,

Ne serait-il pas utile dans Siril d'avoir une fonction de purge des fichiers intermédiaires pour passer des raw vers l'image stackée ? (*.fit, pp*.fit, r_pp*.fit)

Ca prend vite de la place si on ne fait pas le ménage...

[mbnb24]

si tu fais attention tu peux ne pas mettre de préfixe et ca écrase l'étape d'avant

par contre, si tu fais une bétise, faut tout refaire

[vinvin]

C'est beaucoup plus facile de faire un

$ rm *.fit, pp*.fit, r_pp*.fit

que de programmer ça, parce que les noms dépendent de ce qu'a demandé l'utilisateur comme noms intermédiaires en plus alors il est le mieux placé pour supprimer ses propres fichiers.

[DDS]

C'est beaucoup plus facile de faire un

$ rm *.fit, pp*.fit, r_pp*.fit

que de programmer ça, parce que les noms dépendent de ce qu'a demandé l'utilisateur comme noms intermédiaires en plus alors il est le mieux placé pour supprimer ses propres fichiers.

 

Oui, bien compris.

Ou alors, supprimer automatiquement les fichiers précédents, à chaque étape de création de nouveaux fichiers...

 

C'est pas que le mode console me rebute, loin de là (je suis linuxien, et pas Windowsien). Mais si il pouvait y avoir une suppression automatique, ça ferait moins de manips, c'est tout. Mais je chipote

 

Merci encore pour ce logiciel

[vinvin]

Oui je vois, mais dans ce cas on risque de supprimer les images originales, c'est dangereux et pas simple de les identifier parmi les autres à 100%.

Merci de l'utiliser

[Cyp]

Yop !

 

Je suis en train de frôler la crise de nerfs à me taper la tête contre le mur Je maudits l'informatique, les jours comme ça

 

Je suis en train de traiter mes acquisitions lunaires du jour. Et Siril plante à répétition. C'est très pénible. Surtout quand je dois refaire la sélection de mes meilleures images à la main. Après avoir essayé toutes les combinaisons possibles pour comprendre d'où vient le plantage (erreur de segmentation, dixit le terminal), il semblerait que cela provienne de la normalisation au moment de l'empilement (à moins que ce ne soit que le symptome d'un problème en amont ?...). Si je ne choisis pas de normalisation, Siril ne plante pas.

 

Petit détail (qui a peut-être son importance), ce plantage ne survient — et dans ces conditions — seulement si je choisis d'empiler les images manuellement sélectionnées. Si je choisis d'empiler toutes les images de la séquence, ça ne plante pas.

 

À noter que cela s'est également produit les jours précédents, mais de manière assez isolée et aléatoire, et il me suffisait de réessayer pour que cela fonctionne. Aujourd'hui, c'est systématique. Et comme je suis en train de craquer, je vais la faire sans normalisation, tant pis

 

Remarques supplémentaires :

 

• Dans la fenêtre de visualisation, il serait bien de pouvoir visionner les images en appliquant le décalage calculé lors de l'alignement. Pour une sélection manuelle des images, l'œil est très performant si les détails restent parfaitement au même endroit, nettement moins si l'image se décale, ne serait-ce qu'un petit peu, entre chaque image ;
  
• Toujours dans cette fenêtre de visualisation, il serait bien d'avoir un raccourci clavier pour afficher rapidement l'image suivante ou précédente, afin d'alterner suffisamment rapidement pour apprécier les différences de qualité.
  

[vinvin]

Merci Cyp pour le rapport et désolé pour le temps perdu, c'est très énervant. J'essaierai de corriger ça bientôt. Pour la comparaison et le tri manuel des images, j'utilise les aperçus dans la fenêtre de registration qui permettent d'avoir en transparence une image de référence et l'image courante, et qui les affichent avec le bon alignement.

Une autre possibilité avant que nous permettions un affichage global qui prenne en compte les données de registration, c'est d'exporter la séquence, dans l'onglet séquence, la nouvelle sera bien alignée.

Et pour passer d'une image à l'autre ou la sélectionner, je suis d'accord qu'un raccourci supplémentaire serait bien, en attendant j'utilise la liste des images à gauche de la vue de l'image, on peut se ballader dedans avec les flèches et les touches espace et entrée.

[Cyp]

Tu n'as pas à être désolé ! Faut pas déconner, c'est vous qui faites tout le boulot Juste de la frustration de ma part

 

Oui, j'avais bien pensé à exporter, mais bon, il y a peut-être moyen de faire plus léger. Sinon, j'utilise aussi la liste à gauche de la fenêtre de visualisation, bien-sûr. Mais, à la souris, ça oblige de faire des allers-retours avec les yeux, et c'est pas idéal. Au clavier, c'est plus lent. Et puis il faut quand même vérifier si on n'est pas sur une image déjà décochée. D'ailleurs, pour ça, ce serait bien de pouvoir masquer les images décochées. Ainsi, on passerait directement à l'image cochée suivante ou précédente, afin de correctement comparer les images encore en lice entre-elles plutôt que de devoir repasser celles qu'on ne veut pas ou devoir y aller à la souris.

[lock042]

Salut.

Désolé pour le plantage qui ne devrait pas exister. Comme quoi on ne teste jamais assez.

Sache cependant que la normalisation ne sert à rien pour tes images. En effet, vu la luminosité de la lune je présume que le fdc de chaque image est identique ou au moins très proche.

De fait la correction apportée est proche de 0.

[vinvin]

La normalisation c'est offset + scale non ? Peut-être qu'il y a un scale applicable quand même ?

[lock042]

Si les conditions de prise de vue sont identiques, et qu'il n'y a pas un changement drastique de la qualité du ciel, je ne pense pas que cela soit à prendre en compte.

[TIbasic]

Encore un succès pour Siril, quasi aucune retouche après le traitement mis à part un peu d'anti bruit pour le fdc sous rawtherapee ! Je crois que je commence à maîtriser la bête, l'empilement marche du feu de dieu maintenant ! Merci à l'équipe !!!

 

http://www.webastro.net/forum/showthread.php?t=152683

[Cyp]

Salut !

 

Petite remarque ergonomique. Après une sélection manuelle des images dans la fenêtre de prévisualisation, le bouton radio « Aligner seulement les images sélectionnées » est automatiquement choisi dans l'onglet Alignement. Je trouve ça bien, et ça me paraît logique. Ce serait bien que cela soit pareil dans l'onglet Empilement.