jm2

Bonjour, Un exemple d'image de M82 obtenue avec une LPI http://astrosurf.com/astrotech/M82.jpg et M57 : http://astrosurf.com/astrotech/M57.jpg J'avais parlé de mon expérience avec la LPI l'année derniere http://www.astrosurf.com/ubb/Forum2/HTML/006272.html [Ce message a été modifié par jm2 (Édité le 13-12-2007).][Ce message a été modifié par jm2 (Édité le 13-12-2007).][Ce message a été modifié par jm2 (Édité le 13-12-2007).]

Bonjour Les informations sur la résolution des imprimantes fournies par les constructeurs sont des infos subjectives : c'est la résolution que devrait avoir une imprimante matricielle aux pixels identiques et régulièrement espacés pour que l'impression visuelle sur une image soit comparable. Ce n'est pas la véritable résolution de l'imprimante. Exemple : imprimante HP PhotosmartL'imprimante qui est donnée pour une résolution de 4800x1200dpi n'imprime en fait qu'avec une résolution de 300 dpi, et encore, les traits ainsi obtenus sont irréguliers. Observés au binoculaire, ils sont constitués de points irréguliers qui débordent largement le trait de 1 pixel de large. Le trait le plus fin imprimé a une largeur de l'ordre de celle d'un cheveu (100 microns).

Un petit résumé personnel sur l'utilisation de la LPI Meade Ces infos ont fait l'objet de posts anciens sur Astrosurf mais ils ont du disparaitre après le crash J'ai également poste des images faites à la LPI (M13 et plus récemment M82)Capteur : CMOS Hynis Semiconductor Inc. HV7131E1 (Type 1/3") Taille image : Diagonale 6.5 mm, 5.18 mm x 3.90 mm Nb de pixels effectifs 644 (H) x 484(V) 310K pixels Nb total de pixels : 648(H) x 488(V) Taille des pixels : 8.0micron x 8.0 micron Résolution max : 640 x 480 Durées de pose : 1/1000 s - 16 sPas de compression : RGB24 Taux maxi de trames : 3 trames par seconde. Qualité d'image Excellente : bruit faible si les paramètres d'acquisition sont bien réglés et surtout pas d'artifacts visibles, ce qui permet ensuite des traitements d'image poussés (rehaussement des contrastes, etc...) Ceci est du à l'absence de compressionSensibilité Comparée à la Philips ToUcam Pro (modèle PCVC740K) la sensibilité est beaucoup plus faible. En installant une LPI à la place de la ToUcam sur un télescope, on constate qu'il faut des poses 4 fois plus longues, bien que le champs soit plus grand de 50%, soit le double en surface. Ainsi, pour des photos au foyer, les temps de pose seront 4 fois plus longs et pour des images planétaires, des images avec une planète à taille égale demanderont des poses 8 fois plus longues.Typiquement, pour le planétaire, avec un 200mm et un rapport F/D de 18, les temps de pose sur Saturne conseillés par le logiciel se situent autour de 0.36 s Les effets de la turbulence pour ce temps de pose ne sont plus négligeables. Si on réduit les temps de pose, en augmentant la luminosité, on obtient des images bruitées. Celles ci seront tout à fait exploitables : la composition d'un grand nombre d'images permettant de supprimer le bruit, mais les outils de mise au point automatique (Magic Eye de Meade) comme les algorithmes de sélection des meilleures images marcheront mal et il sera nécessaire d'effectuer un tri manuel des meilleurs images.Par ailleurs, la cadence faible d'acquisition ne facilite pas la mise au point. Celle ci est assez difficile dans un site moyen et conditions de turbulence moyennes. Compte tenu des temps de pose assez longs nécessités par la faible sensibilité et qui vont donc donner des images assez flou avec la turbulence, de la faible cadence d'acquisition (en pratique 2.5 images à la seconde) et du retard d'affichage (de 1 à 2 trames) la mise au point n'est pas simple. Elle devient encore plus difficile avec un PC peu puissant. Par exemple, un Pentium à 350 Mhz, avec USB 1 ne permet des acquisitions qu'à la cadence d'une image toutes les 2 secondes.En ciel profond, la faible sensibilité conduit à des résultats variables suivant les objets. Le critère n'est pas la magnitude ni la luminosité surfacique globale, mais la luminosité surfacique des détails des objets.Exemple d'objet très facile : La nébuleuse d'Orion (évidemment !) Exemples d'objets faciles : M13, M57, M82 Exemples d'objets plus difficiles: M51 Exemples d'objets très difficiles : M27, M81Ce classement peut surprendre. Par exemple, obtenir une image présentable de M27 est difficile avec la LPI Meade alors que cette nébuleuse est parfaitement visible à l'oculaire et que sa magnitude est faible. En fait, M27 est rès étendue et possède des étoiles brillantes. Si on examine la luminosité surfacique des détails, tels que le second lobe du "trognon de pomme" et surtout les anses, on s'aperçoit qu'elle est très faible. En pratique, M27 n'est pas visible sur l'écran du PC, même avec le temps de pose maximal de 16 secondes et la luminosité au maximum. Il faut donc se repérer sur les étoiles environnantes pour centrer l'objet sur le capteur. L'addition d'une dizaine d'images acquises à 16 secondes permet de reconnaître l'objet. Mais l'addition de 300 images ne permet toujours pas de faire ressortir les anses, bien que cela corresponde à une acquisition de 1H 20mn. Il faut noter que les acquisitions de M27 se font en été, les nuits sont chaudes et le bruit du capteur est plus important (il est en gros multiplié par 2 pour chaque augmentation de la température de 7 degrés C) De même M81 est difficile si on veut faire apparaître les bras de la galaxie. On voit très bien sur chaque image brute le noyau de la galaxie mais il faut 200 poses de 16 secondes pour deviner un des bras au milieu du bruit et il faudrait compter 1000 à 2000 poses pour avoir une image présentable de M81. Par contre M82, bien que globalement plus faible que M81, possède des détails très lumineux et apparaît presque présentable sur une seule pose de 16 secondes, surtout lorsque l'acquisition est effectuée par une nuit froide d'hiver.Quelques infos sur le bruit de la LPILe capteur de la LPI est un capteur CMOS (HV7131E1) Bien que sa taille soit assez importante (type 1/3e), son bruit est bien supérieur à celui d'un capteur CCD tel que celui de la Toucam Pro II Ce bruit va donc limiter la durée maxi d'exposition, surtout lorsque la température est élevée. J'ai effectué quelques mesures du bruit de la LPI (Mesures effectuées avec un gain égal à 100 et offset à 100, acquisition en Noir et Blanc.) A 18 °C Images de 16s max : 255 (il ya saturation) min : 91 moy : 171.8 sigma : 25.6Images de 5.7 s max : 249 min :86 moy : non notée sigma : 15.9Images de 2 s max : 238 min :92 moy : non notée sigma : 9.3 Bien que les mesures sur les images à 16s ne soient pas très significatives du fait de la saturation, on constate que lorsque le temps de pose est multiplié par : 2.85 l'écart type sur le bruit est multiplié par : 1.71lorsque le temps de pose est multiplié par : 8 l'écart type sur le bruit est multiplié par : 2.75 On en déduit approximativement que lorsque le temps de pose est multiplié par n, le bruit est multiplié par la racine carrée de n Sachant que le signal utile est proportionnel au temps de pose, on en déduit que lorsque le temps de pose est multiplié par n, le rapport signal / bruit est multiplié par racine de n Mesures effectuées un autre jour (le 6/06/2005) sur le bruit de la LPI Pose : 2s Max : 250, Min : 129, Moy : 177 Sigma : 7.3 Pose : 1 s Max 233, Min 124 , Moy 158, Sigma : 5.2 Pose : 0.5 Max 196, Min 119, Moy 144, Sigma : 3.5 Pose : 0.25s Max 176, Min 112, Moy 136, Sigma : 2.6 Pose : 0.01s Max 141, Min 116, Moy 121, Sigma : 2.2 Efficacité du cumul d'images avec des poses courtes On prend comme référence une pose de 16s, et on va calculer la durée cumulée de pose avec des poses plus courtes pour avoir le même rapport signal sur bruit, sachant que si le bruit est multiplié par un facteur k, il faudra k*k images pour retrouver le même rapport signal sur bruit. En fait de rapport signal sur bruit on prend le rapport temps de pose sur sigma du bruit. Durée de pose Bruit/Signal référence Nb images Temps cumulé 16 1.6 1 1 16 s 5.7 2.8 1.75 3 17 s 2 4.65 2.9 8.4 16.8 sLa seconde série de mesure effectuée dans des conditions de température différentes donne : 2 3.6 2.25 5 10 s 1 5.2 3.25 11 11 s 0.5 7 4.38 19 9.5 s 0.25 10.4 6.5 42 10.5 s 0.01 220 137.5 18906 189 sIl y a un décalage entre les 2 séries de mesure (température différente) mais elles permettent de suivre l'évolution de l'efficacité du cumul des poses courtes.Conclusion : on voit que le technique du cumul marche bien et le temps global de pose est équivalent à condition que l'on puisse négliger le temps supplémentaire du à l'enregistrement ds fichiers et bien sûr à condition de ne pas descendre à des temps de pose très faible car en dessous de 0.25s, le bruit reste à peu près constant et le rapport signal sur bruit se dégrade. Il y a en plus un temps perdu par l'enregistrement de nombreux fichiers qui devient considérable. Ainsi pour obtenir le même résultat avec des poses à 0.01s que celui obtenu avec une seule pose de 16s, il faut 18906 images, mais le temps réel d'acquisition de ces images sera bien supérieur à 189s (même si on ne les enregistre pas sur le disque).Combinaison d'images. Lorsqu'on additionne n images prises avec un capteur non refroidi, un obtient un rapport Sigal sur Bruit qui est divisé par racine de n.Conclusion : entre 100 poses de 16s et 1600 poses de 1s (soit le même temps de pose), on a un résultat à peu preès équivalent. Ce résultat ne serait plus vrai si on compare des poses de 16s avec des poses de 1/60 de seconde. Le temps cumulé de pose serait alors beaucoup plus important avec des pose très courtes qu'avec des poses de 16s.Vérification avec des images d'une étoile (Arcturus) On va comparer une photos de cette étoile et de son voisinage avec une pose de 16s avec la somme de 16 photos de 1s. Les 2 images (etoile_16s.bmp et etoile_16fois1s.bmp) sont assez similaires. Remarque : la somme des 16 images a été effectuée sans recalages. On va plus loin en comparant la somme des 5 images à 16s avec la somme de 80 images à 1 s Il faut alors effectuer des recalages dans les 2 cas (celui des 5 images à 16s et celui des 80 images à 1s) On constate que le rapport signal sur bruit est bien comparable et en particulier, les étoiles faibles apparaissent aussi bien. On note toutefois une plus belle figure de diffraction de la grosse étoile Les bruits sont plus lissés sur la combinaison d'images de 16s. Par contre les étoiles faibles apparaissent beaucoup plus ponctuelles sur la combinaison d'images de 1s. Conclusion : les résultats sont assez similaires entre des prises de vue à 1s et des prises de vue à 16s. Avec une monture stable, il faut choisir des poses à 16s. Par contre, effectuer des acquisitions avec des temps de pose plus faibles (en descendant jusqu'à 1 seconde) ne dégrade pas beaucoup les résultats. Mesure du bruit de la LPI à basse température Dans congélateur à -17°C Une image simple avec pose de 16s : congel_16s1-1.bmp on trouve : Max : 187 Min : 97 Sigma : 4.5 On voit que le bruit est très réduit (écart-type). Bien que la mesure effectuée à 18°C ne soit pas très précise à cause de la saturation, on peut dire que le bruit a été réduit dans un rapport proche de 6 (5.7) Si le seul bruit thermique du capteur était en cause, la réduction due à une baisse de température de 35°C aurait du être égale à 2 à la puissance 5 soit 32 fois (le bruit étant divisé par 2 pour une baisse de température de 7 degrés). Malgrès tout, c'est une amélioration considérable, puisque pour avoir le même rapport signal sur bruit, 6 fois plus faible, il faudrait un temps de pose 36 fois plus important. On peut donc espérer des résultats spectaculaires sur un objet tel que M27 par rapport aux photos faites en plein été, en refroidissant la LPI, même de manière modérée avec un boitier entourant la caméra.

Pour les acquisitions de longue durée sur Jupiter, j'ai mis en ligne un petit logiciel Sur le forum Astronomie pratique : http://www.astrosurf.com/ubb/Forum2/HTML/017372.html

Bonjour, J'ai mis sur mon site une version expérimentale du logiciel permettant de traiter des séquences de longue durée sur Jupiter, en tenant compte de la rotation de la planète. L'interface a été un peu modifiée, avec une datation plus simple Il semble fonctionner correctement pour des séquences dont la durée atteint 10 minutes Je n'ai cependant pas fait beaucoup de tests et j'attend des avis si vous l'utilisez.Adresse du site http://www.astrosurf.com/astrotech

Bonjour, Effectivement, ce n'est que lorsque l'étoile est très loin (rayons parallèles) qu'un miroir parabolique fonctionne correctement : les rayons convergent en un point et parcourent la même distance (conservation du front d'onde). Sur une étoile artificielle proche, ce n'est pas le cas. J'avais écrit il y a quelque temps, un post à ce sujet qui semble avoir disparu à la suite du crash du serveur. J'avais écrit ce post à l'époque ou Pierro décrivait la réalisation d'une étoile artificielle avec une fibre optique multimode. (avec il me semble quelques débats houleux !) De toutes façons, mon post n'a soulevé aucun enthousiasme sur le forum et je n'ai donc pas poursuivi. Le projet était de faire un petit programme qui permette de faire un star test sur une étoile artificielle située à une distance modérée. Toutefois je n'ai jamais envisagé qu'il soit possible de faire un star test sur une étoile artificielle située à une distance aussi faible que 15 mètres car dans ce cas les erreurs correspondant à un grand nombre de longueur d'onde semblent impossibles à corriger. Le but était de permettre de réaliser un start test à une distance inférieure à une centaine de mètres (en fonction du diamètre et de la focale du télescope, au lieu de plusieurs kilomètres) en tenant compte de l'aberration de sphéricité artificielle introduite par cette distance faible, car on sait la calculer. Il est donc possible, en théorie, de tenir compte de ces aberrations artificielles pour reconstituer une image identique (ou assez proche) à celle d'une étoile placée à l'infini. S'il faut placer une étoile artificielle à plusieurs kilomètres cela ne présente pas d'intérêt, car outre l'aspect très peu pratique, les problèmes de luminosité à grande distance de l'étoile artificielle, la quantité d'air traversée, à travers des couches près du sol en plus, il vaut mieux utiliser une véritable étoile. Comme toujours, les idées théoriques doivent être validées par des manips concrètes pour vérifier, tout d'abord s'il n'y a pas d'erreur de raisonnement et ensuite si c'est utilisable en pratique.

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é.

Bonjour, Voici une petite image de galaxie prise avec une LPI dans la nuit du 23 au 24 Janvier. Image brute avec uniquement la soustraction des darks, la registration et l'addition de 432 poses de 16 secondes (la LPI n'est pas extrêmement sensible !) Difficile de rivaliser avec des APN ou des webcams mieux adaptées au ciel profond. Lieu : région d'Angers Heure : entre 0H05 et 2H13 (locale) Telescope : Newton 200/800 sur monture SkyView (Le suivi n'est pas très bon)

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.

Bonsoir et joyeux Noel à tous,J'ai retraité mes images. J'en ai conservé seulement 49. J'ai aussi éclairci l'image, mais c'est toujours sur le même AVI, avec son gamma mal ajusté. Le résultat me parait un peu moins flou, mais, du coup, la granulation ressort plus ! Compte tenu des déformations sur les images brutes, je compte faire un essai de la fonction DISTOR d'IRIS

Oui, l'image est trop sombre. La nuit, sur mon écran LCD, j'avais l'impression qu'elle était meilleure.

Bonjour, Un petit essai sur Copernic le Samedi 10 Décembre 2005 à 19H30 TU Lieu : région d'Angers Turbulence : très importante Télescope Sky Optic Observer 200/800 sur monture Sky View (configuration de base) Webcam : Toucam pro II Projection oculaire Sélection des 86 meilleures images (ou plutot les moins mauvaises) sur un AVI de plus de 2000 Registration et ondelettes : IRIS Le résultat est bien moyen, à cause de la turbulence et surtout à cause des vibrations de la monture transmises par le moteur pas à pas. Il ne travaille pas en micro pas ! J'ai fait de nombreux essais pour réduire ces vibrations (couroie, galet avec caoutchouc, fonctionnement à vitesse double et une roue 2 fois plus grande, cadre en bois léger avec masses aux extrémités pour réduire la fréquence des vibrations) mais aucun système n'a donné de résultats acceptables.

Bonjour, Dans le post : http://www.astrosurf.com/ubb/Forum2/HTML/014121.html j'avais fait un petit résumé, à partir de mon expérience personnelle sur l'utilisation de la LPI

Bonjour à tous J'utilise un Sky Optic 200/800 depuis 2 ans dans sa configuration de base, c'est à dire la version à 750 Euros avec monture SkyView I et sa motorisation en AD. Je confirme ce qui a déjà été dit à propos de la qualité du tube optique. Il est comparable à des télescopes de marque réputés. Il est aussi très pratique à transporter (70 cm de long), avec une collimation très stable (une fois qu'elle est faite !) Bien entendu il a les défauts d'un Newton ouvert à 4, c'est à dire : - une collimation extrêmement délicate (les principales erreurs de collimation évoluent comme l'inverse du cube de F/D). Elle est par exemple 2 fois plus délicate que la collimation d'un télescope ouvert à 5, qui n'est déjà pas très simple. Le décalage du miroir secondaire nécessaire pour récupérer toute la lumière devient très sensible avec cette ouverture et peut perturber l'utilisateur qui effectue la collimation. - la mise au point est aussi plus délicate, mais la latitude de mise au point est "seulement" liée au carré du rapport F/D - le champ sans déformation de coma est limité (en l'absence de correcteur) - l'obstruction est assez importante. Par contre, pour la monture Sky View I, il n'y a pas de miracle : elle n'est pas chère mais elle n'est vraiment pas stable. J'ai observé dans un tube identique monté sur une EQ6 et c'est nettement plus confortable. Mais c'est une configuration qui n'est plus à 750 Euros ! Cette monture possède une erreur périodique importante (qui d'ailleurs n'est pas vraiment périodique). Je n'ai pas sous la main la courbe que j'avais faite il y a presque 2 ans. La motorisation est mal compensée en fonction de la température. Sur ma monture, la vitesse est trop faible lorsque la température est supérieure à 15 degrés, trop élevée lorsque la température est inférieure à 10 degrés et à nouveau trop faible en dessous de 0 degré. Mais le plus gênant c'est qu'elle présente des vibrations à haute fréquence avec une amplitude d'environ 5 sec d'arc dans les meilleures conditions. Bien entendu si le tube n'est pas bien équilibré, lorsqu'il fait très froid et que la graisse est un peu figée et lorsque le sol est gelé, ces vibrations deviennent encore plus importantes. Elles ne sont pas très gênantes pour l'observation ou la photograpie du ciel profond, on s'en accomode en observation visuelle planétaire (en appuyant très légèrement l'oeil sur l'oeilleton) mais elles ne permettent pas d'obtenir des images planétaires de bonne qualité. On voit très bien l'effet de ces vibrations sur la division de Cassini qui apparait doublée. J'ai essayé différents système pour les atténuer (courroie pour l'entrainement, stabilisation du tube avec un cadre supportant 2 masses éloignées, etc...) sans grand succès. En conclusion, on trouve actuellement des tubes avec une qualité optique très acceptable à des prix très bas mais ce n'est pas le cas pour les montures.

Tom d'Orion > Oui mais si on rallonge le temps de pause, peut-on arriver à un résultat semblable ? Mais bien sûr. Pour obtenir un résultat comparable à acquisition de 1 heure réalisée avec des poses de 30s et une webcam modifiée, il suffit de cumuler des acquisitions à 5fps pendant 100 heures (ordre de grandeur) et de cumuler les 1 800 000 images obtenues (J'espère ne pas m'être trompé d'un zéro). Ne pas oublier que lorsqu'on fait des acquisitions à 5fps, le temps d'intégration est bien inférieur à 0.2s. En résumé, c'était envisageable lorsqu'on pouvait, par exemple en prenant un driver modifié sur les Vesta, réaliser des poses de près d'une seconde. Avec les nouvelles Toucam, il ne faut pas espérer obtenir de bons résultats en ciel profond en cumulant les images prises avec une webcam non modifiée.Tom d'Orion > Et en bidouillant avec les Dark, il y a pas moyen de supprimer des parasites ? He bien non. Le problème des parasites, c'est qu'ils sont aléatoires ! Ils n'auront pas la même valeur d'une image à l'autre, ni entre un dark et une image. On peut supposer en gros qu'ils suivent une distribution gaussienne et on montre qu'on peut améliorer le rapport signal / bruit en compositant les images, selon une valeur qui est égale, théoriquement, à la racine carrée du nombre d'images utilisées, mais on ne peut pas vraiment "bidouiller" pour les supprimer. On peut les rendre moins visibles en appliquant des filtres passe-bas (type filtre gaussien, etc), mais on répartira le défaut sur les pixels voisins. Quel que soit le traitement utilisé, on ne fabriquera pas d'information (à moins de prendre un outil de dessin avec une gomme !)