DeepSkyStacker versus Pixinsight stacking.

Activity Forums Astrosoftware PixInsight DeepSkyStacker versus Pixinsight stacking.

Viewing 13 posts - 31 through 43 (of 43 total)
  • Author
    Posts
  • #10898
    Groenewold
    Participant

    Zijn boxplotjes dan niet interessant om de ruis-waarden in te zetten? Of is dat te simpel gedacht.

    #10900
    Groenewold
    Participant

    Uitermate 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.

    #10903
    Haverkamp
    Participant

    Qua 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:

    #10905
    KeesScherer
    Participant

    \0/ yay! Deze conclusie snap ik weer!

    #10908
    Groenewold
    Participant

    Als APP nu beiden goed doet, ben je klaar. ;)

    #10910
    Haverkamp
    Participant

    Zijn 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:

    #10911
    Haverkamp
    Participant

    Uitermate 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.

    #10912
    Haverkamp
    Participant

    \0/ yay! Deze conclusie snap ik weer!

    HiHaaaaaahhhh!

    #10913
    Groenewold
    Participant

    Dat 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.

    #10914
    Haverkamp
    Participant

    Een 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.

    #10942
    MauriceToet
    Participant

    Prachtige, 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.

    #10944
    Groenewold
    Participant

    Klopt, 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.

    #10959
    Haverkamp
    Participant

    @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)

Viewing 13 posts - 31 through 43 (of 43 total)
  • You must be logged in to reply to this topic.
Scroll to Top