nico1038

A mon avis la première chose à tenter est d'utiliser directement HistogramTransformation. 1) Commence par désactiver le STF sur ton image 2) Active la real-time preview Les 3 points suivants peuvent alors être répétés plusieurs fois jusqu'à obtenir un résultat satisfaisant 3) Modifie les curseurs midtones et shadows 4) applique le résultat sur l'image 5) Reset les paramètres de HT En procédant de la sorte, par étapes, et grâce à la visualisation en temps réel, tu dois pouvoir obtenir un très bon résultat.

Hello @Aïki Le Autostretch de l'outil STF de pixinsight permet d'obtenir une vison raisonnable d'une image dans sa phase linéaire. Il donne parfois un résultat satisfaisant qui peut être utilisé pour étirer l'image "pour de vrai" (en copiant les parametres de STF vers HistogramTransformation) mais il ne doit pas être considéré comme un moyen systématique de réaliser cette opération. Avec M27 (un objet souvent petit dans l'image et très brillant) tu as typiquement le cas d'une image qui ne va pas donner un résultat très satisfaisant avec un Autostretch. Il est possible de modifier les curseurs de l'outil STF pour obtenir un résultat conforme à ce que tu souhaites mais la bonne réponse est, je crois, de complétement oublier STF pour réaliser l'étirement de ton image. Pourquoi dis tu que HistogramTransformation reprends les paramètres de STF? Ça n'est pas du tout le cas et tu peux utiliser HistogramTransformation de manière complétement indépendante de STF. Il existe aussi d'autre outils pour étirer une image. Personnellement j'utilise presque exclusivement GHE (GeneralyzedHyperbolicStretch) et ça fait bien longtemps que je n'ai pas recopié les paramètres de STF pour étirer une image. Nico

Ma remarque précédente sur l'utilisation du format fit est surtout valable pour les premiers phases du traitement quand l'image est toujours linéaire. A ce moment là les données associées au format fit sont importantes pour le traitement et si tu veux partager ces images. Une fois que l'image est étirée c'est beaucoup moins vrai (même si les avoir les infos est toujours intéressants) et tu peux alors convertir l'image au format tiff par exemple qui sera plus facilement lisible par des logiciels qui ne sont pas forcément dédiés à l'astro. Cela étant dit, c'est quand même curieux car Gimp est normalement capable de lire les fichiers fits. Si l'image est en noir est blanc cela suggère que ce n'est pas une image RGB mais une image monochrome CFA ce qui ne devrait pas être le cas pour une image empilée et déja traitée. Tu peux partager l'image en question ? (tu peux utiliser un service de partage comme wetransfer ou autre en attendant que le partage d'image soit a nouveau possible sur le forum)

Comme on peut pas poster d'image directement, voici un lien vers ma version: https://kdrive.infomaniak.com/app/share/1883582/cee165f2-d732-414f-967d-dc2c48918559

Je pense qu'il s'agit d'un bug. Il a été signalé ici: https://www.webastro.net/forums/topic/12124-reports-de-bugs/page/96/#findComment-3248520

Je ne suis pas convaincu que le driver soit le même, la valeur du mot clé INSTRUME est différent ce qui me semble étrange si le driver utilisé était bien le même. De toute façon, à moins de ne pas avoir le choix et de savoir exactement ce que l'on fait il faut mieux éviter de calibrer des images avec des fichiers qui ne sont pas pris avec le même logiciel d'acquisition (et les mêmes réglages) que pour les lights. C'est une source constante de problèmes et de résultats douteux.

L'implémentation de Nina est la plus correcte à mon avis: Les dimensions de l'images sont cohérentes avec les mots clés suivants: BAYERPAT = "RGGB" XBAYROFF = 0 YBAYROFF = 1 ROWORDER = 'TOP-DOWN' Cela se traduit par un motif de dématriciage GBRG En revanche PRISM n'indique aucun de ces mots clés dans l'entête de ses fichiers. Pour un dématriciage correcte (avec une lecture en TOP-DOWN) il faut utiliser le motif "BGGR" Il n'y a pas vraiment d'erreur selon moi, il n'est pas inhabituel d'avoir des tailles d'images différentes en fonction des drivers et de leurs paramétrages mais disons que PRISM et ARTEMIS me semble très light sur les métadonnées.

Pourrais tu partager un exemple de fit pris avec chaque logiciel?

C'est probablement une question de drivers. Est ce que tu n'utiliserais pas le driver Ascom dans un cas et un driver natif dans l'autre? Cette différence n'est pas forcément un problème, il faut juste veiller à bien prendre l'ensemble des fichiers (y compris les fichiers de calibration) avec la même configuration. Avec une caméra couleur il faut également veiller à ce que le motif de bayer enregistré dans les images soit bien adapté aux dimensions (suivant la position de la colonne en moins, cela peut en effet modifier le motif de dématriciage)

En effet, ça semble être le cas partout sur le forum. Il y avait avant je crois un bouton joindre quand on rédigeait un message et ce dernier a disparu.

L'image traitée sera très similaire à la précédente mais sans les trainées de satellites. C'est là tout l’intérêt de la réjection. Tu as bien fait à mon avis de creuser les choses dans DSS. Même si tu bascules sur Siril par la suite, cela permet de mieux comprendre ce qui est fait et de comparer les logiciels de façon plus objective.

Ce conseil était surtout valable pour tes prochains traitements. Le format tiff n'est pas mauvais en soi pour des images empilées (quand il est au format 32 bits) mais il est moins adapté que le format fit qui contient un ensemble de metadonné astronomiques très utiles. Il ne faut pas supprimer les images mais activer le rejet des pixels déviants lors de l'empilement. Cela a pour effet d'éliminer les pixels aberrants de façon statistiques (par rapport aux autres pixels de la pile) et va notamment supprimer ces traces de satellites. Je ne suis pas un utilisateur habituel de DSS mais je crois qu'il faut choisir le mode d'empilement Kappa-Sigma-Clipping dans les paramètres d'empilement.

Hello @toumreg83 et bravo pour ces images. Voici M16, traité avec Pix: Tu as un problème de réjection: il n'est pas normal d'avoir des traces de satellites quand on empile presque 100 images. Tu devrais aussi privilégier le format fit qui est bien plus adapté pour l'échange d'images astronomiques.

En Eqmod, l'Asiair est vraiment le seul maitre à bord. Il communique ses instructions directement aux moteurs de la monture et ne communique pas du tout avec le processeur de cette dernière. Il doit donc possible (et même recommandable) de se passer complétement de Synscan. Encore une fois: je pense que tu n'utilises pas le bon terme. On ne peut pas se passer de mise en station. C'est de l'alignement synscan dont tu parles.

La question importante c'est de savoir si vous êtes connectés en eqmod ou autrement sur cette monture. Cela conditionne pas mal de chose.

Le platesolve se fait avec la caméra de prise de vue, c'est normal. Si le platesolve fonctionne il n'y a donc pas de problème de champ et la combinaison de ta caméra et de ton instrument convient (le champ minimum pour que l'Asiair puisse faire un platesolve est de 0,2°). Pour pouvoir utiliser correctement l'Asiair il faut que tu oublies complétement Synscan si c'est possible. C'est la combinaison des deux applis qui risque de poser problème. L'asiair est-il connecté a ta monture par un cable eqmod? Et pourquoi zapper la mise en station? Comme je l'explique au dessus c'est indispensable et ça n'a rien à voir avec le goto. La procédure correcte devrait être la suivante: 1) Faire un goto Home avec l'Asiair 2) Repositionner la monture à la main (en desserrant les freins) si elle n'est pas dans la bonne position 3) Faire la mise en station avec l'Asiair 4) refaire un goto Home (celle étape là est probablement facultative) depuis l'Asiair 5) Viser une cible avec l'Asiair Est ce quelque chose t’empêche de faire cette procédure?

Le platesolving remplace le besoin de calibration. Même si l'objet visé n'est pas dans le champ lors du premier déplacement, l'Asiair platesolve la zone, trouve où pointe le telescope et ajuste en conséquence. C'est extrêmement efficace et il est difficile de faire machine arrière quand on a utilisé ce genre de système basé sur l'astrométrie. Je te déconseille de passer par Synscan, ça ne devrait pas être nécessaire. Peux tu décrire le modèle de ta monture et la façon dont tu connectes l'Asiair à celle-ci?

Hello @JM24 Il me semble que tu confonds 2 choses: la mise en station qui a pour but de placer la monture équatoriale dans l'axe de rotation de la terre. C'est quelque chose qui doit être fait avec toutes les montures équatoriales sans exception et qui doit toujours être le plus précis possible. Il y a plusieurs techniques pour le faire, notamment à l'aide d'un viseur polaire ou grâce à des méthodes qui s'appuie sur le platesolving. Avec l'Asiair il y a 2 méthodes pour faire cette mise en station. La méthode classique quand on a accès à la région du pole nord céleste, la monture prend une première image en position home (tube vers le nord, contrepoids vers le bas) puis se décale de 60° vers l'ouest (en ascension droite), reprend une image puis nous indique les corrections à apporter en azimute et en altitude. Il y a également la possibilité de faire une mise en station quand on a pas accès au nord (je ne connais pas exactement la procédure dans ce cas là). Ensuite il y a le calibrage du goto. C'est quelque chose de complétement indépendant de la mise en station. Cela consiste juste à ce que la monture sache où elle vise dans le ciel. C'est ce dont tu parles avec la calibration sur 1,2 ou 3 étoiles avec Synscan. Avec l'Asiair pas besoin de faire ce genre de chose, l'Asiair va viser approximativement la zone souhaitée puis va corriger lui même sa position grâce au platesolving (en général une correction suffit). Normalement c'est extrêmement efficace et beaucoup plus facile car, en pratique, il n'y a rien à faire et la précision est totale. Une erreur courant rencontrée avec l'Asiair et qui pourrait expliquer tes problèmes est que la position "Home" de la monture est mal estimée par l'Asiair. Par conséquent, quand l'Asiair vise pour la première fois la cible qu'on lui donne il est complétement dans les choux (car il ne part pas de la bonne position). C'est pour cela qu'il est essentiel de faire un goto Home en début de session. Et si l'instrument ne se place pas dans la position souhaitée, alors on dessert les freins et on le replace dans la bonne position. De cette façon la position Home de l'Asiair correspond bien à la réalité et le premier déplacement sera correct.

Hello Bruno, Tu as bien fait de la poster. On sent que l'image a beaucoup de potentiel. Si j'étais toi je commencerai par faire un traitement des images du filtre L-Pro uniquement et de la poster ici. Normalement tu devrais pouvoir calibrer dans Siril les couleurs de cette image de façon "objective" grâce à la spectrophotométrie. Ajouter la couche H-alpha est une opération plus délicate, avec plusieurs façon de faire et ça peut être délicat de conserver des couleurs naturelles aprés cette opération. Procéder en 2 temps est une bonne idée à mon avis.

Ok: si tu ouvres une image fit issue de l'Asiair dans Siril, tu verras qu'elle est inversée. Siril ne gère pas le sens d’écriture top-down pour l'affichage des images (il le gère cependant pour le dématriciage ce que j'ai toujours trouvé un peu paradoxal). Lorsque tu passes par un fichier tiff ( tu devrais éviter d'ailleurs, DSS peut tout à fait sortir un fichier fit) puis que tu le sauvegardes en tiff dans Siril il est alors écrit en bottom-up. Il faut donc régler Pix pour lire les fit dans ce sens. Le problème du format fit, malgré toute ses qualités c'est qu'il est permissif sur le sens d'écriture et qu'il faut veiller à bien configurer les logiciels pour qu'ils soient opérationnels entre eux. Dans ton cas c'est d'autant plus complexe car tu passes par 3 logiciels différents!

Superbe image de cet objet rarement imagé. Bravo Siril, considère que le sens de lecture (et d'écriture) par défaut des fichiers fit est le bottom-up (ce qui n'est pas le cas de la majorité des logiciels d'acquisition). Si ton image est dans le bon sens dans Siril cela signifie sans doute qu'elle est "bottom-up". Quel est ton logiciel d'acquisition et est ce qu'il inscrit le mot clé ROWORDER dans tes fichiers fit? Dans Pix tu peux régler le sens de lecture des fichiers fit dans les préférences du format fit.

Hello @Starlex, Il est important de réussir à configurer les bases de données Gaia dans Pix. C'est un aspect important du logiciel. Tu as donc 2 bases de données que tu peux télécharger dans la partie Software distribution du site de Pixinsight: 1) La base gdr3 qui est utilisé pour l'astrométrie (ImageSolver) et qui est constituée de 16 fichiers classés par magnitude. Tu peux en télécharger autant que nécessaire pour ta configuration. Dans la plupart des cas, les 4 premiers fichiers sont largement suffisants. 2) La base gdr3/sp qui contient moins d'étoiles mais avec en supplément les informations spectrophotométriques utilisées par des process comme SPCC et SPFC. Pour cette base tu as le choix entre le "small set" de 4 fichiers ou le "complete set" de 20 fichiers mais il faut télécharger l'ensemble des fichiers d'un set donné. Tous ces fichiers gdr3 et gdr3sp doivent alors être configurés dans Pix via les préférences du process Gaia en veillant bien à choisir le bon Data release pour chacune des bases. Une fois que c'est bien configuré tu pourras alors utiliser ImageSolver ainsi que SPCC notamment. Je n'ai pas bien compris ce qu'était l'image "photo.fit" que tu joignais à ton message? Il s'agit d'une image linéaire mais qui semble avoir déjà été traité dans une certaine mesure ce qui complique largement son traitement. Il faudrait également connaitre les circonstances d'acquisitions de cette image (notamment les filtres utilisés) pour pouvoir appliquer MGCC et SPCC correctement. Quoi qu'il en soit, voici ma version: Nico

Comme tu peux le voir le champ couvert par l'image de chatgpt est bien plus grand que celui de l'image d'origine (et, par ailleurs, il y a des aigrettes sur les étoiles...). Il ne s'agit en aucun cas d'un traitement de l'image d'origine mais, comme le dit @Le jupitérien, l'IA a reconnu la nébuleuse d'Orion et a recréé celle ci à partir de données qui ne sont pas les tiennes. Je ne sais pas si ta question est sérieuse mais il y a donc autant d’intérêt à faire cela qu'à taper directement "nébuleuse d'Orion" dans google image.

Les cartes de rejections sont curieuses mais on ne peut à mon avis en tirer aucune conclusions pour le moment car le prétraitement n'est (sans doute) pas correct en l'état. Il faudrait vraiment relancer un run avec uniquement les lights, le masterdark et le masterflat et en ajoutant master dans le nom de ces 2 derniers. Et avant de lancer WBPP, vérifie bien que les 2 masters sont identifiés comme des masters avec une étoile près de leurs noms. Je te conseille aussi de faire un reset de WBPP avant de relancer le run, il me semble que tu as changé pas mal des réglages par défaut.

Oui le log est très curieux: Si je comprend bien, les fichiers 1-offset_-10d_G100_Novembre_2024.fit 1-flat_OIII_G100_Decembre_2024.fit 1-dark_300s_-10d_G100_Novembre_2024.fit sont des masters, c'est bien ça? Si c'est le cas, WBPP ne les reconnaît pas comme tels et il essai par exemple de calibrer le fichier 1-flat_OIII_G100_Decembre_2024.fit, ce qui est sans doute une erreur (car l'offset a probablement déjà été retiré de ce fichier). Il faudrait ajouter "master" dans le nom de ces fichiers pour éviter ce genre de chose. Par ailleurs tu n'utilises pas la dernière version de Pix qui est la 1.9.3. Je te conseille de mettre à jour, cela te permettra aussi d'avoir WBPP v2.8.9. Par contre, il faut savoir qu'avec les dernières versions, les masters utilisés dans WBPP doivent être au format xisf. En plus d'ajouter "master", il faudra donc aussi convertir les fit en xisf.