Des amas ouverts, un serpent et plein d'étoiles : NGC654 et alentours [SW Esprit 80/400 + Poseidon-C (IMX571)]

[krotdebouk]

Bonjour à tous !

NGC654 est l'amas ouvert qui se trouve à côté du "dark serpent" vers le centre de cette image. Elle a été faite cette nuit en 540 x 60" (9h) avec la Lune à 82%, une caméra IMX571-C et un "simple" filtre IR/UV Cut sur une SW Esprit 80/400.

J'ai tout donné au process WBPP de Pixinsight qui s'est débrouillé comme un grand en 5h29 seulement.. Heureusement que mon PC pédale et est bien refroidi ! La suite avec Pix toujours et un peu d'Affinity Photo 2 pour terminer.

 

Si vous avez un BF ou un tilt à régler, je vous conseille cette cible

[shibon]

Y a un sacré paquet d'étoiles !! C'est beau.

Si tu as utilisé le retrait de gradient RBF de Siril, tu as laissé QQ points sur des étoiles (en même temps vu le nombre...) et ça donne des zones sombres comme autour de cet amas:

[Pascal76]

Le champ est magnifique,  et il est beau le petit amas de vieilles étoiles (jaunes) au centre gauche. Il forme un triangle isocèle avec les deux autres amas, vraiment belle image 👍👍

[180Vision]

26 minutes ago, shibon said:

Y a un sacré paquet d'étoiles !! C'est beau.

Si tu as utilisé le retrait de gradient RBF de Siril, tu as laissé QQ points sur des étoiles (en même temps vu le nombre...) et ça donne des zones sombres comme autour de cet amas:

 

Belle image JM !

 

Alors le pb que décrit/relève Sam, je l'ai souvent eu en L/RGB...

Il faudrait que je regarde pour vérifier que ma méthode d'aujourd'hui a éliminer ça mais je ne pense pas que cela vienne du retrait de gradient (je peux me tromper)...

 

Ce qui est certain c'est que maintenant je "force" moins sur BlurX ET surtout sur NoiseX...en lien peut être avec le moment du StarX peut être en sus...

PAr ailleurs, je mets un coup de ACDNR avec préfilter sur la pure RGB + Convolution.

bref pas très précis, mais me suis fait la remarque.

 

J'ai l'impression qu'il s'agit plutôt de quelque chose de cet ordre, mais il faudrait que je revalide...

 

J'ajoute l'objet à la liste, même si j'ai un champ bien plus petit, c'est très chouette.

Modifié 26 septembre 2023 par 180Vision

[T350]

Très jolis ces amas,

et de bien belles couleurs!

 

bravo

 

a+

 

Serge

[krotdebouk]

Merci pour vos remarques et appréciations sympatoches !

 

@Pascal76 @C14edgeHD : pareil, j'aime beaucoup ce grand champ. J'avais saturé les étoiles un peu fort, c'est tentant..

 

il y a 23 minutes, shibon a dit :

Si tu as utilisé le retrait de gradient RBF de Siril, tu as laissé QQ points sur des étoiles (en même temps vu le nombre...) et ça donne des zones sombres comme autour de cet amas

 

il y a 17 minutes, 180Vision a dit :

Ce qui est certain c'est que maintenant je "force" moins sur BlurX ET surtout sur NoiseX...en lien peut être avec le moment du StarX peut être en sus...

 

J'ai utilisé GraXpert, le même algo que sous Siril il me semble, je n'avais pas de bons résultats avec Pix (la Lune..).

Le retrait de gradient n'est pas l'étape que je maitrise le mieux (parmi d'autres étapes d'ailleurs..). Sur ce coup là j'ai utilisé Kriging juste parce que c'était celui qui y était. Je vais refaire des tests des 3 méthodes dispos. Sur ce genre d'image, j'ai recouvert la totalité avec les petits carrés, il y a peut être boulette là aussi ?

 

Pour les zones sombres je vais être plus attentif sur ma v2. Il y a effectivement la piste de Julien avec BXT et NXT mais également celle du script DarkStructureEnhance qui pourrait bien y être pour quelque chose. Je l'ai passé 2 ou 3 fois pour accentuer le serpent..

 

Bref, je prends note de tout ça, je mets à jour Pix et j'y vais plus calmement. Merci encore pour vos remarques 

[180Vision]

13 minutes ago, krotdebouk said:

Merci pour vos remarques et appréciations sympatoches !

 

@Pascal76 @C14edgeHD : pareil, j'aime beaucoup ce grand champ. J'avais saturé les étoiles un peu fort, c'est tentant..

 

 

 

J'ai utilisé GraXpert, le même algo que sous Siril il me semble, je n'avais pas de bons résultats avec Pix (la Lune..).

Le retrait de gradient n'est pas l'étape que je maitrise le mieux (parmi d'autres étapes d'ailleurs..). Sur ce coup là j'ai utilisé Kriging juste parce que c'était celui qui y était. Je vais refaire des tests des 3 méthodes dispos. Sur ce genre d'image, j'ai recouvert la totalité avec les petits carrés, il y a peut être boulette là aussi ?

 

Pour les zones sombres je vais être plus attentif sur ma v2. Il y a effectivement la piste de Julien avec BXT et NXT mais également celle du script DarkStructureEnhance qui pourrait bien y être pour quelque chose. Je l'ai passé 2 ou 3 fois pour accentuer le serpent..

 

Bref, je prends note de tout ça, je mets à jour Pix et j'y vais plus calmement. Merci encore pour vos remarques 

D'ailleurs, en évoquant "DarkStructure", j'ai utilisé aussi parfois le HDR transform ou  le Localhisto...et me suis aperçu avec le temps que ça peut être vite destructeur et créer des zones bizarres...

J'avais prévu de mon coté retraiter une ou deux images RGB avec mes connaissances d'aujourd'hui, pour voir si en effet il y a un des processus qui peuvent engendrer ce genre de curiosité...

 

Après JM, il faut cliquer sur la pleine résolution et le relever, c'est pas non plus rédhibitoire mais autant en effet essayer de trouver ces effets non désirés c'est sûr...

En tout cas, tes images "SHO" issues de ta cam couleur + filtre duo/tri, je n'ai pas souvenir d'avoir noté ça justement....

 

Et chez moi, idem, j'ai pas eu récemment cet effet sur toutes les H/S/O ou  même lRGB avec luminance issue de Ha...

Coïncidence ou pas...

[tazdevil71]

Un bien joli champ. Je suis sur smartphone donc le souci de zones sombres ne m’a pas sauté aux yeux, d’autant qu’il y’a pas mal d’autres nébuleuses obscures tout autour.

pour le peu d’expérience que j’ai sur ces cibles, le traitement starless s’est montré très efficace pour booster les nébuleuses obscures à coup de curve par itération 

[krotdebouk]

il y a 2 minutes, tazdevil71 a dit :

le traitement starless s’est montré très efficace pour booster les nébuleuses obscures à coup de curve par itération

Tu fais bien de me le signaler : par itération et non pas en un coup comme certain le fait..

[sebseacteam]

La vache 5h40 pour 500 images à traiter...

Il fait quoi exactement ce process WBPP?

Il pré-traite les light par les DOF et quoi en plus ? 🤔

[krotdebouk]

il y a 10 minutes, sebseacteam a dit :

La vache 5h40 pour 500 images à traiter...

Il fait quoi exactement ce process WBPP?

Il pré-traite les light par les DOF et quoi en plus ? 🤔

C'est l'étape local normalisation qui prend le plus de temps. Ca permet de traiter unitairement les gradients si j'ai bien compris (1h39).

Puis il y a l'intégration en drizzle 2 qui prend aussi du temps, ça c'est pas une obligation (1h06).

Et mon fixe est récent basé sur un AMD Ryzen 9 5950X 16-Core Processor + 64 Go de RAM. Mon portable aurait pris feu si je lui avait fait ça..! Je vais voir si je peux pas ajouter un refroidissement à l'azote liquide

 

[sebseacteam]

Mouais ok.

Et y a pas moyen de faire ça avec Sirilic? Ha ben si tiens.. tiens.... je serai curieux de voir la différence de temps et si ça se voit sur l'image sortie d'empilement...

Déjà utilisé Sirilic de ton côté ?

Test à faire si envie un jour pluvieux par exemple...

[krotdebouk]

il y a 6 minutes, sebseacteam a dit :

Déjà utilisé Sirilic de ton côté ?

Oui et même récemment sur mon image du coeur (94 brutes) mais ça ne m'a pas convaincu, le gradient du stack était compliqué. Il est aussi fort possible que je m'y prenne mal.. En comparaison, ça avait pris une vingtaine de minutes avec Sirilic contre 54 minutes pour Pix/WBPP. Par contre là c'est 540 brutes de 50 Mo avant débayer, ça m'a donné plus de 500 Go de fichiers intermédiaires à la fin du prétraitement !

[sebseacteam]

Oui je comprends, je ne peux pas comparer avec ma 294c.

ça devient fou la place nécessaire à avoir.

Un peu comme avec les jeux de la PS5....mais ça c'est quand il pleut  

[krotdebouk]

il y a 1 minute, sebseacteam a dit :

ça devient fou la place nécessaire à avoir.

Et pas que.. Il y a un post en face sur les disques SSD qui ne sont pas éternels à force d'écrire dessus. Je traite sur le disque M.2 de mon fixe (1To), disque qui contient Windows. Je serai très déçu si il devait claquer prématurément rien que par le traitement astro. J'ai un SSD rapide pour l'acquisition solaire/lunaire et je peux même traiter directement dessus sans ralentissement notable. Je pense m'en prendre un autre rien que pour le traitement des images CP.

[Celebrinnar]

Un champ superbe !!

Bravo !!

il y a 1 minute, krotdebouk a dit :

Je pense m'en prendre un autre rien que pour le traitement des images CP.

j'ai exactement la même chose en prévision

[krotdebouk]

@Celebrinnar Merci !

J'ai ce SSD pour le lunaire/solaire, il dépote.

[M16]

D'habitude j'ai vraiment du mal avec les amas......

Là champ est vraiment top et super couleurs, il y a plein de choses a regarder !

 

Il y a 10 heures, krotdebouk a dit :

J'ai ce SSD pour le lunaire/solaire, il dépote.

 

Merci pour l'astuce : un SSD pour gagner du temps sur le traitement.

Si je pige bien stockage sur un  DD externe ou sur le DD de ton PC et quand tu veux traiter tu balances tout sur le SSD pour que pix puisse depoter ?

[krotdebouk]

il y a 2 minutes, M16 a dit :

Merci pour l'astuce : un SSD pour gagner du temps sur le traitement.

Si je pige bien stockage sur un  DD externe ou sur le DD de ton PC et quand tu veux traiter tu balances tout sur le SSD pour que pix puisse depoter ?

C'est ça, c'est ce que je fais déjà en lunaire/solaire et je vois que ça devient pareil pour le CP avec les images de plus en plus lourdes. Je pense même capturer directement dessus pour le CP.

Mais c'est surtout pour préserver le SSD de mon fixe qui contient Windows, j'ai failli le saturer sur cette image avec les 500 Go de fichiers intermédiaires. En plus de s'user avec les écritures/effacements, les SSD n'aiment pas être saturés. 

Il a bien baissé ce SSD Samsung, je l'avais payé 122.94€ en janvier.

Le post en face : http://www.astrosurf.com/topic/164231-hdd-vs-ssd-pour-traitement-via-autostakkert-ou-astrosurface/

[cezanne]

Joli champ et beaucoup de choses à voir 👍

[T350]

Il y a 15 heures, krotdebouk a dit :

C'est l'étape local normalisation qui prend le plus de temps. Ca permet de traiter unitairement les gradients si j'ai bien compris (1h39).

Puis il y a l'intégration en drizzle 2 qui prend aussi du temps, ça c'est pas une obligation (1h06).

Et mon fixe est récent basé sur un AMD Ryzen 9 5950X 16-Core Processor + 64 Go de RAM. Mon portable aurait pris feu si je lui avait fait ça..! Je vais voir si je peux pas ajouter un refroidissement à l'azote liquide

 

Oui mais là, il a une bête de course comme PC Krot.

Moi, avec une machine gamer qui a 3 ans et Cuda etc, j'y passerais 10 Heures.

 

a+

 

Serge

[krotdebouk]

il y a 4 minutes, C14edgeHD a dit :

Moi, avec une machine gamer qui a 3 ans et Cuda etc, j'y passerais 10 Heures.

Et peut être même plus, Cuda n'intervient pas dans cette partie. J'ai un portable de gamer de 5 ans, un Asus ROG, il m'a supplié d'arrêter.. Ca c'est le mauvais côté de Pix.

Pour ce genre de manip, je vais le laisser bosser la nuit.