Des nouveautés dans Siril, en attendant la beta

lock042 · 24 avril 2014

Et voici une petite vidéo sur la façon dont Siril peut corriger la colorimétrie de vos images :

http://free-astro.vinvin.tf/videos/EqualizeCP.webm

gastropode · 29 avril 2014

Tu as donc les FWHM qui sont remplies. Vérifie que les valeurs soient assez homogènes. Une valeur très différente pour une image pourrait indiquer que ce n'est pas la bonne étoile qui a été sélectionnée pour cette image. L'idéal étant de prendre une étoile brillante, (non saturé de préférence : mais ça c'est difficile avec des images d'APN) et isolée.

Ensuite tu peux faire la registration (Layer Green toujours) en FWHM registration et en sélectionnant au préalable comme image de référence l'image avec la plus faible FWHM.

Je confirme le bon fonctionnement de cette étape du logiciel.

Merci aux développeurs pour leur réactivité.

gastropode · 8 mai 2014

L'image suivante est un exemple d'usage de Siril... un peu à contre-emploi.

Mercredi soir, 7/05/2014 dix photos de 5 secondes sur pied fixe (sans suivi équatorial) dans la Vierge, de façon à capturer les positions de Ceres et de Vesta.

Objectif macro de 40 mm de focale ouvert à F/2.8

Premier quartier de Lune pas très loin, banlieue de Châteauroux avec éclairage dans la rue.

Photos en JPEG... cela passe !

http://lerautal.lautre.net/journal/AAI/pallas/somme_diximages.jpg

Le contraste a été augmenté sous Gimp.

Compte tenu des circonstances, le cliché me semble bien meilleur que ce que j'espérais.

Siril ne plante plus depuis que j'ai installé la version 455.

Eric S · 9 mai 2014

L'image suivante est un exemple d'usage de Siril... un peu à contre-emploi.
Mercredi soir, 7/05/2014 dix photos de 5 secondes sur pied fixe

[...]

Je vais être médisant mais là, tu additionnes surtout du bruit de lecture

Néanmoins, à mes débuts, j'avais essayé avec Iris d'empiler des photos grand champ sans suivi et je n'étais arrivé à rien de concluant. J'ai un exemple plus récent avec la Voie Lactée au fisheye et sans suivi. Toujours difficile avec Iris. Je pense que j'avais fait une registration manuelle avec QR3 sur une vingtaine d'étoiles par image. Si quelqu'un veut tester Siril dessus, je peux fournir les brutes

vinvin · 9 mai 2014

Oui il faudrait faire quelques darks et bias, ça améliorerait un peu les choses, vu que quand on empile des images qui ne sont pas alignées, les pixels chauds font généralement des traits qui n'existent pas.

J'ai déjà utilisé Siril pour aligner des images grand champ longue pose pour faire un filé d'étoiles circumpolaire, et vu qu'il n'y a pas de point fixe entre les images il faut les aligner à la main, ce que Siril permet de faire assez bien il me semble.

Merci gastropode de partager tes résultats en tout cas, ça fait plaisir !

A bientôt

gastropode · 12 mai 2014

Oui il faudrait faire quelques darks et bias, ça améliorerait un peu les choses, vu que quand on empile des images qui ne sont pas alignées, les pixels chauds font généralement des traits qui n'existent pas....
Merci gastropode de partager tes résultats en tout cas, ça fait plaisir !

A bientôt

La critique précédente est évidente : la photo affiche beaucoup d'information (sic) non désirée.

Ceci étant, elle résulte de choix hasardeux successifs :

- le pied fixe

- l'enregistrement en JPEG en format "moyen" : on ne trouve pas la correspondance pixel à pixel, le boitier a fait sa cuisine pour sortir une image moins grande... et non pas en RAW où Siril est "à l'aise".

Pourquoi un tels choix ?

L'intention était de retrouver à moindre contrariété (matériel léger, plus petits cliché) les deux astéroïdes Ceres et Vesta. Il a été facile de répéter, par jeu, le même cliché 10 fois, pour pouvoir tester ce que pouvait donner un empilement de tels résultats.

Le lendemain j'ai fait avec les mêmes réglage 10 darks et 10 offsets.

Cela a donné l'image mise en ligne. J'en suis assez content parce qu'elle me permet de retrouver plus d'étoiles que si je n'avais qu'un seul cliché.

Malgré ses défauts elle démontre la faisabilité d'une telle manipulation "bas de gamme"... et c'est pourquoi je l'ai mise en ligne.

gastropode · 12 mai 2014

Cela a donné l'image mise en ligne. J'en suis assez content parce qu'elle me permet de retrouver plus d'étoiles que si je n'avais qu'un seul cliché.

Afin d'illustrer ce qui précède, voici une image avec un extrait d'une même zone du ciel :

- à gauche : ce qui figure sur Une seule image

- à droite : ce qui figure sur l'empilement de 10 images.

http://www.webastro.net/forum/attachment.php?attachmentid=25923&stc=1&d=1399929908

gastropode · 14 mai 2014

J'ai téléchargé, compilé et installé la dernière version (du moment).

Cela m'a donné l'occasion d'expérimenter l'outil appelé "Dynamic PSF".

Voir à ce propos : http://free-astro.vinvin.tf/index.php/Siril:PSF

Je trouve cet outil extrèmement intéressant.

lock042 · 15 mai 2014

Pour les allergiques à l'anglais j'avais fait une vidéo tuto en français :

http://free-astro.vinvin.tf/videos/DPSF_vf.webm

Eric S · 15 mai 2014

J'ai des question sur la détermination de la PSF.

À la première étape d'identification paramétrique sans angle, quel sens ça a de déterminer indépendamment FWHMx et FWHMy? Sauf à avoir des pixels rectangulaires ou un autre défaut sur la chaîne optique, on ne s'attend pas à ce que les étoiles soient plus allongées sur un axe du capteur que l'autre. Sur la vidéo (0:10), on voit d'ailleurs des valeurs assez proches. Sont-elles différentes si on tenait compte des barres d'erreur? Quitte à simplifier, pourquoi ne pas prendre FWHMx=FWHMy à la première étape?

Pour la seconde étape, vous utilisez le critère SigmaX-SigmaY>0,01 pour décider d'optimiser ou non l'angle. On peut imaginer une étoile allongée exactement à 45° pour laquelle SigmaX=SigmaY et qui aurait quand même besoin d'une optimisation sur l'angle. En plus, le critère devrait tenir compte des barres d'erreur sur SigmaX et SigmaY. Plus généralement, pour savoir si des critères supplémentaires sont nécessaires, on passe par les histoires (que je ne maitrise pas bien:confused:) de Chi² réduit. C'est lourd car c'est un calcul à postériori qui oblige à résoudre tous les cas qu'on veut comparer mais ça permet de rester sur des modélisations raisonnables du phénomène physique.

vinvin · 15 mai 2014

J'ai fait une traduction rapide de la page PSF, elle est maintenant disponible en français aussi.

http://free-astro.vinvin.tf/index.php/Siril:PSF/fr

Je vais laisser lock042 te répondre Eric S, tout ce que je peux dire c'est que la FWHM différente en X et Y est fréquente avec les images prises sans autoguidage, ou avec une aberration géométrique. Quand c'est un filé à 45° cette différence n'est pas valide.

lock042 · 15 mai 2014

À la première étape d'identification paramétrique sans angle, quel sens ça a de déterminer indépendamment FWHMx et FWHMy? Sauf à avoir des pixels rectangulaires ou un autre défaut sur la chaîne optique, on ne s'attend pas à ce que les étoiles soient plus allongées sur un axe du capteur que l'autre. Sur la vidéo (0:10), on voit d'ailleurs des valeurs assez proches. Sont-elles différentes si on tenait compte des barres d'erreur? Quitte à simplifier, pourquoi ne pas prendre FWHMx=FWHMy à la première étape?

Bonne question. Tu pars du principe que ta photo est nickel.

Or, quand les photos sont merdiques, de partout ou juste sur les bords, les étoiles peuvent apparaitre étirées. Cela permet d'avoir un outil statistique sur la qualité du suivi ou de l'optique. Le paramètre "r" résumant le tout.

Je pourrais rajouter un truc ou on veut simplifier en forçant une gaussienne ronde (mais la qualité de l'ajustement s'en ferait ressentir) mais j'ai franchement la flemme .

Pour la seconde étape, vous utilisez le critère SigmaX-SigmaY>0,01 pour décider d'optimiser ou non l'angle. On peut imaginer une étoile allongée exactement à 45° pour laquelle SigmaX=SigmaY et qui aurait quand même besoin d'une optimisation sur l'angle. En plus, le critère devrait tenir compte des barres d'erreur sur SigmaX et SigmaY. Plus généralement, pour savoir si des critères supplémentaires sont nécessaires, on passe par les histoires (que je ne maitrise pas bien) de Chi² réduit. C'est lourd car c'est un calcul à postériori qui oblige à résoudre tous les cas qu'on veut comparer mais ça permet de rester sur des modélisations raisonnables du phénomène physique.

La dessus, je ne suis pas sûr de te suivre.

On pourrait (sûrement même on devrait) utiliser les barres d'erreur. Elles sont calculées en interne. Je trouvais le truc un peu lourd. Pour ce qui est du critère, je me suis TRES librement inspiré (et je m'en cache pas) de ce que propose PixInsight et qui marche très bien. J'ai d'ailleurs pu comparer les résultats des 2 qui sont très semblables.

Pour une étoile à 45° tu n'auras pas sig_x = sig_y mais sig_x = 2sig_y par exemple comme le donne en image le site pixinsight ici

EDIT : par définition, sig_x = sig_y donne une étoile parfaitement ronde et donc un angle nul. C'est pour cela qu'on a un critère de 0.01 sinon l'ajustement va diverger plein pot. On estime qu'en dessous de 0.01 (barre d'erreur ou pas ca change peu de chose), calculer l'angle n'est pas nécessaire et il risque de diverger. Donc on le force à 0.

Le calcul du Chi2 est fait par la routine Levenberg-Marquardt présente dans la dynamic PSF et cette dernière le minimise pour donner les résultats.

Modifié 15 mai 2014 par lock042

gastropode · 16 mai 2014

Un exemple de détournement de "Dynamic PSF".

Ainsi qu'il est expliqué dans le didacticiel consacré à cet outil, il est possible d'enregistrer un fichier texte contenant à la fois :

- les coordonnées X et Y des étoiles qu'il a trouvées

- les dimensions en pixels de ces étoiles.

Je me suis interrogé sur la faisabilité de réaliser une carte en SVG à partir de ces données.

Voici :

- l'image de départ http://lerautal.lautre.net/journal/siril/cropee.jpg

- la carte réalisée (la galaxie a été gommée) : http://lerautal.lautre.net/journal/siril/cartesiril.svg

- le code Python du programme qui exploite les données : http://lerautal.lautre.net/journal/siril/lirelst_siril03.py

Eric S · 16 mai 2014

En préambule, je précise que ce qui m'amène sur la détermination de la position des étoiles, c'est que je cogite depuis pas mal de temps sur la façon de faire de la réduction astrométrique pour un système optique préalablement calibré. Je voudrais un truc plus léger (idéalement tournant sur smartphone) que astrometry.net qui ne fait aucune hypothèse sur la chaîne optique. Et donc, la première étape, c'est de déterminer la position des étoiles. Je me suis un peu penché sur la question mais sans rien coder. Alors si d'autres ont fait la brique logicielle correspondante, je suis preneur :be:

Tu pars du principe que ta photo est nickel.
Or, quand les photos sont merdiques, de partout ou juste sur les bords, les étoiles peuvent apparaitre étirées. Cela permet d'avoir un outil statistique sur la qualité du suivi ou de l'optique. Le paramètre "r" résumant le tout.

Je pourrais rajouter un truc ou on veut simplifier en forçant une gaussienne ronde (mais la qualité de l'ajustement s'en ferait ressentir) mais j'ai franchement la flemme .

Pour préciser mes interrogations sur la forme des étoiles, c'est que moins il y a de paramètres et plus l'identification des paramètres est robustes, c'est-à-dire peu sensibles aux parasites comme le bruit. Pour l'exemple, si on a des étoiles rondes, utiliser le modèle allongé va réduire la précision sur la position. Inversement, il ne faut pas utiliser le modèle rond sur les étoiles allongées .

C'est le Chi² réduit qui doit permettre de choisir entre les deux modèles. Le r tout seul n'est pas nécessairement super pertinent: plus on ajoute de paramètres et plus il se rapproche de 1.

Pour une étoile à 45° tu n'auras pas sig_x = sig_y mais sig_x = 2sig_y par exemple comme le donne en image le site pixinsight ici

Dans l'exemple, c'est avec angle=45°. Si on bloque angle=0, on va se retrouver avec sig_x = sig_y. Il faut que je fasse un dessin pour mieux expliquer?

EDIT : par définition, sig_x = sig_y donne une étoile parfaitement ronde et donc un angle nul. C'est pour cela qu'on a un critère de 0.01 sinon l'ajustement va diverger plein pot. On estime qu'en dessous de 0.01 (barre d'erreur ou pas ca change peu de chose), calculer l'angle n'est pas nécessaire et il risque de diverger. Donc on le force à 0.

Toujours pas d'accord avec la première assertion. Tu risques de partir sur un modèle à étoile ronde alors qu'elle est allongée à 45°. Par contre, je comprends ton problème de divergence que tu cherches à éviter. Peut-être qu'il faudrait commencer par faire une régression linéaire sur le nuage de points pour avoir une estimation de l'angle. Ça devrait limiter le risque de divergence (voir discerner tout de suite les étoiles rondes de celles allongées?).

Le calcul du Chi2 est fait par la routine Levenberg-Marquardt présente dans la dynamic PSF et cette dernière le minimise pour donner les résultats.

Donc, si tu as déjà le Chi², pas de problème pour passer au Chi² réduit

Mes 2 centimes :be:

Et pendant que j'y suis, j'ai d'autres questions:

- comment ça se passe avec les étoiles saturées?

- avec les images couleur?

- avec les images CFA?

lock042 · 16 mai 2014

C'est le Chi² réduit qui doit permettre de choisir entre les deux modèles. Le r tout seul n'est pas nécessairement super pertinent: plus on ajoute de paramètres et plus il se rapproche de 1.

r c'est un paramètre que j'ai ajouté et qui correspond à la rotondité de l'étoile. Il est donc indépendant du nombre de paramètre. C'est juste le rapport des 2 fwhm.

Dans l'exemple, c'est avec angle=45°. Si on bloque angle=0, on va se retrouver avec sig_x = sig_y. Il faut que je fasse un dessin pour mieux expliquer?

C'est ce que je dis du coup non ? On doit pas se comprendre.

Toujours pas d'accord avec la première assertion. Tu risques de partir sur un modèle à étoile ronde alors qu'elle est allongée à 45°

Ben non, c'est l'inverse de ce que tu dis. Si angle = 45deg, l'étoile ne peut pas être ronde.

On doit pas se comprendre sur un point.

Pour ce qui est de l’estimation de l'angle en fait on fait l'inverse. On ajuste sans angle et on utilise les paramètre obtenus comme paramètre initiaux pour le 2ème ajustement avec angle si on estime que c'est nécessaire. Ca ne diverge jamais et j'ai fait énormément de tests pour le vérifier.

Donc, si tu as déjà le Chi², pas de problème pour passer au Chi² rédui

Oui mais on s'en sert pas. Le chi2 est géré par la librairie qui minimise (GSL). Au début on avait fait notre propre routine Marquardt Levenberg mais c'était trop lent. Autant prendre des routines optimisées.

Et pendant que j'y suis, j'ai d'autres questions:
- comment ça se passe avec les étoiles saturées?

- avec les images couleur?

- avec les images CFA?

- Ben les étoiles saturées y'a pas grand chose à faire. L'information est perdue. Il faut donc les éviter pour faire une étude dessus.

- Les images couleurs ? Par défaut on travaille sur le layer green mais c'est laissé au choix.

- On ne gère pas (encore ?) les images CFA

J'espère avoir répondu a tes interrogations. Encore une fois je n'ai rien inventé. J'ai utilisé PixInsight, j'ai aimé le truc. J'ai lu leur doc et avec un pote on a codé la routine en suivant leur doc et nos connaissances en physique (il est lui aussi physicien et fait couramment des algo de minimisation. Par conséquent j'ai très confiance en son savoir-faire).

Si tu as des doutes sur une partie de cette routine et que tu souhaites y jeter un coup d'oeil, le code est libre et dispo ici.

Bonne soirée

Modifié 16 mai 2014 par lock042

gastropode · 16 mai 2014

En préambule, je précise que ce qui m'amène sur la détermination de la position des étoiles, c'est que je cogite depuis pas mal de temps sur la façon de faire de la réduction astrométrique pour un système optique préalablement calibré. Je voudrais un truc plus léger (idéalement tournant sur smartphone) que astrometry.net qui ne fait aucune hypothèse sur la chaîne optique. Et donc, la première étape, c'est de déterminer la position des étoiles. Je me suis un peu penché sur la question mais sans rien coder. Alors si d'autres ont fait la brique logicielle correspondante, je suis preneur

Le logiciel Aladin : http://aladin.u-strasbg.fr/aladin-f.gml fait quelque chose qui ressemble à ce que je comprends de votre description :

- On charge une image

- on clique sur quelques-unes (moi j'en prends de 3 à 5) ce qui détermine leur position X Y sur le cliché

- on entre les coordonnées AD et DEC pour ces étoiles.

A partir de là, Aladin se dépatouille pour aller chercher dans les catalogues les étoiles qui vont bien.

Et, en plus, quand on promèene le curseur de la souris sur l'image, il donne les coordonnées AD et DEC correspondantes.

A aucun moment on n'a entré d'information sur le système optique.

Voici une capture que j'avais faite sur un exemple :

http://lerautal.lautre.net/journal/AAI/aladin/capture_aladin.jpg

et aussi http://lerautal.lautre.net/journal/AAI/coma/capture_coma_aladin.jpg

Aladin est écrit en Java (et irait donc bien sur Android) mais n'existe pas sur ce genre de terminal.

lock042 · 29 mai 2014

Bonjour,

Récemment nous avons mis en place un nouveau type d’empilement spécialisé pour les traînées d'étoiles. C'est l'équivalent de la fonction add_max2 dans iris ou de maximum dans DSS.

Voici une comparaison faite avec un empilement standard et cet empilement :

Cette méthode met même en évidence le passage d'un iridium .

Je joins également une vidéo pour indiquer la marche à suivre. Les images d'origine étaient en jpg mais cela marche bien évidemment pour les formats RAW de vos APN.

Vidéo : http://free-astro.vinvin.tf/videos/Star_trails.webm

Bonne journée.

lock042 · 12 juin 2014

Bonjour,

Je tenais à vous informer que j'ai amélioré l'outil de suppression du bruit chromatique vert.

Ce dernier fonctionne dorénavant exactement de la même façon que l'outil de PixInsight en donnant l'option de préserver la couche L* (obtenue via l'espace de couleur CIE L*a*b*). Cela revient au même quand sur Photoshop on applique HLVG uniquement sur la couche couleur.

Il y a 4 algorithmes disponibles.

Les calculs sont également parallélisés pour favoriser les machines à plusieurs cœur .

Voici une vidéo : http://free-astro.vinvin.tf/videos/RemoveGreen.webm.

De nouvelles fonctionnalités intéressantes vous seront peut-être également présentées prochainement car Siril évolue très vite ces derniers temps .

Modifié 12 juin 2014 par lock042

lock042 · 18 juin 2014

Et pendant que j'y suis, j'ai d'autres questions:

- comment ça se passe avec les étoiles saturées?

- avec les images couleur?

- avec les images CFA?

Voilà . Les images CFA sont maintenant prises en charges. Siril peut convertir les images RAW en images normales (3 canaux), ou bien en image noir et blanc CFA.

Ensuite il est possible de debayériser les images CFA pour obtenir une image RGB.

Le prétraitement pour APN est donc pleinement fonctionnel, même si encore quelques bugs sont à noter .

Bonne soirée

Modifié 18 juin 2014 par lock042

Eric S · 19 juin 2014

Voilà . Les images CFA sont maintenant prises en charges. Siril peut convertir les images RAW en images normales (3 canaux), ou bien en image noir et blanc CFA.
Ensuite il est possible de debayériser les images CFA pour obtenir une image RGB.

Le prétraitement pour APN est donc pleinement fonctionnel, même si encore quelques bugs sont à noter .

Bonne soirée

En fait, ma question sur les images CFA concernait plus spécifiquement la détermination de la position des étoiles. Quand je me suis renseigné sur le sujet, je suis tombé sur plusieurs articles. Grosso modo, ça disait qu'on atteignait assez facilement des précisions de 1/50ème de pixel. Sauf que c'est pour des capteurs monochromes . Donc, je me suis demandé ce qu'il se passait avec les capteurs couleurs. On commence par interpoler les pixels (verts) manquants et ensuite on fait concorder notre psf dessus. Finalement, on utilise des pixels qui n'ont pas vraiment d'information en propre mais seulement celle des voisins. Ça ne serait pas plus sain de faire le fit uniquement sur les vrais pixels verts, avant dématriçage?

Sur le dématriçage en général, comment ça se passe pour les matrices non Bayer? (X-trans de Fuji, Foveon de Sigma...)

lock042 · 19 juin 2014

En fait, ma question sur les images CFA concernait plus spécifiquement la détermination de la position des étoiles. Quand je me suis renseigné sur le sujet, je suis tombé sur plusieurs articles. Grosso modo, ça disait qu'on atteignait assez facilement des précisions de 1/50ème de pixel. Sauf que c'est pour des capteurs monochromes . Donc, je me suis demandé ce qu'il se passait avec les capteurs couleurs. On commence par interpoler les pixels (verts) manquants et ensuite on fait concorder notre psf dessus. Finalement, on utilise des pixels qui n'ont pas vraiment d'information en propre mais seulement celle des voisins. Ça ne serait pas plus sain de faire le fit uniquement sur les vrais pixels verts, avant dématriçage?

On peut utiliser la méthode de SuperPixel dans ce cas là pour récupérer l'image. Comme ça on ne fait aucune interpolation, mais la taille de l'image est divisé par 4.

Sur le dématriçage en général, comment ça se passe pour les matrices non Bayer? (X-trans de Fuji, Foveon de Sigma...)

On achète un autre APN ? :be:

Je viens de voir que DCRAW gère ce genre d'APN, donc probablement que libraw le gère aussi pour convertir une image de ce type en CFA. Par contre on ne pourra pas débayériser pour l'instant.

Pour l'instant Siril gère les 4 filtres principaux de Bayer des cameras RGB.

  0 1 2 3 4 5	  0 1 2 3 4 5	  0 1 2 3 4 5	  0 1 2 3 4 5
0 B G B G B G	0 G R G R G R	0 G B G B G B	0 R G R G R G
1 G R G R G R	1 B G B G B G	1 R G R G R G	1 G B G B G B
2 B G B G B G	2 G R G R G R	2 G B G B G B	2 R G R G R G
3 G R G R G R	3 B G B G B G	3 R G R G R G	3 G B G B G B

Eric S · 20 juin 2014

Je réponds un peu tardivement, étant saturé ces derniers temps par d'autres activités.

- Ben les étoiles saturées y'a pas grand chose à faire. L'information est perdue. Il faut donc les éviter pour faire une étude dessus.

D'abord, dans une étude systématique, il n'est pas nécessairement facile d'éliminer les étoiles saturées.

Ensuite, pourquoi ne pas utiliser la méthode du centroïde sur ces étoiles saturées? La méthode du centroïde marche bien pour la position sur les étoiles étalées sur plusieurs pixels, ce qui est souvent le cas de celles qui sont saturées. C'est moins bon pour la magnitude :be: mais on conserve au moins le classement des étoiles par luminosité, ce qui peut être utile pour certaines méthodes de réduction astrométriques automatiques.

On peut utiliser la méthode de SuperPixel dans ce cas là pour récupérer l'image. Comme ça on ne fait aucune interpolation, mais la taille de l'image est divisé par 4.

C'est un peu dommage de diviser la résolution par 2 dans chaque direction quand on veut faire de la réduction astrométrique précise

Sur le dématriçage en général, comment ça se passe pour les matrices non Bayer? (X-trans de Fuji, Foveon de Sigma...)

On achète un autre APN ?

C'est pas gentil, ça

J'en discutais avec un utilisateur de Fuji. Même pour les photos de jour, il a du mal à trouver des logiciels de dématriçage qui vont bien ...

Je vais lui suggérer de faire du SuperPixel de 6x6 :be: .

Pour l'instant Siril gère les 4 filtres principaux de Bayer des cameras RGB.

C'est moi qui manque d'imagination? J'ai du mal à voir d'autres arrangements que ces 4 là.

lock042 · 20 juin 2014

On peut faire du super pixel 2x2 je pense. Faut juste prévoir le pattern 6x6

http://en.m.wikipedia.org/wiki/Fujifilm_X-Pro1

Sinon effectivement pour les pattern 2x2 rgb on a que 4 solutions différentes.

Après il existe les 6x6, les caméras CYMG, etc... Je suis loin de tout connaître.

lock042 · 20 juin 2014

Ah et je pense que l'algo par gaussienne donne de très bons résultats de position même si l'étoile est saturée. Pour ce qui est de l'intensité....

Modifié 20 juin 2014 par lock042

Sylvain Billot · 8 octobre 2014

Bonjour à tous

Mon 1er traitement avec SIRIL (Avec l'aide de Cyril R.)

La bulle du 2 octobre 2014

(Canon 600D sur Orion 80ED, 44 poses de 3 minutes, 5 darks, 5 flats, ISO 1600)

Initiative à soutenir, ce logiciel pourrait bien accoucher d'un petit bijou OpenSource

vinvin · 8 octobre 2014

Super Sylvain, merci !

Bravo pour ce traitement, bientôt ce sera plus simple d'installer Siril avec la version beta et son paquet debian !

Sylvain Billot · 9 octobre 2014

Merci vinvin

Je suis en train de reprendre avec siril toutes mes dernières prises dont le résultat ne m'avait pas satisfait à 100%

Pour l'instant il me semble que siril a un excellent rapport netteté/bruit que je n'ai pas retrouvé nativement dans iris ou audela.

Ci dessous 3 crops de traitement différents de la même série de photos.

(104 poses de 60 minutes iso 3200)

Compiler, j'aime ça

Modifié 9 octobre 2014 par Sylvain Billot

Eric S · 9 octobre 2014

(104 poses de 60 minutes iso 3200)

Ça, c'est du lourd

Pour Iris, surtout juillet mais aussi un peu en août, les trames du fond ressemblent à un signal thermique mal compensé. Peut-être qu'avec le choix d'une autre méthode d'optimisation du signal thermique, Iris ferait aussi bien.

PS : c'est bien la même prise de vue avec trois traitements différents?

Sylvain Billot · 9 octobre 2014

Oui il s'agit bien 104 même poses.

Les fameux "peignes" sont effectivement un problème de bruits ; je suppose du au fait que je prends mes darks en fin de shots alors que la température est plus basse.

Je ne prétends pas connaître tout d'iris et pense qu'il est capable de faire au moins aussi bien que siril.

Mais sur les 2 premières j'y ai passé des heures, sur la dernière moins de 20 minutes.

vinvin · 9 octobre 2014

Des poses de 60 minutes ? C'est possible avec un EOS ça ? C'est 60 secondes non ?

Connexion

Des nouveautés dans Siril, en attendant la beta

Messages recommandés

Les pipelettes du sujet

Les pipelettes du sujet

Images postées dans ce sujet

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante