nico1038

Hello @grosluc Ton process ne m'a pas l'air correct. Les images RGB doivent être combinées en linéaires avec le process RGBCombination puis (après les différentes étapes du traitement linéaire) les images RGB et la luminance doivent toutes 2 êtres étirées et enfin la luminance combinée avec la couleur avec le process LRGBcombination.

Beaucoup mieux! Et là effectivement on reconnait bien les IFN alors que dans la version d'origine le coté trop régulier des structures n'était pas naturel. Et je ne sais pas si c'est lié à ces problèmes de prétraitement mais du coup même les zones avec un SNR élevées sont mieux définies et je trouve également les couleurs meilleures dans cette version.

Les coordonnées d'un objet étendu comme la rosette ne sont pas absolues, il n'y a pas vraiment de coordonnées correctes (tout comme il n'y a pas de taille absolue pour les objets astronomiques). Tous les catalogues n'ont donc forcément exactement les mêmes informations. Pour la rosette je te conseille de chercher SH2-275 qui te donnera un résultat plus centré. En tous cas ce n'est pas un problème de pointage et c'est la raison pour laquelle il faut toujours vérifier son cadrage avant de lancer ses acquisitions.

Je ne suis pas sûr de comprendre exactement le problème mais as tu vérifié le cadrage avec l'outil framing. Si je cherche Rosette dans Nina voilà ce que ça donne: Les coordonnées de l'objet peuvent paraitre décentrées par rapport aux nébulosités. N'est ce pas ce qui t'arrive?

Superbe, elle est bien plus belle comme ça!

Non c'est bon, c'est ce que je voulais dire mais peut être que ma traduction de repository en répertoire était malheureuse! En tous cas, tant que les scripts et process sont gérés depuis "Manage Repositories", il n'y a normalement aucun problème. La liste est conservée lors des mises à jour et il y a juste à réinstaller les scripts en une fois lors du premier démarrage. A noter quand même que lors d'un changement de version les auteurs des scripts doivent faire le nécessaire pour que leurs scripts soit bien adaptés. Mais pour la 1.9 c'est normalement le cas pour tous les scripts (en tous cas tous les scripts les plus importants) C'est parce que tu utilises le repository rc-astro pour le tensorflow et CUDA. Perso je n'aime pas beaucoup cette solution car pour que cela fonctionne (et si je comprend bien le principe) il installe CUDA dans le répertoire de Pix. Je trouve ça compliqué et je préfère une solution un tout petit peu moins automatisé qui est de remplacer le fichier tensorflow.dll à chaque mise à jour. Cela dit si ça marche, pas de raison de changer. Je ne vois pas pourquoi ça serait nécessaire? Le retour à une version précédente est exactement comme une mise à jour classique: la liste des repository est conservé et je ne vois pas pourquoi il faudrait toucher aux clés de la suite BXT?

Hello @krotdebouk Mon avis: si tu n'es pas sur Mac il n'y a aucune raison de ne pas faire la maj. Il y a clairement des problèmes sur les Mac mais rien de bloquant sur les autres plateformes. Il n'est pas normal de devoir réinstaller tous les scripts (tant qu'ils ont un répertoire), la procédure est normalement d'installer la maj puis de faire un check for update, d'installer les updates et de rédemarrer Pix. En faisant ça en principe tu devrais avoir tous les scripts et process à disposition. Pour CUDA, la seule chose à faire est de remplacer le fichier tensorflow.dll par la version accélérée. La bonne version fait 506226 Ko Pas besoin non plus de toucher aux bases de donnés Gaia DR3, DR3/SP. Ces dernières doivent être situées en dehors du répertoire d'installation de Pix, elles ne sont donc pas impactées par la maj et il n'y a rien à faire à leur sujet. Les nouvelles bases MARS doivent être gérées de la même façon. Je te déconseille d'essayer d'installer 2 versions de Pix en parallèle, à moins d'utiliser une machine virtuelle.

C'est malheureusement le problème du format Fits: ces paramètres que tu évoques ne sont en fait pas normés du tout.

Je n'ai pas de 700D mais je me demande si il n'y a pas un réglage "Release shutter without card" qui pourrait peut être avoir de l'importance ici.

Merci Vincent pour cette très belle série d'amas ouverts.

En fait j'ai plutôt l'impression que la caméra est bien en RGGB conformément à ses spécifications mais que le ROWORDER n'est pas correct. Il me semble que cette image est bien ordonnée en TOP-DOWN, malgré la valeur BOTTOM-UP dans l'entête du fichier. Du coup avec une lecture en TOP-DOWN et un motif RGGB, le dématriciage est ok. Je ne connais pas AstroArt mais, si j'étais toi, je ferais des tests avec un autre logiciel d'acquisition (par exemple ASIImg, le logiciel de ZWO). Cela te permettrait de confirmer le sens d'écriture de l'image et de vérifier si tes soucis de refroidissement sont liés à la caméra ou si il s'agit d'un problème de drivers ou de réglages.

Ok, le keyword ROWORDER est en effet bien présent avec BOTTOM-UP mais il manque l'essentiel mot clé BAYERPAT et donc Siril ne peut par récupérer l'info automatiquement. Le motif de dématriciage correct est GBRG Il faut donc configurer Siril comme cela: L'image peut alors être dématricié correctement: Nico

Hello @leforgeron Il s'agit en effet d'un problème de débayerisation. Soit le motif de bayer n'est pas le bon, soit l'image n'est pas lu dans le bon sens. Pourrais tu partager une image brute au format fit (une image directement issue de la caméra, sans le moindre traitement)?

J'ai compris que tu n'utilises pas les scripts par défaut et c'est surement ok mais, en cas de doute sur ses résultat, il faut à mon sens justement revenir aux bases. Par exemple je ne suis pas sûr que l'on puisse faire l'impasse sur les pixels froids/chauds. Ils peuvent avoir des conséquences que l'on n'imagine pas forcément (normalisation, alignement,...).

Non non, si tu n'utilises pas de darks il faut alors calibrer les brutes en retirant l'offset comme tu le fais. C'est nécessaire. j’émets juste des doutes sur le fait de ne pas utiliser de darks (même si je ne pense pas que ce soit le problème de cet image). Qu'en est t'il de la correction cosmétique? Dans ses scripts de base Siril utilise une correction cosmétique avec un masterdark, ce qui n'est donc pas possible dans ton cas.

Pardon je n'avais pas compris ça. Effectivement ça doit marcher dans ce cas là (cela dit je pense que c'est une mauvaise idée dans l'absolu: autant le bias synthétique me semble complétement ok pour calibrer ses flats autant ça me parait être un problème dans de nombreuses situations pour calibrer ses lights). En tous cas, comme je te l'ai dit plus haut je pense qu'il faut tester une façon de faire plus classique au moins pour en avoir le coeur net.

Les darks servent également à retirer l'offset des lights. C'est nécessaire pour que la division par le masterflat soit valide. Si on n'utilise pas de masterdark il faut alors soustraire le masterbias des lights mais comme tu utilises un bias synthetique je n'ai aucune idée de ce qui est fait réellement?

Donc, si je comprend bien, tu n'as pas utilisé de masterdark sur ce traitement? Mais du coup, par quoi l'as tu remplacé? Je regarderais volontiers tout ce que tu pourras envoyer mais, si j'étais toi, je ferais un test ultra classique avec les scripts de siril et un masterdark et sans retrait polynomial (à mon avis avec un bortle 5 c'est inutile). Il serait intéressant de comparer le résultat de cette intégration "classique" avec l'autre. Nico

Hello @180Vision et très bonne année. J'ai été revoir ta M45 et effectivement c'est très similaire et je ne comprend pas vraiement ce moutonnement. Tu images dans des conditions très polluées? A mon sens c'est peut être un problème de prétraitement mais, comme tu utilises Siril que je connais moins, je ne suis pas sûr d’où peut venir le problème? Si tu veux partager une image brute, ton masterdark et ton masterflat je peux essayer de voir si je trouve quelque chose.

Ok: ça n'est pas une bonne chose et ça explique que la correction cosmétique ne fonctionne pas bien. Tu as un problème d'acquisition. Le logiciel que tu utilises réalise vraisemblablement une balance des blancs et applique un coefficient différent sur les pixels RGB de l'image. Celle ci n'est donc plus une vrai image brute, ce qui n'est pas idéal pour la calibration. Je te conseille de corriger ça pour tes prochaines acquisitions et de refaire des darks et des bias.

C'est une bonne chose d'avoir trouvé le problème mais j'ai peur que l'enquête ne soit pas complétement finit! C'est une option qui fonctionne normalement très bien mais il faut pour cela un bon masterdark. Quand tu ouvres ce dernier (et avec un auto-stretch), est ce que tu peux voir un motif en quadrillage (type bayer)?

Je parlais plutôt du fichier log complet (.log), le ProcessLogger est un court résumé qui n'apprend pas grand chose. Je soupçonne cependant la nouvelle option de correction cosmétique automatique intégrée au process de calibration. As tu comparé une image brute (dématriciée) avec une image calibrée. Vois tu ces traces bleues sur cette dernière?

Hello @Akeenoya et très bonne année. Avant d'essayer de les supprimer il faut essayer de comprendre ce qui se passe et voir si il n'y a pas moyen de corriger. Peux tu partager le log WBPP de ce run?

Très beau trio. Bravo Serge. Si j'étais toi je pousserais un peu la saturation, je suis sûr que la qualité de l'image le permet.

Tu peux prendre des photos en mode preview mais toutes les opérations qui nécessitent une analyse astrométrique (PA, Goto, framing) ou un alignement comme le mode live ne peuvent en effet être tester qu'avec des étoiles.