nico1038

J'ai utilisé Narrowband Normalization avec ces paramètres: Je te joins le fichier xisf pour que tu puisses regarder son historique. Ça te donnera une idée des opérations que j'ai effectué (même si ça n'est pas toujours très clair...): IC410.xisf

Hello @Archer92 Très belle image mais je préfère la V1 car j'aime mieux quand il y a des étoiles! Voici une version très différente (pour les couleurs j'ai utilisé le process NarrowbandNormalisation): Nico

Avant de vouloir faire ressortir les nébuleuses, il faudrait déjà avoir les bras 😉 Je crois vraiement que tu aurais un résultat infiniment meilleur sans filtre Mais quel est le message? Peux tu refaire un screenshot en poussant juste la fenêtre pour qu'on voit la console en entier?

Hello @yannusbonus Il y a très peu de signal sur cette image et des méchants gradients. Je pense que tu as utilisé un filtre très restrictif et c'est une mauvaise idée sur ce genre de cible. Tu devrais pouvoir obtenir beaucoup mieux avec ce temps de pose global. Tes conditions de ciel sont elles très difficiles? En tous cas il n'est vraiement pas évident de faire ressortir la galaxie, voilà ce que j'obtiens: Pour la résolution dans Siril ça fonctionne chez moi directement avec ton fichier. Je vois sur ton screenshot un message rouge qui parle d'internet: quel est-il exactement et avais tu bien une connexion au moment ou tu as lancé cette résolution?

Et bien non, pas vraiment: le mode eqmod est un moyen particulier de connexion aux montures Skywatcher qui délègue la totalité du contrôle de la monture à un appareil externe (en l’occurrence l'Asiair). En gros en mode suivi l'Asiair va juste envoyer un ordre de tracking qui fera donc juste tourner l'axe d’ascension droite. Cela ne peut donc pas fonctionner sans une adaptation pour le mode azimutale. Si tu vas voir le lien donné au dessus il semble bien que le mode Azimutale ne soit pas vraiment supporté pour l'AZGTI Comme je l'explique plus haut, le platesolve de l'Asiair n'est pas un "blind solver". Il a besoin de savoir approximativement dans quelle région du ciel il pointe. Si le goto ne fonctionne pas alors le platesolve ne fonctionnera pas.

Le truc c'est que l'Asiair n'est vraiment pas conçu autour du planétaire et de l'azimutale. Je ne suis pas complétement sûr par exemple que l’utilisation de l'AZGTI en mode Alt-Az avec un cable eqmod soit seulement possible? Quoi qu'il en soit il nécessaire pour que ça marche que l'Asiair soit conscient de piloter une monture Azimutale. Si tu n'as aucun réglage en ce sens, alors ça ne va pas. Je connecte ma monture avec le mode "EQmod mount" mais il doit y avoir autre mode pour l'azimutale. En tous cas n'hésites pas à poster des images de tes essais de map avec un bathinov aussi bien que des images des champs étoilés sur lequel le platesolve a échoué. On pourra vérifier si il y a un problème. Edit: voici un thread sur le sujet sur le site de ZWO: https://bbs.zwoastro.com/d/12294-az-gti-in-altaz-mode Malheureusement ça n'est pas très prometteur...

Hello @Mallozh Concernant l'Asiair, il faut bien comprendre que son utilisation avec une monture alt-az n'est pas son domaine de prédilection et qu'il n'a pas été conçu ni tester prioritairement pour ce mode. Je pense que tu te faciliteras beaucoup la vie si tu commences par utiliser ta monture en mode équatorial et tu trouveras plus d'aide pertinente si tu utilises ce mode (j'ai cette monture mais je l'utilise exclusivement en mode équatoriale) Cela étant dit je pense qu'il est quand même possible de l'utiliser en mode azimutale: comment connectes tu ta monture à l'Asiair? Il me semble qu'il existe un mode Alt-Az à sélectionner dans la liste déroulante. Concernant la map la première chose à faire à mon sens est de tester de jour sur une cible fixe (et lointaine) si tu peux atteindre la mise au point avec la caméra en place. C'est un prérequis indispensable avant d'utiliser ton matériel sur le ciel. Concernant le platesolve, le champ minimum pour que l'Asiair puisse résoudre une image est de 0,2°. Avec ton matériel il me semble que tu as un champ de 0,55° x 0,37°. Tu es donc au dessus du minimum requis et l'Asiair devrait être capable de réussir les platesolves. Les échecs sont sans doute liées à tes autres problèmes: il faut en effet que la mise au point soit bonne et que le tube ne pointe jamais trop loin de la zone visée. Nico

Hello Max, C'est un objet vraiement pas simple. Peux tu nous en dire plus sur le matériel employé?

Hello Fred, Il n'est pas nécessaire d'aligner les courbes. SPCC est la seule opération nécessaire pour calibrer les couleurs d'une image RGB et il ne faut plus ensuite effectuer d'opérations qui peuvent modifier cet équilibre. En temps normal il ne devrait pas être nécessaire d'utiliser SCNR par exemple. Le problème dans ton cas c'est que tu as peu d'image couleurs par rapport à la luminance et cela peut rendre la calibration plus aléatoire et, peut être, justifier d' intervenir ultérieurement (probablement après l'étirement) pour "corriger" les couleurs. Par rapport à ton Worflow, j'éviterais aussi de faire une correction du gradient sur les couches individuelles. Les outils de corrections du gradient sont bien plus efficace quand on les appliques directement sur l'image couleur. La constellation de Céphée fait partie de la couverture actuelle de la base MARS et donc tu peux utiliser le process MultiscaleGradientCorrection pour corriger les gradients de ton image. C'est sans doute l'outil à privilégier.

Hello @Hubus Pour une image broadband, le workflow habituelle est de calibrer les couleurs en phase linéaire avant l'étirement (c'est indispensable sur tu fais une calibration par photométrie). L'étirement, quel que soit l'outil utilisé (et si il est effectué en mode RGB sur les 3 canaux), ne doit pas modifier cette calibration. Je ne sais pas ce que tu reproches à l'histogramme que tu nous montres mais je n'y vois rien d'anormal: les pics des 3 courbes sont à peu près alignés et, comme sur cette image le fond de ciel à l'air prépondérant par rapport à la nébuleuse, cela signifie que le fond de ciel est neutre. D'une manière général je trouve qu'on ne peut pas trop se fier à l'histogramme d'une image pour juger si les couleurs sont correctes: si toute l'image est constituée d'une nébuleuse en émission, il est alors normale de voir des courbes très différentes entre les canaux. Bref, au moins dans une utilisation classique, GHS n'est pas en charge de l'équilibrage des couleurs.

Bonjour Cyril, Je la trouve très belle. Bravo.

Tes résultats ne m'étonnes pas du tout: ce dernier test tout comme les essais avec les différents algorithmes confirment que c'est bien un problème de rejet des pixels déviants lié à un changement de méridien. Une asymétrie se produit sur les étoiles brillantes lors de la bascule du télescope et, lors de l'empilement et en fonction du nombre d'images prises d'un coté et de l'autre du méridien certains pixels sont donc considérés comme déviants et sont alors rejetés. Les algorithmes de rejet ont tous des caractéristiques différentes (que je ne connais pas en détail) mais ils sont tous basés sur une approche statistique. Il est facile de rejeter sans conséquence des pixels déviants quand ils sont clairement identifiés et qu'ils ne représentent qu'une fraction de la pile mais, ici, c'est plus compliqué car les pixels considérés comme déviants représentent sans doute une part significative de la pile et qu'ils sont donc à la fois plus dur à identifier et que leurs rejet n'est pas sans conséquence (car ils restent alors moins de pixels à empiler). C'est cela qui provoque ces artefacts. J'ai quelques questions: Combien d'images as tu fait d'un coté et de l'autre du méridien dans ce cas particulier? Les images empilés que tu montres (partie 1 et partie2) sont elles alignées entre elles? Il me semble que non mais ça serait intéressant de voir ces mêmes images de cette étoile alignées pour bien constater l’asymétrie. En tous cas, je pense que la meilleure façon de corriger le problème reste de modifier les paramètres des algorithmes de rejet. En me basant sur tes tests j’essaierai avec l'algorithme Linear fit clipping et en augmentant le paramètre "Linéaire haut" Une autre idée serait d'essayer l’algorithme Median Sigma Clipping qui, plutôt que de rejeter les pixels déviants les remplace par la valeur moyenne de la pile. Je pense que ça devrait corriger ce genre d'artefacts mais je ne suis pas exactement sûr des conséquences que ça peut avoir par ailleurs... Pour simplifier et accélérer les tests une idée serait d'essayer de reproduire le problème avec un échantillon limité d'images, en conservant la proportion des images d'un coté et de l'autre du méridien. Nico

Pas d'inquiétude: la dominante rouge est normal. Pour pouvoir visualiser l'image correctement il faut délier les canaux Canaux liés: Canaux déliés: Le fait qu'il y ait un déséquilibre à ce stade est parfaitement normal. Il sera corrigé lors de la calibration des couleurs Perso je trouve tes images pas mal du tout. C'est plus au niveau de la calibration et du traitement qu'il faut que tu trouves les bonnes formules.

Le problème est que j'effectue toutes ces opérations dans Pix en général donc je ne sais pas exactement comment les mettres en pratique de la meilleur façon avec Siril. Pour le crop tu peux passer par la ligne de commande avec la commande crop. Par exemple Crop 314 123 2574 2821 les deux premiers chiffres sont les positions x et y du point de départ du crop et les 2 suivants la largeur et la hauteur du crop. De cette manière tu peux reproduire la commande facilement sur toutes les images. Une autre possibilité qui doit marcher aussi est de ne pas croper avant la composition RVB. Çà doit marcher aussi et il faudra juste cropper sur l'image couleur. C'est peut être plus simple finalement.

Je ne suis pas le mieux à même pour répondre à cette question car je n'ai jamais fait cette opération avec Siril mais juste avec Pixinsight. Mais je crois que la commande rgbcomp permet de composer la luminance avec l'image couleur avec la syntaxe suivante: rgbcomp -lum=luminance_image rgb_image

Formidable compte rendu. Merci: j'ai eu l'impression d'y être!

En effet, les images sont cette fois correctement identifiées mais il me semble que ton process n'est pas correct. La combinaison des images RVB doit se faire avec des images linéaires, c'est impératif (la calibration des couleurs par photométrie ou la déconvolution n'ont pas de sens sur des images déjà étirées. Avec ces 4 images voilà un workflow possible: 1) Alignement des images R,V et B sur la luminance 2) Crop des 4 images pour enlever les bandes noires (il y a un changement de cadrage significatif entre la luminances et les couches RVB) 3) Combinaison des images RVB pour créer l'image couleur A ce stade, avant même la calibration des couleurs ou toute autre forme de traitement on a une image couleur raisonnable: Il faut ensuite traiter cette image (Correction du gradient, calibration des couleurs, déconvolution,...) puis l'étirer et traiter et étirer la luminance en parallèle. La composition de la luminance avec la couleur se fait, enfin, avec ces 2 images non linéaires.

Il faut essayer en tous cas. Et sans même parler de savoir si ça résout bien ton problème d'artefacts, je serais curieux de savoir la différence de temps que ça engendre.

Je vois. Dans Pix l'algorithme était utilisé par défaut dès 15 images dans les versions précédentes. Au contraire, dans la version 1.9 cet algorithme n'est plus utilisé par défaut du fait du temps de calcul qu'il implique. En tous cas, à mon avis, ce n'est pas l’algorithme à conseiller pour les gros jeux de données (>100)

Où as tu vu ce conseil? Ça me semble étrange car GESD fonctionne parfaitement avec une vingtaine d'images par exemple.

Student (GESD) est surement l'algorithme le plus efficace mais c'est aussi le plus lourd. Du coup, je ne crois pas que la logique grand nombre d'images = student soit toujours valable. On peut considérer que la rejection est facilité avec un grand nombre d'image et il me semble qu'il faut donc alors mieux favoriser des algorithmes plus rapides.

Mon hypothèse c'est que tu as un défaut dans la psf de tes étoiles et que ce défaut est modifié lors du changement de méridien. Lors de l'empilement, l’algorithme de rejet va tenter de rejeter les pixels considérés comme déviant mais, en fonction notamment du nombre d'images prises d'un coté et de l'autre du méridien cela peut donne ce genre d'artefacts. Je te conseille d'essayer de changer l'algorithme de rejet (notamment GESD et Linear Fit Clipping) et de relancer un empilement voir si ça change le résultat. Le clamping est un paramètre d'alignement (accessible dans l'onglet alignement et nommé "interpolation contrainte" en français). C'est vrai que l'alignement est aussi une possibilité, il faudrait voir sur les images alignées si tu vois une trace de l'artefact en question.

Hello Sam, Pour les étoiles c'est clairement un problème de rejet: Quel algorithme de rejet utilises tu (et avec quels paramètres)? Combien d'images as tu empilé? As tu fais un changement de méridien durant les acquisitions?

J'ai utilisé Pix pour le traitement. Il n'y a rien de très particulier à faire pour composer une image rvb. Les images linéaires RVB doivent être composées directement en sortie d'empilement (outil composition RVB dans Siril ou ChannelCombination dans Pix). L'image composée avec un auto ajustement et les canaux déliés doit alors déjà afficher des couleurs raisonnables (une nébuleuse en émission doit être rouge, les galaxies doivent être plutôt blanches, les étoiles du jaune au bleu,...) Ça n'a pas l'air d'être le cas pour cette image. Du coup j'ai quand même un doute sur tes fichier. Pourrais tu les partager?

Bravo Romain, superbe image!