Nebulium

Le Clavius de Wilexpel revisité.

Messages recommandés

"Neb, as-tu vu..."

Pas encore, je voulais avant dégrossir avec le "Deshaker"

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
quote:Notre affaire ne passionne pas (encore) les foules, ...

Ce sera intéressant de voir les réactions aux premiers articles (pour l'instant il n'y a que les premières pages statiques qui vont s'étoffer grâce aux articles).


Salut

Au contraire, je suis cela avec un œil très très attentionné, question turbu justement. Même si intrinsèquement le traitement temps réel me laisse dubitatif (faire de l'itératif en temps réel, même en parallélisant le calcul a mort, j'y croit moyennement, mais Jocelyn Serot dit "legalet" sur AS me contredira peut être, vu que c'est son sujet de recherche en tant que professionnel), l'approche algorithmique du traitement d'image me semble malgré cela cohérente dans une certaine mesure.
A la lecture des publis que tu a cité dans d'autres posts, ms, il y a des algo laissant des zones d'ombre à mon humble avis (j’entends au niveau de leurs domaines de validité physique par rapport à la phénoménologie liée a la turbulence, j'étais d'ailleurs un peu monté dans les tours sur la question du traitement de la turbu en faible flux). Mais la confrontation a des disques planétaires comme le souligne Christophe, et j'imagine d'autres planéteux distingués, peut être très intéressante.

En tout état de cause, et je m'avance un peu en disant cela, est que la turbu simulée sur les séquence vidéos utilisée par Tiang est un peu "molle" et déterministe au regard de celle que l'on mesure sur des essais physique (mesures en optiques atmosphérique). Attention, je précise ma pensée, cela ne veut pas dire que l'algorithmie que tu met en œuvre soit inadaptée aux problèmes planétaires, mais il y a peut être un gap entre leur adaptabilité en astro et leur efficacité intrinsèque en tant que technique de restauration d'images.

Ayant 3 gros truc sur le feu actuellement, (dont un en turbu que je pense tester au pic cet été) je n'ai pas le temps d'essayer Julia (alors que je suis en ubuntu 14.04), mais je dit pas que je m'y mettrais pas avec curiosité quand j'aurais bouclé ce que j'ai en route.

Wait and see....

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut Brizhell

Ah, je me disais bien...
Content que tu te joignes à nous

Je viens de récupérer le dernier AS!2
Sûr que les images "underwater" lui sont totalement indigestes, bien trop déformées pour de l'astro.

Je me suis rabattu sur cette page "Turbulence" du site d'Omar où j'ai chargé ce gros zip

On y trouve quatre séquences plus crédibles pour notre souci, avec des images "raw" en TIF de 640x480, facilement prétraitables avec VDub pour ressembler aux timbres-poste témoins BMP 250x180.

Celles-ci conviennent très bien à AS!2 et j'ai l'intention de mon côté de voir ce que donne en final la déconvolution aveugle préalable image par image avec l'algo chinois dont j'ai trouvé une version en ligne de commande.
En plus, je viens de m'apercevoir que le filtre "Photomasque" de VDub est parfait pour "casser" les bords d'image qui perturbent la PSF.
Pour traiter une séquence, c'est autrement plus commode que la bidouille en ligne que j'ai indiquée en page 1 !

[Ce message a été modifié par Nebulium (Édité le 09-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
si vous voulez du SER qui gigote dans tous les sens, j'en ai plein ma besace...
ta version de traitement sur le clavius de william est impressionnante de réalisme, peut être que les arêtes sont trop dentelées?
stephane

[Ce message a été modifié par exaxe17 (Édité le 09-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
En tout état de cause, et je m'avance un peu en disant cela, est que la turbu simulée sur les séquence vidéos utilisée par Tiang est un peu "molle" et déterministe au regard de celle que l'on mesure sur des essais physique (mesures en optiques atmosphérique).

Tian (2009) -> Oreifej (2011) -> Xie (2014).
Xie a fait la jointure entre la correction de la turbulence sous-marine faite par Oreifej (Two-Stage reconstruction) et la correction de la turbulence atmosphérique faite par Zhu (Near-Diffraction-Limited-based reconstruction). Entre les deux Oreifej nous montre une chose intéressante concernant l'évolution de la moyenne temporelle :

Et quand tu pousses un peu plus loin, tu retombes sur notre sujet de traitement de la turbu en faible flux.

quote:
Sûr que les images "underwater" lui sont totalement indigestes, bien trop déformées pour de l'astro.

"underwater" c'est en fait ce qui se passe très souvent pour la turbu terrestre à longue distance ou pour la surface du Soleil où des régions très déformées cohabitent avec des régions à peu près calmes.

Julia est un langage relativement jeune mais qui possède déjà tous les outils pour faire un traitement statistique sur des nuages de points qui évoluent comme des étourneaux.

quote:
si vous voulez du SER qui gigote dans tous les sens, j'en ai plein ma besace...

Proposer des algorithmes empêchant le SER de gigoter dans tous les sens c'est le but du site srapplis.org

[Ce message a été modifié par ms (Édité le 10-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites

............ elle est si belle ma petite Julia ........

bon,je suis complètement largué ..

polo

Partager ce message


Lien à poster
Partager sur d’autres sites
"............ elle est si belle ma petite Julia ........ "

Tu nous montres laquelle c'est ?


Polo, j'ai vu que tu avais du temps à passer, et donc pour que tu reprennes confiance, je vais te passer un lien vers un AVI monochrome.

Ça me rendrait service si tu pouvais me le traiter avec AS!2 et Registax, plus ondelettes, etc, tout ce que tu veux (en disant quoi et gardant les paramètres si possible) pour explorer, en utilisant le langage de ms, les deux trajets dans le labyrinthe (et même trois avec Avistack) et publiant les images finales en PNG.

[Ce message a été modifié par Nebulium (Édité le 10-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Merci Polo

Je vois qu'il y a encore deux autres lascars dans la course, en plus d'Omar.
Je ne vais plus arriver à suivre, n'en jetez plus !

Dans l'immédiat, avec mes moyens limités et l'aide à venir de Polo (car je ne suis pas un spécialiste du paramétrage fin des logiciels d'empilement, mais toutes et tous sont aussi bienvenus pour le coup de main), j'ai commencé à explorer en béotien un des chemins du labyrinthe, celui passant par AS!2 réglé plus ou moins par défaut, avec un max d'AP.

J'ai commencé à travailler sur la séquence A d'Omar (440 images) dont voici un échantillon en réduction 50%, après correction Luminosité Contraste Gamma des "raw" d'origine. *
.
.

Ce film me semble affecté principalement de déformations (il y a du vent !) mais pas de défocalisations. Il est également peu bruité.

Mes capacités ne me permettent pas de mettre en oeuvre le code proposé par Omar pour apprécier ses résultats

Mais si cette approche non matheuse intéresse, on pourra ouvrir un autre fil dédié aux approches simples du problème en attendant les avancées de ms avec publication de premiers résultats.

J'ai déjà comparé l'empilement des images avant et après accentuation (2D FFT en "batch") des images individuelles puis accentuation finale 2D FFT et déconvolution "simple" de FitsWork.
J'en laisse un peu pour les adeptes des ondelettes et autres masques flous
Je vais m'attaquer maintenant aux déconvolutions "aveugles" individuelles des images d'origine, mais là, c'est un peu au-dessus de mes connaissances actuelles, faut que j'étudie un peu le truc.

* La fenêtre "Cinéclub" est destinée à éviter certains artefacts de traitement en particulier lors des déconvolutions.

[Ce message a été modifié par Nebulium (Édité le 10-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Doublon !

[Ce message a été modifié par Nebulium (Édité le 10-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut Neb

quote:
Content que tu te joignes à nous

Je le redit, juste comme observateur, avant d'avoir le temps de replonger dans le code, sachant que j'ai déjà dépilé quelques publis.

quote:

Et quand tu pousses un peu plus loin, tu retombes sur notre sujet de traitement de la turbu en faible flux.


Tu peut toujours rêver ms, mais il y a un des fondamentaux que tu ne maîtrise visiblement toujours pas et pour lequel moi et quelques autres (un certain Thierry L. si je ne m'abuse) t'ont signalé que s'était physiquement impossible en faible flux. Pas parce que tes algo ne sont pas robuste et efficaces, mais parce que tu ne sépare pas le signal du bruit dans tes brutes. Je pense qu'il y a des choses intéressantes dans ta démarche à condition d'avoir du signal (ce qui est le cas des vidéos en planétaires et solaire), mais aller chercher le pulsar du crabe avec une Toucam proII et un ETX90 est tout simplement physiquement impossible. C'est comme distinguer le bruit du battement d'aile d'un papillon a 4 mètres des enceintes d'un concert de Metallica au stade de France... Il y a des limites physique que tu ne peut franchir, et la détectivité d'une camera en faible flux en est une, quelque soit l'algorithme de traitement que tu emploie....

Sur du planétaire par contre, il y a probablement matière, et je perdrait pas une miette de vos tests !


Partager ce message


Lien à poster
Partager sur d’autres sites
J'ai oublié de préciser, Neb, je trouve ton retraitement de cette image de clavius absolument somptueux !!

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
mais aller chercher le pulsar du crabe avec une Toucam proII et un ETX90 est tout simplement physiquement impossible

Physiquement oui, là je suis entièrement d'accord avec vous mais statistiquement non.
L'approximation variationnelle (bayésienne ou autre) doit pouvoir s'appliquer dans le cas d'une acquisition où le flux de photons nécessaires est obtenu à posteriori. Le signal et le bruit feraient par exemple parti d'un modèle de mélange ... je développerai cette idée à la fin de la deuxième application.

Neb, le but c'est de charger et d'évaluer tous les codes (algorithms, applications, quality, performances) sous Juno comme dans la page suivante :
http://srapplis.com/?page_id=721

Toutes mes applications sont sous Linux Mint mais ceux qui préfèrent Windows ou Mac OS X peuvent utiliser Juno dans leur environnement (vous risquez juste de rencontrer un problème avec la mémoire partagée qui est encore en cours de test dans ces environnements).

L'organisation des fichiers est indiquée dans l'article suivant : http://srapplis.com/?p=1579

[Ce message a été modifié par ms (Édité le 11-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Bonjour

Merci Brizhell pour ta sympathique appréciation

Merci ms

Je viens d'ouvrir un nouveau fil pour mes bidouilles du moment.
Dès que j'en aurai fini avec l'os sur lequel je suis tombé, je reviendrai sur ton site.
Peux tu me donner ton avis sur le "naturel" de la séquence A d'Omar , Merci
Je n'ai pas trouvé le film résultant d'Omar fait avec ses calculs, que je suis dans l'impossibilité de maîtirser

Il faudra aussi que je regarde les deux chinois, mais tu as peut-être déjà un peu défriché le terrain

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
Physiquement oui, là je suis entièrement d'accord avec vous mais statistiquement non.
L'approximation variationnelle (bayésienne ou autre) doit pouvoir s'appliquer dans le cas d'une acquisition où le flux de photons nécessaires est obtenu à posteriori. Le signal et le bruit feraient par exemple parti d'un modèle de mélange ... je développerai cette idée à la fin de la deuxième application.

Je répond rapidement.

La on rentre dans mon domaine de boulot....
Non, c'est ne partie là qu'il y a erreur du point de vue physique, la statistique Bayesienne (ou autre ne peut pas être appliquée), tant du point de vue temporel que spatial en comptage de photons, à rapport signal sur bruit inférieur à 1 derrière un système de conversion photon/électron (ce qui est le cas dans une webcam ou une camera classique dont la détectivité est insuffisante. Tout simplement parcequ'il est impossible de distinguer en sortie de chaîne d'aquisition un électron généré par un photon tombant sur la matrice, d'un électron de bruit généré naturellement par le silicium ou les composants de conversion charge/tension.

Il faut avant de faire de la statistique, un système de ségrégation des événements pour pouvoir appliquer les principes de la statistique. En d'autres termes, il faut séparer le signal électronique du au photons du bruit électronique dut à la conversion des charge.
Et ce régime la est inaccessible avec des cameras non adaptées.

La turbulence est au regard de la camera, non pas du bruit mais du signal. Signal indésirable, certes, mais signal quand même. Et en faible flux, si on n'extrait pas ce signal du bruit intrinsèque de la camera, ben on fait rien.

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
Il faut avant de faire de la statistique, un système de ségrégation des événements pour pouvoir appliquer les principes de la statistique.

En faisant une hypothèse sur la distribution du bruit et en remarquant qu'à chaque itération tu as le même niveau de flou entre la moyenne des trames et chaque trame. Le champ de déformation est estimé à chaque itération à partir du champ de déformation de la moyenne des trames. Ces hypothèses peuvent être facilement vérifiées en faisant la même observation avec une CCD et une EMCCD par exemple. Je reviendrai plus tard sur cette manip quand j'aurai bouclé les 2 premières applications.
Cette corrélation entre le niveau de flou de la moyenne et le niveau de flou d'une trame est signalé par exemple par Oreifej.

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut

Desolé de poursuivre, on est pas dans la bonne rubrique en fait, ce post devrait maintenant se trouver sur astropratique.

quote:
En faisant une hypothèse sur la distribution du bruit et en remarquant qu'à chaque itération tu as le même niveau de flou entre la moyenne des trames et chaque trame.

Ben non, et c'est la que tu fait une confusion évidente entre le bruit, le signal utile et le signal de perturbation.

J'avais détaillé ça ici (attention c'est assez technique) :
http://www.astrosurf.com/ubb/Forum2/HTML/039303.html

En faisant un résumé rapide. Ce que regarde le système d'imagerie, après conversion des photons en électrons, c'est un signal en tension composé de : QRE*Signal de photons + Bruits électroniques de toutes sorte (bruit du DEC, bruit de conversion, bruit des amplis, etc...).
QRE est le rendement quantique de la matrice.

le premier terme de cette somme se décompose en 2 termes :
Signal de photons = Signal de l'objet + fluctuations de signal de l'objet + signal de perturbations atmosphériques

En règle générale, les fluctuations de signal de l'objet sont négligeables, même à faible flux.

Ce que toi tu appelle du bruit est en fait du signal de perturbation atmosphérique.
Les hypothèses utilisant les statistiques Bayesiennes (ou autres méthodes variationnelles) sur la distribution spatiale des photons de signal ne sont applicables qu'a partir du moment ou la totalité du signal de photons (signal de perturbations atmosphérique comprise) est extraite du bruit électronique. Et tu ne peut pas remplir cette condition en faible flux en pose courte, c'est aussi simple que ça (ca vaut dire que tu ne peut rien faire physiquement avec une webcam et en ETX, sauf peut être en planétaire, et encore, mais on est plus en faible flux).

quote:
Le champ de déformation est estimé à chaque itération à partir du champ de déformation de la moyenne des trames. Ces hypothèses peuvent être facilement vérifiées en faisant la même observation avec une CCD et une EMCCD par exemple.

La condition de base qui s'ajoute comme contrainte supplémentaire en faible flux est que la turbulence atmosphérique soit figée, autrement dit posé avec des temps de poses de l'ordre de quelques millisecondes (Christian Viladrich, et moi en interfero des tavelures, en avons fait de très belles démonstrations). A quelques millisecondes de temps de pose en CCD, tu n'a quasiment pas de signal en faible flux (en particulier pour le CP). Le bruit (et je parle bien du bruit camera) sera supérieur au signal total de photons.

quote:
Cette corrélation entre le niveau de flou de la moyenne et le niveau de flou d'une trame est signalé par exemple par Oreifej.

Oreifej utilise des séquences videos sur lesquelles tout le signal de photo est séparé du bruit électronique.


Partager ce message


Lien à poster
Partager sur d’autres sites
Pour faire imagé, et avec les mains. Imagine qu'un pixel est un pot de peinture verte. les électrons sont des cubes de couleurs nageant dans le pot de peinture.
Au départ (avant la pose) les cubes nagent librement dans la peinture. Le pot est fermé. Tu ne connais pas le nombre exact de cube dans le pot.

Puis tu ouvre le pot de peinture (début de la pose), et les photons vont a la surface du pot fabriquer des cubes supplémentaires de couleur bleue. Ces cubes bleus vont tomber au fond du pot et donc se colorer en vert. Tu perd donc l'information sur cubes dus aux photons/cubes nageant dans le pot.

Pour obtenir le nombre total de cube dans le pot, tu verse le contenu du pot dans une passoire et tu compte le nombre de cube. Tous les cubes sont vert. Tu ne sais pas ceux qui sont issus du fond du pot ou ceux qui sont issus des photons.
Tu ne peut prendre que des hypothèses statistiques sur le nombre de photons par rapport au nombre de cube qu'a condition d'avoir très peu de cube au départ au fond du pot de peinture, de connaître précisément la probabilité de conversion d'un photon en cube bleu, etc.....

C'est beaucoup plus compliqué qu'il n'y parait, en faible flux de séparer le signal (toutes sources confondues) du bruit.

[Ce message a été modifié par brizhell (Édité le 13-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
J'aime bien ta métaphore du pot de peinture verte qui explique d'une certaine façon la nécessité dans cette affaire d'effectuer un comptage de photons. J'en retrouve aussi une explication au chapitre 8 (formule 8.1) dans cet ouvrage récent (merci google) : http://books.google.fr/books?id=RzehSUtgxvsC

Je reviendrai plus tard (en 2016 probablement) sur la turbulence en faible flux (c'est une autre sujet en effet) mais sans CCD cette fois.

Ce problème de faible flux mis de coté, je reviens sur l'aspect "temps réel" de certains traitements itératifs. Dans un prochain article, je parts de l'algorithme d'interpolation ICBI (iterative curvature based interpolation) qui ne donne pas d'artefacts et je compare 3 implémentations : Octave, Julia, Julia // (mémoire partagée et programmation par GPU). Je pense que cela devrait donner envie à certains de découvrir Julia. Dans la publication suivante, le développement CUDA est fait en C++ (mon but c'est d'avoir le même langage de bout en bout : de l'algorithme à l'application) :
http://www.andreagiachetti.it/icbi/InterTIPmod2c.pdf

[Ce message a été modifié par ms (Édité le 13-02-2015).]

Partager ce message


Lien à poster
Partager sur d’autres sites
> C'est beaucoup plus compliqué qu'il n'y parait, en faible flux de séparer le signal (toutes sources confondues) du bruit.

Tout à fait, Bernard Avec une em-ccd, par exemple, on peut rendre le bruit de lecture totalement négligeable. C'est alors le bruit de photon (celui du fond du ciel typiquement) qui devient prépondérant et qui limite au final la détectabilité des objets.

Sur les possibilités d'implémentation temps-réel, ce qui compte c'est le _déterminisme_ temporel des algorithmes. A la limite ils peuvent être itératifs mais on doit pouvoir borner a priori le nombre d'itérations. Mais dans ce cas, on est le plus souvent amené à _fixer_ le nombre d'itérations a priori ce qui conduit soit à des résultats sous-optimaux, soit à des temps de calcul exagérés. D'une manière générale, passer d'un code disons en Matlab à un bitstream pr un FPGA suppose presque toujours (sauf pr des cas triviaux) une _reformulation_ plus ou moins profonde des algorithmes. Certains langages - je le sais, j'en développe un - permettent d'aider à reformuler, mais rien ne peut se faire automatiquement. C'est là tout le challenge aujourd'hui.

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
Certains langages - je le sais, j'en développe un - permettent d'aider à reformuler, mais rien ne peut se faire automatiquement. C'est là tout le challenge aujourd'hui.

Embarquer Julia sur une carte CPU+GPU (Jetson TK1 par exemple) et gérer à la fois la mémoire partagée (CPU) et les processeurs graphiques (GPU) c'est d'une certaine façon répondre à ta question non ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Tout dépend de ce que tu entends par "gérer"..
Si c'est fait _explicitement_ dans le langage alors je ne suis pas sur qu'un algorithmicien lambda aura envie de "gérer" justement..
Si c'est fait de manière transparente, alors il y a encore du boulot pour obtenir des performances satisfaisantes sur des algorithmes non triviaux..
Une thèse intéressante sur le sujet.

Partager ce message


Lien à poster
Partager sur d’autres sites
Çà plane haut par ici :-)

J'aurais tendance à dire que si on cherche du flux ... on peut en trouver en solaire ;-)
Il y a aussi les méthodes de "phase diversity" qui paraissent intéressantes (enfin, vue de la lorgnette d'un béotien ...).

Partager ce message


Lien à poster
Partager sur d’autres sites
C'est complétement glucose
à 3min40

https://www.youtube.com/watch?v=Z4MyUpbPRVE

Partager ce message


Lien à poster
Partager sur d’autres sites
T'es dur Yann. Après tout, l'espoir de Neb et Ms n'est peut-être pas si désespéré. A condition d'analyser que l'absolu ne doit pas être annihilé (et vice-versa)

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant