Fits Header

[impla007]

Bonjour a tous,

 

J'envisage d utiliser Siril pour des prétraitements automatiques pour de la détection astéroides pour un Survey en cours car on a besoin d'un prétraitement rapide et quasi temps réel. 

Le problème que je rencontre c'est la disparation d'informations de l'entête de mon image brute lorsque celle ci est intégrée à Siril. 

 

A gauche le FitsHeader de l'image brute et a droite le header de la  meme image mais juste passé par l'onglet conversion de Siril. 

 

 

 

Plein d'infos trés utilises pour la suite ont disparues. Alors peut être que j'intègre mal les images dans Siril. Le but de l'utilisation de Siril est de l'intégrer (via scripts)  dans le pipeline pour faire le prétraitement par lots lorsque la totalité du champ aura été imagé. Cependant, si dés le départ du prétraitement, on perd les infos essentielles, cette utilisation n'est plus envisageable. Le but du jeu étant, a la sortie des images pré-traitées, de pouvoir avoir exactement les mêmes infos dans le header que les infos de l'image  d'origine. 

 

Je précise aussi que je passe par l'onglet conversion car je n'arrive pas à faire avaler les images dans Siril juste en lui indiquant le directory de travail .

les images portent ce type de nom :

eclip3_2020-11-12_18-58-20_LIGHT_Lum_-4.10_1x1_60.00_0001.fits

 

 

A mon avis c'est un truc tellement basic que  j'ai du louper quelque chose dans les paramètres de Siril et les milliers de messages et d'infos sur les forums.

 

Merci si vous avez une idée

 

Georges

 

 

 

 

 

 

 

 

[vinvin]

Salut Georges, pour éviter de dupliquer les fichiers qui sont mal nommés, siril peut maintenant faire des liens symboliques, sous windows aussi à condition d'activer le mode développeur de windows. Dans ce cas il n'y aura pas de perte à la conversion.

Mais ce qui est problématique en effet c'est que quand siril lit puis enregistre une image une partie du header disparait, donc ça arrivera après le pré-traitement de toute façon. Il faudrait qu'on gère mieux les mots clés qu'on n'utilise pas. Vu qu'on en ajoute ou qu'on en modifie pendant le traitement, on ne peut pas juste garder ceux d'origine, il faut faire un tri et on le fait mal.

[impla007]

OK... merci Vincent. Donc, j'en conclus que pour l'instant, Siril n'est pas utilisable car les infos importantes dont on a besoin ( pour faire du tracking d'astéroides) auront disparues suite au pré-traitement. 

C'est vraiment dommage car cela coupe quand même une grosse partie d'utilisations potentielles de Siril, notamment tout ce qui est scientifique car,   alpha delta, position de l'observateur et d'autres ect... c'est vraiment important...  On va donc continuer à utiliser notre pipeline de prétraitements... Prism etc... dommage.

 

Merci pour ta réponse rapide, je vais me concentrer sur une autre solution. 

 

Bon ciel a tous. 

 

Georges

 

 

 

 

[lock042]

Bonjour. En fait ce n'est pas un "problème" au sens de bug. C'est un comportement "normal".

Comme dit Vincent, on n'enregistre que les mots clés qu'on utilise en interne, et tous les vrais standards.

 

La principale difficulté du FITS c'est que 99% des mot clés ne sont pas standards. Et puis, certains mot clés DOIVENT disparaitre.

Par exemple toutes les infos WCS n'auront plus de sens une fois l'image alignée avec rotation.

il y a 1 minute, impla007 a dit :

notamment tout ce qui est scientifique car,   alpha delta, position de l'observateur et d'autres ect... c'est vraiment important... 

Oui mais ca ca a pas de sens de les garder une fois qu'on a fait un alignement.

[lock042]

Et d'ailleurs pour continuer, en ce moment j'ai bcp bossé sur l'integration de l'astrométrie.

Les coordonnées WCS ne devraient pas être supprimées lors d'une simple calibration (dark flat offset), juste pendant l'alignement. Cependant, j'ai pas d'images brutes possédants de telles data pour faire un test.

[impla007]

45 minutes ago, lock042 said:

Oui mais ca ca a pas de sens de les garder une fois qu'on a fait un alignement.

Ben justement, c'est pour ca que l'on ne fait pas un empilement mais on en fait 10000 jusqu'a ce que ça match et on recalcule les données de l'empilement qui a marché. Mais, pour cela, il faut que l'on ait les centres des images individuelles, position observateur etc. 

 

8 minutes ago, lock042 said:

Cependant, j'ai pas d'images brutes possédants de telles data pour faire un test.

tu veux des images ?  

[lock042]

il y a 3 minutes, impla007 a dit :

Ben justement, c'est pour ca que l'on ne fait pas un empilement mais on en fait 10000 jusqu'a ce que ça match et on recalcule les données de l'empilement qui a marché. Mais, pour cela, il faut que l'on ait les centres des images individuelles, position observateur etc. 

Je suis pas sûr de comprendre. Désolé.

 

il y a 3 minutes, impla007 a dit :

tu veux des images ?  

oui bien sur

[impla007]

Just now, lock042 said:

Je suis pas sûr de comprendre. Désolé.

On fait du tracking synthétique. dans la pile d'image, chaque image est décalée de la précédente d'un petit x,y . pour chaque décalage x,y, on fait un stack et  on regarde ce qui est fixe. Et on recommence jusqu'a avoir épuisé tous les décalages possibles. Le points qui restes fixes pour chaque décalage sont des astéroides/cometes. 

 

Chaque image fait 60Mpix 16bits... on a des piles de 30 à 60 images sur lesquelles , on peut faire plusieurs milliers de décalages et de  stacks.

On utilise des GPU sur plusieurs machines pour faire cela.

un papier sur le sujet ici. 

 

https://www.researchgate.net/publication/256499035_Finding_Very_Small_Near-Earth_Asteroids_using_Synthetic_Tracking

 

un NEO que l'on a découvert récemment avec ce procédé ici 

 

https://minorplanetcenter.net/mpec/K20/K20UP5.html

 

Cette partie détection  fonctionne a peu prés bien. On a la possibilité de faire le pré-traitement sur les machines GPU mais, cela consomme inutilement de la ressource de calcul. On peut faire le pré-traitement sur les machines d'acquisition mais, les softs actuels sont... lents.... sur des gros volumes. 

 

 

 

 

 

 

 

[impla007]

Je viens d'essayer en activant les liens symboliques, j'ai prétraité avec un retrait du dark... et c'est pareil. Le header de l'image résultante est strippé..

 

 

 

@lock042 Je te mets une image sur mon drive et son dark. Envoi du lien en mp.

 

 

 

 

 

 

 

Modifié 4 décembre 2020 par impla007

[lock042]

Il me faudrait 3-4 images stp. Pas plus.

[impla007]

9 minutes ago, lock042 said:

Il me faudrait 3-4 images stp. Pas plus.

Les images font 120Mb.. et j'ai une liaison montante trés trés trés lente.   Ce soir j'essaye de t'en mettre un peu plus

 

 

[lock042]

En tout cas, ca tombe bien le sujet, car les infos WCS sont clairement le sujet de la branche sur laquelle je bosse ces derniers temps.

[impla007]

Aprés quelques échanges fructueux et  un super boulot trés réactif de @lock042 que je remercie,  la nouvelle branche de dev de Siril permet de conserver des infos importantes pour des traitements futurs dans les images. 

Avec la super aide de @Cissou8 pour générer une version, j'ai testé que les headers conservent bien les infos importantes aprés prétraitements/alignements dans cette nouvelle version. Extra.. On va pouvoir s'amuser avec les objets qui bougent. 

 

Merci encore pour cette réactivité.

 

Georges

 

 

 

 

Modifié 5 décembre 2020 par impla007

[vinvin]

Super ! Merci !