[Siril] Création de master de calibration - conservation des infos de header ?

[clouzot]

Je voulais faire quelques expériences avec le logiciel Jocular (un petit soft spécial VA pas très simple d'accès, sachant qu'en plus il est en Python et que le Python c'est le mal incarné). Le soft est censé récupérer tous les FITS qu'on lui balance dans un répertoire spécifique, et les trier (par filtre, par temps d'expo, par type de frame [light, dark, bias, flat] et faire son affaire tout seul.

 

J'ai donc voulu rejouer un stack à partir des fichiers que j'avais sous la main, en particulier un masterfalt fait dans les règles de l'art (avec bias synthétiques bien sûr !) avec Siril.

 

Or le pauvre Jocular s'est retrouvé tout perdu car il n'a pas reconnu qu'il s'agissait d'un masterflat. Et pour cause, il semblerait que Siril (1.0.0-rc2 ici) ne conserve pas certaines infos des subs dans le FITS empilé.

Voilà par exemple ce qu'il y a dans le header d'un FITS unitaire, tel que sauvé par ma boiboite rouge :

 

... et le master créé par Siril

 

Il manque IMAGETYP, dommage car c'est justement ce qui permet aux autre softs (Jocular, mais aussi ASTAP) de s'y retrouver.

 

Sur un masterdark, même combat. Là c'est carrément le gain, la température et le temps d'expo qui ont sauté

 

 

Alors oui, j'imagine que ce n'est pas super simple à gérer et qu'en plus ce n'est pas super normalisé, chaque soft utilise ses petits HDU non standard à lui (l'Asiair inscrit "IMAGETYP", Sharpcap colle du "FRAMETYP" à la place...), mais serait-il possible de rajouter la conservation de toutes les métadonnées utiles dans la liste de souhaits ? Ou bien alors, j'ai fait une fausse manip ?

[lock042]

Siril ne garde que ce qu'il connait.

Les mots clés des FITS étant, pour la plus grande majorité, non standards il est dur (voir impossible) de tout gérer. D'ailleurs tu le montres bien, chacun fait un peu à sa sauce.

[clouzot]

Ok, bien compris. Ceci dit on pourrait imaginer une façon pour SiriL de transmettre même ce qu’il ne connaît pas : si un TAG inconnu est présent dans (toutes) les subs, le laisser tel quel sans y toucher. 
Je suis aussi assez surpris de l’absence d’infos de GAIN et EXPTIME dans le masterdark. Ça SiriL les connaît puisqu’il les reporte (voire les cumule !) quand il fabrique un master flat. 

[lock042]

il y a 5 minutes, clouzot a dit :

Ok, bien compris. Ceci dit on pourrait imaginer une façon pour SiriL de transmettre même ce qu’il ne connaît pas : si un TAG inconnu est présent dans (toutes) les subs, le laisser tel quel sans y toucher. 

Ca veut dire parcourir toutes les images dans un premier temps. Donc niveau perf je trouve que c'est peu envisageable.

 

EXPTIME devrait être présent ceci dit. Quel algo de stack as tu utilisé ?

 

@clouzot : je viens d'ajouter IMAGETYP (et/ou FRAMETYP) comme mot clé géré.

Ca sera dispo sur la prochaine version 1.0.0.

Modifié 17 janvier 2022 par lock042

[clouzot]

il y a 4 minutes, lock042 a dit :

EXPTIME devrait être présent ceci dit. Quel algo de stack as tu utilisé ?

GAIN aussi ça serait pas mal, ainsi qu'OFFSET, et CCD-TEMP, bref, tout ce qui est important pour ne pas faire n'importe quoi ensuite. Ceci dit j'ai une convention de nommage de fichier pour éviter les plus grosses erreurs.

 

Si je me souviens bien, les manips que j'ai faites :

- conversion en séquence : j'ai demandé la conversion soit en SER, soit en séquence de FIT (je fais souvent ça pour éviter d'avoir 3000 fichiers intermédiaires)

- stacking : average with rejection, et sans normalisation puisqu'il s'agissait d'un dark.

 

il y a 8 minutes, lock042 a dit :

Ca veut dire parcourir toutes les images dans un premier temps. Donc niveau perf je trouve que c'est peu envisageable.

Hmm là je ne suis pas sûr de te suivre : on a bien une séquence de fichiers unitaires que Siril va de toute façon ouvrir tous à la file (ou en parallèle) pour les empiler à un moment ou à un autre ? Donc ce qui est dans le header va finir par être lu... mais pas forcément au début, c'est vrai

[lock042]

il y a 4 minutes, clouzot a dit :

qu'OFFSET, et CCD-TEMP,

Ca existe déja. OFFSET est même utilisé pour les bias synthétique.

Ah par contre si tu converti en SER tu perds plein de choses. Et c'est normal car le SER ne possèdent pas autant de mots clés possibles.

[Cissou8]

12 minutes ago, clouzot said:

conversion en séquence : j'ai demandé la conversion soit en SER, soit en séquence de FIT (je fais souvent ça pour éviter d'avoir 3000 fichiers intermédiaires)

Cc, avec du fitseq, ça devrait te preserver les en-têtes, en tout cas, les mots-clefs conservés par Siril. Hormis IMGTYP, ils devraient tous y etre. On veut bien un retour si jamais c'est pas le cas.

 

Je relève pas les méchancetés sur python, je prends ça pour de la provoc

 

C.

[clouzot]

Aaah merci @lock042 et @Cissou8

voilà mon erreur fatale : le SER. Et en plus c’est complètement logique quand on regarde comment est défini le format. 

Je me fais donc un beau post-it qui rime : « Le SER, c’est que pour le planétaire ». 
 

il y a 17 minutes, Cissou8 a dit :

Je relève pas les méchancetés sur python, je prends ça pour de la provoc

  Désolé ce truc me rend fou à chaque fois. Tu connais mon « amour » pour ce diable de Python, je n’ai jamais vu une techno aussi bordélique (et pourtant j’ai bouffé du Matlab matin midi et soir pendant des années). C’est un concentré de soucis de dépendances en cascade, du genre qu’on voit dans les grosses organisations, sauf que là c’est sur MA machine que ça se passe. 

[Cissou8]

6 hours ago, clouzot said:

Ça SiriL les connaît puisqu’il les reporte (voire les cumule !) quand il fabrique un master flat. 

On en discutait avec @lock042 et se posait la question de savoir s'il serait une bonne idee de garder les 2 infos, le temps unitaire et le temps total d'expo. Et d'y associer le nom de cle qui va bien puisque rien n'est standard dans ce standard. En allant piocher la: https://heasarc.gsfc.nasa.gov/docs/fcg/common_dict.html, on voit que LIVETIME correspondrait en definition au temps total d'integration....on laisserait alors EXPTIME a sa valeur de depart.

Quand tu recuperes les cles pour faire tes nomenclatures de fichiers, tu te sers de quoi a priori?

 

 

Modifié 17 janvier 2022 par Cissou8

[clouzot]

@Cissou8 effectivement rien de très standard et ça sent la bonne grosse galère pour trouver un système qui se tienne dans tous les cas. En particulier, rien n'est vraiment prévu pour un FITS issu de l'empilement de plusieurs FITS unitaires, c'est très visible quand on regarde la page NASA que tu lies : le LIVETIME semble plutôt être prévu pour donner le temps d'exposition effectif d'une brute (temps total auquel on retranche les périodes d'inactivité du capteur), même si par extension on pourrait effectivement dire que c'est le temps d'intégration... mais est-ce que les autres softs sauront reconnaître ce tag pour ce qu'il est ?

Pour ma part, je fais tout à la main, sans extraction des infos de header.

 

Pour un masterdark, ce qui importe c'est vraiment le EXPTIME (tel que trouvé dans chaque unitaire, et qui devrait être reporté tel quel, ou moyenné sur l'ensemble des darks unitaires si on veut être précis). Le LIVETIME (temps d'intégration cumulé) n'apporte qu'une information d'historique, finalement (combien de subs ont été empilées pour faire le master)

Pour le masterflat, les infos de temps sont finalement assez optionnelles puisqu'on sait bien que ce qui importe... c'est OFFSET, bien sûr

Enfin pour un stack de lights, il semble qu'actuellement vous mettez EXPTIME comme temps d'intégration total. Je vous rejoins là-dessus, par extension il vaudrait peut-être mieux avoir le duo EXPTIME (durée de chaque unitaire) et LIVETIME (temps cumulé)

 

 

[lock042]

il y a 34 minutes, clouzot a dit :

Pour un masterdark, ce qui importe c'est vraiment le EXPTIME

OUi donc la actuellement on n'est pas bon car EXPTIME est le temps de pose cumulé.

il y a 35 minutes, clouzot a dit :

Enfin pour un stack de lights, il semble qu'actuellement vous mettez EXPTIME comme temps d'intégration total. Je vous rejoins là-dessus, par extension il vaudrait peut-être mieux avoir le duo EXPTIME (durée de chaque unitaire) et LIVETIME (temps cumulé)

OK, j'ai un patch pour ca, que j'ai filé à @Cissou8. Elle me fera un retour pour voir si je pète rien. Mais je pense que le risque est assez minime.

[Cissou8]

2 hours ago, clouzot said:

Enfin pour un stack de lights, il semble qu'actuellement vous mettez EXPTIME comme temps d'intégration total.

En réalité, c'est la même chose qui est faite, que ce soit un stack de lights ou un stack pour faire un master. Y a pas de notion de type de fichiers. On empile ce qui vient.

Mais on est d'accord, disposer des 2 infos, temps unitaire et temps d'integration, c'est certainement une bonne chose. Je teste ca vite

2 hours ago, clouzot said:

Pour ma part, je fais tout à la main, sans extraction des infos de header.

J'ai un bout de python si ça t'intéresse 😁

[Papalima]

Je crois connaître le coupable...

https://www.ouest-france.fr/pays-de-la-loire/mayenne/python-retrouve-en-mayenne-il-n-y-aura-pas-d-enquete-63a48bfe-76b8-11ec-8853-e4e9fff06f6d

[clouzot]

il y a 36 minutes, Cissou8 a dit :

J'ai un bout de python si ça t'intéresse 

Vade retro !

 

je vais le faire en Matlab 

il y a 5 minutes, Papalima a dit :

Je crois connaître le coupable...

https://www.ouest-france.fr/pays-de-la-loire/mayenne/python-retrouve-en-mayenne-il-n-y-aura-pas-d-enquete-63a48bfe-76b8-11ec-8853-e4e9fff06f6d

Heureusement que la distance géographique me disculpe automatiquement 

[Cissou8]

37 minutes ago, clouzot said:

je vais le faire en Matlab 

pffffffff, alors qu'y a astropy qui te fait ça avec une élégance rare...sans avoir besoin (si il existe) d'un énième module...

 

37 minutes ago, clouzot said:

Heureusement que la distance géographique me disculpe automatiquement 

Mouais, on verifiera ton alibi qd meme...

[clouzot]

Sinon, la boîte rouge rajoute un TAG aux masters qu’elle crée : STACKCNT, qui contient le nombre de subs empilés. Aucune idée de si c’est plus ou moins standard. 

 

Citation

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                   16 / number of bits per data pixel
NAXIS   =                    2 / number of data axes
NAXIS1  =                 4144 / length of data axis 1
NAXIS2  =                 2822 / length of data axis 2
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
BZERO   =                32768 / offset data range to that of unsigned short
BSCALE  =                    1 / default scaling factor
CREATOR = 'ZWO ASIAIR'         / Capture software
OFFSET  =                   30 / camera offset
XORGSUBF=                    0 / Subframe X position in binned pixels
YORGSUBF=                    0 / Subframe Y position in binned pixels
FOCALLEN=                 1229 / Focal length of telescope in mm
EGAIN   =     1.00224268436432 / Electronic gain in e-/ADU
XBINNING=                    2 / Camera X Bin
YBINNING=                    2 / Camera Y Bin
CCDXBIN =                    2 / Camera X Bin
CCDYBIN =                    2 / Camera Y Bin
XPIXSZ  =     4.63000011444092 / pixel size in microns (with binning)
YPIXSZ  =     4.63000011444092 / pixel size in microns (with binning)
IMAGETYP= 'Dark    '           / Type of image
STACKCNT=                   20 / Stack frames
EXPOSURE=                  10. / Exposure time in seconds
EXPTIME =                  10. / Exposure time in seconds
CCD-TEMP=                 -10. / sensor temperature in C
DATE-OBS= '2021-08-13T14:33:01.728' / Image created time
INSTRUME= 'ZWO ASI294MM Pro'   / Camera model
GAIN    =                  120 / Gain Value

 

[lock042]

il y a 7 minutes, clouzot a dit :

Sinon, la boîte rouge rajoute un TAG aux masters qu’elle crée : STACKCNT, qui contient le nombre de subs empilés. Aucune idée de si c’est plus ou moins standard. 

Allez, on est dans le troll, tout ce qui sort de la boite rouge n'est pas standard... :).

[clouzot]

il y a 1 minute, lock042 a dit :

Allez, on est dans le troll, tout ce qui sort de la boite rouge n'est pas standard... :).

Je sais 😏

On va faire dans le troll pragmatique alors : il est probable que ça devienne un standard de fait…

[lock042]

Il y a 3 heures, clouzot a dit :

On va faire dans le troll pragmatique alors : il est probable que ça devienne un standard de fait…

T'as de la chance, je fais passer ça en correction de bug ...

Car on ne met pas de nouvelles features avant la 1.0.0 ;).

 

Du coup ca devrait être présent.

[clouzot]

il y a 34 minutes, lock042 a dit :

T'as de la chance, je fais passer ça en correction de bug ...

Car on ne met pas de nouvelles features avant la 1.0.0 ;).

 

Du coup ca devrait être présent.

  

(j’avoue qu’il m’arrive de faire le même genre de tour de passe-passe : « c’est pas une feature, c’est du bugfix ». S’ensuit une pull-request de 3500 lignes de code)

[vinvin]

Je ne vois pas de quoi vous voulez parler https://gitlab.com/free-astro/siril/-/merge_requests/225/diffs

[Cissou8]

@vinvint'as pas fait semblant la...

[vinvin]

J'aime bien tout casser avant la release, ça met un peu de suspense et ça fait plaisir à Cyril

 

Non en fait j'y suis allé mollo, la plupart des trucs que j'avais noté n'étaient pas critiques et réglables avec un if.

[clouzot]

C'est là-dessus qu'il faut cliquer pour prévenir le Siril Bug Review Board, c'est bien ça ?

[lock042]

il y a 3 minutes, vinvin a dit :

J'aime bien tout casser avant la release, ça met un peu de suspense et ça fait plaisir à Cyril

 

Je suis en PLS là.

[Cissou8]

1 minute ago, lock042 said:

Je suis en PLS là.

Ah ben déjà que pour un bugfix/featurette a 6 changes, t’étais fébrile...