Iris/caméra/Encodage fits... J'en apelle à vous les gourous du traitement

[yannp29]

Bonjour à tous,

 

Voilà j'ai un ptit soucis et je n'arrive pas à mettre le doigt dessus. Restant tout de même un novice avec tout ça. J'en appelle à vos lumières et surtout corrigez moi si ma réflexion est erronée.

 

Sous le logiciel de capture de ma caméra (ezplanetary de QHY), j'ajuste mon exposition et mon gain de manière à utiliser le maximum de dynamique possible du capteur (ICX618 sur QHY IMG0H).

J'enregistre en format fit histoire de profiter des 14 bits de conversion A/D.

L'image est bonne et non saturée, je jette un coup d'oeil dans l'histogramme et ça a l'air d'être bon.

Je souligne que sous Registax je n'ai pas ce soucis, mais j'ai voulu voir ce qu'Iris donnait.

 

Voilà pour le tableau.

 

Dites moi ou je me trompe:

L'image est capturée sur 2^14=16384 niveaux

Iris gère les images de -32767 à +32767 soit 2^16 bits (en fait je suppose 2^15 plus un bit de signe)

 

Lorsque j'importe mon image, je devrais avoir à une vache près (si j'ai pris le maximum de l'échelle), ma dynamique comprise entre 0 et 16384 et donc ne pas être saturé à 32767.

 

ci joint une capture d'écran d'une brute non debayerisé.

 

 

Une petite idée????

 

Merci beaucoup

 

Yann

[yannp29]

Edit: Bon en fait je retire ce que j'avais mis.... Ca ne m'avance pas à grand chose.

Toujours le même problème.

 

Et re edit: en fait ça marche mais il ne faut pas que j'importe les fichiers avant... Pfiou on va y arriver

convertsx etc, etc fonctionnent.

 

J'ai donc ouvert un post pour rien.

 

Yann

Modifié 12 septembre 2012 par yannp29

[patry]

Le "problème" du fit c'est que c'est un fourre tout. Tu peux y mettre de l'entier 16 bits signé ou non (softs d'acquisition et de traitement), du 32 bits signé ou non (soft de traitement), du 32 bit flottant (je ne connais qu'avistack pour faire cela).

Iris lit le 16 bit signé nominalement mais convertsx te permet de lire d'autres format (je n'ai essayé que du 16 bit non signé).

 

 

Marc

[yannp29]

Merci Marc pour ces précisions.

 

Il est clair que c'est la première fois que je capture des images en fit directement à la sortie de la caméra et que je n'avais jamais été confronté au problème.

C'est dommage que ce soit comme tu le dis fourre-tout.

Enfin, l'avantage des problèmes c'est que ça permet de se pencher sur le fonctionnement du matériel et des logiciels

 

Merci et bonne soirée.

 

Yann

[patry]

Je sait pas si c'est finalement un problème.

Tout dans l'entête permet de définir ce qu'il y a ensuite ; des données ça d'accord, mais sur un vecteur, un plan, voire en 3D (ou un film en 2D+Temps), comment sont stockées les informations ... bref tout pour qu'un logiciel puisse lire le format.

 

Un peu de lecture là http://adsabs.harvard.edu/cgi-bin/nph-data_query?link_type=ARTICLE&url=http%3a//www.aanda.org/htbin/resolve%3fbibcode%3d2001A%2526A...376..359HPDF&bibcode=2001A%26A...376..359H&db_key=AST

 

voire avec la norme FIT 3.0 ; http://fits.gsfc.nasa.gov/standard30/fits_standard30.pdf

 

 

Marc

[yannp29]

Il est vrai que normalement on devrait y trouver tout ce qu'il faut pour les interpréter.

Le header de mes fichiers stipule 16 bits donc 65536. Ceci expliquant cela. Le logiciel doit tout rééchelonner sur une pleine échelle de 16 bits. Je ne vois pas l'intérêt mais bon.

Il me semble que je ne perds ou ne gagne rien. C'est juste un peu lourd à gérer.

Maintenant, la caméra encodant sur 14 bits, il aurait peut être été plus judicieux que la caméra les enregistre sur 14 bits effectifs (avec 2 bits en rab) plutôt que de rééchelonner tout ça.

 

Merci pour la lecture, il y a une interrogation quand on a potassé tout ça?

 

Yann

Modifié 13 septembre 2012 par yannp29

[patry]

Non, si BITPIX vaut 16, cela veut seulement dire 2 octets par pixel. Par défaut tu est codé en signé (+/- 32k). Maintenant tu a le BZERO pour fixer l'origine de la valeur réelle (et le BSCALE pour changer d'échelle si besoin).

 

C'est pas certain que ton image soit sur 16 bits, mais je penche plutôt sur un 14 bits non signé (ca tombe bien ca rentre dans 16 bits signé tel quel). Avec un visualiseur FIT tu aura vite ta réponse.

 

Marc

[yannp29]

Je me suis mal exprimé. J'ai vérifié dans fitliberator avant d'affirmer que le codage était bien sur 16 bits.

 

Maintenant, je vais potasser la lecture que tu m'a indiqué histoire de visualiser un peu tout ça.

 

ci-dessous la capture d'écran.

[patry]

Ce sont deux choses disjointes, et je peux parfaitement écrire 1, ou 10 ou 100 en 8, 16, ou 32 bits !

Dans ton cas tu a du 16 bits décalé ce qui donne un "non signé" puisque la on doit ajouter 32768 (valeur du BZERO) pour obtenir la valeur réelle.

 

Maintenant je peux parfaitement avoir un codage 10 bits stockés sur 16 bits, et la question sera de savoir où vont se placer les bits à zéro.

Normalement tu cale le signal sur les poids faibles et ton 4095 (max sur 12 bits) vaut aussi 4095 en 16 bits. Par contre tu n'aura jamais 5000 !

Certains logiciels se gourent un peu et pour eux, cette image est parfois présentée à l'écran en virant bêtement l'octet de poids faible ... verdict il ne reste que 16 niveaux de gris (les 4 bits restants).

Autre idée, coller le signal à gauche sur les poids forts. Là tu a bien une image correctement lue par les logiciels mais c'est la discrétisation qui se fait mal (la valeur 0 existe mais la valeur suivante c'est 16, et les valeurs 1..15 n'existent pas !

 

Tout un mic mac pour rentrer une simple valeur entière dans un mot !