mak jack

Camera planétaire, une fois pour toutes...

Messages recommandés

La turbu c'est en gros fonction du rapport D/R0 et du temps de cohérence (quelques ms quand on habite pas au Dôme C). En France l'idéal serait une EMCCD travaillant à 500ips (2ms) avec une sensibilité monstrueuse ... ça existe déjà mais avec de petits capteurs (128x128) ayant de gros pixels (plus de 20µm) donc pas facile pour réaliser le bon échantillonnage en planétaire.

L'exposition ou le temps d'obturation c'est un autre problème. Si tu veux obtenir une image moins tremblotante de la lune ou de juju, tu augmentes effectivement le temps d'obturation. Il y avait déjà une discutions à ce sujet sur ce forum qui expliquait que l'exposition n'était pas la solution miracle.

Partager ce message


Lien à poster
Partager sur d’autres sites
On en revient toujours à considérer l'exposition comme le premier moyen de lutter contre la turbulence. Le taux d'image permet d'obtenir plus d'images, donc statistiquement plus de bonnes images (celle rendues bonnes par l'exposition surtout).

Sur des sites privilégiés (de très faible seeing), on est très peu limité par le ciel, et on peut allonger l'exposition. C'est pas JLD qui faisait des exposition de 100ms ou 200ms sur Jupiter au pic alors que c'est parfaitement surréaliste de vouloir faire ne serait-ce qu'une exposition de 50ms en plaine. Une exposition longue, cela a le mérite de permettre une forte réduction du gain et par là une augmentation nette du rapport S/B.
Peut être même de faire des captures à >8 bits !


Marc

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
alors que c'est parfaitement surréaliste de vouloir faire ne serait-ce qu'une exposition de 50ms en plaine

Surréaliste quand même pas ... du temps des webcams on était à 200 et 100 ms (5 et 10 fps) et aujourd'hui encore, dans le bleu - et en IR ! on peut être autour de 40-50, ce qui fait quand même 20-25 fps.

Partager ce message


Lien à poster
Partager sur d’autres sites
La cadence en webcam était souvent décorrelée de l'exposition aussi (genre 1/30e, mais toujours 5i/s pour ne pas compresser le flux en USB1.1). Même si c'est vrai qu'à 10i/s on ne perdait pas grand chose en qualité (cela se voyait sur certains aplats trop "parfaits").

La faible qualité des images "exotiques" est souvent le signe d'une exposition très (trop ?) longue tu ne crois pas ?


Marc


Partager ce message


Lien à poster
Partager sur d’autres sites
Pour le coup je suis d'accord avec Marc ...

A l'époque de l'argentique, on était sur des temps de pose de 1 à 4 s, parce qu'on ne pouvait pas faire autrement.
Avec les webcams, c'était du 100 à 200 ms pour les mêmes raisons.

Pour avoir fait des images d'étoiles à 200 images / s, on s’aperçoit que le temps de cohérence est vraiment faible en général (< 5 ms) sauf site exceptionnel.

On pose plus long car on n'a malheureusement pas le choix ... pour le moment.

Partager ce message


Lien à poster
Partager sur d’autres sites
Cet historique argentique, webcam USB1, webcam USB2, webcam USB3, ... est très intéressant (et exact) mais je crois que nous ne parlons pas de la même chose.

En France il est possible de trouver des sites dont le temps de cohérence est en moyenne de 5ms sur 10s ce qui signifie qu'à 400ips on peut réaliser une vidéo de 10 secondes dont toutes les images seront reconstruites pour annuler les effets de la turbulence. Des algorithmes de reconstruction existent déjà et permettent de traiter des vidéos complètes. Les ordinateurs existent aussi pour faire les traitements dans des temps raisonnables.

Le goulot d'étranglement sera au niveau de l'acquisition si le flux de données dépasse les 600Mo/s de l'USB3 par exemple, cela nécessite l'utilisation d'un buffer capable de stocker les 10 secondes d'acquisition correspondant à notre vidéo de 4000 images non compressées.

La seule différence avec l'argentique et les webcams c'est le faible taux de déchets. Chaque vidéo de 10 secondes produit une image corrigée de la turbulence qui pourra être ajoutée à une autre image et ainsi de suite. Les 10s sont fonction du site, elles correspondent au laps de temps durant lequel la cohérence est en moyenne de 5ms.

Des cameras CMOS sensibles approchent aujourd'hui les 400ips à coût raisonnable ce qui devrait permettre ce type de manip dans les prochains mois ... est-ce la fin du bestof ?

Les puristes diront qu'il faut rester dans l'angle d'isoplanétisme pour valider chaque reconstruction mais dans le cas de petits instruments (D < 12"), on peut se contenter d'acquisitions faites à D/r0 < 4 par exemple (la mesure d'un r0 moyen sur 10s permettant de valider la reconstruction).

A mon avis un 10" a plus d'avenir qu'un 20" en photo planétaire haute résolution (et même peut-être en ciel profond).

Partager ce message


Lien à poster
Partager sur d’autres sites
ms, où peut-on voir une illustration de ces "algorithmes de reconstruction" sur des images réelles (pas des simulations) ? D'autre part, me trompe-je en disant que le RSB se dégrade sensiblement avec ces algos ? 10s sur une planète genre Jupiter ou Saturne c'est quand même bien peu (même avec un capteur à haut RQ), si en plus le RSB se dégrade...


Partager ce message


Lien à poster
Partager sur d’autres sites
Un truc qui est certain c'est qu'il est plus "régulier" de faire des bonnes images avec un 250mm qu'avec un 400mm (pour atteindre son pouvoir résolvant je veux dire).
Mais à raisonner ainsi, on fini, comme chacun sait, avec une lunette de 50 à 60mm qui donne son optimum (airy) tous les jours ! Très pratique pour voir les nuages sur neptune, mais bon, c'est pas l'objet du débat. Moi j'ai jamais rien vu de tel avec la 80ED qui, mais ce doit être son handicap, fait 1 ou 2cm de trop !

Je veux bien croire qu'il y aura une autre "révolution logicielle" (les fameux algos de reconstruction) pour travailler à très haute vitesse mais bon, il faudra encore travailler sur la sensibilité de la caméra ... 5ms sur jupiter ou saturne, à part avec un F/D de nain, je vois pas trop comment c'est possible à part à gagner presque 50% de QE d'un coup !
Peut être que ce sera plus facile sur du solaire (même pas certain pour du lunaire).

Cela reste passionnant en tout cas je trouve. Tu a des liens pour ces algos ?


Marc

Partager ce message


Lien à poster
Partager sur d’autres sites
Pour déconvoluer sur la PSF en temps réel (et donc la turbulence), il faut une image d'étoile qui soit dans le même plan d'isoplanétisme que l'objet imagé, et que cette image soit synchro avec les acquisitions. A la limite sur un satellite pour les géantes.
Cela me paraît très très difficile pour l'amateur

Après pour déconvoluer sur la PSF pour les défauts optiques de l'instrument est possible, c'est a déjà été fait sur les images de JLD et T1M me semble-t-il.

Partager ce message


Lien à poster
Partager sur d’autres sites
Bonjour,

l'algo de déconvolution que j'avait testé avec JLD est décrit sur ce post :
http://www.astrosurf.com/ubb/Forum2/HTML/036639.html

Ce n'est pas une déconvolution sur des images du 1m, mais bien sur un newton de 150mm.
Contrainte, en effet comme le disait Chonum, il faut avoir une étoile dans le champs (dans l'angle d'isoplanétisme pour être rigoureux) pour obtenir la psf réelle instantanée.
Les conditions d'application de ce type d'algorithme est en effet de poser vite pour passer sous le temps de cohérence, et espérer avoir localement, en fonction de la probabilité de Fried, des images pour lesquelles le rapport D/rO est proche de 1 (histoire de ne pas diluer tout ca avec des tavelures).
Ici c'est fait avec une PSF théorique. L'écart à la PSF réelle est minimisé par la sélection d'images pour lesquelles les hautes fréquences (dans la bande passante de l'optique sont maximales).

TL, je doit pourvoir te fournir les brutes pour mesure quantitative de la conservation du RSB si cela t'interesse (au pire tu peut les avoir via Jean Luc)

J'ai un boulot en route sur le traitement de la turbu (et l'obligation d'aller vite, mais la présentation que j'ai faite aux RCE cette année n'est pas en ligne a cause des enomres videos que j'ai jointe :-(...)
Dans la page que je prépare, il y a des videos de mesure quantitative temps réel des 3 quantités critiques Isoplanétisme, Temps de cohérence et r0.

Bernard

Partager ce message


Lien à poster
Partager sur d’autres sites
Tant qu'il n'y a pas une étoile ou un coup de laser dans le champ d'isoplanétisme, c'est mort pour le planétaire ;-)

En revanche, sur le solaire la deconvolution post-facto marche très bien (c'est la granulation solaire qui sert de référence). Faut juste avec un gros calculateur et attendre un peu le résultat du calcul... Il y a pas mal de doc sur le sujet (en solaire).

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut Christian.

>Tant qu'il n'y a pas une étoile ou un coup de laser dans le champ d'isoplanétisme, c'est mort pour le planétaire ;-)

C'est bien ce que je disait dans l'autre post :-)
Même à faible rapport D/r0 les tavelures dissolvent les détails, même trés finement. Faut avoir le ciel du pic pour que ca reste envisageable via une psf théorique

[Ce message a été modifié par brizhell (Édité le 05-02-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
ms, où peut-on voir une illustration de ces "algorithmes de reconstruction" sur des images réelles (pas des simulations) ? D'autre part, me trompe-je en disant que le RSB se dégrade sensiblement avec ces algos ? 10s sur une planète genre Jupiter ou Saturne c'est quand même bien peu (même avec un capteur à haut RQ), si en plus le RSB se dégrade...

La chaîne de traitement ne se limite pas à une reconstruction ou à une déconvolution aveugle. Le RSB n'est pas dégradé avec ces algos (voir "Performance of the Restoration Approaches Evaluated in PSNR Values" dans le premier lien). Enfin 10s c'est pour une image en sortie de la déconvolution aveugle, rien n'empêche d'en ajouter quelques dizaines si nécessaire.

Les deux liens indiqués dans le document de Xiang Zhu confirment la non nécessité d'avoir un objet ponctuel dans le champ d'isoplanétisme (contrairement à AIDA par exemple).

Enfin ceux qui connaissent MATLAB (payant) ou GNU Octave (libre) ou Scilab (libre mais moins compatible avec MATLAB) pourront tester les différents algos sur leurs propres séries d'images brutes.
http://users.soe.ucsc.edu/~xzhu/doc/download_tr.php


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

Partager ce message


Lien à poster
Partager sur d’autres sites
En effet, ca al'air de tenir la route après uen lecture rapide de la publi.

Je l'avais raté celle la !! Merci ms, je vais regarder ca d'encore plus près Ca tourne sous scilab ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Ce débat m'inspire quelques réflexions de béotien.
Je me réfère à ma propre expérience: en effet, du temps où j'utilisais ma toucam, j'obtenais mes meilleurs AVI en pratiquant des réglages qui semblent aller à contre courant de ce que les cam actuelles semblent proposer.
Je m'explique: je réglais ma caméra sur 5 images/s, jamais plus.
Ensuite, le temps d'exposition et la luminosité de façon à avoir un ciel le plus noir et le plus lisse possible.
Aujourd'hui on me dit qu'il faut au moins 120 images par secondes. Je présume que pour obtenir un AVI exploitable à un tel débit, il faut une sensibilité de malade ou alors on enregistre autant de bruit que d'information...non?
Merci de m'éclairer...enfin ceux qui comprennent ...lol

Amicalement.

JF

Partager ce message


Lien à poster
Partager sur d’autres sites
JF> "on" c'est qui ? Le commercial qui te dit que la nouvelle voiture est "vachement" mieux que l'ancienne et que tu a bien fait d'en changer ? Ou le routier qui a fait deux fois le tour du compteur de la vieille sans pépins ?

Capturer beaucoup d'images par seconde, c'est intéressant surtout (seulement ?) quand tu est limité dans le temps ! Exemple caractéristique sur Jupiter où on répétait (avec raison) que plus de 90" avec 250~280mm et ca bouge (vérifié par ton serviteur).
SAUF, que maintenant, avec winjupos, il y a des doux dingues (c'est amical) qui font des captures sur 10 minutes et avec de très bons résultats !
Donc franchement, et à moins que tu sois payé à l'heure pour ta passion (c'est pas ton boulot rassure moi) une capture de 2' à 60i/s ou 1' à 120i/s cela ne change pas grand chose au problème ... si ?

Je ne veux pas dire par là qu'on peut se limiter à 5i/s (un rapport 10 à 20 n'est pas anodin pour l'augmentation des risques d'emm***ements) mais c'est pas ce qui est important. Sensibilité, exposition, me semble incomparablement plus importants aujourd'hui (tant que les nouveaux algos décrits par ms ne sont pas encore répandus).


Marc

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
Ca tourne sous scilab ?

Sous GNU Octave-Forge, tu n'as pratiquement rien à changer mais sous Scilab la compatibilité MATLAB est moins bonne.

L'Ecole Polytechnique Fédérale de Lausanne a fait un site internet MATLAB/GNU Octave-Forge :
http://enacit1.epfl.ch/cours_matlab/

Je n'utilise pas MATLAB/Octave/Scilab mais : Python + NumPy + SciPy.

En fait ces algos devraient marcher aussi très bien avec des AVIs réalisés à 50ips et même moins. J'ai même prévu de faire des essais en planétaire à 25ips.

Au lieu de chercher la fuite en avant avec de nouveaux capteurs toujours plus rapides et plus sensibles, les passionnés de photos planétaires feraient bien de garder leur matériel et se tourner vers cette autre voie qui reste encore à défricher.

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

Partager ce message


Lien à poster
Partager sur d’autres sites
J'ai une licence matlab au boulot, mais si ca tourne sous SciPy ca me rappelera mes déboires avec Aida
J'ai jamais essayé de faire tourner un code Matlab sous SciPy

Vais essayer ca des que je peut

Partager ce message


Lien à poster
Partager sur d’autres sites
Il existe même un IDE comme celui de MATLAB : Spyder fournit le même environnement de développement sous Windows, Linux et MacOS X.

Personnellement, je lui préfère Portable Python (version 2.7.3) qui contient sur une clé USB tous les packages scientifiques nécessaires (NumPy, SciPy et Matplotlib) mais aussi IHM (PyQt et PyGTK) et Web (Django) avec l'IDE qui va bien (PyScripter).

Tu as aussi des exemples de migrations MATLAB -> Python à la pelle sur internet comme celui-ci (voir l'IDE Spyder de Pierre RAYBAUT) :

https://www.projet-plume.org/files/PRaybaut.pdf

patry : est-ce que tu as encore la vidéo de ta juju ainsi que les conditions d'acquisition ?
Ce serait intéressant de voir ce que donnent ces algos sur juju d'autan plus qu'en longue pose la dérotation peut se faire lors de la première étape.

brizhell : pour la dernière étape ce serait bien d'avoir le choix entre plusieurs algos de déconvolution aveugle car dans ce domaine des progrès ont été faits en terme de qualité et de vitesse.

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

Partager ce message


Lien à poster
Partager sur d’autres sites
ms> Ce qui se passe c'est que sur 90 à 120" la dérotation avec winjupos marche évidemment très bien mais les algorithmes de traitements par segments me semblent tout aussi efficace (les déplacements relatifs sont encore faibles).
Et ce, même si la même vidéo traitée en deux fois (sur chaque moitié) montre sans aucune ambiguïté un mouvement de balancement (capture au C11).
Evidemment, la limite temporelle est à adapter à l'instrument (lire parfois qu'une 80ED est limitée à 2' est parfaitement ridicule on ne travaille pas dans la même gamme de résolution). Par contre avec un 400 ou un 500mm évidemment la limite descend dangereusement ... si on utilise pas les "bons" logiciels après coup. Mais qui fait encore du monopoint ?

D'autres astrams (ils se reconnaîtrons) font des captures beaucoup plus longues sur plusieurs minutes en une ou plusieurs fois. Là on parle de capturer des dizaines de milliers d'images et d'en compositer plusieurs fois des milliers. Je pense que ce sont ces fichiers là que tu souhaite utiliser ?


Marc

Partager ce message


Lien à poster
Partager sur d’autres sites
Ce qui est intéressant c'est de stresser ces algos pour voir comment ils réagissent en fonction de niveaux de turbulence plus ou moins forts. Pour cela des petites vidéos de 10s à 30s suffisent.

En fait ce qui m'intéresse c'est d'appliquer plus tard ces algos à de la vidéo traitée en léger différé.

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut ms,

une question histoire de ne pas réinventer la roue au cas ou ...
As tu réalisé la transposition du code matlab sous Python ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant