Pour ceux qui ont la référence, j'ai constaté un problème issue de la rémanence du capteur sur le traitement du requin.
Avec de nombreux artefacts désagréables

ici:

Après analyse de la couche rouge, je m'aperçois que sur 44 Images, 24 images sont impactés par le RBI et 20 sont propres.
Ce qui ne laisse évidement pas assez d'information statistique pour que la rejection fonctionne.

J'ai donc attrapé le requin par les cornes et je me suis lancer dans le scripting pixinsight.

L' idée étant d'éliminer au mieux l'artefact avant de passer à l'étape d'intégration.
Voici, un petit zoom sur un des artefacts:

 Ligne du haut de gauche a droite

• Image d'intégration partielle de la couche rouge des 24 images impactées par le RBI
• Image d'intégration partielle de la couche rouche des 20 images sans RBI
• Image de support pour mon script obtenu pas soustraction des 2 images précédente.

Ensuite je passe mon petit script dont l'unique objectif est d'effectuer en boucle sur les images brute issue de la registration le  traitement suivant.

1. Linearisation de l'image de support au regard de la brute à traiter
2. Division de la brute par l'image de support (RBI_ONLY) via le classique pixelmath: $T*mean(RBI_ONLY)/RBI_ONLY
    

• Après traitement brutes, j'ai ré-intégré l'ensemble de la stack de 44 images. et j'obtiens l'image du bas.

Cela semble plein de promesses, donc je vais me coller au re-traitement des autres couches de cette LRGB.
PS: pour l'instant mon code n'est pas signé, je publierai le lien quand j'aurais fait le nécessaire avec juan.

 

ho bien joué !

c'est quoi ton capteur une ccd ?

si c'est le cas ce souci est bien connu :

nombre d'astram faisaient alors des flashages de la matrice entre chaque image (un mini dark)

Je suis stupéfait par les connaissances des membres de l'avex!

A ce que j'ai pu comprendre, c'est un rémanent de l'image précédente? Donc ce problème est périodique ?

+1 cet article doit absolument rejoindre la base de co avex

https://avex-asso.org/BookStack/public/shelves

la remanence de ce capteur est très bien connu.
Il s'agit du kodak KAF16803.

Voir ici pour le détail: https://www.gxccd.com/art?id=418&lang=409

Il existe plusieurs stratégie pour tenter de minimiser la problématique lors de l'acquisition en particulier l'IR PreFlash;
mais cela se fait au détriment du SNR, ce qui ne me conviens pas vraiment.

L'autre stratégie est d'intercaler une prise de dark (a jeter) entre le focus et l'acquisition de la cible...
Maxpilot dispose d'une option pour cela je crois, je ne suis pas certain de l'efficacité de cette méthode, (de toute façon nous pilotons avec voyager), car nous faisons un retour sur la cible après le focus, et il y a au moins une acquisition intermédiaire pour réaliser le platesolve lors du recentrage avant de repasser sur la capture de cible.

 

Le 13/09/2023 à 13:18, supaii a dit :

A ce que j'ai pu comprendre, c'est un rémanent de l'image précédente? Donc ce problème est périodique ?

@supaii Oui et non, en fait la rémanence est très présente après un focus, car on mitraille à répétition sur étoile de forte magnitude (surtout en ha) au même endroit sur le capteur. Donc, oui c'est l'acquisition de la cible immédiatement après le focus qui est impactée. On peux considérer que c'est périodique, mais c'est un choix externe qui détermine cette périodicité (l'évolution de la temperature lors de la nuit) ou la périodictié du changement de filtre 3 ou 6 images.

 

Sinon, je suis en train de réviser mon script...

La problématique c'est que le traitement étant pour l'instant effectué sur les images issues de la registration,
il est impossible de réaliser une intégration drizzle puisque les images de référence ne sont pas corrigées !

J'effectue donc les changements pour appliquer la division sur les images calibrées avant l'étape de registration, et il faut pour cela re-aligner l'image qui contient le RBI avec la frame d'acquisition avant de pouvoir faire une division correcte de l'artefact.
Cela permettra aussi de pouvoir reprendre le traitement via wbpp pour terminer l'assemblage final alors que cela n'était pas possible précédemment à cause de la gestion de cache de wbpp

stay tuned !

Modifié 16 septembre 20233 a par hoxca

Bon, j'y ai passer bien plus de temps que prévu pour trouver une solution viable.

Ce RBI étant présent sur l'ensemble des images réalisées avec le capteur KAF16803 j'ai fini par écrire un programme en GO pour faire la detection et le traitemeent de ces artefacts résiduels.
Pour ceux que cela intéresse le code est disponible ici:


https://github.com/hoxca/exorciser

L'idée est de traiter ces artefacts en batch après la phase de registration mais avant l'empilement statisitque.
Parce que je travaille avec pixinsight, les images sont au format xisf, il m'a donc été aussi nécessaire d'écrire une petite librairie en GO pour manipuler ces fichiers xisf. Le code de la librairie est ici : https://github.com/hoxca/xisf

Avec ce programme (exorciser) je peux caractériser le profil des artefacts a chercher dans l'image en indiquant 1 artefact pas ses coordonnées dans une image de référence.
Ensuite le programme est capable d'identifier l'ensemble des images impactés par le RBI dans le stack d'images, et d'établir la liste des images à corriger.
Et d'identifier l'ensemble des artefacts présent dans ces images. Pour constituer par la suite une liste des artefacts à traiter.
voici un exemple parlant à l'issue de l'étape de détection :


La dernière étape était de trouver un code d'inpainting capable de réparer ces artéfacts dans les images.
Pour cela, le réalise un empilement intermédiaire de 16 images sans artéfacts afin de fabriquer une base de référence.
Puis pour chaque image et chaque artefact identifié, on recalcule sont centroid (les images étant issue de la registration l'artéfact est mouvant avec le dithering);
pour enfin effectuer l'inpainting en conservant les moments statistiques de l'image à réparer.

Bon, il peux arriver que le programme soit en échec lors de la phase de recalcul parce que perturbé par un gros outlier 😅,
mais cela sera assez rare pour que la réjection s'en charge par la suite. Voici un exemple de cette erreur de recalcul:


Il s'est trompé a cause du satellite ☠️

Mais, ce qui est interessant, c'est que pour une fois on vois le traitement réalisé même si il n'est pas au bon endroit ! 😀
L'artefact à corriger était juste au dessus de la ou est réalisé l'inpainting.

Voila j'ai le code en place est j'ai enfin pu refaire le traitement de VDB149 !