Okee, ik zie dat je er flink werk van maakt om het helder te krijgen ;-) Top!
Een score per frame is inderdaad handig, maar daar zitten ook meteen veel gevaren aan. Je wilt weten hoe die score precies wordt berekend en welke factoren er een rol spelen. Sommige factoren zoals de SNR weight is met name een gevaarlijke factor die je gewoon niet wilt meenemen in de kwaliteitsbepaling (ook al doen dit heel veel mensen!!! ).
Mijn argumenten tegen het gebruik van SNR weight
– SNR weight is een relatieve SNR bepaling die echt extreem! gevoelig is voor gradienten in je data. Twee even goede subs met verschillende gradienten (wat je al hebt een uur later op dezelfde nacht) zullen (onterecht) een verschillende SNR bepaling laten zien. Deze waarde is helemaal niet robuust te noemen.
– opnames met dikkere sterren door verlies van optimale focus of slechter wordende transparantie/seeing laten een hogere SNR weight zien.
– hoge sluierbewolking draagt duidelijk bij aan een hogere SNR weight…. dus je krijgt een hoge waarde terwijl de opname waarschijnlijk niet goed is.
Ik zelf kijk nooit naar de SNR, enkel naar de noise, maar in APP bekijk ik de noise pas na data normalisatie, dat is de noise waarde die van wezenlijk belang is voor het stacken. Zoals ik liet zien in jouw PI versus DSS stack verhaal is een noise vergelijking alleen zinvol na data normalisatie, daarvoor is het van weinig waarde… helemaal als je data wilt combineren van verschillende setups en/of verschillende nachten dan wel atmosferische condities. ( Zowel PI als DSS doen dit dan ook volgens mij niet helemaal goed is mijn bescheiden mening. )
Als je de 4 subs upload naar onze gezamelijk dropbox folder analyseer ik ze even met APP, en zal dan de resultaten hier tonen. Dan kunnen we kijken of er verschillen zijn, dan wel overeenkomsten? Ook APP toont een quality getal per sub middels een formule om de gebruiker te helpen.
Aangezien je zelf al veel doet om goede subs te verzamelen zou je toch vrij makkelijk een goede indicatie moeten krijgen welke frames goed of niet goed zijn lijkt me.
“Brandende vraag van mijn kant: Je verwijst naar de periode dat je een trial versie van PI had, waarom heb je als ontwikkelaar van de directe concurrent van PI geen gewone licentie aangeschaft?”
Ik heb toen de trial werkte (dacht 45 dagen) PI uitgebreid getest en vergeleken op de features die APP ook heeft en ik wist vrij snel genoeg. Bovendien ken ik de handleiding van PI bijna uit mijn hoofd en bijna alle referenties die PI geeft heb ik ook gelezen en nog meer. Ik vond het op dat moment niet nodig om PI aan te schaffen want ik had genoeg informatie op dat moment.
Mogelijk dat ik PI wel aanschaf wanneer de Beta groep start, want het is duidelijk dat vrijwel iedereen in de beta groep met PI werkt en PI is dus wel de referentie voor iedereen. Als ik dan zelf PI heb is het makkelijker om te communiceren en vergelijkingen te maken natuurlijk.
Ik wil er ook wel bij aangeven dat ik gewoon een zo goed mogelijk verwerkings programma voor Deep Sky opnames wil maken en dat ik mijn eigen gedachtes volg op basis van de literatuur die ik lees. Zo heb ik in APP een paar unieke features gemaakt die anders zijn dan in PI en als concept nieuw zijn, zoals normalisatie maps naast rejection en weight maps. Ik heb bewust niet blind de uitleg van de PI handleiding gevolgd omdat ik het daar op sommige punten ook niet mee eens ben of omdat ik denk dat het anders dan wel beter kan dan wel moet. PI is een goed programma, maar er is nog heel veel ruimte voor verbetering, daar ben ik wel van overtuigd.