nico1038

Peut être qu'un nouveau post serait plus approprié mais quel est ton problème exactement? Les DOF sont des images comme les autres. Que se passe t'il quand tu essais d'en ouvrir un dans Siril (et en particulier qu'affiches la console?)

Hello, Ça n'est pas bien grave mais la version flatpak de Siril 1.4.2 a une icône svg un peu curieuse qui dénote un peu dans l'interface de kubuntu 24.04 (et j'imagine des autres distributions) En cherchant un peu, je crois avoir trouvé l’icône en question ici: /var/lib/flatpak/app/org.siril.Siril/current/active/export/share/icons/hicolor/scalable/apps/org.siril.Siril.svg La voici: org.siril.Siril.svg Et voici ce que ça donne dans le lanceur de kubuntu par exemple: Nico

Hello Pascal, C'est une superbe image. J'adore le cadrage !

Hello Valentin, Elle est très belle et les couleurs de la V2 me semblent en effet meilleures que sur la première version. Je trouve quand même que tu as eu la main un peu lourde sur les curseurs. Ces grandes galaxies que l'on peut résoudre en étoiles sont difficiles à traiter car la déconvolution est rendu délicate par la présence d'étoiles visibles dans la galaxie et que ces populations d'étoiles peuvent facilement être interprété comme du bruit par les outils de débruitage. Je ne sais pas quels outils tu as utilisé exactement (noisex et blurx?) mais je pense que c'est leur utilisation excessive (associé peut être avec des masques ?) qui conduit à une image trop lisse et à des artefacts et hétérogénéité dans le fond de ciel.

Hello @Mizery Tout d'abord bravo pour le travail effectué. Cependant, au risque de passer pour un râleur un peu aigri (ou pour un puriste élitiste), je pense que ce genre d'approche à base d'IA est un risque pour le sens et l'intérêt même de l'activité de l'astrophotographie amateur. Faciliter les choses est évidemment positif si cela peut permettre à plus de monde de découvrir l'astrophoto, mais la simplification ne peut pas se faire à n'importe quel prix. L'esthétique et le côté spectaculaire du résultat obtenu ne doivent pas être les seuls critères pour juger du résultat d'un traitement. Il y a, me semble-t-il, un aspect scientifique dans l'astrophotographie amateur qu'il faut absolument conserver et qui doit faire placer la cohérence et la réalité du résultat au-dessus de l'aspect esthétique. Avec l'IA, le risque est donc double à mon sens: 1) Le premier risque est donc de s'affranchir de la réalité en cherchant uniquement à obtenir un résultat plaisant. Dans ton exemple de la tête de cheval par exemple le résultat "chef d'oeuvre" m'a tout de suite intrigué. C'est une nébuleuse célèbre que l'on voit souvent sur ce forum et que j'ai moi-même imagé à plusieurs reprises et il y a quelque chose qui ne va pas dans cette image. La résolution est très basse, donc il est difficile de se faire une idée précise, mais en comparant l'image d'origine avec le "chef-d'œuvre" on constate que certaines étoiles ont bougé et que d'autres sont même apparues ou ont disparues ! Il est facile de vérifier que l'image d'origine est correcte vis-à-vis de la position des étoiles alors que le "chef-d'œuvre" ne l'est pas. Je ne sais pas ce qui s'est passé exactement (c'est souvent le problème avec l'IA), mais la position des étoiles n'est pas, selon moi, quelque chose de négociable en astophoto! Je crois également qu'il y a d'autres problèmes avec le résultat final (par exemple, il me semble que la structure visible juste en bas à droite d' Alnitak n'existe pas) bien qu'il soit difficile d'être affirmatif avec la résolution proposée (pourrais-tu partager les images avant/après en pleine résolution) ? 2) L'autre risque, plus subtile, mais encore plus problématique est la décorrélation du résultat produit par l'IA avec les données acquises. L'IA étant en effet capable (en se basant sur sa base de connaissance), de générer des informations bien réelles qui ne sont pas présentes dans les données originales. C'est quelque chose que j'ai déjà observé avec des résultats de traitement basé sur l'IA qui proposait un champ supérieur à celui des images acquises (et où il ne faisait donc aucun doute que les données n'étaient pas seulement issues de ces acquisitions) ! Cela soulève bien entendu la question de l'intérêt même d'acquérir ses propres images si elles ne servent pas de base à l'image finale. Chacun fait bien sûr ce qu'il veut, mais il me semble important de réfléchir à ces sujets, car je pense qu'ils peuvent conduire à un désintérêt profond pour l'activité même de l'astrophoto dans les années à venir. Nico

Une image splendide. La version recadrée en particulier est saisissante. Bravo Dan

Non pas du tout. J'ai acheté ce tube dans les petites annonces et c'est une configuration standard du ONTC tel qu'il est vendu par Teleskop Service.

Il me semble que le miroir est un Orion Optics UK. Sa focale réelle est de 880 mm ce qui me donne un rapport F/d natif de 4.4

Oui, c'est très certainement le capteur qui évolue. Personnellement j'ai une 2600MC depuis près de 5 ans et j'ai dû refaire ma bibliothèque de darks a plusieurs reprises. À chaque fois, je m'en suis rendu compte, comme toi, lorsque des pixels chauds ont commencé à apparaitre sur mes stacks. Une chose à noter aussi est que le script OSC de Siril utilise par défaut l'agorithm "Winzorized Sigma Clipping" qui est très bon pour cacher la présence de ces pixels chauds résiduels. Je trouve l'algo "Linear Fit Clipping" utilisé par défaut dans WBPP moins efficace pour ce problème particulier des pixels chauds (bien sûr il est possible de changer l'algo dans WBPP) Oui un dithering de 10 pixels est en effet très efficace pour l'élimination des pixels chauds mais avec ma monture (une Ioptron CEM40) et mon newton 200/900, cela nécessite plus de 10s supplémentaires de stabilisation par rapport à un dithering de 2 pixels. Autant te dire que je préfère faire des darks et gagner des dizaines de minutes d'acquisition sur la nuit!

Pas d'accord Michel: la réjection ne suffit pas toujours à supprimer les pixels chauds. Cela dépend étroitement du nombre d'images qu'on empile et de l'agressivité du dithering que l'on a fait durant l'acquisition. Les traces de ces pixels peuvent parfois être difficiles à identifier, mais une comparaison entre une image calibrée avec un masterdark et une image qui s'appuie uniquement sur la réjection pour éliminer ces pixels est souvent révélatrice. De plus, augmenter l'agressivité du dithering pour régler ce problème se traduit immédiatement par des temps de stabilisation qui augmentent entre les poses et donc du temps d'acquisition en moins. C'est un compromis qui a peu de sens selon moi quand on compare avec la simplicité d'une soustraction d'un masterdark.

Tu peux vérifier facilement ce qui s'est réellement passé en utilisant les fichiers intermédiaires de Pix (c'est à ça qu'ils servent) Dans ton cas, il faut comparer un fichier calibré (fichier avec le suffixe _c) avec le même fichier cosmetized (avec le suffixe _c_cc). Tu devrais trouver des pixels chauds dans le premier et regarder si ils ont bien été supprimé dans le second. Si c'est le cas, alors c'est bien la correction cosmétique qui aura fait le job. À noter qu'il peut être plus simple de dématricier les 2 fichiers que tu compares pour identifier les pixels chauds plus facilement.

Pour partager des fichiers volumineux il faut mieux passer par un service dédié type googledrive, dropbox, wetransfer,... et partager un lien public ici. C'est la meilleure façon d'analyser ton problème correctement car il est difficile d'avoir des certitudes sur ce qui se passe autrement tant il y a de possibilité. Je pense que c'est lié à la calibration car le log semble indiquer qu'il n'y a aucune translation lors de l'alignement, ce qui est suspect.

Si DSS fonctionne bien pour toi, c'est parce que tu as modifié ses réglages pour qu'ils conviennent à tes images et à tes conditions. Je doute fortement que tu utilises les réglages par défaut du logiciel (empilement par moyenne sans réjection par exemple). Et tu as très probablement dû activer la correction cosmétique pour traiter les pixels chauds. Mais il faut se méfier avec ce type de correction cosmétique (qui est d'ailleurs également disponible sur Pix et Siril ) car elle peut avoir des résultats désastreux sur certaines images (surtout pour les images couleurs) En tout cas, conseiller d'utiliser DSS dans ce cas-là sans préciser d'activer la correction cosmétique ne va pas régler le problème des pixels chauds. C'est pour ça qu'il est important de comprendre les problèmes rencontrés et les outils qui vont permettre de les régler. Quant au côté intuitif, c'est très subjectif selon moi. Je suis le plus à l'aise avec Pix car c'est celui que j'utilise le plus et je suis un peu perdu à chaque fois que j'utilise DSS Je traite toutes sortes d'images (pas seulement les miennes) et parfois sans les fichiers de calibration nécessaires. Sans même parler de la différence entre les logiciels (qui ne veut pas dire grand-chose à mon avis si on ne précise pas un peu plus comment on les a utilisés), je vois des différences de résultat considérables au sein d'un même logiciel selon les réglages, algorithmes et méthodes employées.

Bien que j'utilise essentiellement Pix et Siril pour prétraiter les images, j'utilise également DSS régulièrement et je n'ai pas le même avis que toi sur ce logiciel. Il n'est pas mauvais, mais il est loin d'être infaillible et, comme les autres, le résultat dépend largement de la qualité et des caractéristiques des images et des réglages utilisés. Je t'assure qu'avec des images vraiment difficiles, les réglages par défaut ne peuvent pas suffire, quel que soit le logiciel.

Le log confirme qu'un masterdark a bien été utilisé mais il ne semble pas très efficace... Essayer d'autre logiciel peut être utile, mais je crois que comprendre ce qui se passe est la meilleure chose à faire. Tous les logiciels que tu cites font en réalité des choses très similaires en termes de prétraitement quand on sait utiliser leurs fonctionnalités et les régler de façon similaire.

Hello @Champfleuri Il semblerait que les images soient alignées sur les pixels chauds et pas sur les étoiles (on ne constate aucun déplacement lors de l'alignement sur l'image de référence). Je penche fortement pour un problème de calibration. Pourrais-tu partager une image brute ainsi que ton masterdark et ton masterflat?

Alors dans Pix il faut ouvrir le process CosmeticCorrection et le configurer comme cela: A noter que la valeur de 3 pour le Hot Sigma convient si tes images sont correctement échantillonées. Si tu es sous échantillonée il faut sans doute augmenter cette valeur. Ensuite tu crées une instance de ce process (avec le bouton trianglulaire en bas à gauche) et tu l'appelles (par exemple) CC Ensuite dans WBPP du décoches Automatic dans la section "Cosmetic Correction" et tu choisis ton template CC Ce que cette manip va permettre c'est d'utiliser le mode "Auto detect" du process CosmeticCorrection pour identifier les pixels chauds restants après la calibration et les remplacer par une moyenne des pixels voisins (en fait les pixels n+2 pour les images couleurs). C'est une opération peu rigoureuse mais relativement efficace quand on a pas un masterdark sufisament récent.

Ce sont bien des pixels chauds. Si tu utilises WBPP, tu as selon moi 2 possibilités: La plus propre est de refaire des darks afin de mieux caractériser ton capteur. Cela devrait corriger immédiatement ces pixels chauds. La deuxième est d'utiliser la correction cosmetique de Pix en mode Auto-detect (pas le mode auto par défaut qui utilises le masterdark). Il faut pour cela créer un template du process CosmeticCorrection et le définir dans WBPP. Personellement je n'aime pas trop utiliser ce processus car le hot sigma doit être configuré finement pour ne pas dégrader les étoiles.

Le script est le bon mais quelque-chose ne se passe pas bien lors de la calibration. Soit c'est en effet les flats qui ne correspondent mais ça peut aussi être lié aux darks ou aux bias. Difficile de t'en dire plus sans les fichiers. Pour les artefacts, as tu vérifié la profondeur en bit de ton master?

Hello @Fredvelo Les poussières devraient être corrigées par les flats. Comment as tu procédé pour pretraiter tes images? Tu as utilisé un des scripts de Siril? Pour les structures circulaires, je pense que le master n'est pas en 32 bits et que la profondeur de16 bits n'est pas sufisante pour afficher correctement cette image linéaire.

Non c'est OK, le problème était sans doute que tu ne lisais pas le motif de bayer dans l'en-tête des fichiers (si j'ai bien compris les changements que tu as effectué)

Hello @Polo666 La faiblesse generale des couleurs et la palette des couleurs sont caractéristiques d'un problème de dematriciage. Tes images sont bien dematriciées (car elles sont en couleurs) mais elles n'ont pas été dematriciée avec le bon motif. Comme avec un Asiair il est probable que le motif inscrit dans l'en-tête des fichiers fits soit correct, le problème se situe sans doute dans le sens de lecture des fichiers. Dans Siril il faut que tu règles le sens de lecture des fits en TOP-DOWN. Nico

Hello Sam, Je ne suis pas surpris: je ne connais pas cette caméra particulière mais j'ai déjà vu souvent ce genre de problème. La dimension des images depend etroitement du driver utilisé. C'est la raison pour laquelle il est important dans la mesure du possible de prendre les fichiers de calibration dans la même configuration que pour les lights (même logiciel et même drivers). Dans ton cas la différence de dimensions permet d'ailleurs d'identifier le problème immédiatement mais j'ai aussi vu des cas où les dimensions des images sont identiques mais où les pixels sont en fait décalés entre les lights et les images de calibration! Cela rend l'analyse plus complexe. Dans ton cas je pense que le plus simple est d' installer/reinstaller les drivers natifs Altair Nico

Tu as bien raison et j'irai même plus loin : le terme "offset" signifie littéralement "décalage", or il y a des décalages partout lors de l'acquisition, du prétraitement et du traitement de nos images. Il y a donc quantité de sens différent pour le terme en fonction du contexte où il est utilisé (le réglage de la caméra, le décalage du signal en ADU, l'ajout d'un socle lors de la calibration, le niveau de noir,...). Le choix d' "offset" pour designer les images bias est donc particulièrement mal choisi et ajoute à l'ambiguïté et à la confusion. Je suis d'ailleurs heureux de voir que Siril, dans les dernières versions, a remplacé ce terme par bias (et biases) dans ses scripts (même si le terme "offset" reste encore malheureusement présent dans l'interface).

J'aime beaucoup. Le résultat reste naturel selon moi.