Jupiter en HR

[brizhell 2433]

Et encore, on a pas parlé de physique de la turbulence, traitement du signal, théorie de l'information.....

Ni de ce que l'on peut conclure dans le détail du reverse engineering sur le code de turbu (ça nous a bien fait rigoler moi et 2 collègues)...

[jldauvergne 12666]

Il y a 8 heures, loulou13 a dit :

prend les 20% des meilleures scores par AP, mais doc potentiellement dans l'ensemble des images ? (donc plus que les x % évaluées comme globalement meilleures lors de la phase d'analyse ?).

Tu as le choix d une sélection locale ou globale. Don oui tu as l'option de faire ce quz tu dis.

Edited March 12 by jldauvergne

[polo0258 34075]

Message par ms55 » 27 sept. 2022, 19:33

Callisto avec quelques détails et surtout sans le point noir central qui dégrade les images que l'on voit circuler sur les forums astro.;

 

 

et ici il nous sort un magnifique Callisto   digne d'un 400 ......

 polo

 

[jldauvergne 12666]

Un couo un satellite bien plus flou que la planète et là l'inverse

[CPI-Z 1039]

Vu le nombre d'intervenant, cela devient trop lourd pour moi.

@jldauvergnetu sais bien que mes softs utilisés sont principalement IRIS, AS3, Astrosurface et ImageJ (parce qu'il a beaucoup de plugins)

Hors "histoire" MS, tu percutes bien que je sais ce qu'est une bonne image, que je n'utilise pas des PhotoShop and Co et que je reconnais certains style d'images comme les tiennes, on aime ou on n'aime pas c'est pas là la question.

Je sais aussi reconnaître si dans une image il y a du signal, du bruit, des artefacts, et qu'une amélioration consiste à faire ressortir le signal avec le moins de bruit et d'artefacts possible.

J'ai fait quelques bonnes images, donc je sais ce que mon vieux matos peut produire, mais j'ai aussi quelques vielles vidéos un peu plus turbulentes où AS3 de donne rien de bon par rapport aux bonnes séries.

AS3 est donc limité en correction de la turbulence, ce qui s'explique certainement à plusieurs niveaux.

Ce type de Luchy-imaging dans un premier temps trie l'ensemble des images selon un critère de qualité, les images retenues selon un pourcentage défini par l'utilisateur.

AS3 les découpe en damier, les damiers d'une position donnée sont empilés, encore avec un tri indépendant du précédent, et tout en les translatant latéralement (tilt local), c'est sa méthode de correction de la turbulence.

Je suppose qu'il y a addition ou moyenne pour l'empilement des damiers et que les tilts locaux sont calculés à partir d'une image de référence, d'abord sur un empilement plus classique, puis en double stack sur le résultat de la première boucle.

Donc, on a le pourcentage des retenues de départ (par exemple 30%). Pour la sélection au niveau des damiers, il utilise peut être le même ratio, soit encore 30%, donc il reste que 9% au total des images d'origine utilisées dans la fusion. Le RSB est nécessairement faible.

 

Coté PNG de (...), je ne le nomme pas ici car ce n'est pas le sujet, je ne sais absolument pas comment elles sont construites, j'ignore totalement qu'elle est sa méthode d'empilement

Moi je constate que tout le signal de sa finale est bien là.

Sans IA ou autres,  je n'ai utilisé que de la déconvolution, filtre bruit et dé-rotation, pour qu'il n'y est aucune ambiguïté.

Tu peux les décomposer les 3 couches couleur, c'est moche mais l'info est bien là. Tu peux aussi décomposer celle de Simon pour une comparaison.

 

Je sais pertinemment qu'un C11 ne peut pas faire mieux qu'un C14, et tu sais que quand trouve une erreur coté optique j'en parle.

Ne peut-on pas imaginer l'inverse, que se soit les C14 qui auront été limité par une mauvaise correction de la turbulence ? Pour moi les trop grandes différences entre Simon et Peach en attestent.

 

Juste pour info et sans vouloir ajouter quoi que ce soit dans l'affaire, je ne savais pas que l'on pouvait créer un défaut de collimation artificiellement. Mais c'est hors sujet ici.

Il y a 16 heures, jldauvergne a dit :

Au lieu de radoter avec ce jeu d'images brutes très moyennes, prise encore une fois avec un télescope mal collimaté. 

 

Alors existe-t-il d'autres méthodes plus efficaces ? c'est possible ou pas possible ?

Je vous avais communiqué quelques liens trouvés sur internet, mais sans retour jusqu'à présent

Le 08/03/2023 à 02:43, CPI-Z a dit :

Alors vers quoi se retourner, existe-t-il autre chose ?

http://alumni.soe.ucsc.edu/~xzhu/doc/turbulence.html#ref

https://github.com/mnhrdt/ipol_centroid/tree/master/src

https://github.com/pui-nantheera/atmospheric-turbulence-removal/find/master

https://www.mdpi.com/2072-4292/14/19/4797/htm

https://github.com/vita-group/turbnet

https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/ipr2.12559

https://xg416.github.io/TMT/

https://github.com/arielweizman1/AtmosphericTurbulenceRemovalUsingML

https://par.nsf.gov/servlets/purl/10226148

https://ecommons.udayton.edu/cgi/viewcontent.cgi?article=1422&context=ece_fac_pub

https://github.com/Nianyi-Li/unsupervised-NDIR

.

.

 

De mon coté j'imagine qu'il y aurait au moins deux principes (sans tenir compte des lois de l'optique), l'un par grilles, je pense qu'AS3 en fait parti, et l'autre par nœuds

 

par grille

https://github.com/Nianyi-Li/unsupervised-NDIR

pour moi c'est trop compliqué à 'installer pour pouvoir tester.

 

Exemple par nœuds

 

test "Local blur" (troisième case) 200 images 90000 nœuds

 

les 8 premières sur les 200 pour une visu

https://demo.ipol.im/demo/105/

 

Peut-être corriger localement par translation les images dans un premier temps apporterait une amélioration, ou plus si l'on peut corriger aussi le flou, puis seulement après les empilées avec AS3.

 

 

Pour test en conservant 100% des images

        

building.zip

REG.zip

 

Je ne peux pas être contre le lucky-imaging puisque c'est notre seul outils actuel à notre disposition, mais le RSB a tout autant son importance en astro-image.

Encore une affaire de compromis.

 

Pour la "bouillie" dans laquelle le signal serait inévitablement perdu, évoquée plusieurs fois dans ce post par des cadors, le trop grand nombre d'images retenues tue le signal,

On peut tout de même opposer la loi des statistiques dont le cumul  des dé-rotations.

 

Exemple pas très comparable de par des méthodes différentes, mais tout de même j'en parle, c'est celui de la mesure d'étoile double.

Dans la mesure d'étoiles doubles, plus il y a d'images, plus la mesures est bonne (courbe asymptotique).

 

Encore une fois, concernant les PNG, je ne peux rien dire de plus de ce que j'ai déjà dis. Mais pour moi j'imagine que des améliorations sont possibles.

 

CPI-Z

 

 

 

Edited March 12 by CPI-Z

[jldauvergne 12666]

il y a 26 minutes, CPI-Z a dit :

C14 qui auront été limité par une mauvaise correction de la turbulence ? Pour moi les trop grandes différences entre Simon et Peach en attestent

Tu bloques Je ne là dessus, ca atteste juste que le bruit est filtré trop fort chez Peach. Il est comme tout le monde il dose plus ou moins bien

 

il y a 28 minutes, CPI-Z a dit :

je ne savais pas que l'on pouvait créer un défaut de collimation artificiellement. Mais c'est hors sujet ici.

.

Je ne sais pas ce que tu essayes de dire. Un défaut d'alignement est forcément artificiel et un bon alignement aussi.

 

il y a 30 minutes, CPI-Z a dit :

Alors existe-t-il d'autres méthodes plus efficaces ? c'est possible ou pas possible

C'est un autre débat,  je ne sais pas la réponse.  Je suppose que oui. On parle de MS qui a toujours montré que son soft fait moins bien que as3.

Tu pars hors sujet pour noyer le poisson. Ouvre un autre fil si besoin où on pourra échanger avec des arguments objectifs sur les algoz au lieu de subir des allégations absurdes sur Turbu et les images diffusée par MS le mytho.

 

Tu n'as pas donné un seul argument sur la supériorité de Turbu à part des affirmations gratuites sur un outil que tu dis ne pas avoir utilisé (tout en invoquant la sacrosainte démarche scientifique)

 

 

Ici effectivement tu n'as convaincu personne et nulle besoin pour ça de me prêter des supers pouvoirs. Tu as déroulé tes arguments et ca n'a juste pas convaicu, et pour cause cette discussion est déjà pliée depuis presque 1 an ... Et depuis ce que MS a partagé sur astronomie-va est accablant.

 

 

 

 

[christian viladrich 6280]

il y a 48 minutes, CPI-Z a dit :

Ce type de Luchy-imaging dans un premier temps trie l'ensemble des images selon un critère de qualité, les images retenues selon un pourcentage défini par l'utilisateur.

AS3 les découpe en damier, les damiers d'une position donnée sont empilés, encore avec un tri indépendant du précédent, et tout en les translatant latéralement (tilt local), c'est sa méthode de correction de la turbulence.

Je suppose qu'il y a addition ou moyenne pour l'empilement des damiers et que les tilts locaux sont calculés à partir d'une image de référence, d'abord sur un empilement plus classique, puis en double stack sur le résultat de la première boucle.

Donc, on a le pourcentage des retenues de départ (par exemple 30%). Pour la sélection au niveau des damiers, il utilise peut être le même ratio, soit encore 30%, donc il reste que 9% au total des images d'origine utilisées dans la fusion. Le RSB est nécessairement faible.

 

En fait, ce n'est pas tout à fait cela : il n'y a pas d'abord un tri basé sur la totalité de la surface de l'image, puis ensuite des tris basés sur des sous-parties des images. Cela n'aurait aucun sens.

 

Le tri se fait donc directement et uniquement par sous-images.

 

Ce qui peut prêter à confusion, c'est que dans AS3, il y a une première étape de tri basé sur la totalité de la surface de l'image. Cette étape est là juste pour faire joli (en première approximation), à savoir afficher une courbe de qualité qui ne sert à rien. D'ailleurs Emil avait pensé à un moment la supprimer car elle apporte plus de confusion qu'autre chose.

 

Donc en résumé : le tri se fait directement et uniquement par sous-images. Il n'y a aucun tri sur la totalité de l'image (sauf si on choisi l'option "global"). Ensuite, les meilleures sous-images de chaque damier sont empilées (avec un tri indépendant d'une case du damier à l'autre).

 

Autrement dit, si on part d'une vidéo de 1000 frames, et que l'on choisi un critère de 30% pour la sélection, chaque sous-image (=chaque case du damier) est la somme de 1000 x 0.3 = 300 sous-images. Faire autrement serait totalement absurde. Et la méthode n'est pas nouvelle. Elle date de Registax 6 et Avistack

 

Dit autrement au cas cela ne serait pas clair, ce type de logiciel fait de lucky imaging par sous-image.

 

Après, on peut entrer dans les choses plus subtiles, à savoir comment on constituer l'image de référence qui est utilisée pour calculer les corrections de tip/tilt à appliquer aux sous images. Je renvoie là à "Astronomie Solaire" ou "Astronomie Planétaire" pour les gens qui veulent savoir, et surtout pour ne pas brouiller les débats avec ces subtilités de deuxième ordre (bien que importante pour le résultat)

 

Enfin, un point important, souvent négligé dans beaucoup de discussions, c'est quelle est la source d'information. Pour ma part, ce que je sais de AS3 (ou 2) provient des discussions que j'ai eu avec Emil pendant la rédaction de "Astronomie Solaire" ou "Astronomie Planétaire". Même chose d'ailleurs à une autre époque où j'avais pas mal discuté avec le concepteur d'Avistack (1 et 2). Ces gens-là sont en général très accessibles

 

 

 

[CPI-Z 1039]

Il y a 2 heures, christian viladrich a dit :

Le tri se fait donc directement et uniquement par sous-images

Et bien merci, là c'est plus clair, ainsi que sur le tri et donc sur le nombre d'images réellement utilisées.

Bonne soirée

[Jean-Francois P 172]

Bonsoir,

 

Je suis tombé sur cette discussion hier soir. Je ne vais pas trop commenté.

 

Un point de Christian concernant le tri au début ... et bien c'est possible sur Avistack. Mais cela ne veut pas dire que tout le monde doit l'utiliser.

Sur l'image ... à partir d'un film de 300 images, j'ai choisi 150 images (Quality analysis - Use frame cut-off) ... ensuite tous les traitements ne se font que sur les 150 images sélectionné par le tri initial.

C'est parfois utile avec un ciel pourri :-) ou bien si des nuages sont passés, et bien il est possible aussi de trier par intensité des images.

Si une fois, 90% des images sont à jeter, et bien temps qu'à faire les traitements que sur les images qui contiennent quelque information.

Bien sûr avec un ciel à moins de 1" ... tu peux tout utiliser.

 

Pour des algorithmes de traitements des images perturbées ... j'ai déjà fait des essais ... il y a très longtemps.

En 2006, j'avais contacté un professeur Donald Fraser à l'université de Canberra (Australie). https://staff.itee.uq.edu.au/lovell/aprs/dicta2003/pdf/0019.pdf

J'ai les fichiers *.mat de l'époque ... si quelqu'un est intéressé.

 

Bonne soirée,

Jean-François

 

 

[Optrolight 687]

@christian viladrich donc si je comprends bien. Dans as3 il faudrait choisir sa taille d'ap en fonction du R0 des images rapporter à la platescale ? 

Quelqu'un a regarder l'influence de cela dans les résultats ?

[Nebulium 1347]

Hello

 

J'ai retrouvé  dans ce fil de 2018 une photo de ce que je pense être ce fameux C11 :

 

"Ici le télescope est un C11 sur monture EQ6-R avec caméra ASI224MC et carte graphique GeForce 1050 Ti" :

 

 

Dans ce même fil, @polo0258 écrivait :

je suis en train de travailler sur ton projet 1.300  60 360 120 420 ..........31 films et images

 

Et voila le résultat du travail de @polo0258, obtenu bien sûr en temps différé :

 

http://nebulium.free.fr/vids/Lune40s.mp4

A gauche, le direct, à droite en léger différé.

Le défilement est évidemment volontaire pour la démonstration, bravo Paul !

 

Plus d'informations ici.

 

 

 

Edited March 14 by Nebulium

[polo0258 34075]

il y a 6 minutes, Nebulium a dit :

je suis en train de travailler sur ton projet 1.300  60 360 120 420 ..........31 films et images

 

 

 bonjour jean ! me rappelle même plus ce que veut dire cette série de nombres !!

 

 pour le reste j'ai du faire une vidéo normale en laissant faisant dériver !

 pour le montage et le traitement et la vidéo , c'est ton travail  , il me semble !

 bonne journée !

 paul

 

[jldauvergne 12666]

Il y a 17 heures, Optrolight a dit :

Dans as3 il faudrait choisir sa taille d'ap en fonction du R0 des images rapporter à la platescale ? 

Quelqu'un a regarder l'influence de cela dans les résultats ?

En théorie oui. Mais dans la pratique, c'est un peu plus compliqué que ça. Descendre sous une certaine taille ça ne fonctionne pas car il n'y a plus assez d'information dans l'AP. 
Typiquement au plus bas je mets des boites de 45 pixels alors que j'échantillonne fort (environ 0.1"/pix). Dans cette boîte de 45 p, si il y a du jet stream l'échelle de "floutage" sera facilement de 5 à 10 pixels, donc ça on ne peut pas trop luter contre. Autrement dit en deçà d'un certain angle d'isoplanetisme c'est game over. 

Les autre limitation tiennent à la nature de l'objet. Sur certaines zone de la Lune on peut à la limite accrocher des détails vraiment petits partout. C'est moins vrai dans les mers, où le logiciel peut perdre pied si les AP sont trop petits. 
Les planètes ça dépend de leur luminosité et de leur nature. AS3 fait des miracles sur la division de Cassini. Parfois c'est de la tôle ondulée et il s'en sort. Ca dit aussi que la réponse du télescope est très importante, plus il donne des brutes contrastées, plus ça aide AS3. 
Enfin dans la version actuelle, il y a l'option de poser des AP de différentes taille. Le logiciel va choisir au cas par cas selon les zones quelle est l'AP la plus appropriée. Ca fonctionne relativement bien. 

Edited March 14 by jldauvergne

[QGineys 1243]

Donc si je comprend bien:

 

 lorsqu’on sélectionne par exemple 30% a stacker au niveau du stack, on demande au logiciel de stacker 30% des meilleurs ap pour un un ap final?

cependant il ne va pas forcement chercher les ap à stacker sur les mêmes images. Potentiellement, pour une image finale, il peut avoir pris un ap sur l’image 234 pour une zone défini et ne plus utiliser cette même image pour d’autres ap?

 

Donc théoriquement (théoriquement je dis car je pense que ca doit être rare, si une image est mauvaise, elle est mauvaise de manière globale) il se peut donc qu’il aille cherche un ap sur image très moyenne parceque cette zone spécifique sur cette image en question est mieux que sur d’autres images?

Edited March 14 by QGineys

[jldauvergne 12666]

Il y a 1 heure, QGineys a dit :

lorsqu’on sélectionne par exemple 30% a stacker au niveau du stack, on demande au logiciel de stacker 30% des meilleurs ap pour un un ap final?

cependant il ne va pas forcement chercher les ap à stacker sur les mêmes images. Potentiellement, pour une image finale, il peut avoir pris un ap sur l’image 234 pour une zone défini et ne plus utiliser cette même image pour d’autres ap?

Si tu choisis l'option Local oui. 
Sinon il jouera avec les 30% des meilleures images et pas les autres. 

Il y a 1 heure, QGineys a dit :

Donc théoriquement (théoriquement je dis car je pense que ca doit être rare, si une image est mauvaise, elle est mauvaise de manière globale) il se peut donc qu’il aille cherche un ap sur image très moyenne parceque cette zone spécifique sur cette image en question est mieux que sur d’autres images?

Oui. 
Flou de manière globale ou pas ça dépend du champ, si tu fais de la Lune avec un IMX533 tu peux facilement avoir des variations très fortes d'un  bord à l'autre du champ. Au contraire si tu te fais une Mars de 10'', là la somme de 30% des meilleures AP et 30% des meilleures images, ça ne doit pas changer grand chose. 

Edited March 14 by jldauvergne

[Clouzot 237]

Question de bleu : si, à mon SER fait avec mon C6 tout pourri, je rajoute une (et une seule) superbe image finale de @jldauvergne mise à l’échelle pour que ça colle et dont date et horaire correspondent à ma séquence, puis que je demande à AS3 (ou autre) de l’utiliser comme image de référence, est-ce la seule présence de cette image va améliorer l’empilement de ma soupe de pixels ? Ou le gap est-il tellement grand que le soft ne s’y retrouvera de toute façon pas ?

[Nebulium 1347]

Il y a 5 heures, polo0258 a dit :

me rappelle même plus ce que veut dire cette série de nombres !!

 

Bonjour Paul

 

Tu retrouveras tes petits dans le fil cité plus haut :

http://www.astrosurf.com/topic/122666-vidéos-stabilisées-avec-as3-mode-demploi/

 

[Nebulium 1347]

il y a 12 minutes, Clouzot a dit :

je demande à AS3 (ou autre) de l’utiliser comme image de référence,

 

Hello Henri-Georges, euh, non, Jacques

 

Avant de demander à ChatGPT  tu trouveras ici :

http://www.astrosurf.com/topic/116499-jupiter-par-polo-à-la-sauce-artificielle/

quelques  cogitations préhistoriques sur le sujet 

[polo0258 34075]

 merci jean ! oui, j'avais mis ces films sur free !

 bonne soirée !

 paul

[Nebulium 1347]

Le 05/03/2023 à 21:43, jldauvergne a dit :

En tout cas ces personnes là (au moins 3 ou 4 personnes indépendantes les unes des autres), on vu que le code ne contient strictement rien de révolutionnaire

 

Hello

Dans le fil cité dans mon message précédent,  qui date de 2018,  quelques interventions de @ms  pourraient éclairer sur  les algorithmes utilisés dans ce code, en particulier l'usage du "deep learning", manière indirecte d'emprunter les images des autres.

[polo0258 34075]

il y a 38 minutes, Nebulium a dit :

Dans le fil cité dans mon message précédent,  qui date de 2018,  quelques interventions de @ms  pourraient éclairer sur  les algorithmes utilisés dans ce code, en particulier l'usage du "deep learning", manière indirecte d'emprunter les images des autres.

 

 j'ai donné un coup de main en donnant mes données , films  etc ..

 maintenant la haute résolution et ses algorithmes , ça me dépasse et n'est pas de mon niveau !

 pour moi pas de miracle ! un bon télescope , bien réglé , un bon seeing  et de bonnes images à la clef sans tout ce casse-tête !

bonne soirée !

paul

Edited March 14 by polo0258

[Clouzot 237]

Moi ce serait plutôt la version Jacques (moustache comprise). 
 

Dans le sujet que tu cites, ça cause d’entraînement de réseau. Tu avais bien fait de passer à Tensor Flow d’ailleurs  

Je ne doute pas que si on entraîne avec de super images on peut faire à peu près ce qu’on veut (si on met de côté l’aspect dynamique de l’atmosphère de Juju, qui peut peut-être limiter un peu la chose contrairement à d’autres surfaces planétaires plus figées). Et finalement le peu de données dispo, qui peut provoquer un méchant overfitting. 
 

Mais ma question était nettement plus basique : les softs classiques utilisent une (ou plusieurs) image de référence et chaque tuile va ensuite être classée par rapport à cette image, puis déformée selon un modèle X ou Y pour correspondre au mieux à ladite référence. Je me demandais simplement si, dans le cas où cette référence est de top qualité, l’empilement de ma bouse de séquence en sortirait grandie. 

[jldauvergne 12666]

il y a une heure, Clouzot a dit :

Ou le gap est-il tellement grand que le soft ne s’y retrouvera de toute façon pas ?

C'est une très bonne question. 

Si le gap est immense je ne sais pas si c'est judicieux. La diffraction entre 150 et 300 fait que les details sont differents. Mais la question avec une bonne image de 180 mm ca se pose. Est ce que ca gagne en précision ? Possible.

[christian viladrich 6280]

Il y a 1 heure, QGineys a dit :

Donc théoriquement (théoriquement je dis car je pense que ca doit être rare, si une image est mauvaise, elle est mauvaise de manière globale)

 

En fait, ça dépend de l''objet imagé et du champ couvert

 

En solaire, et à haute résolution, la zone où l'image est nette est presque toujours très petite par rapport au champ de la caméra. Voici un exemple qui montre juste 1/8 du champ du capteur. Le reste du champ est pourri. La zone nette est nettement plus petite que ce 1/8 du champ du capteur.

 

 

 

Du coup, en solaire, il faut que les carreaux du damiers soient très petits : je prends APsize = 32 pixels.

 

La nuit sur les planètes, c'est une autre histoire. En général, quand la planète est floue, elle est floue partout. Mais ce n'est pas toujours vraie, on peut avoir l'anneau de Sature net d'un côté, et flou de l'autre. Ça dépend du type de turbu, du diamètre du télescope, etc.

 

Sur la Lune, c'est un peu comme les planètes, mais le champ peut être nettement plus grand. On peut alors avoir des zones plus ou moins nettes dans le champ couvert par le capteur.

 

Dans tous les cas, c'est AS3 qui se débrouille de trouver les meilleures morceaux

 

Bien évidemment, se pose alors la question du choix de la valeur de APSize, sachant que ce APsize sert à deux choses :

1) découper l'image en morceaux pour faire ensuite des tris pour chaque morceaux,

2) corriger le tip/tilt sur chaque morceau d'images.

 

On peut très bien avoir Saturne uniformément nette (donc APsize grand potentiellement), mais avoir une image de Saturne en tôle ondulée, du coup on choisira un AP size petite pour corriger cela. Cela dépend complètement du type de turbulence.

 

On avait fait il y a très longtemps des comparaison sd'images de Mars au C14 avec Régis Benedictis. Sur son site, il avait une turbu rapide avec des images nettes mais en tôle ondulée (=> AP Size petit), moi j'avais une turbu lente globale (=> AP size grand).

 

Faut pas hésiter à faire des tests.

 

 

 

[christian viladrich 6280]

il y a 30 minutes, Clouzot a dit :

Mais ma question était nettement plus basique : les softs classiques utilisent une (ou plusieurs) image de référence et chaque tuile va ensuite être classée par rapport à cette image, puis déformée selon un modèle X ou Y pour correspondre au mieux à ladite référence. Je me demandais simplement si, dans le cas où cette référence est de top qualité, l’empilement de ma bouse de séquence en sortirait grandie. 

 

Quand tu dis "classée", tu veux peut-être dire "alignée" ? En effet, si on prends AS3, le tri des sous-images est fait sur la base du Lagragien. C'est un tri, de la meilleure sous-images à la pire. Il n'y a pas de classement par rapport une "image de référence".

 

Ensuite, il y a la question intéressante de l'alignement des sous-images par rapport à "une image de référence". Il faut donc calculer une "image de référence"

 

Il y a deux sous-questions :

- on aimerait que la géométrie de cette image ne soit pas "déformée" par la turbulence. Cela ne veut pas dire nécessairement que cette "image de référence" soit nette, mais les angles droits doivent être droits Pour cela, il faut compter sur le fait que la turbulence est "isotrope", autrement dit il n'y a pas de direction privilégiée. Si on empile suffisamment d'images, l'image résultant est peut-être floue, mais les angles droits sont bien droits,

- on aimerait aussi que cette image soit nette, car cela permettrait d'avoir un recentrage des sous-images plus fins. Pour cela, il faut additionner peu d'images.

 

On a donc deux objectifs contradictoires

 

 

Pour ce qui concerne AS3, et sans entrer dans les détails, l'idée du "double stack reference" est - après une première passe - de refaire une 2e passage avec cette fois-ci comme image de référence l'image issue de la 1er passe.

 

On peut aussi dans AS3 faire des choix sur comment est calculée l'image de référence.

 

D'une façon générale, ce n'est pas trop la peine de se prendre la tête là- dessus