Activity › Forums › Astrosoftware › PixInsight › DeepSkyStacker versus Pixinsight stacking.
Tagged: DSS PI vergelijk
- This topic has 42 replies, 5 voices, and was last updated 9 years, 4 months ago by
Haverkamp.
-
AuthorPosts
-
January 16, 2017 at 19:48 #10898
GroenewoldParticipantZijn boxplotjes dan niet interessant om de ruis-waarden in te zetten? Of is dat te simpel gedacht.
January 16, 2017 at 19:51 #10900
GroenewoldParticipantUitermate subtiel ja, ik zie het wel, maar wat zie je hier na een beetje stretch-werk nog van terug vraag ik me dan af? Het is wel indicatief voor de achterliggende procedures die door beiden gevolgd worden, PI is niet heilig.
January 16, 2017 at 19:54 #10903
HaverkampParticipantQua stergrootte wint de PI stack, maar het is uiterst marginaal (een verschil kleiner dan 0.1 pixel kan ik niet zien namelijk):
Let even op de pixelwaardes van de assen van de contour plot & cross section curves van de PSF, APP heeft intern bepaald om net een iets andere schaal te gebruiken.
eerste plaatje is de PI stack en de tweede is de DSS stack:
January 16, 2017 at 19:57 #10905
KeesSchererParticipant\0/ yay! Deze conclusie snap ik weer!
January 16, 2017 at 20:05 #10908
GroenewoldParticipantAls APP nu beiden goed doet, ben je klaar. ;)
January 16, 2017 at 20:06 #10910
HaverkampParticipantZijn boxplotjes dan niet interessant om de ruis-waarden in te zetten? Of is dat te simpel gedacht.
Wat niet is kan komen natuurlijk ;-)
(Maar ik vind dat zelf niet heel waardevol, je kijkt naar een gestretcht plaatje terwijl de ruiswaarde wordt bepaald op de lineaire data. Dus je zet er een getal bij van iets anders. Maar kan altijd gemaakt worden natuurlijk )
Ik vind het veel interessanter om dan bijvoorbeeld zo’n plaatje te laten zien bij de ruis analyse van een foto, het is eeen echte MRS noise representatie van de data, vind ik zelf veel leuker dan een boxplotje en dit staat op mijn todo lijstje:
January 16, 2017 at 20:09 #10911
HaverkampParticipantUitermate subtiel ja, ik zie het wel, maar wat zie je hier na een beetje stretch-werk nog van terug vraag ik me dan af? Het is wel indicatief voor de achterliggende procedures die door beiden gevolgd worden, PI is niet heilig.
Je bekijkt beide stacks met een identieke stretch in dit geval, dat is juist de manier om het verschil te zien ;-) Als je ze beiden verschillende stretcht, dan ga je andere dingen zien, en dan kan je er ook geen harde conclusie aan verbinden zoals nu.
January 16, 2017 at 20:12 #10912
HaverkampParticipantJanuary 16, 2017 at 20:13 #10913
GroenewoldParticipantDat snap ik, maar ik doel erop dat je met beiden uiteindelijk aan het werk gaat, waarbij de gebruiker uiteindelijk zelf aanpassingen maakt aan de hand van de mogelijke afwijkingen van de uitgangs-data. Oftewel, ook al is dit verschil er, is dat significant genoeg om uiteindelijk dit visueel nog terug te zien.
January 16, 2017 at 20:15 #10914
HaverkampParticipantEen belangrijke nuance in dit verhaal (ik wil de pret niet drukken, maar moet toch):
de verschillen die we zien zijn marginaal en puur het verschil in outlier rejection methode en/of het verschil in demosaic algoritmes die gebruikt zijn, kunnen verantwoordelijk zijn voor deze verschillen.
Maar dat weten we nu dus kwalitatief niet.
January 17, 2017 at 19:18 #10942
MauriceToetParticipantPrachtige, uitgebreide analyse weer, Mabula. Ik ben ook van mening dat de verschillen te verklaren zijn door verschillende outlier rejection methoden. PI biedt daarin veel opties met per optie weer diverse finetuning methoden die niet op basis van intuïtie te doorgronden zijn, maar vragen om trial and error. Dat is nu ook precies wat PI soms een lastig pakket maakt. Gebruikers passen het liefst zoveel mogelijk default settings toe.
January 17, 2017 at 19:45 #10944
GroenewoldParticipantKlopt, maar dat heb ik mij zsm afgeleerd. Met name in mijn laatste bewerking merk ik hoeveel ik gehad heb aan experimenteren, lekker sleuren aan schuifjes en kijken wat het doet.. soms heb je dan opeens data waarbij je je herinnert dat dat schuifje, in dit specifieke geval weleens kan helpen.
January 18, 2017 at 13:13 #10959
HaverkampParticipant@mauricetoet, bedankt voor het compliment.
Wat ik met name wilde aangeven is dat enkel een noise vergelijking tussen subs/stacks middels het PI noise script, echt niet veel zegt en dus makkelijk tot foute conclusies leidt. Zeker als de bron anders is. Enkel als lokatie en dispersie van de histogrammen gelijk zijn kan je een zinvolle ruis vergelijking doen. Op fora wereldwijd wordt deze fout aan de lopende band gemaakt ;-(
En komt PI vaak als winnaar uit de bus. En geregeld dus gewoon onterecht.
De oorzaak:
Pixinsight heeft de flat calibratie zo geimplementeerd dat de data qua dispersie sterk wordt gecomprimeerd. Waarom weet ik niet, en ik heb zelf geen wetenschappelijk verklaring kunnen vinden. Misschien dat bijvoorbeeld Wei-Hao Wang hieraan kan bijdragen in de beta groep. Die weet misschien wel waarom PI dit zo doet en of dit wel terecht/handig is.
De dispersie van een flat gecalibreerde sub in PI is veel lager (factor 10x soms, het is afhankelijk van de gebruikte flats) dan de dispersie van de niet-gecalibreerde sub.
Dit heeft 2 gevolgen:
1) als je data vergelijkt die flat gecalibreerd is, tussen PI en in dit geval DSS, zonder een correcte data normalisatie, zul je altijd tot de conclusie komen dat de ruis in de PI stack lager is.
2) de sterren in de PI stack kleiner zijn. In dit geval zijn de PI sterren ongeveer 10% kleiner, iets van 0,2-0,3 pixel in FWHM waarde.
Maar beide conclusies zijn dus niet helemaal correct en soms zelf gewoon fout dus. Na data normalisatie zie je in dit geval dat de DSS stack beter qua ruis is en dat het verschil in stergrootte is gereduceerd tot nog maar 0.1 pixel, wat maar weinig mensen zullen zien.
(in feite draait PI je een rad voor de ogen door de vreemde flat calibratie, dat is wel mijn stelling op dit moment)
-
AuthorPosts
- You must be logged in to reply to this topic.




