› Fora › ASTRO-FORUM › ASTROFOTOS OG -TEGNINGER › LocalNormalization i Pixinsight – hjelp ønskes
- Dette emne har 9 svar og 3 stemmer, og blev senest opdateret for 5 år, 1 måned siden af erikgu. This post has been viewed 832 times
-
ForfatterIndlæg
-
24. januar 2019 kl. 18:16 #320272
ØysteinDeltager- Giant
Hei,
Er det Pixinsight brukere her inne som har erfaringer å dele når det gjelder ”LocalNormalization” før en stacker?
Det jeg først og fremst tenker på er valg av referansebilde. Hva er det lurt å vektlegge? SNR, minst mulig gradienter, eller…?
Selv har jeg så langt ikke brukt LocalNormalization, men føler at det kanskje er noe jeg burde se nærmere på.
Mvh
Øystein24. januar 2019 kl. 22:31 #320275
erikguDeltager- Nova
Hei Øistein,
Jeg skal ikke si jeg kan LocalNormalization. Jeg har akkurat satt meg inn i det i ei runde hvor jeg brukte det på Rosetta HA. Kvalitet blei en del bedre på stacket bilde enn ute LN.
Jeg fulgte https://www.lightvortexastronomy.com/tutorial-pre-processing-calibrating-and-stacking-images-in-pixinsight.html#Section5 i stor grad. Dvs,. at SubframeSelector med vektformelen:
(15*(1-(FWHM-FWHMMin)/(FWHMMax-FWHMMin)) + 15*(1-(Eccentricity-EccentricityMin)/(EccentricityMax-EccentricityMin)) + 20*(SNRWeight-SNRWeightMin)/(SNRWeightMax-SNRWeightMin))+50
som du finner et stykke nedi blei brukt til å finne best frame som blei brukt som referanse i LN pluss at jeg brukte vektingen i scriptet under integreringen.Jeg har ikke satt meg inn i formelen men det ser ut til å gi et godt resultat.
Erik G
25. januar 2019 kl. 11:37 #320277
ØysteinDeltager- Giant
Hei Erik,
Mange takk for ditt interessante innspill! Veldig kjekt om vi i forumet noen ganger også kan diskutere slike små ”detaljer” i tillegg til å vise fram bildene våre. Emnet er nok bare interessant for de som bruker akkurat denne programvaren, derfor prøvde jeg å være tydelig i emneoverskriften.
Jeg er ikke sikker på at jeg ennå helt har forstått hva LocalNormalization gjør, Pixinsight er ikke akkurat på topp når det gjelder dokumentasjon, men mener at det dreier seg om hvordan en bedre skal hanskes med tilfeller der en har fotografert over flere kvelder og med vekslende forhold slik at de ulike sub’ene har ulike gradienter – styrke, form og retning. Uten bruk av LN kan en da risikere at masterbildet etter stacking har et veldig komplisert gradientmønster. Standard prosedyre med Pixinsight er jo å fjerne gradienter i hvert masterbilde med DBE (evt. ABE) og så ta en ny omgang med samme etter at en har kombinert til (L)RGB. Dette fungerer oftest forbausende bra, men jeg tror at hensikten med LN er å oppnå et enda bedre resultat – å enda bedre bevare små reelle variasjoner i bakgrunnen som skyldes svak tåke eller IFN.
Jeg tror at riktig valg av referansebilde da blir helt sentralt. Hvis LN fungerer slik jeg tror, forbehandles sub’ene før stacking slik at de blir mer like gradientmessig – hver sub transformeres slik at den gradientmessig etterligner referansebildet. I beste fall gjør dette senere bruk av DBE (evt. ABE) enda bedre. Tror jeg :)
Formelen du angir gir prioritet/vekt til sub’er med god seeing, god tracking, god fokusering osv. , samtidig som alle uansett bidrar med minst 50% vekt (de helt håpløse sub’ene kan en jo manuelt sortere fra før en stacker). Jeg tror formelen fungerer helt utmerket under stackingen.
Jeg er imidlertid ennå litt usikker på om en for LN referansebildet ikke heller burde lete fram et bilde som er minst mulig plaget av gradienter. Samtidig må det jo være et ”godt” bilde ellers også. Kanskje en kan sortere sub’ene først basert på din formel, og så etterpå plukke ut et av de som ligger høyt oppe på listen og som samtidig synes å være et av de beste gradientmessig?
At dette er blitt interessant for meg nå, er fordi jeg jobber med et område rundt Polaris med svak IFN som jeg vil prøve å løfte fram.
Øystein
25. januar 2019 kl. 12:57 #320280
erikguDeltager- Nova
Hei Øystein,
Ang. utvelgelsen av referansebildet så var det så små forskjeller på de “beste” hos meg, gradient kunne jeg ikke se noe forskjell på. Når det gjelder gradient vil den ikke ha noe å si på vektingen? trodde at de må ha noe å si på “stjernekvaliteten” som vel er med i vekt beregningen?
Erik G
25. januar 2019 kl. 14:48 #320281
ØysteinDeltager- Giant
Hei igjen, Erik
Stjernekvaliteten inngår absolutt i formelen, men jeg er usikker på hvor mye gradienter påvirker denne (og dermed vektingen). Jeg tror egentlig at LocalNormalization har mest for seg når en har vanskelige gradienter og gradientene varierer mye mellom sub’ene/øktene. Dessuten av type bilde/objekt – hvor vesentlig det er å bevare svake ekte variasjoner i himmelbakgrunnen.
Øystein
25. januar 2019 kl. 22:54 #320294
erikguDeltager- Nova
Hei igjen,
Du har sikker rett Øystein. Jeg tror det er gunstig for meg å bruke LN siden jeg bor i et boligfelt med mye lys som lager gradienter. Hvis jeg må foreta en meridian flip vil en normalisering også være til “stor” hjelp. Når jeg tok Rosetta eksponeringene så var det med en flip pluss mye måne som også vil gi varierende gradient i løpet av natten.
Erik G
27. januar 2019 kl. 14:59 #320354
ØysteinDeltager- Giant
Hei,
I en egen tråd legger jeg ut et CASE der jeg bruker LocalNormalization til å kombinere to datasett som er forskjøvet og rotert i forhold til hverandre.
Øystein
31. januar 2019 kl. 17:59 #320424
denjnieDeltager- Planet
Hej Øystein
Jeg er enig i at vejledningerne er sparsomme, men jeg kan anbefale denne video: https://www.youtube.com/watch?v=Oh52MJsi6rc
Min erfaring er, at LN kan give værdi. Jeg deler din opfattelse af, at processen bruges til at normalisere subs som ikke er flade, f.eks grundet skydække.
Dette er dels for at gøre billedet fladere inden DBE, dels for at kunne anvende subs i integrationen som man ellers ville smide væk.Referencebilledet skal være det billede som har den mest jævne baggrund. En integration af flere subs kan også bruges og jeg har endda anvendt ABE eller DBE på referencebilledet.
Som det ses i ovenstående video kan LN ikke kun bruges “batch”, men også visuelt på enkelte billeder ved at trække trekanten over, som normalt.
Mit workflow er, at jeg initielt anvender BatchPreprocessing Script.
Herefter udvælger jeg referencebilledet til LN blandt de registrerede subs, eventuelt integrerer flere til en stak.
jeg udvælger referencebilledet visuelt, som det mest flade billede – jeg tror at udvælgelse via Subframeselector kan være misvisende
Herefter afvikler jeg LN på de registrerede billeder, hvorefter jeg stakker manuelt via ImageIntegrationKan det betale sig ? – Jeg ved det ikke. Der er ingen tvivl om at LN kan reparere subs som man ellers ville kaste bort.
LN reducerer signalet kraftigt (se billedet), så filosofien må været, at disse trods alt bidrager lidt til den færdige integration
Jeg har eksperimenteret lidt med at sammenligne SNR med og uden LN – LN giver en mindre SNR, men ikke signifikant.
Jeg bruger også LN i kombination med vægte fra SubframeSelector, men har ikke målt hvor stor den reelle værdi erJeg hører gerne om Jeres erfaringer – ovenstående er mine foreløbige – og indtil videre sparsomme erfaringer
Jeg vedlægger et skærmbillede: https://www.dropbox.com/s/vz0eomx5brtv099/Sk%C3%A6rmbillede%202019-01-31%20kl.%2017.49.23.png?dl=0
– Øverst er mit referencebillede som er en stak af 3 billeder, efterfulgt af ABE
– Midterst er der 3 frames som tydeligvis har skyer
– Nederst er de LN kørt på de 3 frames. Resultatet er fladere, men også grovere frames, der dog kan bidrage til den endelige stakmvh. Jens
Edit: Mit uploadede billede, eller mit linkede billede vises ikke – jeg ved ikke hvorfor
31. januar 2019 kl. 22:43 #320430
ØysteinDeltager- Giant
Hei Jens,
Mange takk for ditt grundige innlegg! Interessant link, jeg vil prøve å bruke LN på enkeltbilder også.
Jeg tror egentlig at vi forstår LN svært likt. Både når det gjelder valg av referansebilde og når en har størst effekt av å bruke metoden. Et hovedpoeng er nok at LN transformerer sub’ene slik at bakgrunnen til referansebildet etterlignes. Slik kan f.eks sub’er der deler av bildet er plaget av drivende skydekke eller et utelys som plutselig kommer på reddes. Generelt vil også bruk av LN gjøre at det integrerte bildet er mindre kaotisk gradientmessig, slik at senere bruk av DBE/ABE blir enda mer effektiv.
Jeg ser imidlertid ikke bort fra at LN også har sine svakheter, så jeg tror jeg vil reservere metoden til tilfeller der jeg klart ser et behov. Og jeg vil passe på, som også Erik var inne på, at referansebildet er av god kvalitet også utover det å ha en flat bakgrunn – er redd for å tilføre bildene mer støy. Kommer nok til å ’blinke’ meg gjennom sub’ene.
En litt mer spesiell bruk av LN er som vist i en annen tråd, ”CASE”. Her er det jo ekstrem ulikhet i bakgrunnene, og LN gjør etter mitt syn ”underverker”.
Som deg bruker jeg BatchPreprocessing scriptet, der jeg altså legger inn LN-filene (og oftest drizzle-filer) i tillegg til de registrerte (align.) bildene. Første gang jeg forsøkte, ga bruk av LN absolutt null effekt. Advarer andre mot å gjøre samme feilen som jeg: Husk å endre parameteren Normalization til verdien ”Local normalization”!
Synd at du ikke fikk lagt ut skjermbildet ditt, men jeg tror at jeg forstår poenget. Interessant at du laget referansebilde av en stack. Jeg er litt usikker når det gjelder den etterfølgende bruken av ABE på referansebildet, DBE/ABE skal jo likevel brukes senere.
Mvh
Øystein31. januar 2019 kl. 23:11 #320431
erikguDeltager- Nova
Hei,
Jeg har lest og sett litt mer på LN, også testet litt og ser at det dere sier om å plukke det med minst gradient er det riktige. Jeg satte først det med høyest vekt som referanse, neste forsøk blinket jeg igjennom til jeg fant det med minst gradient. På de stackede bildene vart det ikke enkelt å se noen særlig forskjells så jeg tok derfor bildeLN1-bildeLN2 som ga resultatet under som bare er autostretched i Pixinsight, så LN har effekt.
Her er statistikk resultater som jeg ikke er god på men for meg ser det ut som bilde som er stacket sist, dvs. referanse med minst gradient, siste statistikk, gir bedre dynamikk.
LN1
Det nye bilde behandlet blei slik. link til full størrelse : https://www.dropbox.com/s/w9r2d2kjrfgfaw2/Rosetta12.tif?dl=0
Erik
Erik G
Vedhæftninger:
Du skal være logget ind for at få adgang til vedhæftede filer.
-
ForfatterIndlæg
- Du skal være logget ind for at svare på dette indlæg.