nico1038

Le platesolving de l'Asiair n'est pas un blindsolver, il lui faut les paramètres correctes. Or la focale de ton setup est bien de 120mm, c'est confirmé par l’échantillonnage de 4.97 arcsec/pixels trouvé par astrometry.net Cette différence avec la focale "normale" de l'objectif suggére que ta caméra n'est pas située à la bonne distance l'objectif. Avec le champ réduit de la 662MC ce n'est pas forcément un problème mais cela peut expliquer des déformations des étoiles dans les coins.

Hello @yannusbonus Elle a beaucoup de potentiel à mon avis (beaucoup plus que ton image précédente d'Andromède) mais tu as un problème de prétraitement et il est dommage d'essayer de traiter cette image sans corriger d'abord ses défauts. 1) Problème de cadrage. C'est sans doute un cadrage différent entre les 2 sessions (et là il n'y a rien à faire mais heureusement sur cette cible ça n'est pas trop grave car il y a de la marge pour recadrer) mais j'avoue que je comprend mal ce résultat avec ces bandes noirs en biais? 2) Problème de calibration avec des pixels chauds non corrigés qui laisse des traces sur l'image finale 3) Problème de rejet avec des satellites et des avions non rejetés. A minimum, les points 2 et 3 doivent pouvoir être corrigés facilement. Pourrais tu expliquer en détail comment tu procèdes pour le prétraitement? Tu utilises Siril je crois,as tu utilisé un script? Fais tu des DOF? Comment as tu fais pour intégrer les 2 sessions ensemble? Combien d'images as tu empilé en tout? Sais tu pourquoi le rejet des pixels déviants n'a pas fonctionné? Nico

Hello @tranquiliste La bande sombre au milieu n'est pas du au flat à mon avis. Je soupçonne plutôt le script CanonBandingReduction qui peut provoquer ce genre d'artefacts. Sinon le gros problème est en effet la couleur. Ton image en est quasiment dépourvu. Nico

Très sympa. Et n'oublions pas M105 (la galaxie la plus brillante du groupe de 3 en haut à gauche)

Hello Max, C'est facile à vérifier: résout astronomiquement (avec ImageSolver) une image individuelle de chacune des deux sessions et compare l'angle de rotation des 2 images. Normalement, si tu n'as touché à rien, ça ne devrait pas se produire. Il y a donc sans doute quelque chose qui a bougé/glissé entre les 2 nuits.

Peux tu faire la manip suivante: 1) Ouvre Siril 2) Définis le dossier de travail 3) Lance le script OSC_Preprocessing 4) Quand ça plante montre nous la sortie complète de la console depuis l'ouverture de Siril. PS: Arrêtons de conseiller de réinstaller les logiciels à tour de bras: même si il peut arriver (rarement) que ça corrige un problème en réinitialisant des paramètres, ça ne permet pas de comprendre ce qui s'est passé.

Hello @pyrou61 Effectivement il y a quelque chose d'étrange et je pense qu'il s'agit plutôt d'problème de prétraitement. Les images de la 294 sont délicates à calibrer. Peux tu nous dire comment tu as procéder pour le prétraitement dans Siril et dans Pix? Quelle est la durée de tes flats? Avec cette caméra il est souvent recommandé d'avoir des flats supérieurs à la seconde si possible et de les calibrer avec des darks plutôt qu'avec des bias.

Il semble que tu ais de vieux scripts. Comme on peut le voir sur la copie d'écran de @lepac les dossiers doivent être nommés biases, flats, darks et lights (en minuscule)

Salut, Le problème des lentilles gravitationnelles c'est qu'elles sont plutôt dues à la masse globale de la galaxie (voir d'un amas de galaxie) il me semble. Comme manifestation directe d'un trou noir, je verrais plutôt le jet de M87 Cela dit ça me parait presque impossible avec ton matériel pour une question d’échantillonnage. Voir par exemple cette superbe image d' @encelade18 Nico

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!