nico1038

Non, ça n'irait pas non plus: le boitier rouge possède uniquement un port ST4 (pour le guidage) qui ne permettrait pas à l'Asiair d'avoir un contrôle suffisant de la monture. Il est possible malgré tout d'utiliser un Asiair avec ces boitiers (et même avec le tien avec un seul moteur) mais on perd alors une bonne partie de l’intérêt de l'Asiair. Il n'y a plus de goto, plus d'astrométrie, une mise en station dégradée (il faudrait tourner le télescope à la main), pas de guidage (possible par contre éventuellement avec le boitier rouge). Bref, ça n'en vaut pas le coup selon moi car l'expérience de l'Asiair serait très largement dégradée.

Ok. Je crois malheureusement que tu ne pourras pas connecter ce boitier avec un Asiair: aucun port ne le permet. L'Asiair ne pourra donc pas contrôler ta monture. Ce qu'il te faudrait c'est un kit goto comme celui là: https://www.pierro-astro.com/materiel-astronomique/montures/accessoires-montures/kit-goto-pour-neq5-sky-watcher_detail?gQT=2

Bonjour Léa, S'agit-il de ce kit là: https://www.pierro-astro.com/materiel-astronomique/montures/accessoires-montures/motorisation-double-axe-avec-raquette-pour-eq5-neq5_detail ?

Perso je vois bien le graph 3D monter autour de 80% pendant utilisation de Starx ou Blurx. Est ce que par hasard tu n'aurais pas la possibilité de choisir directement "Cuda" à la place de "3D" ou de "Video Encode" ?

Oui, je n'utilise pas cette ligne. Je considère que ça n'est pas une façon correcte d'installer CUDA (parce que ça n'a en fait rien à voir avec Pix). Mais attention, enlever cette ligne ne va pas supprimer l'installation de CUDA et il risque donc en effet d'y avoir des problèmes de cohabitation. Bref si ça marche, il faut sans doute mieux ne toucher à rien! C'est juste que je pense qu'il faut y réfléchir à 2 fois avant d'utiliser cette méthode. C'est surement plus simple à première vue mais ça peut aussi se révéler problématique dans certains cas.

C'est pour ça que, perso, je n'aime pas trop l’installation de CUDA avec le repository RC-astro. Avec lui, CUDA est installé dans le répertoire Pixinsight ce qui n'est pas très propre et va empêcher CUDA de fonctionner pour d'autres applications. La manière traditionnelle d'installer CUDA est certes, un peu plus complexe, mais elle n'est à faire qu'une seule fois (il y a juste à remplacer le fichier tensorflow.dll lors d'une nouvelle installation de Pix).

Je parlais en fait des structures concentriques qui apparaissent sur ton image (et qu'on peut également distinguer dans la version de Julien). Elles sont dues au fait qu'après le retrait du gradient, l'histogramme de l'image est tellement resserré que les valeurs de pixels disponibles en 16 bits ne sont plus suffisantes pour représenter correctement l'image. C'est particulièrement visible sur la couche OIII ou le signal est le plus faible. Par exemple ici, après le retrait du gradient et des étoiles, l'ensemble des pixels de l'image sont codés sur moins de 50 valeurs discrètes! Ce n'est pas assez et ça explique la postérisation de l'image. La seule solution est d'enregistrer tes masters en 32 bits.

Hello @Tromat Merci pour cette comparaison très bien réalisée 👍

Il manque visiblement des messages dans la discussion pour pouvoir tout suivre mais en tous cas, si je me réfère à la dernière version des standarts FITs (pourtant antérieure à la conversation), cette façon de faire me semble incorrecte de la part d'astroart Le format fit requiert que les images 16 bits soient enregistrées avec des valeurs signées. Or comme les caméras écrivent des valeurs non signées, il existe une procédure clairement définie pour régler cette situation. Il y a même un exemple concret dans le pdf définissant le standard:

C'est plutôt le contraire: le seul rotateur pouvant fonctionner avec l'Asiair est bien le CAA mais ce dernier est en revanche compatible ascom et peut donc être utilisé sans problème à travers d'autres logiciels.

Hello Régis, D'après les standards du format FITS (https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf), je ne comprend pas vraiment l'usage de Bzero = 0 et surtout je ne vois pas pourquoi cette valeur serait différente pour des bias par rapport aux autres types de fichiers? Pourrais tu partager un de ces bias?

Merci. 80x180s pour chaque panneaux avec l'objectif ouvert à f/3.5

Hello @cezanne Les reflets circulaires sont dus au fait que tes images sont en 16 bits. Cela diminue clairement les possibiltés de traitement sur ce genre d'images. Ca vaut le coup de refaire ton prétraitement. Nico

Bonjour à tous, J'ai retraité récemment une mosaïque de la région du Cygne que j'avais shooté en 2023. Grace à certains des nouveaux outils de Pixinsight, le traitement a été largement facilité et je me suis dit que je pouvais faire un post sur la façon dont j'avais procédé histoire de partager les techniques. J'évoquerais ici uniquement la réalisation de la mosaïque elle même, jusqu'à la jointure finale. Et je ne parlerais pas du traitement qui vient après. En gros, la mosaïque repose sur 3 étapes: la préparation des panneaux (notamment la correction de leurs gradients) l'alignement des panneaux sur la géométrie finale grâce à MosaicbyCoordinates La jointure des panneaux grâce au Script PhotometricMosaic. A noter que ce dernier script n'est pas un script de base de Pixinsight. Il faut ajouter un "repository" pour pouvoir en bénéficier (https://www.astroprocessing.com/repository.html) Présentation des images: Il y a 4 panneaux de la région du Cygne shooté avec ma caméra ASI2600MC, un objectif Tamron de 85mm et un filtre duo-band (Ha-OIII) Antlia APL-T. Les panneaux ont été prétraités avec du drizzle x2. Voici ce que donne les 4 panneaux brutes en sorties de prétraitement: Préparation des Panneaux Correction des étoiles Malheureusement, à l'époque de l'acquisition, j'avais encore des problème de réglage de backfocus et de rigidité du montage entre la caméra et l'objectif. Du coup, les étoiles dans les coins des panneaux sont très mauvaises: C'est un problème pour les mosaïques car cela va provoquer des artefacts au niveaux des jointures et il faut donc essayer de corriger ça. La première chose que j'ai fait est de séparer les canaux (avec le process ChannelExtraction) puis de les réaligner (avec le process StarAlignment) en prenant le canal vert comme référence et en activant la prise en compte de la distorsion et enfin de recombiner les canaux (avec le process ChannelCombination). Cette opération permet de limiter les décalages chromatiques (visibles notamment dans le coin en haut à gauche) de l'image d'origine. Et puis application de Blurx en mode "correct only": Le résultat n'est pas parfait et ça ne remplace pas une acquisition plus soignée mais on évite ainsi un certain nombre de problèmes au moment de la jointure des panneaux. Après avoir réalisé ces opérations il est bien de refaire une résolution astrométrique des panneaux pour avoir la solution la meilleure possible pour les étapes d'après. Correction des gradients L'étape suivante est la correction du gradient. Avec les outils de retrait traditionnels (comme DynamicBackgroundExtraction), j'avais toujours des problèmes pour les mosaïques. Même si le gradient était visuellement parfaitement corrigé sur les panneaux individuels, le retrait était fait de telle manière que les panneaux n'était plus vraiment "compatibles" entre eux et cela donnait alors des transitions visibles au final. Grace au nouvel outil de correction du gradient de Pix: MultiscaleGradientCorrection (MGC) qui se base sur l'approche décrite ici (https://pixinsight.com/tutorials/multiscale-gradient-correction/ ) on a un outil qui permet un retrait objectif des gradients et donc des panneaux qui se joignent parfaitement après le retrait. Par contre, comme il s'agit d'une image narrowband, il faut faire un peu attention pour utiliser MGC correctement. Le préalable est d'utiliser l'outil SPFC qui va permettre de calibrer les flux de l'image avec les réglages correspondant au filtre utilisé (ici le Antlia-ALP-T): Une fois ce préalable fait on peut alors appliquer MGC avec les réglages suivants: Après avoir réalisé ces opérations sur les 4 panneaux, on a désormais le résultat suivant: Resample Afin de limiter les temps de calculs des opérations suivante et pour avoir une géométrie finale de taille raisonnable j'ai choisit de resampler les panneaux individuels à 75% en utilisant le Process Resample de Pix. Avec des images sous-échantilloné comme celles-ci, il faut faire attention à l'algorithme utilisé car ils vont avoir un impact important sur l'aspect final des étoiles et il peuvent provoquer des artefacts sur ces dernières. Ici j'ai choisi l'algorithme "Bicubic-Spline" avec une réglage de "Clamping Threshold" à 0,1. A noter que le resample va supprimer la solution astrométrique des images et qu'il faut donc la recalculer avec ImageSolver pour chaque panneaux. Alignement des Panneaux L'alignement des panneaux sur la géométrie de la mosaïque est réalisé avec le script MosaicbyCoordinates. En lui passant en entrée les 4 panneaux, celui ci va déterminer automatiquement les caractéristiques de la géométrie finale et va aligner les 4 panneaux sur celle-ci. Comme avec le resample, il faut faire attention à l'algorithme d'interpolation utilisé. Voici un exemple de la différence entre l'algorithme Bicubic Spline et les réglages par défaut de MosaicbyCoordinates Une fois le script terminé, on obtient les 4 images suivantes: Jointure des Panneaux Il reste alors à joindre les panneaux avec le script PhotometricMosaic. Je ne suis pas sûr que ce soit absolument nécessaire mais l'auteur du script PhotometricMosaic recommande de supprimer quelques pixels en bordure des images avant de les joindre. Il propose un script dédié à ça: TrimMosaicTile (qui vient dans le même repository que PhotometricMosaic). J'ai donc enlevé 5 pixels de chaque coté des 4 panneaux. Le script PhotometricMosaic lui même est assez complexe ( il est par contre très bien documenté) mais Il est à mon sens largement préférable au vieux script natif de Pix: GradientMerge mosaic. Le principe est qu'il utilise la photométrie des étoiles pour mettre les panneaux à l'échelle et pour gérer les zones de transition. Cela donne en général d’excellents résultats. Son seul point faible est qu'il ne peut joindre des panneaux que 2 à 2. Il faut donc procéder par étapes et cela peut devenir laborieux quand on a beaucoup de panneaux dans sa mosaïque... Ici, grâce aux traitements préalables des panneaux, j'ai utilisé tous les réglages par défaut du script, excepté le mode de combinaison réglé sur "Blend" et le réglage "Outlier" réglé sur 10: Ensuite j'ai donc procédé par étape en joignant les 2 panneaux de gauche puis les deux panneau de droite et enfin en joignant les 2 résultats précédant: Il reste alors à croper l'image et à la résoudre astronomiquement une dernière fois. Le travail spécifique de la mosaïque est alors terminé et il ne reste plus qu'à traiter l'image normalement. Je vous met le résultat final de mon traitement. Après les étapes décrites au dessus je n'ai fait aucune opération particulière de traitement des gradients ce qui prouve à mon sens l'efficacité de ce workflow et en particulier la fiabilité des résultats de MGC sur les panneaux individuels. N’hésitez pas si vous avez des questions ou des remarques. Nico

Hello @lefredo Je ne suis pas vraiment d’accord avec la doc de Siril concernant l'algorithme GESD. Déjà je ne sais pas d’où vient cette valeur de 50 pour le nombre d'images (le papier original de Rosner précise qu'on obtient déjà des résultats avec un échantillon de seulement 25 et la doc de Pixinsight donne, elle, un chiffre minimum de 15) mais surtout il y a un paradoxe avec cet algorithme: Tout le monde semble d'accord qu'en terme de qualité pure l'algorithme GESD est le meilleur mais c'est aussi le plus lourd en terme de calcul. Or tous ces algorithmes statistiques fonctionnent d'autant mieux que l'échantillon est grand. Par conséquent plus le nombre d'images sera important plus la lourdeur de l'algorithme GESD va se faire sentir mais aussi plus la différence de résultat avec les autres algo plus "simples" va se réduire. Contrairement à ce que laisse entendre la doc de Siril, ce n'est donc pas à mon avis un algorithme à privilégier quand le nombre d'images est important mais plutôt un algo à tester quand les autres ont échoué à rejeter correctement les pixels déviants (et cela quel que soit le nombre d'images). Nico

Superbe!

Si, absolument. Pour le script: pourquoi pas mais je me demande si ce genre de script intermédiaire ne complique pas la compréhension des outils?

Très belle image: le traitement est parfait.

Le requin est bien dans la base MARS. Je pense que ça vaudrait le coup d'essayer MGC. A mon sens, avec un champ aussi riche où les nébulosités sont partout, un outil de soustraction du gradient basé sur des points sensés représenter le fond de ciel risque de donner des résultats aléatoires (et subjectifs). Il faut mieux utiliser dans ces cas là des outils comme GradientCorrection ou MultiscaleGradientCorrection.

Bravo Serge, elle est superbe.

Une possibilité est qu'avec le temps la pastille de dessicant n'est plus aussi efficace et qu'il reste des traces d'humidité dans la chambre du capteur. Et dans certaines conditions de température et de refroidissement (et peut être aussi la présence ou non du désembuage) cela provoque ce phénomène. Voici un autre sujet ou un cas un peu similaire est évoqué: https://stargazerslounge.com/topic/405799-zwo-asi6200-strange-problem/ La répartition des artefacts sur ton image ressemble t'elle à celle visible sur le flat du 1er message?

Hello @chinois02 Aucun doute que ce sont bien les IFN. En poussant encore un peu plus le contraste et en comparant avec une de mes images (ou j'avais posé beaucoup plus) on retrouve exactement les mêmes structures: (par contre ton image est inversée )

Pour la couleur je crois qu'il faut différencier les IFN (Integrated Flux Nebulae) qui sont des nuages extra galatiques des nébuleuses par réflexions "locales" situées au coeur de la galaxie. Les nébuleuses par réflexion ont différentes couleurs en fonction de ce qui les illumine mais souvent une couleur brune assez marqué comme par exemple les nuages dans Céphée, dans le Taureau ou dans Orion. Cette couleur est due à leurs composés carbonés qui absorbe la lumière et la fait tendre vers le rouge. On peut noter la situation locale de ces nébuleuses au fait qu'elles cachent certaines étoiles et qu'elles sont donc situées au premier plan. Les IFN sont bien plus lointaines et elles reflètent la lumière de l'ensemble des étoiles de notre galaxie (d'où le terme Integrated Flux). C'est pour ça je crois qu'elles sont plus plus uniforme avec une couleur plus "froide". La région la plus connue pour ces nébuleuses est la région du Pôle nord céleste avec des nuages qui s'étendent entre autre jusqu'au couple M81/M82. D'après cette article https://cosgrovescosmos.com/projects/sh2-73 , SH2-73 est bien une IFN et donc ont peut s'attendre en effet a couleur légèrement plus bleu/grise. Cela dit les nuages complétement désaturés me semble aussi un peu discutable. Je pense que pour certaines images le LRGB peut expliquer ces couleurs dans une certaine mesure: avec une luminance qui représente parfois une part très importante des acquisitions il est difficile de faire ressortir l'information sur la couleur des objets les plus diffus.

Le truc c'est que je ne suis pas sûr que le désembuage ait un impact direct sur ce problème de givre: il a pour but d'éviter la buée sur la vitre de protection de la caméra or là on parle bien de cristaux de glace directement sur le capteur lui même. La caméra est elle neuve?

Hello Guillaume, Ce genre de problème concentré au centre de l'image et qui provoque des artefacts à l'échelle des pixels me fait penser à de la formation de glace sur le capteur. Cependant ce qui ne colle pas complétement avec cette théorie c'est l'aspect directionnel des trainées et le fait que cela ne se produit pas avec les drivers Ascom. Quand tu as fait le test avec Ascom, était ce immédiatement après avoir testé avec les drivers natifs? Avais tu activé la résistance chauffante de la caméra avec le driver Ascom? Si j'étais toi j’essaierai de faire des images sans refroidissement pour voir si le phénomène se reproduit. Voir par exemple ici une discussion ou on parle du phénomène: https://www.cloudynights.com/topic/684150-zwo-asi-6200-mm-pro-initial-impressions/page-68 En tous cas, si c'est ça le problème il y a éventuellement 2 choses à faire: Changer la pastille de désicant Refroidir la caméra plus lentement (par pallier) ou se contenter d'une température moins froide Nico