Siril, retour d'utilisateur convaincu !

[Roch]

EDIT du 30/03 : Ajout des points B-5, C-1, C-2 et C-3

 

EDIT du 10/03 : Ajout des points B-3 et B-4 

Bonjour à tous

 

Alors ça y est, je me suis lancé, j'ai testé Siril. J'ai fait joujou avec pendant toute cette dernière semaine, traité entièrement quelques images et commencé d'autres trucs.

Verdict : le logiciel est excellent, un grand bravo aux concepteurs !

 

L'alignement semble très précis d'après ce que j'en ai vu ( au moins aussi bon que ce que je fais avec IRIS ), c'est rapide, et cela ne plante pas.
Les deux dernières images que j'ai publiées ici ou sur astrobin ( https://www.astrobin.com/users/_Roch_/  ) sont entièrement prétraitées avec Siril ; pour le traitement, pour le moment je garde mes outils habituels.
Néanmoins, le prétraitement est, de loin, l'étape la plus critique d'un traitement d'image astronomique à mon sens. Si les conditions sont réunies, Siril me permet de faire ce que je faisais avec IRIS en un temps infiniment moins long et avec beaucoup plus de facilité.
Donc encore bravo à toute l'équipe !
 

Ceci étant dit...
 

Si je commence ce post, c'est justement parce qu'il me semble que certaines choses pourraient être améliorées. Du bug mineur à la fonctionnalité importante, j'ai noté beaucoup de choses qui me semblent perfectibles, et d'autres dont j'ai eu l'idée et qui, à ma connaissance, ne sont présentes dans aucun autre logiciel.
Donc, ce post, c'est à la fois une boîte à idées pour les concepteurs et un fil rouge me concernant, ou je noterai petit à petit les choses qui me viennent à l'esprit.
Je n'ai qu'une semaine d'expérience "sérieuse" du logiciel, donc je pourrais encore manquer de recul ; peut être même que certaines fonctionnalités que je vais proposer existent déjà.
 

Néanmoins j'ai envie de parler de tout ça tant que c'est frais dans mon esprit.

 

Tout ce que je vais raconter maintenant concerne mon expérience du logiciel, cela pourrait donc être différent pour certains. 
Cela fait quelques années que je fais uniquement de l'imagerie pose courte, ce qui change un peu la donne sur certains points ; je sais que ce n'est pas le cas de la majorité des astrophotographes, pourtant je suis convaincu que cette technique d'imagerie sera de plus en plus populaire dans l'avenir et que beaucoup de monde finira par y venir. Notamment si un logiciel simple et rapide permet de rendre le truc plus accessible
Donc je vais également aller assez loin dans certaines directions, et proposer quelques fonctionnalités un peu "avant garde" mais qui, à mon sens, seront bien utile dans les 5 ou 10 années à venir.

 

Tout ce que je vais dire concerne également la version windows. Je sais qu'il a été pensé au départ pour linux, mais voilà, j'ai windows comme une grande majorité de personnes ici, et je n'ai pas envie d'apprendre à changer de système ; je préfère sortir faire de l'astro
Donc encore une fois, il se peut que certains éléments dont je parle soient différents sur la version linux... mais malheureusement ça ne change rien pour moi.

 

Pour plus de clarté, je vais organiser mes idées en trois grandes parties :

A - Les petits trucs qui simplifieraient la vie
B - Les modifications importantes qui seraient un vrai plus
C - Les fonctionnalités "hardcore" pour aller toujours plus loin

 

Donc prenez des cahuètes, c'est parti !

 

 

A - Les petits trucs qui simplifieraient la vie

 

 

1) Chargement des fichiers

 

Premier constat lors du démarrage, lorsqu'on veut ajouter des fichiers dans l'onglet "conversion", on appuie sur le bouton "ajouter des fichiers à convertir", et là... on attend. J'ai compté 20s pour ma part.
Alors 20s ça pourrait être supportable si ce n'était à faire qu'une fois ; cependant, mes fichiers sont rangés dans des dossiers individuels à chaque fois que je lance une séquence de capture, soit toutes les 15 ou 20 minutes. ça peut donc facilement faire 20 dossiers par nuit d'acquisition.
Donc 20x20 secondes ça commence à faire long. presque plus long que le prétraitement lui même

Qui plus est, le logiciel revient à chaque fois dans le dossier de base "Siril" alors que mes fichiers sont rangés ailleurs lors de l'acquisition... donc ça signifie à chaque fois naviguer dans les dossiers du pc.
Pour finir, le design de la fenêtre laisse penser qu'une option "click and drag" doit être possible... or, ça ne marche pas. Pas pour mes fichiers .png en tout cas.

Bref, voilà, rien de dramatique mais quelque chose qui mérite amplement sa place ici, à mon sens.

 

 

2) Les boutons

 

Un truc qui m'a frappé en ouvrant le logiciel la première fois, c'est que je n'arrivais pas à trouver oùse trouvaient les boutons facilement.
Une règle tacite qui me semble importante et commune à de nombreux softwares, est que le bouton "valider" ou "OK" est toujours situé en bas à droite lorsqu'il s'agit d'un truc important.
Et là, c'est le bazar...
 
Dans l'onglet "conversion", l'onglet "convertir" est au milieu à gauche
Dans l'onglet "alignement", le bouton "aligner" est en haut au centre
Dans l'onglet "pré-traitement", c'est en bas...
Et en bas à droite se situe un bouton "modifier répertoire" qui me semble certes important, mais ne mérite pas cette place principale

Ca fait que même lorsque j'ai trouvé l'emplacement du bouton, j'ai une appréhension à le presser parce que je me demande si c'est bien ça qui va lancer la commande principale du menu en question.

 

Bon évidemment après une semaine je m'y suis fait, mais l'ergonomie est un truc qui m'a beaucoup dérouté au début et ça fait aussi partie des raisons pour lesquelles je n'ai pas essayé sérieusement Siril avant.

 

Après, si ça ne gêne que moi, c'est un faux problème évidemment.

 

 

3) La conservation des paramètres

 

C'est simple, dés que j'éteins le logiciel, si je le rallume, tout revient à son état initial.
Il faut que je pense à cocher "garder le 1er canal" dans l'onglet conversion, il faut que je recharge mon dark principal dans l'onglet prétraitement, il faut que je pense à redéfinir mes paramètres de l'outil de détection d'étoiles...
A mon avis il serait souhaitable de pouvoir garder tous ces paramètres en mémoire quelque part, puisque on reste souvent sur un même genre d'image à traiter. Qui plus est, on se souvient plus facilement de ce qui change plutôt que dece qui reste constant.

 

Bon, si c'est déjà possible et que j'ai loupé cette option quelque part, toutes mes confuses.

 

 

4) Empilement bloqué à 2048 fichiers ?

 

Il apparaît qu'on ne peut pas empiler plus de 2048 images à la fois sur la version windows.
Cette limitation est vraiment handicapante. Je sais qu'on peut passer les fichiers en .ser pour contourner le problème, mais ça reste un truc dommage.

 

 

5) Gestion des fichiers

 

Lorsque Siril enregitre les fichiers en .fit, la nomenclature me laisse penser que le nombre de fichers est limité à 99.999 puisqu'il y a un nombre fixe de zéros précédant l'index de chaquue fichier. Si cette limitation est bien réelle, encore une fois cela me semble trop peu ; on atteint parfois des nombres d'images dépassant la centaine de milliers et il est clair que cela ne va pas s'arrêter là ; d'ici quelques années, le million ou même peut être la dizaine de millions d'images seront monnaie courante, à mon avis.
Donc si cette limitation existe, pour prévoir large, il faut rajouter des zéros

 

 

6) Sélection manuelle des images

 

L'outil de sélection manuelle est très pratique et très rapide. Une option qui serait très appréciable serait de pouvoir enlever toute une série d'images ( en sélectionnant la première et la dernière à enlever ) plutôt que de devoir toutes les sélectionner individuellement ; très utile en cas de passage nuageux par exemple.

 

 

7) PSF dynamique

 

C'est encore une fois un outil très intéressant ; je n'ai pas encore eu le temps de le tester à fond.
Néanmoins, il serait appréciable de pouvoir trier les étoiles, par exemple par ordre croissant ou décroissant de fwhm, en cliquant sur l'en-tête de colonne correspondant.

 

😎 Windows 32 bits

 

Bon je met celui là en dernier, parce que je dois être un des seuls à avoir besoin d'une version compatible windows 32 bits.
Cependant, mon PC d'acquisition est en 32 bits et je ne peux pas le changer en 64. J'ai un pc fixe en 64 bits chez moi pour traiter, mais lorsque j'image, il m'arrive de rester plusieurs semaines avec uniquement mon petit pc d'acquisition... et heureusement que j'ai toujours IRIS dessus, car ne pas pouvoir commencer à traiter les images pendant tout ce temps serait une torture
Donc je comprendrais très bien que ce ne soit pas une modification envisageable, je n'ai aucune idée de la quantité de boulot à fournir pour ce genre de truc, mais sachez juste que oui, il existe encore des gens que ça embête

 

 

B - Les modifications importantes qui seraient un vrai plus

 

 

1) Calcul de la PSF sur les images

 

Alors qu'on ne se méprenne pas, c'est un outil qui marche très bien. L'option qui permet de changer des réglages de la détection des étoiles est très intéressant.

Là ou il y a un problème, c'est que lorsque le logiciel affiche une psf moyenne de l'image, il tient compte aussi des étoiles saturées, qui affichent toujours une valeur bien plus élevée !
Cela fausse donc la valeur moyenne de la FWHM puisque cela ne représente plus la réalité. On peut donc avoir l'impression qu'une nuit était mauvaise en regardant juste ce chiffre, alors qu'on avait juste plusieurs étoiles saturées dans le champ.

 

Personnellement, pour donner un exemple, j'ai en moyenne entre 20 et 25 étoiles que le logiciel détecte sur mes poses de 2s, et dans ce chiffre 4 ou 5 sont saturées en général. Parfois la valeur de la FWHM monte à des chiffres comme 11 ou 12 alors que pour le reste des étoiles on est plutôt à 3.
Evidemment, on peut toujours utiliser les étoiles saturées pour recaler les images. Par contre on ne peut pas les utiliser pour une mesure de la FWHM qui se veut précise, cela va tout fausser.

 

Autre problème plus grave avec ce principe, si une grosse étoile saturée sort du champ en cours de l'acquisition, la FWHM va subitement descendre d'un cran sur les prises suivantes.
Cela va donc fausser le classement des images par la PSF pour l'empilement qui arrivera après. On va sélectionner des images moins bonnes, mais que le logiciel considère meilleures simplement car la grosse étoile n'est plus fdans le champ.

 

De la même manière, l'outil auto sélectionne parfois des galaxies en arrière plan au lieu des étoiles. Il y a certainement un moyen d'éviter cela, au moins en partie, mais j'y reviendrai dans ma partie "hardcore"
Ce n'est pas un problème pour le recalage ( c'est même souhaitable d'avoir le maximum de points possibles ) mais cela fausse aussi le calcul global de la FWHM.

 

 

2) Images en 16 bits

 

Bon alors là on va parler de dynamique.

Certes, 16 bits est largement suffisant ( pour le moment...) pour traiter les poses unitaires sortant de n'importe quelle caméra.
Le problème c'est qu'en empilant des milliers, des dizaines de milliers voir des centaines de milliers d'images comme on peut le faire  de nos jours en poses courtes, les 16 bits deviennent largement insuffisants.

A chaque fois que l'on fait la moyenne un nombre n d'images, on fait diminuer le bruit de fond de ciel d'un facteur sqrt(n) ce qui augmente la dynamique  de notre image finale d'autant.

Pour donner un exemple parlant, sur une nuit d'acquisition normale, je vais acquérir environ 10.000 images de 2s.
Pour une image unitaire, la dynamique sera faible, notamment parce que j'utilise un gain très élevé. Mais après l'empilement de ces 10000 images, la dynamique globale sera 100 fois plus importante ( 100 = sqrt(10000) ) ce qui fait environ 6.6bits supplémentaires.

Mes images unitaires ont une dynamique d'environ 7.5 bits lorsque j'utilise le gain maximal ; cela donne donc une dynamique finale de 14.1 bits. On pourrait penser qu'on a encore de la marge, mais non !

 

- D'une part ce calcul est valable si je met le gain à fond ( ce que je fais habituellement ) mais si j'image un objet lumineux, je peux avoir envie de descendre le gain et donc d'augmenter la dynamique de mes images unitaires. Si je met le gain à zéro, ça fait environ 11 bits de dynamique... additionnons 10.000 de ces images, on obtient une image à 17.6 bits, que l'on ne pourra donc pas coder snas perte d'information sur un système en 16 bits. De la même manière, on peut avoir envie d'imager en poses plus courtes ( ce qui augmente également la dynamique puisqu'on augmente le nombre d'images ) ou d'imager sur plus d'une nuit.

 

- D'autre part, il faut une petite marge si on ne veut vraiment aucune perte d'information dans l'image. Même une image contenant 14 bits de dynamique aura quelques pertes si elle est codée en 16 bits et sera légèrement mieux rendue si elle est codée en 32 bits. On parle de quelques pourcents à peine, mais c'est de plus en plus flagrant à mesure qu'on se rapproche des 16 bits. Pour une image astro, ça veut dire moins de petits objets faibles dans le fond de ciel par exemple...

 

Donc pour conclure, il est nécessaire d'avoir un système qui code les images en 32 bits au moins. Pour le moment on peut encore s'en tirer avec 16, mais c'est de plus en plus critique à mesure que la technologie avance... et déjà on peut avoir des pertes si on travaille en poses très courtes, à gain faible ou sur plusieurs nuits.

32 bits devraient permettre de voir venir pour un bon moment. Même si on imagine des images en 16 bits à la base, il faudrait en empiler environ 200 millions pour commencer à être vraiment gêné

 

Après, pour gagner de la place et du temps d'opération, on pourrait imaginer un système qui modifie le nombre de bits sur lesquels l'image est codée en fonction de celle-ci... mais je vais laisser cette réflexion pour la partie "hardcore"

 

3) L'alignement des images

Alors là, je vais parler d'une fonctionnalité qui n'existe, à ma connaissance, dans aucun logiciel astro. ( Pix peut être ? je ne connais pas bien... )

En imagerie poses courtes, on est très souvent tenté d'utiliser une monture un peu sous-dimensionnée, sans se préoccuper d'autoguidage ou de n'importe quel autre bazar. Le champ est réduit, et la conséquence est donc qu'on a une cible qui se balade pas mal dans le champ.
On peut aussi avoir la rotation de champ qui s'en mèle si la MES n'est pas parfaite, ou pire, si on image à l'aide d'une monture altaz.

Malheureusement, en utilisant les outils d'alignement / empilement actuels, cela signifie une dégradation significative. Soit on doit sacrifier du champ, soit on doit sacrifier des poses dans lesquelles l'objet est trop excentré, et ce même si l'objet principal peut parfois être encore entier dans l'image, c'est donc un gaspillage pur et simple  

Pourtant, il me semble qu'il pourrait exister une solution à ce problème, qui permettrait d'obtenir une image finale utilisant toutes les informations de nos images unitaires, sans compromis ni sur le cadrage ni sur le nombre d'images empilées.

On va prendre un exemple pour que ce soit plus parlant ; on imagine deux images décalées en hauteur de 10 pixels. Lorsque le logiciel recale l'image 2, celle-ci sera donc déplacée de 10 pixels vers le bas. La conséquence est que l'information contenue dans 10 pixels du bas de l'image 2 d'origine sera perdue, et les 10 pixels du haut de l'image 2 seront transformés en pixels d'intensité zéro, ce qui rendra inutile les 10 pixels du haut de l'image 1 puisqu'à l'empilement cela créera un effet "escalier" extrêmement disgracieux. Il faudra donc recadrer l'image.

Maintenant, imaginons un autre procédé.
-Première étape : On place les images sur une grille plus large que les images d'origine. Ici dans notre cas, 10 pixels de marge suffisent, mais on pourrait imaginer un paramètre réglable.
On aura donc notre image 1 et notre image 2 qui gagneront 10 pixels dans toutes les directions, et ceux-ci n'auront pas d'intensité définie ( pixels "transparents" )
-Deuxième étape : on aligne les images comme on a l'habitude. Simplement, au lieu d'attribuer la valeur zéro aux pixels inutiles, on garde des pixels "sans valeur attribuée"
-Troisième étape  : on procède à l'empilement. Simplement, au lieu de faire une somme, on va faire une moyenne ( ce qui revient absolument au même en terme de rapport signal/bruit si l'image est codée sur un nombre de bits suffisants ) et cette moyenne n’intégrera que les pixels pour lesquels la valeur est attribuée.

Donc dans le cas de notre exemple, cela va nous donner une image 20 pixels plus haute au total qu'une image issue d'un empilement classique, et même 10 pixels plus haute qu'une image unitaire. Si la calibration est bonne, il n'y aura aucun bord visible sous ces 10 pixels puisque on fait la moyenne d'une image pour les 10 pixels du haut et la moyenne de deux images sur les pixels en dessous.
Là où il y aura une différence visible, c'est sur le rapport signal/bruit ; il sera bien évidemment meilleur dans la zone centrale que dans les zones hautes et basses. Toutefois, avoir une image dont les zones externes ont un RSB moins élevé n'est pas vraiment un problème puisque l'objet principal est souvent situé près du centre ; les zones périphériques ne servent généralement qu'à ajouter du contexte. C'est d'ailleurs généralement déjà le cas, puisque le vignetage réduit également le RSB des zones périphériques.

Pour un résultat vraiment parfait, certains paramètres doivent rester stables, comme le niveau de fond de ciel ou celui des objets photographiés ; cependant, une calibration des images préalables adéquate permettraiy de compenser des variations de transparences ou de luminosité de fond de ciel, et donc de résoudre ce problème supplémentaire

Bref, j'espère avoir été suffisamment clair sur le procédé  après je ne sais pas dans quelle mesure c'est réalisable facilement, notamment sur le point ou il est nécessaire de générer un pixel sans valeur attribuée.

 

4) la sélection des meilleures images

L'outil de sélection automatique des meilleures images actuel fonctionne très bien. Néanmoins, il serait utile de pouvoir croiser plusieurs paramètres dans la sélection pour l'empilement final.
Par exemple, on pourrait imaginer évacuer les 10% plus mauvaises du point de vue de la PSF ET les 10% les plus mauvaises du point de vue de la rondeur du même coup.

Il serait d'ailleurs judicieux de pouvoir croiser encore d'autres paramètres dans notre sélection finale, dont certains  pourraient être accessibles assez facilement :
- Le niveau du fond de ciel ( une voiture qui passe, la lune qui se lève... )
- Le niveau de transparence, accessible sans trop de difficultés en mesurant l'intensité globale d'une étoile non-saturée sur toutes les images ( pour éliminer les passages nuageux ou quantifier l'arrivée de la brume )

Obtenir les graphiques associés à ces paramètres ( de la même manière que pour l'évolution de la PSF ) serait également très instructif.

Si je ne me trompe pas, il n'est pas possible de sortir une séquence d'image constituées, par exemple, des 2000 meilleures images selon la PSF ; ce serait également une option appréciable, et ce, pour l'ensemble des critères de sélection imaginés ci-dessus.

 

 

5) Le drizzle et le bayer drizzle

 

A priori, je n'ai pas besoin d'expliquer ce que c'est ; la technique est bien connue des astrams et des logiciels assez pointus comme pixinsight permettent bien de prendre la mesure du bénéfice que peut apporter cette fonction.

Cependant, je vais ici expliquer pourquoi c'est pour moi un point crucial concernant la technique des poses rapides.

 

Pourtant, c'est plutôt contre intuitif ; disposant déjà d'un nombre d'images très conséquent, on n'a pas vraiment envie de ralentir encore plus notre temps de traitement... cependant si l'option était disponible je l'utiliserais sans ménagement

 

Si on décide d'acquérir des images de manière classique ( avec autoguidage ) le temps de pose unitaire n'est finalement pas une limite très importante. Lorsque l'on considère son setup, si on veut aller aussi loin que possible dans les détails, il suffit de suréchantillonner un peu par rapport à notre facteur limitant, la turbu.
Par exemple en doublant la focale ( ou en divisant par deux la taille des pixels ) le flux de photons atteignant chaque photosite sera divisé par quatre ; il suffira alors de multiplier le temps de pose unitaire par quatre et le rapport signal sur bruit de chaque photosite restera identique. 

 

L'avantage c'est qu'on aura moins de pertes dans la définition de l'image lors de l'alignement des images, donc en réduisant l'image finale à 50% après alignement ( binning logiciel ) on aura une image à la fois aussi sensible, mais également plus détaillée qu'une image prise avant le doublement de focale, et ce, simplement au prix d'une augmentation du temps de pose unitaire. ( mais pas du temps de pose total )

 

Ceci étant, en poses courtes le principe reste valable, mais l'augmentation par quatre du temps de pose unitaire est un gros problème : on cherche en effet à avoir le temps de pose le plus court possible ! Il faut donc trouver le meilleur compromis, de manière à ce que le flux par pixel reste suffisant ( donc courte focale ) mais en même temps queles pertes dues à l'alignement soient les plus faibles possible ( donc longue focale )
Comme le drizzle ( et le bayer drizzle pour les caméras couleur ) réduit drastiquement ces pertes de résolution, on pourra donc se permettre d'utiliser des F/D plus courts ou des pixels plus gros pour une image aussi résolue. Et donc, puyisque le flux par pixels sera plus important, on pourra faire des poses unitaires plus courtes... donc avoir une image mieux définie au final

 

Le "faux drizzle" proposé par Siril ( et que j'utilisais déjà avec IRIS ) permet déjà une légère amélioration, et j'en fais une utilisation systématique car mon échantillonnage est plus que limite si j'ai de bonnes conditions de turbu, mais un "vrai drizzle" serait bien plus efficace

 

 

 

C) Les fonctionnalités "hardcore" pour aller toujours plus loin

 

 

Avertissement : Ce qui va suivre ne constitue que des idées encore bien floues dans mon esprit, mais qui ont certainement un fort potentiel de développement dans les années à venir, conséquemment à des détecteurs de plus en plus performants et des puissances de calcul de plus en plus importantes. Donc évidemment je ne m'attends pas à voir ces fonctionnalités implémentées dans le logiciel d'ici 2 semaines, loin de là je serais même étonné qu'une seule de celles-ci soit implémentée un jour. Mais si on veut faire cracher le maximum d'informations à nos images, il me semble que des développements sont possibles dans ces directions, donc je vous livre mes réflexions en l'état ( pour le moment ) ; tout est bien entendu susceptible d'évoluer.

 

 

1) Prétraitement par extraction des informations sur les brutes d'acquisition

 

Voici une voie que j'ai commencé à explorer il y a quelques temps, et qui me semble assez prometteuse. Le principe est simple : se passer totalement d'images de type Dark, flat ou offset, et extraire nos informations nécessaires au prétraitement directement des images d'acquisition.

Je viendrai aux avantages de ce procédé plus tard, mais commençons par envisager comment réaliser une telle chose.

 

La différence entre les informations issues du ciel et les signaux parasites de notre instrumentation, c'est que ces derniers restent parfaitement immobiles sur l'image alors que le signal bouge selon les aléas de notre monture. Pour un setup à autoguidage parfait, ce procédé est impossible, mais avec suffisamment de mouvements erratiques ( ou causés par un dithering bien conçu ) on peut théoriquement extraire parfaitement ces données ( enfin il me semble ) pour peu qu'on dispose d'un nombre suffisant d'images. ça tombe bien, c'est justement le cas en poses courtes.

Pour ceux que ça intéresse, j'avais commencé un fil sur la question ; néanmoins j'ai un peu abandonné étant donné que tester la chose demande un temps fou avec IRIS ( on parle de centaines de commandes répétitives à réaliser manuellement... )
J'avais toutefois obtenu un premier résultat avec une nébuleuse du crabe présentant un fond de ciel bien plus propre que ce que j'avais obtenu avec des darks réalisés de façon classique.

 

Bon, vous me pardonnerez, c'est en face...  http://www.astrosurf.com/topic/123160-en-finir-avec-la-trame/

 

Un des premiers avantages de ce type de prétraitement, c'est que les fichiers utilisés sont pris à l'instant même de l'acquisition. On se situe donc dans les conditions exactes de l'acquisition, et qu'il est parfois difficile de reproduire parfaitement pour la prise de nos fichiers de prétraitement.

Sur les détecteurs CMOS que j'utilise, j'ai pu constater des modifications de la carte d'offset ou de dark très rapides ; Parfois une simple déconnexion de la caméra peut modifier tout cela. On peut aussi avoir des variations de température, on ne compte pas le nombre de personnes ayant eu des problèmes de flats... bref.

Pour un détecteur dont la température varie, on pourrait même envisager de réaliser plusieurs cartes de prétraitement en utilisant, par exemple, les données de chaque heure, et soustraire ensuite chaque carte aux prises unitaires de l'heure correspondante. Cela peut marcher également pour un gradient qui évolue en fonction de l'altitude d'un objet...

 

Si beaucoup de gens ont des problèmes de trame en poses courtes, ce n'est pas pour rien ; la proportion ( Signal utile ) / ( Bruit parasite ) est beaucoup plus importante puisqu'on divise les temps de pose unitaires par un facteur 100. Et à mesure que l'on pourra descendre en temps de pose avec des détecteurs de plus en plus puissants, cette proportion risque d'être encore plus faible ; il nous faut donc des cartes de prétraitement de plus en plus précises.

 

Bref je reviendrai certainement vers ces petites expériences un jour ou l'autre... j'ai récemment acquis des images ciel profond à 100fps pour un petit test extrème, je ne vous raconte pas l'enfer du prétraitement pour ne pas se retrouver avec une trame horrible

 

 

2) Alignement des images optimal en poses très rapides

 

Le temps des poses unitaires à 10ms en ciel profond n'est pas encore arrivé, mais d'ici une dizaine d'années, qui sait...

Et maintenant vient la question qui tue : comment aligner efficacement une image si aucune étoile n'est détectable sur certaines frames, parce qu'à ce moment, aucun photon ne daigne frapper convenablement notre capteur ?  

Vous allez me dire, c'est impossible. Sauf que ce n'est pas impossible en considérant cette image au sein des milliers d'autres.

 

Pour faire simple, il faudrait un procédé qui fonctionne en boucle de la manière suivante :

 

-Détecter les étoiles du champ
-Aligner en fonction des étoiles détectées ( le cas échéant, alignement similaire à l'image précédente )
-Constituer une nouvelle série d'images en les additionnant deux par deux ( dans l'ordre chronologique )
-Recommencer pour la série d'images ainsi obtenue

 

La boucle prend fin lorsqu'il ne nous reste qu'une image, c'est notre image finale

 

 

Ainsi, notre étoile pasée "sous le radar" à 100fps se retrouvera peut être détectable à partir de 50fps. Et le plus rapidement l'étoile est détectée, le mieux c'est car la turbulence sera intégrée sur la période la plus courte possible.

Qui plus est, on a intérêt à aligner sur un nombre d'étoiles le plus élevé possible, puisque la turbulence varie d'un point à un autre de notre image. En gros, plus on s'éloigne de notre point d'alignement de base, plus l'effet bénéfique de l'alignement ( qui corrige en partie la turbu ) va s'estomper, pour même donner un effet contre-productif si l'on s'éloigne suffisamment.

D'après mes différentes lectures sur le sujet, la taille de cette zone varie, mais on peut espérer encore gagner en précision pour un objet situé à 1 minute d'arc du point d'alignement. Ce qui donne donc une "zone" de 3 minutes d'arc carrées où cet alignement a un effet positif sur le piqué.

Bon je balance un peu ces chiffres comme ça, mais encore une fois, j'ai réalisé un petit test là dessus ces dernières semaines, je présenterai les résultats bientôt, dés que j'aurai eu le temps de tout décortiquer.

Mais si on part de cette valeur, cela signifie que pour un effet bénéfique sur l'ensemble du champ, il faut aligner sur un nombre conséquent d'étoiles. Et quoi qu'il arrive, plus l'objet sera situé du point d'alignement, plus le gain sera substantiel... donc il faut toujours plus d'étoiles.

 

Et là on arrive dans les problèmes de la méthode.

 

Malheureusement, même en considérant un détecteur parfait qui détecterait un seul photon de manière systématique, celui-ci ne sera pas suffisant pour former un point d'alignement. En effet, une étoile représentera au final une tache sur notre détecteur, le photon peut avoir eu une trajectoire aboutissant à n'importe quel point de cette tache. Donc l'alignement gagnera en précision à mesure qu'on détectera des photons supplémentaires puisque le centre de la tache pourra être déterminé avec plus de précision.
Il doit donc également être possible de pondre un algorithme d'alignement tenant compte de cela , c'est à dire en donnant une "force d'alignement" ( conséquente à l'incertitude inhérente à l'aspect quantique du phénomène ) pour chaque point en fonction du nombre de photons détectés. Et de là, on peut même utiliser nos points avec un seul photon, simplement la "force d'alignement" sera bien moins importante.

 

Un autre problème qui se pose, c'est que l'alignement doit entraîner une baisse de résolution la plus faible possible, de manière à ce que même après 10 ou 20 itérations l'image ne soit pas dégradée de manière significative. petit renvoi vers le drizzle, tout ça...

 

 

Bon et le problème majeur, c'est que... c'est une usine à gaz pas possible

Après en y réfléchissant quelques secondes, on se rend compte qu'en faisant une infinité d'itérations, on ne fait que doubler le temps nécessaire à une itération puisqu'on réduit le volume de données d'un facteur deux à chaque fois. Donc, pas inenvisageable.

On peut aussi voir ça comme un moyen d'accélérer certaines étapes du traitement ; par exemple on peut se contenter de faire une sélection des meilleures images après quelques itérations ( de manière à pouvoir y détecter quelque chose par exemple ) au lieu de le réaliser sur les images "source".

 

Mais la question c'est aussi, quel apport d'un tel bazar ? Pour le moment je ne peux pas répondre, certainement infime pour mes poses unitaires de 2s, mais je suis convaincu qu'un jour il sera substantiel. Le petit test réalisé l'autre jour à 100fps me permettra certainement d'y voir plus clair et de quantifier un peu les choses.

 

 

3) Empilement d'images "intelligent"

 

Je me suis toujours posé la question : jusqu’où dois-je aller dans les poses si la lune arrive ? est-ce que la moindre augmentation du fond de ciel va compromettre irrémédiablement mon image ? est-ce que je peux laisser passer quelques minutes ? est-ce qu'en ajoutant les images prises avec la lune j'aurai quand même un résultat légèrement meilleur ?

 

J'ai un peu creusé le sujet, mais moins que pour les deux derniers points, donc j'y reviendrai certainement plus tard

 

En théorie, c'est simple ; par présence de pollution lumineuse, le fond de ciel prendra une valeur plus élevée, induisant par là une hausse du bruit de fond. On aura donc une baisse de rapport signal sur bruit, qui sera d'autant plus sensible que les signaux incriminés seront faibles. Pour être plus clair en donnant un exemple concret, on perdra beaucoup en RSB sur les extensions de notre galaxie mais très peu sur le coeur.
Et là ou le truc devient embêtant, c'est qu'en théorie, ajouter une image à fort RSB avec une image à faible RSB devrait pouvoir donner une image avec un RSB très légèrement meilleur. Cependant, pour cela, il nous faut appliquer un coefficient à l'une des deux images pour obtenir la meilleure valeur de RSB possible au final.

Multiplier une image par une constante est facilement faisable ; je le fais déjà parfois dans IRIS. Lorsque j'ai par exemple un petit passage brumeux ou une extinction de lampadaires, je calcule le coefficient me garantissant le meilleur RSB possible au niveau du fond de ciel après l'empilement afin de conserver quand même les images en question. C'est un petit peu le bazar, mais au final je gagne quelques pourcents sur le RSB final... toujours bon à prendre et c'est assez rapidement visible en fait.

Seulement voilà, d'une part c'est une opération longue qui pourrait être automatisée simplement, et d'autre part multiplier une image par un coefficient n'est même pas la solution optimale, parce que c'est une valeur qui garantit un meilleur RSB pour les faibles signaux ( donc généralement ceux qui nous intéressent ) mais qui détériore le RSB de signaux élevés. Donc ce fameux coefficient doit varier en fonction de la luminosité du pixel... on se retrouve donc à appliquer une transformation plus complexe à l'image.

 

Comme dit plus haut, je ne me suis pas penché dans le détail sur ce "problème", mais on doit pouvoir trouver la transformation parfaite qui permettrait de garantir le meilleur RSB possible une fois la somme effectuée, à partir d'informations de base que l'on peut déduire de l'image ( ici en l'occurence, la transparence du ciel et la luminosité du fond )

 

Pour aller encore plus loin, on pourrait également appliquer un coefficient à certaines images suite à la sélection par la FWHM, ou toute autre méthode. En effet, en poses courtes on est toujours à la recherche du compromis entre quantité de signal et détails ; on cherche le juste milieu entre sélectionner 1% des images ( ce qui donne le meilleur piqué ) et sélectionner 100% des images ( ce qui donne le meilleur RSB )

Donc il me semble logique qu'au lieu d'une sélection binaire des images ( Oui ou Non ) on pourrait les pondérer, de manière à faire intervenir davantage les images les mieux résolues et moins les images les moins résolues ; sans être allé très loin dans la réflexion, il me semble évident qu'il doit exister une série de coefficients permettant de gagner un peu de RSB en conservant la même netteté par rapport à un empilement classique à sélection binaire.

Et puis alors pour combiner tout ça avec le point précédent, bonjour...

 

 

 

 

Bref, comme vous pouvez le voir, il y a encore matière à réflexion

Qu'on ne se méprenne pas, je ne serai jamais assez reconnaissant envers les concepteurs de ce logiciel gratuit ; cependant à mon avis les possibilités de propulser ce logiciel bien au delà de ses possibilités actuelles sont multiples et ne pourraient que lui apporter du bien. Donc si certains des développeurs passent par ici et sont intéressés par mes idées ( qui ne sont pas encore vraiment écrites là d'ailleurs mais ça ne saurait tarder ), servez vous je vous en prie  

Romain


 

Modifié 30 mars 2019 par Roch

[lock042]

Hello, vu le roman ( ) je vais essayer de pas faire trop long, et je vais scinder mes réponses. Tout d'abord, merci pour le retour c'est sympa.

Ensuite, passons enfin aux choses sérieuses.

 

Il y a 2 heures, Roch a dit :

A - Les petits trucs qui simplifieraient la vie

 

Il y a 2 heures, Roch a dit :

1) Chargement des fichiers 

Je comprend pas tout ici. Dans siril, tu peux charger des fichiers venant de partout. Par contre, en effet ils seront tous converti dans le dossier de travail. Ce dernier est hérité de IRIS d'ailleurs et permet de savoir ou on met les choses, surtout quand on script. D'ailleurs en parlant de scripts, tu pourrais facilement automatiser tes conversions.

 

Il y a 2 heures, Roch a dit :

2) Les boutons

Comme tu as sans doute pu le voir, on essaye de regrouper les boutons par thème car un onglet peut avoir plusieurs fonctions. Les boutons importants sont censé être assez gros pour ne pas être loupé :). Alors, oui, l'interface peut etre assez confuse, cependant c'est vraiment dur de faire un truc qui va à tout le monde. On est en train de travailler sur une refonte graphique de toute façon.

 

Il y a 2 heures, Roch a dit :

3) La conservation des paramètres

Pour ici, la plupart des fonctions réellement importante sont sauvegardés. Notamment dans les paramètres. De plus certains paramètres nécessites de revenir à leur état initial ou l'utilisateur va faire n'importe quoi. Par exemple l'option "dématricer", les options de sélection de meilleures images pendant l'empilement, etc ....

 

Il y a 2 heures, Roch a dit :

Il faut que je pense à cocher "garder le 1er canal" dans l'onglet conversion,

Ce genre de paramètre, on l'utilise assez rarement d'ailleurs. Pkoi l'utilises tu ?

 

Il y a 2 heures, Roch a dit :

4) Empilement bloqué à 2048 fichiers ?

Alors la je suis désolé, mais il va falloir que tu changes de crémerie ou que tu passes au SER. En effet, cette limite de 2048 est inscrite en dure dans le code de Microsoft WIndows. Sous macOS et Linux c'est 10 000, et cette fois c'est la librairie cfitsio qui marque cette limite (et encore j'ai demandé aux gars qui la code d'augmenter la limite qui était à 1000 avant). Attention, cette limite n'existe pas pour un empilement par somme, seulement pour des empilement ou siril a besoin de lire tous les fichiers avant.

 

Il y a 2 heures, Roch a dit :

5) Gestion des fichiers

 

Lorsque Siril enregitre les fichiers en .fit, la nomenclature me laisse penser que le nombre de fichers est limité à 99.999

Si tu comptes faire plus de fichiers, passe en SER. Le ciel profond rapide on le fait en SER.  Tu auras un gain de temps et ca évitera d'avoir une tonne de fichiers par dossier

 

Il y a 2 heures, Roch a dit :

Néanmoins, il serait appréciable de pouvoir trier les étoiles, par exemple par ordre croissant ou décroissant de fwhm, en cliquant sur l'en-tête de colonne correspondant.

Pourquoi pas en effet.

 

Il y a 2 heures, Roch a dit :

😎 Windows 32 bits

Alors là ... Ne reve pas. On a essayé vite fait, et c'est trop le bordel. Juste pour rappel, on est deux développeurs et aucun de nous n'utilise Windows :). Donc bon :).

De plus, 32 bits c'est obsolète maintenant et on est limité en traitement, surtout si tu fais beaucoup de fichiers.

Modifié 8 mars 2019 par lock042

[lock042]

Il y a 2 heures, Roch a dit :

B - Les modifications importantes qui seraient un vrai plus

 

Il y a 2 heures, Roch a dit :

Là ou il y a un problème, c'est que lorsque le logiciel affiche une psf moyenne de l'image, il tient compte aussi des étoiles saturées, qui affichent toujours une valeur bien plus élevée !

La tu as raison, c'est quelque chose que je veux faire un de ces 4 .... mais ... je trouve jamais la motivation. En meme temps c'est pas un problème simple. En effet, une étoile va pas saturer au même ADU pour tous les capteurs.

Chez un canon 14bits ca va etre vers les 14000 et non 16383, dans les APN 12bits ca sera 4095, pour les caméra 16bits ca sera 65534 ... etc ... Bref, comment on fait pour définir quand l'étoile a vraiment saturé  ???? J'ai pas de solution simple.

Il y a 2 heures, Roch a dit :

2) Images en 16 bits

Augmenter la précision est le chantier de la 1.0. Chantier pas encore commencé et c'est pas facile. Il suffit de voir combien GIMP a mis pour passer de 8 bits à plus. Comme je t'ai dit, on n'est que deux et on a déjà tellement de trucs ouverts en même temps (notamment une version planétaire).... Cela dit, les calculs internes sont tous fait en précision double quasiment (soit 64bits), c'est juste qu'on converti en 16 bits à la fin à cause de "cœur" de siril, ancien. Ceci est d'autant plus vrai si tu empiles avec l'algo somme, qui est souvent l'outil utilisé pour un tel nombre d'images dans le ciel profond rapide.

Modifié 8 mars 2019 par lock042

[lock042]

Sinon @Roch, nous apprécions énormément ton retour.

Je vais essayer de réfléchir au problème de la saturation dans les PSF, et si tu as des solutions (idées) je suis preneur. Il faut penser qu'on doit gérer toutes sortes de fichiers provenant de toutes sortes de capteurs.

Modifié 8 mars 2019 par lock042

[Roch]

Wow, ça c'est de la réponse rapide, merci

Je compléterai mon premier message demain soir si j'ai le temps. En attendant, pour répondre à quelques-unes de tes interrogations:
 

il y a 57 minutes, lock042 a dit :

Je comprend pas tout ici. Dans siril, tu peux charger des fichiers venant de partout. Par contre, en effet ils seront tous converti dans le dossier de travail. Ce dernier est hérité de IRIS d'ailleurs et permet de savoir ou on met les choses, surtout quand on script. D'ailleurs en parlant de scripts, tu pourrais facilement automatiser tes conversions.

Je parle de l'étape où on doit ajouter les fichiers à convertir dans l'espace ou il est écrit "Source"
Le fait de cliquer sur le bouton "ajouter des fichiers à convertir" me fait attendre 20s avant de me proposer de naviguer dans l'arborescence du PC pour trouver les fichiers en question ; comme je dois le faire une vingtaine de fois à la longue c'est beaucoup

Si on pouvait par exemple cliquer-déplacer les fichiers depuis l'explorateur de fichiers directement dans l'espace "source" ( un peu comme dans IRIS après être passé dans le menu "sélectionner des fichiers" ), je gagnerais un temps fou.

 

il y a une heure, lock042 a dit :

 

Il y a 2 heures, Roch a dit :

Il faut que je pense à cocher "garder le 1er canal" dans l'onglet conversion,

Ce genre de paramètre, on l'utilise assez rarement d'ailleurs. Pkoi l'utilises tu ?

Alors je fais mes captures en .png, et pour une raison que j'ignore, les fichiers après conversion m'arrivent en couleur, ce qui fait donc un fichier image trois fois plus gros avec trois canaux identiques. ( en tout cas ça fait ça dans IRIS, et il me semble avoir vu ça aussi dans Siril )
Donc en ne prenant que le premier canal j'évite ce problème. Enfin je crois
 

 

il y a une heure, lock042 a dit :

Pour ici, la plupart des fonctions réellement importante sont sauvegardés. Notamment dans les paramètres.

 

Il y a quand même beaucoup de choses qui ne sont pas conservées... en plus de celles que j'ai déjà mentionnées, il y a tous les paramètres à cocher / décocher dans alignement ( la méthode, le "drizzle simplifié", idem dans l'onglet "prétraitement... je le fais toujours de la même manière, donc si le logiciel pouvait se "souvenir" que je n'utilise qu'un dark sans offset ni flat et que je ne fais pas de correction cosmétique d'une fois sur l'autre, ce serait sympa de sa part

 

il y a une heure, lock042 a dit :

Alors la je suis désolé, mais il va falloir que tu changes de crémerie ou que tu passes au SER. En effet, cette limite de 2048 est inscrite en dure dans le code de Microsoft WIndows. Sous macOS et Linux c'est 10 000, et cette fois c'est la librairie cfitsio qui marque cette limite (et encore j'ai demandé aux gars qui la code d'augmenter la limite qui était à 1000 avant). Attention, cette limite n'existe pas pour un empilement par somme, seulement pour des empilement ou siril a besoin de lire tous les fichiers avant.

Okok c'est compris  je bosse en .ser pour le traitement maintenant de toute manière, c'est en effet ce qui semble le mieux.
Par contre, j'avais également essayé avec un empilement par somme, et il n'avait pas voulu non plus à cause de cette fameuse limite.

le .ser a des avantages, mais pour l'acquisition par exemple, il a aussi des inconvénients : il est plus lourd que du .png et surtout, un plantage signifie la mort de tout le fichier .ser et donc potentiellement la perte de plusieurs minutes voir heures d'acquisition.
D'ailleurs c'est pour ça que je ne fais plus de .ser en sortie... une déco de la caméra ou autre bug du logiciel de capture est si vite arrivé.

 

il y a une heure, lock042 a dit :

Alors là ... Ne reve pas. On a essayé vite fait, et c'est trop le bordel. Juste pour rappel, on est deux développeurs et aucun de nous n'utilise Windows :). Donc bon :).

De plus, 32 bits c'est obsolète maintenant et on est limité en traitement, surtout si tu fais beaucoup de fichiers.

Compris

 

il y a une heure, lock042 a dit :

La tu as raison, c'est quelque chose que je veux faire un de ces 4 .... mais ... je trouve jamais la motivation. En même temps c'est pas un problème simple. En effet, une étoile va pas saturer au même ADU pour tous les capteurs.

Chez un canon 14bits ca va etre vers les 14000 et non 16383, dans les APN 12bits ca sera 4095, pour les caméra 16bits ca sera 65534 ... etc ... Bref, comment on fait pour définir quand l'étoile a vraiment saturé  ???? J'ai pas de solution simple.

Oui, d'autant qu'après le retrait du dark et autre normalisation c'est encore plus compliqué.
je vais essayer de réfléchir à quelque chose.

Après une manière "simple" pourrait être de partir du principe d'exclure les valeurs de fwhm aberrantes ou trop éloignées, par exemple, d'une médiane des valeurs de fwhm de toute l'image.
A priori il y aura toujours plus d'étoiles non-saturées que d'étoiles saturées. Bon après il pourrait y avoir plus de galaxies que d'étoiles ( j'ai fait abell1185 récemment et je suis sûr que c'est le cas ) mais à mon avis il y a moyen de trouver une méthode de réjection efficace, en partant du principe que les étoiles seront toujours les points où la FWHM sera la plus faible ( sauf valeur aberrante, mesure d'une fwhm sur un pixel mort ou rayon cosmique )
 

 

il y a une heure, lock042 a dit :

Augmenter la précision est le chantier de la 1.0. Chantier pas encore commencé. Comme je t'ai dit, on n'est que deux et on a déjà tellement de trucs ouverts en même temps .... Cela dit, les calculs internes sont tous fait en précision double quasiment (soit 64bits), c'est juste qu'on converti en 16 bits à la fin à cause de "cœur" de siril, ancien. Ceci est d'autant plus vrai si tu empile avec l'algo somme, qui est souvent l'outil utilisé pour un tel nombre d'images dans le ciel profond rapide.

Ravi de l'entendre

Merci à toi et ton acolyte pour le boulot fourni, je tâcherai d'aider au mieux ; déjà je continuerai mon petit compte rendu au plus vite.

Romain

[lock042]

il y a 13 minutes, Roch a dit :

Si on pouvait par exemple cliquer-déplacer les fichiers depuis l'explorateur de fichiers directement dans l'espace "source"

OK, on va essayer de voir ca.

 

il y a 13 minutes, Roch a dit :

Alors je fais mes captures en .png

Houla .... A éviter, vraiment. On capture en FITS ou en SER. Deux format astro qui permettent de stocker des data brutes. Le logiciel de capture doit te créer des png faussement monochromes, mais avec les trois couches identiques. D'ou le résultat dans siril. Bref, oublie le PNG, sérieusement, sauf pour enregistrer le résultat final !!

 

il y a 13 minutes, Roch a dit :

Il y a quand même beaucoup de choses qui ne sont pas conservées... en plus de celles que j'ai déjà mentionnées, il y a tous les paramètres à cocher / décocher dans alignement ( la méthode, le "drizzle simplifié", idem dans l'onglet "prétraitement... je le fais toujours de la même manière, donc si le logiciel pouvait se "souvenir" que je n'utilise qu'un dark sans offset ni flat et que je ne fais pas de correction cosmétique d'une fois sur l'autre, ce serait sympa de sa par

Oui et non. Le problème est que par exemple. Si on sauvegarde tous les paramètres dans l'onglet "empilement", comme ce dernier est utilisé pour faire les master et aussi l'empilement final, ca n'aurait pas de sens. Il y'a plein de situations identiques avec d'autres options. Dis toi que l'utilisation de Siril est plus large que ton utilisation et qu'il faut toujours y penser. Pour le Drizzle, encore, pourquoi pas. A voir.

 

il y a 13 minutes, Roch a dit :

Par contre, j'avais également essayé avec un empilement par somme, et il n'avait pas voulu non plus à cause de cette fameuse limite.

Alors la, permet moi d'insister mais non :). Cela devait être autre chose car pour la somme on lit les fichiers au fur et à mesure.

 

il y a 13 minutes, Roch a dit :

le .ser a des avantages, mais pour l'acquisition par exemple, il a aussi des inconvénients : il est plus lourd que du .png et surtout, un plantage signifie la mort de tout le fichier .ser et donc potentiellement la perte de plusieurs minutes voir heures d'acquisition.

Euh, oui mais nooooooooooooooooooon. Pas le png :). Sinon, le SER il faut en faire plusieurs. Ensuite dans siril tu peux les concaténer. L'avantage du SER c'est que tu as l'horodatage précis, un entête utile et c'est prévu pour l'astro !!

 

il y a 13 minutes, Roch a dit :

une déco de la caméra ou autre bug du logiciel de capture est si vite arrivé.

Dans ce cas la, siril sait généralement réparer le SER corrompu.

 

Demain je présente les nouveautés de Siril 0.9.10 lors de la Journée de l'Occasion de l'Astronomie à Communay. Au cas où tu n'habites pas loin.... Je présente des trucs dont tu me parles :).

 

Modifié 8 mars 2019 par lock042

[Roch]

Je préfère toujours le .png au .fit parce que ça prend moins de place et que l'espace sur mon PC d'acquisition coûte très cher
Rien ne m'empèche de convertir en .ser par la suite sur mon pc de traitement.
Et quand bien même, avant je shootais en .ser et j'ai perdu des fichiers de 30mn. Même si j'en fais plusieurs, il faut bien que je laisse le bazar tourner si je veux aller faire une sieste...
Et là en revenant, c'est le drame.

Bref

Tiens, autre suggestion en passant, pourquoi ne pas convertir nativement les fichiers en .ser ( sans que l'on doive rajouter l'extension manuellement ) et nous laisser rajouter l'extension .fit si on veut vraiment du .fit ? Puisque ça a l'air d'être plus intéressant le .ser, autant le favoriser au maximum non ?

 

il y a 19 minutes, lock042 a dit :

Dis toi que l'utilisation de Siril est plus large que ton utilisation et qu'il faut toujours y penser.

Je suis entièrement d'accord. Mais en gros, l'idée était de pouvoir démarrer Siril dans l'état exact ou on l'avait laissé en l'éteignant. Avec les mêmes options cochées, les mêmes séquences chargées, les mêmes darks/offsets chargés... à mon avis c'est justement une option qui devrait satisfaire tout le monde, non ?
Bon après ce n'est pas non plus très important, juste du confort

Malheureusement je bosse demain, et Communay c'est un peu loin  une prochaine fois !

Romain

[lock042]

il y a 31 minutes, Roch a dit :

Rien ne m'empèche de convertir en .ser par la suite sur mon pc de traitement.

Oui mais dans ce cas tu pers tout l'horodatage et tu dématrices le fichier dans le cas de cam couleurs. Et ca on veut éviter.

 

il y a 31 minutes, Roch a dit :

Même si j'en fais plusieurs, il faut bien que je laisse le bazar tourner si je veux aller faire une sieste... 
Et là en revenant, c'est le drame.

Pas si tu programmes une séquence sur Firecapture. Avec @exaxe on avait écrit un papier sur astrosurf magazine sur le sujet.

 

il y a 31 minutes, Roch a dit :

Tiens, autre suggestion en passant, pourquoi ne pas convertir nativement les fichiers en .ser ( sans que l'on doive rajouter l'extension manuellement ) et nous laisser rajouter l'extension .fit si on veut vraiment du .fit ? Puisque ça a l'air d'être plus intéressant le .ser, autant le favoriser au maximum non ?

Car le FITS est plus commun et contient un entête sans limite. Du coup le FITS est mieux pour une utilisation classique. Le SER est top pour les grosses quantités d'images. Et encore, en fait il existe le FITS cube (une dimension en plus) qui permet de faire comme le SER, mais on le gère pas encore. Les logiciels de capture non plus. De plus le SER est limité a 16bits. Pas le FITS.

 

il y a 31 minutes, Roch a dit :

à mon avis c'est justement une option qui devrait satisfaire tout le monde, non ?

Pas forcément, car une meme option peut etre coché ou non dans une meme session selon ce qu'on fait.

Modifié 8 mars 2019 par lock042

[Roch]

il y a 12 minutes, lock042 a dit :

Car le FITS est plus commun et contient un entête sans limite. Du coup le FITS est mieux pour une utilisation classique. Le SER est top pour les grosses quantités d'images. Et encore, en fait il existe le FITS cube (une dimension en plus) qui permet de faire comme le SER, mais on le gère pas encore. Les logiciels de capture non plus.

Ok.
Le pb que j'ai avec le système actuel est qu'on est sensés savoir qu'il faut mettre l'extension .ser au préalable ; du coup un nouveau venu ne pourra pas le savoir facilement.
Dans ce cas peut être le mieux serait de mettre un choix (.fit ou .ser) dans l'onglet de conversion, avec l'option réglée sur .fit par défaut.
 

 

il y a 16 minutes, lock042 a dit :

Pas forcément, car une meme option peut etre coché ou non dans une meme session selon ce qu'on fait

Ok aussi,
Dans ce cas une option à cocher dans les paramètres divers, qui s'appellerait "se souvenir des informations de ma session précédente"... par exemple juste en dessous de "se souvenir des positions des fenêtres"

Bref, encore une fois ça reste des suggestions  je ne demande rien, je donne simplement mon opinion ; vous faites ce que vous en voulez ensuite.

Romain

[lock042]

@Roch   : pour evaluer une séquence sans te soucier des étoiles saturées.

Selection d'une étoile. Clic droit. Psf de la séquence. Tu reproduis sur plusieurs étoiles. Tu vas dans l'onglet graphique et tu peux jouer.

[exaxe]

Intéressant ce sujet!

Romain, si tu as des soucis de stabilité avec le SER, tu peux l'ameliorer avec l'option USB trafic dans FC , tu utilises FC?

Je pense qu'il va falloir passer à du 64b et en SER si tu veux dormir.

 

Il y a 4 heures, Roch a dit :

Une option qui serait très appréciable serait de pouvoir enlever toute une série d'images ( en sélectionnant la première et la dernière à enlever ) plutôt que de devoir toutes les sélectionner individuellement ; très utile en cas de passage nuageux par exemple.

c'est bien cela! je le fait avant avec PIPP

Il y a 4 heures, Roch a dit :

Néanmoins, il serait appréciable de pouvoir trier les étoiles, par exemple par ordre croissant ou décroissant de fwhm, en cliquant sur l'en-tête de colonne correspondant.

Apres l'alignement , je retourne sur la fenetre visu, et je clic sur qualité, il me tri par ordre decroissant ou croissant mes images, j'ai la possibilité de choisir ma meilleure brute dans les images, ou de deselectionner celles qui sont incoherentes (souvent la buée ou des nuages qui diminue la lumiere de mon etoile guide creeant des fausses données).

 

 

 

 

 

[Roch]

Me revoilà

Edition du sujet initial : ajout des points B-3 et B-4

 

Le 08/03/2019 à 23:40, exaxe a dit :

Apres l'alignement , je retourne sur la fenetre visu, et je clic sur qualité, il me tri par ordre decroissant ou croissant mes images, j'ai la possibilité de choisir ma meilleure brute dans les images, ou de deselectionner celles qui sont incoherentes (souvent la buée ou des nuages qui diminue la lumiere de mon etoile guide creeant des fausses données).

Yes ! Merci, je ne connaissais pas cette fonction

Après, je parlais de trier les étoiles par FWHM au sein d'une même image ( en gros, trouver l'étoile la plus fine et la moins fine  )
 

 

Le 08/03/2019 à 23:26, lock042 a dit :

pour evaluer une séquence sans te soucier des étoiles saturées.

Selection d'une étoile. Clic droit. Psf de la séquence. Tu reproduis sur plusieurs étoiles. Tu vas dans l'onglet graphique et tu peux jouer.

Oui, j'ai déjà fait.

D'ailleurs, rien à voir, mais je trouve toujours une différence significative entre la FWHM donnée par le module automatique et celle donnée par sélection manuelle d'une étoile... des idées sur le pourquoi du comment ?
La sélection manuelle me donne typiquement des valeurs bien plus élevées.

Romain

[lock042]

il y a 5 minutes, Roch a dit :

des idées sur le pourquoi du comment ?

Pour des raisons de rapidité en auto on fit avec un paramètre (l'angle) en moins.

[lock042]

Le 08/03/2019 à 18:47, Roch a dit :

3) l'alignement des images

De ce que je comprend, c'est un mode mosaique que tu demandes. DSS le fait, mais en effet ca fait des bords d'image avec un rapport signal sur bruit un peu plus pourri.

 

 

Le 08/03/2019 à 18:47, Roch a dit :

Si je ne me trompe pas, il n'est pas possible de sortir une séquence d'image constituées, par exemple, des 2000 meilleures images selon la PSF ; ce serait également une option appréciable, et ce, pour l'ensemble des critères de sélection imaginés ci-dessus.

Tu te trompes. On peut exporter une séquence avec les meilleures FWHM.

Pour ce que est de croiser les paramètres, on a un ticket ouvert sur le sujet :).

Modifié 10 mars 2019 par lock042

[exaxe]

Il y a 8 heures, Roch a dit :

Après, je parlais de trier les étoiles par FWHM au sein d'une même image ( en gros, trouver l'étoile la plus fine et la moins fine  )

Je n'avais pas compris, c'est dans le cadre de l'alignement global ?

[lock042]

Le 08/03/2019 à 18:47, Roch a dit :

Pour finir, le design de la fenêtre laisse penser qu'une option "click and drag" doit être possible

Il y'a de bonnes chances pour que le drag and drop soit présent dans la prochaine version ;).

[lock042]

Le 08/03/2019 à 18:47, Roch a dit :

Néanmoins, il serait appréciable de pouvoir trier les étoiles, par exemple par ordre croissant ou décroissant de fwhm, en cliquant sur l'en-tête de colonne correspondant.

C'est codé pour la 0.9.11.

 

Le 08/03/2019 à 18:47, Roch a dit :

Pour finir, le design de la fenêtre laisse penser qu'une option "click and drag" doit être possible... or, ça ne marche pas. Pas pour mes fichiers .png en tout cas.

Ca aussi.

[Roch]

Merci lock, déjà de belles avancées !

Pas encore fini mon post initial, ça va venir, il faut juste que je touve le temps

 

Romain

[Roch]

Bon, j'ai rajouté un énorme pavé, donc "up" pour ceux que ça intéresse

 

J'ai rajouté les parties B-5, C-1, C-2 et C-3

 

Je sais que j'en ai oublié, mais j'ai déjà fait le tour de ce qui me trotte dans la tête à l'heure actuelle. 

Il me reste aussi les fonctions d'astrométrie à tester... bref tout ça ne fait que commencer, je repasserai régulièrement !  

Ah et puis j'éditerai quanad j'aurai testé les fonctionnalités implémentées avec succès pour afficher la progression
 

 

Le 11/03/2019 à 07:17, exaxe a dit :

Je n'avais pas compris, c'est dans le cadre de l'alignement global ?

Non, simplement  sur une image... pour trouver facilement la "meilleure étoile"
Purement informatif, juste une petite fonction pratique comme ça en passant

 

Modifié 7 avril 2019 par Roch

[vinvin]

Bonjour Roch et merci beaucoup pour ce message détaillé ! Contrairement à Cyril qui a vite répondu, je te réponds avec 7 mois de retard :)

Une partie des commentaires ont déjà été résolus dans les nouvelles versions, voici quelques autres en vrac :

• A-1) Le problème des 20s d'attente est uniquement lié à windows et je ne sais pas s'il a été réglé depuis.
• A-2) l'ergonomie n'est pas une chose simple. Avoir un programme à la fois capable de plein de choses et utilisable facilement nécessite d'y travailler activement, et donc d'avoir quelqu'un qui s'occupe de ce problème... Malheureusement, c'est rarement faisable dans un projet gratuit et rarement le cas en astronomie à ce que j'ai pu voir.
• A-8) windows 32 bits nous avions essayé et ça ne fonctionnait pas malheureusement, par contre pour linux 32 bits (et processeur ARM en particulier) ça fonctionne très bien.
• B3) le résultat assez grand pour contenir toutes les images d'entrées avec leurs déplacements relatifs serait assez sympa aussi, un utilisateur l'avait implémenté avec des valeurs fixes de marges alors nous ne l'avions pas intégré, mais c'est prévu pour une future version, juste moins prioritaire que d'autres choses
• B5) le bayer drizzle, pour une raison que je n'explique pas, n'est pas aussi simple que nous pourrions croire. Nous avons essayé deux fois sans résultat meilleur que sans... Mais c'est prévu...

Le 08/03/2019 à 17:47, Roch a dit :

Même une image contenant 14 bits de dynamique aura quelques pertes si elle est codée en 16 bits et sera légèrement mieux rendue si elle est codée en 32 bits.

Si ce sont les mêmes nombres en 14 16 ou 32, ça ne change rien à l'image résultante. Pour l'empilement de plein d'images oui, mais pas pour une seule.

 

Je répondrai à la partie C dans les jours qui viennent.

[vinvin]

C1)

Le 08/03/2019 à 17:47, Roch a dit :

La différence entre les informations issues du ciel et les signaux parasites de notre instrumentation, c'est que ces derniers restent parfaitement immobiles sur l'image alors que le signal bouge selon les aléas de notre monture.

Parmi les signaux parasites il y a du bruit, sinon les images de biais et dark seraient toujours les mêmes, et donc on ne peut pas simplement les identifier, c'est une quesiton de rapport signal/bruit. Je crois qu'avec la méthode à laquelle tu penses tu peux arriver à trouver la réponse des photosites du capteur, donc l'équivalent du flat field, mais je crois que tu perdras des informations faibles dans le fond de ciel. Un professionnel m'a dit qu'ils faisaient un dark par image, en alternance, ce qui rejoint ta remarque sur la variation lente des signaux majeurs des darks. Je ne sais pas comment c'est traité par contre.

 

C2) c'est la problématique principale du ciel profond rapide. Doit-on avoir plus d'images moins faciles à aligner ou moins d'images avec plus de signal pour les aligner ? Je n'ai pas la réponse à cette question. Empiler des images deux à deux, est-ce mieux que de faire des poses deux fois plus longues ? Si l'empilement ne donne pas des étoiles rondes, l'alignement à plusieurs étoiles ne sera pas forcément plus facile, et probablement qu'avec deux images seulement il n'y aura pas d'étoile de plus qu'à une seule.

 

C3) enlever le gradient de fond de ciel à chaque image au lieu de l'enlever au résultat qui en fait une moyenne est probablement une bonne chose dans le cas où les conditions d'acquisition changent beaucoup. Mais le faire automatiquement n'est en effet pas simple. On pourrait le faire un peu automatiquement en le faisant manuellement sur une image avant empilement, sauvegardant les paramètres qui ont permis d'identifier les zones, et appliquant les mêmes paramètres à chaque image. Et pour le reste du commentaire, je crois que les algorithmes de rejet de l'empilement moyen de siril et PI correspondent un peu au coefficient dont tu parles.

 

Merci

[exaxe]

il y a 27 minutes, vinvin a dit :

c'est la problématique principale du ciel profond rapide. Doit-on avoir plus d'images moins faciles à aligner ou moins d'images avec plus de signal pour les aligner ? Je n'ai pas la réponse à cette question. Empiler des images deux à deux, est-ce mieux que de faire des poses deux fois plus longues ? Si l'empilement ne donne pas des étoiles rondes, l'alignement à plusieurs étoiles ne sera pas forcément plus facile, et probablement qu'avec deux images seulement il n'y aura pas d'étoile de plus qu'à une seule.

Je pense qu'on ne peut pas trancher.

Il faut garder une certaine coherence entre 3 points, voir 4:

-Echantillonnage :plus l'objet prend de la place sur le capteur moins il est lumineux mais on a la possibilité de separer les details ,  mais--->

-Seeing( mais pas la turbulence rapide, on reste encore trop lent): plus cela bouge plus il faut aller vite mais------->

-Magnitude de surface de la cible, moins il y a de lumiere plus il faudra poser lentement mais-------------------------->

- les logiciels ne font de miracle; donc il faut un minimun de lumiere. Juste de quoi faire la difference entre le bruit de fond et la cible.