Aller au contenu

Siril 0.9 Beta

lock042

Par lock042
dans Logiciel SIRIL

 Partager

Messages recommandés

gastropode

gastropode

Posté
Posté

Exemple de résultat obtenu.

Voir http://lerautal.lautre.net/journal/Astro/america1.jpg

800 iso 8 poses de 30 secondes

Ojectif de F 105 mm ouvert à F/4 (soit une ouverture de 2,6 cm... ce qui ne fait pas beaucoup).

On m'a fait remarquer que d'habitude, la couleur rouge était plus évidente.

Je n'ai fait aucune manipulation de couleur si ce n'est de diminuer le vert comme prévu dans Siril.

J'aime beaucoup la profusion d'étoiles...

  • Réponses 276
  • Créé
  • Dernière réponse

Les pipelettes du sujet

Les pipelettes du sujet

Images postées dans ce sujet

lock042

lock042

Posté
  • Auteur
Posté

Bonjour gastropode. La couleur rouge est évidente pour les appareil défiltrés. Sinon il n'en est rien car NGC7000 émet principalement dans le Ha.

Cyp

Cyp

Posté
Posté

Salut !

 

Une entrée de menu ? C'est à dire ? Si je l'ai mis là, c'est pour que ça soit dans la logique des appellations. En effet, la debayérisation est une conversion. Alors oui, on pourrait rajouter un onglet debayérisation mais ca rajouterait de la largeur à la fenêtre pour une utilisation qui n'est pas obligatoire (CCD)

 

Je ne pensais pas à un nouvel onglet, mais à une entrée dans le menu « Image processing », par exemple.

 

Hum, si normalement on fait ce genre d'opération en mode linéaire (avant d'avoir étirer l'histo) c'est pour éviter la monté de bruit. Il faudrait que je regarde plus en profondeur le pourquoi du comment.

 

Je suis bien d'accord sur le principe. Par contre, en pratique dans Siril, ça marche beaucoup moins bien ;)

 

Je suis d'accord avec tout ce que tu as dit, je vais pas faire une réponse détaillée vu que ça a déjà été fait, mais en résumé : nous allons continuer à améliorer et stabiliser Siril, il reste des bugs et des choses pas pratiques.

 

J'en suis bien conscient. Mes remarques n'étaient pas du tout des reproches, bien au contraire, vous avez fait un travail formidable qui demande beaucoup d'investissement et de temps. Si je peux vous aider en proposant quelques améliorations ou en décelant quelques bugs, je le ferais !

lock042

lock042

Posté
  • Auteur
Posté (modifié)
Je suis bien d'accord sur le principe. Par contre, en pratique dans Siril, ça marche beaucoup moins bien

 

En fait je pense que c'est du à la discrétisation de notre précision 16-bits non signés je pense. Or la soustraction du gradient s'opère dans un espace 32bits et est converti en 16-bits après. De même, la transformation de l'histogramme se fait en double. C'est fait ainsi afin de préparer une future version ou on sera en 32bits. On aura peu de changement à faire, cependant c'est la reconversion en 16-bits qui doit créer cette discrétisation.

 

 

 

J'en suis bien conscient. Mes remarques n'étaient pas du tout des reproches, bien au contraire, vous avez fait un travail formidable qui demande beaucoup d'investissement et de temps. Si je peux vous aider en proposant quelques améliorations ou en décelant quelques bugs, je le ferais !

 

Ne t'inquiète pas, tes remarques sont prises telles quelles, c'est à dire comme une source d'aide pour l'amélioration du logiciel. D'ailleurs tu m'a permis de corriger des bugs dans la version que je viens de mettre à jour ;).

Modifié par lock042
Cyp

Cyp

Posté
Posté

Salut !

 

J'ai téléchargé et compilé la version SVN. Et refait des tests sur mes images de M 101.

 

L'interface n'est pas instinctive. Je préfère le réécrire ici car je commence à m'y habituer, et cela risque donc de moins me gêner à l'avenir ; je n'aurai ainsi plus le regard frais du nouvel utilisateur. Les champs sources et destinations, la sélection des séquences, en charger toutes les images, la séquence d'image qui ne se met pas à jour après un traitement et qui nous fait donc travailler sur la précédente si on n'y fait pas attention, prendre l'habitude de re-sélectionner la bonne séquence même si a priori ce n'est pas nécessaire histoire d'être sûr, des champs qui semblent redondant, une démarche pas naturelle, une impression de faire plusieurs fois les même choses, une impression de fouillis, etc.

 

Comme dit, je ne reviendrai pas sur ce point car je suis en train de perdre le regard neuf de l'arrivant. Sans compter que je n'ai rien à proposer pour l'améliorer.

 

Concernant les méthodes de stack, en utilisant les paramètres par défaut, je trouve la « Percentile Clipping » très étrange car elle me sors des artefacts qui n'existent pas sur la version sans réjection. La « Linear Fit Clipping » sort avec un fort « grain ». La « Sigma Clipping » et « Winsorized Sigma Clipping » ne semblent pas présenter de grandes différences. La « Median Sigma Clipping » a ma préférence.

 

Toutes les méthodes de réjection créées un artefact autour des étoiles saturées (rectangle et points noirs, seulement sur la couche rouge). C'est avec la « Median Sigma Clipping » que c'est le moins notable. Peut-être qu'en jouant sur les paramètres, je peux arriver à améliorer la chose. Je n'ai pas essayé.

 

Concernant l'extraction du fond de ciel, la méthode « Spline » est étrange. L'affichage des boîtes m'indique clairement que la galaxie n'est pas prise en compte dans le calcul... mais elle apparaît pourtant bien sur le fond calculé (ainsi que les principales étoiles, d'ailleurs), avec en plus quelques artefacts sombres (grandes zones à 120° de la galaxie). La méthode « Polynomial » me semble bien meilleure (bien qu'imparfaite, des zones à forts gradients sont calculées trop doucement).

 

Par ailleurs, il est dommage de ne pas pouvoir revenir en arrière. Genre si la balance manuelle ne convient pas, ou la transformation d'histogramme, on est obligé de recharger l'image ; au risque d'ailleurs de perdre d'autres traitements si on n'a pas sauvegardé entre temps.

lock042

lock042

Posté
  • Auteur
Posté (modifié)

Je vais par manque de temps ne te répondre que sur un point pour l'instant,

Concernant les méthodes de stack, en utilisant les paramètres par défaut, je trouve la « Percentile Clipping » très étrange car elle me sors des artefacts qui n'existent pas sur la version sans réjection. La « Linear Fit Clipping » sort avec un fort « grain ». La « Sigma Clipping » et « Winsorized Sigma Clipping » ne semblent pas présenter de grandes différences. La « Median Sigma Clipping » a ma préférence.

 

Il faut a tout prix toucher aux paramètres. Tu auras des artefacts si par exemple tu as 20% de rejection sur la couche rouge. Il faut donc bien jouer avec les paramètres et faire en sorte de ne pas trop avoir de rejection. Pour ma part, le Winsorized Clipping me donne généralement de bon résultats. et je n'utilise quasiment que lui.

Le percentile Clipping n'est a utiliser que pour un set d'image petit (< 6). C'est sur qu'il faut le savoir et pour l'instant je n'ai pas eu le tps de tout détailler dans la doc. A choisir entre coder et faire la doc, j'ai choisis de coder. On peut trouver l'explication des algo sur la doc de pixinsight par contre : j'utilise les memes.

 

Il faut essayer de minimiser le bruit en sortie de stack. Qu'est ce qui a marqué sur la console après un stack ? les valeurs ?

 

Sinon, sur le background extraction. C'est vrai que j'ai pas mal de soucis avec, surtout au niveau du spline. Je ne suis pas l'auteur du moteur du code et j'ai des difficulté à l'intégrer. C'est pour ca que je suis en train de rajouter la selection manuelle des boites. Pour qu'il marche relativement bien, il ne faut pas hésiter a bien diminuer le nombre de boite par ligne. Mais je concède que le spline est un peu galère. Je vais continuer d'y travailler dessus. Promis. Sinon le polynomial fait le job mais n'a pas la souplesse d'un spline, ca c'est évident et mathématique.

Bref, tout n'est pas parfait, mais je pense qu'on peut faire des (pré-)traitement complet d'assez bonne facture quand même avec Siril.

Modifié par lock042
Cyp

Cyp

Posté
Posté

Merci de tes conseils. Je n'ai plus la sortie du terminal, mais j'y ferai plus attention la prochaine fois.

 

Pour ce test, j'ai donc retraité M 101. Je trouve que c'est de mieux en mieux à chaque fois ;) Effectivement, la dernière version était bien trop magenta. La nouvelle version est ici : http://www.cypouz.com/imagerie/080503/m-101

lock042

lock042

Posté
  • Auteur
Posté (modifié)

Ah oui !!!! Cette image est vraiment bonne la.

Bien joué.

 

Grosso modo :

 

- Quand tu fais les master bias et dark, tu choisis "no normalisation" et tu stack en mediane. Si tu choisis le Winsorized, tu peux, fais juste attention que le rejet soit aux alentours de 0.3 %

- Pour les flats pareil sauf que la normalisation doit être en multiplicative.

 

Ensuite y a plus qu'a stacker les images. La tu choisis une normalisation additive with scaling.

Si tes images brutes sont moins nombreuses que 6 alors le sum stacking (sans rejection) ou le percentile (avec rejection) vont très bien.

Si t'en a pas mal le Winsorized et le linear fit clipping sont sympa. Par contre surveille bien le taux de rejection. S'il est trop haut sur sig_high, alors tu augemente la valeur de sig_high. Pareil pour le bas.

Et surtout, tu compare les valeur de l'estimation du bruit qui doivent diminuer. Idéalement tu peux faire (ca se fait rapidement) un sum stacking et noter la valeur du bruit. Ensuite avec le Winsorized tu essayes de t'en rapprocher ;).

 

En gros, le taux de rejection est important à regarder si tu rejettes des pixels (c'est logique).

 

Voila,

Bonne soirée !!!

Modifié par lock042
gastropode

gastropode

Posté
Posté

L'interface n'est pas instinctive. Je préfère le réécrire ici car je commence à m'y habituer, et cela risque donc de moins me gêner à l'avenir ; je n'aurai ainsi plus le regard frais du nouvel utilisateur. Les champs sources et destinations, la sélection des séquences, en charger toutes les images, la séquence d'image qui ne se met pas à jour après un traitement et qui nous fait donc travailler sur la précédente si on n'y fait pas attention, prendre l'habitude de re-sélectionner la bonne séquence même si a priori ce n'est pas nécessaire histoire d'être sûr, des champs qui semblent redondant, une démarche pas naturelle, une impression de faire plusieurs fois les même choses, une impression de fouillis, etc...

J'expérimente les traitements d'images de fond de ciel avec Siril depuis un an et je comprends ce que tu appelles "le regard frais" : je ne l'ai plus depuis longtemps.

A ce titre, l'organisation des traitements qui va des images RAW pour aboutir à une image empilée me semble plutôt rationnelle et organisée en "coins".

Il y a le coin pour convertir, le coin pour les pré-traitements,...

Ce qui peut dérouter c'est d'avoir à convertir deux fois. Mais une fois que l'on en a compris la nécessité, la logique des séquences et des "coins" semble une réponse adaptée au traitement de la complexité.

Quand j'ai fini par comprendre, je me suis fait une "check-list" qui me permet de ne pas rater une étape. Le fait de donner des noms commençant par des lettres précises aide aussi.

Par exemple les RAW convertis en CFA deviennent des "b" quelque chose pour rappeler qu'ils sont "bayérisés".

Plus tard, ils deviennent des "db" parce qu'ils sont débayérisés...

Enfin chacun ses trucs.

Pour ce qui est des traitements qui viennent ensuite, c'est affaire de tâtonnements.

Si nous étions plus nombreux nous pourrions mettre en ligne quelques "bouts d'images FIT" que nous charcuterions concurrement de façon à faire sortir les réglages qui marchent.

vinvin

vinvin

Posté
Posté

Le genre d'astuce dont tu parles gastropode, avec les noms de fichiers pré ou postfixés, est une bonne illustration d'un défaut logiciel : c'est l'utilisateur qui doit savoir ce qu'il fait parce que le logiciel n'en est pas capable. C'est justement ce que je reproche à Iris, mais actuellement Siril ne fait pas beaucoup mieux au niveau de la convivialité et du "workflow", les étapes à suivre pour faire un traitement. Ce fonctionnement est d'ailleurs encore très proche de celui de la version 0.8 reprise il y a deux ans. On voit bien la différence quand on utilise Registax ou DSS.

 

J'aimerais bien que Siril fasse mieux, mais ça prend énormément de temps pour améliorer les choses. Et petit à petit ça avance. Depuis quelques semaines, quand on finit le dématriçage ou le pré-processing, la nouvelle séquence est automatiquement chargée, ça fait deux étapes de moins dans la check-list, mais il en reste beaucoup trop à mon goût.

 

Un point important est que Siril permet de traiter correctement les images et il a beaucoup progressé de ce point de vue là, C'est déjà mieux que rien, ce rien étant la raison de la reprise du projet pour en arriver là où nous en sommes.

 

Merci à vous pour vos commentaires, même négatifs, c'est toujours bon d'avoir un oeil neuf et extérieur, et de savoir qu'on ne l'a pas fait que pour nous. Siril avance avec vous aussi :)

Cyp

Cyp

Posté
Posté

Merci @gastropode pour tes « trucs » d'habitué.

 

@lock042, merci encore de tes conseils. C'est quoi de « bons » pourcentages de réjection ? Là, je teste sur mes 9 images de M 51, bien moins nombreuses que pour M 101, et j'obtiens un bruit à 2.017e-04 en simple stack, puis 2.400e-05 avec la réjection à 0 % – 3 % en Median Sigma Clipping.

 

@vinvin, je suis content de voir que tu as bien conscience des problèmes d'ergonomie dans la gestion du workflow :) En tout cas, vous pouvez être fiers du travail accompli. Perso, je comptes bien désormais l'utiliser systématiquement. Comme ça, avec gastropode, on sera deux à l'utiliser :D Et à bêta-tester, bien-sûr !

lock042

lock042

Posté
  • Auteur
Posté (modifié)

@lock042, merci encore de tes conseils. C'est quoi de « bons » pourcentages de réjection ? Là, je teste sur mes 9 images de M 51, bien moins nombreuses que pour M 101, et j'obtiens un bruit à 2.017e-04 en simple stack, puis 2.400e-05 avec la réjection à 0 % – 3 % en Median Sigma Clipping.

 

Hum c'est marrant que t'aies un bruit 10 fois moins important dans le second cas (ca doit être due a la normalisation qui est pas possible dans le sum stacking simple (d'ou l'importance de la normalisation)) .

 

Pour ce qui est des rejection, honnêtement je fais ca au juger. C'est pas crucial d'etre a 0.1% mais bon. Par exemple déja je regarde si changer les paramètres influe beaucoup sur les réjections.

Si oui alors j'évite de ne rejeter aucun pixel et j'évite de dépasser 1-1.5%

 

Mais encore une fois, c'est au jugé un peu. Dis toi que dans DSS on a aucun controle de ça ;)

Du coup je suis parfaitement d'accord avec Vinvin mais je nuancerai en disant que je suis contre le tout automatique. Pour les raisons expliqué juste au dessus par exemple. Avoir le controle de ce qu'on fait est vital. Même si ca oblige a lire la doc et a se renseigner :)

Modifié par lock042
Cyp

Cyp

Posté
Posté (modifié)

OK merci.

 

Concernant le Median Sigma Clipping et mes problèmes dans le rouge. En fait, les pixels saturés et rejetés apparaissent noirs. Sauf que c'est écrit que normalement ils sont remplacés par la valeur médiane. S'ils apparaissent tout de même noirs, c'est parce qu'ils sont rejetés dans toutes les images, c'est bien ça ? Ne pourrait-il pas y avoir un algorithme qui empêche ce cas-là ? Genre, qu'il fasse une moyenne des pixels qui entourent celui qui est rejeté, par exemple, histoire de ne pas apparaître noir.

Modifié par Cyp
lock042

lock042

Posté
  • Auteur
Posté (modifié)

Voudrai tu partager les 9 images que tu stacks sur un dropbox ?

Il serait plus facile pour moi de te dire avec les images.

 

Normalement l'algo a une protection pour ne pas rejeter tous les pixels. Il en garde forcément 3. Et en plus dans le median sigma clipping, il n'y a pas de rejet a proprement parler car c'est remplacé par la médiane.

Est-ce que ca serait un bug ? C'est bizarre car j'ai pas mal tester ces algos. Du coup il me faut essayer :).

Modifié par lock042
lock042

lock042

Posté
  • Auteur
Posté

Ne t'inquiète pas j'ai l'habitude.

Pendant ce temps quelle est ta sortie de console après le stack litigieux ? Fait moi un copié collé stp. et donne moi la valeur de tes sigmas.

Cyp

Cyp

Posté
Posté

J'ai essayé plusieurs combinaisons. En voici une :

01:49:00: Stacking in progress (sigma low=2.200, sigma high=2.000)...
01:49:43: Pixel rejection in channel #0: 2.121% - 3.479%
01:49:43: Pixel rejection in channel #1: 2.226% - 3.565%
01:49:43: Pixel rejection in channel #2: 2.064% - 3.611%
01:49:43: Rejection stacking complete. 9 have been stacked.
01:50:09: Noise estimation: 2.412e-05

Cyp

Cyp

Posté
Posté

Voilà, c'est uploadé. Zippé, ça ne fait plus que 140 Mo, c'est plus tolérable ;) Même lien et mot de passe que précédemment.

 

Voici ce que j'en tire : http://www.cypouz.com/imagerie/080501/m-51

 

Le Median Sigma Clipping n'est pas bien ajusté car il y a encore la trace d'un satellite sur la moitié gauche de l'image.

gastropode

gastropode

Posté
Posté
... c'est l'utilisateur qui doit savoir ce qu'il fait parce que le logiciel n'en est pas capable. C'est justement ce que je reproche à Iris, mais actuellement Siril ne fait pas beaucoup mieux au niveau de la convivialité et du "workflow", les étapes à suivre pour faire un traitement...

Un point important est que Siril permet de traiter correctement les images et il a beaucoup progressé de ce point de vue là...

 

1.

Siril traite de façon plus efficace les images (qu'avant).

Donc vous avez progressé et le logiciel est meilleur.

 

2.

Tu lui reproches un manque de convivialité.

Dans les évolutions envisagées, il y a l'enchaînement des commandes en utilisant des scripts. Les utilisateurs sont des "Unixiens" et accepteront (au moins pour certains) une interface qui ne soit pas du glisser-déplacer à "la tablette".

Cela existe dans Iris et c'est, de mon point de vue, un des points forts du logiciel.

Quant au fait que l'utilisateur doit savoir... L'utilisateur est le premier artisan de sa réussite et il me semble sain qu'il soit contraint de s'impliquer à minima.

lock042

lock042

Posté
  • Auteur
Posté (modifié)

OK. La rejection a 3% c'est assez élevé.

Moi j'obtiens ça en median sigma clipping stacking avec la normalisation (additive with scaling) :

09:28:42: Stacking in progress (sigma low=2.500, sigma high=2.200)...
09:29:17: Pixel rejection in channel #0: 0.378% - 1.461%
09:29:17: Pixel rejection in channel #1: 0.435% - 1.514%
09:29:17: Pixel rejection in channel #2: 0.359% - 1.542%
09:29:17: Rejection stacking complete. 9 have been stacked.
09:29:22: Noise estimation: 2.371e-05

 

Voici ce que j'obtiens. Je n'ai pas noté de soucis dans la couche rouge et on peut surement faire mieux niveau traitement surtout pour les couleurs. Mais tu as l'air de mieux le gérer que moi vu tes images.

mini_861846m51.jpg

Modifié par lock042
Cyp

Cyp

Posté
Posté

Quelles valeurs de sigma ?

 

La trace du satellite est toujours visible également. Bon, je suis d'accord que le nombre de pose est limite. Les artefacts sont bien là aussi. Je te fais une capture d'écran pour te montrer à quoi cela ressemble dans l'interface de Siril.

lock042

lock042

Posté
  • Auteur
Posté

Au temps pour moi je n'avais pas mis mes valeurs de sigma.

Je viens de corriger.

 

Tes artefacts, si tu regardes bien, sont présents sur tes images individuelles. Il est donc très difficile de les faire disparaître.

Ouf j'ai envie de dire car j'avais peur d'un bug ;)

 

mini_168824Capturedu20141128113015.png

lock042

lock042

Posté
  • Auteur
Posté (modifié)

Il est possible que cela vient du prétraitement tes artefacts. En effet, surveille bien la console quand tu fais le prétraitement et ca te dit si tu as du overflow. Si telle est le cas, ca te dit quoi faire ;)

 

EDIT :

dans la doc j'avais mis :

 

Siril automatically evaluates the normalisation coefficient used in the flat division. However, this value can be over-evaluated and in this case you will be warned into the console output. For example you can have this output :

 

Overflow detected, change level value in settings: 3278.00 is too high.

 

So, the solution consists to uncheck the auto-evaluation in settings and define your own value, smaller than 3278 in this example.

 

Après ca apparait peut-être sur tes images brutes ... dans ce cas la on peut pas faire grand chose

Modifié par lock042
Cyp

Cyp

Posté
Posté

Je n'y avais même pas regardé :) Pas de problème du coté de Siril, alors. Saleté de capteur :)

Cyp

Cyp

Posté
Posté

Je ne vois rien sur les images brutes CR2 mais ça ne veut pas dire que ce n'est pas déjà présent. Les artefacts apparaissent dès la débayerisation.

 Partager
Aller sur la liste des sujets

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.