Mars du 16 décembre, vidéo de 4h non stop

[Lambda]

Faut quand même avoir envie de rester 4h avec toi (la tout de suite ça met un frein quand même), par -5 (ça c'est a la portée de tous les astrams), a regarder un écran (ça ne dérangera pas les habitués du VA, tant que ça ne dure pas plus de 20')

+1, parce que du coup, pour moi, c'est plus du "VA" en fait, on éjecte la notion de "temps réel", ou au moins pseudo-réel, qui, je me répète, c'est vrai me semble essentielle à la pratique "VA"/Observation Assistée Electroniquement.....

Autant en CP, avec nos moyens amateurs de 2022, on peut tolérer de faire du stacking sur quelques minutes, parce qu'on échappe pas au fait malheureux qu'on ait besoin d'accumuler un minimum de flux de photons pour en tirer un signal utilisable sur des machins tout faiblards, autant en planétaire, si on veut rester dans l'esprit VA/OAE, on est en droit de rechercher à obtenir un effet "whaouu" dès qu'on pointe la planète brillante, ou du moins peut-être qu bout de quelques dizaines de secondes max de capture. D'un point de vue "psycho-sensoriel", immersion, ça collerait plus à la pratique VA/OAE. Sinon, si il faut laisser mouliner et prendre un kawa entre temps, on rentre plus dans une"manip de labo" pré-programmée....

Si ça se trouve, MS, ta méthode elle irait bien dans de l'observatoire pro/semi pro automatisé, pour faire du monitoring planifié et répétitif sur une grande période, de telle ou telle planète en fait, je me dis....

[ms55]

@ms55 , je suis un gars plein de bonne volonté : j'ai regardé ta vidéo !

Sauf erreur de ma part, tu précises au démarrage du soft quelle est la cible. Ton soft sait à quoi s'attendre comme genre d'image.

Sans chercher à polémiquer, l'arrivée d'une image potable dans la fenêtre de droite est assez brutale et du coup je me dis sincèrement "elle vient d'où cette image ?"

- elle est calculée uniquement à partir de l'acquisition ?

- elle est "fabriquée" en mêlant acquisition et bibliothèque d'images en stock avant l'acquisition ?

Je n'ai pas d'état d'âme par rapport à ça mais c'est vrai que, pour moi, il est indispensable de savoir dans quel cas on se trouve.

Regardes bien dès le début, les 5 premières minutes suffisent pour comprendre.
Au départ je vais définir une image brute de référence, c'est l'image brute qui est centrée sur le réticule.
Elle est stockée dans le répertoire "raw" :

0.png (110.28 Kio) Consulté 2652 fois

Différents contrôles sont fait (collimation, MAP, ADC, histogramme, ...) avant de lancer les opérations avec la touche *

Maintenant, il te faut regarder le compteur sur les images brutes, l'affichage va défiler de 1 à 8000 avec un pas de 5 (5, 10, 15, ...., 8000) pour ne pas dégrader les performances de la carte graphique. Les traitements sont faits eux sur les 8000 images qui défilent à la cadence de 198fps ... donc au bout de 8000/198 = 40s, l'image cumulée n°1 est enregistrée dans le répertoire "png" :

1.png (37.95 Kio) Consulté 2652 fois

Cette image va subir différents traitements pour obtenir l'image VA n°1 qui elle sera stockée dans le répertoire "sharp" :

1.png (68.07 Kio) Consulté 2652 fois

et ainsi de suite jusqu'à la dernière (n°360).

Tu peux toi aussi traiter l'image cumulée avec tes outils et nous montrer ce que tu obtiens, ce ne sera pas très différent de mon image VA.

[sebb916]

Bonjour

"My2cents" sur quelques points évoqués précédemment :
1) 4 h d'acquisition en planétaire c'est en effet très long : était-ce une nécessité de rester aussi longtemps dessus ?
Je comprends les remarques précédentes ; lors de la dernière NDE (2020 ) je montrais au public en double écran : sur le premier l'image en temps réel avec tous ses défauts, et sur le second je faisais un traitement express (3 min chrono pour que le public reste sur place d'une vidéo acquise juste avant. Je pense que cela a pas mal intéressé une partie du public, mais certains devaient se demander si ce n'était pas de la "triche", habitués qu'ils sont aux "photoshophage" des images

2) Est-ce que le manipulateur aux commandes du logiciel peut avoir la main, en temps réel, sur quelques paramètres ? "Agressivité", constraste, balance, saturation, déconvolution en temps réel ?
L'idée d'un traitement en direct est évidemment intéressante, elle libère du temps consacré a posteriori au traitement (long et fastidieux selon son niveau d'exigences).
L'intérêt du "VA" c'est cette quasi-immédiateté avec la possibilité de tripoter les curseurs et voir l'effet immédiatement.

J'ai toujours beaucoup d'admiration pour ce type de travail, étant totalement incompétent en programmation,

Les traitements monopolisent toute la puissance processeur et prennent du temps : serait-il envisageable/pertinent de limiter alors drastiquement le nombre d'images enregistrées pour obtenir un traitement "à la volée" avec prise en compte de quelques paramètres ?
Des captures écran que j'ai vu passer, le processus me semble "hermétique", on voit bien des lignes de commande qui s'affichent et les deux fenêtres mais je n'ai rien vu de plus.

[steph37]

Quand je pose une question de fond, la réponse que j'obtiens est de l'arithmétique, c'est systématique.

@ms55, on s'en doutait déjà un peu mais on ne va pas arriver à établir un vrai dialogue et c'est pas grave, ni pour toi, ni pour moi.

[John Mc Burn]

@steph37 la réponse est "42"

image.png (514.02 Kio) Consulté 2633 fois

[steph37]

@steph37 la réponse est "42"

Merci @John Mc Burn ! je suis pas surpris du résultat mais je n'ai pas encore les ressources de calcul nécessaires à la maison pour m'en approcher suffisamment.
Je suis actuellement tout près de "24", je vais ptet tenter une habile transformation pour gagner un peu de temps sur la convergence

[ms55]

Bonjour

"My2cents" sur quelques points évoqués précédemment :
1) 4 h d'acquisition en planétaire c'est en effet très long : était-ce une nécessité de rester aussi longtemps dessus ?
Je comprends les remarques précédentes ; lors de la dernière NDE (2020 ) je montrais au public en double écran : sur le premier l'image en temps réel avec tous ses défauts, et sur le second je faisais un traitement express (3 min chrono pour que le public reste sur place d'une vidéo acquise juste avant. Je pense que cela a pas mal intéressé une partie du public, mais certains devaient se demander si ce n'était pas de la "triche", habitués qu'ils sont aux "photoshophage" des images

2) Est-ce que le manipulateur aux commandes du logiciel peut avoir la main, en temps réel, sur quelques paramètres ? "Agressivité", constraste, balance, saturation, déconvolution en temps réel ?
L'idée d'un traitement en direct est évidemment intéressante, elle libère du temps consacré a posteriori au traitement (long et fastidieux selon son niveau d'exigences).
L'intérêt du "VA" c'est cette quasi-immédiateté avec la possibilité de tripoter les curseurs et voir l'effet immédiatement.

J'ai toujours beaucoup d'admiration pour ce type de travail, étant totalement incompétent en programmation,

Les traitements monopolisent toute la puissance processeur et prennent du temps : serait-il envisageable/pertinent de limiter alors drastiquement le nombre d'images enregistrées pour obtenir un traitement "à la volée" avec prise en compte de quelques paramètres ?
Des captures écran que j'ai vu passer, le processus me semble "hermétique", on voit bien des lignes de commande qui s'affichent et les deux fenêtres mais je n'ai rien vu de plus.

1) Ce n'est pas moi qui décide mais les nuages, ici l'éclaircie a duré de 22h00 à 2h00. Une rotation complète de Mars c'est 24h alors 4h à coté c'est pas grand chose.

2) Pour Mars c'est 40s entre 2 images VA tous traitements compris, autrement dit en 4h, j'obtiens 360 images traitées. Si le temps le permet dans 2 ans, je pourrais tenter une rotation complète en 2 sorties de 12h.
A chaque nouvelle image VA, une ligne est affichée, il y en a 360 lignes au total.
A 180fps, il faut faire vite ... quand une nouvelle image brute se présente le logiciel doit être capable de la fusionner avec la précédente en moins de 5,5ms c'est la première difficulté qu'il faut résoudre quand on s'attaque à ce genre de logiciel. Après, il reste peu de temps pour traiter la fusion des 8000 images brutes, ceux qui ont chargé la vidéo remarqueront qu'il y a "16 dropped frames" soit 16x5,5=88ms avant le démarrage de la prochaine capture. C'est le temps qu'il faut pour passer au traitement qui donne l'image VA à partir des 8000images fusionnées. Le temps total entre 2 images VA est de 40s + 88ms soit en gros 40s.

Après en tâche de fond c'est le multi-thread qui travaille pour aller chercher plus de détails 8 images VA avant et 8 images VA après.
Pour finir c'est un modèle de dégradation qui va traiter toujours en tâche de fond l'image issue de la recherche de détails en profondeur.
J'avais présenté le processus décrit plus haut en prenant l'image n°164 comme exemple :

164_process.png (194.57 Kio) Consulté 2611 fois

Sur les 360 images obtenues en 4 heures, j'en ai un bon 1/3 de cette qualité et cela ne posera pas de problème quand je ferais un 360°.
Ceux qui ont chargé la vidéo de cette soirée pourront vérifier que l'image n°164 n'est pas la meilleure.
Ce qui m'intéresse c'est d'utiliser mon matériel le plus possible et diffuser mes vidéos à un large public.
Cette première étape est aujourd'hui terminée, je vais donc pouvoir passer à la deuxième étape.

[John Mc Burn]

Ce qu'on essaie tous plus ou moins de dire, c'est que tu dis ce que tu fais, mais à aucun moment tu n'expliques comment ça fonctionne.

Aller chercher plus de détails en profondeur, ça ne dit pas comment ni à partir de quoi, si le soft ne sait pas ce qu'il doit trouver, soit il invente, soit il sait quoi chercher. La question a été posée plusieurs fois ici ou là, qu'est ce que tu donnes à manger à ton soft pour qu'il trouve des details qui n'existent pas dans tes brutes en tant que tels, si ce n'est une bouillie de pixels floue ? Est-ce que le soft se base sur des données externes à celle de la prise de vue (au pif une image de mars à l'instant T via winjupos) pour essayer de retrouver la même chose ensuite dans les brutes ?

Après de multiples fils ici et ailleurs, on a toujours pas compris comment ça fonctionne, et tu ne réponds jamais vraiment aux questions

[alaindumercantour]

Ce qui me réconforte c'est que, manifestement, je ne suis pas le seul à ne pas avoir compris ce qui se passe dans cette manipe, qui semble pourtant intéressante. Par contre j'ai compris qu'il faut de la grosse ressource de calcul.

[ms55]

La courbe bleu représente les images VA et la courbe rouge les images finales.
La courbe démarre à l'image n°9 (1+8=9) et se termine à l'image n°352 (360-8=352) à cause de la recherche (8+1+8) :

Le gain en qualité est assez important entre les images VA et les images finales.
D'autre part, il y a un lissage des effets de la turbulence lié à la recherche (8+1+8).
Vous pouvez vérifier sur la courbe rouge que l'image n°164 n'est pas la meilleure.

Ce qui me réconforte c'est que, manifestement, je ne suis pas le seul à ne pas avoir compris ce qui se passe dans cette manipe, qui semble pourtant intéressante. Par contre j'ai compris qu'il faut de la grosse ressource de calcul.

Pour Mars une carte graphique d'entrée de gamme suffit parce que les images font 400x300 pixels mais pour les grosses planètes il faudra plus de puissance pour atteindre un résultat comparable en 800x600.
C'est le prix à payer pour sortir son télescope par tout temps mais la principale difficulté c'est le temps nécessaire pour développer un logiciel qui exploite pleinement la carte graphique pour atténuer les effets de la turbulence. Personnellement j'ai utilisé la librairie C/C++ ArrayFire pour développer tous mes algorithmes.

[John Mc Burn]

Tu ne réponds toujours pas...

[Caprice]

Si je peux ajouter ma piécette et si je ne suis pas aux fraises, j'ai l'impression que l'on comprend à peu près comment tu passes de la courbe bleue à la courbe rouge. C'est comment tu parviens de 8000 images en poses de 1/200s que tu conserves quasiment toutes pour proposer déjà les images de la qualité de la courbe bleue.
Les habitués du planétaire ont plutôt une logique de lucky imaging ici et arriver à faire mieux en ajoutant en plus les "détails" de ce qu'ils considèrent d'habitude comme du déchet de prise pose beaucoup de questions, d'où l'idée d'une référence externe par exemple pour savoir où chercher ou d'une première image en lucky qui servirait de base pour aller chercher plus de détails avec le reste des frames

[ms55]

Ce qu'on essaie tous plus ou moins de dire, c'est que tu dis ce que tu fais, mais à aucun moment tu n'expliques comment ça fonctionne.

Aller chercher plus de détails en profondeur, ça ne dit pas comment ni à partir de quoi, si le soft ne sait pas ce qu'il doit trouver, soit il invente, soit il sait quoi chercher. La question a été posée plusieurs fois ici ou là, qu'est ce que tu donnes à manger à ton soft pour qu'il trouve des details qui n'existent pas dans tes brutes en tant que tels, si ce n'est une bouillie de pixels floue ? Est-ce que le soft se base sur des données externes à celle de la prise de vue (au pif une image de mars à l'instant T via winjupos) pour essayer de retrouver la même chose ensuite dans les brutes ?

Après de multiples fils ici et ailleurs, on a toujours pas compris comment ça fonctionne, et tu ne réponds jamais vraiment aux questions

Oui, j'explique le Quoi mais pas le Comment.
Une bonne partie des logiciels qui traite le problème de l’atténuation de la turbulence (turbulence mitigation) utilise l'algorithme "lucky-region fusion" sous différentes formes (voir les différentes publications à ce sujet).
Ici ce n'est pas le cas, j'utilise un algorithme que l'on pourrait appeler "no lucky-region fusion" et qui comme cela a été expliqué utilise toutes les images brutes en entrée.
C'est le premier point important, celui qui conduit aux images résultant de la fusion de 8000 images brutes.
Cela fonctionne comment ?
Au départ j'ai une image de référence qui va permettre d'aligner en temps réel mes 8000 images brutes.
Je ne vais pas décrire l'algorithme d'alignement-fusion qui est une des nouveautés du logiciel "turbu".
A l'arrivée j'obtiens une image floue mais qui contient tous les détails ... reste cependant à révéler ces détails.
C'est ce que fait un autre algorithme et je peux comparer le résultat que tu obtiendrais avec tes propres outils sur l'image n° 164 suivante :

164.png (36.39 Kio) Consulté 2544 fois

Si bien sûr personne ne fait l'effort de traiter cette image avec ses propres outils, il me sera difficile d'aller plus loin dans mes explications.

J'ai donc à un instant donné une image VA entourée de 8 images VA avant et 8 images VA après.
Un troisième algorithme va réaliser une interpolation sur le flot optique de ces images.
Une interpolation de grande précision qui va me permettre d'obtenir 9 images que je vais une nouvelle fois fusionner afin de me débarrasser du bruit.
L'image résultante contient un flou résiduel qu'un quatrième algorithme nommé MDD (modèle de dégradation) va gommer.

La manip complète consiste donc à traiter (8+1+8) images du répertoire "png" joint pour obtenir :
1) 17 images VA avec vos propres logiciels,
2) une image résultante obtenue par dé-rotation ou autre.

La meilleure façon de vous convaincre que vous pouvez arriver à un résultat analogue avec vos propres outils c'est de le faire vous-même.
La version 0.1 de turbu que j'ai mise à disposition en janvier 2022 contient entre-autre l'algorithme d'alignement-fusion qui est utilisé pour générer les images du répertoire "png".

Le répertoire "png" dans lequel vous trouverez les 360 images de départ :
https://www.dropbox.com/s/x8qxaclxt4af8uk/png.zip?dl=0
Les dates sont dans le répertoire en temps local.

Plus tard, je pourrais vous joindre les autres répertoires (sharp, depth et final) pour comparer avec vos résultats.

Ceux qui prendront le temps d'essayer verrons bien qu'il n'y a pas de gris-gris dans cette affaire.

D'un point de vu général, atténuer les effets de la turbulence atmosphérique c'est un travail de restauration qui permet de minimiser les distorsions, les bruits et les flous.
A mon avis, le lucky imaging veut aller trop vite en besogne et pour cela il recherche les meilleurs morceaux.
Le logiciel turbu s'y prend en plusieurs étapes, il se focalise dans un premier temps sur les distorsions puis fait ressortir une partie des détails bruités puis recherche en profondeur d'autres détails en se débarrassant d'une bonne partie du bruit et enfin corrige les bruit et flou résiduels en utilisant un modèle de dégradation.

[Lavinch31]

Au départ j'ai une image de référence

Question:

D' où sort donc cette image de référence ?

[pejive]

Si j'applique un traitement basique comme je le fais avec mes propres images (ondelettes, niveaux) sur ton image 164 j'obtiens des artefacts anormaux (une sorte de moirage)
Ondelettes

164wv.png (75.27 Kio) Consulté 2542 fois

zoom x2

164wvx2.png (176.93 Kio) Consulté 2542 fois

Ondelettes+réglage des niveaux

164wvlvl.png (47.63 Kio) Consulté 2542 fois

[ms55]

Au départ j'ai une image de référence

Question:

D' où sort donc cette image de référence ?

C'est une image brute toute bête que je centre sur le réticule après avoir vérifié la MAP, la colim, l'histogramme, l'ADC, ...
Je fais éventuellement plusieurs essais en appuyant sur la touche / pour obtenir un minimum de qualité mais cela n'a pas une grande influence par la suite car elle ne sert qu'à l'alignement.
Le logiciel va scanner 1000 images et prendre celle qui est de meilleure qualité.

[Caprice]

Un petit test rapide de ton image de référence



sous Registax donne en effet ce résultat chez moi

[ms55]

Si j'applique un traitement basique comme je le fais avec mes propres images (ondelettes, niveaux) sur ton image 164 j'obtiens des artefacts anormaux (une sorte de moirage)
Ondelettes
164wv.png
zoom x2
164wvx2.png
Ondelettes+réglage des niveaux
164wvlvl.png

L'image Registax plus haut se rapproche déjà pas mal de la mienne :

164.png (61.02 Kio) Consulté 2530 fois

J'ai décomposé tous les algorithmes à des fins de test, je peux obtenir l'image ci-dessus par la commande :
$ planet png/164.png sharp/164.png 74000 0.27 1.0 0.0 6600 1.6
ces paramètres sont propres à Mars dans les conditions d'observations choisies (8000 images brutes, 400x300, ...).

Le programme "planet" effectue :
- convolutions,
- alignement des couches RGB,
- balance des blancs,
- température des couleurs,
- saturation.

Attendons d'autres essais.

[soulearth]

C'est ce que fait un autre algorithme et je peux comparer le résultat que tu obtiendrais avec tes propres outils sur l'image n° 164 suivante
Si bien sûr personne ne fait l'effort de traiter cette image avec ses propres outils, il me sera difficile d'aller plus loin dans mes explications

Le répertoire "png" dans lequel vous trouverez les 360 images de départ :

Plus tard, je pourrais vous joindre les autres répertoires (sharp, depth et final) pour comparer avec vos résultats

dejaVu.gif (1.16 Mio) Consulté 2520 fois

[Lavinch31]

je peux obtenir l'image ci-dessus par la commande :
$ planet png/164.png sharp/164.png 74000 0.27 1.0 0.0 6600 1.6

et bien tu vois quand tu veux , on peux parler de manière simple

[Poussin]

défilent à la cadence de 198fps

A 180fps, il faut faire vite

[soulearth]

@Poussin je crois que tu tiens un truc !!!

Alors j'ai bien creusé et je pense que grâce à @Poussin on tient un début d'explication solide : ici

[John Mc Burn]

@soulearth m'a tueR (non il n'y a pas de faute)

je sais pas si j'ai envie de relancer d'un sirop de 21

[exaxe]

Une bonne partie des logiciels qui traite le problème de l’atténuation de la turbulence (turbulence mitigation) utilise l'algorithme "lucky-region fusion" sous différentes formes (voir les différentes publications à ce sujet).
Ici ce n'est pas le cas, j'utilise un algorithme que l'on pourrait appeler "no lucky-region fusion"

Trop fort le terme!
Et c'est cela le secret les gars, il faut dire non à la turbulence (qui noie l'information dans des pliures de dingue, avec du defocus et en plus différent sur le plan de la capture)
par un simple NO.
Tu fais ce que tu veux avec ton cerveau mais arrête de dire : je lisse le lissage de la turbulence pour récupérer de l'info!
Ton logiciel possède (peut-être) quelque chose d'intéressant, le fait de ne plus stocker des milliers de brutes sur un disque dur. Par contre prendre la totalité voir pire (et oui c'est pire quand tu injectes de l'info du passé et du futur) pour la résolution finale.
Franchement,les pros bossent depuis des décennies sur le Lucky pour rien? C'est une réponse peu coûteuse au Observatoire qui n'ont pas le budget pour l'optique déformante.
Après je sais que les algorithmes évoluent, par exemple depuis peu dur un article récent :
L'imagerie  Lucky  est  une  technique  de  récupération  d'images  astronomiques  à  haute  résolution  avec  deux  algorithmes  
d'implémentation  classiques,  à  savoir  la  sélection,  le  décalage  et  l'ajout  d'images  dans  l'espace  image,  et  la  sélection  de  données  
et  la  synthèse  d'images  dans  l'espace  de  Fourier.  Cet  article  propose  un  nouvel  algorithme  d'imagerie  chanceux  où,  avec  des  taux  
de  sélection  dans  le  domaine  spatial  et  dans  le  domaine  fréquentiel  comme  lien,  les  deux  algorithmes  classiques  sont  combinés  
avec  succès,  faisant  de  chaque  algorithme  un  sous­ensemble  approprié  du  nouvel  algorithme  hybride.  Les  résultats  expérimentaux  
montrent  qu'avec  le  même  jeu  de  données  d'expérience  et  la  même  plate­forme,  l'image  haute  résolution  obtenue  par  l'algorithme  
proposé  est  supérieure  à  celle  obtenue  par  les  deux  algorithmes  classiques.  Cet  article  propose  également  un  nouveau  schéma  
de  sélection  et  de  stockage  d'images  chanceuses,  qui  peut  économiser  considérablement  la  mémoire  de  l'ordinateur  et  permettre  
à  l'algorithme  d'imagerie  chanceuse  d'être  implémenté  dans  un  ordinateur  de  bureau  ou  un  ordinateur  portable  commun  avec  une  
petite  mémoire  et  de  traiter  des  images  astronomiques  avec  plus  de  cadres  et  une  plus  grande  taille.  De  plus,  grâce  à  une  analyse  
de  simulation,  cet  article  discute  des  limites  de  détection  d'étoiles  binaires  du  nouvel  algorithme  d'imagerie  chanceux  et  des  
algorithmes  traditionnels  dans  différentes  conditions  atmosphériques." @JL Yang.
Maintenant la question est: comment tu crées ton image ?

[John Mc Burn]

@exaxe comme ça:

$ planet png/164.png sharp/164.png 74000 0.27 1.0 0.0 6600 1.6



Bon la j'ai simplifié pour que tu comprennes, avec des mots c'est trop sujet à discussion.

Quand je pense que dans les grands observatoires pros ils se font @@@ la @@@ a créer des étoiles artificielles dans l'ionosphere via de puissants lasers, pour analyser en temps réel la déformation du front d'ondes et appliquer une correction via un miroir d'une complexité incroyable qui se déforme plusieurs milliers de fois par seconde afin de reconstituer le front d'onde corrigé de la turbulence reelle, alors qu'un programme de 70ko est capable de deviner ça tout seul, ils sont vraiment nuls à l'ESO