leforgeron Posté 5 juin Posté 5 juin Bonjour J'acquière mes image avec ASTROART9 avec une camera Player one Artemis couleur pro. Mes Darks sont bien noirs et en moyenne à 314 ADU de mémoire. Mes Biases présentes des bandes mais tournent autour de 312 ADU Avec les stats de AA9 Si j'ouvre les images dark avec SIril tout est ok bien noir et stat à 314 ADU env Mais les Biases sont lumineux bien que linéaires et les stat montent à 32780ADU. Le mot Bzero = 0 sur les bias ce qui explique ce décalage. Mais du coup, puis je utiliser ces biases ? Si non je ne vois pas comment modifier le Bzero si non une image après l'autre. Merci pour votre aide. Bon ciel Régis.
nico1038 Posté 6 juin Posté 6 juin (modifié) Le 05/06/2025 à 13:36, leforgeron a dit : Bonjour J'acquière mes image avec ASTROART9 avec une camera Player one Artemis couleur pro. Mes Darks sont bien noirs et en moyenne à 314 ADU de mémoire. Mes Biases présentes des bandes mais tournent autour de 312 ADU Avec les stats de AA9 Si j'ouvre les images dark avec SIril tout est ok bien noir et stat à 314 ADU env Mais les Biases sont lumineux bien que linéaires et les stat montent à 32780ADU. Le mot Bzero = 0 sur les bias ce qui explique ce décalage. Mais du coup, puis je utiliser ces biases ? Si non je ne vois pas comment modifier le Bzero si non une image après l'autre. Merci pour votre aide. Bon ciel Régis. Voir davantage Hello Régis, D'après les standards du format FITS (https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf), je ne comprend pas vraiment l'usage de Bzero = 0 et surtout je ne vois pas pourquoi cette valeur serait différente pour des bias par rapport aux autres types de fichiers? Pourrais tu partager un de ces bias? Modifié 6 juin par nico1038
keymlinux Posté 6 juin Posté 6 juin Bonjour, Il semblerait que ce problème soit connu (déjà discuté sur el forum astroart) https://www.astroart-forum.net/forum/viewtopic.php?f=2&t=222&p=749&hilit=bzero#p749 Lors de l’enregistrement du fichier fît, si il y a au moins une valeur de pixel supérieure a 32768 (ce qui est le cas sur tes dark sur les pixels chauds) alors les valeurs sont écrites en entiers signés entre -32k et +32k avec un bzero a 32768. Si par contre la valeur max des pixels est inférieure a 32k ( cas de tes bias) alors le fît est écrit avec des valeurs entre 0 et 32k et le bzero=0
nico1038 Posté 6 juin Posté 6 juin (modifié) Le 06/06/2025 à 09:55, keymlinux a dit : Bonjour, Il semblerait que ce problème soit connu (déjà discuté sur el forum astroart) https://www.astroart-forum.net/forum/viewtopic.php?f=2&t=222&p=749&hilit=bzero#p749 Lors de l’enregistrement du fichier fît, si il y a au moins une valeur de pixel supérieure a 32768 (ce qui est le cas sur tes dark sur les pixels chauds) alors les valeurs sont écrites en entiers signés entre -32k et +32k avec un bzero a 32768. Si par contre la valeur max des pixels est inférieure a 32k ( cas de tes bias) alors le fît est écrit avec des valeurs entre 0 et 32k et le bzero=0 Voir davantage Il manque visiblement des messages dans la discussion pour pouvoir tout suivre mais en tous cas, si je me réfère à la dernière version des standarts FITs (pourtant antérieure à la conversation), cette façon de faire me semble incorrecte de la part d'astroart Le format fit requiert que les images 16 bits soient enregistrées avec des valeurs signées. Or comme les caméras écrivent des valeurs non signées, il existe une procédure clairement définie pour régler cette situation. Il y a même un exemple concret dans le pdf définissant le standard: Citation To cite a spe-cific, common example, unsigned 16-bit integers are represented in a signed integer FITS array (with BITPIX = 16) by setting BZERO = 32768 and BSCALE = 1 Voir davantage Modifié 6 juin par nico1038
leforgeron Posté 6 juin Auteur Posté 6 juin Bonjour Oui le standard Fits défini des règles et en principe AA s'y plie. Et Siril Egalement mais a l'ouverture avec AA ce n'est pas la même avec Siril. Je vous envoie des fichiers des que je suis sur mon ordi avec les entête fits et les stats. Si ce décalage ne changeait en rien l'histo de l'image cela ne me poserait pas de souci. Mais là...
keymlinux Posté 6 juin Posté 6 juin Pour Siril, il me semble ( pas sur, à confirmer), que Siril n’implémente pas directement dans son code la lecture/écriture des fits, il fait appel a une librairie « libcfitsio » qui se charge des i/o (input/output) pour les fichiers fits, et c’est donc les développeurs de cette librairie qui ont la charge d’implémenter la norme fits @lock042 aurait tu un avis sur le problème rencontré ? Cordialement, Stephane
leforgeron Posté 6 juin Auteur Posté 6 juin Bonjour voici un Bias Bias_NGC6543 -10° gain 120_002.fitFetching info... Si je l'ouvre avec AA9 les stat sont ok et l'histo bien à gauche Si je l'ouvre avec Siril les stats donne 33084 adu de moy soit en réels normalisés : 0.50448034
keymlinux Posté 6 juin Posté 6 juin J'ai testé l'ouverture du fit avec ASIfitsviewer et Siril Avec ASIfitsviewer, aucun problème, les stats sont min=100, max=524, moy=314 et histogramme bien à gauche Avec siril (1.2 et 1.4 beta), on a des moyennes à 32000 et quelques... Donc même si AstroArt écrit ses fits de manière "atypique" (ne maitrisant pas la norme "fits" je n'ose pas écrire "incorrecte"), il semble que ASIfitsviewer semble s'en accommoder, ce qui n'est pas le cas de Siril. Je suis bien incapable de trancher sur qui a tord ou raison dans l'implémentation, le problème est-il coté AstroArt ou bien Siril, ou bien éventuellement du coté d'une librairie tierce comme libcfitsio Cordialement
leforgeron Posté 6 juin Auteur Posté 6 juin Oui le problème est que ce mot semble être utilisé en décalant l'histogramme si Bzero 32768 valait 0 et bien il n'y aurait pas de souci de Bias. Je vais peut être m'en passer car s'il faut éditer et modifier un pixel a 65000 sur chaque bias même si on ne le fait pas souvent ben ...bof bof. Je ne pense pas qu'il y est une méthode détourner ni sur AA9 ni sur Siril pour régler ce souci. Merci pour vos retours je vais faire avec en attendant que la bibliothèque utilisée par Siril évolue de ce côté si cela est l'origine du problème. Bon ciel Régis.
solfra Posté 9 juin Posté 9 juin Salut @leforgeron, Une solution simple aussi consiste a enlever le keyword BZERO du header fits. Cela ce fait facilement en python. Voici donc en pièce jointe un petit script SIRIL qui enlève le keyword BZERO sur tous les fichier fits du répertoire dans lequel il est lancé. Avec la nouvelle version de Siril tu as juste a exécuter ce script après avoir défini ton répertoire de bias comme répertoire de travail. (Si tu veux le lancer en dehors de Siril il faut enlever les deux première ligne propre à Siril) Tester sur ton image posté plus haut et les valeurs de bias redevienne bien normal, c'est-à-dire autour de 315. remove_bzero.pyFetching info...
leforgeron Posté 9 juin Auteur Posté 9 juin Merci Solfra je vais essayer ça !! Sur les bias et sur les flats. Cyril à jeter un oeil là dessus mais c'est du côté AA9 que l'enregistrement n'est pas bon. Et sur leur forum le pb est évoqué en 2016. AArt stipulent qu'ils suivent scrupuleusement la norme Fits et que les autres logiciels ne sont pas compatibles. Bref je suis bloqué. Mais je vais me servir de ton script. Merci je donne les résultats au plus vite mais un peu surchargé ces temps ci. Bon après midi. Bon ciel Régis.
leforgeron Posté 9 juin Auteur Posté 9 juin Bonsoir. Le script à bien fonctionné et la calibration est faite. Il reste quelques pétouilles que le flat n'a pas supprimé. Mais du coup il est un peu faiblard à 3749 Adu. A refaire sans doute. Merci pour le coup de main. .fNGC6543 version 16 bits.fitsFetching info...
lock042 Posté 9 juin Posté 9 juin Le 09/06/2025 à 10:24, solfra a dit : Une solution simple aussi consiste a enlever le keyword BZERO du header fits. Cela ce fait facilement en python. Voici donc en pièce jointe un petit script SIRIL qui enlève le keyword BZERO sur tous les fichier fits du répertoire dans lequel il est lancé. Voir davantage Siril peut modifier les mots clé FITS nativement. Et ce, sur la séquence entière. 1
leforgeron Posté 10 juin Auteur Posté 10 juin Bonjour lock042. Merci pour l'info. Je vais chercher dans le manuel comment procéder. Mais le script à bien fonctionné. Bon ciel sans fumées canadiennes.
Messages recommandés