nico1038

Le réglage de l'offset n'est pas accessible avec l'Asiair. Il est fixé ici à 15 sur toutes ces images

Je ne suis pas d'accord avec ton analyse, la première image (1_Light_NGC4631_300.0s_Bin1_20250613-011413_0009.fit) montre déjà très clairement un problème. Une image astro (visualisée en linéaire) ne doit pas avoir un fond de ciel "plutôt gris"! Avec cette image tu perd déjà plus de 50% de la dynamique de la caméra. Rien n'a changé dans la caméra et elle n'a aucun problème à mon avis. Le problème est juste exacerbé par les conditions d'acquisition actuelles et la solution est de modifier tes réglages (le gain) et la durée des expositions.

Hello @GoblE Deux questions par rapport à ce problème de calibration et d'orthogonalité: Où (dans quel coin du ciel) réalises tu ta calibration ? Ton réglage du calibration step est il correcte: en combien d’étapes se fait la calibration sur les 2 axes?

Hello Seb, Pour moi il y a 3 possibilités: Un problème de calibration Un problème de traitement Un problème plus fondamental type walking noise ou un quelque chose qui impact directement les images brutes (buée,...) Pour trancher il faudrait nous en dire plus sur ton matériel (notamment le modèle de ta caméra) et la façon dont tu as pré-traité tes images (avec des DOF, quel logiciel,...) et peut être partager l'image en sortie d'empilement

Ok, le mot clé ROWORDER = 'TOP-DOWN' est bien présent dans le fichier d'origine. Si on l'ouvre dans Pix avec les réglages Fit par défaut, l'image est affichée dans le bon sens et peut être dématriciée correctement avec le motif "RGGB" Dans Siril, c'est différent car Siril utilise l'info du mot clé ROWORDER pour le dématriciage mais pas pour l'affichage pour lequel il considère toujours le sens 'BOTTOM-UP'. (J'avais posé une question sur ce point à Cyril ici : http://www.astrosurf.com/topic/168812-m13-imx-571-besoin-de-votre-aide/?do=findComment&comment=2407240 ) Du coup l'image apparait inversée même si elle est dématricié correctement. Après une résolution astrométrique dans Siril, l'image est remise dans le bon sens pour l'affichage mais le mot clé ROWORDER, lui, reste à TOP-DOWN . Du coup la matrice de l'image est inversée sans que cela se reflète sur le mot clé ROWORDER et l'image apparait alors inversée quand on l'ouvre dans Pix... Pour moi c'est un bug dans Siril mais je pense que la réponse risque d'être que le mot clé ROWORDER ne sert qu'au dématriciage et pas à l'affichage. Malheureusement, avec ce workflow, j'ai peur qu'il n'y ait pas vraiment d'autre solution que de faire une inversion miroir à la main.

C'est toujours la plaie ces histoires de Roworder. C'est une grande faiblesse du format fit à mon avis que de laisser le choix des deux orientations! Pourrais tu partager une image brute parce que j'ai du mal à comprendre? Ton image brute originale (en sortie de Nina) a t'elle un mot clé ROWORDER? Je crois qu'on ne voit pas la bonne zone de l'entête dans ton premier screenshot.

Il n'y a en fait qu'un miroir possible, après c'est juste une question de rotation. Tu peux donc le corriger indifféremment avec un miroir horizontale ou verticale, dans les deux cas ton image sera dans le bon sens. Pour le passage de Pix à Siril, ce qui se passe sans doute c'est que Siril écrit le fichier Fit en BOTTOM-UP et que Pix le lis en TOP-DOWN. C'est quelquechose que tu peux changer dans l'un ou l'autre des logiciels.

V2, sans hésitation!

L'image de l'outil transformation de l’histogramme que tu nous montres ne peut pas correspondre au stretch réalisé sur cette image: étirer une image ne consiste pas à adapter l'échelle aux valeurs min et max 32 bits mais à modifier la balance des tons moyens en la baissant (en général très fortement) et à ajuster les basses lumières. Ici tu nous montres un transformation ou tu augmentes uniquement d'un pouillème la valeur des tons moyens. Çà ne colle pas. En tous cas, si les valeurs des pixels ne sont pas clippés lors d'une transformation de l'histogramme, il doit être possible effectivement en théorie de faire la transformation inverse pour retrouver une image linéaire mais je ne suis pas sûr de comment procéder? Je crois que c'est plus fondamental que ça: une image astronomique n'a réellement de sens physique que quand la luminosité de chaque pixel dépend du nombre de photons reçu de manière linéaire. De nombreux traitements fondamentaux dépendent de cet état et ont besoin de cette linéarité. Par exemple le calcul d'une psf, la déconvolution, la correction cosmétique ou toute forme d'analyse (FWHM, estimation du bruit, SNR,...) ne peuvent être réalisés correctement que sur une image linéaire. C'est vrai pour Pix mais aussi pour Siril et APP par exemple. On peut certes faire plein de choses sur une image étirée mais on est alors dans le domaine de la retouche d'image et on perd tout l'intérêt des outils de traitements astro.

Je trouve cette dernière version un peu moins réussi que la première. Voici ce que j'ai obtenu avec Pix:

Bonjour Laurent, On ne peut vraiment pas faire grand chose avec une image déjà étirée. Je ne sais pas ce que tu veux dire exactement par étirement "sans perte" mais c'est une opération qui n'est pas réversible (d'autant plus qu'on ne connait rien aux caractéristiques de l'étirement que tu as réalisé). Il y a un curieux vignetage inversée sur cette image (un problème de calibration?) qu'il faudrait essayer de corriger mais ça ne peut se faire correctement qu'avec l'image linéaire.

Bonjour Jacques, Je trouve ton traitement très réussi et naturel. En cherchant bien je ne vois que 2 défauts: Il faudrait croper un tout petit peu plus serré pour enlever les artefacts sur les bords (surtout en bas de l'image) Il me semble qu'il y a des artefacts circulaires sur les étoiles les plus brillantes. A voir à quel moment du traitement ils apparaissent.

La moyenne dont je parle est la moyenne de la valeur des pixels de l'image ce qui représente en gros la valeur du fond de ciel pour la plupart des images. On peut l'obtenir dans Pix avec le process Statistics ou dans Siril dans Tools> Image Analysis > Statistics Sur ton image de M101 la moyenne est de 6442 sur une plage 16 bits de 65536 valeurs soit une valeur normalisé (sur la plage [0,1]) de 0.098. C'est déjà énorme (pour te donner une idée, avec un télescope à f3, une image de 180s me donne une moyenne à 0,01) D'ailleurs, ça se voit: on distingue la galaxie même quand l'image est linéaire. Ça signifie que tu perds sur la dynamique de l'image. Sur l'image de ngc4631 c'est encore bien pire: la moyenne normalisée est de 0,35 Bref, dans les deux cas le fond de ciel est déjà bien trop haut (même si pour M101 l'image reste exploitable). Pour utiliser efficacement cette caméra avec le gain de 252 il faut absolument que tu réduises considérablement tes temps de pose.

Tu peux poster une image de cette session de M101, je suis curieux de voir la valeur moyenne de l'image.

Je pense que cette caméra a la particularité d'avoir le fond de ciel qui explose de façon non linéaire dès qu'on franchit un certain cap en luminosité. C'est quelque chose que j'avais déja observé avec ce modèle sur le forum de Pix: https://pixinsight.com/forum/index.php?threads/ln-errors-while-using-wbp.25126/ et https://pixinsight.com/forum/index.php?threads/ln-reference-generation-fails-in-wbpp-it-used-to-work.23385/ Tu as sans doute rencontré ce problème car effectivement, comme le dit Seb, le ciel n'est pas assez sombre en ce moment (même à minuit). Tu as deux possibilités à mon avis: réduire le gain ou réduire les temps de pose. Je te conseille le deuxième choix. Avec les caméras CMOS modernes il n'y a presque que des avantages à réduire les temps de pose (jusqu'à un certain point bien sûr)

Hello Yves, Pour un problème spécifique comme le tien il est mieux à mon avis d'avoir ton propre sujet. Ça permet de rassembler les interventions ce qui facilite les choses aussi bien pour toi que pour les autres. L'idéal serait d'avoir les images fit problématiques pour pouvoir les analyser. Les as tu conservé (notamment l'image très lumineuse de 180s que tu évoques)? Sinon peux tu ouvrir un fit de n'importe quel image faite avec cette caméra et vérifier dans son entête quel est l'offset réglé par l'Asiair ? Quand tu as eu ces images blanches, le problème s'est il reproduit sur plusieurs images ou as tu interrompu immédiatement le run? Et ça n'explique pas directement le problème mais je pense que des poses de 5 min sont complétement inutiles et que tu aurais intérêt à les réduire largement (au moins en broadband)

Hello Cyril, 1) Il n'existe pas de technique infaillible pour traiter ce genre de halo. Il s'agit d'un problème optique qui ne peut donc qu'être camouflé et non pas traité par des méthodes strictes. La différence est importante car elle implique que la correction ne pourra se faire qu'au détriment de l'information contenue dans l'image . Une technique habituelle qui fonctionne bien si le halo est isolé est par exemple de passer en starless, de corriger le halo avec des outils de type clonestamp puis de remettre les étoiles. 2) Là, au contraire, j'ai l'impression qu'il s'agit d'un problème de prétraitement. Il faudrait essayer de regarder l'image linéaire en sortie d'empilement et les images alignées afin de comprendre l'origine du phénomène. Si il s'agit d'un pixel chaud qui n'a pas été corrigé par la calibration, l'idéal serait d'ajouter une étape de correction cosmétique pour régler le problème à la source. Sinon, si tu ne veux pas t’embêter et comme l'artefact est de taille réduite, il est toujours possible d'utiliser le process clonestamp (ou des outils équivalents) 3) L'outil que tu cherches s'appelle SCNR. Cependant ce n'est pas un process à utiliser systématiquement. Avec une calibration des couleurs correctes il n'y a, en principe, pas de raison de l'utiliser. 4) Que veux tu dire exactement par tirer sur le rouge? Normalement, une fois les couleurs calibrés il faut en général éviter d'intervenir sur les canaux RGB individuels. En tous cas je trouve ton image très belle. Je dirais que je trouve juste que les étoiles pourraient être adoucies avec un étirement un peu plus progressif. Nico

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 👍