Aller au contenu

nico1038

Membre
  • Compteur de contenus

    2285
  • Inscription

  • Jours gagnés

    44

Tout ce qui a été posté par nico1038

  1. Hello Fred, Il n'est pas nécessaire d'aligner les courbes. SPCC est la seule opération nécessaire pour calibrer les couleurs d'une image RGB et il ne faut plus ensuite effectuer d'opérations qui peuvent modifier cet équilibre. En temps normal il ne devrait pas être nécessaire d'utiliser SCNR par exemple. Le problème dans ton cas c'est que tu as peu d'image couleurs par rapport à la luminance et cela peut rendre la calibration plus aléatoire et, peut être, justifier d' intervenir ultérieurement (probablement après l'étirement) pour "corriger" les couleurs. Par rapport à ton Worflow, j'éviterais aussi de faire une correction du gradient sur les couches individuelles. Les outils de corrections du gradient sont bien plus efficace quand on les appliques directement sur l'image couleur. La constellation de Céphée fait partie de la couverture actuelle de la base MARS et donc tu peux utiliser le process MultiscaleGradientCorrection pour corriger les gradients de ton image. C'est sans doute l'outil à privilégier.
  2. Hello @Hubus Pour une image broadband, le workflow habituelle est de calibrer les couleurs en phase linéaire avant l'étirement (c'est indispensable sur tu fais une calibration par photométrie). L'étirement, quel que soit l'outil utilisé (et si il est effectué en mode RGB sur les 3 canaux), ne doit pas modifier cette calibration. Je ne sais pas ce que tu reproches à l'histogramme que tu nous montres mais je n'y vois rien d'anormal: les pics des 3 courbes sont à peu près alignés et, comme sur cette image le fond de ciel à l'air prépondérant par rapport à la nébuleuse, cela signifie que le fond de ciel est neutre. D'une manière général je trouve qu'on ne peut pas trop se fier à l'histogramme d'une image pour juger si les couleurs sont correctes: si toute l'image est constituée d'une nébuleuse en émission, il est alors normale de voir des courbes très différentes entre les canaux. Bref, au moins dans une utilisation classique, GHS n'est pas en charge de l'équilibrage des couleurs.
  3. Bonjour Cyril, Je la trouve très belle. Bravo.
  4. Tes résultats ne m'étonnes pas du tout: ce dernier test tout comme les essais avec les différents algorithmes confirment que c'est bien un problème de rejet des pixels déviants lié à un changement de méridien. Une asymétrie se produit sur les étoiles brillantes lors de la bascule du télescope et, lors de l'empilement et en fonction du nombre d'images prises d'un coté et de l'autre du méridien certains pixels sont donc considérés comme déviants et sont alors rejetés. Les algorithmes de rejet ont tous des caractéristiques différentes (que je ne connais pas en détail) mais ils sont tous basés sur une approche statistique. Il est facile de rejeter sans conséquence des pixels déviants quand ils sont clairement identifiés et qu'ils ne représentent qu'une fraction de la pile mais, ici, c'est plus compliqué car les pixels considérés comme déviants représentent sans doute une part significative de la pile et qu'ils sont donc à la fois plus dur à identifier et que leurs rejet n'est pas sans conséquence (car ils restent alors moins de pixels à empiler). C'est cela qui provoque ces artefacts. J'ai quelques questions: Combien d'images as tu fait d'un coté et de l'autre du méridien dans ce cas particulier? Les images empilés que tu montres (partie 1 et partie2) sont elles alignées entre elles? Il me semble que non mais ça serait intéressant de voir ces mêmes images de cette étoile alignées pour bien constater l’asymétrie. En tous cas, je pense que la meilleure façon de corriger le problème reste de modifier les paramètres des algorithmes de rejet. En me basant sur tes tests j’essaierai avec l'algorithme Linear fit clipping et en augmentant le paramètre "Linéaire haut" Une autre idée serait d'essayer l’algorithme Median Sigma Clipping qui, plutôt que de rejeter les pixels déviants les remplace par la valeur moyenne de la pile. Je pense que ça devrait corriger ce genre d'artefacts mais je ne suis pas exactement sûr des conséquences que ça peut avoir par ailleurs... Pour simplifier et accélérer les tests une idée serait d'essayer de reproduire le problème avec un échantillon limité d'images, en conservant la proportion des images d'un coté et de l'autre du méridien. Nico
  5. nico1038

    m51 en luminance

    Pas d'inquiétude: la dominante rouge est normal. Pour pouvoir visualiser l'image correctement il faut délier les canaux Canaux liés: Canaux déliés: Le fait qu'il y ait un déséquilibre à ce stade est parfaitement normal. Il sera corrigé lors de la calibration des couleurs Perso je trouve tes images pas mal du tout. C'est plus au niveau de la calibration et du traitement qu'il faut que tu trouves les bonnes formules.
  6. nico1038

    m51 en luminance

    Le problème est que j'effectue toutes ces opérations dans Pix en général donc je ne sais pas exactement comment les mettres en pratique de la meilleur façon avec Siril. Pour le crop tu peux passer par la ligne de commande avec la commande crop. Par exemple Crop 314 123 2574 2821 les deux premiers chiffres sont les positions x et y du point de départ du crop et les 2 suivants la largeur et la hauteur du crop. De cette manière tu peux reproduire la commande facilement sur toutes les images. Une autre possibilité qui doit marcher aussi est de ne pas croper avant la composition RVB. Çà doit marcher aussi et il faudra juste cropper sur l'image couleur. C'est peut être plus simple finalement.
  7. nico1038

    m51 en luminance

    Je ne suis pas le mieux à même pour répondre à cette question car je n'ai jamais fait cette opération avec Siril mais juste avec Pixinsight. Mais je crois que la commande rgbcomp permet de composer la luminance avec l'image couleur avec la syntaxe suivante: rgbcomp -lum=luminance_image rgb_image
  8. Formidable compte rendu. Merci: j'ai eu l'impression d'y être!
  9. nico1038

    m51 en luminance

    En effet, les images sont cette fois correctement identifiées mais il me semble que ton process n'est pas correct. La combinaison des images RVB doit se faire avec des images linéaires, c'est impératif (la calibration des couleurs par photométrie ou la déconvolution n'ont pas de sens sur des images déjà étirées. Avec ces 4 images voilà un workflow possible: 1) Alignement des images R,V et B sur la luminance 2) Crop des 4 images pour enlever les bandes noires (il y a un changement de cadrage significatif entre la luminances et les couches RVB) 3) Combinaison des images RVB pour créer l'image couleur A ce stade, avant même la calibration des couleurs ou toute autre forme de traitement on a une image couleur raisonnable: Il faut ensuite traiter cette image (Correction du gradient, calibration des couleurs, déconvolution,...) puis l'étirer et traiter et étirer la luminance en parallèle. La composition de la luminance avec la couleur se fait, enfin, avec ces 2 images non linéaires.
  10. Il faut essayer en tous cas. Et sans même parler de savoir si ça résout bien ton problème d'artefacts, je serais curieux de savoir la différence de temps que ça engendre.
  11. Je vois. Dans Pix l'algorithme était utilisé par défaut dès 15 images dans les versions précédentes. Au contraire, dans la version 1.9 cet algorithme n'est plus utilisé par défaut du fait du temps de calcul qu'il implique. En tous cas, à mon avis, ce n'est pas l’algorithme à conseiller pour les gros jeux de données (>100)
  12. Où as tu vu ce conseil? Ça me semble étrange car GESD fonctionne parfaitement avec une vingtaine d'images par exemple.
  13. Student (GESD) est surement l'algorithme le plus efficace mais c'est aussi le plus lourd. Du coup, je ne crois pas que la logique grand nombre d'images = student soit toujours valable. On peut considérer que la rejection est facilité avec un grand nombre d'image et il me semble qu'il faut donc alors mieux favoriser des algorithmes plus rapides.
  14. Mon hypothèse c'est que tu as un défaut dans la psf de tes étoiles et que ce défaut est modifié lors du changement de méridien. Lors de l'empilement, l’algorithme de rejet va tenter de rejeter les pixels considérés comme déviant mais, en fonction notamment du nombre d'images prises d'un coté et de l'autre du méridien cela peut donne ce genre d'artefacts. Je te conseille d'essayer de changer l'algorithme de rejet (notamment GESD et Linear Fit Clipping) et de relancer un empilement voir si ça change le résultat. Le clamping est un paramètre d'alignement (accessible dans l'onglet alignement et nommé "interpolation contrainte" en français). C'est vrai que l'alignement est aussi une possibilité, il faudrait voir sur les images alignées si tu vois une trace de l'artefact en question.
  15. Hello Sam, Pour les étoiles c'est clairement un problème de rejet: Quel algorithme de rejet utilises tu (et avec quels paramètres)? Combien d'images as tu empilé? As tu fais un changement de méridien durant les acquisitions?
  16. nico1038

    m51 en luminance

    J'ai utilisé Pix pour le traitement. Il n'y a rien de très particulier à faire pour composer une image rvb. Les images linéaires RVB doivent être composées directement en sortie d'empilement (outil composition RVB dans Siril ou ChannelCombination dans Pix). L'image composée avec un auto ajustement et les canaux déliés doit alors déjà afficher des couleurs raisonnables (une nébuleuse en émission doit être rouge, les galaxies doivent être plutôt blanches, les étoiles du jaune au bleu,...) Ça n'a pas l'air d'être le cas pour cette image. Du coup j'ai quand même un doute sur tes fichier. Pourrais tu les partager?
  17. Bravo Romain, superbe image!
  18. Hello @Glloq Pour ton problème, rien de plus simple à mon avis: tu fais un goto Home et, une fois la monture positionnée tu desserres les freins et la repositionne dans la position correcte. Pas besoin de réinstaller l'Asiair! Il n'est pas essentiel que la position Home soit parfaite (car comme l'Asiair fonctionne par astrométrie, toute erreur lors d'un goto sera corrigée) mais il est important que la monture soit à peu près correctement positionnée pour éviter toute surprise lors du premier goto avec un risque de heurter le trépied par exemple.
  19. Bonjour à tous, Voici 2 nouvelles constellations: Le grand Chien au Canon 6D + Tamron SP 85mm ouvert à f/3.5. 91x60s: La très faible hauteur de cette constellation a compliqué l'acquisition et le traitement mais je voulais absolument la tenter car c'est une constellation emblématique qui contient l'étoile la plus brillante de note ciel: Sirius. On peut également noter M41: l'amas ouvert du grand chien au coeur de la constellation ainsi que plusieurs autres amas clairement identifiables. Le Lynx au Canon 6D + Sigma Art 50mm ouvert à f/4 90x60s: Le Lynx est une constellation mineure située entre la grande Ourse, le Cancer et les Gémeaux. Il n'y a aucun objet remarquable sur ce champ et même quasiment aucune galaxie clairement identifiable à part NGC2403 dans le coin inférieure gauche. Voici les images sans les lignes des astérismes: Nico
  20. La fonction "synchronise" est accessible via le menu Image ou par un clic droit sur une vue. Il y a 2 types de synchro: la synchro simple, par pixels. Dans ce cas tout déplacement ou zoom sera reproduit sur les images synchronisées. La synchro par astrométrie (dans ce cas toutes les images doivent être résolues astrométriquement). Cette dernière fonction est particulièrement utile pour comparer 2 images (ou plus) entre elles. Si tu zoom sur un détail d'une image, les images synchronisées vont zoomer automatiquement sur le même détail. C'est aussi avec cette fonction que le cadre représentant le champ d'une image apparait sur les autres images synchronisées.
  21. Bravo Pascal, elle est vraiment très belle!
  22. Merci 👍 J'ai regardé ton image et c'est vrai qu'elle est pas très bien orientée pour pouvoir continuer la mosaique. Ça se visualise très bien avec la nouvelle fonction "Synchronize" de Pix. Le cadre rouge est ton image:
  23. Bonjour à tous, J'ai pu profiter du beau temps de ces derniers jours pour ressortir mon newton et compléter une image de 2023 sur laquelle j'avais shooté le duo M95/M96. J'ai donc ajouté le trio voisin M105/NGC3371/NGC3373 en faisant une mosaique de 2 panneaux. Les images sont donc prises avec mon newton 200/900 et ma caméra ASI2600MC. Le traitement est réalisé intégralement sur Pixinsight. Il y a 212x120s pour le premier panneau (M95/M96) et 180x120s pour le second. Nico
  24. Voici le fichier fusion: Support Sigma 50mm v13.f3d Dis moi si ça marche. Attention, je suis un autodidacte sur fusion et je ne fais surement pas les choses dans les règles de l'art (par exemple je désactive l'historique de conception). Je crois qu'un utilisateur chevronné s'arracherait les cheveux sur ce fichier! Le support est attaché sur la queue d'aronde Vixen grâce à un écrou M6 qui vient s'enfoncer dans la partie basse du support. La charnière est un simple boulon en M5. J'ai améliorer la charnière sur les modèles que j'utilise sur mon Tamron 85mm et sur le Samyang 135 mais celle là fonctionne bien quand même. Nico
  25. Hello, Je crois que ça n'existe pas. Du coup je me suis imprimé un support: Si jamais tu es intéressé par les fichiers, dis le moi et je les posterai ici. Nico
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.