Sign in to follow this  
Nebulium

Jupiter au T 1m du Pic. 2010. Le retour.

Recommended Posts

L'utilisation d'un nombre réduit de trames (100 / 450) se traduit par une baisse du signal dans une partie seulement des fréquences :

La différence en visuel est beaucoup moins sensible quand on compare les 2 images suivantes (l’œil effectue un lissage des fréquences) :
http://www.dropbox.com/s/okodmq89x83hnit/jup_ms1_100.png?dl=1 http://www.dropbox.com/s/3wlit8099jooglw/jup_ms1.png?dl=1

Retenir 100 trames pour le visuel assisté est donc largement suffisant.

Share this post


Link to post
Share on other sites
Publicité
En vous inscrivant sur Astrosurf,
ce type d'annonce ne sera plus affiché.
Photographier la Lune
Guide complet pour la photographier de la Lune.
Information et commande sur www.photographierlalune.com
quote:
J'ai intégré les 450 images du Pic et j'en ai profité pour faire un traitement entièrement automatique (dégauchissage + défloutage + débruitage).

Ca, c'est intéressant !

quote:
Sur l'image, il y a toujours une petite contraction (problème de recalage avec RGX ?).

Tu aurais intégré RGX dans ton traitement automatique ?

quote:
Sur la courbe, tout se passe comme si SW avait utilisé plus de trames alors qu'en principe vous avez plutôt tendance à en jeter. J'opte plutôt pour le fait qu'il y a moins de trames mais une image PNG en 16 bits alors que la mienne n'est qu'en 8 bits (pour du visuel assisté 8 bits suffisent).

Il me semble que les films publiés par JLD étaient des SER (avec combien de bits ?)
Quand je serai rentré, je regarderai si je ne les retrouve pas dans de vieilles sauvegardes

quote:

Les images obtenues ...
jup_ms1.png
jup_sw1.png

Ces deux images sont quasiment identiques, "ms1" un micropoil plus fine.

Mais la sw1 ne correspond pas à l'original de la p 1, j'ai dû zapper un truc
La chute de la réponse de la ms1 ente Fs 0.15 et 0.2 me surprend, et je n'arrive pas à récupérer qoui que ce soit au delà.
Pour le rendu des fins détails, on est encore loin de ce que JLD avait montré avec sa "jupmorphed 3", même si celle-ci peut paraître surtraitée

Deux remarques techniques :

1. Je ne sais pas avec quoi tu fais tes GIF, mais la palettisation est crade, sur les images de Juju, c'est inexploitable !
A défaut d'un traitement manuel approprié, tu pourrais essayer "Instagiffer."
- Importer les PNG dans VDub
- Filtre "Resize" à 50%
- Sauver en AVI sans compression
- Charger l'AVI dans Instagiffer, paramétrage ci-dessous :
.

Et voici ton GIF revu (en 207 ko contre 192 ko)
.

L'idéal serait encore de monter un "mouseover" sur une page html, voici un exemple mais c'est du boulot !.


2. Je vois que tu t'es mis à FW.
Pour comparer les FFT , plutôt qu'un GIF alternatif :

- Charger les deux images
- Faire apparaître la courbe de la 1
- Clic droit dedans > Faire une image du graph => Graph1
Eventuellement, la colorier (Couleurs > Balance)

idem pour la 2 => Graph2 , la garder en focus

Ensuite : Combinaison d'images > Additionner ...
Voici un exemple avec swo (original en p 1, jaunie) et ms1 :
.

3. Il existe un gadget "Glass2k" qui permet de rendre les fenêtres transparentes. Très utile pour égaliser les FFT.

quote:
L'utilisation d'un nombre réduit de trames (100 / 450) se traduit par une baisse du signal dans une partie seulement des fréquences :

Je vais charger ces images et les étudier.

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

Share this post


Link to post
Share on other sites
Je suis ... je suis... même si je n'interviens pas....

quote:
Il me semble que les films publiés par JLD étaient des SER (avec combien de bits ?)

C'était des avi non (ou très peu) compressés ( la taille du zip est la moitié de l'avi)

Les noms des fichiers à l'époque :
jup_2010-09-29_22-58-53_V.zip/avi
jup_2010-09-29_22-59-28_B.zip/avi
jup_2010-09-29_22-58-16_R.zip/avi

Francis

PS : je vais revenir dès que j'ai un peu de temps pour finir mes traitements sur cette histoire de "distorsion" par rapport aux (dans ? ;-) ) résultats d'alignement/empilage fournis par Sylvain à l'époque.

Share this post


Link to post
Share on other sites
quote:
Je ne sais pas avec quoi tu fais tes GIF, mais la palettisation est crade

Oui c'est quand je réduis le gif de 100% à 50% avec GIMP mais à l'avenir je ferais tous les gif avec ImageMagick surtout que c'est plus rapide :
$ convert -delay 100 -loop 0 *.png image.gif
pour 100/100 = 1s entre chaque image.

quote:
Ces deux images sont quasiment identiques, "ms1" un micropoil plus fine.

C'est l'algo de débruitage et défloutage qui lisse tout le monde, voir ci-après le travail sur la couche rouge de sw et ms :

quote:
Pour le rendu des fins détails, on est encore loin de ce que JLD avait montré avec sa "jupmorphed 3", même si celle-ci peut paraître surtraitée

C'est normal ... il manque un étage à la pyramide qui se limite pour l'instant à l'Optical Flow. Cette étage c'est la Super-Résolution. Pour de la vidéo assistée, l'Optical Flow est suffisant mais pour la haute résolution c'est en gros : Super-Resolution Optical Flow.

Et pour venir à bout de certains cas difficiles (la juju de Neb, les images pourries par une turbulence forte, ...), j'utilise les réseaux de neurones Caffe (C/C++) ou Mocha (Julia) et l'Optical Flow pour obtenir un étage utilisable pour la Super-Résolution.

Share this post


Link to post
Share on other sites
quote:
Mais la sw1 ne correspond pas à l'original de la p 1, j'ai dû zapper un truc

En jaune : images recalées couleur 8 bits (comme ms1 et sw1 ci-dessus).
En blanc : images recalées couleur 16 bits (comme la sw de la page 1).
En cyan : image sw de la page 1.

Les images couleurs 8bits recalées ms1 et sw1 qui me servent pour les essais :

En jaune : ms1.
En blanc : sw1.
http://www.dropbox.com/s/4mfrycp0tjdsyeu/j_ms1_8bits.png?dl=1
http://www.dropbox.com/s/wbuobkf6hrbz42q/j_sw1_8bits.png?dl=1

Je vais faire la même manip avec les images R,G,B issues des fichiers AVI mais avec une profondeur de 16 bits au lieu de 8 bits.

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

Share this post


Link to post
Share on other sites
quote:
En jaune : images recalées couleur 8 bits (comme ms1 et sw1 ci-dessus).
En blanc : images recalées couleur 16 bits (comme la sw de la page 1).
En cyan : image sw de la page 1.

A vrai dire, je n'ai pas compris grand chose à cette légende

En tout état de cause, il est très facile d'ajouter du texte dans FW : Touche T.
.

Je reste néanmoins surpris de la différence de résultats entre 8 et 16 bits.
De plus j'ai cru comprendre que les AVI d'origine (et les PNG qui en découlent) sont en 8 bits et donc que SW a obtenu l'image de la p 1 par un traitement des 8 bits initiaux.
Il est vrai aussi que les divers traitements d'accentuation opèrent ensuite en 16 ou plus ou flottant, mais ça ne devrait pas beaucoup influer sur les résultats.

Share this post


Link to post
Share on other sites
Non, les AVI d'origines sont en 16 bits et les PNG que j'en avais extrait étaient en 8 bits.

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

Share this post


Link to post
Share on other sites
ms : les avi d'origine sont en 8 bits niveaux de gris ( c.a.d 8 bits par pixel avec une LUT 8bits->RGB en niveaux de gris ), non compressés.
Note que la taille des fichiers .avi ( environ 626 MO ) correspond bien à cette description.

Francis

Share this post


Link to post
Share on other sites

Merci Francis

J'avais un doute quant à l'existence d'AVI en 16 bits.
D'où "l'invention des SER"

Je vais essayer de résumer la situation telle que je la comprends, les parties prenantes sont invitées à corriger et / ou préciser, merci :

- Le "focus" est actuellement sur l'objectif initial de ce fil, à savoir appliquer les nouvelles techniques de "super-résolution" étudiées par ms à des prises de vues exceptionnelles de Jupiter réalisées par JLD au T1m du Pic en 2010 qui ont déjà été traitées en leur temps par un certain nombre de spécialistes. auxquels d'autres se sont ajoutés récemment dans les premières pages de ce fil.

- Les prises de vues originales se présentent sous forme de trois films R, V, B de 450 images en AVI 16 bits.
Ils ne sont plus disponibles sur le net, mais en page 1, on les trouve sous forme de PNG 8 bits mis en ligne par ms.
J'ai cru comprendre que ms disposait des originaux, peut-être aussi Françis, peut-être aussi moi-même, à vérifier quand je retrouverai mes archives.
- Ces prises de vue ont été traitées par SW (Sylvain), l'un des développeurs de Registax.
Il a publié, disponibles en p 1 un pack "JupiterPdM-Registax60122.zip" comportant en PNG 8 bits des empilements séparés RGB RGX6 bruts qui après recalage géométrique et synthèse fournissent l'image appelée par ms "sw1" et des RGB accentuées (qui saurait en déchiffrer les paramètres d'après les noms des fichiers ?) qui après recalage géométrique et synthèse par SW fournissent la première image de la p 1 en JPG, que je propose de nommer "sw0"
- Ces prises de vue subissent actuellement divers traitements par ms, en 8 bits et 16 bits (nota : il faut bien comprendre qu'il s'agit ici de la profondeur des images d'origine, car les divers logiciels astros intervenant par la suite fonctionnent d'office en 16 bits ou plus ou en flottant) et en utilisant des quantités diverses d'images, triées selon des critères de qualité qu'il convient de préciser, afin que tout un chacun intéressé ait la possibilité de comparer sa cuisine avec celle de ms.
Ci-dessus, sont publiées "jup_sw1.png" (450 images ?) "jup_ms1_100.png" (100 images) et" jup_ms1.png" (450), toutes obtenues à partir des PNG 8 bits.

PS : deux autres objectifs sont évoqués dans ce fil, le focus devrait y revenir sous peu :
- L'application de ces techniques à des prises de vues habituelles, avec des instruments d'amateur et dans des conditions de turbulence moyennes et à des prises de vue avec des dégradations simulées d'une image de référence de haute qualité
- L'obtention en temps quasi-réel sur l'écran (à condition de disposer d'une bécane de course avec carte de visu idoine !) d'images "live" de qualité dans des conditions d'observation ordinaires sinon médiocres.

Share this post


Link to post
Share on other sites

Pffffffffff !
Brêle de RTC

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

Share this post


Link to post
Share on other sites
Oui les AVI sont en 8 bits (1 octet par pixel) :
450x1392x1040x1 = 650 Mo pour chaque fichier R, G et B.

Par contre les PNG R, G et B fournis par SW en sortie de recalage sont bien en 16 bits. En les transformant en 8 bits, j'obtiens pratiquement les mêmes courbes 2D FFT (voir post de la page précédente).

L'exemple du Pic est intéressant parce qu'il va montrer l'intérêt de compléter l'implémentation pyramidale du recalage par 'Optical Flow' par un étage de super-résolution.

L'exemple de Marc (que je n'ai pas pu recharger) ou celui de Neb sont intéressants parce qu'ils vont montrer comment les réseaux de neurones (avec apprentissage non supervisé) peuvent être utilisés pour compléter des étages très détériorées par une forte turbulence.

Neb,après Lena :

Share this post


Link to post
Share on other sites
"L'exemple de Marc (que je n'ai pas pu recharger) "

Tu l'auras dans quelques jours...

Share this post


Link to post
Share on other sites
Nous y voilà !

J'ai enfin pu récupérer le film de CP.
Voici maintenant celui de Marc(SER).


Pour une raison inconnue, je ne suis pas arrivé à "upl" le zip entier (1 162 411 ko), donc le voici en multivolume par morceaux de 200 Mo.
En principe en double cliquant sur le dernier, les autres 1, 2, 3, 4, 5 sont automatiquement raboutés en un zip unique

PS : A propos du SER, j'ai vu que PIPP que j'avais utilisé en son temps ne convertissait les SER qu'en 8 bits.
En fait, Ninox fait l'affaire en 8 et 16 bits, au prix d'un recentrage qui me semble incontournable mais utile et qui ne doit en rien dégrader les images.
En fouinant sur le net, pour trouver d'autres convertisseurs d'un film SER en images individuelles, j'ai découvert dans les gratuits un outil intéressant, Siril qui ne tourne qu'avec Linux.


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

Share this post


Link to post
Share on other sites
quote:
En principe en double cliquant sur le dernier, les autres 1, 2, 3, 4, 5 sont automatiquement raboutés en un zip unique

Malheureusement pas sous Linux (j'ai l'impression que ça ne marche qu'avec WinZip sous Windows).

SIRIL c'était fait au départ (dans les années 2005) pour avoir les fonctionnalités d'IRIS sous Linux. Pour les fichiers SER, c'est assez rapide d'écrire un peu de code vu la simplicité des spécifications.

Share this post


Link to post
Share on other sites
"ça ne marche qu'avec WinZip sous Windows"

Peux-tu essayer sur ton émulateur avec la version portable d'Izarc ?

Je vais voir de mon côté avec 7z

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

Share this post


Link to post
Share on other sites
Pas de problème avec IZarc, je récupère un fichier de 1,6 Go (1 631 274 658 octets exactement).

Share this post


Link to post
Share on other sites
OK, c'est bien la taille du SER, on va voir ce que tu vas en tirer
Pour info, je suis de nouveau en débit réduit pour une dizaine de jours.

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

Share this post


Link to post
Share on other sites
Les images sont en 8 bits :
5310 x 640 x 480 x 1 = 1 631 232 000 octets = 1,6 Go

Ces 5310 images contiennent toute l'information mais de façon très fractionnée contrairement aux images du Pic. D'un autre coté, il y a 12 fois plus d'images avec des détails apparaissant dans les trous de turbulence. Le travail de reconnaissance par réseaux de neurones s'apparente au travail du dessinateur qui croque quelques zones dans les trous de turbu, un travail par petites touches plus près de l’impressionnisme que du numérique que la turbulence a rendu myope. D'ailleurs, le rendu final peut être au choix de type photo ou de type dessin suivant la technique utilisée pour fusionner les différentes régions.

Share this post


Link to post
Share on other sites
Mon avis est que c'est le traitement de ce genre d'images avec rendu final photo qui va intéresser un maximum de gens.
Donc wait and see

Share this post


Link to post
Share on other sites
quote:
En fait, Ninox fait l'affaire en 8 et 16 bits, au prix d'un recentrage qui me semble incontournable mais utile et qui ne doit en rien dégrader les images.

En regardant de près la dernière version (3.1.199), je vois que l'on peut maintenant éviter le recentrage avec le paramètre "-cutout=off" ou "-nocutout".
Mais pourquoi se priver de ce recentrage fait selon des nombres de pixels entiers (il me semble qu'il n'est pas toujours très rigoureux) lors de la conversion SER => FITS ?
En continuant mes investigations sur cette version, je constate que le SER de Marc est transformé en FITS 16 bits, avec vraisemblablement les 8 poids faibles à 0.

Je suis en train de tester le morphing2 sur les 500 meilleures (par défaut) images FITS recentrées (curieusement, le recentrage vertical laisse à désirer, à élucider) avec détourage en 448 x 448 (pour fabriquer 14 tuiles 32x32).
Ligne de commande Windaube (à mettre par commodité dans un fichier .bat local plus facilement éditable pour les essais) :

code:

ninox.exe -outdir=morph -morphing=2 -morph-ref=ref0.fit -morph-across=14


Il faut soigner la création de l'image de référence, sinon rien ne se passe, le dossier de sortie "morph" (créé automatiquement) reste désespérément vide

Nota : l'expression " srcdir/" qui apparaît sans explication dans l'exemple de la doc concerne apparemment le chemin des images à traiter pour toutes les fonctions.
En son absence, par défaut, c'est le dossier de travail. Si les images sont dans le sous-dossier "tri500" par exemple, il faut mettre " tri500\" :

code:

ninox.exe -outdir=morph -morphing=2 -morph-ref=ref0.fit -morph-across=14 tri500\

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

Share this post


Link to post
Share on other sites
quote:
Je suis en train de tester le morphing2 sur les 500 meilleures (par défaut) images FITS recentrées (curieusement, le recentrage vertical laisse à désirer, à élucider) avec détourage en 448 x 448 (pour fabriquer 14 tuiles 32x32).

Comment peux-tu voir évoluer un détail si tu casses le lien permettant de passer de la première à la seconde puis à la troisième ... image brute ?
En traitant les images brutes par paquets de 10, tu obtiens 500 images de meilleure qualité qui elles-mêmes peuvent être traitées par paquets de 5 pour donner 100 images recalées.
A comparer en terme de qualité aux 90 images recalées obtenues à partir des 450 images brutes du Pic.
Après sur cette centaine d'images (Marc ou Pic), il ne reste plus qu'à appliquer une des techniques de super résolution pour obtenir l'image haute résolution ou la vidéo haute résolution. Encore que quand le calcul du flot optique devient subpixellique ça limite la super résolution à un simple débruitage et défloutage.
J'ai encore quelques réglages à faire pour améliorer la précision du flot optique ainsi que les temps de traitement. Cela devrait permettre d'améliorer aussi les images recalées du Pic.
Je pense que la fin est proche car l'intuition initiale qui consistait à dire qu'il fallait garder toutes les trames (même les plus pourries) commence à se matérialiser.

code:
ninox.exe -outdir=morph -morphing=2 -morph-ref=ref0.fit -morph-across=14 tri500\


Sous linux, si tu installes tes fichiers FITS sous ~/Images/ninox/tri500 et ton image de référence ref0.fit sous ~/Images/ninox , tu peux taper dans le terminal :
code:
$ cd ~/Images/ninox 
$ ninox -outdir=morph -morphing=2 -morph-ref=ref0.fit -morph-across=14 tri500/

Au préalable les images de tri500 et l'image de référence doivent être créées (tu fais comment pour éviter le répertoire intermédiaire 1 ?).

ninox c'est sympat mais le morphing (on devrait plutôt parler de warping) n'est pas piloté par un flot optique précis et de ce fait on retombe sur les techniques de recalage des autres logiciels astro (AS2, RGX, SIRIL, IRIS, ...), dommage.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this