SIRIL : Traitement d'images sous Linux

Pour nos amis qui travaillent sous Linux, j'ai trouvé ce lien en parcourant le net : http://dulle.free.fr/alidade/siril.php

Merci Sébastien,

Il ne faut négliger les utilisateurs de Linux.

Siril vise les astronomes amateurs qui ont acquis des images et qui veulent les traiter avec des moyens semi-automatiques. Il fournit une interface plus conviviale que la ligne de commande d'Iris, mais n'est pas autant automatisé que DeepSkyStacker ou Registax. Il fournit toutefois une ligne de commande pour accéder facilement à différentes fonctions de traitement.

Siril est capable de traiter des images planétaires (un grand nombre de petites images) aussi bien que de ciel profond (un nombre réduit d'images de grande taille avec un important pré-traitement). La registration est capable d'aligner automatiquement (seulement en translation pour l'instant) les images planétaires en utilisant une transformée de Fourier discrète, et les images de ciel profond en utilisant la PSF sur une étoile de référence, il ne faut donc pas un décalage trop important des images. La fonctionnalité d'alignement manuel rend Siril aussi utile aux astronomes amateurs ayant des images de mauvaise qualité ou plus généralement pour lesquelles les logiciels automatisés ont le plus de mal à trouver les points d'alignement.

Toutes les infos ici : http://free-astro.vinvin.tf/index.php/Siril/fr

J'en traite dans une de mes prochaines conférences, si cela vous intéresse... 

Rem : Iris for Linux = sirI-L 

ttf a écrit:

J'en traite dans une de mes prochaines conférences, si cela vous intéresse... 

Je suis pour !

Planification, planification... 

J'ai envoyé un mail à Julien sur le sujet... 

Tiens, petit parallèle "IRIS" <> "Siril" en terme de fonctions de base (au niveau ligne de commande), je ferai cela au fur et à mesure... 

ADD_MAX (IRIS, SIRIL)
Supposons l'intensité I1(x,y) d'un pixel de l'image I1 aux coordonnées (x,y) et l'intensité I2(x,y) d'un pixel de l'image I2 aux mêmes coordonnées (x,y). 

ADD_MAX produit une nouvelle image, I, où l'intensité du pixel (x,y) est :
I(x,y)=I1(x,y) if I2 <= I1
I(x,y)=I2(x,y) if I2 > I1

En d'autres termes, un pixel de l'image I1 est remplacé par un pixel de l'image I2 si l'intensité locale de I2 est supérieure à celle de I1.

ADD_MAX est compatible 16 bits (images en niveaux de gris) et 48 bits (images en vrais couleurs).

Si on applique cette commande à une séquence d'images, très efficace pour construire des
images de traînées d'étoiles longue pose, même lorsque le fond de ciel est lumineux.

Exemple :

BG (IRIS, SIRIL)
Renvoie la valeur du niveau du fond de ciel de l’image affiché.

Un essai sur la même image donne 
- Siril : Valeur de fond du ciel : 174
- IRIS : Background : 61

Dans les manuels, peu de description sur le fonctionnement, 
seulement "return the median sky background"

On pourrait donc s'attendre à une valeur statistique simple... 
(évaluation des valeurs de chaque point + moyenne simple)

Un usage simple est l'estimation du "point bas du ciel".
Dans IRIS, on estimait généralement qu'un niveau "background" moyen doit être entre 20 et 50...
Donc, si le résultat de BG est 134, il faut faire -104 (OFFSET) sur l'image pour récupérer 30,
par exemple...

Donc : 50 sur 32767, c'est faible... Mais ce n'est pas zéro ! 
Perso, je n'appliquait pas trop la règle, je le faisait au "visuel"... 

Ici, on a clairement une manière différente d'évalue le "background"...
D'où vient cette différence ? 

La fonction "Stat" peut-elle aider ?

STAT (IRIS, SIRIL)
Renvoie les statistiques globales de l’image

Sous IRIS
*** Couche rouge ***
Moyenne : 266.8      Médiane : 135 Sigma : 339.3
Maximun : 32767.0     Minimum : 0.0

*** Couche verte ***
Moyenne : 112.3      Médiane : 61 Sigma : 176.9
Maximun : 14940.0     Minimum : 0.0

*** Couche bleue ***
Moyenne : 162.8      Médiane : 43 Sigma : 214.3
Maximun : 14940.0     Minimum : 0.0
 
=> clairement, la mesure de BG = mesure de la médiane de la couche verte... 

Sous SIRIL

Canal Red : Moyenne : 388.7, Médiane : 298.0, Sigma : 347.0, AvgDev : 245.4, Min : 1.0,
Max : 33763.0
Canal Green : Moyenne : 221.7, Médiane : 174.0, Sigma : 193.6, AvgDev : 140.5, Min : 1.0,
Max : 14940.0
Canal Blue : Moyenne : 252.0, Médiane : 195.0, Sigma : 220.4, AvgDev : 160.5, Min : 1.0,
Max : 14940.0

=> identique... Donc BG (théorique) de IRIS = BG (théorique) de SIRIL 

Mais par contre, ce sont les valeurs évaluées qui ont le plus changé... 
   

	Moy Red	Moy Green	Moy Blue	BG	Min	Max red	Max green	Max blue
IRIS	266,8	112,3	162,8	61	0	32767	14940	14940
SIRIL	388,7	221,7	252	174	1	33763	14940	14940
Ratio	1,46	1,97	1,55	2,85		1,03	1,00	1,00

Le ratio indiquerai comme une "courbe" de correction de balance de blanc...
Alors que les valeurs "max" sont quasi identiques...
Mais en désactivant toutes les options de "balance de blanc" de SIRIL, rien ne change...

=> Mwais, faudra y revenir... 

BGNOISE (IRIS, SIRIL)
Renvoie la valeur du niveau de bruit de fond de l’image affiché (bruit RMS).

IRIS : Bruit RMS : 171.884

SIRIL :  
Déviation standard du bruit : calcul en cours...
Estimation du bruit : (canal : #0) : 250.912 (3.829e-03)
Estimation du bruit : (canal : #1) : 163.493 (2.495e-03)
Estimation du bruit : (canal : #2) : 173.868 (2.653e-03)

Mwais... idem, faudra comprendre... 

CDG (IRIS)
Retourne les coordonnées du centre de gravité dans la zone sélectionnée avec la souris.

Ex : pas possible sur mon image... (zoom 1x trop grand pour une sélection)

CDG (SIRIL)
Return the coordinates of the center of gravity of the image

Ex : Les coordonnées du centre de gravité sont (0.000, 2056.000)

=> avantage SIRIL, il ne faut pas sélectionner toute l'image...

COSME et FIND_HOT (IRIS, SIRIL)

Subissent un petit lifting... Mais bizarre, en soi... 

Le but de COSME : corriger les "pixels chauds" (détectés dans un dark, par exemple...) et 
pour cela, utiliser un ficher (.lst) qui contiendra (en mode texte) les coordonnées des points à corriger.

Le but de FIND_HOT : déterminer les points "chauds" à corriger dans une image et créer un fichier 
qui les contient (.lst)

Donc, on fait "find_hot" avant "cosme"... 

1ère différence : syntaxe
Sous IRIS, la syntaxe est P(p) x y avec p = optionnel, le plan couleur concerné (R,B,G)  
Sous SIRIL, la syntaxe est (o) x y (t) avec 
o = objet, P(ixel), C(olumn), L(ine)
x,y = coordonnée
t = optionnel, le type H(ot) ou C(old)

Donc, sous SIRIL : 
C x 0 = corrige la colonne à x
L y 0 = corrige la ligne à y

En IRIS, il fallait utiliser la comme REPAIR(X ou Y)
 
2ème différence : invocation
IRIS, SIRIL : COSME filename

IRIS : FIND_HOT filename seuil
SIRIL : FIND_HOT filename cold_sigma hot_sigma
 
=> sous SIRIL, on peut déterminer une "fourchette" pour les déterminer

IRIS : l'analyse se fait en une fois sur les 3 plans couleurs
SIRIL : l'analyse ne se fait que sur un plan (à extraire d'une image raw)
 
=> Plus restrictif... Mais cela dépend ce que l'on cherche...

IRIS : max 500 étoiles par fichier et la détection s'arrête à 10000 points 
SIRIL : apparemment, pas de limite... (J'ai été jusque 300000 sans problèmes)
 
=> SIRIL permet de détecter tout...
 
Intéressant, mais il faut tester...

DDP... (IRIS, SIRIL)

Du complexe... 
Faisons le tour pour ceux qui ne connaissent pas... 

ddp level coef sigma

"Performs a DDP (digital development processing) as described first by Kunihiko Okano. This implementation is the one described in IRIS. It combines a linear distribution on low levels (below level) and a non-linear on high levels. It uses a Gaussian filter of sigma sigma multiplies the resulting image by coef. The typical values for sigma are included between 0.7 and 2"

ok, décodons... 
- il modifie chaque pixel
- il modifie la distribution des valeurs sur l'ensemble de l'image
- la formule : If I(x,y) is the input image, than the output image is:
I'(x,y) = coefficient * level * {I(x,y)/([I(x,y)] + level)}

La question est de savoir si la linéarité d'un CCD est importante pour ceux qui veulent "une belle" 
photo... La réponse est évidemment non ! (peut importe si toutes les magnitudes ne veulent 
rien dire, si c'est joli...)

Donc : la dynamique réelle d'une CCD dépasse largement se que l'on publie (ex: JPEG...)
Mais de facto, certaines régions vont "saturer" rapidement si on descend le nombre de niveaux.

Cette formule va avoir comme effet de "distribuer" plus "hyperboliquement" (courbe en S) les valeurs... 

Sigma : va régler les "détails" et si >0, on affine... Mais attention de ne pas exagérer (>2)

Ex : avant DDP / Après DDP (coef 5, sigma 0.8 )



Ex : 


Et après DDP ; Coef 3, sigma 1


Bon, on reviendra sur l'évaluation des valeurs cibles... Cela dépend de plusieurs paramètres...
Mais c'est une fonction intéressante...

ENTROPY (IRIS, SIRIL)

Return the value of the entropy in a zone of the image selected with the mouse.

Rappelons que mesurer l'entropie, c'est mesurer le désordre... 

Donc, une autre méthode pour mesurer le "bruit" (ou le signal) dans une image...

Sur la même zone...
IRIS :   Entropie : 5.0472
SIRIL :  Entropie : 0.795


Visiblement, ils n'ont pas la même notion de désordre 

Bon, la raison des différences entre les mesures est toujours à creuser... 

EXTRACT (SIRIL)

Extracts NbPlane Planes of Wavelet domain. 

Testons avec une photo de Lune (prise au hasard, pas à Pouf) 



Et faisons "extract 6", et nous obtenons 

Fichier FITS enregistré : fichier layer00.fit, 3 canal(aux), 776x584 pixels
Fichier FITS enregistré : fichier layer01.fit, 3 canal(aux), 776x584 pixels
Fichier FITS enregistré : fichier layer02.fit, 3 canal(aux), 776x584 pixels
Fichier FITS enregistré : fichier layer03.fit, 3 canal(aux), 776x584 pixels
Fichier FITS enregistré : fichier layer04.fit, 3 canal(aux), 776x584 pixels
Fichier FITS enregistré : fichier layer05.fit, 3 canal(aux), 776x584 pixels



Ce qui a l'air d'être les niveaux de décomposition par wavelet
On peut s'en servir comme masques, au besoin...

FFTD et FFTI (IRIS, SIRIL)

"Fourier Fast Transform" et son inverse... 

Fonctionnent apparemment de la même façon... 
Difficile de trouver un cas "utile" directement pour illustrer... 

Je reprends l'exemple bien connu... 

=> il y a un "parasite" électrique (pattern régulier) lors de la capture... 
=> ce genre de signal va apparaître lors de conversion via Fourier

Idem dans Siril


Un "FFTD a b"

Donne 


Ce qui différent que la version fournie par IRIS


OK, on fait idem que dans IRIS, sélection des zones "parasites" et "FILL 0" ensuite


Après Fill


On procède la même façon avec l'autre anomalie... 

Puis : sauver l'image... SAVE x

Retour à la normale... FFTI x b


Ce qui n'est pas terrible ! 
Mwais... 

Oui, mais, si je rentre dans les fonctions "affichées" de SIRIL (Fourier et Inverse) 

Et bien, SANS rien modifier, (donc, FFT, puis invers sur base des fichiers construit) on obtient la même chose... !!!

(avec la parasite en plus... )

Mais en testant dans IRIS : j'ai aussi des problèmes...(image obscurcie)
 
=> Donc : problème avec le fichier d'entrée... Revoir cette fonction en détails !