Dank je @keesscherer, Hier is een screenshotje voor @mth75 met hoe ik initieel de kleur calibratie doe, daarna gebruik ik ook nog een selective color. Dit allemaal op de lineaire data, ook de selective color ;-) Eindresultaatjes komen eraan, een Lanczos3 resampling versie, een Bayer drizzle met 2x upscaling en 2 drizzle versies (2x en 3x) met verschillende drizzle kernels ;-) ColorCalibration

Dit maakte ik er met mijn eigen programma destijds van, (dat is wel aan een nieuwe bewerking toe geloof ik ;-) ): Stack-average-6474.697s-sigma clip_1_3.0-lanczos-3-reference-equal-RGB-BGlower-RGBFinal-crop-small

@buzzmeister, startools ken ik en heb ik geprobeerd vorig jaar geloof ik, ik heb zelfs uitvoerig contact gehad met Ivo Jager. Het is voor zover ik weet puur een post processing applicatie voor je stack. Maar ik kreeg nogal vreemde resultaten (en de resultaten die Ivo me stuurde vond ik ook niet heel bevredigend.) Ik heb er verder niet meer mee gespeeld. Misschien dat het nu mogelijk beter en verder ontwikkeld is? Dit kwam uit startools toen van 50mm data van ngc7000, gemaakt door Ivo zelf:Bula_NGC7000-starToolsTutorial-small

@joswennmacker-nl, alvast een sneak preview op 40subs: m42-josswennmacker-40subs

@joswennmacker-nl, mijn onedrive is je bestanden aan het synchroniseren, dat zal nog wel even duren. Maar ik heb alvast even gekeken wat er met een stack van 14subs gebeurd in Deep Sky Stacker. Dit zijn opnames verspreid uit alle 524 opnames.. Dat lijkt volgens mij allemaal goed te gaan met stacken, maar als het proces klaar is past DSS geen stretch toe. Ik dacht dat hij dat normaal wel doet, maar nu niet in ieder geval. Je moet de data zelf stretchen met de schuifjes, zie hieronder de screenshots met settings die ik heb ingesteld om M42 zichtbaar te maken in je stack ;-) dss-stretchparam2dss-stretchparam3dss-stretchparam1

@joswennmacker-nl, mijn onedrive is je bestanden aan het synchroniseren, dat zal nog wel even duren. Maar ik heb alvast even gekeken wat er met een stack van 14subs gebeurd in Deep Sky Stacker. Dit zijn opnames verspreid uit alle 524 opnames.. Dat lijkt volgens mij allemaal goed te gaan met stacken, maar als het proces klaar is past DSS geen stretch toe. Ik dacht dat hij dat normaal wel doet, maar nu niet in ieder geval. Je moet de data zelf stretchen met de schuifjes, zie hieronder de screenshots met settings die ik heb ingesteld om M42 zichtbaar te maken in je stack ;-) dss-stretchparam2dss-stretchparam3dss-stretchparam1

@joswennmacker-nl, mijn onedrive is je bestanden aan het synchroniseren, dat zal nog wel even duren. Maar ik heb alvast even gekeken wat er met een stack van 14subs gebeurd in Deep Sky Stacker. Dit zijn opnames verspreid uit alle 524 opnames.. Dat lijkt volgens mij allemaal goed te gaan met stacken, maar als het proces klaar is past DSS geen stretch toe. Ik dacht dat hij dat normaal wel doet, maar nu niet in ieder geval. Je moet de data zelf stretchen met de schuifjes, zie hieronder de screenshots met settings die ik heb ingesteld om M42 zichtbaar te maken in je stack ;-) dss-stretchparam2dss-stretchparam3dss-stretchparam1

En we zien aan de metadata dat er een hele oude DeepSkyStacker wordt gebruikt, versie 3.0. Ik zou adviseren om de laatste te downloaden dat is 3.3.2. http://deepskystacker.free.fr/english/index.html screenshotoriginaltiffjoswennmackermetadata

Hier een screenshot van de stretch op de originele TIFF van @joswennmacker-nl met het histogram erbij. Aan het histogram zie je meteen dat stretchen niet het enige probleem is: screenshotshotoriginaltiffjoswennmacker

Als laatste dit waarbij de achtergrond wordt geneutraliseerd, dan is het nog duidelijker: gestapeld-vc-cbg-stretch

gestapeld-vc-stretch

@joswennmacker-nl, ik heb hem gedownload, ik zie dat het een 16bits TIFF is. Dat is om te beginnen al niet optimaal. Je wilt de stack saven als een 32bits TIFF of FITS file. Ik heb je TIFF ingeladen in het stack programma dat ik zelf ontwikkel, mijn software maakt dit ervan met een automatische stretch: gestapeld-stretch

Zeker! Ben er blij mee, binnenkort de smalband filtertjes maar bestellen ;-) Ik heb al een paar belichtingen gedaan van 10minuten en de read noise, dark current met lichte amp glow is echt prima te calibreren. Ik zie bij mij heel licht wat amp glow aan de rechter boven- en onderkant. Zwaar gestretchte dark van 5minuten op gain 0 offset 10 (10 is 12bits, dus in 16bits is dat 160 en dat klopt): Indicatie van hoe sterk dit gestretcht is, de gaussische ruis in deze masterdark is 3,73 ADUs in 16bit, dat is minder dan 0,25 ADU  in 12bit. De masterdark is samengesteld uit 50 darks. De readnoise + dark current is dus veel lager! dan de shot noise van je opnames ;-) als je een paar minuten belicht. De sensor heeft ook erg weinig bad pixels. Statistiek uit mijn FITS header: EXPTIME =                300.0 / exposure time (s) MEAN    = ' 1,65E+02'          / mean of channel MED     = ' 1,65E+02'          / median of channel SIGMA   = ' 1,33E+01'          / standard deviation of channel NOISE   = ' 3,73E+00'          / MRS gaussian noise estimate of channelmasterdark-300s-gain0-offset10_-25c-asi1600mm-cool

Bij deze, eindelijk een first light van mijn nieuwe camera, de asi1600mm-cool ;-) met Baader LRGB filters. Elk kanaal is ongeveer 20x 5minuten belicht, dus dat wordt ongeveer 80x5 minuten = dik 6 uur belichting. Geschoten vanuit het centrum van Arnhem onder matige transparantie. Ik ben toch wel verbaasd over de hoeveelheid nevel die naar voren komt. Met mijn Nikon D5100 baader bcf mod, heb ik in het verleden m45 wel geprobeerd, maar ik kwam absoluut niet in de buurt van dit. Ook niet na veel langere integratietijden van dik 10 uur. Oftewel, ik ben overtuigd van de kracht van deze camera ;-) ! Takahashi TSA102 + TOA-35 0,7x op Avalon Linear Complete dataverwerking en post-processing met mijn eigen programma ;-) http://www.bulapedia.nl/images/m45/M45-LRGB-Mabula.jpgm45-lrgb-mabula-lq

Ik heb even bij mij gekeken. Volgens mij heb ik de verklaring. Dit zie ik zonder camera witbalans: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WhiteLedPanel-FLAT_TV16s_200iso-colorAndHistogram.jpg Met camera wit balans, in de screenshot zie je links dat ik camera witbalans aan heb gezet, ik kan ook de multipliers opzoeken ter bevestiging. De histogrammen zijn nu in ieder geval wel hetzelfde als in jouw screenshot: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WitPanelCameraWhiteBalanceLinear.jpg Of te wel, PI neemt de camera wit balans over. Dat wil je normaal gesproken niet. Dat is niet hoe de sensor de wereld ziet. Het gaat altijd ten koste van data die aan de rechterkant uit het histogram wordt gegooid, want de multipliers zijn bij wit balans altijd 1 of groter. zonder wit balans zijn ze 1 namelijk. En verklaring voor verschil in hoogte van histogram pieken, komt door log stretch in histogram lijkt het, dit zie ik zonder log: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WitPanelCameraWhiteBalanceLinear-nonLogHistogram.jpg Deze R,G,B, multipliers staan in FLAT_Tv16s_200iso_20161015-08h38m10s753ms.CR2 voor de camera witbalans: R = 2024.0 /1024  = 1,98 G1 = 1024.0 /1024 = 1 G2 = 1024.0 /1024 = 1 B = 1691.0 / 1024 = 1,65 Dus dat verklaard zeker het verschil als ik dit zo zie. R wordt 1,98x versterkt door WB setting... B 1,65x. Ik hoop dat je dat wel netjes kan uitzetten ergens. Voor de leuk een screenshot uit ontwikkel omgeving, http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/CameraWBOuput.jpg midden boven in de code zie je MatrixOperations.printVectorToOutput(RGGBasShot, "multi"); en in de console onderaan, zie je: multi 2024.0 1024.0 1024.0 1691.0 Een van de voordelen, van het schrijven van eigen raw converters ;-)

Ik heb even bij mij gekeken. Volgens mij heb ik de verklaring. Dit zie ik zonder camera witbalans: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WhiteLedPanel-FLAT_TV16s_200iso-colorAndHistogram.jpg Met camera wit balans, in de screenshot zie je links dat ik camera witbalans aan heb gezet, ik kan ook de multipliers opzoeken ter bevestiging. De histogrammen zijn nu in ieder geval wel hetzelfde als in jouw screenshot: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WitPanelCameraWhiteBalanceLinear.jpg Of te wel, PI neemt de camera wit balans over. Dat wil je normaal gesproken niet. Dat is niet hoe de sensor de wereld ziet. Het gaat altijd ten koste van data die aan de rechterkant uit het histogram wordt gegooid, want de multipliers zijn bij wit balans altijd 1 of groter. zonder wit balans zijn ze 1 namelijk. En verklaring voor verschil in hoogte van histogram pieken, komt door log stretch in histogram lijkt het, dit zie ik zonder log: http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/WitPanelCameraWhiteBalanceLinear-nonLogHistogram.jpg Deze R,G,B, multipliers staan in FLAT_Tv16s_200iso_20161015-08h38m10s753ms.CR2 voor de camera witbalans: R = 2024.0 /1024  = 1,98 G1 = 1024.0 /1024 = 1 G2 = 1024.0 /1024 = 1 B = 1691.0 / 1024 = 1,65 Dus dat verklaard zeker het verschil als ik dit zo zie. R wordt 1,98x versterkt door WB setting... B 1,65x. Ik hoop dat je dat wel netjes kan uitzetten ergens. Voor de leuk een screenshot uit ontwikkel omgeving, http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/CameraWBOuput.jpg midden boven in de code zie je MatrixOperations.printVectorToOutput(RGGBasShot, "multi"); en in de console onderaan, zie je: multi 2024.0 1024.0 1024.0 1691.0 Een van de voordelen, van het schrijven van eigen raw converters ;-)