-ms-

J'ai repris la même que toi : Avec EVA en multiframe je me rapproche de cet aspect après réduction de mon image super résolue x4.

En faisant un apprentissage sur une seule image (c'est insuffisant bien sûr) avec un réseau analogue au DCGAN ci-dessus, j'obtiens le résultat suivant : Avec EVA cela devrait être intéressant car la super résolution se fera en multiframe. En blanc l'image de référence.

Tu veux pas essayer de dé-bruiter et de recaler tes 14 poses de 45s avant de te lancer dans les dépenses ? A mon avis, tu as déjà de quoi faire avec un Nexstar Evolution. Si le traitement te pose un problème et si tu as encore les 14 poses, tu peux les mettre sur le forum. Vérifies aussi que sur chaque pose les étoiles ne soient pas trop ovalisées.

Tu veux dire est-ce que je dépense 1199 euros pour une monture équatoriale plutôt que 399 euros pour une table équatoriale adaptée au Nexstar Evolution pour un résultat pas meilleurs ? Cette table équatoriale a une capacité de charge de 16kg pour un poids de 7kg ce qui est déjà pas mal.

fr = w * cos(lat) * cos(az) / cos(hau) avec : fr = la vitesse angulaire de rotation de champ pour l'objet observé w = la rotation angulaire de la Terre (15,04 degrés par heure) lat = la latitude de l'observateur az = l'azimut local de l'objet observé hau = la hauteur locale de l'objet observé Tu y vois qu'il n'y a pas de problème quand l'objet est à l'est ou à l'ouest. Tu y vois que ça se gâte quand l'objet approche de 90° en hauteur. Tu sais aussi qu'un objet est plus intéressant à photographier quand il est le plus haut dans le ciel c'est à dire quand il passe au méridien (sud) d'où l'intérêt d'un dérotateur ou d'une monture équatoriale ou d'une table équatoriale (dans ton cas) pour la photo : Pour les poses, tu peux te limiter à 30s puis utiliser la commande rregister d'IRIS.

En utilisant la carte graphique tu obtiendras en gros un gain de 30 à 40 sur le calcul matriciel donc tu vas descendre à moins de 2mn ce qui est bien mais encore loin du temps réel. Quand TensorFlow sera intégré au silicium, là on pourra certainement l'utiliser pour les différents algorithmes mais on sait déjà que le traitement des images naturelles sera moins bon qu'avec d'autres méthodes utilisées aujourd'hui. Par contre pour des images fabriquées artificiellement c'est le contraire. Ce qui est positif par contre c'est de mettre les mains dans le cambouis et comme tu dis la fête ne fait que commencer. A partir de juin 2018, je vais retravailler avec TensorFlow sur les vidéos obtenues avec EVA. EVA permet de fabriquer à partir d'images naturelles (les images brutes), des images artificielles (les images de la vidéo assistée) qui se prêteront bien à des traitements avec TensorFlow. Pour revenir à ton image du milieu qui est loin d'être inintéressante. Ton réseau a pris les tonalités de l'image de droite, il faut lui apprendre à prendre la résolution de cette image, c'est toute la difficulté de l'apprentissage profond. Tu veux lui apprendre à booster les hautes fréquence à partir d'un apprentissage automatique comme le fait par exemple le réseau DCGANN de Qiaojing Yan et Wei Wang : http://stanford.edu/class/ee367/Winter2017/yan_wang_ee367_win17_report.pdf EVA utilise les algorithmes "traditionnels" pour estimer le bruit et le flou des images naturelles par contre l'apprentissage profond est utilisé pour traiter par super résolution les vidéos assistées. La super résolution booste les hautes fréquences comme avec DCGANN implémenté ici en Python avec TensorFlow (j'ai un modèle analogue implémenté en C++ qui sera dispo en juin sur mon site internet) : Tu peux trouver le détail : https://github.com/carpedm20/DCGAN-tensorflow PS : il faut laisser causer ceux qui critiquent plus vite que leur ombre comme Valère et quelques autres pour continuer à tracer son sillon comme tu le fais.

J'ai actuellement une batterie 12V 100Ah et un convertisseur pur sinus., la batterie est déchargée à 50%. En mode calcul, CPU (65W) et GPU (55W) sont pratiquement utilisés à 100% d'où la puissance nécessaire sur le terrain. Avec une puissance de 120W (65+55) : 120W / 12V = 10A 50% x 100Ah / 10A = 5h (mon convertisseur à un rendement proche de 100%). Avec un système qui donne la puissance CPU+GPU ci-dessus avec une consommation de 60W au lieu de 120W, l'autonomie atteint 10h (cette solution existe déjà chez Intel et elle sera dispo en mars 2018 dans un boîtier de 1,2litres). Malgré cela, je vais rester sur la solution Shuttle de 3litres qui est robuste et plus raisonnable, elle supporte aussi les SSD M.2 PCIe NVMe comme le Samsung SSD 960 Pro de 512 Go.

Oui, tout cela devrait encore s'améliorer quand toute la chaîne sera traitée sur le terrain par EVA.

La vidéos stabilisées en MP4 (152ko) : stabilized.mp4 stabilized1.mp4

Les modules sont écrits en C/C++ et vont être embarqués prochainement dans le prototype ci-dessous (le CPU reste encore à définir entre i5-7500T 35W et i5-7500 65W mais plus puissant). Le matériel est dispo chez LDLC qui peut assurer le montage et chez Amazon.fr (prix global de 1000euros hors écran). Le proto n'est pas la version définitive qui elle utilisera un processeur Intel ou AMD intégrant un GPU aussi puissant que celui du proto, le prix global sera de l'ordre de 500euros hors écran. J'ai prévu de faire des rafales de tailles variables afin d'avoir une qualité d'image constante pour une vidéo donnée. Cela est maintenant possible parce que je contrôle mieux l'estimation du bruit et celle du flou. Ce système sera testé sur les 3 oppositions à venir.

C'est peut-être hors sujet mais un exemple de produit (parmi d'autres) dont je me suis occupé il y a quelques années, c'est plusieurs dizaines de milliers de lignes de code C et c'est fait entièrement avec les outils de l'environnement Unix évoqués plus haut. Sans une approche méthodologique, pour ce type de produit, tu ne passes pas le barrage US de la FDA. Bonjour aussi les problèmes de hard en environnement IRM (champ magnétique important). http://www.schiller.ch/fr/fr/product/maglife-serenity

C'est pas à ce niveau là qu'il faut dé-bruiter cette vidéo de 87 images mais je n'ai pas le choix : Tout cela préfigure ce que vous allez voir dans quelques mois avec les oppositions de Jupiter, Saturne et Mars sauf qu'avec EVA tout cela se fait en temps réel sur le terrain le temps de boire une bonne tasse de café.

J'ai fait rapidement un petit programme qui égalise et dé-floute à l'aveugle, il faudrait encore dé-bruiter pour que ce soit plus propre, je ferais un essai plus tard :

Ben non, une bonne méthodologie vaut tous les outils de la Terre. Avant de coder, tu as des phases d'analyse, de conception préliminaire puis détaillée. Quand tu codes, il ne faut pas oublier de faire les tests unitaires puis d'intégration. Quand tu as des dizaines de milliers de lignes, tu as des outils pour gérer cela. Beaucoup de gens ne font pas la différence entre la méthode et les outils, ce n'est pas parce que tu as un environnement de développement intégré (IDE) ou un atelier de génie logiciel (AGL) que ton approche sera méthodologique. Les debuggers, profilers, gestionnaires de version, de documentation, etc ... ne sont que des outils. Tu ferais mieux d'apprendre à te servir de gcc, g++, make, gdb, gprof, git, etc ... si tu veux progresser dans l'environnement Unix.

C'est pas nécessaire d'avoir une usine à gaz pour développer en langage C/C++ quand un éditeur (vim, emacs ou leurs versions simplifiées) et l'environnement d'Unix suffisent. L'intérêt d'Unix pour un développeur c'est que tous les outils sont déjà dedans mais cela demande un peu d'apprentissage. Il y a une expression qui dit : prendre un marteau-pilon pour écraser une mouche.

Moi je préfère (pour une photo) au rapport signal sur bruit, le rapport signal sur émotion.

Est-ce que tu as essayé de traiter le problème à différentes échelles ? Essayes de construire un MS RNLF (Multi Scale RNLF). L'autre point c'est de travailler avec une rafale d'images brutes et non avec une seule image.

J'aime bien ces images jpeg où l'on peut réduire différents types de bruit en une passe (y compris les artefacts liés à la compression) : Pour NGC2903 ce serait mieux de dé-bruiter chacunes des 7 poses de 15s avant de les empiler (de ce fait, je suis obligé de faire 2 passes, ce qui est pas top), pour du visuel assisté ce type d'image me convient très bien :

Windows c'est tout bon pour ceux qui adorent passer à la caisse si ça c'est pas un TOC. Sous Windows, il y a aussi matplotlib et PyQwt qui fonctionnent bien, il faut chercher ce qui fonctionne le mieux dans les 3 environnements. Sous Linux c'est sûr que gnuplot est pratiquement utilisé par tous.

On devine la licorne, c'est un plaisir à regarder.

Il n'y a pas que l'optimisation fiscale qui est à la mode, elle touche aussi la quasi totalité des processeurs d'Intel et même ceux qui ont plus de 20 ans. Après, il faut savoir de quelle faille on parle parce que sur les 2, il y en a une qui est plus problématique que l'autre et qui ne touche pas qu'Intel. Cette affaire là est loin d'être terminée.

C'est la question qui s'était posée sur un autre post : Je pense qu'il est possible de se passer de tous ces traitements sous certaines conditions. Ici le temps de pose est de 20s et on observe quelques résidus mais à 10s, il doit en rester moins et à 1/100s rien du tout. Avec EVA l'essentiel des observations se fait en altaz de 1/100s à 10s sans offsets, darks, flats et avec un ADC logiciel quand l'objet est trop bas (j'ai vu dernièrement sur ce forum une image de M1 faites avec des poses de 1s à l'ASI224, il me semble que c'est une bonne approche mais elle doit être automatisée pour ne pas durer une éternité ). Au delà de 10s, je pense qu'il faut entrer des master darks, flats, ... L'avenir ce sont des capteurs et des GPU capables d'obtenir le même résultat en 10 fois moins de temps, de 1/1000s à 10s les cibles seront encore plus nombreuses. Quelque soit la technologie utilisée, l'essentiel sera de bien maîtriser l'estimation d'un bruit hybride pour garantir de bonnes chances de réussite au reste de la chaîne.

Je me suis amusé à réduire le signal parasite par logiciel dans le cas de la nouvelle version : Les quelques pixels colorés restant laissent une traînée sur la vidéo (objets mobiles) et sont détectés par l'algorithme de flot optique. Avec l'ancienne version c'est aussi possible de traiter par logiciel. Comme dit Lucien si on s'en tient à des temps de pose de 1/100s à 5s, les darks ne sont pas nécessaires et ils sont englobés dans l'estimation du bruit hybride. Pour les pixels chauds, les poussières sur le capteur, ... c'est la vidéo qui permet de les mettre en évidence et ils sont englobés dans l'estimation du flot optique. Est-ce qu'il existe des caméras analogues à cette ASI224 fabriquées en France ou au moins en Europe ?

C'est un problème de capacité de calcul de la carte graphique, pour des images jusqu'au Full HD, une GTX 1050 Ti ou similaire suffit. Les prochaines échéances sont les oppositions 2018 de Jupiter, Saturne et Mars puis suivra le ciel profond. Pour le temps c'est quasi temps réel.

Si je fais la somme des images et que je normalise, forcément tous ceux qui sont tapis dans l'ombre vont pointer leur nez. Il faut donc trouver le moyen de les débusquer avant d'accumuler des trames (somme, moyenne, médiane ou autre). L'essentiel du travail se fait sur un dizaine de trames consécutives dans lesquelles on recherche des similarités entre patchs, des régions homogènes de bruit, des "lucky regions" et autres. L'analyse de la rafale d'images peut dans certains cas être multi-échelle et même multimodale. Ce travail préliminaire sur une rafale d'images conditionne toute la chaîne de traitements en aval. Il faut bien sûr avoir un minimum de signal dans l'image brute (temps d'exposition variant de 1/100s pour les planètes à quelques secondes pour les objets faibles) sinon il n'y a pas d'autres contraintes. Cette étape fonctionne comme un tamis. Je me suis même attaqué aux images compressées comme les jpeg (même pas peur), voir par exemple les 2 images ci-dessus.