Le film "Saturne du 6 août" (2017) par Polo retraité avec un réseau de neurones convolutifs

[Nebulium 459]

Il y a 12 heures, ms a dit :

Je trouve le premier plus intéressant

 

Hello

 

 

Tu veux parler du premier essai avec le "Restoration" de Dmitry, réglages  monochrome "Barbara" donc couche par couche pour la RVB, évoqué ici  ?

 

Sauf erreur, j'avais obtenu cette image :

 

 

Depuis, je me suis fait un peu la main avec RGX6, je vais la retravailler avec ses ondelettes pour  comparer avec les sorties  "super-résolues".

 

En tout état de cause ma conviction maintenant est que les résultats obtenus à partir d'originaux floutés par  filtrage gaussien ou autres (pour permettre de faire des mesures de qualité genre PNSR) sont bien plus flatteurs que ceux  obtenus à partir de nos images naturellement floues.

Une simple affaire de détails ... subsistant faiblements dans un cas, inexistants dans l'autre !

 

....

 

Alors voilà, un passage aux ondelettes, façon SW  :

 

 

Sûr que ça pique et artefacte !

Les déformations se voient, je pourrais essayer de passer avant empilement  les 16 images de départ au "morphing" de Ninox des fois qu'il s’avérerait plus efficace que celui de AS !  , et refaire toute la procédure...

 

En ce moment  je mouline l'image restaurée ci-dessus au 'deepimg', en x2 (une grosse heure avec la GPU à 100%), puis elle passera au RGX...

 

 

 

Edited February 24 by Nebulium

[ms 301]

Citation

Tu veux parler du premier essai avec le "Restoration" de Dmitry, réglages  monochrome "Barbara" donc couche par couche pour la RVB, évoqué ici  ?

Non, de la toute première Saturne, en monochrome.

Pour celle de polo, il faut extraire tous les patchs qui ont une qualité suffisante puis tenir compte des similarités et enfin terminer par l'inpainting s'il reste des trous.

Pour ce dernier point le "Deep Image Prior" semble donner de bons résultats.

Pour le premier point, il faut encore creuser.

[Nebulium 459]

il y a une heure, ms a dit :

Non, de la toute première Saturne, en monochrome

 

Oui, on est bien d'accord :

Cette Saturne est issue de la HST que j'ai convertie en N&B, et que j'ai renommée "barbara.png",  monochrome à utiliser dans l'application  'restoration.ipynb' que j'ai finalement préférée à la  'denoising.ipynb' .

 

 

En  y choisissant l'option 'kate' pour traiter en couleur  la 'satpol16_bal_al.tif', j'ai eu des plantages qu'il faudrait que je revoie d'ailleurs maintenant que je maîtrise mieux les *.ipynb. Il faut dire que la sauvegarde automatique exécutée par  'Jupyter' est chiante, malgré plusieurs  visites chez StackOverFlow  & Cie, je n'ai pu l'inhiber.

Du coup, j'ai traité la 'satpol16_bal_al.tif'' couche par couche en option monochrome 'barbara', ce qui me semble pour l'instant la meilleure piste pour mon idée de base.

Il faut encore que j'arrive à bidouiller le 'restoration.ipynb' pour y éliminer une normalisation qui me casse la balance de la 'satpol16_bal_al.tif' et trouver comment sauver directement sous ipython le résultat en dimensions d'origine.

 

Je viens de passer au RGX6 le résultat de l'application SR en x2 de l'image restaurée, rien pu sortir de correct, je la publie ci-dessous telle qu'issue du 'deepimg' :

 

 

Dernier truc à regarder avec mes moyens limités pour être complet le morphing de Ninox.

 

Edited February 24 by Nebulium

[ms 301]

En appliquant les 2 étapes définies précédemment (meilleurs patchs + similarités) :

[Nebulium 459]

Ouais, ça progresse bien de ton côté !

 

Tu n'aurais pas vu l'appli 'Restoration'  en Tensorflow, quelque part ?

 

 

il y a 17 minutes, ms a dit :

meilleurs patchs

 

Et combien d'images empilées pour fabriquer ces meilleurs patches ?

[ms 301]

Citation

En tout état de cause ma conviction maintenant est que les résultats obtenus à partir d'originaux floutés par  filtrage gaussien ou autres (pour permettre de faire des mesures de qualité genre PNSR) sont bien plus flatteurs que ceux  obtenus à partir de nos images naturellement floues.

Une simple affaire de détails ... subsistant faiblements dans un cas, inexistants dans l'autre !

C'est pour cela qu'il vaut mieux utiliser des modèles obtenus à partir de situations plus proches de la réalité :

 

Dans chaque image, on peut extraire les meilleurs patchs pour les réassembler par la suite. S'il n'y a pas assez de patchs, on peut toujours faire appel à l'inpainting (Deep Image Prior ou autre algorithme). Le phénomène qui cisaille la cheminée est un des plus destructeur, on le retrouve sur Jupiter en ce moment, il y a aussi le flou local qui ne peut être traité qu'au niveau du patch et non de l'image globale, etc ...

La sélection des meilleurs patchs permet de remonter à la texture après déconvolution aveugle :

 

Citation

Et combien d'images empilées pour fabriquer ces meilleurs patches ?

Dans le cas de la vidéo de Saturne de polo, j'ai pu extraire des patchs à partir de 19090 images brutes sur 21204 images au total soit 90% des images brutes utilisées.

Il me reste encore à déterminer l'image d'accroche dont la qualité sera définie par l'algorithme BRISQUE (de type No Reference Image Quality), chez polo j'ai choisi la première image brute de chaque série de 150 mais ce n'est pas top. Ici l'image d'accroche est enrichie des patchs extraits des images brutes suivantes :

 

Prochaine étape : appliquer un algo NRIQ aux images de polo puis essayer de remonter à la texture comme ci-dessus.
Enfin passer à Jupiter sur le terrain, ça turbule pas mal en ce moment mais même avec 10% des images brutes, il doit être possible de reconstruire une image (meilleurs patchs + similarités + inpainting).

 

Citation

Tu n'aurais pas vu l'appli 'Restoration'  en Tensorflow, quelque part ?

Je n'utilise que l'inpainting et encore uniquement si j'ai des trous dans l'image finale . J'ai adapté le modèle présenté par iyhaoo à mon environnement Linux/ArrayFire/C++ (pour obtenir des performances correctes, il faut au moins 4Go de mémoire graphique comme sur la GTX 1050 Ti mais déjà se profile la GTX 1660 Ti avec ses 6Go de mémoire graphique ) :

https://github.com/iyhaoo/deep-image-prior-tensorflow

 

Edited February 26 by ms

[Nebulium 459]

Il y a 8 heures, ms a dit :

des modèles obtenus à partir de situations plus proches de la réalité :

 

Oui, tu es plus convaincant quand tu noies ce genre de poisson !

 

Il y a 8 heures, ms a dit :

19090 images brutes

 

C'est certain qu'avec 16 images, ça ne fait pas le poids.

Encore que :

 

 

Maintenant,  je peux en utiliser plus, mais je voulais expérimenter sur un minimum, d'abord 1 puis 16,  disons 64 pour la prochaine fois.

Je vais quand même voir auparavant ce que donne le morphing de Ninox avant l'empilement par AS! qui ici n'a pas géré au mieux les déformations des "lucky" images.

L'ami Arthur écrit :

" Level 2 is align + distort where each frame is first aligned and then distorted so that all the major features of the frame align perfectly with the reference frame."

 

Il y a 8 heures, ms a dit :

Je n'utilise que l'inpainting

 

Merci pour le lien

 

Mais avec mon idée, je n'ai pas de trous à boucher, la "super-resolution"  m'a déçu, à  moins que je l'aie mal utilisée.et c'est finalement la "restoration"  disponible uniquement en 'pytorch' qui m'a donné les meilleurs résultats.

 

Par ailleurs, j'ai des problèmes d'incompatibilité de versions GPU simultanées entre 'tensorflow', 'pytorch'   et 'cuda 9.x , non résolus même avec des environnements différents pour 'python', cette affaire est vraiment merdique, je vais donc me remettre avec 'pytorch' seul dans une configuration basique unique.

Edited February 26 by Nebulium

[ms 301]

Avec des paquets de 300 images brutes et une sélection par l'algorithme BRISQUE, j'obtiens ceci (c'est un peu moins terne que la précédente) :

 

 

Je vais faire un apprentissage sur des images planétaires pour améliorer la sélection.

 

Citation

Par ailleurs, j'ai des problèmes d'incompatibilité de versions GPU simultanées entre 'tensorflow', 'pytorch'   et 'cuda 9.x , non résolus même avec des environnements différents pour 'python', cette affaire est vraiment merdique, je vais donc me remettre avec 'pytorch' seul dans une configuration basique unique.

Je suis en train de faire un montage Raspberry Pi3 B+ et Intel NCS2 (Neural Compute Stick 2) pour justement détecter les bonnes trames à partir d'un apprentissage préalable.

 

Edited February 26 by ms

[Nebulium 459]

Il y a 2 heures, ms a dit :

j'obtiens ceci

 

Cassini n'est pas très piquée, mais le contraste des bandes sur le globe est intéressant.

 

Il y a 2 heures, ms a dit :

sélection par l'algorithme BRISQUE

 

Un peu plus fûté  que le  PSNR ? mais il me semble que lui aussi a besoin d'une référence ?

 

score = brisque(A) calculates the no-reference image quality score for image A using the Blind/Referenceless Image Spatial Quality Evaluator (BRISQUE). brisque compare A to a default model computed from images of natural scenes with similar distortions. A smaller score indicates better perceptual quality.

 

Faut'il comprendre que l'on se fabrique d'abord un modèle de manière classique que l'on bidouille au mieux ou alternativement, que l'on part par exemple ici de la HST ou de l'image JLD du Pic adaptées, et qu' ensuite on trie les brutes selon le score et on refait le traitement classique ?

Edited February 26 by Nebulium

[CPI-Z 106]

 

Il y a 11 heures, ms a dit :

C'est pour cela qu'il vaut mieux utiliser des modèles obtenus à partir de situations plus proches de la réalité :

MS perso je trouve cet exemple pas très représentatif de la réalité car sur chaque image turbulente il y a toujours des points nets. Le mouvement est lui représentatif de la réalité mais pas l’absence de netteté locale. La réalité est donc encore plus compliquée. Est-ce alors encore possible de résoudre l'image dans cette simulation ?

[ms 301]

Citation

Le mouvement est lui représentatif de la réalité mais pas l’absence de netteté locale.

Le détail montre qu'une homographie locale permet de reconstruire l'image par morceaux. Un patch ne représente qu'une surface de 8x8 ou 16x16 pixels mais le détail obtenu par assemblage des patchs est bien plus important 618x468. Pour une planète, on peut disposer de 120.000 images brutes et non 12 comme dans l'exemple sous-marin.

 

Citation

Cassini n'est pas très piquée, mais le contraste des bandes sur le globe est intéressant.

 

 

Citation

Qu'a-t'il de plus intéressant que le  PSNR, il me semble que lui aussi a besoin d'une référence ?

Pas de référence nécessaire mais un apprentissage du domaine.

https://github.com/FlyingRhenquest/No-Reference-Image-Quality-Assessment-using-BRISQUE-Model

 

Edited February 26 by ms

[Nebulium 459]

 

 

Il y a 21 heures, ms a dit :

Pas de référence nécessaire mais un apprentissage du domaine.

https://github.com/FlyingRhenquest/No-Reference-Image-Quality-Assessment-using-BRISQUE-Model

 

Ce lien  est hors de portée pour moi, mais j'ai vu plus abordable ailleurs.

Le concept est intéressant, j'ai vu qu'il en  existait une version 'Python'

 

Edited February 27 by Nebulium

[ms 301]

Citation

score = brisque(A) calculates the no-reference image quality score for image A using the Blind/Referenceless Image Spatial Quality Evaluator (BRISQUE). brisque compare A to a default model computed from images of natural scenes with similar distortions. A smaller score indicates better perceptual quality.

Faut'il comprendre que l'on se fabrique d'abord un modèle de manière classique que l'on bidouille au mieux ou alternativement, que l'on part par exemple ici de la HST ou de l'image JLD du Pic adaptées, et qu' ensuite on trie les brutes selon le score et on refait le traitement classique ?

Tout dépend de ce que l'on cherche à faire : tester une image brute (mon post précédent) ou une image traitée (ce post), il faut adapter l'apprentissage en conséquence.

Ici j'utilise les 21204 images brutes en formant 70 paquets de 300 images, BRISQUE m'indique que je peux  empiler les 70 images pour obtenir l'image suivante :

Edited February 27 by ms

[Nebulium 459]

Il y a 10 heures, ms a dit :

l'image suivante

 

Sa cotation "BRISQUE " ?

 

Et celle de cette image :

 

[ms 301]

Et celle de celle-là :

 

[Nebulium 459]

Hum, rien de nouveau autour du Soleil, déjà l'an dernier :

 

 

Apprentissage rime avec clonage, retour aux sources, et la suite.

[ms 301]

Cette image est très improbable à partir de 21.000 images brutes parce qu'il n'y a pas assez de "bons patchs".

A vérifier donc avec 10 fois plus d'images brutes (15x60x233=210.000) puis en utilisant les similarités dans l'image et enfin l'inpainting s'il reste des trous.

Une image comme celle de droite me semble plus probable en laissant tourner le temps nécessaire :

 

 

Edited February 28 by ms

[Nebulium 459]

L'image de droite serait assez plaisante, mais quelle part de la Saturne JLD du Pic et/ou de la HST contient-elle ?

De mon côté, je finis de creuser mon idée minimaliste = tirer un max de peu de "lucky" images en exploitant le "morphing", qui chez AW  procède basiquement   avec ses tuiles de la même démarche que tes patches.

[ms 301]

L'image de droite est obtenue à partir d'un complément d'images brutes "simulées", reste à valider cela avec de vrais images brutes sur le terrain.

 

Par contre l'image qui ressemble à celle du Pic résulte de la manipulation suivante qui n'a pas un grand intérêt :

 

Citation

De mon côté, je finis de creuser mon idée minimaliste = tirer un max de peu de "lucky" images en exploitant le "morphing", qui chez AW  procède basiquement   avec ses tuiles de la même démarche que tes patches.

Si dans 16 images, tu as 80% de "bons patchs" alors tu peux compléter les 20% manquants avec l'inpainting.

Cependant dans une image qui globalement semble "pourrie", tu as souvent quelques "bons patchs" d'où l'intérêt de travailler avec toutes les images brutes :

Ici la cheminée est pourrie mais la pelle, l'ancre, une fenêtre et une partie du requin sont exploitables en terme de patchs. Sur d'autres images une partie de la cheminée peut aussi être exploitable. Bref ce n'est que localement que l'on peut aligner des images brutes après avoir reconstitué quelques zones à partir de "bons patchs". 
Les patchs de moins bonne qualité peuvent être remplacés par des patchs similaires (fractales) de meilleure qualité.
Au final, tu obtiens une image nette avec parfois quelques trous que l'inpainting viendra combler.

 

 

Edited February 28 by ms

[Nebulium 459]

On ne sait plus trop qui est qui et depuis quoi et comment ...

 

Bon, alors voici un empilement AS!3 des 12 (j'en ai jeté 4 par couche pas trop belles ) meilleures "lucky" du film original, passées au morphing (patches  de  32x32)  couche par couche, aligné RGX et balancé.

Voir maintenant ce que l'on peut en tirer de mieux :

 

 

 

Edited March 1 by Nebulium

[ms 301]

Avec tes 16 images, j'ai pas mieux que cela  (centroïde + similarités) :

 

[Nebulium 459]

Ouais, c'est prometteur, mais il faudrait voir maintenant à faire la balance, la couche bleue est faible et bruitée et donc polluera  pas mal la version équilibrée.

Tiens, voici les gifs de la couche R après et avant le morphing :

Ce n'est pas encore le pied pour les déformations, mais ça a pu faciliter le travail pour AS!

 

 

 

Nota : les images "avant" ont déjà été recentrées par PIPP lors de l'extraction classée en qualité depuis le SER original.

Edited February 28 by Nebulium

[ms 301]

Effectivement, il est possible de dé-bruiter la couche bleu (image de droite) lors de l'alignement des couches ou mieux lors de l'ADC logiciel :

 

Citation

 

Tiens, voici les gifs de la couche R après et avant le morphing :

Ce n'est pas encore le pied pour les déformations, mais ça a pu faciliter le travail pour AS!

 

AS ! est dans les choux dans ce type de configuration, je pense que la méthode du centroïde est plus rapide (une fraction de seconde avec CUDA) et surtout plus précise :

 

Pourquoi ne traites-tu pas directement les images brutes RGB ?

 

Edited March 1 by ms

[Nebulium 459]

Il y a 10 heures, ms a dit :

AS ! est dans les choux dans ce type de configuration

 

Je pense que les AP de AS! réalisent en fait une sorte de morphing.

 

"la méthode du centroïde est plus rapide (une fraction de seconde avec CUDA) et surtout plus précise"

 

Oui, c'est évident sur ton exemple, et on la trouverait  où cette méthode,, exécutable en Python ou similaire ?

 

 

 

Il y a 10 heures, ms a dit :

Pourquoi ne traites-tu pas directement les images brutes RGB ?

 

Ninox ne morphisant  que des images monochromes je suis obligé de lui fournir les couches une par une (en BMP) . 

Par ailleurs, à la différence de AS! ou RGX, il utilise une image de référence (= empilement préliminaire légèrement accentué) et travaille sur une mosaïque de tuiles  carrées en nombre  paramétrable.

Ci-dessus les tuiles faisaient 32x32, voici un essai en 8x8 :

 

 

Il m'a l'air plus précis .

 

Je vais essayer  le double morphing :

 

 

Hum, pas très propre, non ?

 

Et  finalement, avec lequel refaire l'empilement RGB ? ?

 

Mis à part le passage par le morphing, je travaille  normalement sur les RGB en vérifiant l'alignement avec RGX.

Je vais devoir réinstaller l'appli originale de Dimitry ( + Pytorch) qui marchait bien avec l'usine à gaz Anaconda  car elle plante maintenant (la faute à Jupyter ?) sous l'installation simple Python 3.6 + pip/pip3  bien que j'aie en principe  trouvé les bonnes compatibilités, ceci pour revoir pourquoi sa 'restoration' plante en RGB ('Kate'), sinon  je resterai en monochrome avec 'Barbara' pour finaliser l'intérêt du morphing d'Arthur.

 

 

Edited March 1 by Nebulium

[ms 301]

Citation

Oui, c'est évident sur ton exemple, et on la trouverait  où cette méthode,, exécutable en Python ou similaire ?

Cette méthode est détaillée ici :

https://www.researchgate.net/publication/227172988_The_Centroid_Method_for_Imaging_through_Turbulence

J'en ai fait une version C/CUDA que j'utilise en post-traitement des images de la vidéo assistée.