Pixinsight 1.9.5, nouveautés et comparatif MLDenoise

[Tromat]

il y a 4 minutes, lock042 a dit :

Dans la clé a molette. Tu as une option dans calibration pour prendre nearest flat.

J'ai trouvé, à côté de la clé à molette, en cliquant sur le quartier de lune on peut attribuer flats et darks.

Par contre, il me dit : Siril error: Command 'calibrate' failed: Sequence not found

 

Je ne sais pas si je vais y arriver 😅

[Tromat]

 

Qu'est-ce que j'ai fait, encore ?

[lock042]

La comme ça je vois pas. J'ai peur qu'il aime pas les masters provenant d'autres logiciels. En tout cas j'ai jamais testé. Es tu sur qu'ils ont la même taille ? Tu peux vraiment pas utiliser les brutes ?

Si je comprends le problème je pourrais voir a corriger, mais là je sais pas. Je suis sur que c'est lié au masters fait par PI par contre.

[Tromat]

il y a 21 minutes, lock042 a dit :

Tu peux vraiment pas utiliser les brutes ?

Faudrait encore les avoir à disposition !

 

J'ai essayé sans dark, ni flat et ça ne marche pas non plus. Ca vient peut être de la conversion en fit depuis PI ? Tous mes fichiers sont en xisf.

[lock042]

Tu peux me faire une archive ? Je vais voir pour corriger 

[lock042]

Du coup, maintenant que ça marche, on attends le retour

[Tromat]

il y a 15 minutes, lock042 a dit :

Du coup, maintenant que ça marche, on attends le retour

Ah ah, oui il faut que je prenne le temps de faire ça. Par contre je vais surement avoir encore des questions. Genre quel est l'algo de stacking utilisé ? Je ne vois pas où on peut le sélectionner.

Modifié 30 septembre par Tromat

[lock042]

il y a 10 minutes, Tromat a dit :

Ah ah, oui il faut que je prenne le temps de faire ça. Par contre je vais surement avoir encore des questions. Genre quel est l'algo de stacking utilisé ? Je ne vois pas où on peut le sélectionner.

En fait j'ai fais le choix que le script choisisse automatiquement en fonction du nombre d'images.

[Tromat]

à l’instant, lock042 a dit :

En fait j'ai fais le choix que le script choisisse automatiquement en fonction du nombre d'images.

WBPP fait ça aussi par défaut, mais tu peux forcer à la main celui que tu souhaites utiliser. Avec 6 ou frames dans mon exemple c'est quoi qui est utilisé ? Du sigma-clipping ?

Pour ce qui est du calcul de distorsion il est fait sur une image générée depuis un catalogue c'est bien ça ? Dans PI c'est fait par rapport à l'image de référence.

 

Il faudrait que je sélectionne un stack de brutes un peu plus important pour faire un comparatif vitesse/qualité entre les deux. Après il est difficile de ne pas comparer des choux et des carottes, chaque solution propose des options différentes.

En tout cas, pour un premier test, avec 1mn02s contre 3mn42s pour la dernière build de Pixinsight, Siril est incontestablement plus rapide.

Mais là encore je compare des choux et des carottes, et il y a des modes beaucoup plus rapide. Là je viens de faire un 1mn49s lors d'un test en tweakant 2-3 trucs.

[lock042]

il y a 2 minutes, Tromat a dit :

WBPP fait ça aussi par défaut, mais tu peux forcer à la main celui que tu souhaites utiliser. Avec 6 ou frames dans mon exemple c'est quoi qui est utilisé ? Du sigma-clipping ?

Percentile clipping

 

il y a 2 minutes, Tromat a dit :

Pour ce qui est du calcul de distorsion il est fait sur une image générée depuis un catalogue c'est bien ça ? Dans PI c'est fait par rapport à l'image de référence.

Dans Siril, ça te prend l'image de référence. Ca fait le platesolve dessus et sort donc la position des étoiles vs la position exacte. Et ca calcule la distorsion. Cette distorsion est donc appliquée à toutes les images.

[nico1038]

Bonjour,

 

Même si je n'accorde pas une si grande importance que cela aux temps de traitement, voici une comparaison entre WBPP et AMSP sur le même jeu de données.

 

Description du PC sur lequel j'ai fait cette comparaison:

• CPU: AMD Ryzen 7 7700X (16) @ 5.58 GHz
• GPU: NVIDIA GeForce RTX 3080
• OS: Fedora Linux 44 (KDE Plasma Desktop Edition) x86_64
• Memoire: 32G

A noter que j'ai redémarré le PC avant chaque test pouer être bien sur que toute la mémoire était bien disponible.

 

Description du jeu de données:

Les images sont des images CFA issus d'une ASI2600MC (6248*4176)

• 125 lights
• 25 flats
• 1 masterdark (au format xisf pour pix et au format fit pour Siril)
• 1 masterbias (au format xisf pour pix et au format fit pour Siril)

 

Version des logiciels:

• PixInsight Core 1.9.5 Lockhart (x64) (build 1706 | 2026-09-27)
• Siril 1.4.4

 

Réglages effectués sur WBPP et AMSP pour essayer de les rendre comparable au mieux:

• Désactivation de la distortion sur AMSP
• Désactivation de LocalNormalization, AstrometricSolution et Autocrop dans WBPP

 

 

 

 

 

 

Résultats:

 

Temps total AMSP: 3min26s

Log AMSP (copie de la console de Siril): 

ASMP.log

 

 

Temps total WBPP: 4min19

 

Log WBPP:

20260930110926.log

 

N'hésitez pas à me dire si vous pensez que j'aurais du modifier un réglage sur Siril ou sur Pix. Je m'interroge par exemple sur le fait de désactiver le weighting dans WBPP?

 

Nico

 

 

Modifié 30 septembre par nico1038

[Tromat]

Merci pour le test !

 

il y a 57 minutes, nico1038 a dit :

Même si je n'accorde pas une si grande importance que cela aux temps de traitement

Non moi non plus, je préfère passer bien plus de temps si ça permet d'améliorer la qualité. Le prétraitement conditionne toute la suite des opérations donc c'est vraiment crucial.

Et ce qui m'interpelle quand je lis les commentaires des uns et des autres c'est le nombre de personnes qui utilisent et/ou recommande Siril pour le prétraitement alors qu'ils possèdent Pixinsight. Et quand tu demandes pourquoi, la question de la vitesse d'exécution revient systématiquement.

 

Donc pour aller plus loin, il faut maintenant comparer le résultat. J'ai commencé à faire ça mais c'est pas évident. J'essaie de comparer WBPP options au max, avec Siril au max également, et FBPP.

Ca prend du temps et il y a de nombreux biais à contourner. De ce que je vois malgré tout, ça confirme ce que je soupçonne depuis le début. Siril est effectivement plus rapide (malgré l'écart suite aux màj récentes de PI) mais c'est au détriment de la qualité du résultat final. 

[lock042]

il y a 36 minutes, Tromat a dit :

) mais c'est au détriment de la qualité du résultat final. 

Intéressant de savoir comment tu mesures cela par contre :).

[nico1038]

il y a une heure, Tromat a dit :

Merci pour le test !

 

Non moi non plus, je préfère passer bien plus de temps si ça permet d'améliorer la qualité. Le prétraitement conditionne toute la suite des opérations donc c'est vraiment crucial.

Et ce qui m'interpelle quand je lis les commentaires des uns et des autres c'est le nombre de personnes qui utilisent et/ou recommande Siril pour le prétraitement alors qu'ils possèdent Pixinsight. Et quand tu demandes pourquoi, la question de la vitesse d'exécution revient systématiquement.

 

Donc pour aller plus loin, il faut maintenant comparer le résultat. J'ai commencé à faire ça mais c'est pas évident. J'essaie de comparer WBPP options au max, avec Siril au max également, et FBPP.

Ca prend du temps et il y a de nombreux biais à contourner. De ce que je vois malgré tout, ça confirme ce que je soupçonne depuis le début. Siril est effectivement plus rapide (malgré l'écart suite aux màj récentes de PI) mais c'est au détriment de la qualité du résultat final. 

 

La qualité des deux images finales de ce test est finalement très similaire avec ces réglages. À noter que les deux outils ont choisi la même image (la 79) comme référence.

Je dirais que les différences sont essentiellement imputables à trois choses :

• Le rejet de certaines images par WBPP qui a supprimé automatiquement les 5 premières images du jeu de données (qui sont clairement très mauvaises)
• La pondération des images qui est faite par WBPP mais pas par AMSP ou elle est désactivée.
• et peut être l'algorithme d'alignement: Lancoz3 pour Pix contre Lancoz4 pour Siril (il me semble bien que je ne le vois pas dans la console). 

Voici les 2 fichiers finaux (je peux aussi partager le jeu de données complet si nécessaire).

https://kdrive.infomaniak.com/app/share/1883582/fa6e298e-f7a6-4907-9a82-c0edd90e3c3d

Modifié 30 septembre par nico1038

[Tromat]

il y a 59 minutes, lock042 a dit :

Intéressant de savoir comment tu mesures cela par contre

C'est en parti subjectif forcément, mais de ce que je vois, il y a la finesse des étoiles qui bouge un peu, la "texture" du bruit qui semble plus flou ou interpolé avec Siril (c'est difficile à décrire), le gradient qui est plus compliqué (LocalNormalization fait des merveilles de ce point de vue là), l'autocrop n'est pas optimal non plus avec Siril mais je n'ai étudié les autres fonctions. Par contre le fait de corriger la distorsion par astrométrie dès le prétraitement est intéressante, surtout pour la création de mosaïque, et je ne crois pas que PI le propose directement.

 

Après attention, c'est pas le jour et la nuit hein, mais quand on essaie d'optimiser au mieux ses précieuses données tous ces petits détails font malgré tout une différence.

[lock042]

il y a 32 minutes, Tromat a dit :

l'autocrop n'est pas optimal non plus avec Siril

y'en a pas. Tu peux définir ton type de cadrage dans les options par contre.

 

il y a 34 minutes, Tromat a dit :

le gradient qui est plus compliqué

Quand le gradient est compliqué il faut coché le retrait de gradient de level 1 a chaque image. C'est forcément plus long car ca fait une passe de plus sur tout le set, mais le gradient est plus simple après.

[Tromat]

il y a 10 minutes, lock042 a dit :

y'en a pas. Tu peux définir ton type de cadrage dans les options par contre.

C'est de ça dont tu parles, c'es pas un genre d'autocrop ?

 

 

 

il y a 12 minutes, lock042 a dit :

Quand le gradient est compliqué il faut coché le retrait de gradient de level 1 a chaque image.

C'est cette option là ? Elle est cochée dans mes tests.

 

 

[lock042]

il y a une heure, Tromat a dit :

de ça dont tu parles, c'es pas un genre d'autocrop

J'appellerai pas ça comme ça. Mais du coup tu peux choisir ta préférence.

[Tromat]

Il y a 3 heures, Tromat a dit :

 

Après attention, c'est pas le jour et la nuit hein, mais quand on essaie d'optimiser au mieux ses précieuses données tous ces petits détails font malgré tout une différence.

Bon alors, mea culpa, après avoir corrigé une petite erreur de ma part le résultat est finalement vraiment similaire. Il est toujours difficile d'obtenir deux vues vraiment identiques au pixel près sans affecter l'un ou l'autre des logiciels dont j'ai fait au mieux avec un gros crop.

Il y a quelques différences de signal mais je pense que c'est dû au paramètres de rejet différents et que je n'ai pas chercher à affiner. Dans les deux cas c'est du drizzle 1x. 

 

La seul différence que je vois c'est cette texture de bruit beaucoup plus nette avec PI. Ma première conclusion, les deux se valent ! Je vous laisse juger :

 

Pixinsight :

 

Siril :

 

[Tromat]

Erratum : je viens de comprendre l'origine de cette différence de texture. Je me suis rappelé que tu m'as dis que les vues étaient réalignées après le stacking, il y a donc une interpolation à ce moment qui vient dégrader le bruit.

Je suis reparti des vues L cette fois, en prenant la version non alignée pour comparer et là il n'y a pour ainsi dire aucune différence entre les deux logiciels. A part que ça sort plus vite de Siril !

Le souci d'alignement sera corrigé avec la prochaine version si j'ai bien compris.

 

Pixinsight :

 

Siril :

[lionthom]

Queee—wouah ! On a donc raison, tous autant qu’on est, de pré traiter sur Siril ! 😂
Et là, on peut remercier @Tromat qui nous a fait un test sérieux, pas du Raoult…😀

[Tromat]

il y a 25 minutes, lionthom a dit :

On a donc raison, tous autant qu’on est, de pré traiter sur Siril !

Plus forcément en fait, avec le gain de rapidité opéré par PI il n'y a plus une différence aussi énorme. On est passé de 5 à 10x plus rapide, à seulement quelques dizaines de pourcent. C'est encore beaucoup pour des gros sets d'image mais plus aussi spectaculaire.

Enfin ceci dit vous ne m'avez pas attendu pour faire ce que vous voulez hein  

 

Une autre question que je me pose c'est : est-ce que les GPU ont leur mot à dire dans cette histoire ? Il y a une partie du boulot qui est faite avec dans Siril (pas bien compris quoi) et dans PI il y avait un utilisateur qui avait conçu un script pour PI qui démultipliait les performances. C'est, je crois, ce qui a fait péter les plombs à Juan d'ailleurs, et a mené à la fermeture du forum officiel. Avec leur premier pied dans le monde de l'utilisation du GPU est-ce que le prétraitement va en profiter ? Je ne sais pas. Déléguer le boulot au GPU ne présente pas toujours d'intérêt selon la tâche mais ça dépasse très nettement mes connaissances en la matière.

[lock042]

il y a 4 minutes, Tromat a dit :

est-ce que le prétraitement va en profiter ?

Ca m'étonnerait. Le goulot d'étrangement ici c'est les lectures/écritures des fichiers. Et ça... On peut rien faire avec le GPU.

 

il y a 5 minutes, Tromat a dit :

PI il y avait un utilisateur qui avait conçu un script pour PI qui démultipliait les performances. C'est, je crois, ce qui a fait péter les plombs à Juan d'ailleurs, et a mené à la fermeture du forum officiel.

Il faut utiliser Siril, les dev sont moins ... caractériels ?

 

il y a 52 minutes, Tromat a dit :

Le souci d'alignement sera corrigé avec la prochaine version si j'ai bien compris.

Je confirme.

[Tromat]

il y a 21 minutes, lock042 a dit :

Il faut utiliser Siril, les dev sont moins ... caractériels ?

Certes. Et très enclins à aider leur prochain. Merci !

 

Après, l'innovation est souvent venue du côté de Pixinsight, directement ou non, et l'interface est vraiment géniale. Je pensais à un truc, avec la 1.9.5 on se rapproche de la 2.0, qu'est-ce qu'il se passe ce jour là ?

[lock042]

il y a 5 minutes, Tromat a dit :

Après, l'innovation est souvent venue du côté de Pixinsight,

Il me semble que la "stretch war" a commencé après la sortie des scripts Veralux sous Siril

[Tromat]

il y a 1 minute, lock042 a dit :

Il me semble que la "stretch war" a commencé après la sortie des scripts Veralux sous Siril

D'où le "souvent", auparavant j'aurais dis "toujours". Dans tous les cas c'est bien, ça stimule la concurrence et ça les force à se sortir les doigts du cul.

 

La "stretch war"... 🤣 Le terme est bien trouvé, c'est vraiment ce qu'il s'est passé ! Il est réjouissant de se dire qu'on peut encore innover en terme de traitement d'image 2D.

[krotdebouk]

il y a 40 minutes, Tromat a dit :

Je pensais à un truc, avec la 1.9.5 on se rapproche de la 2.0, qu'est-ce qu'il se passe ce jour là ?

C'est très simple et Juan y avait pensé avant Russel et son évolution en ML5 ($auf qu€ le gar$ ruru a été bi€n plus rapid€ à compr€ndr€ qu€ Juan..).
C'est dans la FAQ du site de Pix :

https://pixinsight.com/faq/index.html

Modifié 30 septembre par krotdebouk

[lock042]

Pour la version 2 de siril on la fera au même prix que la version actuelle.

Promis.

[lock042]

En tout cas, je suis content de ce test. Déjà, on ne peut pas dire que @Tromat avait un avis biaisé en faveur de Siril.

Ce que cela montre ici, c’est que gratuit et libre ne veut pas forcément dire qualité moindre.

 

L’argument que j’entends maintenant, c’est : « Pour le traitement, PixInsight est mieux. » Franchement, avec tous les nouveaux scripts, je pense qu’on peut aujourd’hui tout faire avec Siril.

 

Et pour les masques ? Ils sont déjà développés dans la version de développement (que j’utilise au quotidien).

[krotdebouk]

Il y a 1 heure, lock042 a dit :

Et pour les masques ? Ils sont déjà développés dans la version de développement (que j’utilise au quotidien)

Bonne nouvelle ça, masques de luminosité et masques de couleurs ?