nico1038

Vois tu ou ne vois tu pas une structure dans tes masterbias? Personnellement je n'ai encore pas vu de caméras avec un masterbias (constitué d'un nombre suffisant d'images) parfaitement uniforme. Et c'est bien ça mon argument: si une structure (en général des bandes verticales) est visible alors le signal qui la constitue est supérieur à celui du bruit aléatoire et il y a donc bien un bénéfice à le soustraire. Pour une correction à grande échelle du champ d'illumination, cela n'a pas vraiment d'importance mais les flats ont aussi pour but de corriger les variations de sensibilité d'un pixel à l'autre. C'est inutile pour calibrer une image astro traditionnelle mais c'est beaucoup plus important pour des applications types photométrie. C'est bien pour ça que la soustraction des darks et des bias est décrite dans tous les process de réduction de données pour calibrer les flats. Par exemple un papier récent décrivant les process de calibration d'images issues de télescopes chinois équipés de 6200MM: https://arxiv.org/abs/2504.01616

Bien que je trouve que la technique des bias synthétiques soient tout à fait ok pour calibrer des flats (cela dit je ne trouve pas qu'ils soient plus simples que des vrais bias) je ne suis pas du tout d'accord avec cette idée. Si l'on considère qu'un masterbias introduit du bruit lors de la calibration (ce qui est indéniable), il faut alors également considérer le signal (indésirable) qu'il supprime. Or, le simple fait de pouvoir visualiser ce signal sur un masterbias démontre que celui ci est supérieur au bruit présent dans l'image. En d'autres termes (et de façon très simplifié), lors de la soustraction d'un masterbias on enlève plus de signal indésirable qu'on ajoute de bruit. Pour des application de nature scientifique, la calibration d'un flat avec un masterbias (ou mieux avec un masterdark) reste la meilleure façon de procéder.

Désolé mais je ne comprend toujours pas ce que tu proposes: dans un prétraitement classique, tel qu'il est conseillé notamment par Siril, on ne soustrait pas l'offset des darks. Voici l'ordre habituel des opérations: 1) Intégration des darks pour créer un masterdark 2) Intégration des bias pour créer un masterbias 3) Calibration des flats par soustraction du masterbias 4) Intégration des flats calibrés pour créer un masterflat 5) Calibration des lights par soustraction du masterdark et division du masterflat 6) Intégration des lights calibrés pour créer un masterlight La technique du bias synthétique consiste à remplacer à l'étape 3 la soustraction du masterbias par la soustraction d'une valeur fixe correspondant au niveau d'offset des images. Peux tu préciser à quel étape intervient ce que tu proposes?

La question initiale n'est pas claire: que veux tu dire par "pourquoi faire appel à une niveau du Bias , si le logiciel peut utiliser la valeur moyenne du Dark… "? Parles tu de la calibration des lights ou des flats? Veux tu dire que le logiciel pourrais utiliser directement la valeur moyenne du masterdark plutôt que de soustraire ce dernier. Quel en serait alors l’intérêt vu qu'il dispose du masterdark? Dans le lien cité au dessus il est expliqué qu'il est possible d'utiliser une valeur de bias synthétique pour calibrer les flats. Pour calibrer les les lights, il est possible de faire la même chose mais les résultats sont alors loin d'être optimum. Comparer un masterbias à un masterdark uniquement en comparant leurs moyennes est trompeur: une simple comparaison visuelle entre les 2 images permet de révéler les différences qui existent entre les deux avec la présence de pixels chauds dans le masterdark (d’autant plus nombreux que la durée d'exposition des darks augmente). C'est ce qui justifie de calibrer les lights en soustrayant un masterdark qui va corriger directement ces pixels chauds.

C'est beaucoup mieux je trouve. Le résultat est à la fois plus beau et plus intéressant avec une vrai distinction entre les zones Ha et OIII.

Un autre très bel exemple. La couche OIII apporte un vrai plus sur cette galaxie selon moi (quand on sait où regarder!)

Je ne crois pas que ce soit une histoire de temps de pose. A mon avis tu as fait une erreur quelque part lors de la composition. Je dois dire que je n'ai jamais vraiment ajouté une couche OIII à une image RGB et que je ne peux pas vraiment te conseiller mais je dirais que l'ajouter juste sur la couche bleu est une erreur (les 501 nm de la raie spectrale de l'OIII sont situés entre le vert et le bleu mais plus proche du vert). L'image de Romain est un bon exemple (même si je pense qu'il a trop supprimé toute nuance de vert de son image): https://www.webastro.net/forums/topic/271050-m33-saison-2-en-haoiilrgb/ Comme tu le dis IC132 émet à la fois en Ha et en OIII, le résultat ne doit donc pas être une nébuleuse toute rouge. C'est un bon test (et pareil pour NGC588) Nico

Hello Franck, Disons que je pense qu'une intervention d'une poignée de membres parmi les 66000 de webastro ne soit pas suffisant, que j'ai un doute sur le fait que la manip libère réellement de l'espace sur les serveurs et que je trouve dommage de supprimer tes images si la solution retenue au finale est une augmentation des capacités de stockage. Après je me garderais bien de critiquer les administrateurs, déjà ils sont bénévoles et je suis sûr qu'ils font du mieux possible. J'imagine que ce genre de chose peut prendre du temps. Écoutons ce qu'ils nous conseillent et prenons notre mal en patience! Nico

Hello @lionthom Très belle image mais (a cause des soucis actuels du forum sans doute) on n'a pas accès à la pleine résolution et on distingue donc peu les détails. Je suis tout de même surpris car je ne vois pas vraiment les émissions OIII auxquelles je m'attends dans cette galaxie (IC132 apparait toute rouge par exemple alors qu'elle émet très fort en OIII) Comment as tu ajouté cette couche OIII?

Hello Sam, Il est bien sur sympa de faire ce genre d'action pour aider le forum mais je crois que ce genre d'initiative est contre productive et peut générer des conséquences inattendues. Les administrateurs du forum connaissent les vrais causes et circonstances de la situation actuelle et donc les meilleurs solution pour la régler. Si du nettoyage doit être fait ils pourront surement le faire de façon beaucoup plus efficace que nous et si une autre solution est retenue (type augmentation de capacité) alors le nettoyage n'est plus nécessaire et une intervention manuelle de beaucoup d'utilisateurs peut ne pas être sans conséquence. Par ailleurs il est toujours dommage de supprimer les images d'un post, quelle que soit leurs qualitées. J'aime rechercher des choses dans les archives du forum et je suis souvent frustré quand les images ne sont plus disponibles. Il est par exemple très frappant de constater l'évolution des résultats en astrophoto dans les 2 dernières décennies mais il est presque impossible d'obtenir des exemples pour les premiers messages de ce forum. C'est une perte à mon avis. Il est préférable d'attendre à mon avis.

Oui, je connais. Tu as aussi la petite roue à coté de la cloche en haut. Mais les autres thèmes ne me conviennent pas vraiment et il me semble que le thème "Bleu" souffre du même problème de contraste avec du texte blanc sur fond bleu claire.

Bonjour, En plus de la problématique de joindre des images sur le forum il y a eu récemment un changement d’apparence que je trouve étrange. Désormais, quand on arrive sur une des rubriques du forum, ça ressemble à ça: Je n'ai pas d'images de comment s'était avant mais je suis sûr qu'il n'y avait pas ces textes en blancs qui, je trouve, ne facilite pas la lecture. S'agit-il d'un changement volontaire?

Superbe! J’apprécie particulièrement les acquisitions en OIII qui sont plutôt rare sur cette cible alors qu'il y a des objets qui émettent fort dans cette longueur d'onde comme on le voit bien dans ta version HOO. Peut on en savoir un peu plus sur le traitement et en particulier l'ordre des opérations (dans les grandes lignes) pour gérer toutes ces couches?

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.