Traitement planétaire : finesse ou pas finesse ? ( + sondage )

[Nebulium 1 436]

Merci Marc, mais rien d'urgent

Après une cuisine innommable avec des paramètres au pif, je propose ce GIF qui ne casse pas trois pattes à un canard, où la vitesse de rotation est multipliée par 120, en réduction 80% :
.

Dans ce cas le traitement "ms" devrait prendre nettement le dessus !

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

[-ms- 2]

Je poursuis le traitement du flou local avec 14/18 images (les n°2 et 5 n'étaient pas correctement cadrées lors de l’acquisition), il y a déjà une amélioration p/r à la précédente. Pour l'instant les seuls traitements en sortie du recalage sont : un simple masque flou et un dé-bruitage. Le delta restant à corriger se résume aux régions bleues qui se rétrécissent :

La comparaison des 16 images traitées avec l'image de référence donne un PSNR compris entre 39,0 et 40,5 dB :

Il me reste à ajouter encore 3 images pour terminer la série.

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

[-ms- 2]

quote:

---

Et bien OUI il y a des éléments qui bougent de 1 pixel environ. Toutefois je suis souvent sur-échantillonné par construction et ce pixel est au dessous de la résolution des plus fins détails !

---

Quand tu additionnes : le sur-échantillonnage initial, le lucky imaging, le traitement multi-points et la dé-rotation finale, c'est dur de voir évoluer les détails, non ?

quote:

---

Dans ce cas le traitement "ms" devrait prendre nettement le dessus !

---

Suivre l'évolution d'un détail dans une bouillie composée de 250 images consécutives via le flot optique ou même l'analyse en composantes principales, ça me semble une entreprise moins hasardeuse que l'approche actuelle qui multiplie les obstacles.

[patry 1 971]

C'est toujours pareil ms, la dérotation ou le traitement multipoint vont avoir peu ou prou la même action sur des périodes de temps aussi courtes en recalant des zones de l'image.

Le lucky-imaging n'est pas si "lucky" que cela, comme si on introduisait un facteur chance dans le traitement.
Non, il ne faut pas le voir comme cela, mais lors d'une capture, la turbulence, aléatoire je le rappelle, fait que certaines images sont plus perturbées que d'autres.
Le "lucky" en ce sens dit simplement qu'au cours de la capture, on trouve des images meilleures que d'autres. Mais c'est pas de la "chance" c'est de la statistique. Reste à trouver ces images et à les isoler du reste. Découper l'image en zone et rechercher pour chaque zone le meilleur contraste possible c'est assez loin d'être de la magie là encore.

Maintenant on pourrait également prendre une infinité d'images et se rappeler qu'au terme d'un gros traitement logiciel, on retrouvera le signal perdu.

Toutefois, sous une turbulence médiocre on ne trouvera aucune image avec des détail, donc le résultat ne peut pas être bon au final. Le traitement n'apporte rien qui ne soit déjà dans les images initiales. C'est dans ces conditions médiocres que j'attends beaucoup de ton travail en tout cas.

Par contre je ne vois pas pourquoi tu critique la dérotation qui n'est jamais qu'une correction géométrique d'une rotation sphérique projetée sur un plan !
Et suivre un détail qui n'apparaît que fugitivement sur 4 ou 5 images sur 250 me semble à moi bien plus hasardeux (à l'heure actuelle en tout cas, et je fait confiance à ceux comme toi qui ont une nouvelle approche) que de considérer quelques milliers d'images pour retrouver ce même détail a une centaine de reprises.

Sinon bonne nouvelle, j'ai retrouvé le fichier d'origine de mon image, mais je n'ai conservé que les 4800 images d'un SER qui a subi la dérotation. Un traitement vite fait me ressort la même image que postée là. Il y a 470Mo au format 7z en cours de transfert. Le lien sera disponible plus tard dans la matinée.

Marc

[patry 1 971]

Voila le lien vers le fichier : https://drive.google.com/open?id=0B7u4Uyq7qO1iWFRZM0JQZkpPOEU
C'est du format 7z (à l'époque je n'utilisais que cela) et il contient 4800 images, bien meilleures que dans mon précédent fichier.
Le fichier d'origine (SER) a été recentré, recadré et a subi une dérotation pour aboutir à ce nouveau fichier SER qu'il ne reste plus qu'à aligner. La quasi totalité des 4800 images sont exploitables ... la nuit était vraiment bonne cette fois là au C11, c'est rare.

Marc

[Nebulium 1 436]

Hello

quote:

---

C'est dans ces conditions médiocres que j'attends beaucoup de ton travail en tout cas.

---

C'est effectivement après cela que l'on attend tout au long de cette séquence de multiples longs fils qui s'étirent au fil du temps...

quote:

---

Par contre je ne vois pas pourquoi tu critique la dérotation qui n'est jamais qu'une correction géométrique d'une rotation sphérique projetée sur un plan !

---

Au plan théorique, la dérotation qui est essentiellement destinée à améliorer les larges zones périphériques droite et gauche de l'image (pour la zone centrale, elle n'apporte pratiquement rien) n'est pas critiquable.
Mais au niveau du subpixel, malgré le soin apporté aux calculs par Grischa - et on peut lui faire confiance!- il est possible que les rééchantillonnages dénaturent la structure du bruit et induisent une sorte d'intermodulation avec le signal utile qui perturbent les algorithmes de ms.
Je comprends donc son souhait de travailler sur des images brutes parfaitement vierges

quote:

---

Sinon bonne nouvelle, j'ai retrouvé le fichier d'origine de mon image, mais je n'ai conservé que les 4800 images d'un SER qui a subi la dérotation. Un traitement vite fait me ressort la même image que postée là. Il y a 470Mo au format 7z en cours de transfert. Le lien sera disponible plus tard dans la matinée.

---

Parfait, merci
Mais, attention, filtrage !

Cliquer sur la flèche vers le bas en haut d'image.
.

Mais le dnl s'arrête aussitôt car :

Google Drive ne peut pas effectuer l'analyse antivirus de ce fichier

2012-12-11-2042_6-J20121211-204153859_MPa_None_pipp-DeRot.7z (469M) dépasse la taille maximale que Google peut analyser. Voulez-vous vraiment télécharger ce fichier ?

Cliquer sur "Télécharger quand même"

L'objectif pour cette phase est d'obtenir une image de référence de la meilleure qualité possible toutes conditions optimales réunies avec les traitements classiques.

Marc, pourrais-tu rappeler les conditions de prise de vue :
F/D réel et filtrage utilisés, ips, pas pixel caméra, merci

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

[patry 1 971]

C'est pris avec une PLA-Mx (pixel 5,6µm), il y a 4800 images capturées en 80" (exposition 16ms). J'ai appliqué une dérotation sur ces 4800 images (Winjupos) puis un crop (PIPP) afin de réduire drastiquement la taille du fichier (400Mo de gagné, ça compte pour mes sauvegardes).
L'échantillonnage est de 0,11"/pixel (winjupos) ce qui me donne une focale de 10208mm environ soit un F/D de 36 sur le C11.
Pour une fois, ce n'est pas une capture au 23A, mais plutôt avec un L (ou un C que j'ai eu également à ce moment).

Le fichier est en effet trop gros pour subir l'antivirus de Google. C'est pas grave, et je l'ai vérifié en amont.

Marc

[-ms- 2]

18/21 images (3 images mal cadrées).

On peut aussi considérer 14/21 (3 images mal cadrées + 4 images dans des conditions moins bonnes).

Il ne reste plus qu'à supprimer le flou résiduel pour dévoiler cette image déjà très douce.

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

[Nebulium 1 436]

Demain ?

[ValereL 15 378]

Salut les gars,

le résultat maigrichon était prévisible Neb, le but de l'animation n'étant pas de partir de fichiers aussi petits en nombre d'images.
Marc, j'estime que ton traitement est optimal sur ta dernière jupiter postée, pas la peine d'en remettre une couche avec un autre essai ! Je laisse la main.

[-ms- 2]

480 premières trames permettant de fabriquer 2 images corrigées que j'empile :

A comparer par la suite à : 4800 trames consécutives permettant de fabriquer 20 images corrigées.

[Nebulium 1 436]

quote:

---

Il ne reste plus qu'à supprimer le flou résiduel pour dévoiler cette image déjà très douce

---

Hé, ms, tu te f....s de nous ?
Ne te disperse pas, il faudrait voir à pas changer d'image avant d'avoir montré ton résultat sur l'autre que l'on attend depuis des mois, et ne nous fais plus le coup de ta dropbox, stp, ton message a été flashé ! !

Et en plus, mon avis est que ton dernier exploit manque de naturel...

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

[patry 1 971]

ms> Si je peux me permettre, c'est assez nettement moins bon (à la fois plus granuleux et moins fin et contrasté) que ma version quand même.
Il n'y a clairement pas assez d'images dans ton flot c'est évident, mais pour autant, c'est très bien pour servir "d'image de référence" pour la suite du traitement. Surtout avec aussi peu d'images utilisées.
Cette opération (d'image de référence) je ne la maîtrise pas du tout dans autostakkert sauf à faire un premier traitement et à le réutiliser comme image de référence pour recommencer.

Y'a pas, quand les conditions sont bonnes, on en voit des trucs sur seulement 48" d'arc avec un C11 ! Dans le flux, la quasi totalité des 4800 images peuvent être exploitées, ça aide.

Marc

[-ms- 2]

Pour de la vidéo assistée ce niveau de rendu me convient très bien, il faut imaginer l'observateur qui toutes les 2,4 secondes va pouvoir suivre l'évolution de la planète. A la fin de son observation ce sont des dizaines d'images de cette qualité qu'il va pouvoir empiler (le système calcule des images intermédiaires pour fluidifier la vidéo mais il ne les stocke pas, les autres images sont conservées pour être empilées ultérieurement).

Neb, les différents processus (Pic, Marc et autres) concourent pour obtenir le même niveau de rendu. Pour certains c'est assez rapide et pour d'autres c'est un peu plus lent.

[Nebulium 1 436]

quote:

---

les différents processus (Pic, Marc et autres) concourent pour obtenir le même niveau de rendu.

---

Ayé, tu jettes l'éponge pour la super-résolution !

Alors on se contentera de l'appli vidéo, si elle n'exige pas un CrayOne, tu n'auras pas bossé des mois pour rien !

[patry 1 971]

neb> Rhooo tu est taquin, le parcours n'est pas facile et je pense que tous les moyens sont bons pour juger de la qualité d'une image.

ms> ok pour du visuel assisté mais au niveau macroscopique, les images dans l'intervalle [0,2s] dont on extrait une image à partir de 160 images, peut être assez nettement moins bien (à cause de 150/160 images) que celles de la période [T,T+2] grâce peut être à 150 sur les 160 images (trou de turbulence).
Du coup au compositage final, on risque de donner le même "poids" pour une image dans la tranche de temps [0,2s] (mauvais lot) qu'une autre image dans la tranche de temps [T,T+2s] (bon lot).
Pire on pourrait rejeter une très bonne image et conserver une image médiocre. Sans une analyse globale c'est difficile de se prononcer sur ce qu'est une bonne image je pense.

L'approche de firecapture est plutôt pas mal je pense ; les images sont toutes capturées mais une analyse de contraste permet d'en rejeter une partie qui sont décidément trop mauvaises. Cela rejoint un peu ce que tu veux faire je pense. On consomme un peu de CPU (mais c'est rarement ce qui manque) et on économise de la bande passante de disque ET de la place disque ce qui est loin d'être négligeable.
Je ne sais pas si Firecapture gère l'horodatage des trames dans un fichier SER, et si cet horodatage est utilisé pour une dérotation dans WinJupos mais c'est à mon sens une bonne approche.
Cela marche à une cadence de 20i/s sur Jupiter avec un core 2 duo, incomparablement moins performant qu'un i3 ou à fortiori i5/i7 actuel, avec un réglage faible pour conserver éventuellement des images partiellement bonnes qui seront conservées en multi-point.

Marc

[Nebulium 1 436]

Personnellement, je dirais que cette image N&B par la sonde New Horizons me semble une bonne photo, ce sera mon objectif de rendu pour le film L de Marc, car pour les conditions de prise de de vue j'ai trouvé ceci :
LORRI, the “eagle eyes” of New Horizons, is a panchromatic high-magnification imager, consisting of a telescope with an 8.2-inch (20.8-centimeter) aperture that focuses visible light onto a charge-coupled device (CCD). It’s essentially a digital camera with a large telephoto telescope – only fortified to operate in the cold, hostile environs near Pluto.

[Edit]Plus de détails ici :
LORRI is a narrow angle (field of
view=0.29°), high resolution (4.95 µrad pixels), Ritchey-Chrétien telescope with a 20.8 cm
diameter primary mirror, a focal length of 263 cm, and a three lens field-flattening assembly. A
1024 × 1024 pixel (optically active region), thinned, backside-illuminated charge-coupled device
detector is used in the focal plane unit and is operated in frame transfer mode. LORRI provides
panchromatic imaging over a bandpass that extends approximately from 350 nm to 850 nm.

Ce serait donc du vrai N&B comme au bon temps !
.

Credit : NASA/John Hopkins University Applied Physics Laboratory/ Southwest Research Institute

Voir aussi cette page

Un plus grand choix sur le site, rechercher "Jupiter", voir p 3.

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

[-ms- 2]

quote:

---

Ayé, tu jettes l'éponge pour la super-résolution !

---

La super résolution c'est pas un problème, tu peux créer ce type de module en une journée avec OpenCV 2.4 ou 3.1 par exemple. Le problème c'est ce que tu vas lui donner à manger en entrée et c'est pour cela que je soigne la vidéo.

quote:

---

Du coup au compositage final, on risque de donner le même "poids" pour une image dans la tranche de temps [0,2s] (mauvais lot) qu'une autre image dans la tranche de temps [T,T+2s] (bon lot).

---

Non parce que les images qui sortent de la plage de PSNR ne sont pas prises en compte par la super résolution.

[Nebulium 1 436]

quote:

---

La super résolution c'est pas un problème, tu peux créer ce type de module en une journée avec OpenCV 2.4 ou 3.1 par exemple

---

.

Pas moi, en tous cas !

et par toi, on attend toujours

quote:

---

Le problème c'est ce que tu vas lui donner à manger en entrée

---

Héhé
Retour à a case départ !

[patry 1 971]

ms> et comment defini-tu la plage valide de psnr ?
Parce que tout le problème est là je crois.

L'image L du JPL est superbe avec un 8 pouces ... mais bon ils se sont un peu approché aussi et n'ont pas de soucis de seeing. Du coup ça ne compte pas !

[-ms- 2]

Le programme de super résolution "connaît" la courbe de PSNR de toute la vidéo (la vidéo peut durer plusieurs minutes). Comme il ne travaille pas en temps réel, il peut reconstruire une image haute-résolution en tenant compte de données de qualité variable. Le problème, il est plus en amont quand il faut déterminer le nombre d'images nécessaires pour produire une vidéo fidèle, c'est d'ailleurs le seul paramètre important.

[patry 1 971]

heuuu, tu a besoin de toute la vidéo pour déterminer le PSNR,et tu a besoin du PSNR pour déterminer les images à conserver dans le flux temps réel.
Ça va être coton c't'histoire !

[-ms- 2]

Dans le flux temps réel, je traite un premier paquet d'images qui va me permettre d'initialiser le paquet suivant en fonction de la turbulence, les paquets successifs peuvent avoir des tailles différentes. C'est l'image qui est au centre du paquet qui m'intéresse parce que je peux savoir ce qui se passe avant et après cette image, cette image est conservée dans la vidéo.

[ValereL 15 378]

Salut ms, pareil que Marc, c'est beaucoup moins bon et la texture me semble zarbie. L'image me semble dénaturée avec des détails qui semblent provenir de calculs hasardeux, enfin bref ça va dans le sens de ce que te disait Brizhel pour moi.

[-ms- 2]

Oui le problème de texture est lié au traitement du flou local qui donne pour l'instant un résultat plutôt merdique. En supprimant ce traitement j'obtiens ceci :