nico1038

Salut Serge, Bravo: elle est très belle.

Ok: quand tu regardes ce fichier matricié tu te rend compte que certaines lignes sont décalées par rapport aux autres. Les pixels en couleurs sur l'image dématriciée ne sont qu'une conséquence de ces décalages. Si tu as déjà eu ça c'est plutôt une bonne nouvelle à mon avis car ça limite je pense la probabilité d'un défaut sévère de la cam. Comme je te disais je soupçonne une interférence ou peut être un mauvais contact quelque part. Le truc c'est qu'à mon avis tu peux faire le test de jour. Je pense que n'importe quelle photo devrait montrer le même phénomène. Tu devrais donc pouvoir faire des tests facilement.

Hello @nicolas44 Pour être clair: l'image que tu montres est celle d'une image brute, c'est bien ça (pourrais tu partager cette image d'ailleurs plutôt que l'image empilée qui cache un peu le problème)? Le problème est apparu soudainement? Je me demande si ça ne serait pas des interférences électriques. Si j'étais toi j’essaierai: 1) d'écarter le cable usb du câble d'alimentation de la caméra lors des acquisitions 2) de changer les câbles 3) de changer d'alimentation (plutôt une batterie qu'une alimentation secteur) Nico

Là je ne peux pas t'aider: je me contente du wifi de l'Asiair (mais je ne suis jamais loin). Il est vrai que le temps d'apparition de l'image à l'écran peut être un peu long mais cela n'impacte en rien la vitesse des acquisitions. Ça n'est donc pas un très gros problème je trouve.

Je ne sais pas d'où tu tiens ça mais ça n'est pas toujours exact: avec mon AsiairPro par exemple une séquence de 10 images de 60secondes met très exactement 10min et 10s au total à s'écrire sur le disque (le temps d'affichage sur le téléphone ou la tablette est en fait complétement indépendant de la vitesse d'écriture sur le support de stockage) En revanche il est vrai que, quand on réduit les temps d'exposition, la mémoire tampon n'est plus suffisante et des délais supplémentaires apparaissent. Donc c'est vrai qu'avec la 2600MC par exemple on va perdre beaucoup de temps en pose courte avec le mode Autorun ou Plan. Le avi est un format conteneur qui ne dit rien de la compression employée. En l’occurrence, avec l'Asiair c'est du RAW sur 8 bits. Le seul problème étant donc la profondeur de seulement 8 bits mais qui est sans doute suffisante pour des poses courtes sur la plupart des objets? A mon avis, c'est possible d'utiliser l'Asiair en poses courtes grâce au mode vidéo si tu peux te contenter du format 1920x1080. Je ferais quand même des tests avec ta 2600MC avant d'acheter une nouvelle caméra... Il faut également bien calculer l'espace de stockage disponible car les fichiers risquent d'être gros. Quand au modèle de caméra, je ne sais pas: les petits pixels de la 585 sont intéressants pour essayer d'améliorer encore la résolution mais on perd alors en signal ce qui est sans doute un problème en poses courtes. Tu n'en parles pas mais la meilleure caméra pour cet usage est sans doute une caméra mono... EDIT: Attention aussi si tu utilises le mode vidéo pour du ciel profond à bien positionner les réglages de balance des blancs WB_B et WB_R à 50

Je ne suggérais pas une seule seconde de faire ce genre de choses pour pouvoir utiliser ta caméra! L'idée est justement de faire des test pour mieux comprendre le problème et éventuellement justifier un retour SAV. Dans ce genre de situation il faut limiter au maximum les variables donc par exemple: 1) Prise d'une série de 20 darks à 30s puis d'une série de 20 darks à 180s avec la caméra dans un environnement bien sombre (si possible démontée du train optique). 2) Changer le logiciel d'acquisition et reproduire le test 3) Changer les câbles et reproduire le test Si dans tous les cas tu vois clairement apparaitre le problème à la 20ème prise alors je pense malheureusement que la caméra est en cause et qu'il n'y a pas d'autres solution que le SAV...

L' "avantage", si le problème apparait sur les darks, c'est qu'il est possible de faire des tests n'importe quand. Je pense d'ailleurs que tu devrais concentrer tes tests sur les darks car cela élime toute sorte de problème potentiel comme la buée ou les reflets (si bien sûr il n'y a aucune entrée de lumière lors de l'acquisition des darks) Un problème d’interférence me semble le plus probable mais je ne vois pas pourquoi cela apparaitrait toujours à la 19ème pose?!

Je ne vois pas en quoi augmenter l'offset changerait quoi que se soit (l'offset a un effet général sur l'image qui ne peut pas expliquer, je pense, ce genre d'artefacts)? Si tu vois toujours le problème apparaitre à la 19ème image c'est très étonnant et il faut creuser de ce coté. Observes tu le même phénomène avec des poses beaucoup plus courtes? Que se passe t'il si tu interromps la séquence après la 19ème image puis la relance après quelques minutes? Peux tu partager un dark où tu vois ce phénomène?

Avec l'Asiair Pro tu peux voir directement le voltage d'entrée directement dans l'interface. C'est très pratique et c'est, à mon sens, cette information qui est réellement significative. Je ne vois pas vraiment comment l’ampérage (qui ne doit pas dépasser 2A grand max sur une HEQ5 en goto) pourrait être un problème (à moins d'avoir un problème de câbles?) Perso, je voyais le clignotement apparaitre quand je passais nettement en dessous des 12V Si tu as une tension de 12,8V directement en sortie de la batterie chargée à bloc, ça me semble peu.

Non mais ça fait un moment que j'ai remplacé ma HEQ5 et il est possible que j'ai raté le clignotement durant les goto. J'avais remarqué par contre que la led se mettait à clignoter lorsque ma batterie (qui alimentait donc mon Asiair) faiblissait. Quelle est la valeur de l'input voltage sur l'Asiair quand tu constates ce clignotement? Et enfin, à mon avis, un clignotement lors du goto n'est pas un gros problème. C'est un clignotement en mode tracking qui doit vraiment alerter.

cela ne devrait pas se produire si Siril est bien configuré. Un fichier fit comme un fichier raw ne sont que des containers qui contiennent la matrice de pixels de l'image ainsi que des metadata associés. Le format fit est à privilégier si possible pour une image astronomique car il permet d'enregistrer des metadata précieuses pour cet usage. Si le dematriciage d'un fit ne donne pas le même résultat que la même image en CR2 cela signifie que quelquechose ne va pas dans la façon dont Siril lit le fit. Soit le motif de bayer n'est pas correcte, soit le sens de lecture du fit est mauvais (TOP-DOWN vs BOTTOM-UP)

Pas d'accord: les ports 12V de l'Asiair sont dimensionnés pour alimenter les caméras. Voir par exemple cette discussion en face: http://www.astrosurf.com/topic/161450-asi533mc-pro-aide-débutant/?do=findComment&comment=2289889 Cette idée vient d'une mauvaise interprétation des documents ZWO qui précisent bien au contraire que ces ports sont destinés à l'alimentation de la caméra. C'est l'alimentation de la monture depuis l'Asiair qui est déconseillé dans certains cas. Personnellement avec un Asiair Pro et un Asiair Mini ça fait des années que j'alimente la totalité de mes appareils depuis l'Asiair. Y compris mes montures (une HEQ5 puis une Ioptron CEM40).

OK mais je pense au contraire que l'on ne peut pas analyser correctement le problème sans une calibration aux petits oignons. En tous cas n'hésites pas à poster quelques images brutes et tes masters si tu le souhaites.

Effectivement: l'anneau est sans doute le signe d'un problème plus sérieux mais les images que tu montres dans le 3eme message ont avant tout un gros problème de calibration. Et il est difficile de se faire une idée précise du problème sur une image mal calibrée. Une calibration avec des flats mais sans darks ni bias ne peut pas fonctionner correctement.

Hello @roza Pourquoi acec ce genre de problèmes dillumination ne pas faire de DOF? C'est la seule solution pour améliore les choses et avoir un traitement beacoup plus simple. Nico

Je d'accord avec @Ant-1: dans les exemples montrées au début il est incontestable que la poussière a bougé et c'est ce qui explique la mauvaise correction. Si tu penses qu'il y a un autre problème dans tes nouveaux tests, peux tu poster à nouveau une image brute et le masterflat et masterdark correspondants?

Très belle image. Je trouve que la galaxie est très bien traitée. Personnellement j'aurais juste essayé de révéler un peu plus le centre avec le process HDRMT. Pas d'accord avec cet ordre d'opération. Avec Siril ou avec Pix, la calibration doit avoir lieu le plus tôt possible dans le traitement. La suppression du vert n'est là que pour compenser une éventuelle défaillance de la calibration. La doc de Siril précise d'ailleurs que cet outil doit être employé sur une image étirée, donc bien plus tard dans le traitement (https://siril.readthedocs.io/fr/stable/processing/colors.html) Le problème de Siril dans la version actuelle est que la calibration se fait par simple photométrie qui ne tient pas compte du spectre des étoiles ou des caractéristiques de nos optiques. Cela entraine des imprécisions qui faussent souvent le résultat final avec parfois des déséquilibres évidents dans le résultat. C'est pour ça qu'on doit intervenir avec des outils comme la suppression du bruit vert ou une modification des courbes à la main par exemple. La calibration par spectrophotométrie qui existe dans Pixinsight et arrive dans la prochaine version de Siril est un changement important car les résultats sont très souvent bien meilleurs et ne nécessite plus d'intervention par la suite. L'idée est alors de calibrer les couleurs puis d'éviter dans la mesure du possible toute opération qui pourrait modifier cet équilibre.

Une autre marque qui m'a l'air particulièrement intéressante pour l'astro. Notamment les modèles 30Ah et 50Ah: https://www.amazon.fr/gp/product/B0CMQ9PNG4/ref=ox_sc_act_title_1?smid=A2EP3TN9KIZP5L&th=1

On l'attend avec impatience!

Avant la version 1.9, WBPP utilisait par défaut GESD à partir de 15 images. C'était d'ailleurs une des raisons qui expliquaient pourquoi WBPP était lent (GESD est très performant pour le rejet mais très lourd). Avec la 1.9 c'est désormais l'algorithme Linear Fit Clipping qui est choisi par défaut à partir de 15 images. C'est plus rapide mais ça peut valoir le coup de le changer si on un rejet imparfait des pixels déviants. FBPP utilise lui l’algorithme Winsorized Sigma Clipping C'est aussi pourquoi ces comparaisons sont toujours limités au fait qu'il existe de nombreux réglages et que les valeurs par défaut ne sont pas forcément idéales. D'ailleurs, à mon avis, la meilleure façon de comparer les logiciels entre eux est d'essayer d'utiliser les mêmes algorithmes dans la mesure du possible (il sont souvent disponibles). Mais ici, pour les tests de @krotdebouk, avec des empilements de 300 images, le rejet des pixels déviants n'est pas ce qui fait la différence. C'est plutôt l'alignement qui est en cause à mon avis.

Oui: je pense que cette carte est la cause la plus probable du problème.

Merci pour cette analyse. J’avoue ne pas voir de grande différences sur ces screenshots! A mon sens Il n'y a pas réellement de débruitage au moment du prétraitement (ni avec Siril, ni avec Pix). Je crois que les différences subtiles que tu observes sur le bruit et les détails sont probablement dus aux algorithmes d'alignement (et peut être aussi de dématriciage) et à l'interpolation qu'ils entrainent. Il faudrait répéter le test en changeant d'algorithme sur Siril (car dans FBPP je crois qu'on ne peut rien changer). Personnellement après avoir fait quelques tests, je considère que FBPP est complètement valable dès que le nombre d'images à empiler est suffisant et surtout quand on est dans le cas d'un empilement classique. Quand les conditions d'acquisitions sont difficiles avec des gradients qui varient ou avec des problèmes de rejet (type géostationnaire), alors WBPP peut faire une différence significative en proposant des réglages pour gérer ces particularités. Il est également nécessaire de l'utiliser quand on empile des images issues de plusieurs setups car cela necessite alors la prise en compte de la distorsion lors de l'alignement, ce que ne permet pas FBPP.

Salut Philippe, Ce fichier est corrompu, comme visiblement ces autres fichiers sur ton disque dur. Siril n'est pas en cause et ce n'est pas la peine d'essayer de convertir ces fichiers dans un autre format: ça ne réglera pas le problème. Il faut avant tout comprendre pourquoi il sont corrompus. Je vois 3 possibilités: Soit ton Canon R a en effet un problème Soit c'est le stockage qui a un soucis, as tu essayé de changer le support de stockage dans l'appareil Soit c'est au moment du transfert que le fichier se dégrade. Comment procèdes tu pour transférer les images de l'appareil vers ton ordinateur? Nico

Je pense que tu es dans le vrai: les algorithmes et étapes utilisés par Siril (en particulier avec ses scripts) sont en effet plus proche de ce qui est fait dans FBPP. On évite notamment certaines étapes très longues comme LocalNormalisation. Pour ton traitement en plusieurs paquets, pour obtenir des paquets de qualité équivalente et éviter de perdre de l'information quand tu les intègres il faudrait repartir les images successives dans les différents paquets. Paquet 1: Images 1,5,9,13,... Paquet 2: Images 2,6,10,... Paquet 3: Images 3,7,11,... Paquet 4: Images 4,8,12,... Ça peut faire une différence significative si la qualité des images a varié lors de la soirée.

Pour SPCC il faut télécharger les fichiers Gaia DR3/SP (soit les 4 fichiers de la petite base soit les 20 de la grande base) et les configurer dans le process Gaia. Oui le dithering fera incontestablement du bien mais je suis quand même surpris par les motifs dans l'image. Je les trouve très présent pour une caméra refroidie (même sans dithering) et surtout ils ne sont pas orientés de la même façon partout dans l'image. C'est très curieux!