tech Programme de pretraitement : alignement images(étoiles)

[Laphroaig]

Bonjour

 

Ayant commander une camera, je me suis lancé dans le développement en OpenCV (en C++) d'un programme me permettant de faire le pretraitement. [brute - Dark / Flat - offset)

Car je trouve que sur Iris ce n'est pas assez rapide et assez fastidieux.

 

4 dossier (Dark,Brute,Offset,Flat) + 1 template et tout le traitement se ferait tout seul

 

1ere etape:

Empilement des darks et moyenne des darks

 

2eme etape:

Empilement des offsets et moyenne des offsets

 

3ème etape:

Empilement des FLAT et moyenne des FLATs

 

4eme etape:

Soustraction du DARK moyenné aux Brutes (Brute - Dark)

 

5ème étape:

Normaliser (Brute - Dark / Flat -Offset)

 

6ème étape:

Empilement des brutes

 

Le gain de performance est très interessant par rapport a Iris pour cette partie du traitement.

Mais plus gourmand en RAM je pense.

Toute la pile d'image est chargé au debut. Je pense que iris charge a la volée.

Sur le traitement la Ram est optimisé en evitant de dupliquer des données.

Si les données sont gigantesques mon programme pourrait exploser peut etre ... (Tout depend de la Ram que l'on possede)

 

 

Il manque une etape l'alignement des images.

Je calcule l'alignement des le debut grace a un template ( Un morceau de l'image sur lequel on aura fait l'alignement)

Et je ferais l'alignement juste avant l'empilement final.

 

Mon calcul de l'alignement est basé sur des translations. Et je pense que des rotations seraient plus adequates.

Mais les rotations sont plus compliques à détecter.

 

Venons a ma question enfin ... que vous voyez venir

 

Sur une durée pas tres longue je pense que la translation suffira. Sur les tests que j'ai fait pas de soucis.

Un grand angle avec une série de brute s'étendant sur une longue durée je pense que j'aurais des soucis d'alignement

Qu'en pensez vous ?

 

En esperant avoir pas ete trop long et trop technique

Merci d'avance

 

PS : Je cours je viens de recevoir ma caméra.

J'espere que c'est pas truffe de faute. Désolé sinon.

[Claude39]

Pour détecter rapidement si tu as de la rotation ou pas dans une photo, tu peux effectuer un calcul de translation sur trois étoiles : l'une au milieu du champ, l'autre chacune sur un bord opposé de la photo.

 

Si tes valeurs de translations sont les mêmes, pas de rotation.

 

Si tu as de la rotation avec un centre sur la photo (rotation de l'imageur, de l'APN dans le porte oculaire), la translation sera nulle ou presque sur l'étoile du centre, positive sur une étoile et négative sur l'autre.

Si ton centre de rotation se trouve hors champ, tes valeurs de translations risquent d'être différentes et toutes positives ou négatives.

 

Mais si tout est bien fixé lors des prises de vues, il y a peu de chance d'avoir une grosse rotation, et la correction par translation devrait aller (a moins d'imager sur plusieurs soirs avec un montage / démontage de l'imageur : la il risque d'y avoir rotation).

 

En tout cas bon courage pour la programmation de tout cela !

[deufrai]

hello,

OpenCV sert vraiment à tout

 

Dans le cas de prises faites sur un simple trépied, je pense en effet que l'absence de détection de rotation va vite poser un problème.

 

Tes sources sont dispo qqpart ?

[dauphin-joyeux]

Iris procède différemment :

Empilement des darks avec soustraction de l'offset maître

Sur les images brutes, optimisation du noir avec soustraction séparée de l'offset et du dark.

Ta méthode simplifiée ne doit pas être aussi bonne, sinon pourquoi Iris se décarcasse ?

[Laphroaig]

Merci Claude pour les informations

 

hello,

OpenCV sert vraiment à tout

 

Dans le cas de prises faites sur un simple trépied, je pense en effet que l'absence de détection de rotation va vite poser un problème.

 

Tes sources sont dispo qqpart ?

 

Oui je pense mais elle vont servir a ma cam donc surtout du planetaire ... La translation devrait suffire

Les sources je peux te les passer. Mais je suis qu'a une version Beta, je fait aucun test robustesse

Mais la chaine de traitement existe sans l'alignement.

 

C'est une bibliotheque de traitement d'image que j'avais developper pour autre chose a une epoque.

 

Iris procède différemment :

Empilement des darks avec soustraction de l'offset maître

Sur les images brutes, optimisation du noir avec soustraction séparée de l'offset et du dark.

Ta méthode simplifiée ne doit pas être aussi bonne, sinon pourquoi Iris se décarcasse ?

 

Je comprend pas

Je n'ai pas simplifier la methode.

(Brute - dark / Flat - offset) ya pas d'autre formule si sans le offset

Le seul truc couteux dans cette operation c'est la division

 

Chaque image brute est traite individuellement pour etre empile uniquement a la fin

 

Iris est aussi un visualiseur d'image ce qui change tout dans la logique.

Je sais pas comment il est fait apres ... avec OpenCV ou pas

 

Je pense que c'est plus lent parcequ'il charge a la volée.

 

Mon avantage c'est que c'est un programme qui alloue le plus gros avant l'execution de la chaine

Travailler en RAM sera toujour plus rapide que passer par le disque dur c'est tout !

 

Sur iris tu fait etape par etape et tu stocke les resultat temporaires sur ton disque.

Ca change tout.

 

COmme logiciel de traitement d'image bas niveau, tres bien fait il y a "ImageJ" fait en java

 

Rémi

[dauphin-joyeux]

 

Je comprend pas

Je n'ai pas simplifier la methode.

(Brute - dark / Flat - offset) ya pas d'autre formule si sans le offset

 

Moi non plus, je ne comprends pas tout, mais ce qui est sûr, c'est qu'Iris soustrait l'offset au dark. J'avais posé la question à Christiand il y a bien longtemps, et sa réponse était que c'est fait pour l'optimisation du noir : pour plus de précision, lui demander.....

Ton dark contenant l'offset, tu simplifies au détriment de l'optimisation du noir. C'est tout ce que j'ai compris.

[Laphroaig]

Moi non plus, je ne comprends pas tout, mais ce qui est sûr, c'est qu'Iris soustrait l'offset au dark. J'avais posé la question à Christiand il y a bien longtemps, et sa réponse était que c'est fait pour l'optimisation du noir : pour plus de précision, lui demander.....

Ton dark contenant l'offset, tu simplifies au détriment de l'optimisation du noir. C'est tout ce que j'ai compris.

 

 

Je viens de comprendre la precision

Ca sera pas plus couteux en temps de calcul une soustraction deplace

 

Je vais revenir pour l'explication mathematique et physique si j'ai bien compris

[Laphroaig]

Recap des differentes images

 

Offset : Defaut electronique, tres court temps de pose dans l'obscurite

 

Dark : Signal thermique,

temps de pose identique à l'image de brute dans l'obscurite pour connaitre son signal thermique

Le Dark contient l'offset

 

Flat : Vignettage, sensibilité differentes des pixel

temps de pose assez court sur une surface blanche uniforme

LE Flat contient l'offset et un peu de bruit thermique

 

Image Brute = Image utile + Signal Thermique + Defaut electronique

 

Donc Image Brute - Dark = Image Utile

Normaliser grace aux (Flat - offset)

FORMULE = (BRUTE - DARK) / (FLAT - OFFSET)

 

La formule dans Iris si j'ai bien compris

Si on enleve loffset du dark il reste uniquement le bruit thermique

Image Brute - (Dark - offset) = Image Utile + offset

Du coup je suppose qu'il normalisera avec le Flat contenant l'offset

FORMULE = (BRUTE - DARK -OFFSET) / FLAT

 

Peut etre qu il enleve encore l'offset du flat je sais pas apres

Si la deuxieme formule est plus interessante je suis preneur

 

En tout cas sur la chaine de calcul la deuxieme formule (meme en enlevant l'offset du flat) ca allourdit pas

Donc si vous avez des precisions sur ces formules je suis preneur

 

Apres pour moi l'axe d'amelioration possible serait de prendre des darks du Flat : Dark du meme temps de pose que le Flat

Pour effacer le peu de bruit thermique present dans le flat (peut etre est il negligeable)

Plus besoin de offset du coup

FORMULE : Image Brute - DarkBrute / Flat - DarkFlat

 

Rémi

Modifié 5 octobre 2016 par Laphroaig

[Eric S]

Je vais aller dans le sens de Dauphin-joyeux, il faut comprendre la physique sous-jacente pour comprendre les étapes. Le signal thermique est très sensible à la température alors si ton capteur n'est pas thermorégulé, il faut prévoir une méthode de rattrapage. C'est l'optimisation du signal thermique. Et dark = signal thermique + l'offset.

 

Donc:

* étape 1 : calcul de l'offset maître par moyenne des offsets

* étape 2 :

- soustraction de l'offset aux darks

- normalisation des darks entre eux

- calcul du dark maître en réalisant la médiane des darks normalisés (médiane plutôt que moyenne arithmétique pour minimiser le bruit)

* étape 3 :

- soustraction de l'offset aux flats

- normalisation des flats entre eux

- calcul du flat maître en réalisant la médiane des flats normalisés (la moyenne arithmétique est aussi possible)

* étape 4:

- soustraction de l'offset maître aux Brutes

- calcul du coefficient multiplicateur à appliquer au dark maître pour optimiser la soustraction du signal thermique à chaque brute. Le coefficient est optimale lorsque le bruit restant est le plus faible (mesure du bruit direct ou par réduction d'entropie)

- pour à chaque brute, soustraction du dark maître avec le coefficient multiplicateur associé à la brute

* étape 5: Normaliser : brute précédente/ Flat maître

* étape 6 : dématricer si matrice

* étape 7 : aligner

* étape 8 : faire la moyenne des brutes (nombreuses méthodes au choix pour limiter le bruit)

[Eric S]

Laphroaig,

 

On a rédigé nos derniers messages en parallèle.

 

Pour le flat, s'il est vraiment court (je les fais au flash), le signal thermique est négligeable.

[Laphroaig]

Ok je vois

 

J'ai loupe la mediane a la place de la moyenne qui sera plus couteux mais ca va

J'ai des corrections a apporter je vais avoir le temps il fait mauvais

 

Par contre le coeff multiplicateur avec la normalisation des darks va falloir me l'expliquer car j'ai pas tout compris

[Fred_76]

Bonjour

 

L'alignement des images est bien plus complexe qu'une simple translation+rotation. La translation+rotation n'est valable que pour les très longues focales, pour des objets proches du zenith et des optiques exemptes de déformation.

 

C'est rarement le cas. On se retrouve dans la majorité des cas avec des images non superposables, même avec une translation + rotation. Il faut aussi redresser les images. Pour cela trois méthodes :

 

A ) Tu prends une image de référence (Iris prend la première) et tu alignes toutes les images sur cette référence. Problème, quand il y a trop de rotation de champ, au bout d'un moment il n'y a plus assez d'étoiles en commun et le process plante.

 

B ) Tu calcules les paramètres entre chaque image successive (temporellement) et ensuite l'empilement se fait de proche en proche. C'est comme ça que fait DSS. Quand il y a beaucoup de rotation de champ, on est certain d'avoir toujours un empilement.

 

C ) Un passage en astrométrie te permet de recaler les images sur un catalogue d'étoiles. On est ainsi certain d'avoir des images parfaitement superposables d'une séance à l'autre, même prises avec des équipements différents ou personnes différentes.

 

Pour la logique de détection des étoiles et de calcul les déformations à appliquer... il faut chercher les algos sur le net. Ca doit se trouver car Christian Buil, Juan Conejero & co. y sont bien arrivés !

 

PS : tu habites Toulouse, comme Ch. Buil me semble-t-il. Et si tu prenais contact avec lui pour optimiser Iris et le porter sur les systèmes multicoeurs, ou éventuellement modifier son interface ?

Modifié 6 octobre 2016 par Fred_76

[Laphroaig]

Ok je vois le probleme pour l'alignement

 

Je perfectionnerai ca avec le temps

Pour le moment avec ma cam(1280 * 960) et ma focale de 1000mm, je pense que la translation suffira Par contre pour le grand champ pas la peine

 

Par contre j'ai plein d'autre boulot.

 

Normaliser FLAT entre eux

Se repencher sur le DarkMaster

 

Lire les image raw dans le .fit, je galere un peu d'ailleurs

 

Optimiser Iris oula la je sais pas

Iris est un tres bon logiciel de traitement d'images astronomie avec un visualiseur et beaucoup d'outils permettant de corriger des artefacts

Pas le plus performant, mais assez fiable et tres exhaustif.

Son choix a ete de faire du "pas à pas" pour etre plus rigoureux.

 

Moi c'est uniquement un programme qui prend en

ENTREE: brutes, flats, offsets, darks

SORTIE: Image finale

Ma chaine de traitement est statique. Le resultat intermediaire n'est pas stockée. Donc l'interpretation du resultat intermediaire par l'operateur ne peut avoir lieu.

 

Le seul avantage de mon programme par rapport a Iris ne peut etre que la performance avec le defaut de ne pas pouvoir interagir pendant l'execution de la chaine.

 

Ayant des competences en traitement d'image moi j'utilise d'autres logiciels avec des operateurs primaires.

[Eric S]

Par contre le coeff multiplicateur avec la normalisation des darks va falloir me l'expliquer car j'ai pas tout compris

 

Chaque pixel a son propre signal thermique.

 

Le signal thermique est fonction de la température. C'est la même fonction de température qui s'applique à tous les pixels. Typiquement, le signal double tous les 4 à 5°C suivant les capteurs (CMOS). Si le signal thermique double sur un pixel donné, il doit aussi doubler sur tous les autres pixels du capteur.

 

Thermique(x,y,T) = Thermique(x,y,Tref) * 2 ^ ((T-Tref)/DeltaTDouble)

 

Thermique(x,y,T) : signal thermique du pixel (x,y) à la température T

Thermique(x,y,Tref) : signal thermique du pixel (x,y) à la température de référence Tref

DeltaTDouble : écart de température nécessaire au doublement du signal thermique

 

DeltaTDouble est un coefficient unique à tout le capteur.

 

Si on considère un autre pixel (x',y') alors :

 

Thermique(x',y',T) = Thermique(x',y',Tref) * 2 ^ ((T-Tref)/DeltaTDouble)

 

Thermique(x',y',T)/Thermique(x,y,T) = Thermique(x',y',Tref) / Thermique(x,y,Tref)

 

Les rapports des signaux thermiques entre pixels restent proportionnels quand on change la température.

 

En pratique, tu ne connais pas Tref ni T mais en exploitant la proportionnalité, tu peux t'en sortir.

 

Par exemple, pour ta série de darks (après soustraction de l'offset), tu constates qu'ils n'ont pas tous le même niveau moyen (moyenne sur l'ensemble du capteur). C'est normal parce qu'ils n'ont pas été pris exactement à la même température. Tu multiplies chacun des darks par un coefficient correcteur pour qu'ils se retrouvent à la même moyenne (une normalisation). Ensuite, tu appliques la médiane sur la série de darks corrigés.

 

Pour les images réelles, non seulement tu ne connais pas la température du capteur mais en plus le signal thermique est superposé au signal photonique. Tu essaies plusieurs coefficients multiplicateurs au dark maître jusqu'à ce que tu ais minimisé le bruit spatial sur ton image après soustraction du dark maître modifié, c'est-à-dire que tu as bien soustrait le signal thermique propre à ton image, ni trop, ni trop peu. L'idée sous-jacente, c'est que le signal thermique présente un fort bruit spatial, chaque pixel étant totalement indépendant du voisin du point de vue du signal thermique. Inversement le signal photonique est beaucoup moins bruité car il ne varie pas du tout au tout entre chaque pixel. Et sur l'idée de mesurer quantitativement le bruit d'une image, on prend sa mesure d'entropie. On fait une transformée de Fourier et on regarde les densités d'énergie dans l'espace réciproque, surtout aux hautes fréquences.

 

PS1 : dans les étapes de traitement, avant ou pendant le dématriçage, j'ai oublié la gestion des pixels chauds.

 

PS2 : en fait, ça m'intéresserait un programme qui puisse effectuer rapidement le pré-traitement d'une image éventuellement en s'arrêtant avant le dématriçage. On peut imaginer que les offset, dark et flat maîtres sont calculés à l'avance. Ça serait pour utiliser depuis mes logiciels avant de faire des calculs astrométriques à la volée.

 

PS3 : si tu fais du planétaire, tu fais des poses courtes? (<<1 s) Le signal thermique est souvent négligeable dans ces cas (comme pour les flats faits au flash par exemple).

[Fred_76]

Oh non, la loi du courant d'obscurité n'est pas aussi simple que ça ! Chaque photosite a sa propre loi, ça dépend des impuretés contenues dans le silicium et aucun photosite n'est constitué de la même façon. Certains auront un comportement "raisonnable" en 2^(T/5) mais d'autres seront bien plus déviants dans un sens ou l'autre.

 

Ensuite les photosites auront en général un comportement linéaire en fonction de l'illumination. On parle de rendement quantique. Quand des photons arrivent, ils génèrent un nombre d'électrons proportionnel au nombre de photons. Mais certains photosites dévient fortement : il y a les froids qui ne retournent pas d'électron, les morts (chauds) qui saturent tout de suite même quand aucun photon n'arrive (le courant d'obscurité suffit à les saturer), mais il en existe aussi entre les deux. C'est pourquoi retirer les pixels chauds avec seulement les darks ne suffit pas : il en reste.

 

Bref, on ne peut pas globaliser le traitement sur l'ensemble de l'image. Il faut traiter chaque photosite indépendamment des autres. C'est ce que font tous les logiciels de traitement d'image.

[benjamindenantes]

Recoder un programme plus simple que d'utiliser iris...

 

Faut pas déconner quand même. A part si ça te fait plaisir de passer du temps là dessus, je ne vois pas l'intérêt.

 

Deux alternatives gratuites:

 

Utiliser les scripts sous iris! Tu tapes "script iris tifloastro" et tu trouvera le script qu'il te faut. Il fait exactement ce que tu demandes:

 

ENTREE: brutes, flats, offsets, darks

SORTIE: Image finale

 

En plus tu as les fichiers intermédiaire que tu finiras pas trouver intéressant quand tu iras plus loin dans tes traitements.

 

Seul inconvénient, c'est un peu lent iris ne fonctionnant que sur un cœur de processeur.

 

Autre alternative: DSS

 

Aux premiers abords, il fait "juste"

ENTREE: brutes, flats, offsets, darks

SORTIE: Image finale

 

Mais en réalité on a la main sur pas mal de paramètres et là encore c'est souvent très pratique.

 

Bref, tu as deux alternatives qui font du "simple" en embarquant des méthodes pas si simples. Comme expliqué plus haut, une addition n'est pas une simple rotation/translation...

 

Bref, y a plus simple que de recoder un truc qui fera moins bien le boulot que ce qui existe déjà.

[Laphroaig]

Merci beaucoup de vos reponses Eric et fred

 

Je vois bien que le Dark Master est pas si simple.

Pour l'alignement pour le moment j'ai laisse tombé.

 

J'ai galerer aujourd'hui a extraire la matrice dans les .fits pourtant pas si compliqué

Et encore j'ai fait que les 8 bits

 

 

PS2 : en fait, ça m'intéresserait un programme qui puisse effectuer rapidement le pré-traitement d'une image éventuellement en s'arrêtant avant le dématriçage. On peut imaginer que les offset, dark et flat maîtres sont calculés à l'avance. Ça serait pour utiliser depuis mes logiciels avant de faire des calculs astrométriques à la volée.

 

Oui c'est le but ultime ca.

Mais j y suis pas encore.

 

Pour le moment je veux faire la chaine (sans alignement et empilement final) avec les données Raws.

Sans trop m'occuper des problematiques du Darks

 

Ensuite je repasserai aux Dark surtout ...

Mais le cote median, FFT ca fait exploser le calcul, ca c'est sur

 

 

Recoder un programme plus simple que d'utiliser iris...

 

Faut pas déconner quand même. A part si ça te fait plaisir de passer du temps là dessus, je ne vois pas l'intérêt.

 

....

 

Par contre Benjamin ton intervention n'est pas tres sympa et pas tres constructive.

Si tu veux tu peux passer ton chemin ...

 

Mais je vais quand meme te repondre

Etant au chomage, et developpeur informatique avec des competence en traitement d'image et ayant recu une cam ... le chemin etait tout tracé ...

Le but n'est pas de remplacer iris, je n'ai pas cette pretention ....

 

Mais comme Eric a compris si une partie du pretraitement peut etre plus rapide ca peut etre sympa

Je pense que le pretraitement Dark Offset Flat et Brute est faisable...

 

wait and see

Rémi

[benjamindenantes]

 

Par contre Benjamin ton intervention n'est pas tres sympa et pas tres constructive.

Si tu veux tu peux passer ton chemin ...

 

Mais je vais quand meme te repondre

Etant au chomage, et developpeur informatique avec des competence en traitement d'image et ayant recu une cam ... le chemin etait tout tracé ...

Le but n'est pas de remplacer iris, je n'ai pas cette pretention ....

 

Mais comme Eric a compris si une partie du pretraitement peut etre plus rapide ca peut etre sympa

Je pense que le pretraitement Dark Offset Flat et Brute est faisable...

 

wait and see

Rémi

 

Dommage de ne réagir qu'a la première partie de mon message... Et pourtant j'avais raison, tu le fais car ça te fais plaisir!

En revanche, la deuxième partie était pourtant très constructive avec deux vraies solutions simples et toute prête... L'utilisation des scripts rend iris d'une simplicité enfantine. Du coup, recoder un truc n'a que peu d'intérêt (a part pour se faire plaisir)

 

Comme quoi ma première partie de message n'était pas si idiote...

[Eric S]

Oh non, la loi du courant d'obscurité n'est pas aussi simple que ça ! Chaque photosite a sa propre loi [...]

 

Oui, j'ai dit: Chaque pixel a son propre signal thermique.

 

Certains auront un comportement "raisonnable" en 2^(T/5) mais d'autres seront bien plus déviants dans un sens ou l'autre.

 

Dans le process d'Iris, seuls les pixels chauds sont traités à part. Les autres, y compris les froids, sont traités dans le pot commun. Dans le pot commun, tous les pixels sont supposés avoir le même type de comportement pour le signal thermique. C'est le prérequis de toutes les méthodes d'optimisation des darks et pas seulement pour Iris. S'il reste des pixels aberrants, ils seront éliminés avec les méthodes d'empilement style sigma-clipping.

 

Quant à utiliser Iris depuis un autre logiciel, on ne peut pas l'appeler en ligne de commande.

 

Je ne connais pas DSS mais la documentation indique qu'on peut l'utiliser en ligne de commande. Néanmoins, les options paraissent limitées pour un contrôle fin (ou si je comprends bien, il faut aller définir les options dans la version graphique de DSS).

 

Si je devais repartir d'un logiciel existant, j'irais plutôt chercher dans le code source de Siril .

[Laphroaig]

Bon pour ce que ca interesse

Voila l'idée pour le gain de performance

 

 

-------------------------ATTENTION CODE-------------------------------

/// Calcul Alignement

AlignementOperator *align = new AlignementOperator(pileImagesBrute,new AlignementParameters(new DataPile<OPENCV_IMAGE>(templateMat)));

 

/// dark Master

EmpilementOperator *darkMaster = new EmpilementOperator(pileImagesDark);

 

/// Offset Master

EmpilementOperator *offsetMaster= new EmpilementOperator(pileImagesOffset);

 

/// Flat Master

EmpilementOperator *flatMaster = new EmpilementOperator(pileImagesFlat);

 

/// brute - darkMaster : ecrasement pileImageBrute

SupprOperator *preTreat1= new SupprOperator(pileImagesBrute,new SupprParameters(darkMaster->getOutput()));

 

/// flatMaster - offsetMaster : ecrasement flatMaster

SupprOperator *preTreat2 = new SupprOperator(flatMaster->getOutput(),new SupprParameters(offsetMaster->getOutput()));

 

/// brute - darkMaster / flatMaster - offsetMaster : ecrasement pileImageBrute

NormaliseOperator *preTreat3 = new NormaliseOperator (preTreat1->getOutput(),new NormaliseOperator (preTreat2->getOutput()));

 

/// Recalage effectif : ecrasement pileImageBrute

RecalageOperator *recalage = new RecalageOperator(align->getOutput(),new RecalageParameters(pileImagesBrute));

 

/// empilement

EmpilementOperator *empilement = new EmpilementOperator(recalage->getOutput());

empilement->addListenerShow(); //visualisation resultat

empilement->addListenerWrite(); // ecriture resultat

 

/// Kmeans

//SplitRegionChain *splitRegion=new SplitRegionChain(empilement->getOutput(),9);

 

/// Construction Chaine

ChainAndromede<OPENCV_IMAGE,OPENCV_IMAGE> *chain = new ChainAndromede<OPENCV_IMAGE,OPENCV_IMAGE>(pileImagesBrute,new Parameters());

chain->addOperatorAndromede(align);

chain->addOperatorAndromede(darkMaster);

chain->addOperatorAndromede(offsetMaster);

chain->addOperatorAndromede(flatMaster);

chain->addOperatorAndromede(preTreat1);

chain->addOperatorAndromede(preTreat2);

chain->addOperatorAndromede(preTreat3);

chain->addOperatorAndromede(recalage);

chain->addOperatorAndromede(empilement);

 

// EXECUTION DE TOUTE LA CHAINE

chain->exec();

 

--------------------------------------------------

 

Allocation en RAM de toutes les images brutes, flat, offset et dark

Ca peut faire mal au PC

 

Si probleme

 

On Pourrait optimiser pour faire pas a pas ... ca serait plus intelligent d'ailleurs

Chargement Darks => calcul Dark Master => Vidange des Darks : on conserve que le dark Master

et ainsi de suite ...

Par contre toutes les brutes devront etre en RAM

 

Voila en esperant pas pollué

 

J'ai pu faire des test sur la lune pour la methode d'alignement uniquement en translation

 

Ca fonctionne tres bien avec ma focale et ma camera, sur une duree assez courte

En plus j'ai pas de suivi. Donc pour le moment je vais m'en contenter.

 

 

Rémi

Modifié 7 octobre 2016 par Laphroaig

[Eric S]

Oui, il faut séparer les différentes parties qu'on ne calcule pas nécessairement à la même fréquence. Histoire d'optimiser l'utilisation du processeur et de la mémoire. Si pour une seule image, il faut refaire le calcul de toute la séquence . Je voudrais traiter mes images une par une à la volée sur une tablette windows x86 avec un processeur Atom Z3740D (quad-core à 1,3 Ghz) .

 

 

--------------

Offset master: ne dépend que de la sensibilité (qu'on ne change pas habituellement pour un capteur donné).

--------------

Dark master : dépend de la sensibilité, de la température et de la durée. A besoin de l'offset master pour le calcul.

--------------

Flat master : dépend de la sensibilité (pas trop) et de l'optique. A besoin de l'offset master pour le calcul.

--------------

Prétraitement à proprement parler.

Alignement.

Empilement.

--------------

[Laphroaig]

Si flat, dark offsset master sont deja calculé

Traiter a la volée image par image avec visualisation comme un film ça devrait être faisable (tout dépend de la taille de la matrice bien sur et du rafraichissement)

 

Le probleme c'est que c'est du C/C++ donc il faut le recompiler sur ta machine

Autant mon code que la lib openCV

Chez moi tout est compiler en 64bits.

 

Donc deja il faudra installer compilateur C/C++ et compiler OpenCV.

Je peux t'aider

Pour faire des setups j'ai pas les outils pour ...

 

Mon code sera beaucoup moins complique à compiler

 

C'est vraiment le bordel tout ces formats raw ...

Fit, cr2, dng, ...

 

Pas beaucoup de soft lise bien le fit

 

Et je n'arrive pas a decoder ces satanée FIT 16 bits contrairement aux 8 bits

Je comprend pas la matrice de données

 

Si qqu un un a une idée ...

Modifié 11 octobre 2016 par Laphroaig

[Fred_76]

Il faut respecter la syntaxe... c'est comme l'orthographe !

 

Le lien de référence : http://fits.gsfc.nasa.gov/

[Laphroaig]

Désolé pour l'orhographe ...

 

J'ai déjà regardé les spécifications sur le site je lis très bien l'entête

 

Mais j'ai un problème au chargement des data 16 bits

Le fait que les données soient signées m’embête je pense

[Fred_76]

Il y a des librairies toutes faites :

 

http://fits.gsfc.nasa.gov/fits_libraries.html

[Laphroaig]

Pour les compiler sous windows c'est le bordel

Je vais mettre peut être plus de temps a compilé cette satanée librairie qu a coder le décodeur

 

Surtout que c'est pas si complique a lire les .fits

mais je doit avoir un cast qui me met dedans ... les 16bits sont signées dans les fits.

 

Je vais me replonger dessus aujourd'hui

Peut etre que ma donnée est corrompu

 

Une question normaliser les flats entres eux ...

 

Cela consite a prendre le minimum et maximum global des flats

Et étaler tous les flats sur la dynamique [minGlobal - maxGlobal] ?

 

Rémi

[Laphroaig]

C est réglé j'inversais les octets.

 

Je peux lire des fits sur 16bits qui contiennent des informations uniquement sur 12 bits

[Fred_76]

Ta façon de normaliser les flats ne fonctionnera pas. Le max sera un point chaud, le min un point mort !

 

La méthode utilisée par Iris est de calculer l'intensité médiane de chaque image de flat (prétraitée après retrait de l'offset et du dark maître) et de normaliser chaque image à un niveau commun (par exemple 1000). Une fois cette opération faite, le flat maître est obtenu en prenant pour chaque pixel la médiane des pixels correspondants des images individuelles. Si tu calcules ton flat maître en réel et non en nombre entier, tu peux normaliser à 1.

[Laphroaig]

Merci beaucoup Fred pour l'aide

 

Ok

J'étale sur la dynamique commune entre 0 et 1 c'est tres bien d'ailleurs

Et après faut que je code intelligemment cette médiane qui va être couteuse.

D'ou pourquoi on dit de prendre toujours un nombre impair d'image.

 

Pour le offset Master : faut il normaliser aussi de la même façon ?

Meme question pour le Dark Master ?

 

Je suppose que pour le Dark Master ca sera forcement plus compliqué

 

Je me met sur cette fameuse mediane.

 

Faire un "sort" sur chaque pixel ca va faire mal.

Je vais faire un rangement par dichotomie je pense que ça sera mieux ...

 

Merci encore pour tes réponses Fred

 

PS:

Je devrais peut être renommer le sujet, mais je sais pas si c'est possible.

[Eric S]

Quand on parle de normaliser, dans le cas présent, on parle de remettre le niveau moyen de chacune des images au même niveau commun. On fait ça quand les signaux correspondants ont des variations d'une image sur l'autre. On ne parle pas de la dynamique de l'image (façon contraste auto sur une photo de jour).

 

Pour l'offset, le signal d'offset est très stable d'une image sur l'autre, pas besoin de normaliser.

 

Pour le dark, le signal thermique varie significativement d'une image sur l'autre à cause des variations de température. On normalise (et on sélectionne les darks avec des températures proches des photos à pré-traiter).

 

Pour le flat, on a souvent des petites variations qu'on ne peut pas négliger. Normalisation.

 

Ne pas hésiter à lire la doc d'Iris qui explique le principe des différentes étapes de prétraitement.

 

Sur l'addition des images prétraitées, il est écrit:

Astuce: parfois, dans le cas du compositage d'images du ciel profond, il apparaît que le niveau du fond de ciel n'est pas le même entre les images de la séquence. Ceci perturbe les fonctions qui utilisent les statistiques pour rejeter les intensités aberrantes. Avant de faire un compositage médian ou du type sigma-clipping par exemple il est fortement recommandé d'amener le fond de ciel au même niveau pour toutes les images de la séquence.

 

Sur le calcul de la médiane, comme elle est calculée pixel par pixel, on pourrait se contenter de charger en mémoire un seul pixel de chaque image à la fois. Je pense aussi qu'il existe un algorithme itératif permettant de ne charger qu'une image à la fois (ou peut-être deux pour conserver l'histoire de nombre impair).

 

Ça peut effectivement être judicieux de travailler avec des nombres à virgule flottante même simple précision plutôt que des entiers 16 bits, 32 bits, 64 bits... compte tenu de la grande dynamique des images mais des rapports signal sur bruit limités.