Roch

Siril, retour d'utilisateur convaincu !

Messages recommandés

Posté(e) (modifié)

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... :D
 

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 :D
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 :D

 

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 :D

 

 

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 :D

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.

 

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


Work in progress... ;)



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é par Roch
  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

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é par lock042
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)
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é par lock042
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

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é par lock042
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

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 :D
 

 

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

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)
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 :).

 

Capture d’écran du 2019-03-08 21-59-56.png

Capture d’écran du 2019-03-08 22-12-23.png

Modifié par lock042
  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

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... :D
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

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)
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é par lock042

Partager ce message


Lien à poster
Partager sur d’autres sites
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

Partager ce message


Lien à poster
Partager sur d’autres sites

@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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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).

 

 

 

 

 

  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Me revoilà :D


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

Partager ce message


Lien à poster
Partager sur d’autres sites
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.

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)
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é par lock042

Partager ce message


Lien à poster
Partager sur d’autres sites
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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites
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 ;).

  • Merci / Quelle qualité! 2

Partager ce message


Lien à poster
Partager sur d’autres sites
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.

  • Merci / Quelle qualité! 1

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.