Siril, Problème de flats, Poses courtes, et un bonus en image !

[Roch 1 898]

Salut la compagnie

Bon après une petite pause me revoilà pour utiliser à fond ma nouvelle caméra. Cependant, qui dit grand capteur dit flats
Or je pense avoir mis le doigt sur un problème et je n'ai pour le moment pas de solutions.

Pour utiliser un flat, on va en général diviser notre image prétraitée par ce dernier. Le problème vient du fait que Siril ne gère pas les valeurs négatives.
Quand on fait une pose longue, même après un retrait du dark, on n'a pas de soucis de valeurs négatives puisque le fond de ciel est bien présent. L'écrasante majorité des pixels restent donc dans un domaine positif.
Cependant, en poses courtes, en soustrayant un dark, puisque le fond de ciel est quasiment invisible ( tout dépend de la durée de la pose mais passons ) ben le pixel a une chance sur deux de se retrouver dans les négatifs en théorie.

Si on ne fait qu'enlever un dark, comme souvent en pose courte, pas de panique : il suffit d'ajouter une constante au préalable, et hop, plus de valeur négatives, plus de problème.
Sauf que si on veut retirer un flat, ben ce n'est plus possible car il faut que le flat s'applique à l'image du ciel et à elle seule. donc pas question d'ajouter une constante !

Quand je réalise un prétraitement classique, je me retrouve donc avec une proportion significative de mes pixels qui tombe à zéro, ce qui entraine une perte de sensibilité d'une part, mais également une sur-correction des flats dans les coins. Cela vient du fait que plus de pixels atteindront zéro dans les coins du fait du vignettage.
Et si j'ajoute une constante, là du coup je ne corrige plus assez. Je pourrais trouver la bonne constante à ajouter pour compenser tout juste la différente, mais celle-ci varie au cours de la nuit puisque la luminosité du ciel aussi... je vous raconte pas le b.rdel

Voilà. Y a-t-il une solution à ce problème dans Siril ? Une astuce à laquelle je n'aurais pas pensé ?

En attendant, une petite mise en bouche des images à venir... NGC6888 d'il y a quelques jours  ( avec un gradient compliqué à gérer, si vous avez lu ci-dessus vous aurez compris pourquoi )

 

Bons cieux !

Romain

[Cyril Richard 1 302]

Il y a 2 heures, Roch a dit :

Le problème vient du fait que Siril ne gère pas les valeurs négatives

Justement si.

Siril reconnaît les négatif si on bosse en 32bits.

[Roch 1 898]

Aaaah intéressant !

Je bossais en 16 bits jusqu'à l'empilement et 32 après...

 

Vais tester tout ça et je reviens après

 

Romain

 

[Maïcé 991]

Pas mal la mise en bouche... Ça promet pour la suite !

[jean dijon 1 761]

Il y a 14 heures, Cyril Richard a dit :

Siril reconnaît les négatif si on bosse en 32bits.

Bonjour,

comment passe t'on en 32 bits après l'acquisition des fichiers en 16 bits? Siril me dit qu'il ne peut pas convertir une séquence 16 bits en 32 bits

j'utilise la version 1.0.2

 

jean

[Cyril Richard 1 302]

C'est le comportement par défaut. Les fichiers 16bits sont transformés en 32 pendant le prétraitement.

Sauf si dans les préférences on a choisit de rester en 16bits.

[alx 103]

Il y a 17 heures, Roch a dit :

Pour utiliser un flat, on va en général diviser notre image prétraitée par ce dernier. Le problème vient du fait que Siril ne gère pas les valeurs négatives.

 

Je ne comprends pas bien. Un ''flat'' sert à égaliser l'éclairement sur la caméra, qui peut ne pas être uniforme à cause du parcourt optique dans le télescope (s'il s'agit simplement de corriger des saletés  sur la fenêtre de la caméra, il vaut mieux utiliser un chiffon plutôt qu'un ordinateur ).

Un flat est en général construit à partir d'un éclairement uniforme au 2/3 de la dynamique, par exemple. S'il y a des pixels à zéro, c'est qu'il y a un sérieux problème de vignettage !

alx.

[Roch 1 898]

Il y a 1 heure, alx a dit :

Je ne comprends pas bien. Un ''flat'' sert à égaliser l'éclairement sur la caméra

 

Le problème ne vient pas du flat en lui même mais de l'image a prétraiter.

Si le fond et sombre, et qu'on retire un dark, certains pixels doivent pouvoir se retrouver en négatif. Et d'autant plus dans les coins ou le vignetage rend le fond encore plus sombre.

Si c'est impossible, on a donc une image en moyenne trop "claire" dans les coins puisque les valeurs négatives montent à zéro.

Donc le flat ( qui n'a pas ce pb lui ) se retrouve à surcorriger.

 

Merci aux intervenants

 

Bon c'est bcp demander, mais j'imagine que c'est pas possible de rester en 16bits pour cette option ? Non parce que le traitement est deux fois plus long, et quand c'est déjà long a la base, ben ça fait encore plus long

 

Ou autre option : possible de commencer en 32 bits pour le prétraitement puis repasser en 16 bits après ? Ce qui prend le temps c'est surtout l'alignement et empilement drizzle x2 donc même une étape en plus pour repasser en 16b serait pas dramatique...

 

Romain

 

 

Modifié 21 juillet 2022 par Roch

[exaxe17 5 756]

il y a 23 minutes, Roch a dit :

Bon c'est bcp demander, mais j'imagine que c'est pas possible de rester en 16bits pour cette option ? Non parce que le traitement est deux fois plus long, et quand c'est déjà long a la base, ben ça fait encore plus long

salut Romain!

Et juste pour voir si il y a la meme chose ,tu as essayé avec As! avec le retrait des flat? ou même pipp?

 

[Roch 1 898]

Hmm je vais tester ça aussi

[LucaR 1 093]

Tu peux ptet d'abord ajouter un offset artificiel (une constante, Siril le permet) à toutes tes brutes DOF comprises, avant de passer au prétraitement? Après-tout c'est ce que font la plupart des caméras, justement pour éviter ce genre de souci => si ce n'est pas assez la solution est ptet d'en rajouter encore un peu.

[alx 103]

Il y a 2 heures, Roch a dit :

Le problème ne vient pas du flat en lui même mais de l'image a prétraiter.

Si le fond et sombre, et qu'on retire un dark, certains pixels doivent pouvoir se retrouver en négatif. Et d'autant plus dans les coins ou le vignetage rend le fond encore plus sombre.

Si c'est impossible, on a donc une image en moyenne trop "claire" dans les coins puisque les valeurs négatives montent à zéro.

Donc le flat ( qui n'a pas ce pb lui ) se retrouve à surcorriger.

 

La réponse que je donnerais est qu'il n'ya rien à corriger puisque rien n'est mesuré ! Je m'explique.

A  supposer que le "dark" soustrait soit exactement représentatif de la réponse de la caméra sans signal optique et mesure un vrai zéro (ce qui n'est qu'approximativement le cas), la mesure des points dans un intervalle de plusieurs sigmas autour de ce zéro est indéterminée, mais de moins en moins mal à mesure qu'on s'en éloigne vers les valeurs positives. Pour un signal nul affecté d'un bruit additif gaussien d'écart-type sigma (le cas d'école), 34 % des valeurs mesurées vont être trouvés au delà de 1 sigma autour de zéro, 5% au delà de  2 sigmas, 0.3% au delà de 3 sigmas, etc...

Donc positives ou négatives, même pour un signal strictement égal à zéro.

Il faut donc agir en fonction du bruit estimé, lequel n'est d'ailleurs pas vraiment gaussien (en réalité un mélange de  gaussien, de Poisson et autres).

Je recommanderais donc, à première vue, de NE PAS égaliser les valeurs trop proches de zéro, et de simplement les considérer nulles.

alx.

Modifié 21 juillet 2022 par alx
erreur de rédaction

[cissou8 18]

@Roch, y a peut-etre moyen de faire qqchose en restant en 16b, mais pour cela il faudrait verifier si ton niveau varie pas trop au cours de la session. Tu peux faire un seqstat sur la sequence avant pretraitement, et me faire passer le fichier, ainsi qu'une light, ton masterdark et ton masterdark stp?

 

Cecile