Traitement des acquisitions de longue durée sur Jupiter

[jm2 0]

Bonjour,
Je poste ce message pour présenter un petit projet de traitement des images de Jupiter (ou de Mars) et obtenir des avis sur l'intérêt d'un logiciel de ce type, savoir si cela n'existe pas déjà ou encore, si cela a déjà été essayé et que cela n'a pas marché.

Description du projet
On sait que compte tenu de la vitesse de rotation de Jupiter, la durée d'acquisition d'un AVI ou d'une séquence d'images doit être très réduite.
Ainsi, en 1 minute, sur une image de Jupiter dont la taille est de 100 pixels, un détail situé au voisinage du centre du disque de la planète va se déplacer d'environ 1 pixel.
Avec des webcam telles que ma LPI de Meade (ou la DSI), cela ne permet pas d'enregistrer beaucoup d'images, environ 150 en 1 minute.

Une fois éliminées celles qui sont floues à cause de la turbulence et des vibrations de ma monture, le nombre d'images utilisables est très faible.
Et encore, les premières fois que j'avais utilisé ma LPI, c'était avec un vieux PC à 350 Mhz et la cadence d'acquisition était de une image toutes les 2 secondes!
J'ai fait des essais pour augmenter la durée d'acquisition jusqu'à plusieurs minutes.

Le principe de base est un programme (écrit en Java et tournant sous Windows comme sous Linux) permettant de déformer une image de Jupiter en lui appliquant une rotation (rotation autour de l'axe de la planète).

Ce programme permet de travailler sur des séquences de longue durée.
Supposons que l'on ait une séquence de 300 images acquises avec une cadence régulière durant 3 minutes.
Si on effectue une régistration classique de ces images et une addition, le résultat sera toujours plus mauvais que ce que peut donner un petit télescope de 115 mm, le déplacement des détails situés au centre du disque pendant 3 minutes correspondant à un angle de 1.5 seconde d'arc environ.
Par contre, si on applique aux 100 premières images une rotation égale à l'angle dont tourne Jupiter pendant 1 minute, et aux 100 dernières images, une rotation de même angle, mais de signe opposé, on peut alors additionner ces 300 images.

Evidemment, il y a un problème pour les points situés au voisinage du limbe de la planète (et surtout au voisinage de l'équateur de Jupiter), soit le limbe Est (celui qui "avance" vers l'observateur) dans le cas d'une rotation correspondant à un Delta de temps positif, soit le limbe Ouest pour un Delta T négatif. Mais on remarque que ces points ont un déplacement négligeable si on se limite à des Delta T de quelques minutes seulement et on n'obtiendra donc pas d'artifact décelable dans ces conditions.
Il y a aussi un problème au cas où un satellite (ou son ombre) passe devant le globe : on lui appliquera un déplacement comme s'il faisait partie de la surface de la planète.
Il faut donc éviter les images où un satellite passe devant, sauf s'il est au bord du disque.

Le programme est actuellement à l'état de "maquette", sans interface graphique, et suppose que les images font 640x480. (l'entête Fits n'est pas vraiment lue)
Les simulations présentées ci-dessous ont été effectuées en plus avec une méthode d'interpolation simpliste (plus proche voisin) qui dégrade l'image.
J'ai introduit depuis une interpolation bi-linéaire.
Il lit les fichiers FITS d'IRIS (un seul plan, données au format entier signé 16 bits)
Exemple d'utilisation avec Iris
Après conversion au format FITS d'une série ou d'un AVI (ou de plusieurs AVI), on effectue la régistration des ces images.
On doit avoir une idée de l'heure d'acquisition, à 30 secondes près par exemple.
On note les infos suivantes sur une des images régistrées :
coordonnées en nombre de pixels entier des 2 points extrêmes du disque de Jupiter situés sur l'équateur, à l'Est, puis à l'Ouest.
Remarque : si on s'est trompé dans l'ordre, il suffira de changer le signe du Delta T.
Ces informations permettent au programme de déterminer l'ellipsoide de la planète, les coordonnées de son centre et les 2 composantes (nx et ny) du vecteur rotation et donc la matrice de rotation. J'ai fait l'hypothèse nz=0, valable pour Jupiter, mais qu'il ne faudrait pas faire pour traiter les images de Mars, l'axe de rotation n'étant pas dans le plan de l'image (pole Sud ou Nord en général bien visible).
On appelle alors le programme en lui indiquant les informations ci-dessus et en plus :
le nom de la série d'images à traiter
le nom de la série résultat
le numéro de départ
le nombre d'images
le Delta T en secondes, positif ou négatif
On peut ainsi effectuer des rotations par tranches sur la série.
On laissera la partie centrale de la série inchangée et on découpera les parties extrêmes en tranches de 60 secondes par exemple.
Pour vérifier le principe de l'algorithme de rotation qui est le point essentiel, j'ai utilisé une très bonne image animée de Jupiter trouvée sur Astrosurf et réalisée par Catherine et Frédéric
Site Internet : http://cathetfred.free.fr/index.html
La Tache Rouge en particulier est bien placée pour faire des mesures et controler les déformations de l'image.

Remarque importante : les images ci-dessous et en particulier celles de Catherine et Frederic ont subit des extractions à partir de l'animation et une compression Jpeg. Elles sont donc d'une qualité inférieure à celles que l'on trouve sur leur site.

Voici les résultats de mes premiers essais.
Tout d'abord, un extrait du canal vert de la première image de l'animation :

Une image calculée avec une rotation correspondant à un écart de temps de 2 minutes :

Avec un écart de temps de 4 minutes, on commence à voir des artifacts sur le côté gauche :

Par contre, avec un écart de temps de 20 minutes, les défauts deviennent considérables :

Sur le bord gauche du dique, on obtient n'importe quoi. Le bord droit, même s'il parait moins mauvais n'est pas bon non plus car le traitement des parties cachées n'est pas effectué.

Pour info, voici l'image réelle en couleur obtenue par Catherine et Frédéric 20 minutes plus tard :

Ces manips laissent prévoir que le traitement de séries de 5 min sur Jupiter, c'est à dire avec un décalage d'environ 2 min de part et d'autre, ne doivent poser aucun problème.
Des séries proches de 10 minutes doivent être envisageables avec un traitement plus soigné des points au voisinage du limbe et de l'équateur de la planète.
Par contre il ne sera pas possible d'atteindre des durées 40 minutes sur Jupiter.
Sur Mars, les durées pourraient être proches d'une heure.
Pour certaines affirmations, j'ai supposé que la résolution du télescope était de l'ordre de 0.5 sec d'arc.
Bien entendu, et c'est la raison de ce post, toutes ces considérations doivent être vérifiées.

[leonardcauvra 3 339]

Ca c'est superbe, comme idée. Je la vois essentiellement valable pour Jupiter. Pour Mars, même à 5 images/seconde, un AVI de 3 minutes suffit à obtenir un nombre suffisant d'images (sans distorsion).

[Christophe Pellier 8 855]

Salut, c'est une manip intéressante et si tu peux la mener à bien, ça ferait un peu de bruit... Tu n'es pas le premier à tenter le coup, et un ami à moi (Jean-Jacques Poupeau) a eu la même idée l'an passé sans mener le projet à terme.
Maintenant, si le but est uniquement d'augmenter le nombre d'images brutes, et le rapport signal/bruit, il y a des solutions beaucoup plus directes et faciles, à commencer par utiliser un outil plus performant que la LPI! La moindre webcam fera bien mieux... et sans compter les caméras CCD du type DMK ou Lumenera qui là, permettront d'aller encore plus loin.
On peut aussi soigner l'acquisition, le traitement...
Bref, c'est une idée qui revient de temps en temps, mais la difficulté de conception pour des résultats qui restent à prouver ne supporte pas la concurrence des outils modernes d'acquisition, à mon avis.
De plus ce n'est valable que pour Jupiter - les autres planètes ne souffrent pas de ce problème de rotation trop rapide des détails (même pas Saturne, qui supporte parfaitement 5 mn de capture sans dérive des spots).
Christophe
PS Le temps de capture maxi sur Jupiter est plus important qu'on ne le pense, on peut prendre deux minutes sans craindre grand chose à moins d'utiliser un 350 dans des conditions exceptionnelles...

[octintin 1]

Bonsoir,

j'ai mis en ligne sur le site du club du Versoud, il y a quelque temps une application semblable dans le principe mais pas dans l application : il s agissait (suite à la lecture d'un article dans Sky and Telescope) de faire un petit logiciel pour effectuer des rotations d'une image de la Lune afin de voir "de face" la vrai forme des formations lunaires situés hors la région centrale. Les maths doivent etre totalement les memes que dans la problématique Jupiter décrite ci dessus.

Mon programme est aussi en Java, disponible à la page : http://astro.versoud.free.fr/logiciels/astroc_imrot/index.html

Ca marche pas trop mal, mais j avais pas automatisé la définition de la sphére par le programme (en gros l utilisateur doit définir ou se trouve la Lune, la planete etc...)

A+
Olivier

[jm2 0]

Bonjour,
Je reprend la suite du post (qui date déjà de près de 3 semaines !)
Tout d'abord, merci pour les commentaires.

leonardcauvra> Entièrement d'accord, c'est surtout intéressant pour Jupiter, c'est d'ailleurs le titre du post.

Christophe> On peut obtenir un meilleur rapport signal sur bruit, par exemple 2 fois meilleur avec une durée totale 4 fois plus importante, mais on peut aussi être plus sélectif sur la sélection des meilleures images ou exploiter plus de "trous de turbulence".
Evidemment, avec une lumenera on a un nombre d'images suffisant mais lorsqu'on a seulement une DSI, même si on peut espérer obtenir des images brutes de bonne qualité on n'en aura jamais beaucoup si on se limite à 2 mn d'acquisition.
Aurais tu un peu plus d'infos sur les travaux de ton ami ?
Pourquoi a-t-il abandonné ?
Je sais bien que souvent des idées qui peuvent paraitre intéressantes en théorie se révèlent en pratique inapplicables ou inutiles, et le but de ce post est bien de recueillir des avis préliminaires.

octintin> c'est exactement le même principe que ton programme. Les formules que j'ai utilisées sont différentes car j'ai représenté la rotation sous la forme d'un vecteur rotation et d'un angle, au lieu de la représenter sous la forme des 3 angles habituels, mais cela revient absolument au même : pour chaque point de l'image, on calcule sa coordonnée "Z", on fait tourner dans l'espace et on ne conserve que les 2 coordonnées X et Y.

Voici l'écran de la version expérimentale, avec le programme Java sous forme d'applet intégré dans une page HTML. J'ai ouvert l'image réalisée par Catherine et Frédéric..

Compte tenu de l'applatissement de Jupiter, il aurait été préférable de remplacer le cercle par une ellipse, mais c'est un peu plus compliqué de dessiner une ellipse à partir du moment où ses axes sont inclinés.
Le bouton "Visualisation" affiche dans la fenêtre de l'applet l'image qui a été sélectionnée, la première de la série par exemple mais en fait cela peut être n'importe laquelle.
Un cercle rouge et une flèche permettent de vérifier que les coordonnées des 2 points extrêmes de l'équateur sont correctes. La précision de ces coordonnées n'a pas besoin d'être très importante car les décalages appliqués sont toujours faibles, quelques pixels au maximum, et une erreur sur la position ou l'orientation du vecteur rotation n'aura pas d'influence sensible.
Par exemple, une erreur de 10 degrés sur l'orientation de l'axe de la planète conduira à une erreur qui sera toujours inférieure à 0.35 pixels dans cet exemple.
La flèche indique la direction et le sens du décalage qui sera appliqué aux images de la série.
Cela permet de vérifer si on ne s'est pas trompé entre l'Est et l'Ouest.
Sa longueur n'est pas significative, la valeur du décalage au centre de la planète étant indiquée dans le texte à gauche.
Bien entendu ce décalage sera de plus en plus faible au fur et s'annulera lorsqu'on s'approchera du limbe de la planète.
C'est le bouton "Générer" qui va lancer la génération des images.
Dans l'exemple, on va générer 30 images qui s'appelleront :
jupiter_vert60.fit
etc...
correspondant respectivement aux images :
cath_fred50.fit
etc...
avec une rotation correspondant à +120 secondes.
Ces images générées seront placées dans le même répertoire, ici : C:\Images.
Les 2 index permettent de constituer une série finale homogène.

Remarque 1 : il ne faut pas avoir fait au préalable un "bestof" suivi d'un "select" sur la totalité de la série initiale, sinon on n'a plus aucune idée de la date d'acquisition des images.
Mais on a pu faire des "bestof" sur des blocs avec dates d'acquisition voisines (à 1 minute près par exemple).
Remarque 2 : le programme est sous forme d'applet, ce qui ne pose pas de problème sous Internet Explorer dans la mesure où il est local et appelé par une page HTML locale : il peut alors lire et écrire les images sur le disque.
Si ce n'est pas le cas, il faudrait le signer. C'est peut être le cas aussi avec Firefox, je n'ai pas encore essayé.

[Christophe Pellier 8 855]

Salut, je te retransmet la réponse de Jean-Jacques !!
------
Après avoir eu cette idée ( remettre les pixels du globe jovien en synchronisme) peu après avoir utilisé ma première Toucam, un japonais avait fait quelque chose qui marchait, mais il n'a rien ébruité sur sa façon de procéder.
Voici le lien qui mentionne son travail : http://www5f.biglobe.ne.jp/~kztanaka/prce.html <http://www5f.biglobe.ne.jp/%7Ekztanaka/prce.html>
Il est clair que cette idée marche, mais pour que tous les fans de planètes puissent en profiter, il faudrait mettre en oeuvre un programme convivial, spécifique ou intégré dans un autre logiciel astro existant. En conséquence, je ne puis qu'approuver et encourager ce projet de traitement des images de Jupiter proposé par jm2 dans le forum que tu cites. J'avais soumis cette idée lorsque j'avais rencontré Axel Canicio aux rencontres Astro au parc de la Villette et il avait alors accueilli favorablement mon idée pour l'intégrer dans Astrosnap Pro. Malheureusement il est (toujours) débordé et le développement d'autres fonctionnalités plus prioritaires l'accaparent toujours...
A défaut de posséder une caméra à 60 ou 100 i/s en 12 bits, je rêve malgré tout d'avoir la possibilité de superposer exactement mes images R,V et B obtenues avec ma Toucam N&B ou de faire des empilages de films consécutifs post-synchronisés pour augmenter en finale le nombre total d'images utilisables.
Un grand nombre d'images en matière de haute résolution apporte un gain qui n'est plus à contester...
Cela sera très utile pour tenter d'obtenir des images valables de Jupiter dans les années à venir (quel que soit le moyen de prise de vue) car la déclinaison ne nous sera pas favorable.