ms

Soumis à modération
  • Content count

    7493
  • Joined

  • Last visited

  • Country

    France

Everything posted by ms

  1. En attendant que le ciel se dégage, 2 petites simulations : Concrètement, il n'y a qu'un logiciel (Linux/ArrayFire) qui réalise : - la capture des images brutes couleur de l'ASI 224 MC, - l'alignement des images brutes, - la correction de la turbulence, - l'accentuation des images, - le dé-bruitage, - la balance automatique des blancs, à une cadence supérieure à 100fps avec la carte graphique GeForce 1050 Ti. PS : les nouveaux processeurs AMD incluant la carte graphique (Ryzen 3400G et au-delà) offrent des perspectives très intéressantes dans un volume réduit de 1,2 litre. Quand le ciel se dégagera, je tenterai une vidéo de Jupiter plusieurs heures à raison d'une image HR toutes les 30 à 40s environ. Avec des extraits des vidéos d'écran :
  2. Jupiter et Saturne

    Si la diffamation a été prononcée sur un site internet (ce qui est le cas ici), la victime doit poursuivre d'abord l'auteur des propos et non l'hébergeur du site. Vous semblez ignorer que le procureur ou le juge ne vont pas prendre en compte la nature scientifique mais la nuisance de vos propos et surtout vos récidives qui risquent fort d'être qualifiées d'acharnement. Tout cela est aussi aggravé par le fait qu'un journaliste scientifique astro n'a pas à s'étaler de la sorte sur un forum astro. Se pose alors le problème de la diffamation publique qui est punie plus sévèrement que la diffamation privée. Merci de m'avoir transmis vos identités cela facilitera ma plainte. Mon but n'est pas de vous faire trembler mais de vous ramener à la réalité. Je vais déjà envoyer quelques images au président de l'association qui m'a invité puis je publierai sur mon site internet par la suite. Malgré des conditions difficiles (nuages, turbulence), il a été possible hier soir de montrer au public l'ombre d'Europe et la GTR à partir de rafales de 1000 images brutes obtenues en moins de 10s.
  3. Jupiter et Saturne

    Ce message a été posté et modifié le 29 juin 2019, tout le monde peut effectivement le vérifier. D'autre part, pour tes propos à répétition que je juge diffamant et dont je garde la trace, il y a des lois et tu vas devoir très certainement t'en expliquer prochainement avec ton acolyte. Hier soir, EVA a été présenté à un large public dans le cadre de la Nuit des Étoiles à la demande d'une association. Le ciel s'est finalement découvert entre 22h et minuit ce qui a permis d'observer Jupiter (GTR et Europe), Saturne et Abireo. Je vais poursuivre jusqu'en 2020, les présentations publiques et élargir les possibilités d'EVA au ciel profond. Mettre à disposition des associations un outil permettant d'explorer le ciel sans prise de tête est une des pistes.
  4. Jupiter et Saturne

    Arrêtes ton char, je cite le lien quelques lignes plus bas dans le post en question. Tu es de la police ? Au fait, il en est où votre projet ? 😉
  5. Jupiter et Saturne

    Ça vaut le coup de continuer rien que pour voir quel benêt tu va faire dans peu de temps.
  6. Jupiter et Saturne

    Il s'agit ici d'effets de bords liés au fait qu'on ne maîtrise pas les interfaces entre les différents logiciels qui agissent comme des boites noires : - AS3 prend en entrée un fichier SER provenant de FireCapture, - R6 prend en entrée un fichier TIFF provenant d'AS3, etc ... Cette approche ne permet pas d'assurer la traçabilités des octets obtenus en sortie de la commande "ASIGetVideoData" (API de ZWO) et garanti encore moins que le chaînage de tous les logiciels soit exempt d'artefact. Il faut être capable de suivre à chaque étape la transformation des octets formant chaque image brute mais le fait de les transformer en différents formats (SER, TIFF, PNG, ...) conduit fatalement à des effets de bords. Avec EVA chaque image issue de la commande "ASIGetVideoData" est un objet ArrayFire de type "array" dont tous les états peuvent être tracés (tests unitaires puis tests d'intégration). C'est seulement en bout de course que ces objets sont transformés en image de type PNG ou en vidéo de type SER. Pour reprendre le lien cité plus haut, la traçabilité est assurée dans EVA à chaque étape : - Input sequence = la commande "ASIGetVideoData" - Optical Flow = alignement des images brutes - Reference = image de référence - Lucky = fusion des "lucky regions" - Deconvolution = déconvolution aveugle - Output sequence = fichier PNG ou fichier SER Ci dessus le traitement de la vidéo de Lucien en 1800/235 = 8s. Le sentier d'objectivité c'est déjà assurer la traçabilité et avec le chaînage des logiciels existants, c'est mal parti.
  7. Jupiter et Saturne

    C'est toujours la même série qui me sert (SER) pour Jupiter avec les images brutes qui se déplacent dans le champ pour tester l'alignement et la suite. Pour Saturne, je ne sais plus mais les déplacements importants permettent de faire des tests. Les prochaines vidéos seront un peu plus fraîches. L'idée c'est aussi de supprimer les effets de bords en supprimant les intermédiaires (FireCapture, AS3, R6, WinJUPOS, etc ...). Le même logiciel de bout en bout avec tous les calculs effectués en virgule flottante sur 32bits par le processeur graphique (GPU 10 à 100 fois plus rapide que CPU).
  8. Jupiter et Saturne

    J'ai prévu de faire un essai demain dans les Vosges lors de la nuit des étoiles mais il semble que se sera couvert. Dans 15 jours, je serai à St Michel l'Observatoire et là j'espère que le ciel sera plus dégagé. J'ai fait un test avec 2000 images brutes et le résultat me semble satisfaisant pour une acquisition/traitement de moins de 20 secondes à 130fps :
  9. J'aime bien cette version qui n'est pas dans l'alphabet :
  10. Pour un temps d'acquisition inférieur à 90s (ce qui est le cas ici) la scène à photographier est statique donc tous les mouvements de pixels sont causés par la turbulence. Je ne comprends pas trop cette discussion ... ce qui est admis aujourd'hui concernant la turbulence c'est le processus suivant : 1800 images brutes en entrée et 18 secondes plus tard, une image corrigée des effets de la turbulence. Le cas où des objets se déplacent devant la scène (des poussières du capteur par exemple) est plus complexe à traiter : https://export.arxiv.org/pdf/1905.07498 Enfin, j'aime bien la petite animation de Lucien qui se passe de commentaires : Bonne journée à tous.
  11. La A semble répondre à cela ainsi que la J.
  12. L'image initiale alignée sur celle de Lucien mais avec une autre balance des blancs :
  13. Une deuxième version (orientation de la planète et balance automatique des blancs) :
  14. Quel type de pré-traitement permettrait d'augmenter le nombre de patches valides de ta vidéo ? Ici, je n'ai pas fait de pré-traitement sur les images brutes mais un "dejittering" en x et y compenserait les tremblements. A comparer aussi différentes vidéos pour différentes force de jet-stream.
  15. Un seul outil sous Ubuntu 18.04 et Jetson Nano : $ eva -o jup_lucien_1.png Jupiter_1800_RGB.ser // version 1X jup_lucien_1.png $ eva -o jup_lucien_2.png -sr 2 Jupiter_1800_RGB.ser // version 2X jup_lucien_2.png
  16. Un petit png rapide (image alignée sur celle de Lucien) :
  17. Ce qui est intéressant c'est qu'avec une alim externe 5V/3A de 20000mAh (420 grammes), l'autonomie est de plus de 6h avec une carte graphique bien sollicitée. En mode acquisition automatique (vue la compatibilité GPIO RPI3, il existe pleins de petits moteurs pour contrôler la MAP), l'écran est coupé, du coup l'autonomie augmente.
  18. Avec un petit clavier/touchpad pour remplacer le clavier virtuel et la souris : Une config autonome à moins de 300 euros qui consomme moins de 15W, qui intègre les possibilités d'un Raspberry Pi et CUDA/ArrayFire sous Ubuntu 18.04 c'est assez intéressant. Il ne me reste plus qu'à y connecter une MIPI CAM 290, Sony IMX290 For Raspberry PI, JetsonNano à moins de 100 euros et la config sera complète.
  19. Qui parle de TensorFlow ? J'utilise ArrayFire (voir ci-dessus) qui est une bibliothèque C/C++ de tenseurs avec les cartes embarquées Jetson Nano (CUDA) et prochainement UDOO Bolt (OpenCL). C'est plus rapide que d'utiliser TensorFlow ou Torch comme l'explique Facebook avec sa bibliothèque Flashlight : https://arxiv.org/pdf/1812.07625.pdf Il suffit de recompiler ArrayFire pour l'environnement choisi (amd64, arm64, ...). ArrayFire permet aussi de se passer d'OpenCV et de Qt. Enfin, un développement Jetson Nano est entièrement portable (Ubuntu 18.04, CUDA 10.0 et ArrayFire 3.7) sous Jetson Xavier qui est beaucoup plus puissant.
  20. La consommation c'est 10W par défaut (nvpmodel 0) et 5W en mode bridé (nvpmodel 1). J'utilise le mode par défaut et j'alimente la carte en 5V 3A, cela est suffisant pour l'écran tactile 7" FullHD et la caméra ZWO 224MC (autonomie d'environ 6h pour l'ensemble). Ce petit PC sous Ubuntu 18.04 est autonome dans la mesure où tout peut être compilé directement pour l'ARMv8 (pas besoin de passer par un PC avec processeur Intel comme dans le cas des autres cartes Jetson), j'ai fait le test avec la librairie ArrayFire 3.7 : http://gpu-vision.com/index.php/arrayfire-3-7/ Pas de problème non plus pour l'écran tactile qui fonctionne dans un mode reconnu d'Ubuntu 18.04. Le coût de l'ensemble (JetsonNano + boitier + carte microSD 32Go + écran tactile 7" Full HD + alim 5V 3A) c'est 280 euros. Reste maintenant à dessiner avec FreeCAD un nouveau boîtier qui intègre tout cela (Jetson Nano + écran + alim = 600g environ) puis de le fabriquer avec une imprimante 3D, c'est un oculaire électronique en gestation. Il y a aussi 2 ports USB3 de libres pour piloter la monture et la MAP. Quand on pense qu'une nouvelle génération de carte microSD (900 Mo/s) est en préparation (aussi rapide qu'un disque SSD). Consommation Jetson Nano + écran tactile 7" en sollicitant la carte graphique au maximum = 10 à 13 Watt (inférieur aux 15W fournis par la batterie externe de 20000mAh) : Autonomie = (20 / (13/5)) x 0,8 = 6,15h > 6h
  21. Pourquoi cette précipitation pour ôter le bruit ? Ci-après le 2 premières images enrichies des meilleurs patchs de 40 images consécutives (à gauche l'image brute initiale) : etc ... En faisant la même manip avec ton image brute enrichie des meilleurs patchs de 40 autres images brutes :
  22. Avec une seule image brute ça me semble impossible. Tu prends par exemple cette image et tu l'enrichis des bons patchs extraits des 300 premières images brutes. Tu as plus de chance d'avoir une image fidèle en travaillant au niveau du patch que de l'image entière. L'image résultant de cette opération est encore bruitée, déformée mais elle n'est pas floue. Tu refais la même opération avec une autre image brute et 300 nouvelles images consécutives. A la fin, tu obtiens 70 images enrichies bruitées et déformées mais un algorithme comme le centroïde (ou autre) permet d'obtenir une image non déformée. Tu peux maintenant estimer le bruit et dé-bruiter cette image. Pour le moment je prends les images 1, 301, 601, 901, ... pour démarrer, c'est pas très malin parce que si l'image est très déformée, le résultat final sera moins bon. Il me faut trouver un algorithme rapide qui permette de sélectionner une image de départ sans image de référence. En attendant, je peux faire cette sélection en visuel mais ce serait mieux si c'était automatique. L'apprentissage profond pourrait être une solution pour sélectionner cette image de départ qui sera enrichie par la suite avec les "bons patchs" extraits des images brutes suivantes. Pour tester la validité de cette approche, la lune reste un objet de choix, elle permet même d'augmenter le nombre de détails en utilisant des prises faites à des dates différentes.
  23. Les 21204 images brutes ne sont pas floues comme celle du milieu (empilement de 16) ou celle de droite (empilement de 300). En empilant tu diminues le bruit mais tu amplifies le flou et après c'est la galère pour faire d'autres traitements. Il ne faut pas empiler, tu prends une image brute pas trop mauvaise et tu extrais les meilleurs patchs des 300 images brutes consécutives suivantes par exemple. Puis, tu complètes ton image brute initiale avec les meilleurs patchs, elle est plus détaillée et elle n'est pas floue. Quand tu as obtenu 70 images plus détaillées mais pas floues alors tu peux appliquer le centroïde (ou un autre algorithme plus rapide) pour les redresser et faire diminuer le bruit.
  24. Tous ces algorithmes sont issus du passage dans le labyrinthe de ces 10 dernières années et les plus performants ont été portés sous CUDA. L'extraction des "bons patchs" ne demande plus que 2,3ms par image FULL HD avec une carte graphique 1050 Ti, ce qui laisse suffisamment de temps aux autres traitements pour tenir une cadence de 100 à 150 fps avec des images FULL HD ... mais déjà la 1150 Ti (50% plus rapide) pointe le bout de son nez. Mon dernier mot c'est qu'il doit être possible d'atteindre ce type d'image à condition d'aller au delà des 21000 brutes de cette vidéo :