plaatje 4 is met Mitchell Netravali plaatje 5 is met Catmull Rom Spline en plaatjes 6 als laatste met Lanczos-3.IC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-MNCIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CRSIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-LZ3

plaatje 4 is met Mitchell Netravali plaatje 5 is met Catmull Rom Spline en plaatjes 6 als laatste met Lanczos-3.IC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-MNCIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CRSIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-LZ3

plaatje 4 is met Mitchell Netravali plaatje 5 is met Catmull Rom Spline en plaatjes 6 als laatste met Lanczos-3.IC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-MNCIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CRSIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-LZ3

1ste plaatje) Ik heb een crop uit de opnames genomen op volle resolutie rest van de plaatjes heb ik 0,5x verkleind. Dus de resolutie is in breedte en hoogte 2x verlaagd. plaatjes 2 is met nearest neighbour, dat komt qua ruis overeen met hoe ik eerst de afbeelding verkleinde. Dit is het slechtst. plaatje 3 is met Cubic B-Spline, veel beter.IC348-LRGB-AstroPixelProcessor-Mabula-crop-NoStIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-NNIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CBS

1ste plaatje) Ik heb een crop uit de opnames genomen op volle resolutie rest van de plaatjes heb ik 0,5x verkleind. Dus de resolutie is in breedte en hoogte 2x verlaagd. plaatjes 2 is met nearest neighbour, dat komt qua ruis overeen met hoe ik eerst de afbeelding verkleinde. Dit is het slechtst. plaatje 3 is met Cubic B-Spline, veel beter.IC348-LRGB-AstroPixelProcessor-Mabula-crop-NoStIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-NNIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CBS

1ste plaatje) Ik heb een crop uit de opnames genomen op volle resolutie rest van de plaatjes heb ik 0,5x verkleind. Dus de resolutie is in breedte en hoogte 2x verlaagd. plaatjes 2 is met nearest neighbour, dat komt qua ruis overeen met hoe ik eerst de afbeelding verkleinde. Dit is het slechtst. plaatje 3 is met Cubic B-Spline, veel beter.IC348-LRGB-AstroPixelProcessor-Mabula-crop-NoStIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-NNIC348-LRGB-AstroPixelProcessor-Mabula-crop--0degCW-0.5x-CBS

Ik vind deze laatste inderdaad een heel stuk beter dan de eerste ;-) Heel fraai Kees! Ik denk wel dat er behoorlijk wat rood/H-alpha signaal ? mist met name linksonder, de donkere nevel moet volgens mij rood omlijnd zijn. Ik ben met data van Yves bezig van dit gebied en die laat in zowel RGB en H-alpha data daar veel signaal zien, die ik hier niet zie, dat vind ik een beetje vreemd. Misschien dat het met de kleurcalibratie van de sterren en de achtergrond correctie te maken heeft? Ter vergelijking hier 2 crops van hetzelfde gebied van de data van @yves uit zijn 6 panel mosaic in RGB en H-alpha. Ziet er nogal anders uit... ik weet wel dat in Yves data veel licht-vervuiling zit in het RGB signaal, maar dat zal de verklaring niet zijn aangezien je het signaal heel duidelijk in H-alpha ziet.Barnard-Yves-crop-RGBBarnardCrop-Yves-H-alpha

Ik vind deze laatste inderdaad een heel stuk beter dan de eerste ;-) Heel fraai Kees! Ik denk wel dat er behoorlijk wat rood/H-alpha signaal ? mist met name linksonder, de donkere nevel moet volgens mij rood omlijnd zijn. Ik ben met data van Yves bezig van dit gebied en die laat in zowel RGB en H-alpha data daar veel signaal zien, die ik hier niet zie, dat vind ik een beetje vreemd. Misschien dat het met de kleurcalibratie van de sterren en de achtergrond correctie te maken heeft? Ter vergelijking hier 2 crops van hetzelfde gebied van de data van @yves uit zijn 6 panel mosaic in RGB en H-alpha. Ziet er nogal anders uit... ik weet wel dat in Yves data veel licht-vervuiling zit in het RGB signaal, maar dat zal de verklaring niet zijn aangezien je het signaal heel duidelijk in H-alpha ziet.Barnard-Yves-crop-RGBBarnardCrop-Yves-H-alpha

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

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:StarMap-PIstackStarMap-DSSstack

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:StarMap-PIstackStarMap-DSSstack

En ter bevestiging een visuele inspectie van een kleine stukje hemelachtergrond van de 2 stacks die genormaliseerd zijn voor lokatie en dispersie en waarvan de hemelachtergrond is geneutraliseerd. Identieke stretch zonder saturatie, puur om de ruis in de achtergrond qua structuur te zien. Het verschil is subtiel, maar de achtergrond in de DSS stack is gewoon gladder. Eerste plaatje is de PI stack en de tweede is de DSS stack:NoiseVisualInspectationPIstackNoiseVisualInspectation-DSSstack

En ter bevestiging een visuele inspectie van een kleine stukje hemelachtergrond van de 2 stacks die genormaliseerd zijn voor lokatie en dispersie en waarvan de hemelachtergrond is geneutraliseerd. Identieke stretch zonder saturatie, puur om de ruis in de achtergrond qua structuur te zien. Het verschil is subtiel, maar de achtergrond in de DSS stack is gewoon gladder. Eerste plaatje is de PI stack en de tweede is de DSS stack:NoiseVisualInspectationPIstackNoiseVisualInspectation-DSSstack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Nu wordt het interessant ;-), je ziet aan de histogrammen weer dat de dispersie correct is genormaliseerd. De histogram pieken van beide plaatjes zijn even breed. Maar ze zien er anders uit dan in situatie 2a). In situatie 2a) ziet de PI stack er goed uit, en de DSS stack wordt groenig. Maar in situatie 2b) ziet de DSS er goed uit en de PI stack wordt magenta, dat is de tegengestelde kleur van groen. Omdat groen veel meer bijdraagt aan de Luminance, zie je de magenta verkleuring minder goed, maar hij is zeker aanwezig. In het sterrenstelsel zie je dat het blauw, paarsig wordt in de PI stack.DSSRef-NormalisationForLokationAndDispersion-PIStackDSSRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie a) PI stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je nu dat de dispersie correct is genormaliseerd. De pieken zijn even breed geworden per kanaal. De breedte van de piek is de dispersie. Let op, uiteraard weer getoond met voor beide plaatjes een identieke stretch. PIRef-NormalisationForLokationAndDispersion-PIStackPIRef-NormalisationForLokationAndDispersion-DSSStack

2) normaliseren voor zowel lokatie als dispersie a) PI stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je nu dat de dispersie correct is genormaliseerd. De pieken zijn even breed geworden per kanaal. De breedte van de piek is de dispersie. Let op, uiteraard weer getoond met voor beide plaatjes een identieke stretch. PIRef-NormalisationForLokationAndDispersion-PIStackPIRef-NormalisationForLokationAndDispersion-DSSStack

1) Alleen normalisatie voor lokatie ------------------------------------ b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je dat de dispersie van de DSS stack veel groter is, of andersom de PI stack heeft veel lagere dispersie. Tussen situatie 1a) en 1b) zie je dat de stacks niet goed te vergelijken zijn als je alleen normaliseert voor lokatie. Als je de PI stack neemt, wordt de DSS rood en andersom wordt de PI stack blauw. DSSRef-NormalisationForLokation-PIStackDSSRef-NormalisationForLokation-DSSStack

1) Alleen normalisatie voor lokatie ------------------------------------ b) DSS stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je dat de dispersie van de DSS stack veel groter is, of andersom de PI stack heeft veel lagere dispersie. Tussen situatie 1a) en 1b) zie je dat de stacks niet goed te vergelijken zijn als je alleen normaliseert voor lokatie. Als je de PI stack neemt, wordt de DSS rood en andersom wordt de PI stack blauw. DSSRef-NormalisationForLokation-PIStackDSSRef-NormalisationForLokation-DSSStack

Okee, ik heb de 2 stacks uit DSS en PI van @keesscherer bekeken en geanalyseerd met Astro Pixel Processor. APP bekijkt het als volgt: Allereerst heb ik voor een goede vergelijking de twee stacks met elkaar geregistreerd via Lanczos-3 en vanuit de 2 geregistreerde stacks heb ik identieke crops genomen. Dus we hebben nu een exact gelijk beeldveld voor beiden stacks. Nu gaan we kijken wat er gebeurd met de 2stacks als we 1) alleen normaliseren voor de lokatie ( add )van de histogrammen van de stacks 2) normaliseren voor zowel lokatie als dispersie ( add + scale )van de histogrammen van de stacks in beide gevallen worden de gevonden lokaties van de kanalen gebruikt voor het neutraliseren van de achtergrond. en dat doen we 2 kanten op. a) met de PI stack als referentie b) met de DSS stack als referentie Dus we hebben 2*2 = 4 situaties waarin we de 2 stacks bekijken en vergelijken met elkaar. Visueel en in getallen. Ik laat het eerst in plaatjes zien, dan zie je wat de data normalisatie voor dispersie in feite doet. Data normalisatie voor lokatie is enkel de achtergronden additief (middels een offset die zowel + als - kan zijn ) gelijk trekken. Alle plaatjes die getoond worden van de 2 stacks naast elkaar hebben een identieke preview stretch gekregen van de lineaire data. 1) Alleen normalisatie voor lokatie -------------------------------- a) PI stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je dat de dispersie van de DSS stack veel groter is, of andersom de PI stack heeft veel lagere dispersie.PIRef-NormalisationForLokation-PIStackPIRef-NormalisationForLokation-DSSStack

Okee, ik heb de 2 stacks uit DSS en PI van @keesscherer bekeken en geanalyseerd met Astro Pixel Processor. APP bekijkt het als volgt: Allereerst heb ik voor een goede vergelijking de twee stacks met elkaar geregistreerd via Lanczos-3 en vanuit de 2 geregistreerde stacks heb ik identieke crops genomen. Dus we hebben nu een exact gelijk beeldveld voor beiden stacks. Nu gaan we kijken wat er gebeurd met de 2stacks als we 1) alleen normaliseren voor de lokatie ( add )van de histogrammen van de stacks 2) normaliseren voor zowel lokatie als dispersie ( add + scale )van de histogrammen van de stacks in beide gevallen worden de gevonden lokaties van de kanalen gebruikt voor het neutraliseren van de achtergrond. en dat doen we 2 kanten op. a) met de PI stack als referentie b) met de DSS stack als referentie Dus we hebben 2*2 = 4 situaties waarin we de 2 stacks bekijken en vergelijken met elkaar. Visueel en in getallen. Ik laat het eerst in plaatjes zien, dan zie je wat de data normalisatie voor dispersie in feite doet. Data normalisatie voor lokatie is enkel de achtergronden additief (middels een offset die zowel + als - kan zijn ) gelijk trekken. Alle plaatjes die getoond worden van de 2 stacks naast elkaar hebben een identieke preview stretch gekregen van de lineaire data. 1) Alleen normalisatie voor lokatie -------------------------------- a) PI stack referentie Eerste plaatje is de PI stack Tweede plaatjes is de DSS stack Aan de breedte van de histogram pieken zie je dat de dispersie van de DSS stack veel groter is, of andersom de PI stack heeft veel lagere dispersie.PIRef-NormalisationForLokation-PIStackPIRef-NormalisationForLokation-DSSStack

Hoi allen, Dit is een LRGB versie van IC348, volledig geprocessed met Astro Pixel Processor. Details: Tak TSA102 + toa035 0,7x reducer + asi1600mm-c + Baader LRGB + Avalon Linear alle 4 de kanalen 50 x 300s, de L is uiteindelijk gemaakt van alle data samen, dat verhoogd de kwaliteit goed. Dit was niet zo eenvoudig te bewerken. Ik dacht dat het met name een donkere nevel was met slechts een enkele blauwe reflectie nevel. Het blijkt dat in de hele opname er nauwelijks wat zwarte/grijze hemelachtergrond is te vinden...  Er zit veel zwak bruin stof in, maar ook rood en blauw gloeiend gas. De betere opnames op het net laten dit volgens mij ook zien al zie je wel veel verschillen in de uiteindelijke kleuren. Wat vinden jullie van deze bewerking gedaan in APP? Ik denk dat ik nog wat moet werken om wat meer blauwe sterren te krijgen. Ik vind hem zelf al wel heel mooi en hij pakt eigenlijk heel anders uit dan ik verwacht had. De finale versie zal ik uiteraard in het APP forum plaatsen met beschrijving. Ik ben nu gewoon heel benieuwd naar jullie feedback.. ;-)IC348-LRGB-AstroPixelProcessor-Mabula-small

Even een sfeerplaatje tussendoor: Ondergaande zon op 2de kerstdag, lokatie rosendaalse veld, Nikon D610 met Nikkor 50mm f/1.8 SettingSunChristmas-MabulaHaverkamp-1

Fijne kerst dagen allemaal ;-) ! M45-Pleiaden-Dutch

@keesscherer, @supernov & @yves, nee registratie is voor Astro Pixel Processor geen probleem, er zit wel optische vervorming in de star71 die Yves gebruikt, maar die is vrij normaal. Yves probleem zit echt in het corrigeren van de belichtingsverschillen tussen de panelen. Dat lukt niet in Pixinsight geeft hij aan. Dus dat gaan we nu proberen in APP. Ik ben er nu mee bezig. Het is meteen duidelijk dat er veel gradiënt in de losse panelen zit en dat rechtsboven blijkbaar slechtere transparantie had dan linksonder. Sterdichtheid is visueel wat wat lager volgens mij. Dit is de 6-panel van Barnard's loop van @yves even samengesteld uit 6 losse gekalibreerde (bias en flats) lights. Dan zie je redelijk waar het probleem ligt. Hier heb ik dus nog niks aan gedaan in APP om het probleem te tonen.Barnard-6panel-preview-Yves

@keesscherer, @supernov & @yves, nee registratie is voor Astro Pixel Processor geen probleem, er zit wel optische vervorming in de star71 die Yves gebruikt, maar die is vrij normaal. Yves probleem zit echt in het corrigeren van de belichtingsverschillen tussen de panelen. Dat lukt niet in Pixinsight geeft hij aan. Dus dat gaan we nu proberen in APP. Ik ben er nu mee bezig. Het is meteen duidelijk dat er veel gradiënt in de losse panelen zit en dat rechtsboven blijkbaar slechtere transparantie had dan linksonder. Sterdichtheid is visueel wat wat lager volgens mij. Dit is de 6-panel van Barnard's loop van @yves even samengesteld uit 6 losse gekalibreerde (bias en flats) lights. Dan zie je redelijk waar het probleem ligt. Hier heb ik dus nog niks aan gedaan in APP om het probleem te tonen.Barnard-6panel-preview-Yves

Stap 10) de laatste stap, we gaan nu de data stretchen, wat saturatie toevoegen maar niet in de achtergrond, contrast iets verhogen en iets verscherpen terwijl we de sterren beschermen. Dit is dus 1 enkele stretch in de post-processing ;-) Als laatste 4 JPGS, 1) alleen DDP stretch 2) DDP met saturatie 3) DDP met saturatie en contrast 4) DDP met saturatie en contrast en lichte verscherping , dit is tevens het eindresultaat ;-) van deze post-processing. Heb je ideeen en/of tips? Ik hoor ze graag om mee te nemen in mogelijke verdere ontwikkeling van tools voor post-processing in Astro Pixel Processor. Een volgend draadje zal zeer waarschijnlijk uitgebreid ingaan op het daadwerkelijk maken van een stack, dus data calibratie, registratie, normalisatie en het stacken ;-) Alle reacties zijn welkom ;-) !Horsehead-onlyDDPHorsehead-DDP-SatHorsehead-DDP-sat-contrastHorsehead-DDP-sat-contrast-Sharpen

Stap 10) de laatste stap, we gaan nu de data stretchen, wat saturatie toevoegen maar niet in de achtergrond, contrast iets verhogen en iets verscherpen terwijl we de sterren beschermen. Dit is dus 1 enkele stretch in de post-processing ;-) Als laatste 4 JPGS, 1) alleen DDP stretch 2) DDP met saturatie 3) DDP met saturatie en contrast 4) DDP met saturatie en contrast en lichte verscherping , dit is tevens het eindresultaat ;-) van deze post-processing. Heb je ideeen en/of tips? Ik hoor ze graag om mee te nemen in mogelijke verdere ontwikkeling van tools voor post-processing in Astro Pixel Processor. Een volgend draadje zal zeer waarschijnlijk uitgebreid ingaan op het daadwerkelijk maken van een stack, dus data calibratie, registratie, normalisatie en het stacken ;-) Alle reacties zijn welkom ;-) !Horsehead-onlyDDPHorsehead-DDP-SatHorsehead-DDP-sat-contrastHorsehead-DDP-sat-contrast-Sharpen

Stap 10) de laatste stap, we gaan nu de data stretchen, wat saturatie toevoegen maar niet in de achtergrond, contrast iets verhogen en iets verscherpen terwijl we de sterren beschermen. Dit is dus 1 enkele stretch in de post-processing ;-) Als laatste 4 JPGS, 1) alleen DDP stretch 2) DDP met saturatie 3) DDP met saturatie en contrast 4) DDP met saturatie en contrast en lichte verscherping , dit is tevens het eindresultaat ;-) van deze post-processing. Heb je ideeen en/of tips? Ik hoor ze graag om mee te nemen in mogelijke verdere ontwikkeling van tools voor post-processing in Astro Pixel Processor. Een volgend draadje zal zeer waarschijnlijk uitgebreid ingaan op het daadwerkelijk maken van een stack, dus data calibratie, registratie, normalisatie en het stacken ;-) Alle reacties zijn welkom ;-) !Horsehead-onlyDDPHorsehead-DDP-SatHorsehead-DDP-sat-contrastHorsehead-DDP-sat-contrast-Sharpen

Stap 10) de laatste stap, we gaan nu de data stretchen, wat saturatie toevoegen maar niet in de achtergrond, contrast iets verhogen en iets verscherpen terwijl we de sterren beschermen. Dit is dus 1 enkele stretch in de post-processing ;-) Als laatste 4 JPGS, 1) alleen DDP stretch 2) DDP met saturatie 3) DDP met saturatie en contrast 4) DDP met saturatie en contrast en lichte verscherping , dit is tevens het eindresultaat ;-) van deze post-processing. Heb je ideeen en/of tips? Ik hoor ze graag om mee te nemen in mogelijke verdere ontwikkeling van tools voor post-processing in Astro Pixel Processor. Een volgend draadje zal zeer waarschijnlijk uitgebreid ingaan op het daadwerkelijk maken van een stack, dus data calibratie, registratie, normalisatie en het stacken ;-) Alle reacties zijn welkom ;-) !Horsehead-onlyDDPHorsehead-DDP-SatHorsehead-DDP-sat-contrastHorsehead-DDP-sat-contrast-Sharpen

Stap 9) Met de "selective color" tool heb ik 2 iteraties gedaan om een aantal kleuren wat te veranderen. De screenshots spreken voor zich denk ik, maar ik heb aan bijna alle schuifjes getrokken om wat kleine aanpassingen te doen. waaronder: - cyan uit rode tinten gehaald - groene tinten geneutraliseerd door magenta toe te voegen - magenta roder gemaakt ( zie je in de rode nevel ) Met een selective color kan je op deze manier je opnames flink aanpassen en storende kleuren/randjes verwijderen dan wel sterk corrigeren. Deze implementatie in Astro Pixel Processor is speciaal voor astronomie foto's gemaakt. Dit houdt in dat de selective color een gecorrigeerde schatting van de kleur van een pixel maakt. Als je dit niet doet (bijvoorbeeld de selective color in Adobe Photoshop) dan krijg je veel meer chromatische ruis in de lichtzwakkere delen (gebieden met lagere Signaal tot Ruis verhouding) van je opname die je wilt aanpasssen. Screenshots van iteratie 1 en 2:SelecltiveColor-iter1SelecltiveColor-iter2

Stap 9) Met de "selective color" tool heb ik 2 iteraties gedaan om een aantal kleuren wat te veranderen. De screenshots spreken voor zich denk ik, maar ik heb aan bijna alle schuifjes getrokken om wat kleine aanpassingen te doen. waaronder: - cyan uit rode tinten gehaald - groene tinten geneutraliseerd door magenta toe te voegen - magenta roder gemaakt ( zie je in de rode nevel ) Met een selective color kan je op deze manier je opnames flink aanpassen en storende kleuren/randjes verwijderen dan wel sterk corrigeren. Deze implementatie in Astro Pixel Processor is speciaal voor astronomie foto's gemaakt. Dit houdt in dat de selective color een gecorrigeerde schatting van de kleur van een pixel maakt. Als je dit niet doet (bijvoorbeeld de selective color in Adobe Photoshop) dan krijg je veel meer chromatische ruis in de lichtzwakkere delen (gebieden met lagere Signaal tot Ruis verhouding) van je opname die je wilt aanpasssen. Screenshots van iteratie 1 en 2:SelecltiveColor-iter1SelecltiveColor-iter2

Stap 8b) Wat kunnen we meer doen aan de gekleurde sterranden in de opname van Rutger Bus? We zien vooral cyan gekleurde sterrandjes in de opnames. Dit kunnen we heel goed corrigeren met de "selective color" tool die in APP zit. Deze tool werkt ook probleemloos op lineaire data, in tegenstelling tot selective color tools uit andere programma's zoals bijvoorbeeld Adobe Photoshop. We hoeven de data dus niet te stretchen om de cyan randjes te corrigeren. Screenshots van een sterke zoom op de sterren, voor en na de cyan correctie met de "selective color" tool. Om de verschillen duidelijk te maken is de saturatie flink opgeschroefd. En let op ;-) , de data is dus nog steeds niet gestrecht, de screenshots tonen enkel de stretch preview.SelecltiveColor-StarsBeforeSelecltiveColor-StarsAfter

Stap 8b) Wat kunnen we meer doen aan de gekleurde sterranden in de opname van Rutger Bus? We zien vooral cyan gekleurde sterrandjes in de opnames. Dit kunnen we heel goed corrigeren met de "selective color" tool die in APP zit. Deze tool werkt ook probleemloos op lineaire data, in tegenstelling tot selective color tools uit andere programma's zoals bijvoorbeeld Adobe Photoshop. We hoeven de data dus niet te stretchen om de cyan randjes te corrigeren. Screenshots van een sterke zoom op de sterren, voor en na de cyan correctie met de "selective color" tool. Om de verschillen duidelijk te maken is de saturatie flink opgeschroefd. En let op ;-) , de data is dus nog steeds niet gestrecht, de screenshots tonen enkel de stretch preview.SelecltiveColor-StarsBeforeSelecltiveColor-StarsAfter

Stap 8) pixelpeepen op de sterren (met veel saturatie) toont dat de sterren niet helemaal  rond zijn en ook niet vrij zijn van optische aberraties zoals chromatische aberratie en coma. Rutger had ook al duidelijk aangegeven dat de opnames niet perfect gevolgd zijn, met wat ovale sterren tot gevolg. De ovale sterren kan APP op dit moment nog niet corrigeren, maar aan de gekleurde randjes kunnen we zeker wat doen. Er zijn meerdere opties. 1) Als de opnames sterke chromatische aberratie bevatten kunnen we de kleurkanalen uitlijnen met een speciaal ontwikkelde registratie module tegen chromatische aberratie. Dit registratie model is compleet anders dan degenen die worden gebruikt voor de normale registratie van opnames. Dit model kan zowel longitudinale als wel transversale chromatische aberratie goed bestrijden, ook als deze niet symmetrisch in de opnames zit. Het model is door mijzelf ontwikkeld op basis van recente literatuur over de vormen van chromatische aberratie. Ik heb het geprobeerd op deze stack, maar het levert weinig winst op. De chromatische aberratie is niet groot. In getallen: afwijking van Rood ten opzicht van Groen is 0.35 pixel en na correctie 0,22 pixel. afwijking van Blauw ten opzichte Groen is 0,24 pixel en na correctie 0,15 pixel. Er wordt dus wel wat gecorrigeerd, maar deze correctie is echt nauwelijks te zien. Ik heb wel een voorbeeld van een opname waarbij er een hele grote en duidelijke correctie plaatsvind. Dus die toon ik tussendoor ter illustratie: Dit is een opname van Dominique Dierick van  IC405, AE-auriga ook wel de Flaming Star Nebula gemaakt met een Nikon D810a achter een Skywatcher Esprit 150ED met daartussen een TS 0,79x reducer. De CA is in dit geval groter dan 1 pixel en na correctie kleiner dan 0,2 pixel, voor zowel Rood als Blauw t.o.v. Groen. Dat is een correctie die je heel goed ziet. Screenshots voor en na correctie:AE-Auriga-rechteronderhoekCAAE-Auriga-rechteronderhoekCAcorrected

Stap 8) pixelpeepen op de sterren (met veel saturatie) toont dat de sterren niet helemaal  rond zijn en ook niet vrij zijn van optische aberraties zoals chromatische aberratie en coma. Rutger had ook al duidelijk aangegeven dat de opnames niet perfect gevolgd zijn, met wat ovale sterren tot gevolg. De ovale sterren kan APP op dit moment nog niet corrigeren, maar aan de gekleurde randjes kunnen we zeker wat doen. Er zijn meerdere opties. 1) Als de opnames sterke chromatische aberratie bevatten kunnen we de kleurkanalen uitlijnen met een speciaal ontwikkelde registratie module tegen chromatische aberratie. Dit registratie model is compleet anders dan degenen die worden gebruikt voor de normale registratie van opnames. Dit model kan zowel longitudinale als wel transversale chromatische aberratie goed bestrijden, ook als deze niet symmetrisch in de opnames zit. Het model is door mijzelf ontwikkeld op basis van recente literatuur over de vormen van chromatische aberratie. Ik heb het geprobeerd op deze stack, maar het levert weinig winst op. De chromatische aberratie is niet groot. In getallen: afwijking van Rood ten opzicht van Groen is 0.35 pixel en na correctie 0,22 pixel. afwijking van Blauw ten opzichte Groen is 0,24 pixel en na correctie 0,15 pixel. Er wordt dus wel wat gecorrigeerd, maar deze correctie is echt nauwelijks te zien. Ik heb wel een voorbeeld van een opname waarbij er een hele grote en duidelijke correctie plaatsvind. Dus die toon ik tussendoor ter illustratie: Dit is een opname van Dominique Dierick van  IC405, AE-auriga ook wel de Flaming Star Nebula gemaakt met een Nikon D810a achter een Skywatcher Esprit 150ED met daartussen een TS 0,79x reducer. De CA is in dit geval groter dan 1 pixel en na correctie kleiner dan 0,2 pixel, voor zowel Rood als Blauw t.o.v. Groen. Dat is een correctie die je heel goed ziet. Screenshots voor en na correctie:AE-Auriga-rechteronderhoekCAAE-Auriga-rechteronderhoekCAcorrected

Stap 7) ik vond het op dit moment tijd om te werken aan de compositie van de afbeelding. Het leek mij mooi om de afbeelding bijna 90 graden tegen de klok in te draaien en dan mooi de horsehead nebula met de ringvorminge nevel daarboven in beeld te hebben. Dus ik heb de afbeelding eerst geroteerd. Astro Pixel Processor heeft een batch rotate/resize tool waarbij je alle mogelijke transformaties kan toepassen en kan kiezen uit geschikte resampling algoritmes. Je kan de afbeeldingen tegen de klok in , met de klok mee roteren. Je kan verkleinen en vergroten. Je kan flippen in de x of y richting van de opname. In beide richtingen flippen is hetzelfde als 180 graden draaien. En je kan kiezen uit alle resampling algoritmes die in APP zitten. Voor sterke verkleining krijg je bijvoorbeeld meestal betere resultaten met Catmull-Rom spline interpolatie, en voor dezelfde grootte of groter krijg je over het algemeen de beste resultaten met Lanczos interpolatie, te kiezen tussen Lanczos-3 en Lanczos-4. Door verschillende algoritmes te proberen zie je zelf wat het mooist is op pixelniveau, want je moet wel goed inzoomen om de verschillen duidelijk te zien. In APP heb je voor Catmull-Rom Spline en Lanczos interpolatie de keuze uit versies waarbij de algoritmes worden beschermd tegen under & over shooting. Die hebben de toevoeging NUOS ( No Under Over Shoot). Voor het resamplen van een afbeelding in deze tool wil je vrijwel altijd deze NUOS versies gebruiken anders krijg je mogelijk artefacten door under of overshoot. Under shoot kan bijvoorbeeld erg zwarte pixels geven bij de randen van kleine scherpe sterretjes. Met de NUOS algoritmes voorkom je dit ;-) en behoud je tevens de kwaliteit van deze algoritmes. Na de rotatie is er opnieuw gecropt om het uiteindelijke beeldveld te krijgen. Zie screenshot 2.horsehead-LP-BG-crop-ColorRatios-Compohorsehead-LP-BG-crop-ColorRatios-Compo-crop

Stap 7) ik vond het op dit moment tijd om te werken aan de compositie van de afbeelding. Het leek mij mooi om de afbeelding bijna 90 graden tegen de klok in te draaien en dan mooi de horsehead nebula met de ringvorminge nevel daarboven in beeld te hebben. Dus ik heb de afbeelding eerst geroteerd. Astro Pixel Processor heeft een batch rotate/resize tool waarbij je alle mogelijke transformaties kan toepassen en kan kiezen uit geschikte resampling algoritmes. Je kan de afbeeldingen tegen de klok in , met de klok mee roteren. Je kan verkleinen en vergroten. Je kan flippen in de x of y richting van de opname. In beide richtingen flippen is hetzelfde als 180 graden draaien. En je kan kiezen uit alle resampling algoritmes die in APP zitten. Voor sterke verkleining krijg je bijvoorbeeld meestal betere resultaten met Catmull-Rom spline interpolatie, en voor dezelfde grootte of groter krijg je over het algemeen de beste resultaten met Lanczos interpolatie, te kiezen tussen Lanczos-3 en Lanczos-4. Door verschillende algoritmes te proberen zie je zelf wat het mooist is op pixelniveau, want je moet wel goed inzoomen om de verschillen duidelijk te zien. In APP heb je voor Catmull-Rom Spline en Lanczos interpolatie de keuze uit versies waarbij de algoritmes worden beschermd tegen under & over shooting. Die hebben de toevoeging NUOS ( No Under Over Shoot). Voor het resamplen van een afbeelding in deze tool wil je vrijwel altijd deze NUOS versies gebruiken anders krijg je mogelijk artefacten door under of overshoot. Under shoot kan bijvoorbeeld erg zwarte pixels geven bij de randen van kleine scherpe sterretjes. Met de NUOS algoritmes voorkom je dit ;-) en behoud je tevens de kwaliteit van deze algoritmes. Na de rotatie is er opnieuw gecropt om het uiteindelijke beeldveld te krijgen. Zie screenshot 2.horsehead-LP-BG-crop-ColorRatios-Compohorsehead-LP-BG-crop-ColorRatios-Compo-crop

Stap 6) is het verder aanpassen van de multipliers per kanaal om de ster en nevel kleuren naar smaak te krijgen. In dit proces wil je de histogrammen goed in de gaten houden en inzoomen op gebieden met veel sterren om de histogrammen te zien van die stergebieden. Er zijn een paar zaken die je kunnen helpen om tot een goede kleur calibratie te komen, dwz een calibratie die jij mooi vindt of die volgens jou "correct" is. - Om de sterren als geheel neutraal te maken moeten de histogrammen aan de rechterkant ongeveer een zelfde hoogte hebben/krijgen. - de pieken van de histogrammen moeten op ongeveer dezelde plek blijven. - en je wilt spelen met de kleur ratios R/G en B/G en proberen ratios te vinden zodat groen niet zichtbaar wordt, maar de boel ook niet te paars wordt. ( Ik schijn vaak een beetje paarse opnames te maken... dat ligt denk ik ook aan wat ik zelf mooi vind en dat is dus niet goed of fout in mijn optiek ). Dus na een tijdje spelen met de sliders per kanaal, ben ik tot het volgende resultaat gekomen, screenshot en een JPG als output.horsehead-LP-BG-crop-ColorRatiosHorsehead-lpc-cbg-crop-ColorRatios

Stap 6) is het verder aanpassen van de multipliers per kanaal om de ster en nevel kleuren naar smaak te krijgen. In dit proces wil je de histogrammen goed in de gaten houden en inzoomen op gebieden met veel sterren om de histogrammen te zien van die stergebieden. Er zijn een paar zaken die je kunnen helpen om tot een goede kleur calibratie te komen, dwz een calibratie die jij mooi vindt of die volgens jou "correct" is. - Om de sterren als geheel neutraal te maken moeten de histogrammen aan de rechterkant ongeveer een zelfde hoogte hebben/krijgen. - de pieken van de histogrammen moeten op ongeveer dezelde plek blijven. - en je wilt spelen met de kleur ratios R/G en B/G en proberen ratios te vinden zodat groen niet zichtbaar wordt, maar de boel ook niet te paars wordt. ( Ik schijn vaak een beetje paarse opnames te maken... dat ligt denk ik ook aan wat ik zelf mooi vind en dat is dus niet goed of fout in mijn optiek ). Dus na een tijdje spelen met de sliders per kanaal, ben ik tot het volgende resultaat gekomen, screenshot en een JPG als output.horsehead-LP-BG-crop-ColorRatiosHorsehead-lpc-cbg-crop-ColorRatios