nico1038

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

Hello @Glloq Comme l'on bien expliqué @lionthom et @Wan186 dans les messages précédent il est tout à fait possible d’enregistrer une image en tif avec Siril. Mais pour quelles raisons exactement veux tu faire ça? Le format fit est un format conçu pour les images astronomiques et tu vas perdre plein d'informations utiles en convertissant tes fichiers en tif. Il est possible d'associer Siril à n'importe quel type de fichier. Dans Windows 11, clic droit sur le fichier > Propriétés > S'ouvre avec > Choisir Siril (éventuellement aller chercher l’exécutable Siril.exe si le programme n'est pas proposé dans la liste)

Juste pour te monter la différence, voila ton image sur laquelle j'ai juste fait les opérations suivantes: 1) correction du gradient avec GradientCorrection 2) Calibration des couleurs avec SPCC 3) Blurx 4)Saturation (normalement je ne fais pas la saturation en phase linéaire mais c'est juste pour la démonstration) Voila le résultat de cette image avec un autostrech avec les chaines liées: et la même image image mais avec un autostretch avec les chaines déliées:

En parlant de M63: vous avez remarqué cette galaxie longiligne située juste à sa périphérie? Sa forme est très singulière je trouve. J'aimerai bien voir une image haute résolution de cette région mais je n'ai rien trouvé pour l'instant. Hubble a bien fait des photos de M63 mais a priori juste le coeur de la galaxie.

Je compte bien poursuivre les test mais ça serait top d'avoir d'autres images. Comme le montre ton test, le panel est encore un peu trop petit pour vraiment tester les différentes combinaisons. Je vais ajouter [M63] dans le titre du sujet, peut être que ça attirera l'attention.

Non ce n'est pas seulement marketing: une appli sur un smartphone serait capable éventuellement de piloter une monture wifi (c'est d'ailleurs le cas avec l'appli synscan je crois pour les montures skywatcher) mais c'est loin d'être suffisant. Elle n'a en revanche aucun moyen de se connecter à la caméra et est donc incapable de la piloter ou de récupérer les images ce qui est quand même le but d'une session d'astrophotographie! Et je ne te parle même pas de la problématique du stockage et de la fiabilité de la connexion si tout le pilotage est dans un smartphone relié en wifi au matériel. A mon sens une appli smartphone ne peut être qu'une télécommande liée à un appareil qui est le vrai cerveau de la session et qui est lui lié en filaire avec le matériel (notamment la caméra). Il est essentiel qu'une coupure dans la transmission n’arrêtes pas le déroulement de la session.

Bravo Florian, elle est superbe.

Hello @muhe-ca Pas directement: pour ça il te faut un appareil supplémentaire (type Asiair), branché en direct sur la caméra et et sur la monture et qui gérera l'acquisition, le stockage et la plannification de la session.

Hello @tranquiliste Appliquer directement le STF à HistogramTransformation est une bonne méthode de stretching (même si le résultat d'un Autostrectch ne sera pas toujours idéal) mais en revanche il est important d'avoir lié les chaines (c'est à dire l’icône de la chaine soit activée) avant de le faire. En effet, c'est la calibration des couleurs (qui a lieu en phase linéaire, avant l'étirement) qui va déterminer la proportion entre les 3 chaines. Une fois la calibration effectuée, il faut donc lier les chaines pour visualiser correctement son résultat. Et c'est ce STF (avec les chaines liées) qu'on veut alors éventuellement reproduire pour étirer l'image. Si tu ne lies pas les chaines avant de transférer le STF a l'outil HistogramTransformation tu compromets le résultat de la calibration effectuée précédemment.