M13, imx 571, besoin de votre aide

[Lucien 11 325]

Oui c'est un problème de dematricage.

Et le tiff n'est pas une image brute ici.

Et avec en plus le sens d'écriture des fichiers fits ça rajoute une incertitude.

Heureusement qu'il y a les copains avec lesquels on partage.

 

Bonne journée 

Lucien

[nico1038 45]

il y a 5 minutes, ALAING a dit :

Bonjour,

Quand même quelque chose ne colle pas sur cette brute fits !

Effectivement elle se dématrice correctement par contre les méta données indiquent une focale de 346mm et pas 900 ! ! !

Et sur cette brute, la couleur par astrométrie ne passe pas !

Bonne journée,

AG

 

Je ne crois pas que la focale soit présente dans le header de ce fichier (pas plus d'ailleurs que les coordonnées).

Sharpcap semble un peu léger à ce niveau mais ça n'est pas bloquant je pense. En commençant par un platesolve  avec les bons paramètres on peut calibrer cette image par photométrie.

 

[ALAING 59 748]

il y a 13 minutes, nico1038 a dit :

Je ne crois pas que la focale soit présente dans le header de ce fichier

C'est exact.

C'est pourtant la valeur que trouve la couleur par astrométrie en demandant les méta données.

En fait, il faut d'abord passer par la résolution astrométrique qui donne la bonne focale puis couleur par astrométrie qui passe correctement ensuite.

Donc en empilant les 60 images comme cette fits, on doit retrouver la couleur, bien que pas mal d'étoiles soient saturées.

Bonne journée,

AG

[Cyril Richard 1 344]

Il y a 12 heures, Cyril a dit :

Je vais tester ca demain.

Voici une brute en fit

 

M13_00001.fits

J'arrive un peu comme ça, mais cette image n'est pas brute. Elle est déja dématricée.

[nico1038 45]

il y a 19 minutes, Cyril Richard a dit :

J'arrive un peu comme ça, mais cette image n'est pas brute. Elle est déja dématricée.

 

?

C'est bien une image CFA non dématricié.

Modifié 21 mai par nico1038

[Cyril Richard 1 344]

Oui ok, au temps pour moi. J'ai eu un souci de mon côté :).

[Cyril 166]

Il y a 19 heures, nico1038 a dit :

Ok, cette image me semble tout à fait normal.

Le motif de bayer enregistré dans le header est bien le bon: RGGB.

Il y a également le mot clé ROWORDER avec la valeur TOP-DOWN.

 

Du coup SIRIL arrive normalement a dématricier ce fichier correctement si l'option "Bayer information from file's header is available" est bien coché dans les préférences:

 

 

Bonsoir,

Visiblement, je n'ai pas cette version de Siril. J'ai la 9.12.

Je vais mettre à jour ou télécharger la dernière version.

 

Merci

 

[Tromat2 690]

il y a 17 minutes, Cyril a dit :

J'ai la 9.12.

Siril 0.9.12 sortie le 4 novembre 2019.

 

Ah oui quand même !

[Cyril 166]

il y a 9 minutes, Tromat2 a dit :

Siril 0.9.12 sortie le 4 novembre 2019.

 

Ah oui quand même !

 

Je sais, j'ai honte...

[Cyril Richard 1 344]

Ah oui ... la 0.9.12 ... Tu risques d'être surpris par les changements...

[Cyril 166]

il y a 8 minutes, Cyril Richard a dit :

Ah oui ... la 0.9.12 ... Tu risques d'être surpris par les changements...

Plutot oui  😊

Je reconnais rien ! 

Je décroche pour ce soir, ca sera plus clair demain.

Merci

 

[nico1038 45]

@Cyril Richard

Bonjour Cyril, j'en profite pour poser une question  (indirectement lié à ce sujet):

Je comprend que le défaut pour la lecture des fits est bottom-up. Mais, comme Siril est capable d'adapter le dématriciage pour les fits top-down si l'utilisateur a réglé le paramètre ou si il y a un mot clé ROWORDER = "TOP-DOWN" dans le header du fichier, pourquoi ne tient-il pas compte de l'information pour afficher l'image dans le bon sens?

Ce n'est pas vraiement un gros problème et c'est facile à corriger (notamment avec l'option "flip" du Plate Solver) mais ça peut embrouiller et je constate qu'on voit pas mal d'image inversée.

[Cyril Richard 1 344]

il y a 45 minutes, nico1038 a dit :

Mais, comme Siril est capable d'adapter le dématriciage pour les fits top-down si l'utilisateur a réglé le paramètre ou si il y a un mot clé ROWORDER = "TOP-DOWN" dans le header du fichier, pourquoi ne tient-il pas compte de l'information pour afficher l'image dans le bon sens?

Le mot clé ROWORDER n'a pas été fait pour redresser les images. PixInsight a voulu l'utiliser comme ça et ça leur a causé plein de soucis d'ailleurs (j'avais vu sur leur forum).

Si tu veux voir à quel point c'est complexe comme problème, balade-toi sur notre dépôt de code, il y a plein d'effets secondaires quand on veut prendre en compte l'ensemble des possibles. C'est d'ailleurs une des raisons qui a poussé les dev de PixInsight à créer leur nouveau format de fichier. (Format que je n'aime pas du tout, pour d'autres raisons).

Le moyen que nous avons trouvé pour redresser, ou non, l'image, est de faire en fonction de l'astrométrie. Et là, il n'y a pas de discussion possible.

[Tromat2 690]

il y a 13 minutes, Cyril Richard a dit :

Format que je n'aime pas du tout, pour d'autres raisons

On peut savoir pourquoi, en deux mots pour ne pas polluer le fil ? Du point de vue utilisateur je n'ai rien à lui reprocher mais je ne suis pas expert en format de fichier.

[Cyril Richard 1 344]

Il y a 3 heures, Tromat2 a dit :

On peut savoir pourquoi, en deux mots pour ne pas polluer le fil ? Du point de vue utilisateur je n'ai rien à lui reprocher mais je ne suis pas expert en format de fichier.

C'est un format normalement ouvert. Mais ils ne respectent même pas leur standard. À tel point que les logiciels qui l'utilisent, comme NINA, utilisent le type d'entête FITS à l'intérieur des XISF. Alors qu'un des arguments en faveur du XSIF était d'avoir un meilleur système d'entête de fichier. Assez ironique.

Plus d'explications ici : https://siril.readthedocs.io/fr/latest/file-formats/XISF.html

Modifié 22 mai par Cyril Richard

[Tromat2 690]

Ok, ça reste assez obscur pour moi. Je l'utilise pour communiquer entre NINA et Pixinsight et ça fonctionne bien. Après le reste...

[Bigcrunch 2 510]

je pense que si t u veux que l on t'aide il faudrait partir des brutes et non pas de la brute stackée ...
donc une dizaine de brutes avec les DOF  !!!

 

courage
Olivier