Pixinsight 1.9.5, nouveautés et comparatif MLDenoise

[Tromat]

Le 01/10/2026 à 09:31, lock042 a dit :

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

Je n'ai absolument rien contre le libre, je suis un grand fan de N.I.N.A. par exemple. Il y a des solutions payantes en face mais rien qui ne justifie la bascule à mes yeux.

 

Le 01/10/2026 à 09:31, lock042 a dit :

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.

Mouais. Il y a quand même le problème de l'interface et des masques. Avec Pixinsight je peux ouvrir plein de fichiers à la fois, générer des masques facilement, et comparer des images facilement. Il y a pléthores d'outils, soit en natif, soit via des scripts, c'est vraiment un couteau suisse. Avec Siril j'ai l'impression que c'est plus compliqué, et même si l'interface est mieux c'est quand même encore particulier. Rien que l'histoire des dossiers de travail c'est d'un chiant. 

Après ça ne demande qu'à évoluer

 

[nico1038]

Le 01/10/2026 à 09:31, lock042 a dit :

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.

 

C'est sûr que Siril a beaucoup évolué ces derniers temps et a rattrapé une bonne partie de son retard en matière de prétraitement, notamment avec la prise en compte de la distorsion et du drizzle. Les deux logiciels sont désormais assez proches en termes d'algorithmes disponibles et, plus généralement, dans leur approche du workflow de prétraitement.

 

Si on exclue le coté performance/ temps de calcul qui est le plus facile à comparer il reste quand même selon moi deux grandes différences:

 

D'abord la pondération qui est au cœur du script WBPP (le fameux weighting) et pour laquelle Pix a des algorithmes  évolués (je ne dis pas efficace...) pour estimer la qualité d'une image (et donc son poids dans l'empilement final). Siril dispose aussi d'un système de pondération, mais j'ai l'impression que celui-ci est à la fois plus simple et moins central dans les workflows généralement proposés. Par exemple, si je ne me trompe pas, on ne peut pas activer la pondération dans AMSP.

 

Ce n'est  pas une comparaison facile à réaliser, car il faut bien maîtriser les deux logiciels et effectuer des tests sur différents types de données. Mais j'aimerais vraiment voir des comparaisons sérieuses sur ce point.

Dans les exemples que j'ai partagé plus haut, je constate quand même une différence entre le stack WBPP et le stack AMSP. Mon hypothèse est que c'est du avant tout à la pondération mais il faudrait pouvoir isoler ce paramètre et le tester sur plusieurs séries d'images...

 

L'autre point qui mériterait aussi d'être étudié sérieusement est l'utilisation du process LocalNormalization dans le workflow de Pix. Ce process consiste à appliquer une normalisation local (par zones dans l'image) par rapport à une image de référence. L'idée étant d'harmoniser les gradients en se basant sur la meilleure image avec au final un gradient dans le stack qui sera plus simple a traiter.

Il n'y a pas d'équivalent direct de ce process dans Siril  où  l'approche qui est suggérée est plutôt de traiter le gradient sur chaque image avant de les empiler avec les outils de traitement de gradient traditionnel.

Là aussi j'aimerais bien voir des exemple concrets qui permettrait de  voir les mérites de l'une ou l'autre approche 

 

Nico

[Tromat]

il y a une heure, nico1038 a dit :

Ce n'est  pas une comparaison facile à réaliser, car il faut bien maîtriser les deux logiciels et effectuer des tests sur différents types de données. Mais j'aimerais vraiment voir des comparaisons sérieuses sur ce point.

Effectivement ma comparaison ne porte que sur une seul image, ça peut ne pas être aussi vrai sur d'autres séries.

 

il y a une heure, nico1038 a dit :

L'autre point qui mériterait aussi d'être étudié sérieusement est l'utilisation du process LocalNormalization dans le workflow de Pix. Ce process consiste à appliquer une normalisation local (par zones dans l'image) par rapport à une image de référence. L'idée étant d'harmoniser les gradients en se basant sur la meilleure image avec au final un gradient dans le stack qui sera plus simple a traiter.

De ce que j'ai vu le gradient est beaucoup moins prononcé avec WBPP mais dans mon exemple se corrige aussi bien dans les deux cas. Après pour ce qui est de l'influence sur la qualité de l'empilement il faudrait faire des tests approfondis. En terme de durée de traitement c'est presque gratos dans la version à jour, 10s pour générer l'image de référence et 1s  de calibration par brute avec mes fichiers et ma config.

Sur des images prises avec un bon ciel le gain est sans doute marginal, mais dès que les gradients complexes entre en jeu c'est une autre histoire (lune, pollution, cime des arbres, etc...)

[lock042]

Il y a 3 heures, Tromat a dit :

Mouais. Il y a quand même le problème de l'interface et des masques. Avec Pixinsight je peux ouvrir plein de fichiers à la fois, générer des masques facilement, et comparer des images facilement. Il y a pléthores d'outils, soit en natif, soit via des scripts, c'est vraiment un couteau suisse. Avec Siril j'ai l'impression que c'est plus compliqué, et même si l'interface est mieux c'est quand même encore particulier. Rien que l'histoire des dossiers de travail c'est d'un chiant. 

Ce que je disais dans mon post d'avant. Les masques existent, dans la version de dev : ça fera partie de la future grosse mise à jour. Pour le multifenêtre, on a un script Python qui permet d'ouvrir autant de fenêtres que l'on veut. Je fais de la cam mono. Et franchement je n'éprouve pas le besoin d'ouvrir plusieurs images en même temps. À aucun moment. Je pense que c'est vraiment une histoire de workflow.

 

En fait, d'un point de vue développement, avoir un module de scripting en python, permet BEAUCOUP plus de folies, par rapport au javascript :).

[lock042]

Il y a 23 heures, nico1038 a dit :

Mon hypothèse est que c'est du avant tout à la pondération mais il faudrait pouvoir isoler ce paramètre et le tester sur plusieurs séries d'images...

Siril a des outils de pondération mais c'est vrai qu'AMSP ne les utilise pas. Ça se corrige facilement cependant.

 

A noter, dans la version de dev de siril je suis en train d'introduire de la pondération via la PSF, similaire à ce qu'on trouve dans PI par défaut. Les résultats que j'obtiens (valeur des coefficients de pondération) sont parfaitement similaires actuellement.

[Tromat]

Pour les amoureux du drama :

- ça d'abord : 

 

- et ensuite ça : https://pixinsight.net/dev/index.php?articles/open-letter-to-pixinsight-users.25/

 

Sortez le popcorn.