FLAT un peu trop efficace...

[LaurentG23]

Prendre en main Siril n'est pas évident.

Je souhaite utiliser uniquement des flats, je me dis qu'avec un A7III, pas besoin de dark ou offset.

Est-ce la raison d'une trop grande efficacité de mes flats ? Les coins sombres sont maintenant trop clairs et l'image verdâtre. 😪

[solfra]

Salut,

Il faut faire une réduction du bruit vert : https://siril.readthedocs.io/fr/stable/processing/colors.html#remove-green-noise ; puis un étalonnage des couleurs (plus haut dans la page de la doc).

[LaurentG23]

Oui, ça, je sais faire, c'est surtout les coins trop clair avec le flat qui pose probleme... 😉

[180Vision]

58 minutes ago, LaurentG23 said:

Oui, ça, je sais faire, c'est surtout les coins trop clair avec le flat qui pose probleme... 😉

 

Salut,

 

Tu as combien de flats en stack d'une part et comment est ton histogramme ?

[Fred_76]

Attention à bien soustraire l’offset au flat ! 
 

Si tu ne fais pas d’image d’offset, il faut dans ce cas retirer le niveau d’offset. C’est expliqué dans la doc de Siril. RTFM 😑 

[180Vision]

13 minutes ago, Fred_76 said:

Attention à bien soustraire l’offset au flat ! 
 

Si tu ne fais pas d’image d’offset, il faut dans ce cas retirer le niveau d’offset. C’est expliqué dans la doc de Siril. RTFM 😑 

 

Ca ça allait de soi en effet

Quoiqu'il en soit, même sans offset, ça ne devrait pas autant impacté ton image.

Par contre, si tu n'as pas assez de brutes pour ton stack de flats, tu peux avoir une image qui augmente les signal pour X raisons et te retrouver avec une sous/sur correction.

25 flats mes semblent la base.

 

Bon, après, vu la tailler du champ ici, un bon crop va suffire

 

[LaurentG23]

il y a 33 minutes, 180Vision a dit :

Tu as combien de flats en stack d'une part et comment est ton histogramme ?

Une vingtaine, histo au 1/3 comme indiqué dans les "infos bulles."

(C'est surement très détaillé dans la doc, que j'ai lu, mais pas toujours clair pour un novice comme moi)

Je tente de suivre le tuto de Colmic :

Le champ est large, ici, on peut crop sans problème, mais sur certaines nébuleuses, il me faudra conserver un max de champ, autant y arriver maintenant. 😎

[nico1038]

il y a 36 minutes, 180Vision a dit :

Quoiqu'il en soit, même sans offset, ça ne devrait pas autant impacté ton image.

 

Un flat non calibré va provoquer ce genre de sur-correction. Ça me parait normal au contraire.

 

@LaurentG23 Il n'est pas possible de  faire "uniquement des flats". Il faut bien comprendre que tout est lié dans la calibration.

 

Si tu ne fais pas de darks mais que tu veux corriger le champ avec des flats alors il faut non seulement retirer l'offset des flats comme le dit @Fred_76 mais aussi des lights.

 

 

Il y a 2 heures, solfra a dit :

Salut,

Il faut faire une réduction du bruit vert : https://siril.readthedocs.io/fr/stable/processing/colors.html#remove-green-noise ; puis un étalonnage des couleurs (plus haut dans la page de la doc).

 

La correction du bruit vert, si elle s'avère nécessaire ne doit être faite qu'après avoir calibré les couleurs. Avec des images correctement calibrées et sous un bon ciel, cette étape n'est pas forcément nécessaire.

 

Modifié 29 août par nico1038

[180Vision]

13 minutes ago, nico1038 said:

 

Un flat non calibré va provoquer ce genre de surrection. Ça me parait normal au contraire.

 

@LaurentG23 Il n'est pas possible de  faire "uniquement des flats". Il faut bien comprendre que tout est lié dans la calibration.

 

Si tu ne fais pas de darks mais que tu veux corriger le champ avec des flats alors il faut non seulement retirer l'offset des flats comme le dit @Fred_76 mais aussi des lights.

 

 

 

La correction du bruit vert, si elle s'avère nécessaire ne doit être faite qu'après avoir calibré les couleurs. Avec des images correctement calibrées et sous un bon ciel, cette étape n'est normalement pas nécessaire.

 

 

@nico1038 en effet, logique sur la globalité de l'image, je trouvais curieux que cela ne touche que le "vignettage", comme si un flat était "trop fort" en correction. Mais évidemment, difficile visuellement de voir si la globalité de l'image est impactée. Quoiqu'il en effet,  pas de question à se poser flats-bias et light-bias si pas de darks ( @LaurentG23 sinon le bias est contenu dans tes darks déjà soustraits aux lights).

 

Par ailleurs pour info, dans Siril comme Sirilic, tu peux utiliser un masterbias synthétique (une valeur fixe). La doc de Sirili a un chapitre la dessus (ainsi que dans les docs de Colmic qq part il me semble).

 

@LaurentG23 vu que tu utilises Siril, je te conseille de te pencher sur Sirilic qui laissera moins de place au doute/interprétation/oubli une fois compris, même s'il faut en effet bien saisir nénamoins les tenants/abouttissants/méthodes.

 

Modifié 29 août par 180Vision

[LaurentG23]

Merci, je vais relire vos réponses à tête reposée ! C'est bien complexe ce traitement d'image.

(et puis j'ai reçu les pièces de mon nouveau tube, j'ai les yeux pleins d'étoiles)

[nico1038]

il y a 8 minutes, LaurentG23 a dit :

Merci, je vais relire vos réponses à tête reposée ! C'est bien complexe ce traitement d'image.

(et puis j'ai reçu les pièces de mon nouveau tube, j'ai les yeux pleins d'étoiles)

 

Si je peux me permettre un conseil:  la méthode "classique"  de calibration avec darks, flats et bias est éprouvée, elle fonctionne dans toutes les situations et pour tous les appareils et elle n'est pas si contraignante que cela (si tu fais des bibliothèques de darks et de bias).

 

Une fois cette technique maitrisée et  les implications d'un changement comprises, il est alors temps de faire autrement.

Modifié 29 août par nico1038

[180Vision]

Complexe mais très récurrent et procédural donc simple au final .

1 minute ago, nico1038 said:

 

Si je peux me permettre un conseil:  la méthode "classique"  de calibration avec darks, flats et bias est éprouvée, elle fonctionne dans toutes les situations et pour tous les appareils et elle n'est pas si contraignante que cela (si tu fais des bibliothèques de darks et de bias).

 

Une fois cette technique maitrisée et  les implications d'un changement comprises, il est alors temps de faire autrement.

 

Clairement @nico1038 a raison, ce n'est vraiment pas un écueil  en soi ou qqc de mystérieux !

[schizophrene]

Il y a 1 heure, LaurentG23 a dit :

histo au 1/3

 

C'est au ⅔ qu'il doit être

[lock042]

Il y a 3 heures, solfra a dit :

Salut,

Il faut faire une réduction du bruit vert : https://siril.readthedocs.io/fr/stable/processing/colors.html#remove-green-noise ; puis un étalonnage des couleurs (plus haut dans la page de la doc).

Houla absolument JAMAIS dans cet ordre.

Il y a 2 heures, 180Vision a dit :

Quoiqu'il en soit, même sans offset, ça ne devrait pas autant impacté ton image.

 

AH sisi. Un problème d'offset et justement, l'image peut se trouver sur corrigée par le flat. Exemple dans la doc ici : https://siril.readthedocs.io/fr/stable/preprocessing/calibration.html#understanding-how-the-flats-correct-the-lights

[180Vision]

3 minutes ago, lock042 said:

Houla absolument JAMAIS dans cet ordre.

AH sisi. Un problème d'offset et justement, l'image peut se trouver sur corrigée par le flat. Exemple dans la doc ici : https://siril.readthedocs.io/fr/stable/preprocessing/calibration.html#understanding-how-the-flats-correct-the-lights

 

Oui , c'est ce que j'ai complété plus haut, me suis focalisé sur l'effet vignettage mais en effet, on ne se rendrait pas forcément compte sur la globalité du coup.

MErci pour le lien de nouveau.

[Fred_76]

Pour simplifier l'exemple, je n'ai pas considéré les bruits et signaux parasites (bruit de lecture, signal thermique, poussières...).

 

On considère 3 pixels sur une image.

 

Le biais (offset) du capteur est connu et vaut 1024 (noté O).

Pixel	Valeur du pixel sur le RAW de l'image (Vimg)	Valeur du pixel sur le RAW de la PLU (Vplu)
Au centre de l’image	1996	10000
Excentré	1899	9102
Dans un angle	1850	8654

 

Le calcul correct donne donc :

Pixel	Ratio de vignettage f =(Vplu-O)/(Vplu au centre-O)	Valeur signal =(Vimg-O)/f
Au centre de l’image	(10000-1024)/(10000-1024)=    1.000	(1996-1024)/1.000= 972
Excentré	(9102-1024)/(10000-1024)=         0.900	(1899-1024)/0.900= 972
Dans un angle	(8654-1024)/(10000-1024)=         0.850	(1850-1024)/0.850=  972

 

 

 

 

 

 

On se rend compte, et c’est voulu pour l’exemple, que les 3 pixels ont le même niveau d’intensité lumineuse, une fois l’image correctement corrigée.

 

Qu’aurait-on obtenu si l’on avait tenu compte du biais seulement sur l'image, mais pas fait de correction du vignettage ?

Pixel	Ratio de vignettage f	Valeur signal =(Vimg-O)/f
Au centre de l’image	Non applicable	1996-1024=             972
Excentré	Non applicable	1899-1024=             875
Dans un angle	Non applicable	1850-1024=                 826

 

 

 

 

 

 

Comme il n’y a aucune correction du vignettage, l’image s’assombrit quand on s’éloigne du centre, partant de 972 pour arriver à 826.

 

Qu’aurait-on obtenu si on n’avait pas tenu compte du biais pour le flat (erreur courante) ?

Pixel	Ratio de vignettage f =Vplu/Vplu au centre	Valeur signal =(Vimg-O)/f
Au centre de l’image	10000/10000=         1.000	(1996-1024)/1.000= 972
Excentré	9102/10000=                 0.910	(1899-1024)/0.910= 961
Dans un angle	8654/10000=                 0.865	(1850-1024)/0.865=  954

 

 

 

 

 

 

L’application du flat sans tenir compte du biais sous-corrige : l’image s’assombrit toujours sur les bords, partant de 972 pour arriver à 954.

 

Qu’aurait-on obtenu si l’on n’avait pas tenu compte du biais ni pour le flat ni pour l’image ?

Pixel	Ratio de vignettage f =Vplu/Vplu au centre	Valeur signal =Vimg/f
Au centre de l’image	10000/10000=         1.000	1996/1.000=                  1996
Excentré	9102/10000=                 0.910	1899/0.910=                  2086
Dans un angle	8654/10000=                 0.865	1850/0.865=                  2138

 

 

 

 

 

 

L’application du flat sur corrige, le centre n’est pas corrigé du tout et l’image s’éclaircit d’autant plus qu’on s’éloigne du centre.

 

Voilà pourquoi il est important de bien soustraire le biais à l’image ET au flat.

[lionthom]

Perso, je fais les offsets dans la foulée des flats, ça prend 2 minutes et on est tranquille.

[Fred_76]

il y a 38 minutes, lionthom a dit :

Perso, je fais les offsets dans la foulée des flats, ça prend 2 minutes et on est tranquille.

À vrai dire je ne fais plus d’offset du tout! Je me contente de retirer le niveau d’offset… (2048 pour un Canon 6D).

[180Vision]

1 hour ago, Fred_76 said:

À vrai dire je ne fais plus d’offset du tout! Je me contente de retirer le niveau d’offset… (2048 pour un Canon 6D).

Idem.

 

Et alors, chose incroyable, sur l'imx571 Altaïr (26M), la valeur mean du bias, est égale à la valeur d'offset de la caméra !!

Autrement dit  BIAS = 1*$OFFSET...

 

@shibon tu observes la même chose sur ta 26C ?

 

[Fred_76]

C’est normal !

 

Les caméras actuelles ont un bruit de lecture tellement faible par rapport au niveau d’offset (ou de biais, c’est le mot français pour offset) est négligeable… d’où ton constat.

 

C'est moins vrai sur les caméras plus anciennes.

[nico1038]

il y a une heure, Fred_76 a dit :

C’est normal !

 

Les caméras actuelles ont un bruit de lecture tellement faible par rapport au niveau d’offset (ou de biais, c’est le mot français pour offset) est négligeable… d’où ton constat.

 

C'est moins vrai sur les caméras plus anciennes.

 

Je crois que ce dont @180Vision parles c'est le rapport entre la valeur de réglage de l'offset et la valeur ADU du bias. Or cela n'a en général rien à voir:  la valeur de réglage de l'offset est une échelle arbitraire choisie par le constructeur et qui est ensuite convertie en valeur ADU (par le driver j'imagine?). Les deux valeurs sont donc directement liées (par une relation proportionnelle)  mais différentes.

 

Par exemple sur ma ASI2600MC une valeur d'offset réglée à 100 correspond à une valeur ADU (sur 16 bits) de 500.

et sur mon ASI533MC une valeur d'offset réglée à 70 correspond à une valeur ADU (sur 14 bits) de 700.

 

A priori Altair fait les choses plus simplement et la valeur de réglage = la valeur en ADU

Modifié 30 août par nico1038

[Fred_76]

Ok ! Je suis « APN » et avec un appareil photo, c’est plus simple ! Pas de conversions bizarres et ésotériques 😉 

[180Vision]

3 hours ago, nico1038 said:

 

Je crois que ce dont @180Vision parles c'est le rapport entre la valeur de réglage de l'offset et la valeur ADU du bias. Or cela n'a en général rien à voir:  la valeur de réglage de l'offset est une échelle arbitraire choisie par le constructeur et qui est ensuite convertie en valeur ADU (par le driver j'imagine?). Les deux valeurs sont donc directement liées (par une relation proportionnelle)  mais différentes.

 

Par exemple sur ma ASI2600MC une valeur d'offset réglée à 100 correspond à une valeur ADU (sur 16 bits) de 500.

et sur mon ASI533MC une valeur d'offset réglée à 70 correspond à une valeur ADU (sur 14 bits) de 700.

 

A priori Altair fait les choses plus simplement et la valeur de réglage = la valeur en ADU

Oui oui c'est ça !

 

Sur ma 183m, c'était 64xoffset par exemple après établissement des stats d'u' échantillon.

Et la, en effet, le coeff est 1, ce qui en effet est pratique, après avoir néanmoins fait des échantillons.

 

[LaurentG23]

Il y a 20 heures, lionthom a dit :

Perso, je fais les offsets dans la foulée des flats, ça prend 2 minutes et on est tranquille.

Bien résumé, c'est une habitude à prendre dès qu'on commence à faire de l'astrophoto. Je vais m'y coller !

 

[Tyler]

Il y a 20 heures, 180Vision a dit :

Et alors, chose incroyable, sur l'imx571 Altaïr (26M), la valeur mean du bias, est égale à la valeur d'offset de la caméra !!

c'est normal, tu es en 16 bits, pas de conversion.

avec 12, 14 bits, il faut convertir pour arrive à la valeur en 16 bits.

mon mean adu d'offset est à 720, mon "niveau" d'offset est à 45.

45 x 16 =720, où 16 c'est (2^16/2^Bits) > pour ma camera 12 bits >  (2^16/2^12)
pour une 16 bits, (2^16/2^Bits)=1

edit : je crois que c'est déjà expliqué au dessus

Modifié 31 août par Tyler

[180Vision]

1 hour ago, Tyler said:

c'est normal, tu es en 16 bits, pas de conversion.

avec 12, 14 bits, il faut convertir pour arrive à la valeur en 16 bits.

mon mean adu d'offset est à 720, mon "niveau" d'offset est à 45.

45 x 16 =720, où 16 c'est (2^16/2^Bits) > pour ma camera 12 bits >  (2^16/2^12)
pour une 16 bits, (2^16/2^Bits)=1

edit : je crois que c'est déjà expliqué au dessus

Bah oui, évidemment, pas illogique dans l'absolu...mais néanmoins, sur son ASI2600MC, Nico au dessus n'a pas l'équivalence et doit pourtant bien être en 16bits je suppose...?

 

Modifié 31 août par 180Vision

[Tyler]

il y a une heure, 180Vision a dit :

Nico au dessus n'a pas l'équivalence et doit pourtant bien être en 16bits je suppose...?

oui c'est étonnant, après peut être que l'échelle dans les softs n'est pas la même, je sais pas.

 

Il y a 18 heures, nico1038 a dit :

une valeur d'offset réglée à 100 correspond à une valeur ADU (sur 16 bits) de 500.

c'est bizarre ça non?
mais si je me réfère au calcul d'offset synthetique dans la doc Siril, avec un capteur 16bits c'est différent .

 

extrait de la doc :

"Plus précisément, nous recherchons une valeur de multiplicateur qui est un multiple de 4 pour cette caméra particulière, qui dispose d’un ADC (Analog Digital Convertor) 14 bits. De telle sorte qu’il y a au moins un facteur 4 entre la sortie du convertisseur et la profondeur de bit de mon fichier FITS (16b). De même, une caméra 12b devrait avoir un multiplicateur qui est un facteur de 16 , tandis que pour une caméra 16b, il n’y a aucun moyen de le savoir à l’avance. Par exemple, pour une ZWO 2600MC, le multiplicateur est de 10."


oh pis j'en sais rien, j'm'en fou, ça marche comme ça 😁

[nico1038]

il y a 33 minutes, Tyler a dit :

c'est bizarre ça non?
mais si je me réfère au calcul d'offset synthetique dans la doc Siril, avec un capteur 16bits c'est différent .

 

extrait de la doc :

"Plus précisément, nous recherchons une valeur de multiplicateur qui est un multiple de 4 pour cette caméra particulière, qui dispose d’un ADC (Analog Digital Convertor) 14 bits. De telle sorte qu’il y a au moins un facteur 4 entre la sortie du convertisseur et la profondeur de bit de mon fichier FITS (16b). De même, une caméra 12b devrait avoir un multiplicateur qui est un facteur de 16 , tandis que pour une caméra 16b, il n’y a aucun moyen de le savoir à l’avance. Par exemple, pour une ZWO 2600MC, le multiplicateur est de 10."


oh pis j'en sais rien, j'm'en fou, ça marche comme ça 😁

 

Comme je l'explique plus haut il n'y a pas forcément d'égalité entre la valeur de l'offset et la valeur de l'ADU. C'est complétement indépendant de la profondeur de l'image et dépend exclusivement du bon vouloir des fabriquants.

 

Par contre je me suis trompé au dessus, avec ma 2600 c'est un offset de 50 qui donne un ADU de 500 donc effectivement le coeff est bien de 10.

 

L'extrait que tu cites apporte apporte juste une  précision sur la valeur du coefficient calculé sur 16 bits. Avec une caméra avec un ADC de 14 bits le coefficients sera forcément un multiple de 4. Mais ça ne dit rien d'autre sur la valeur de ce coeff.

Par exemple avec mon ASI533MC un offset de 70 équivaut à un ADU de 700 (sur 14 bits) soit 700x4=2800 (sur 16bits) soit un coeff = 2800/70 = 40

Modifié 31 août par nico1038