Comparaison des formats d’images issus des tubes « VA » automatisés actuels

Inventaire des images issues de télescopes « 2.0 »

Chaque télescope de type « VA » automatisé possède sa stratégie de capture « optimale » en fonction de ses caractéristiques optiques et de capteurs.

Par exemple : Unistellar Equinox V1 se base sur : IMX 224 + 112/450 + png & fits (sur demande)

Le but de cette étude est de réfléchir aux éléments nécessaires pour réaliser un pré-processus automatisé et adapté à plusieurs usages :

• traitement astrophoto standard (donc optimisation des détails de l’image)
• traitement photométrique (différence de luminosités de un ou plusieurs objets)
• traitement de détection d’objets (différence)

Une fois les images calibrées et estimées, une séquence pourra subir un traitement personnalisé par type de télescope.

Afin de traiter automatiquement les images via Python, il faut se pencher sur leurs caractéristiques techniques et les contenus obtenables…

De plus, le marché s’étend (ZWO rentre dans la danse) et il sera intéressant de voir quelles stratégies ces diverses compagnies ont sélectionné pour délivrer leur images.

Caractéristiques théoriques communes aux tubes étudiés :

• Ce sont tous des altazimutal (donc capture par « paliers »)
• Ils compensent la capture équatoriale par une rotation logicielle de l’image (afin de compenser l’angle de capteur fixe par rapport au ciel)
• Ils utilisent tous un « stacking » visant à produire en un temps « court » une image, tout en intégrant les contraintes de capture
• Ce sont des « petits » pixels (2-2.9 µm) et de faible focale (pour aider au pointage automatique)
• ils travaillent en pose « courtes » (< 1 sec) ou de « faible durées » (< 30 sec)
• Le suivi est perfectible, selon le choix des moteurs et engrenages…
• La mise en station, pointage et suivi sont totalement automatisés et la résolution astrométrique est systématiquement utilisée pour le pointage
• La mise au point (sur les réfracteurs) est souvent automatisée se base sur la FWMH des étoiles capturées
• De même, une solution pour la buée des réfracteurs est intégrée (vent ou chauffage)
• La batterie est intégrée au socle de la monture et offre quelques heures d’utilisation (et souvent la capacité d’être accompagnée par une batterie externe)
• Certains (Vaonis) intègrent des images en mosaïque en automatique, autorisant des champs plus large que la capture normale.

Remarque globale :

Rappelons que le but premier de ces fournisseurs est de rendre l’accès au ciel le plus « simple » possible au néophyte total. Et sur ce point, tous ont réussi leur pari, car « n’importe qui » (qui lit la documentation… 🙂 )  est devenu capable de pointer un objet invisible à l’œil nu  ou de réussir un marathon de Messier  !

Dans un cas (Unistellar), un mode « science participative » permet même d’utiliser les captures pour répondre à des analyses photométriques d’évènements. Dans ce mode, la capture peut s’exécuter avec des paramètres avancés.

L’autre pari, celui d’offrir une vue sur des objets du ciel depuis des zones lumineusement polluées est également réussi, avec des résultats variables selon le tube.
Mais en soit : on a technologiquement contourné l’obstacle au lieu de simplement le résoudre (diminuer ou couper l’éclairage), comme d’habitude !

Et un nouveau problème (typique de la génération IA) surgit… En créant désormais une nouvelle catégorie d’observateurs du ciel qui… Ignorent totalement le contenu celui-ci !

Soit ils ne le regardent plus, soit il n’apprennent plus à reconnaître les constellations ou les objets (même les planètes !), puisque c’est le tube qui cherche à leur place…

Trouver la Polaire est devenu un bouton dans le menu des étoiles proposées… Quand à savoir où elle se trouve réellement : plus nécessaire puisque la machine le sait ! 🙁

Cet article s’adresse donc à ceux qui sont encore curieux sur ce qu’ils observent ou veulent utiliser les facilités offertes par ces tubes pour continuer à traiter et observer des objets à la limite de leurs capacités techniques. Autant les exploiter à fond pour les facilités offertes.

Pour les autres où l’aspect science a peu d’intérêt, et si seule la qualité « rapide » les intéressent, le prix suffira pour les guider !
La régle, en astrophoto, est inchangée : une meilleure monture, optique et informatique pour la capture coûte plus cher… Le tout est de savoir où on veut s’arrêter.

Et la suite…

Cet article est donc dédié à revoir les caractéristiques : optiques, capteurs et images fournies par ces montures.
D’autres s’attaqueront à l’automatisation des traitements par catégorie ou modèles via Python
Et en finale, on déterminera les meilleures stratégies de traitement au cas par cas.

Vaonis

Deux télescopes seront analysés : le Vespera Pro (quand il sera disponible, ce qui n’est pas le cas à la date de rédaction) et le Vespera « originel ».

Vespera Pro

A ce stade, on n’en sait pas beaucoup plus… Une lentille de correction doit permettre de passer de 200 à 250mm de focale pour s’adapter au nouveau capteur qui va passer l’échantillonnage à 1.65, quasi le double du modèle standard (avec un champ quasi doublé aussi). L’application devrait permettre me traitement « full auto » et « full manuel » avec l’accès immédiat aux images.

Vespera

Je l’utilise depuis sa sortie, avec plus d’une centaine d’objets du ciel (et 200GB d’images) capturés sous divers latitudes et conditions de capture (dont mon ciel totalement lumineusement pollué du centre de la Belgique).

L’application permet la combinaison de deux modes :

• automatique et manuel au niveau durée d’exposition
• simple ou mosaïque au niveau des captures/empilements

Par défaut, la durée de capture est de 10 sec. Et le suivi semble optimal pour cette durée (voir tests sur 5 et 30sec).

Taille capteur : 1920 x 1080 = 2.073.600 pixels

Le IMX462, choisi par Vaonis, créé comme suite du IMX290, avec la même taille et nombre de pixels, a un bruit de lecture qui tombe bien en dessous de 1 électron, ce qui est intéressant pour le domaine.

Les caractéristiques techniques de lecture :

Et le choix du gain « par défaut » est cohérent (201.0) pour obtenir un bruit de lecture réduit.

Par contre, en efficacité de capture, les caractéristiques sont :

Ce qui donne une bien plus haute sensibilité dans l’IR, avec une sensibilité globale plus faible dans le bleu…

En le comparant au 290MC (ci-dessous), la différence est clairement visible.

En théorie, ce capteur serait donc plus adapté pour le planétaire (par exemple pour le 890 nm/CH4 dans Jupiter) que pour le « ciel profond » (avec 200/250mm de focale, on ne peut de toute façon guère s’attaquer au planétaire).

Evidemment, la grande sensibilité dans la Ha (656 nm) est améliorée, ce qui permettra une capture de nébuleuses plus facile. Était-ce le but recherché par les équipes Vaonis ?

Les images sont sauvées (selon les options) en trois formats. D’autres marques se sont ensuite inspirés de la démarche.

On dispose de : une image fits/jpeg toutes les x secondes, une tiff (soit finale, soit à la demande) et une jpeg finale (de-facto).
Les images fournies sont des « stacks » successifs…  Donc : on ne peut pas les traiter soi-même comme l’addition de pose unitaires… (on verra avec le Vespera Pro)

Le nombre des axes = 2, qui convient à une image à dématricer (via bayer GBRG), sur lesquelles il faudra appliquer les traitements habituels (décalage vers le vert, etc…). Un filtre de type CLS, sorti très peu de temps après, avec auto-détection lors de la capture doit influencer le traitement.

Notons que les images sont directement accessibles depuis la monture, via un transfert wifi (FTP), et cela même pendant une observation (donc pour vider la mémoire qui serait trop remplie…)

Vaonis : Images FITS

A l’analyse des images FITS  (directement via FTP depuis la monture) :

SIMPLE = T / file does conform to FITS standard 
BITPIX = 16 / number of bits per data pixel 
NAXIS = 2 / number of data axes 
NAXIS1 = 1920 / length of data axis 1 
NAXIS2 = 1080 / length of data axis 2 
EXTEND = T / FITS dataset may contain extensions 
BZERO = 32768 
BSCALE = 1 
DATE-OBS= '2023-08-22T20:08:46' / Capture time 
EXPOSURE= 10000 / [ms] Total Exposure Time 
TEMP = 22.2 / [C] Temperature 
FOCAL = 200 / [mm] Focal length 
INSTRUME= 'vespera-xxxxx' / VESPERA by Vaonis 
BAYERPAT= 'GBRG ' / Bayer pattern 
GAIN = 201 / [0.1dB] Sensor gain 
OFFSET = 240 / Camera brightness parameter 
PIXSZ = 2.9 / [um] Pixel size 
WB_B = 68 / White balance (blue) 
WB_R = 62 / White balance (red) 
FILTER = 'CLS ' COMMENT VESPERA by Vaonis

La description est complète, sauf : l’objet observé, qui se retrouvera dans le nom du fichier sauvé, ou dans les autres format images…

Image fits native sans filtre (sous ciel SQM 17.6, stack auto 10 images, M13)

Image fits native avec filtre (sous ciel SQM 18.4, stack 20 images, M27)

Vaonis : Images JPEG

A chaque « prise » stabilisée (surtout si on demande à la monture de travailler en mode mosaïque), une image jpeg du stack est générée.

Le format Jpeg est automatiquement traité pour fournir directement une version corrigée et équilibrée de l’image, il est également documenté (nom de l’observation et nombre de poses). Pour un usage visuel et de contrôle, la qualité nécessaire pour le but principal (grand public) est au rendez-vous.

Il est a remarquer deux éléments : en premier, c’est une image de stack et une perturbation (ex : satellite) va se montrer sur le stack pendant une bonne quantité de prises (surtout si plus longue…), en second : les images fournies en mode mosaïque sont plus fines et moins bruitées.

D’où l’intérêt grandissant du mode mosaïque qui élimine  directement les artefacts de capture, mais au prix de temps (et « captures » de travail)  de déplacement… Ex :  Si on règle la pose à 30 sec, un déplacement peu induire plusieurs images inutilisables (5 ou 6), donc : 1 image utile de 30 sec sur 300 sec !

Donc, une mosaïque sera plus efficace en un même temps donné avec une durée de pose réduite (on y reviendra). Sur des objets brillants et large, autant la réduire si on image avec des objets en mode planification ou manuel.

Ex : M42

Vaonis : Images TIFF

Si on ne demande pas manuellement (« export tiff » pendant la capture), l’image n’apparait qu’à la fin de la séquence de capture (stack maximal avant arrêt programmé, si en mode « planning », ou volontairement). A la différence des images jpeg 8 bits (cible grand public), le format tiff est en 32bits non compressé, d’un format plus réduit (1875×1039) pour supprimer les artefacts de rotation logicielle et contient toutes les informations utiles de la capture (objet, nbr de capture, temps total, ouverture, focale).

Bref : c’est LE format pour un traitement ultérieur idéal, en effet (la M42 ci-dessus est le résultat du traitement du tiff de capture).

Stratégie de capture sur une soirée (4h de capture)

La mémoire du modèle Vespera est de 10 GB, une image fits fait 4,5 MB, une image jpeg au environ de 0.5MB et une image tiff environ 11MB.

Si on active la sauvegarde en fits, à 10sec/capture et en voulant garder 20% de la mémoire disponible (pour les Tiff finaux), on aura droit : 8000(0.5+4.5), soit 1600 images ou  env. 4h de capture (sur 6h d’autonomie)… La question est : faut-il les fits, en finale ?
Examinons les stratégies ( sans sauvegarde via FTP en cours de capture) :

• en mode « capture simple », chaque image est considérée « valable : a 10 sec/capture => 1600 images (env 4 heures)
• en mode « mosaïque », des images sont considérées « perdues » : ce nombre varie assez fort selon la durée de capture, la taille de l’objet, la taille de zone de mosaïque et  la condition du ciel.
  • Sur un même objet durant la même nuit, en faisant varier la durée (de 5 à 30 sec), on passe de
    • 5 sec/capture : 148 considérées sur 184 prises (= 148 x 5 =  740 sec utiles sur 920 sec, soit 80%)
    • 30 sec/capture :  48 considérées sur 116 prises (= 48 x 30 =  1440 sec utiles sur 3480 sec, soit 41%)
  •  Sur une dizaine d’objets pris à 10 sec : la moyenne tourne autour de 80% d’images utiles (101/143, 236/283,  132/176, 473/504,…)
• en mode « science », c’est difficile de gérer des images qui sont le résultat d’un stack à chaque sortie…
  • la photométrie : quasi inexploitable… Sauf : sur la première prise ! (avec la durée de capture optimale pour le cas)
  • recherche d’objets : vu le champ large, le meilleur usage et exploitable (sans photométrie, évidemment).  Le stack continu peut également servir sur l’estimation d’objets rapides (comètes, par exemple)

Exemple : M33, mode Mosaïque

Conclusion pour la capture sur Vaonis :

• Ce n’est pas pour rien que 10 sec/capture est la valeur par défaut… 🙂 Donc, dans la majorité de cas, le bon choix…
• Avec une mosaïque, le gain entre pose plus courte et par défaut n’est pas significative, autant laisser par défaut.
• Pour l’usage « visualisation et partage », désactiver la sortie « fits » : elle ne va rien apporter, sauf remplir la mémoire et limiter le temps d’observation (en remplissant la mémoire).
• Pour le post-traitement : il faut (dans tous les cas) activer le TIFF !
• Pour le mode « science » : choisir durée/format en fonction du besoin…
• Remarque importante : comme on est sur une configuration « fermée » (tant au niveau concept, que utilisation), il n’est pas possible que récupérer ni flat, ni dark… Et c’est l’algorithme de stacking de Vaonis qui est maître.

Update de Novembre 2023 : le dernier update de l’application devrait désormais permettre un mode « expert » sur les captures. Pas encore testé, mais sera examiné dans le deuxième test à venir.

Unistellar

Unistellar Evscope/Equinox 1

Utilise (aussi) un capteur optimisé d’origine « planétaire », le IMX224, mais le modèle « LRQ » (basse intensité).

Le IMX224, de 1.27 Mpix (le plus petit capteur des tous les modèles)  a des caractéristiques bien connues des amateurs de planétaire, avec une vitesse et une taille de pixel adaptée. Les caractéristiques sont les suivantes :

La sensibilité est la plus standard pour la gamme IMX (avec moins de sensibilité IR).

Par contre, le choix « par défaut » du gain interpelle  (25.0) alors que le bruit de lecture chute passé 60, et que l’égalité de 1e/ADU est atteinte à 135.

Equinox V1 : Images PNG

Par défault, c’est le seul format d’image qui est mis disponible au niveau de l’application. Et si la vitesse d’apparition d’une image (très rapide) est à remarquer, la qualité n’est hélas pas vraiment au rendez-vous…

Premier essai (2021) sur comète 67P

On voit les effets de à la fois une MAP moyenne et d’une calibration moyenne…
Il a fallut plusieurs itérations pour totalement régler le tube…

Mais même à ce stade, les étoiles sont « empâtées » et l’image est « upscaled » pour optimiser sa taille sur smarphone, ce qui n’arrange rien !

Equinox V1 : Images Fits

Le fits est moins complet : pas de Debayer (considérer « RGGB » pour un IMX224) et le nom de l’objet aurait vraiment servi ! (Aucune mention dans les noms de fichiers transmis, ce qui oblige à une gestion des librairies relativement poussée).

Par contre la résolution est celle du capteur, sans les bricolages de l’image PNG.

SIMPLE = T / conforms to FITS standard 
BITPIX = 16 / array data type 
NAXIS = 2 / number of array dimensions 
NAXIS1 = 1304 
NAXIS2 = 976 
BUNIT = 'ADU ' 
ORIGIN = 'Unistellar' / institution responsible for creating this file 
DATE = '2022-01-20T11:52:54.618' / date of file creation 
TIMSYER = 0.2 / systematic error on time, in TIMEUNIT 
TELESCOP= 'eVscope v1.0' / name of telescope 
INSTRUME= 'IMX224 ' / name of instrument 
SERIALNB= 'xxxxxx ' / Serial number of the telescope 
DATE-OBS= '2022-01-12T00:34:47.942' / date of the start of the obs 
DATE-AVG= '2022-01-12T00:34:49.928' / date of the mid of the obs 
DATE-END= '2022-01-12T00:34:51.914' / date of the end of the obs 
MJD-OBS = 59591.02416599821 / modified Julian date of the start obs 
MJD-MID = 59591.02418898279 / modified Julian date of the mid obs 
MJD-END = 59591.02421196736 / modified Julian date of the end obs 
EXPTIME = 3.971754 / exposure time, in TIMEUNIT 
TIMEUNIT= 's ' / time unit 
GAIN = 0.1287111991587539 / gain in e-/ADU 
GAINDB = 25.0 / gain in decibel used in the eVscope 
OBSMODE = 'EnhancedVision' / observation mode of the frame 
PURPOSE = 'StackInput' / usage of the frame 
FOVRA = 97.9791 / Field of view Right Ascension in deg (J2000.0) 
FOVDEC = 4.9416 / Field of view Declination in deg (J2000.0) 
FOVXREF = 652 / X reference pixel for FOVRA, FOVDEC 
FOVYREF = 488 / Y reference pixel for FOVRA, FOVDEC 
BSCALE = 1 
BZERO = 32768 
END

Taille capteur : 1304 x 976 =  1.272.704 pixels

Chaque image est accompagnée d’un fichier JSON décrivant les conditions de captures.

{
"cameragain": "250cb",
"expotime": "3.971754s",
"focallength": "450mm",
"fovradecdeg": "296.2006, 50.525",
"fovradecdms": "19h44m48.144s, +50d31m30s",
"framePurpose": "StackInput",
"frameseqid": 0,
"imagedepth": 16,
"pipelinemode": "EnhancedVision",
"sensormodel": "IMX224",
"serialnumber": "xxxxxx",
"size": "1304x976",
"timestamp": "2022-01-05T05-53-41.328",
"version": 1.5
}

Depuis peu (détecté perso en octobre 2023), on peut (enfin) visiblement recevoir les images faite en mode « science », avec la possibilité de modifier les paramètres de capture. On y reviendra dans le chapitre suivant sue le modèle V2

Ce sont des poses unitaires, donc l’empilage s’effectue comme d’habitude, avec tri sur la qualité et le déplacement. Les moteurs du V1 ne permettent pas les poses longues et en mode « normal » : la durée de capture de toutes les images est donc fixée à 4 sec ( quelque soit la configuration sélectionnée en visualisation).

Exemple :

Ou le « bruit de rotation » est déjà fort visible…Dès que l’objet sera étalonné, il sera le principal problème à gérer.

Unistellar V2

Deuxième itération du modèle il intègre désormais un « vrai » 4 Mpix, le IMX347 (et pas une sortie png interpolée, comme dans le cas du V1).

C’est clairement un plus… Il faut cette taille de capteur pour ce type de tube.

Images PNG :

Cette fois-ci, le résultat est un peu meilleur, exploitant les 4 Mpix et un stacking un peu moins agressif.

Les images png ne restent utilisables qu’en visualisation directe, il faut passer aux FITS pour avancer dans des images complexes. Par contre, pour le suivi de « petits corps », les résultats obtenus avec le mode jpeg sont souvent très suffisants pour se faire une idée (la photométrie exige fits).

Mais quoi qu’il en soit, dans ce mode, on est toujours loin de la qualité des images issues de « base » via le Vespera…

Images fits :

Le fits évolue conformément aucapteur (mais toujours pas de bayer, ni de nom 🙁 ) :

SIMPLE  =                    T / conforms to FITS standard                      
BITPIX  =                   16 / array data type                                
NAXIS   =                    2 / number of array dimensions                     
NAXIS1  =                 2088                                                  
NAXIS2  =                 1536                                                  
BUNIT   = 'ADU     '                                                            
ORIGIN  = 'Unistellar'         / institution responsible for creating this file 
DATE    = '2023-04-17T08:03:55.778' / date of file creation                     
TIMSYER =                  0.2 / systematic error on time, in TIMEUNIT          
TELESCOP= 'eVscope v2.0'       / name of telescope                              
INSTRUME= 'IMX347  '           / name of instrument                             
SERIALNB= 'xxxxxx  '           / Serial number of the telescope                 
DATE-OBS= '2023-04-03T19:31:43.581' / date of the start of the obs              
DATE-AVG= '2023-04-03T19:31:45.581' / date of the mid of the obs                
DATE-END= '2023-04-03T19:31:47.581' / date of the end of the obs                
MJD-OBS =     60037.8136988543 / modified Julian date of the start obs          
MJD-MID =    60037.81372200232 / modified Julian date of the mid obs            
MJD-END =    60037.81374515034 / modified Julian date of the end obs            
EXPTIME =             3.999997 / exposure time, in TIMEUNIT                     
TIMEUNIT= 's       '           / time unit                                      
GAIN    =   0.1298063187045237 / gain in e-/ADU                                 
GAINDB  =                 18.3 / gain in decibel used in the eVscope            
OBSMODE = 'EnhancedVision'     / observation mode of the frame                  
PURPOSE = 'StackInput'         / usage of the frame                             
FOVRA   =             148.8882 / Field of view Right Ascension in deg (J2000.0) 
FOVDEC  =              69.0652 / Field of view Declination in deg (J2000.0)     
FOVXREF =                 1044 / X reference pixel for FOVRA, FOVDEC            
FOVYREF =                  768 / Y reference pixel for FOVRA, FOVDEC            
BSCALE  =                    1                                                  
BZERO   =                32768                                                  
END

On dispose aussi de nouveaux « modes » :

Mode science (« science_<objet> »), dans ce cas l’objet est « comet »

SIMPLE  =                    T / conforms to FITS standard
BITPIX  =                   16 / array data type
NAXIS   =                    2 / number of array dimensions
NAXIS1  =                 2088
NAXIS2  =                 1536
BUNIT   = 'ADU     '
ORIGIN  = 'Unistellar'         / institution responsible for creating this file
DATE    = '2023-09-25T11:33:26.651' / date of file creation
TIMSYER =                  0.2 / systematic error on time, in TIMEUNIT
TELESCOP= 'eVscope v2.0'       / name of telescope
INSTRUME= 'IMX347  '           / name of instrument
SERIALNB= 'xxxxxx  '           / Serial number of the telescope
DATE-OBS= '2023-09-25T03:26:45.342' / date of the start of the obs
DATE-AVG= '2023-09-25T03:26:47.327' / date of the mid of the obs
DATE-END= '2023-09-25T03:26:49.313' / date of the end of the obs
MJD-OBS =     60212.1435803473 / modified Julian date of the start obs
MJD-MID =    60212.14360332768 / modified Julian date of the mid obs
MJD-END =    60212.14362630807 / modified Julian date of the end obs
EXPTIME =             3.970986 / exposure time, in TIMEUNIT
TIMEUNIT= 's       '           / time unit
GAIN    =   0.1343474350276938 / gain in e-/ADU
GAINDB  =                 18.0 / gain in decibel used in the eVscope
OBSMODE = 'Science '           / observation mode of the frame
PURPOSE = 'Comet   '           / usage of the frame
FOVRA   =             88.33369 / Field of view Right Ascension in deg (J2000.0)
FOVDEC  =             35.83302 / Field of view Declination in deg (J2000.0)
FOVXREF =                 1044 / X reference pixel for FOVRA, FOVDEC
FOVYREF =                  768 / Y reference pixel for FOVRA, FOVDEC
BSCALE  =                    1
BZERO   =                32768
END

Avec un mode « object » qui varie selon le sujet : Comet, Darkframe (on y reviendra)

Mode planète (« PLANETEV »)

SIMPLE  =                    T / conforms to FITS standard
BITPIX  =                   16 / array data type
NAXIS   =                    2 / number of array dimensions
NAXIS1  =                 2088
NAXIS2  =                 1536
BUNIT   = 'ADU     '
ORIGIN  = 'Unistellar'         / institution responsible for creating this file
DATE    = '2023-09-18T05:52:29.190' / date of file creation
TIMSYER =                  0.2 / systematic error on time, in TIMEUNIT
TELESCOP= 'eVscope v2.0'       / name of telescope
INSTRUME= 'IMX347  '           / name of instrument
SERIALNB= 'xxxxxx  '           / Serial number of the telescope
DATE-OBS= '2023-09-15T01:38:42.817' / date of the start of the obs
DATE-AVG= '2023-09-15T01:38:42.818' / date of the mid of the obs
DATE-END= '2023-09-15T01:38:42.820' / date of the end of the obs
MJD-OBS =    60202.06855113106 / modified Julian date of the start obs
MJD-MID =     60202.0685511441 / modified Julian date of the mid obs
MJD-END =     60202.0685511576 / modified Julian date of the end obs
EXPTIME =             0.002283 / exposure time, in TIMEUNIT
TIMEUNIT= 's       '           / time unit
GAIN    =    1.057406857470196 / gain in e-/ADU
GAINDB  =                  0.0 / gain in decibel used in the eVscope
OBSMODE = 'PlanetEV'           / observation mode of the frame
PURPOSE = 'StackInput'         / usage of the frame
FOVRA   =             43.01367 / Field of view Right Ascension in deg (J2000.0)
FOVDEC  =             15.05218 / Field of view Declination in deg (J2000.0)
FOVXREF =                 1044 / X reference pixel for FOVRA, FOVDEC
FOVYREF =                  768 / Y reference pixel for FOVRA, FOVDEC
BSCALE  =                    1
BZERO   =                32768
END

Etc.. Ces modes sont déclenché via le choix de l’objet et le mode de capture choisi…

Dans le cas du planétaire, on passe visiblement dans un mode tout à fait spécifique, avec comme exemple cette Jupiter capturée par le V2 (mode visuel)

Et vu les caractéristiques du tube (vraiment pas optimisé pour le planétaire), il a fallut du traitement… 🙂

Darkframe

Un sujet en soi… Appelé d’abord par son nom, puis par « calibration », l’observation via un Newton (tube ouvert) oblige à trois contraintes :
– la calibration
– la mise au point
– la gestion du bruit…

En ce qui concerne le troisième, évidemment qu’il veut varier (fortement) selon les conditions d’utilisation. La fonction de calibration stocke (à la demande de l’utilisateur)  un master darkframe (20 images stack) dans l’application pour aider à le gérer.

En mode standard, uniquement les derniers master darks sont rendus avec les fits, en mode science on récupère toutes les images, ce qui permet de faire « son » master dark.

Sur (à la date de rédaction) une utilisation correcte des tubes (  1093 objets observé, dont  930 sur V1 et 163 sur V2), il est intéressant de voir le « vieillissement » du capteur via les darkframes en 2.5 ans est très uniforme, avec évidemment quelques « dead pixels » inévitables.

Pixelmath (+enhance pour visualiser les niveaux) sur 2 masterdarks, IMX224 (2021 et 2023)

Pas de soucis à ce stade, mais la question du remplacement du capteur (si nécessaire), dans un tube « fermé » se pose pour tous ces types de télescope.

Et les flats ?

Si on peut aisément comprendre que dans le cas d’un tube « fermé » (lunette), la question se pose moins, à part des saletés sur la lentille externe, dans le cas d’un Newton, les saletés et poussières circulent partout dans le tube !

Le capteur ayant pris la place du secondaire, il est certes « protégé » par une vitre ad-hoc, mais qui se salira forcément…
Donc : comment le nettoyer correctement ? Et comment le vérifier ? A ce stade, pas de réponse.

Conclusion pour Unistellar :

Le V1 est clairement à garder soit pour des exhibitions (la qualité suffit pour « montrer » un objet) ou faire de la science sur des petits objets (en sélectionnant impitoyablement dans les images) et un traitement strict.

On remarque que le logiciel évolue également, et que l’empilement fort agressif du début s’est réduit avec le temps…

Actuellement à la version 2.4, on peut considérer les éléments de captures suivants :

• l’empilage (trop) agressif sur les images PNG s’est réduit, mais est toujours présent. Sur le V1, cela améliore (un peu) les images directement accessibles
• Contrairement aux autres télescopes où l’accès aux images est immédiat, l’accès aux fits doit se faire via le site de Unistellar et un double échange de données (envoi de la mémoire et déchargement du site web)
• Une capture « très longue » n’aide pas trop, mieux vaut lancer plusieurs séquences de captures plus courtes.
  Ex : au lieu de 1h continu, faire 3 x 20 min. et  assembler les parties. Cela limitera le « bruit » de rotation tjs très important à l’empilage.
• Pour les mesures photométriques, il faut obligatoirement sélectionner les meilleures prises et valider la saturation des étoiles (nombre de fits empilées) pour obtenir une mesure valable. Mais les images unitaires sont parfaitement exploitables dans ces conditions.
• En mode science, depuis qu’on peut les accéder dans le déchargement, on va pouvoir (enfin) faire varier les conditions de capture, ce qui va permettre de calibrer les mesures.
• Pour les images « décoratives », il faudra se concentrer sur le V2 et beaucoup de traitements…
• C’est dans la recherche et la capture de « petits objets » et les phénomènes transitoires que ce télescope devient très utile… Pour les grands objets, son intérêt est très limité.

Exemples d’images « petits objets » :

Ex : Equinox 1, détection de la comète C2023/P1, mag 13, stack de 10 min

Ensuite, le V2 va être utilisé pour fournir des images de meilleure qualité.

Ex : Equinox 2, 2023P1, stack de 5 min, vue png, quelques jours après…

On remarque que le stack « png », légèrement traité, peut déjà suffire pour présenter un objet.

Sur des objets plus « nébuleux », il faut clairement ne pas trop estimer….

Ex : vue « png » sur NGC0404, 15min, 312 images (312×4 = 20 min) avec le V2 parfaitement calibré et mis au point (à refaire souvent)

Prenons deux traitements : « best » et « median »

Best : traitement complet (Siril) avec sélection élevée, sélection de 29 images (sur 312, soit 9%),
via FHWM et rondeur), calibration, stack, étalonnage, gradient, courbes  simples :

Median : traitement complet (Siril) avec sélection moyenne, sélection de 156 images (sur 312, soit 50%),
via FHWM et rondeur), calibration, stack, étalonnage, gradient, courbes+fond du ciel :

Pour que NGC0404 devienne correctement visible, il faut au moins une centaine d’images, dans ce cas-çi.  Mais de-facto, des « étoiles empâtées » apparaissent.. Pour disposer de la qualité du dessus, il faudrait statistiquement en prendre 5x plus (soit plus de 1.5h de capture, au lieu de 20 min…).

Dans le cas de Nébuleuse, un filtre serait bien utile ! Mais c’est une interdiction de la part de la firme d’en rajouter un… Sous peine de perdre la garantie. donc : attendre 2 ans et y aller !

Néanmoins, avec le V2, on peut tout de même « sortir » quelque chose.

M42, Equinox 2, 1h de capture, SIRIL + Affinity

ZWO

ZWO SeeStar 50

Un des derniers « Telescope V2.0 » du marché, lancé avec un prix très agressif pour conquérir le marché. Soulignons un ensemble d’éléments (capteur, mise au point, ASIAIR, optique, monture, filtres) assemblés à un prix très attractif. Si la qualité est effectivement au rendez-vous, il aura du succès.

Reprenons les caractéristiques :

Ce télescope est  certainement actuellement le plus léger VA de la série, avec un format de « poche » (env 3kg sans le pied), mais annoncé avec des fonctions fort étendues sur papier.  Citons l’accès direct aux images, une autonomie (limitée) de 4h de capture, la mise au point automatique, un suivi et capture basé sur le ZWO ASI Air (lite) et deux filtres : un PL (intégré et débrayable par logiciel) et un filtre solaire (manuel). Pour moins de 700 eur à la date de la rédaction de ce texte, c’est très complet !

D’un point de vue capteur, on utilise ici le même que celui du Vespera (donc inutile de reparler de ses caractéristiques) mais avec une focale (via un chemin optique replié) un poil plus longue (250 au lieu de 200) et un filtre PL intégré (avec peu d’information publiée sur ses caractéristiques, mais qui devrait rester relativement standard).

Notons que les images sont directement accessibles depuis la monture, via la connexion USB et cela même pendant une observation (donc pour vider la mémoire qui serait trop remplie…). Mais la batterie intégrée sera vide bien avant la mémoire… Car vu sa taille et le poids, elle a la durée de vie la plus courte des trois tubes examinés.

De nouveau, l’ajout d’une batterie externe permettra de faire « durer » les observations.

Par contre, il est a noter que la « vitesse » de traitement des images et des tâches d’astrométrie est la plus lente des trois.
Mais comme le prix est aussi le plus bas, cela parait cohérent. Si on veut plus rapide, il faudra payer plus cher (une monture ZWO AM5 seule coûte le prix de 4 SeeStar !)

Images JPEG

En mode « standard » (pas de sauvegarde d’images par capture), deux types d’image sont fournies en fin de stack dans la mémoire du télescope (accès via USB-C) : une fits « stackée », une Jpeg (visiblement de travail). Une autre JPEG sera stockée sur le smartphone de l’utilisateur. En soi, c’est la même démarche que les autres VA.

Le capteur étant un IMX462, donc la résolution disponible est de 1920×1080, qui ici sera produite en format « vertical » (inhabituel, car généralement, on maximise la largeur de champ pour les objets larges du ciel). Ex : Il faudra faire M31 en plusieurs fois et l’assembler ensuite…

La JPEG stockée du côté APP répond à cette taille. Mais la JPEG stockée localement est de 148×864 pixels => clairement un « preview » (de très basse qualité) inexploitable.

Pour l’image stockée du côté de l’APP, même combat que du côté Evscope : pas de description de la cible visée ni dans le fichier, ni les metadata, mais un numéro de série non exploitable pour la gestion des images.

Par contre, les informations ont été « incrustées » dans l’image même, par exemple :

On y voit apparaître objet, durée de capture, localisation et date de capture, mais dans l’image même.

Si on veut les exploiter, il faudra les extraire par une technique OCR, comme dans le cas de l’Evscope.

Il apparait déjà (et cela sera examiné après) que la capture est plus linéaire que dans les autres VA, à savoir :

• on utilise un ASI AIR (lite) pour l’essentiel des fonctions, donc il assume visiblement les captures comme le ferait le modèle « hors télescope »
• en mode full auto, le temps de pose est fixe (10 sec), ce qui n’est pas par hasard (rappel des notions examinées chez Vaonis), et a ce stade, je n’ai pas trouvé le moyen de modifier cela
• la capture et le stacking réalisé est le mode « standard » à ZWO, aka : à optimiser par ensuite…  Alors que les autres VA ont intégré un traitement spécifique, du moins dans l’image affichée, pour traiter spécifiquement la PL et la capture « rapide » des objets.

Conclusion sur base des tests effectués (conditions de ciel : Pleine Lune + PL, entre 16.5 et 17.4 SQM):

• Positif : si on veut traiter les images par après, pas de différence fondamentale avec celles prises par un ASI AIR en mode « live stacking », donc : très facilement ré-utilisable dans des workflows habituels (SIRIL, Pix, etc…)
• Positif : pas de phénomène de « sur-luminosité » sur les étoiles brillantes et une colorimétrie mieux contrôlée
• Négatif : il faudra systématiquement plus de temps de capture, et une capture de « 10 min » sous ZWO sera moins lumineuse que pour celles des deux autres, qui « optimisent » pour la présentation le format renvoyé sur l’APP.
• Négatif : la détection astrométrique est moins sensible dans les cas de ciel « difficile ». Sous un cas de pollution « maximal » (Lune + PL Bruxelloise typique), les « ratés » de traitement sont fréquents, tant que l’astrométrie que dans le traitement (« bloque » dans le stack).Sur 12 objets visés lors d’une séance test, tous les objets proches de la Lune (dont Jupiter) ou dans une zone PL marquée ont été « manqués » par l’astrométrie, alors que les deux autres VA ont mieux réussi leur positionnement. A noter que seul le Evscope, dans ce domaine, a fait un « sans faute » (Jupiter, par exemple, a été bien détecté par Vaonis, mais des bugs sont apparus dans le traitement des images).
  Après avoir testé sur un ciel « parfait », je n’ai pas rencontré de problème de positionnement. Donc : c’est bien la qualité du ciel qui est en cause pour les problèmes de positionnement.
• Négatif : qu’on soit sous un ciel pollué ou pas : le  suivi  n’est (vraiment) pas formidable et pose de vraies interrogations sur la fiabilité de la solution.
  Voir l’article dédié pour une explication plus complète

Petite particularité ZWO que j’ai apprise récemment…
Savez-vous que la traduction des cartes (en Français) a du être faite par un revendeur, et non pas la firme elle-même !
Pour une firme chinoise, disposer à l’international d’une carte traduite n’est visiblement une priorité…  🙁

Comme quoi, avoir un potentiel de 1.5 Milliard de client « locaux », cela change les points de vue…

Le mode « recherche » est lui, bien en français (ou anglais, selon le choix)…

Mais cela m’interpelle, en terme « fiabilité » et test sur la carte… Car une erreur (humaine) est toujours possible, donc : les tests complets ont-ils été réalisés ?
Peut-être, mais j’en doute… « Quand on est dans le bricolo, on le reste » (vieux principe IT… 🙂 )

Format FITS:

Fort complet, avec des données de calibration présentes, mais un format « fixed length » (pas de LF ou CRLF) qu’il faut prendre en compte pour le décodage des metadata

SIMPLE = T / file does conform to FITS standard 
BITPIX = 16 / number of bits per data pixel 
NAXIS = 3 / number of data axes 
NAXIS1 = 1080 / length of data axis 1 
NAXIS2 = 1920 / length of data axis 2 
NAXIS3 = 3 / length of data axis 3 
EXTEND = T / FITS dataset may contain extensions 
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H 
BZERO = 32768 / offset data range to that of unsigned short 
BSCALE = 1 / default scaling factor 
CREATOR = 'ZWO SeestarS50' / Capture software 
XORGSUBF= 0 / Subframe X position in binned pixels 
YORGSUBF= 0 / Subframe Y position in binned pixels 
FOCALLEN= 250 / Focal length of telescope in mm 
XBINNING= 1 / Camera X Bin 
YBINNING= 1 / Camera Y Bin 
CCDXBIN = 1 / Camera X Bin 
CCDYBIN = 1 / Camera Y Bin 
XPIXSZ = 2.90000009536743 / pixel size in microns (with binning) 
YPIXSZ = 2.90000009536743 / pixel size in microns (with binning) 
IMAGETYP= 'Light ' / Type of image 
STACKCNT= 60 / Stack frames 
EXPOSURE= 10. / Exposure time in seconds 
EXPTIME = 10. / Exposure time in seconds 
CCD-TEMP= 22.3125 / sensor temperature in C 
RA = 300.137505 / Object Right Ascension in degrees 
DEC = 22.803056 / Object Declination in degrees 
DATE-OBS= '2023-10-29T19:40:48.840116' / Image created time 
FILTER = 'LP ' / Filter used when taking image 
INSTRUME= 'ZWO ASI462MC' / Camera model 
BAYERPAT= 'GRBG ' / Bayer pattern 
GAIN = 80 / Gain Value 
FOCUSPOS= 1732 / Focuser position in steps 
CTYPE1 = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions 
CTYPE2 = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions 
CRVAL1 = 300.080455245 / RA of reference point 
CRVAL2 = 22.7485634804 / DEC of reference point 
CRPIX1 = 297.741333961 / X reference pixel 
CRPIX2 = 1287.31164551 / Y reference pixel 
CD1_1 = -0.000547544177343 / Transformation matrix 
CD1_2 = -0.000365859232261 / no comment 
CD2_1 = 0.000365466726437 / no comment 
CD2_2 = -0.000547357778746 / no comment 
A_ORDER = 2 / Polynomial order, axis 1 
B_ORDER = 2 / Polynomial order, axis 2 
AP_ORDER= 2 / Inv polynomial order, axis 1 
BP_ORDER= 2 / Inv polynomial order, axis 2 
A_0_0 = 0 / no comment 
A_0_1 = 0 / no comment 
A_0_2 = -1.46648628202E-07 / no comment 
A_1_0 = 0 / no comment 
A_1_1 = -1.32017298075E-07 / no comment 
A_2_0 = -7.68287071451E-07 / no comment 
B_0_0 = 0 / no comment 
B_0_1 = 0 / no comment 
B_0_2 = 2.12501720712E-08 / no comment 
B_1_0 = 0 / no comment 
B_1_1 = 3.742917819E-07 / no comment 
B_2_0 = -3.27089991787E-07 / no comment 
AP_0_0 = -3.76836542435E-05 / no comment 
AP_0_1 = 4.0079957692E-08 / no comment 
AP_0_2 = 1.46667282805E-07 / no comment 
AP_1_0 = 9.77504803393E-08 / no comment 
AP_1_1 = 1.32102007821E-07 / no comment 
AP_2_0 = 7.69061907425E-07 / no comment 
BP_0_0 = -2.5223450943E-05 / no comment 
BP_0_1 = -6.73604843036E-09 / no comment 
BP_0_2 = -2.11800988299E-08 / no comment 
BP_1_0 = 7.79160184437E-09 / no comment 
BP_1_1 = -3.74374228317E-07 / no comment 
BP_2_0 = 3.27391012832E-07 / no comment 
IMAGEW = 1080 / Image width, in pixels. 
IMAGEH = 1920 / Image height, in pixels. 
END 

Comme l’image est le résultat du stack, elle est directement fournie au format RGB (3 axes) et donc déjà « dématricée » via GRBG et un algo choisi par ZWO (lequel ? pas d’info) . Donc le traitement va se limiter au paramètres minimums.

Ex dans l’image ci-dessous, pas de chance, on ne sait pas enlever le satellite !
=> il faudra regarder si le mode « sauver chaque image » fournira bien toutes les images nécessaires au traitement.

Ex : après un post-traitement relativement simple (SIRIL : suppression de bruit vert et étalonnage astrométrique), on obtient une image plus utilisable :

Une anomalie que l’on détecte de suite… Remarquée (aussi) sur d’autres images.

Repartons d’une version du ciel de « référence » (image venant de SDSS, via Aladin) sur la région de M27 et 14 Vul, recadrée et orientée de la même manière que la M27 capturée par le ZWO

Si on compare avec la zone près de 14 Vul dans l’image :

Pas de trace de cette « ligne » fort brillante dans l’image, ni dans les autres captures prises au même moment…

Format FITS (update de la version 1.11.0, apparemment) :

SIMPLE = T / file does conform to FITS standard
BITPIX = 16 / number of bits per data pixel
NAXIS = 3 / number of data axes
NAXIS1 = 1080 / length of data axis 1
NAXIS2 = 1920 / length of data axis 2
NAXIS3 = 3 / length of data axis 3
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
BZERO = 32768 / offset data range to that of unsigned short
BSCALE = 1 / default scaling factor
CREATOR = 'ZWO SeestarS50' / Capture software
XORGSUBF= 0 / Subframe X position in binned pixels
YORGSUBF= 0 / Subframe Y position in binned pixels
FOCALLEN= 250 / Focal length of telescope in mm
XBINNING= 1 / Camera X Bin
YBINNING= 1 / Camera Y Bin
CCDXBIN = 1 / Camera X Bin
CCDYBIN = 1 / Camera Y Bin
XPIXSZ = 2.90000009536743 / pixel size in microns (with binning)
YPIXSZ = 2.90000009536743 / pixel size in microns (with binning)
IMAGETYP= 'Light ' / Type of image
STACKCNT= 160 / Stack frames
EXPOSURE= 10. / Exposure time in seconds
EXPTIME = 10. / Exposure time in seconds
CCD-TEMP= 7.25 / sensor temperature in C
RA = 98.28333 / Object Right Ascension in degrees
DEC = 5.1225 / Object Declination in degrees
SITELONG= x.xxxxxx / longitude of the imaging site in degrees
SITELAT = xx.xxxxxx / latitude of the imaging site in degrees
DATE-OBS= '2023-12-03T00:44:00.792987' / Image created time
FILTER = 'LP ' / Filter used when taking image
INSTRUME= 'Seestar S50' / Camera model
BAYERPAT= 'GRBG ' / Bayer pattern
GAIN = 80 / Gain Value
FOCUSPOS= 1743 / Focuser position in steps
TELESCOP= 'Seestar S50' / Telescope name
OBJECT = 'NGC 2237' / name or catalog number of object being imaged
CTYPE1 = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
CTYPE2 = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
CRVAL1 = 97.987165777 / RA of reference point
CRVAL2 = 5.15032384653 / DEC of reference point
CRPIX1 = 505.159049988 / X reference pixel
CRPIX2 = 962.006053925 / Y reference pixel
CD1_1 = -0.000597184478318 / Transformation matrix
CD1_2 = 0.000277928249092 / no comment
CD2_1 = -0.000278080375916 / no comment
CD2_2 = -0.00059744865808 / no comment
A_ORDER = 2 / Polynomial order, axis 1
B_ORDER = 2 / Polynomial order, axis 2
AP_ORDER= 2 / Inv polynomial order, axis 1
BP_ORDER= 2 / Inv polynomial order, axis 2
A_0_0 = 0 / no comment
A_0_1 = 0 / no comment
A_0_2 = -9.25108167985E-08 / no comment
A_1_0 = 0 / no comment
A_1_1 = -6.93647954535E-07 / no comment
A_2_0 = 2.93103738282E-07 / no comment
B_0_0 = 0 / no comment
B_0_1 = 0 / no comment
B_0_2 = 3.74024663208E-07 / no comment
B_1_0 = 0 / no comment
B_1_1 = 3.83777066924E-08 / no comment
B_2_0 = -3.54527809009E-07 / no comment
AP_0_0 = -4.69273743654E-06 / no comment
AP_0_1 = -6.15759423105E-08 / no comment
AP_0_2 = 9.25165018216E-08 / no comment
AP_1_0 = 1.2904901521E-07 / no comment
AP_1_1 = 6.93607663477E-07 / no comment
AP_2_0 = -2.93058698967E-07 / no comment
BP_0_0 = 8.71882615779E-07 / no comment
BP_0_1 = 1.87625962995E-07 / no comment
BP_0_2 = -3.74023477301E-07 / no comment
BP_1_0 = -1.35595202996E-08 / no comment
BP_1_1 = -3.83613904468E-08 / no comment
BP_2_0 = 3.54504044381E-07 / no comment
IMAGEW = 1080 / Image width, in pixels.
IMAGEH = 1920 / Image height, in pixels.
END

Dans la dernière mise à jour, une nouvelle données fort intéressante :
SITELONG= xx.xxxxxx / longitude of the imaging site in degrees
SITELAT = xx.xxxxxx / latitude of the imaging site in degrees

Cette nouvelle information présente m’a à la fois surpris et intéressé.

Intéressé : que ZWO y ait pensé que c’était utile.. Et en creusant, j’ai trouvé des choses intéressantes, que je décrirai dans un autre article.

Surpris : Sinon car le seul télescope « 2.0 » qui fournissait cette information de localisation était le Unistellar, mais uniquement dans le mode « oculaire simulé » (PNG) et ‘lisible », sous forme d’une incrustation dans l’image.
Donc : obligatoire de faire de l’OCR pour l’extraire de l’image.

Dans d’autres image prises de M27 via un autre SeeStar, merci à Pascal (il se reconnaîtra) pour l’envoi… Aucune trace.

Anomalie de capture, phénomène atmosphérique, artefact de traitement ?

Pendant UNE bonne nuit (voir article dédié), je suis parvenu à avoir UNE image digne d’être traitée (26 min de pose), avec cependant un objet iconique : la célèbre « Tête de cheval »

Pris sous un ciel d’hiver idéal, avec SQM 20.89, l’image est cependant intéressante…

Un petit traitement sera le bienvenu pour optimiser cela… Et sur base du fits, tenter de « contenir » la luminosité de Alnitak.

Comparaison globale avec pré-traitement basique des images

Appliquons le même processus aux images issues des 4 télescopes :

• ouverture des images « stacked » (format fits)
• dématriçage
• mise à l’échelle 1:1
• équilibrage global

Cela donne, pour le même objet (M27) :

Evidemment, la différence qui sera nécessaire pour le traitement automatisé saute directement aux yeux…

• Pour les images issues des modèles Unistellar, un pré-processus d’empilage avec traitement des darks suffira.
  (Il faudra réfléchir à l’utilisation d’un « drizzle » selon les besoins…)
• Pour les images issues des modèles Vaonis et ZWO, il faudra rajouter un étalonnage plus poussé pour récupérer un niveau cohérent.

Cela fera donc l’objet d’une programmation spécifique par télescope (en Python, évidemment).

Tests en situation réelle et résultats

Test 1 : sous ciel fortement pollué et pleine Lune

Magnitude SQM : 16.2, max 17.5

Nombre d’étoiles visibles visuellement : moins d’une dizaine…

Les trois télescopes étaient à la distance minimale pour ne pas se gêner entre-eux lors de mouvements et ont reçus les mêmes objets à observer pendant la même durée. La visualisation est assurée par PixInsight, l’image est ouverte SANS aucun traitement effectué, excepté un « fit to size » pour l’affichage

M27, 10 min

De gauche à droite : image ZWO jpeg « basse qualité », image ZWO JPEG « stacked » finale et Vespera image JPEG « stacked » finale

M29, 11 min

NGC7640,  10 min

Remarque : si l’image Vespera est correcte en terme de durée, l’image ZWO ne montre que le résultat sur 2 min de stack, car la capture s’est bloquée et n’a jamais voulu continuer (il a fallu couper brutalement pour en sortir).

Ce phénomène s’est produit plusieurs fois (3) sur différents objets du ciel…

En ce qui concerne l’espace « subjectif » de comparer les images, je laisse le lecteur déterminer ses conclusions tout seul. Je préfère m’attaquer à des éléments plus objectifs.

Détails de M29, analyse plus détaillée :

Format d’image : JPEG, 8 bits...
A gauche : Evscope, au milieu : Vespera et à droite : ZWO
Même condition de ciel (PL extrême), durée et période de capture identique (10 min, vers 20-21h)

On peut maintenant examiner les effets des différentes stratégies logicielles implémentées :

• L’image de Evscope montre un ciel parfaitement « découpé » avec des étoiles parfaitement isolée, mais une colorimétrie « effacée » par l’algorithme assez agressif de stacking. Le but de « montrer » rapidement des objets, donc, tout pixel est additionné avec un seuil très haut.
  => la moitié du temps aurait pu suffire à montrer l’objet. En fait, en 3 min, la visibilité était déjà complète et la sursaturation commençait.
• L’image de Vespera montre un équilibre entre l’exigence de « rapidité d’affichage » et la netteté… Même si les étoiles sont brillantes, la colorimétrie est respectée et on exploite au maximum les capacités du 462. Mais le stacking « amélioré » influence évidemment la taille des étoiles.
  => l’équilibre entre les exigences de rapidité et la qualité d’image est correctement atteinte en 6 min.
• L’image ZWO, sur la même durée est largement plus faible, sans accentuation. Il faudra largement plus de temps (le double ?) pour « rattraper » les deux autres. Mais cet ajout de temps permet de garder une finesse des étoiles plus contrôlée.
  => il faudra 18 min pour quasi atteindre le niveau des images de Vespera.

Détails de NGC884, analyse plus détaillée :

Format d’image : JPEG, TIF, FITS, 8 et 32 bits...

Même condition de ciel (PL extrême), durée et période de capture identique (10 min, vers 20-21h)

De gauche à droite : ZWO 8bits (APP) , ZWO FITS (dans le télescope), Vespera (TIF, dans le télescope), Vespera JPEG (dans l’APP)

Cette fois-çi, on intègre également la « haute qualité » des images délivrées par le même capteur. La seule action graphique réalisée sur toutes les images est un « ScreenTransferFunction » (Pix) visant à équilibrer les niveaux des objects faibles.

Du côté ZWO, la différence est minime, uniquement due à l’augmentation de la dynamique de l’image.

Du côté Vespera, c’est la dégradation vers JPEG qui influence la netteté, mais l’intensité reste largement plus haute.

Mais dans les deux cas, la colorimétrie reste bien contrôlée.

En un usage « plus astronomique », le stacking de la ZWO ne semble par uniforme (sur plusieurs images de la même zone)… Plusieurs tests de photométrie ne sont pas cohérents entre-eux. Il faudra examiner les images « individuelles » et les options disponibles pour conclure.

D’ailleurs, le stacking du Vespera pose le même problème, le processus d’optimisation itératif semble modifier les caractéristiques de luminosité à un moment donné. Si on pense à la complexité ajoutée du mode « mosaïque automatique » (qui est une réussite, soit dit en passant) cela parait normal d’avoir des ajustements au fur et à mesure du temps.

Vaonis annonce d’ailleurs un mode « expert » dans sa prochaine version de son logiciel qui devrait permettre de récupérer toutes les images techniques et de fixer tous les paramètres de capture.

Détails de NGC7640, analyse plus détaillée :

Format d’image : JPEG, TIF, FITS 8, 32 bits...
Même condition de ciel (PL extrême), durée et période de capture identique (10 min, vers 20-21h)

Le choix de cet objet était une tentative pour déterminer les capacités optiques réelles des tubes.
NGC 7640 est une galaxie spirale barrée relativement rapprochée, vue de biais et située dans la constellation d’Andromède. Elle a été découverte par l’astronome germano-britannique William Herschel en 1784.

Avec une brillance de surface égale à 14,49 mag/am2, on peut qualifier NGC 7640 de galaxie à faible brillance de surface (LSB en anglais pour low surface brightness). Les galaxies LSB sont des galaxies diffuses (D) avec une brillance de surface inférieure de moins d’une magnitude à celle du ciel nocturne ambiant.

La galaxie vue par Hubble :

Déclinaison (δ) +40° 50′ 43,5″ 1
Magnitude apparente (V) 11,3, 11,9 (B2)
Brillance de surface 14,49 mag/arcmin²
Dimensions apparentes (V) 10,5′ × 1,8′

Sur le ZWO, avec un échantillonnage de  2.32 arcsec/pix, cela fait 45 pixels de large… (la résolution optique étant de 2.4 arcsec et la perturbation de certainement 2.5 arcsec dans les conditions météo de la capture, on est dans la limite de ce qu’un 50mm pourrait atteindre distinguer… )

Sur le Vespera, S=2.99, on joue sur  36 pix de large.

Sur le Equinox 2, S=1.33 et R=1.07, on passe à  81 pix de large

Comme d’habitude, la taille de l’optique jouera son rôle, mais parvenir à observer cet objet sous un ciel pollué lumineusement est certainement difficile… Tant pour le pointage, la mise au point que la capture automatique.

Voyons ce que l’on obtient.

Image ZWO (FIT)

Le header indique

STACKCNT= 15 / Stack frames
EXPOSURE= 10. / Exposure time in seconds
EXPTIME = 10. / Exposure time in seconds

=> donc, 15×10 = 150 sec ou 2min 30 sec de stack, alors que la capture était toujours active (pendant 10 min).
Cela confirme bien que le processus s’est arrêté, pour une cause ou l’autre (astrométrie défaillante ?)

Traitement (SIRIL) = pas de dématricage (fournie en RGB), pas de Dark, étalonnage astrométrique, histogramme pour augmenter la visibilité, pas de traitement de gradient

On voit que la rotation de champ est importante, l’alignement moins précis et le bruit fort présent, tout cela pour 2 min (cf les images précédentes, qui montrent un stack parfait sur 10min et un bruit sur le même ciel, bien plus contrôlé)  ce qui pourrait confirmer la perte de suivi…. Mais l’objet est bien centré et on peut vaguement le distinguer.

Image Vespera (JPEG, FITS, TIFF)

66 images de 10 sec, soit 11min stack, sans anomalie.

Le format JPEG est déjà suffisant pour distinguer l’objet au centre de la capture. Une simple correction de niveau suffirait pour la distinguer, en exploitant le format tiff, on peut voir que sa taille est approximativement de 38 pix de large

Ce qui « colle » environ à la théorie…

Image Equinox 2 (JPEG, FITS)

66 images de 10 sec, soit 11min stack, sans anomalie.

Tout est déjà dit dès l’image « JPEG » iconique de la marque (crop avec information de capture).

La galaxie se distingue correctement,  découpée sur le fond du ciel, avec son « nuage » caractéristique.

En ouvrant la « Stack » en FITS, même sans traitement, on distingue parfaitement la nature spiralée de l’objet et les objets environnants.

Et si on retraite les fits individuels   (SIRIL : séquence, dark, alignement, drizzle, empilement, étalonnage, niveaux, puis Affinity pour se concentrer sur la Galaxie)

On commence à avoir des détails crédibles… Mais pour en savoir plus, il faudra évidemment : une plus grande focale et diamètre !

 

Conclusions actuelles sur le test « Ciel pollué PL »

On peut largement mesurer la performance accomplie sur ces « petits » tubes en mode « full automatique » !

Il y a 15 ans d’ici, la performance atteinte de fournir une image utilisable an quelques minutes serait de la haute voltige (et certainement pas sous un ciel de 17 SQM !), alors que aujourd’hui, il suffit d’appuyer sur un bouton…

Il n’en reste que ce sont des « petits » tubes, et que le diamètre de 50mm, pratique à mettre dans un volume compact est tout de même un facteur restrictif une fois que l’on s’est intéressé aux « grands » objets du ciel. En soi : on en fait vite le tour…

Donc, dans le mode « grand public »

Ce qui veut dire : présentation des « objets » classiques (M7, M81, M31, etc..) => inutile de prévoir un post-traitement spécifique… Et la qualité « JPEG » suffit pour les besoins.

Clairement, c’est le Vespera qui s’en sort le mieux dans l’exercice de « qualité des images » et « acquisition » et dans ce cas de condition de ciel fort complexe, il a été au bout de sa mission sans problème avec un résultat constant. Quand au mode « mosaique », il apporte un confort inégalé dans la sélection des cibles multiples.  Le Vespera « Pro » est donc attendu avec intérêt…

Par contre, en terme de « rapidité de capture » et « positionnement » pour montrer le plus d’objets pendant la même période de temps, c’est le Equinox qui est clairement le plus rapide, même sur des objets difficiles. La qualité directement disponible n’est pas la priorité, et les nébuleuses « Ha » ne sont guère accessibles sans post-traitement (et filtre !).

Et le ZWO se positionne clairement entre les deux ! Mais si la qualité individuelle des images est au rendez-vous et la facilité de capture également, mais il faudra

• plus de temps pour les acquérir
• parvenir à pouvoir les acquérir ! (voir article dédié…)
•  Sa batterie limitant la durée d’utilisation, il faudra lui rajouter un power bank pour faire la nuit complète, mais cela fonctionne sans problème.

Donc, pour une éclipse, une soirée « astro » autour du barbecue : le rapport « prix/qualité » du ZWO est indiscutable. Mais en terme de qualité logicielle de la solution : il n’est vraiment pas au niveau des autres (en tout cas dans la version logicielle actuelle).

Dans le mode « astronomie pure »

Là, le besoin change… Si on découvre une Nova, cela serait bien de pouvoir estimer sa luminosité… Et en voyage, quel télescope emporter pour capturer des objets du ciel inhabituels ?

Si la « portabilité et qualité » est la priorité, c’est le Vespera qui sera considéré. Et si doit se rendre sous le ciel d’un Dark Sky park, à Teneriffe ou au Chili, je partirai avec le Vespera PRO, en sa basant sur l’évolution du capteur et la capacité (annoncée) de contrôler tous les paramêtres de capture !

Si je veux faire de « l’observation » : l’occultation, des transits d’exoplanète, des étoiles variables ou la poursuite de « petits objets », il faudra que je garde le Equinox 2 (en mode « science », le plus souvent) avec moi.

Quand au ZWO… Il est destiné à rester disponible, grâce à sa « portabilité record » (3kg) dans le coffre de la voiture et être rapidement disponible si l’occasion se présente.
En contrôlant manuellement la capture, on pourra peut-être exploiter les images pour des mesures précises, mais il faudra insister !

Je ne me positionne donc pas sur un « choix », car cela dépend du but de chacun…
Et perso, je considère que les trois tubes sont complémentaires… Je les utiliserai en fonction du cas et du besoin.

Ex : Grand public : peut importe… Eclipse = Vespera ou ZWO, Observation astro pure : Equinox, ciel profond et large objets : Vespera, itinérance légère ou évènement très transitoire : ZWO, etc…

Test 2 : sous ciel faiblement pollué et nuit noire

Dès que réalisé avec un ciel clément, il sera commenté… 🙂

Il ne concernera que le Vespera et l’Equinox, avec le ZWO SeeStar, les résultats actuels montrent qu’il n’est pas capable de suivre les autres….

En attendant, j’i pu réaliser UN test avec le SeeStar, dont voici le résultats, comparé au Vespera.

Détails de IC434, analyse plus détaillée :

Image SeeStar (JPG,FIT)

Je rajoute ici un petit traitement sur la seule image survivante d’une nuit de capture sous un ciel pourtant idéal… Pour les détails, allez voir la page dédié, mais ici, je reviens sur ce que l’on peut obtenir en examinant le résultat  pour ce télescope dans les meilleures conditions théoriques.

Images JPEG (8 bits) :

 

Après une simple mise à niveau de l’image « Stacked Tiff »

Image Vespera (JPEG)

Afin de montrer une différence intéressante, voici une comparaison entre l’image de la même zone mais issue de la version JPEG d’un Vespera… (format Mosaïque)

Comme la durée de capture sur Vespera n’est (heureusement) pas identique, je ne vais pas les comparer techniquement…

Mais pour comparer, il faudrait parvenir à la réaliser sur SeeStar, ce qui est loin d’être gagné aujourd’hui !

• Les poses longues posent problèmes…
• pas de mode mosaïque, donc : à réaliser manuellement (et le point précédant est critique pour cela)

Mais cela montre la différence de niveau (et capacités) entre les deux solutions, on ne joue pas dans la même cour.

Revenez lire ici de temps en temps pour le reste de la comparaison…