Subs selectie/beoordeling op achtergrondhelderheid.

Activity Forums Astrotechniek Methoden en Technieken Subs selectie/beoordeling op achtergrondhelderheid.

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #12143
    KeesScherer
    Participant

    Dit zijn raw frames van 4 verschillende nachten “op de diasorteerder”. Alle 4 deze nachten waren helder volgens b.v. meteoblue en ook volgens mij wanneer ik buiten ging staat met een verrekijker. Ook de Cloudwatcher-grafiek gaf een heldere hemel aan in deze 4 gevallen. Maar de hemelachtergond (en waarschijnlijk ook de SQM waarde, maar die heb ik helaas niet gemeten)  is duidelijk verschillend. Ik zoek een bruikbare methode om subs op kwaliteit te sorteren. Het PI subframeselectorscript is heel traag en ik zie geen goede overeenkomst met de achtergrondhelderheden die ik zie. Wat ook goed werkt is om van elke sub een achtergrondpreview helderheid te meten met de hand, maar ook dat is traag. En waar leg je de grens? Wie heeft tips? Dit probleem speelt met name bij het verzamelen van data voor panelen van een mozaiek, bij b.v. 45 goede subs van paneel 1 kan je verder met paneel 2 enz. Maar je wilt niet teveel data en een 2e kans om even subs bij te schieten is er misschien niet. Ik weet dat Mabula heeft aangeraden om alleen met sterdichtheid te werken als maat voor kwaliteit, maar achtergrondhelderheid zou een directe relatie met SNR moeten hebben en dus ook met het aantal sterren in een sub alleen zie ik nog geen goede correlatie.

    #12147
    Haverkamp
    Participant

    Hoi @KeesScherer,

    Kwaliteits beoordeling van je frames op achtergrond waarde zou voor Pixinsight geen probleem mogen zijn lijkt me.

    Met welk algoritme wil je de data analyseren dan wel normaliseren?

    De vraag is even of je in PI een preview van de foto’s kan krijgen na de data normalisatie, d.w.z. de foto’s gecorrigeerd voor lokatie en dispersie. Als je dan ziet dat de genormaliseerde foto’s er qua belichting hetzelfde uitzien (geen of met dezelfde stretch, met stretch zie je natuurlijk meer mogelijke verschillen) en de histogrammen van de foto’s dezelfde vorm hebben, dan is dat je probleem niet.

    Ik geloof zelf dat PI je dit niet kan tonen omdat de frames worden genormaliseerd in het stack proces. (Althans dat was zo toen ik een dik jaar geleden een PI trial had.) . Dus ik geloof niet dat je PI kan controleren in dit opzicht, als het wel kan hoor ik dat graag.

    Een groot probleem voor goede data normalisatie zijn de immer aanwezige gradienten. Mogelijk dat die je de indruk geven dat PI verkeerde waardes vindt voor de lokatie van de histogrammen.

    Als je data hebt met heel veel hemelachtergrond, dus geen neveligheid, dan zal de lokatie van het histogram min of mee overeen komen met de hemelachtergrond. Maar als de foto’s flink gevuld zijn met neveligheid, dan gaat die vlieger niet meer op. De data normalisatie routines moeten dan ook slimmer/robuuster worden om dat goed te normaliseren.

    Een ander probleem is als je data hebt met verschillende beeldvelden (bij een mosaic of als je foto’s van verschillende camera’s/OTA’s wilt combineren ), dan werkt de naieve en conventionele normalisatie methode gewoon echt niet goed, want de lokatie en dispersie wordt bepaald voor de complete foto (althans ik neem aan dat PI dat doet) en als die een ander beeldveld hebben, ga je nooit goed normalisatie krijgen op de conventionele methode.

    (APP heeft techniek in huis om je voor het stacken te laten zien of data normalisatie goed gaat overigens ;-) en met hulp van normalisatie maps kan je de kwaliteit van data normalisatie verifieren, Local Normalization Corrections lost het probleem van de gradienten op voor het stacken)

    #12149
    KeesScherer
    Participant

    Hoi Mabula!  Ik heb je antwoord gelezen (bedankt daarvoor!) , en het nogmaals gelezen maar ik kan dat geen handen en voeten geven. Ik hou al rekening met de minimale hoogte van objecten en maak de vergelijking tussen subs op vergelijkbare hoogte boven de horizon. Mijn probleem in deze is dat ik het liefst een getal/score aan een sub hang voor de selectie en constateer dat DeepSkyStacker dat eigenlijk goed doet met een score per sub. Wanneer ik dat vergelijk met het subframeselectorscript en het batchstatistics script van PI dan zie ik eigelijk dat de SNR weight waarden van PI een hele goede correlatie hebben met de DSS score. En DSS is in deze 20 x zo snel…(Zie bijgaande vergelijking van 4 sterk uiteenlopende kwaliteit subs)

    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?

    #12150
    Haverkamp
    Participant

    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.

    #12153
    KeesScherer
    Participant

    Dank Mabula! Ik heb de 4 subs ge-upload naar onze dropboxfolder. Het antwoord over het bezit van PI is helder zo. Ik voel aankomen dat mijn vraag geen simpel antwoord heeft, dat er zelfs voor een setup die gelijk blijft en gelijke postie aan de hemel met gelijk onderwerp/FOV en gelijke belichting geen simpele sortering mogelijk zou zijn van RAW bestanden.

    #12154
    Haverkamp
    Participant

    Graag gedaan, ik doe de analyse nu meteen ;-)

    #12156
    Haverkamp
    Participant

    Hmm, daar zit niet veel overlap in… maar als je de andere panels maakt komt dit helemaal goed :-)

    #12158
    Haverkamp
    Participant

    Okee, de analyse uitslagen die APP vindt zie je in de screenprint bij deze tekst. Op het eerste oog zie ik geen heel groot verschil in kwaliteit in deze data.

    De volgorde is dezelfde die je toont in het excel bestand? Gesorteerd op opname datum.

    – de min en max ster FWHM ( dus hoe meer verschil, hoe ovaler, ik gebruik geen eccentricity, maar toon gewoon de min max FWHM van het ster profiel, dat is volgens mij meer evident.).

    1) 2,61 -2,66

    2) 2,67 – 2,70

    3) 2,25 – 2,83

    4 2,51 – 2,74

    dit komt overeen met wat PI toont zo te zien

    Sterren

    1) 950

    2) 1008

    3) 1111

    4) 1102

    APP toont minder sterren omdat ik heb geselecteerd dat alleen sterren worden gebruikt die uit minstens 4 pixels bestaan en 8 kappa boven de lokale ruisvloer komen. Die sterren zijn dan ook geschikt voor een goede registratie. Je ziet ook niet helemaal een zelfde verhouding in de star support van PI. Frame 3 en 4 tonen de meeste sterren. Maar frame 1-3 horen bij het panel linksonder, terwijl frame 4 rechtsboven.

    Achtergrond en dispersie analyse:

    allereerst een kanttekening: dit zijn niet gecalibreerde frames, maar wel van dezelfde setup, dus dispersie als gevolg van vignettering heeft dezelfde invloed. Dus we kunnen nog redelijk de boel vergelijken. Maar normaal wil je deze analyse doen op zo goed als mogelijk gecalibreerde opnames.

    En let op, waarde genormaliseerd in 0-1 data range

    Lokatie (dan wel achtergrond waarde) voor R  G  en B:

    1) 0,214   0,201   0,152

    2) 0,195   0,188  0,149

    3) 0,181   0,176  0,146

    4) 0,184   0,175  0,145

    Op basis van deze waardes zou je verwachten dat frame 3 en 4 het donkerst zijn en dus mogelijk het beste

    dispersie (dan wel spreiding van data tov de achtergrond waarde)

    1) 0,00425   0,00339   0,00253

    2) 0,00371   0,00302  0, 00240

    3) 0,00329   0,00266 0,00226

    4) 0,00335   0,00262  0,00231

    aangezien de data van dezelfde setup is, is het op basis van deze waardes aannemelijk om te denken dat in frame 1 en 2 meer lichtvervuiling en/of gradienten zitten. Dus mogelijk van mindere kwaliteit en/of lastiger te verwerken/bewerken.

    #12161
    KeesScherer
    Participant

    Hmm, daar zit niet veel overlap in… maar als je de andere panels maakt komt dit helemaal goed

    Dat komt goed Mabula, ik heb tot nu toe data voor paneel 1 t/m 4, maar het wordt een 6 paneel mozaiek met 45x 4minuten per paneel.

    #12164
    Haverkamp
    Participant

    En dan nu SNR en noise, en nu zien we hele grote verschillen met de uitkomsten van PI.

    Allereerst

    1) APP berekent noise en SNR pas na data normalisatie ( PI niet ).

    2) APP toont SNR en noise van alle drie de kanalen apart.

    3) de data is in dit geval genormaliseerd met achtergrond neutralisatie, dat kan ook uitgezet worden.

    4) gebruikte debayer patroon heeft veel invloed op de scherpte en ruis in een opname. In PI is waarschijnlijk VNG gebruikt? In APP is Adaptive Airy Disc gebruikt ( zelf ontwikkeld dus nog onbekend in de fotografie wereld).

    SNR voor R G en B

    1) 1,45   1,49  1,14

    2) 1,31   1,38  1,16

    3) 1,30 1,37  1,17

    4) 1,32  1,40  1,23

    Dit geeft een behoorlijk consistent beeld voor de SNR per kanaal. Frame 1 heeft duidelijk wat meer SNR, beinvloed door extra gradienten denk ik. PI toont hogere waardes en wat meer spreding in de gevonden waardes… bij APP is de spreding kleiner dan 1% van de gevonden waarde bij de laatste 3 frames. In Pi is het iets van 3-5%.

    noise voor R G B

    1) 0,00237   0,00187   0,00224

    2) 0,00244   0,00194  0,00227

    3)  0,00248  0,00199  0,00228

    4)  0,00250  0,00204  0,00226

    Dit moet vergeleken worden met de Noise waardes van PI in 16bit neem ik aan?

    een noise waarde van 0,0025 in de 0-1 range correspondeert met 0,0025 * 65535 in 16bit = 160 ADUs

    Pi vind voor de eerste 2 frames een noise van 70-77 ADU, voor de laatste 2  54-55 ADU.  (Hier gaan nu bij mij alarmbellen klinken…)

    Het is uiterst vreemd dat PI hele verschillende noise waardes vind voor deze frames. Als je naar de Noise waardes kijkt in APP zijn die heel stabiel per kanaal en dat verwacht je denk ik ook, want de subs zijn bij vrijwel dezelfde temperatuur gemaakt en de data is genormaliseerd. Dat frame 1 de laagste noise heeft komt omdat de noise bepaling wordt gedaan na data normalisatie en frame 1 heeft de hoogste dispersie door vermoedelijk gradient.. dus dat trekt de noise van dat frame als bijdrage aan de stack die je mogelijk maakt omlaag.

    Ik zal de noise vergelijking even doen zonder correctie voor dispersie om dat te laten zien.

    #12173
    Haverkamp
    Participant

    noise zonder dispersie correctie in de normalisatie weer voor R G B:

    1) 0,00307  0,00238  0,00250

    2) 0,00275 0,00220  0,00242

    3) 0,00248  0,00199 0,00228

    3)  0,00255 0,00201 0,00232

    Nu zie je dat frame 1 en 2 de hoogste noise hebben, dat is wat je verwacht. Die frames zijn bij vrijwel dezelfde temperatuur geschoten en zelfde exposure tijd en zelfde iso. Ze hebben een iets hogere achtergrond waarde, dus de shotnoise van de hemelachtergrond is in dit geval de verklaring voor het verschil.

    #12174
    Haverkamp
    Participant

    Oh en APP’s quality waarden voor de frames

    1)  420

    2)  426

    3)  459

    4)  459

    Dus ja, de DSS score toont misschien een beetje een zelfde beeld, maar de verschillen tussen de frames zijn echt niet zo extreem als DSS toont. Ik vind dit behoorlijk consistente data @KeesScherer ;-)

    APP vind frame 3 en 4 het beste en dat komt door meer sterren, lagere achtergrond, en kleinere sterren met name. Wel zijn in frame 3 en 4 de sterren wat ovaler wat de score iets omlaag trekt. Ronde sterren worden in APP goed beloond. Dus qua rondheid zijn frame 1 en 2 beter als frame 3 en 4, dat toont PI ook. De noise maakt vrijwel geen verschil tussen de opnames.

    In PI zie je in dit geval mooi dat de SNR weight een waarde is die je niet wilt meenemen in de kwaliteitsbepaling. De SNR is het hoogst voor het slechtste frame…

    #12175
    KeesScherer
    Participant

    Dank voor de Analyse Mabula! Ik had even over de negatieve correlatie tussen SNR weight in PI en DSS score heengekeken, die SNR van PI wil je echt niet gebruiken voor selectie zeg, poeh!

    #12176
    Theunissen
    Participant

    – opnames met dikkere sterren door verlies van optimale focus of slechter wordende transparantie/seeing laten een hogere SNR weight zien.

    Aanvullend, subs met lichtsporen (satellieten, vliegtuigen), laten ook een significant hogere SNR zien.

    #12181
    Haverkamp
    Participant

    Graag gedaan Kees ;-)  en inderdaad Marc ;-)

    Even nog een uitleg over de gevonden lokatie/achtergrond waardes.

    In APP negeer ik het black point van de Canon CR2 files. Ook CR2 hebben een blackpoint, deze zit heel stiekem verborgen in een paar pixel waardes aan de rand van de sensor die er altijd afgecropt worden. De blackpoint in de Canon 6D is 2048 zie ik in je files.

    Daar moeten we voor corrigeren omdat de data niet is gecalibreerd. Normaal wordt dit door de masterbias of masterdark ervan afgehaald ;-)

    Dus de lokatie van frame 1:

    16bits : 0,214* 65535 = 14024  –> 14  bits = 3506  –> blackpoint eraf 3506 – 2048 =  1458 ADU

    frame 3:

    16bits : 0,181* 65535 = 11861  –> 14  bits = 2965  –> blackpoint eraf 2965 – 2048 =  917 ADU

    Dit komt overeen met de lokaties die PI toont voor frame 1 en 3.

    Dat geeft een beter perspectief van de achtergrond waardes ;-) en de mogelijke invloed van shot noise hiervan op de noise waarde in de opnames

    Ik neem even aan dat je op iso1600 werkt met een gain van (1./2,7) e- / ADU  aangezien unity gain iets van iso 600 is volgens mij.

    Dus de lokatie in e-

    1) 1458 * (1/2.7) = 547 e-

    2) 917 * (1/2.7) = 343 e-

    Laten we ervan uitgaan dat de QE van de 6D 50 % is

    Dus het aantal fotonen

    1) 1100

    2) 700

    Shot noise hiervan is de wortel

    1) 33 fotonen shot noise

    2) 26  fotonen shot noise

    terug rekenen naar e- naar 14bits en naar 16bits

    1) 33 * 0.5 = 16 e- * 2.7 = 43 ADU * 4 = 170 ADU in 16bits

    2) 26 * 0.5 = 13 e- * 2.7 = 35 ADU * 4 = 140 ADUs in 16bits

    Als we terug kijken naar de gevonden noise waardes, (niet gecorrigeerd voor dispersie), van PI en APP dan zie je dat de Noise waardes van APP hier net iets boven liggen, namelijk

    1) 0,00307  * 65535 = 200 ADU

    3) 0,00248  = 160 ADU

    Het verschil tussen de gevonden noise en de shot noise moet worden gegeven door de andere noise bronnen, de read noise en dark current lijkt me. En in mijn berekeningen ben ik ook niet helemaal precies geweest.

    De verhouding tussen de shot noise componenten in 16bit is 170/140 = 1.2. Nu zie je in de gevonden noise waardes van APP deze verhouding duidelijk terugkomen:

    0,00307 / 0,00248 = 1.22

    De verhouding in PI is

    7,74 / 5.41 = 1.43 , dit komt uit de excel file van @KeesScherer.

    wat dit mogelijk betekent voor de noise bepaling in PI laat ik aan de oplettende lezer ;-)

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.
Scroll to Top