FORUM DU LOGICIEL PRISM

Bonjour,

En testant la dynamique de ma nouvelle ASI6200 MM Pro, je me suis rendu compte qu'elle saturait à 32767 car l'option "récupérer les données des pixels issus des caméras au format entier" était cochée dans la configuration générale\Acquisition caméras CCD.

Si j'ai bien compris, on a le choix entre deux options :

1) Cocher cette case et donc dynamique divisée par 2, mais taille de fichiers plus raisonnable,

ou

2) Ne pas cocher cette case, et dans ce cas la caméra "plafonne" bien à 65535, mais fichier conséquents (si bin 1 : 148Mo en FITS, 74Mo en CPA)

Comme j'ai déjà procédé à l'acquisition d'un tas de bias, darks et flats, avec la case cochée, je suppose que si je décoche cette option pour passer en 32 bits par pixel, il faut que je recommande l'acquisition de ces fichiers de calibration ?

Mais pourquoi PRISM ne travaille - t -il pas en entiers non signés, pour conserver la dynamique initiale du 16 bits, sans division par 2 ?

Emmanuel

Pour des raisons historiques Prism traite des entiers en 16 bits signés, pour avoir des valeurs negatives (on fait mieux des maths comme ca)
et puis on est passé direct pixel en 32 bits, ou y a plus de pbs.
Donc c'est comme ca et ca ne changera pas dans un avenir proche ...

travail avec des fichiers 32 bits. Avec le format 16 bits signé ou non, par exemple, si tu additionnes quelques images, tu va tres rapidement saturer car limité par le format. Avec le 32 bits flottant tu peux additionner, diviser a volonté sans perte d'information.
La taille n'est pas vraiment un probleme, on trouve de la capacité facilement maintenant quelque soit le type de support.

Laurent B.

OK, merci pour vos conseils, je vais décocher la case pour récupérer les pixels en 32bits.

Je suppose donc que les fichiers de réduction que j'ai fait en mode 16bits signés sont à refaire ?

Emmanuel

Par prudence oui.
Apres, il y a toujour moyen de faire avec, il faudrait les convertir en masse du format entier vers réel, puis peutetre multiplier les images par 2 (a vérifier entre des images qui ont été tronqués à 32768 ADU et les images divisé par deux pour ne pas dépasser 32768)...

Laurent B.