Om de ruis beter te tonen zijn hier 3 ingezoomde screenshots uit APP, eerste is niet-gecalibreerd, 2de alleen gecalibreerd met een Bad Pixel Map, de derde volledig gecalirbeerd (MD, MF, BPM). Dit toont extreem goed dat een BPM heel veel kleinschalige ruis er al meteen uithaalt bij deze cmos camera's bij gebruik van narrowband filters. Er is geen enkele reden om niet een BPM te gebruiken ;-) en het verbetert je resultaten snel, sterk en makkelijk.M101-H-alpha-15min-3nm-uncalibratedM101-H-alpha-15min-3nm-onlyBPMM101-H-alpha-15min-3nm-calibrated

Om de ruis beter te tonen zijn hier 3 ingezoomde screenshots uit APP, eerste is niet-gecalibreerd, 2de alleen gecalibreerd met een Bad Pixel Map, de derde volledig gecalirbeerd (MD, MF, BPM). Dit toont extreem goed dat een BPM heel veel kleinschalige ruis er al meteen uithaalt bij deze cmos camera's bij gebruik van narrowband filters. Er is geen enkele reden om niet een BPM te gebruiken ;-) en het verbetert je resultaten snel, sterk en makkelijk.M101-H-alpha-15min-3nm-uncalibratedM101-H-alpha-15min-3nm-onlyBPMM101-H-alpha-15min-3nm-calibrated

Om de ruis beter te tonen zijn hier 3 ingezoomde screenshots uit APP, eerste is niet-gecalibreerd, 2de alleen gecalibreerd met een Bad Pixel Map, de derde volledig gecalirbeerd (MD, MF, BPM). Dit toont extreem goed dat een BPM heel veel kleinschalige ruis er al meteen uithaalt bij deze cmos camera's bij gebruik van narrowband filters. Er is geen enkele reden om niet een BPM te gebruiken ;-) en het verbetert je resultaten snel, sterk en makkelijk.M101-H-alpha-15min-3nm-uncalibratedM101-H-alpha-15min-3nm-onlyBPMM101-H-alpha-15min-3nm-calibrated

Calibrated met matching masterdark, BPM en MasterFlat:M101_900sec_H-alpha_0005_-15C-calibrated-St

Even een visueel voorbeeld met mijn asi1600mm-c: H-alpha exposure van 900 sec = 15min met een 3nm Astrodon H-a filter, Takahashi TSA102 @ F/5.6, M101 Uncalibrated opname, zoom in en wees verbaasd over de ruis en het aantal niet-lineaire (hot) pixels ! Juist met een smalband opname filter zie dit extreem goed. Ook de asi 1600mm-c heeft amp-glow...M101_900sec_H-alpha_0005_-15C-St

Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support

Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support

Astro Pixel Processor 1.055 is released ! Big upgrade, so please upgrade and check all details at: https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-055-ready-for-download/ Highlights of update: - big integrration speed increase for users which integrate on conventional (non-SSD) harddrives. Speed on SSD is also improved. - Added camera support for latest Canon models EOS 5Ds, EOS 5Ds R and EOS 5D Mark IV (Dual-Pixel Raw support). - improvements for the Bad Pixel Map - improvements in star analysis and registration modules - improved star color calibration module - improved auto DDP stretch for astroscapes Be aware: Trial users can upgrade as well within their trial license period. M51-calibratedM51-uncalibrated5DsR-support

Ik heb de minimum area select box in APP gezet op 16x16 pixels, ik kan het wel verlagen in de komende release, sta op het punt om hem uit te brengen. Moet er wel bijzeggen dat ik  data vol met nebulosity probleemloos gecorrigeerd krijg in APP. Te kleine boxjes is juist een probleem eerder. Je wilt genoeg data voor een goede statistiek. 16x16=256 is veel robuuster dan 4x4=16 pixel. De pixels uit die boxjes ondervinden iteratief outlier rejectie (daarom mag er ook gewoon een ster in een box aanwezig zijn) en met meer pixels krijg je een vele betere achtergrond waarde schatting. Om te corrigeren moet er altijd een model gemaakt worden. Dus dat model is aanwezig, mijn vraag is: wat is het nut om dat model te bekijken. Gebruik je het ergens voor? Of wil je dat zien om te vergelijken met een ander model, zodat je ziet waar de verschillen zitten? (De gecorrigeerde opname zegt in mijn ogen voldoende namelijk). Ik kan zeker wel opschrijven dat je met een vinkje ook het model zels als output krijgt, is dat een idee? Een voorbeeld, m42 H-alpha data met een Nikon D600 mono (courtesy of @yves Yves van den Broek) vol met neveligheid, geen probleem. Er zit zelfs een sensor probleem in de data die je er met APP dus uit krijgt bij dit soort data (zie rechter donker kolom): Plaatje voor en na correctie:D600-monoD600-mono-LP

Ik heb de minimum area select box in APP gezet op 16x16 pixels, ik kan het wel verlagen in de komende release, sta op het punt om hem uit te brengen. Moet er wel bijzeggen dat ik  data vol met nebulosity probleemloos gecorrigeerd krijg in APP. Te kleine boxjes is juist een probleem eerder. Je wilt genoeg data voor een goede statistiek. 16x16=256 is veel robuuster dan 4x4=16 pixel. De pixels uit die boxjes ondervinden iteratief outlier rejectie (daarom mag er ook gewoon een ster in een box aanwezig zijn) en met meer pixels krijg je een vele betere achtergrond waarde schatting. Om te corrigeren moet er altijd een model gemaakt worden. Dus dat model is aanwezig, mijn vraag is: wat is het nut om dat model te bekijken. Gebruik je het ergens voor? Of wil je dat zien om te vergelijken met een ander model, zodat je ziet waar de verschillen zitten? (De gecorrigeerde opname zegt in mijn ogen voldoende namelijk). Ik kan zeker wel opschrijven dat je met een vinkje ook het model zels als output krijgt, is dat een idee? Een voorbeeld, m42 H-alpha data met een Nikon D600 mono (courtesy of @yves Yves van den Broek) vol met neveligheid, geen probleem. Er zit zelfs een sensor probleem in de data die je er met APP dus uit krijgt bij dit soort data (zie rechter donker kolom): Plaatje voor en na correctie:D600-monoD600-mono-LP

Ik denk dat je met je RGB H-alpha en OIII data, allerlei verschillende versies kan maken met verschillende kleuren. Is misschien leuk om dat te bestuderen? Puur een RGB een bicolor narrowband en verschillende versies waarbij alle 5 data kanalen anders gewogen worden, ik denk dan aan Ha en OIII op verschillende manieren spreiden over de RGB kanalen waarbij de RGB kanalen hetzelfde blijven voor de sterkleuren. Dit kreeg ik er met APP vrij snel uit bijvoorbeeld, puur een composiet na registratie, verder geen andere processing behalve stretchen:combine-RGB-image-St

Hoi Rob en de rest ;-) Ik ben ook even aan het kijken naar de 4 kanalen die Rob heeft gedeeld. Deze 4 kanalen zijn al aan elkaar geregistreerd, als je registreert met dynamic distortion correction off, zie je dat ook meteen. Registration RMS is heel laag. Wat opvalt is dat als je dynamic distortion correction aan zet, het H-alpha kanaal een probleem oplevert. Daar zal ik zelf even dieper in duiken, want dat moet gewoon werken. Verder valt mij op de er geen BPM is gebruikt of niet afdoende outlier rejection, ik zie veel hot pixels. Maar die zullen de registratie niet beinvloeden, maar die moeten we makkelijk weg kunnen krijgen. Verder kijkend naar de ster vormen, de FWHM waardes. Er zit er een probleemje in het groene kanaal.. dat heeft duidelijk minder ronde sterren dan de andere kanalen. Daarom ga je onvermijdelijk bij de composiet combinatie chromatische abberatie zien. Maar verder kijkend naar de hoeken wordt meer duidelijk. Er zit een groot optisch probleem in de data. Er is of niet met een flattener dan wel reducer gewerkt of deze zat duidelijk niet op de goede afstand van de sensor. Dat is denk ik ook wat Kees constateert, het zal per golflengte andere afwijkingen gaan geven. Door de aberraties op de stervormen over het hele beeldveld krijg je mogelijk ook extra de chromatische aberratie te zien op verschillende plekken in het beeldveld. Dat komt omdat bij aberraties (zoals coma), de aanname dat de piek intensiteit overeenkomt met de ster lokatie, helemaal niet meer op gaat... Ik denk daarom dat dit vooral een data probleem is, niet zozeer een registratie of software probleem. 3 screenshots van de rechteronderhoek van de RGB kanalen laat het duidelijk zien. En nog een screenshot van een snelle (R-Halpha)GB met de saturatie flink aangezet van het midden van het beeldveld. De afwijking van de niet ronde groene sterren is evident. Om dit te corrigeren zal je photoshop technieken zoals selective color in kunnen zetten lijkt me. Dat is de laatste screenshot, (select green and add magenta to neutralize green.)Red-BottomRightGreen-BottomRightBlue-BottomRightRGBCombine-RHaGB-satRGBCombine-RHaGB-sat-SC

Hoi Rob en de rest ;-) Ik ben ook even aan het kijken naar de 4 kanalen die Rob heeft gedeeld. Deze 4 kanalen zijn al aan elkaar geregistreerd, als je registreert met dynamic distortion correction off, zie je dat ook meteen. Registration RMS is heel laag. Wat opvalt is dat als je dynamic distortion correction aan zet, het H-alpha kanaal een probleem oplevert. Daar zal ik zelf even dieper in duiken, want dat moet gewoon werken. Verder valt mij op de er geen BPM is gebruikt of niet afdoende outlier rejection, ik zie veel hot pixels. Maar die zullen de registratie niet beinvloeden, maar die moeten we makkelijk weg kunnen krijgen. Verder kijkend naar de ster vormen, de FWHM waardes. Er zit er een probleemje in het groene kanaal.. dat heeft duidelijk minder ronde sterren dan de andere kanalen. Daarom ga je onvermijdelijk bij de composiet combinatie chromatische abberatie zien. Maar verder kijkend naar de hoeken wordt meer duidelijk. Er zit een groot optisch probleem in de data. Er is of niet met een flattener dan wel reducer gewerkt of deze zat duidelijk niet op de goede afstand van de sensor. Dat is denk ik ook wat Kees constateert, het zal per golflengte andere afwijkingen gaan geven. Door de aberraties op de stervormen over het hele beeldveld krijg je mogelijk ook extra de chromatische aberratie te zien op verschillende plekken in het beeldveld. Dat komt omdat bij aberraties (zoals coma), de aanname dat de piek intensiteit overeenkomt met de ster lokatie, helemaal niet meer op gaat... Ik denk daarom dat dit vooral een data probleem is, niet zozeer een registratie of software probleem. 3 screenshots van de rechteronderhoek van de RGB kanalen laat het duidelijk zien. En nog een screenshot van een snelle (R-Halpha)GB met de saturatie flink aangezet van het midden van het beeldveld. De afwijking van de niet ronde groene sterren is evident. Om dit te corrigeren zal je photoshop technieken zoals selective color in kunnen zetten lijkt me. Dat is de laatste screenshot, (select green and add magenta to neutralize green.)Red-BottomRightGreen-BottomRightBlue-BottomRightRGBCombine-RHaGB-satRGBCombine-RHaGB-sat-SC

Hoi Rob en de rest ;-) Ik ben ook even aan het kijken naar de 4 kanalen die Rob heeft gedeeld. Deze 4 kanalen zijn al aan elkaar geregistreerd, als je registreert met dynamic distortion correction off, zie je dat ook meteen. Registration RMS is heel laag. Wat opvalt is dat als je dynamic distortion correction aan zet, het H-alpha kanaal een probleem oplevert. Daar zal ik zelf even dieper in duiken, want dat moet gewoon werken. Verder valt mij op de er geen BPM is gebruikt of niet afdoende outlier rejection, ik zie veel hot pixels. Maar die zullen de registratie niet beinvloeden, maar die moeten we makkelijk weg kunnen krijgen. Verder kijkend naar de ster vormen, de FWHM waardes. Er zit er een probleemje in het groene kanaal.. dat heeft duidelijk minder ronde sterren dan de andere kanalen. Daarom ga je onvermijdelijk bij de composiet combinatie chromatische abberatie zien. Maar verder kijkend naar de hoeken wordt meer duidelijk. Er zit een groot optisch probleem in de data. Er is of niet met een flattener dan wel reducer gewerkt of deze zat duidelijk niet op de goede afstand van de sensor. Dat is denk ik ook wat Kees constateert, het zal per golflengte andere afwijkingen gaan geven. Door de aberraties op de stervormen over het hele beeldveld krijg je mogelijk ook extra de chromatische aberratie te zien op verschillende plekken in het beeldveld. Dat komt omdat bij aberraties (zoals coma), de aanname dat de piek intensiteit overeenkomt met de ster lokatie, helemaal niet meer op gaat... Ik denk daarom dat dit vooral een data probleem is, niet zozeer een registratie of software probleem. 3 screenshots van de rechteronderhoek van de RGB kanalen laat het duidelijk zien. En nog een screenshot van een snelle (R-Halpha)GB met de saturatie flink aangezet van het midden van het beeldveld. De afwijking van de niet ronde groene sterren is evident. Om dit te corrigeren zal je photoshop technieken zoals selective color in kunnen zetten lijkt me. Dat is de laatste screenshot, (select green and add magenta to neutralize green.)Red-BottomRightGreen-BottomRightBlue-BottomRightRGBCombine-RHaGB-satRGBCombine-RHaGB-sat-SC

Hoi Rob en de rest ;-) Ik ben ook even aan het kijken naar de 4 kanalen die Rob heeft gedeeld. Deze 4 kanalen zijn al aan elkaar geregistreerd, als je registreert met dynamic distortion correction off, zie je dat ook meteen. Registration RMS is heel laag. Wat opvalt is dat als je dynamic distortion correction aan zet, het H-alpha kanaal een probleem oplevert. Daar zal ik zelf even dieper in duiken, want dat moet gewoon werken. Verder valt mij op de er geen BPM is gebruikt of niet afdoende outlier rejection, ik zie veel hot pixels. Maar die zullen de registratie niet beinvloeden, maar die moeten we makkelijk weg kunnen krijgen. Verder kijkend naar de ster vormen, de FWHM waardes. Er zit er een probleemje in het groene kanaal.. dat heeft duidelijk minder ronde sterren dan de andere kanalen. Daarom ga je onvermijdelijk bij de composiet combinatie chromatische abberatie zien. Maar verder kijkend naar de hoeken wordt meer duidelijk. Er zit een groot optisch probleem in de data. Er is of niet met een flattener dan wel reducer gewerkt of deze zat duidelijk niet op de goede afstand van de sensor. Dat is denk ik ook wat Kees constateert, het zal per golflengte andere afwijkingen gaan geven. Door de aberraties op de stervormen over het hele beeldveld krijg je mogelijk ook extra de chromatische aberratie te zien op verschillende plekken in het beeldveld. Dat komt omdat bij aberraties (zoals coma), de aanname dat de piek intensiteit overeenkomt met de ster lokatie, helemaal niet meer op gaat... Ik denk daarom dat dit vooral een data probleem is, niet zozeer een registratie of software probleem. 3 screenshots van de rechteronderhoek van de RGB kanalen laat het duidelijk zien. En nog een screenshot van een snelle (R-Halpha)GB met de saturatie flink aangezet van het midden van het beeldveld. De afwijking van de niet ronde groene sterren is evident. Om dit te corrigeren zal je photoshop technieken zoals selective color in kunnen zetten lijkt me. Dat is de laatste screenshot, (select green and add magenta to neutralize green.)Red-BottomRightGreen-BottomRightBlue-BottomRightRGBCombine-RHaGB-satRGBCombine-RHaGB-sat-SC

Hoi Rob en de rest ;-) Ik ben ook even aan het kijken naar de 4 kanalen die Rob heeft gedeeld. Deze 4 kanalen zijn al aan elkaar geregistreerd, als je registreert met dynamic distortion correction off, zie je dat ook meteen. Registration RMS is heel laag. Wat opvalt is dat als je dynamic distortion correction aan zet, het H-alpha kanaal een probleem oplevert. Daar zal ik zelf even dieper in duiken, want dat moet gewoon werken. Verder valt mij op de er geen BPM is gebruikt of niet afdoende outlier rejection, ik zie veel hot pixels. Maar die zullen de registratie niet beinvloeden, maar die moeten we makkelijk weg kunnen krijgen. Verder kijkend naar de ster vormen, de FWHM waardes. Er zit er een probleemje in het groene kanaal.. dat heeft duidelijk minder ronde sterren dan de andere kanalen. Daarom ga je onvermijdelijk bij de composiet combinatie chromatische abberatie zien. Maar verder kijkend naar de hoeken wordt meer duidelijk. Er zit een groot optisch probleem in de data. Er is of niet met een flattener dan wel reducer gewerkt of deze zat duidelijk niet op de goede afstand van de sensor. Dat is denk ik ook wat Kees constateert, het zal per golflengte andere afwijkingen gaan geven. Door de aberraties op de stervormen over het hele beeldveld krijg je mogelijk ook extra de chromatische aberratie te zien op verschillende plekken in het beeldveld. Dat komt omdat bij aberraties (zoals coma), de aanname dat de piek intensiteit overeenkomt met de ster lokatie, helemaal niet meer op gaat... Ik denk daarom dat dit vooral een data probleem is, niet zozeer een registratie of software probleem. 3 screenshots van de rechteronderhoek van de RGB kanalen laat het duidelijk zien. En nog een screenshot van een snelle (R-Halpha)GB met de saturatie flink aangezet van het midden van het beeldveld. De afwijking van de niet ronde groene sterren is evident. Om dit te corrigeren zal je photoshop technieken zoals selective color in kunnen zetten lijkt me. Dat is de laatste screenshot, (select green and add magenta to neutralize green.)Red-BottomRightGreen-BottomRightBlue-BottomRightRGBCombine-RHaGB-satRGBCombine-RHaGB-sat-SC

Het is belangrijk om het volgende in het achterhoofd te houden bij calibratie van je data: Afhankelijk van de sensor, zijn er meerdere wegen naar Rome: Als je een sensor hebt met duidelijke patronen in de dark current, zoals @ed-defesche, dan wil je zowel de lights als de flats met darks calibreren. Geen bias gebruiken en ook geen bias aftrekken van de darks, want dan krijg je ook problemen in de dark current calibratie. Als je darks gebruikt, gewoon geen bias gebruiken, dat is altijd subtoptimaal en je stelt je calibratie open voor fouten. Altijd een BPM gebruiken, welk calibratie pad je ook volgt voor lights dan wel flats. Heb je een sensor met geen duidelijke patronen in de dark current en geen duidelijke amp-glow. Dan is het interessant om darks achterwege te laten en enkel te calibreren met bias, bpm voor flats en bias, bpm flats voor de lights. Hoe weet je of je dark calirbatie moet toepassen vanwege duidelijke dark current en/of amp-glow: Maak een masterbias uit een N-tal bias frames en een masterdark uit een gelijk aantal darks waar je geen masterbias aftrekt. Vergelijk de 2 met een even sterke stretch, zie je andere patronen in de master dark dan in de masterbias, zoals andere horizontale/verticale strepen of een verschijnende amp-glow dan wil je dark calibratie toepassen. Een voorbeeld van Ed: de master bias en de masterdark beiden gelijk gestretcht, in de masterdark verschijnen opeens strepen die je in de masterbias niet ziet. Dus dark calibratie wordt hierdoor bijna een must, met heel aggresieve dithering (20-40 pixels) en veel opnames kan je het mogelijk bij bias laten, maar anders niet. Het calibratie filmpje van Sara Wager is een voorbeeld waarin bias calibratie voldoende is, daarom laat Sara de darks achterwege.APP-ED-MB-strongStretchAPP-ED-MD-strongStretch

Het is belangrijk om het volgende in het achterhoofd te houden bij calibratie van je data: Afhankelijk van de sensor, zijn er meerdere wegen naar Rome: Als je een sensor hebt met duidelijke patronen in de dark current, zoals @ed-defesche, dan wil je zowel de lights als de flats met darks calibreren. Geen bias gebruiken en ook geen bias aftrekken van de darks, want dan krijg je ook problemen in de dark current calibratie. Als je darks gebruikt, gewoon geen bias gebruiken, dat is altijd subtoptimaal en je stelt je calibratie open voor fouten. Altijd een BPM gebruiken, welk calibratie pad je ook volgt voor lights dan wel flats. Heb je een sensor met geen duidelijke patronen in de dark current en geen duidelijke amp-glow. Dan is het interessant om darks achterwege te laten en enkel te calibreren met bias, bpm voor flats en bias, bpm flats voor de lights. Hoe weet je of je dark calirbatie moet toepassen vanwege duidelijke dark current en/of amp-glow: Maak een masterbias uit een N-tal bias frames en een masterdark uit een gelijk aantal darks waar je geen masterbias aftrekt. Vergelijk de 2 met een even sterke stretch, zie je andere patronen in de master dark dan in de masterbias, zoals andere horizontale/verticale strepen of een verschijnende amp-glow dan wil je dark calibratie toepassen. Een voorbeeld van Ed: de master bias en de masterdark beiden gelijk gestretcht, in de masterdark verschijnen opeens strepen die je in de masterbias niet ziet. Dus dark calibratie wordt hierdoor bijna een must, met heel aggresieve dithering (20-40 pixels) en veel opnames kan je het mogelijk bij bias laten, maar anders niet. Het calibratie filmpje van Sara Wager is een voorbeeld waarin bias calibratie voldoende is, daarom laat Sara de darks achterwege.APP-ED-MB-strongStretchAPP-ED-MD-strongStretch

Wat is nu de oplossing voor je data? Vanwege bovenstaande bevindingen, zul je de beste calibratie van je light frames halen als je zo goed als mogelijk dark calibratie doet. Maak geen masterbias, enkel een masterdark uit een set darks en trek daar geen masterbias vanaf. Als je flats gaat gebruiken, idem voor het beste resultaat, geen bias, maar dark flats maken, dus darks die matchen qua exposure en ISO met je flats. Zie screenshot van een gecalibreerde light met een BPM en de Masterdark waar we geen bias vanaf hebben gehaald. Ik zie nu 2 afzonderlijk problemen die beiden op te lossen zijn en waarmee de kwaliteit van je opnames vooruit zal gaan. Het zwart punt van deze stretch is 0, kan niet lager, je ziet aan het histogram dan ook dat de histogram pieken helemaal niet zijn los gekomen van de linkerkant van het histogram. Daarom krijg je ook nu geen optimale data calibratie en is je data ruizig. Met name het rode kanaal is heel zwak. Dit komt vermoedelijk door het LP filter dat je gebruikt. Nu wil je natuurlijk de lichtvervuiling in de buurt blokkeren, dus dat gebeurd, maar je zult moeten zorgen dat je wat langer belicht om de histogrammen los te doen komen van de linkerkant. Dus langer belichten met een guider zal een flinke verbetering teweeg brengen. Mogelijk is het specifieke LP filter voor jouw omstandigheden en belichtingstijden te agressief. Het rode kanaal is natuurlijk interessant voor de waterstof signalen uit de ruimte, en er komt gewoon erg weinig rood licht op de sensor, zeker als je het vergelijkt met de groene en blauwe signalen. Ik weet dit nu niet zeker hoor, maar het is een gedachte die bij me opkomt kijkend naar de histogrammen. Misschien zijn de opnames wel gemaakt met een volle maan, en de lucht is gewoon veel blauwer op dat moment dus er komt meer blauw binnen.  APP-ED-Light-BPM-MasterDark

Ter illustratie van dit probleem maak ik nu een masterdark waar de bias is afgetrokken. Dat betekent dat ik darks inlaad met de gemaakt masterbias en dan de masterdark maak, dan zie je bij de darks een B staan in de frame column ten teken dat de bias eraf wordt gehaald. Kijk even goed naar de mean en median waardes van deze masterdark en vergelijk ze met de bovenstaande waardes van de masterbias en masterdark. Je zult zien, dan deze masterdark het verschil is tussen die 2. De masterbias is namelijk van de darks afgetrokken. De mean en median van deze masterdark is bijna 0. Belangrijkste is nu omte constateren dat het histogram van deze masterdark niet volledig is, de peak is links afgekapt en omdat je significante signalen in de dark current hebt zal deze masterdark waar de bias vanaf is gehaald nooit voldoen om de dark signalen goed te calibreren. (Omdat de histogram peak niet volledig is, maar afgekapt is "mis je data" om de dark current goed te kunnen calibreren.) FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T12:17:31' / creation date of master dark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master dark' / master dark frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 60.0 / exposure time (s) HDU1 - MEAN-R = ' 4,02E+00' / mean of channel-R HDU1 - MEAN-G1 = ' 4,16E+00' / mean of channel-G1 HDU1 - MEAN-G2 = ' 4,22E+00' / mean of channel-G2 HDU1 - MEAN-B = ' 4,33E+00' / mean of channel-B HDU1 - MED-R = ' 1,00E+00' / median of channel-R HDU1 - MED-G1 = ' 1,00E+00' / median of channel-G1 HDU1 - MED-G2 = ' 1,00E+00' / median of channel-G2 HDU1 - MED-B = ' 1,00E+00' / median of channel-B HDU1 - SIGMA-R = ' 1,93E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 2,03E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,87E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 2,19E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 5,18E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 5,34E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 5,26E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 5,38E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MD-minusMBAPP-ED-MD-minusMB-header

Ter illustratie van dit probleem maak ik nu een masterdark waar de bias is afgetrokken. Dat betekent dat ik darks inlaad met de gemaakt masterbias en dan de masterdark maak, dan zie je bij de darks een B staan in de frame column ten teken dat de bias eraf wordt gehaald. Kijk even goed naar de mean en median waardes van deze masterdark en vergelijk ze met de bovenstaande waardes van de masterbias en masterdark. Je zult zien, dan deze masterdark het verschil is tussen die 2. De masterbias is namelijk van de darks afgetrokken. De mean en median van deze masterdark is bijna 0. Belangrijkste is nu omte constateren dat het histogram van deze masterdark niet volledig is, de peak is links afgekapt en omdat je significante signalen in de dark current hebt zal deze masterdark waar de bias vanaf is gehaald nooit voldoen om de dark signalen goed te calibreren. (Omdat de histogram peak niet volledig is, maar afgekapt is "mis je data" om de dark current goed te kunnen calibreren.) FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T12:17:31' / creation date of master dark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master dark' / master dark frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 60.0 / exposure time (s) HDU1 - MEAN-R = ' 4,02E+00' / mean of channel-R HDU1 - MEAN-G1 = ' 4,16E+00' / mean of channel-G1 HDU1 - MEAN-G2 = ' 4,22E+00' / mean of channel-G2 HDU1 - MEAN-B = ' 4,33E+00' / mean of channel-B HDU1 - MED-R = ' 1,00E+00' / median of channel-R HDU1 - MED-G1 = ' 1,00E+00' / median of channel-G1 HDU1 - MED-G2 = ' 1,00E+00' / median of channel-G2 HDU1 - MED-B = ' 1,00E+00' / median of channel-B HDU1 - SIGMA-R = ' 1,93E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 2,03E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,87E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 2,19E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 5,18E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 5,34E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 5,26E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 5,38E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MD-minusMBAPP-ED-MD-minusMB-header

Voor de duidelijkheid 2 JPGs van een sterk gestrechte Masterbias en de Masterdark met identieke stretch. Je ziet verticale strepen van het uitleespatroon van je sensor (het bias signaal) in beide JPGS en in de Masterdark komen daar horizontale strepen bij van de dark current van je sensor. Als je goed de JPGs vergelijkt zul je meer verschillen zien in de horizontale en verticale strepen tussen de master bias en de master dark. Omdat de uitlees signalen van de sensor en de dark current in de sensor verschillen vertonen middels vaste patronen ontkom je er niet aan om te focussen op goede dark calibratie van je opnames. Of je moet opnames gaan maken met aggresieve dithering van 10-tallen pixels (20-40 pixels) dan kan je het middels integratie meestal ook goed oplossen.MB-strongStretchMD-strongStretch

Voor de duidelijkheid 2 JPGs van een sterk gestrechte Masterbias en de Masterdark met identieke stretch. Je ziet verticale strepen van het uitleespatroon van je sensor (het bias signaal) in beide JPGS en in de Masterdark komen daar horizontale strepen bij van de dark current van je sensor. Als je goed de JPGs vergelijkt zul je meer verschillen zien in de horizontale en verticale strepen tussen de master bias en de master dark. Omdat de uitlees signalen van de sensor en de dark current in de sensor verschillen vertonen middels vaste patronen ontkom je er niet aan om te focussen op goede dark calibratie van je opnames. Of je moet opnames gaan maken met aggresieve dithering van 10-tallen pixels (20-40 pixels) dan kan je het middels integratie meestal ook goed oplossen.MB-strongStretchMD-strongStretch

Nu gaan we kijken naar een masterdark, gemaak uit enkel de 5 darks van 60 seconden; Het eerste plaatje toont de masterdark met dezelfde preview filter settings als de masterbias, dus je ziet dat de master dark vrijwel hetzelfde is, dat verwacht je ook. De bias zit in elk frame, dus ook in de dark, de dark heeft net wat hogere waardes voor de standard deviatie (SIGMA) en de noise, dat is een utiing van toenemende ruis en dark current in de dark bovenop het signaal van het bias signaal weermee elke opname begint. De laatste foto toont de master darks flink gestretcht. Hierin zie je nu de horizontale strepen verschijnen. Dus het is daarom duidelijk dat deze strepen in de dark current zitten en niet in het bias signaal van de sensor in je camera. FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:55:23' / creation date of master dark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master dark' / master dark frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 60.0 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 2,06E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 2,17E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,99E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 2,30E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 8,72E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 9,01E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 8,46E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 8,67E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MDAPP-ED-MD-headerAPP-ED-MD-strongStretch

Nu gaan we kijken naar een masterdark, gemaak uit enkel de 5 darks van 60 seconden; Het eerste plaatje toont de masterdark met dezelfde preview filter settings als de masterbias, dus je ziet dat de master dark vrijwel hetzelfde is, dat verwacht je ook. De bias zit in elk frame, dus ook in de dark, de dark heeft net wat hogere waardes voor de standard deviatie (SIGMA) en de noise, dat is een utiing van toenemende ruis en dark current in de dark bovenop het signaal van het bias signaal weermee elke opname begint. De laatste foto toont de master darks flink gestretcht. Hierin zie je nu de horizontale strepen verschijnen. Dus het is daarom duidelijk dat deze strepen in de dark current zitten en niet in het bias signaal van de sensor in je camera. FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:55:23' / creation date of master dark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master dark' / master dark frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 60.0 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 2,06E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 2,17E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,99E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 2,30E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 8,72E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 9,01E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 8,46E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 8,67E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MDAPP-ED-MD-headerAPP-ED-MD-strongStretch

Nu gaan we kijken naar een masterdark, gemaak uit enkel de 5 darks van 60 seconden; Het eerste plaatje toont de masterdark met dezelfde preview filter settings als de masterbias, dus je ziet dat de master dark vrijwel hetzelfde is, dat verwacht je ook. De bias zit in elk frame, dus ook in de dark, de dark heeft net wat hogere waardes voor de standard deviatie (SIGMA) en de noise, dat is een utiing van toenemende ruis en dark current in de dark bovenop het signaal van het bias signaal weermee elke opname begint. De laatste foto toont de master darks flink gestretcht. Hierin zie je nu de horizontale strepen verschijnen. Dus het is daarom duidelijk dat deze strepen in de dark current zitten en niet in het bias signaal van de sensor in je camera. FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:55:23' / creation date of master dark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master dark' / master dark frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 60.0 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 2,06E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 2,17E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,99E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 2,30E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 8,72E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 9,01E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 8,46E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 8,67E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MDAPP-ED-MD-headerAPP-ED-MD-strongStretch

Hoi Ed, bij deze de uitleg over calibratie van je light frames die uit je EOS 550D komen: Allereerst bekijken we de bias frames en de masterbias die we daaruit kunnen maken. Zie screenshot van de masterbias van 5 bias frames. Deze masterbias heeft in 16bit een Bias pedestal/offset van ongeveer 8000 ADU (zie de bovenste slider waarmee je zwart punt zet). In 14bit is dit 4 keer zo laag, de statistiek van de 14bits data van de masterbias staat in de fits header, dus daarin zie je dat de bias offset in 14bits net iets boven 2000 ADU ligt: FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:47:31' / creation date of master bias HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master bias' / master bias frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 0.00025 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 7,78E+00' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 7,95E+00' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 7,43E+00' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 7,58E+00' / standard deviation of channel-B HDU1 - NOISE-R = ' 7,43E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 7,62E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 7,20E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 7,33E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MBAPP-ED-MB-headerAPP-ED-MB-strongStretch

Hoi Ed, bij deze de uitleg over calibratie van je light frames die uit je EOS 550D komen: Allereerst bekijken we de bias frames en de masterbias die we daaruit kunnen maken. Zie screenshot van de masterbias van 5 bias frames. Deze masterbias heeft in 16bit een Bias pedestal/offset van ongeveer 8000 ADU (zie de bovenste slider waarmee je zwart punt zet). In 14bit is dit 4 keer zo laag, de statistiek van de 14bits data van de masterbias staat in de fits header, dus daarin zie je dat de bias offset in 14bits net iets boven 2000 ADU ligt: FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:47:31' / creation date of master bias HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master bias' / master bias frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 0.00025 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 7,78E+00' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 7,95E+00' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 7,43E+00' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 7,58E+00' / standard deviation of channel-B HDU1 - NOISE-R = ' 7,43E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 7,62E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 7,20E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 7,33E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MBAPP-ED-MB-headerAPP-ED-MB-strongStretch

Hoi Ed, bij deze de uitleg over calibratie van je light frames die uit je EOS 550D komen: Allereerst bekijken we de bias frames en de masterbias die we daaruit kunnen maken. Zie screenshot van de masterbias van 5 bias frames. Deze masterbias heeft in 16bit een Bias pedestal/offset van ongeveer 8000 ADU (zie de bovenste slider waarmee je zwart punt zet). In 14bit is dit 4 keer zo laag, de statistiek van de 14bits data van de masterbias staat in de fits header, dus daarin zie je dat de bias offset in 14bits net iets boven 2000 ADU ligt: FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jul 04 13:47:31 CEST 2017 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 5344 / size of the n'th axis HDU1 - NAXIS2 = 3516 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 4.000183116645303 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2017-07-04T11:47:31' / creation date of master bias HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.048 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'master bias' / master bias frame HDU1 - INSTRUME= 'CANON EOS 550D' / instrument name HDU1 - CFAIMAGE= 'GBRG ' / Color Filter Array pattern HDU1 - GAIN = 800.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 0.00025 / exposure time (s) HDU1 - MEAN-R = ' 2,05E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 2,05E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 2,05E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 2,05E+03' / mean of channel-B HDU1 - MED-R = ' 2,05E+03' / median of channel-R HDU1 - MED-G1 = ' 2,05E+03' / median of channel-G1 HDU1 - MED-G2 = ' 2,05E+03' / median of channel-G2 HDU1 - MED-B = ' 2,05E+03' / median of channel-B HDU1 - SIGMA-R = ' 7,78E+00' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 7,95E+00' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 7,43E+00' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 7,58E+00' / standard deviation of channel-B HDU1 - NOISE-R = ' 7,43E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 7,62E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 7,20E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 7,33E+00' / MRS gaussian noise estimate of channel-B HDU1 - ENDAPP-ED-MBAPP-ED-MB-headerAPP-ED-MB-strongStretch

Hoi Ed, Ik heb je data bekeken en gecalibreerd met de bias en darks die je had aangeleverd. Mijn vermoeden is bevestigd, je hebt zeker geen canon banding script nodig om de horizontale strepen uit de lights te halen. Je hebt enkel de juiste calibratie workflow nodig ;-) Dit zijn je 5 lights gecalibreerd en geintegreerd in APP, vrijwel geen horizontale strepen meer te zien ;-) ik heb maar 5 darks gebruikt, als je er meer toepast dan zal het vrijwel helemaal verdwijnen, dat in combinatie met wat ditheren tussen de opnames en het is volledig weg. De strepen zitten in je dark current. Dus je moet echt dark calibratie goed doen bij deze camera. Ik moet even de deur uit, als ik terug ben zal ik precies uitleggen hoe, wat en waarom. Maar alvast de JPG vrijwel zonder horizontale strepen (1ste foto), zeker vergeleken met je oorspronkelijke integratie, (dat is de 2de foto):St-med-300.0s-NR-x_1.0_LZ3-NS-full-eq-add-sc_BWMV_nor-AA-RL-MBB5_1stLNC_it2-St-LQoriginalStack

Hoi Ed, Ik heb je data bekeken en gecalibreerd met de bias en darks die je had aangeleverd. Mijn vermoeden is bevestigd, je hebt zeker geen canon banding script nodig om de horizontale strepen uit de lights te halen. Je hebt enkel de juiste calibratie workflow nodig ;-) Dit zijn je 5 lights gecalibreerd en geintegreerd in APP, vrijwel geen horizontale strepen meer te zien ;-) ik heb maar 5 darks gebruikt, als je er meer toepast dan zal het vrijwel helemaal verdwijnen, dat in combinatie met wat ditheren tussen de opnames en het is volledig weg. De strepen zitten in je dark current. Dus je moet echt dark calibratie goed doen bij deze camera. Ik moet even de deur uit, als ik terug ben zal ik precies uitleggen hoe, wat en waarom. Maar alvast de JPG vrijwel zonder horizontale strepen (1ste foto), zeker vergeleken met je oorspronkelijke integratie, (dat is de 2de foto):St-med-300.0s-NR-x_1.0_LZ3-NS-full-eq-add-sc_BWMV_nor-AA-RL-MBB5_1stLNC_it2-St-LQoriginalStack

En nog even gekeken naar de JPGs die je had gepost, ik was geinterresseerd in hoe de histogrammen zijn, aan de histogrammen is duidelijk te zien dat de PI bewerking nogal overshoot naar het blauw denk ik, wat ik op basis van de kleurcalibratie en de data niet kan verklaren. Wat beter is? Ik denk zelf dat de PI versie veel te blauw is. PI killed rood of boost blauw in je bewerkingen die je in PI hebt gedaan (ik denk dat rood wordt gekilled). Misschien hebt je na de kleurcalibratie nog anders tools gebruikt die dat kunnen verklaren? Wat ik ook vreemd vind, is dat ik in je JPGs geen horizontale banden meer zie? terwijl ze in de stack evident zijn. MabulaEdd-appEdd-appPI

En nog even gekeken naar de JPGs die je had gepost, ik was geinterresseerd in hoe de histogrammen zijn, aan de histogrammen is duidelijk te zien dat de PI bewerking nogal overshoot naar het blauw denk ik, wat ik op basis van de kleurcalibratie en de data niet kan verklaren. Wat beter is? Ik denk zelf dat de PI versie veel te blauw is. PI killed rood of boost blauw in je bewerkingen die je in PI hebt gedaan (ik denk dat rood wordt gekilled). Misschien hebt je na de kleurcalibratie nog anders tools gebruikt die dat kunnen verklaren? Wat ik ook vreemd vind, is dat ik in je JPGs geen horizontale banden meer zie? terwijl ze in de stack evident zijn. MabulaEdd-appEdd-appPI

En hier nog een JPG, waarin je goed kan zien, dat er horizontale strepen in je data zitten die er met calibratie uit zouden moeten gaan denk ik:Ed-badBiasDarkCalibration

Hoi Ed, ik heb naar je stack gekeken, wat valt mij op: - ik denk dat er iets niet goed gaat in je bias en/of dark calibratie, in je stack zijn duidelijk horizontale lijnen te zien van ofwel de read noise patronen van je sensor of de vaste patronen van de dark current. De lijnen kunnen dus zowel in de bias  als wel de dark current zitten. Dus ik denk dat er hier sterk winst te behalen valt ;-) als we dit kunnen oplossen. - ik krijg min of meer hetzelfde resultaat als jou na remove light pollution, calibrate background, star color calibration en selective color. Waarom het resultaat van PI zo blauw wordt is voor mij op basis van de data niet duidelijk, mogelijk doet PI de kleurcalirbatie middels je histogram en in dit geval is dat denk ik niet goed, maar ik weet het niet zeker moet ik bekennen. - het rode kanaal in je stack is het slechtste/zwakste kanaal, na achtergrond calibratie krijg je daarom een veel breder histogram voor het rode kanaal tov het blauwe en groene kanaal. Ik zou denken dat je mogelijk een filter hebt gebruikt wat veel rood licht heeft tegengehouden en mogelijk meer dan je lief is? Heb je een LPS filter of iets dergelijks gebruikt? Wat plaatjes van mijn bevindingen met histogrammen erbij:Ed-RoodZwakEd-RoodZwak-NBGAPP-SC-HistogramAPP-SC-Histogram-BlauwStrong

Hoi Ed, ik heb naar je stack gekeken, wat valt mij op: - ik denk dat er iets niet goed gaat in je bias en/of dark calibratie, in je stack zijn duidelijk horizontale lijnen te zien van ofwel de read noise patronen van je sensor of de vaste patronen van de dark current. De lijnen kunnen dus zowel in de bias  als wel de dark current zitten. Dus ik denk dat er hier sterk winst te behalen valt ;-) als we dit kunnen oplossen. - ik krijg min of meer hetzelfde resultaat als jou na remove light pollution, calibrate background, star color calibration en selective color. Waarom het resultaat van PI zo blauw wordt is voor mij op basis van de data niet duidelijk, mogelijk doet PI de kleurcalirbatie middels je histogram en in dit geval is dat denk ik niet goed, maar ik weet het niet zeker moet ik bekennen. - het rode kanaal in je stack is het slechtste/zwakste kanaal, na achtergrond calibratie krijg je daarom een veel breder histogram voor het rode kanaal tov het blauwe en groene kanaal. Ik zou denken dat je mogelijk een filter hebt gebruikt wat veel rood licht heeft tegengehouden en mogelijk meer dan je lief is? Heb je een LPS filter of iets dergelijks gebruikt? Wat plaatjes van mijn bevindingen met histogrammen erbij:Ed-RoodZwakEd-RoodZwak-NBGAPP-SC-HistogramAPP-SC-Histogram-BlauwStrong

Hoi Ed, ik heb naar je stack gekeken, wat valt mij op: - ik denk dat er iets niet goed gaat in je bias en/of dark calibratie, in je stack zijn duidelijk horizontale lijnen te zien van ofwel de read noise patronen van je sensor of de vaste patronen van de dark current. De lijnen kunnen dus zowel in de bias  als wel de dark current zitten. Dus ik denk dat er hier sterk winst te behalen valt ;-) als we dit kunnen oplossen. - ik krijg min of meer hetzelfde resultaat als jou na remove light pollution, calibrate background, star color calibration en selective color. Waarom het resultaat van PI zo blauw wordt is voor mij op basis van de data niet duidelijk, mogelijk doet PI de kleurcalirbatie middels je histogram en in dit geval is dat denk ik niet goed, maar ik weet het niet zeker moet ik bekennen. - het rode kanaal in je stack is het slechtste/zwakste kanaal, na achtergrond calibratie krijg je daarom een veel breder histogram voor het rode kanaal tov het blauwe en groene kanaal. Ik zou denken dat je mogelijk een filter hebt gebruikt wat veel rood licht heeft tegengehouden en mogelijk meer dan je lief is? Heb je een LPS filter of iets dergelijks gebruikt? Wat plaatjes van mijn bevindingen met histogrammen erbij:Ed-RoodZwakEd-RoodZwak-NBGAPP-SC-HistogramAPP-SC-Histogram-BlauwStrong

Hoi Ed, ik heb naar je stack gekeken, wat valt mij op: - ik denk dat er iets niet goed gaat in je bias en/of dark calibratie, in je stack zijn duidelijk horizontale lijnen te zien van ofwel de read noise patronen van je sensor of de vaste patronen van de dark current. De lijnen kunnen dus zowel in de bias  als wel de dark current zitten. Dus ik denk dat er hier sterk winst te behalen valt ;-) als we dit kunnen oplossen. - ik krijg min of meer hetzelfde resultaat als jou na remove light pollution, calibrate background, star color calibration en selective color. Waarom het resultaat van PI zo blauw wordt is voor mij op basis van de data niet duidelijk, mogelijk doet PI de kleurcalirbatie middels je histogram en in dit geval is dat denk ik niet goed, maar ik weet het niet zeker moet ik bekennen. - het rode kanaal in je stack is het slechtste/zwakste kanaal, na achtergrond calibratie krijg je daarom een veel breder histogram voor het rode kanaal tov het blauwe en groene kanaal. Ik zou denken dat je mogelijk een filter hebt gebruikt wat veel rood licht heeft tegengehouden en mogelijk meer dan je lief is? Heb je een LPS filter of iets dergelijks gebruikt? Wat plaatjes van mijn bevindingen met histogrammen erbij:Ed-RoodZwakEd-RoodZwak-NBGAPP-SC-HistogramAPP-SC-Histogram-BlauwStrong

Dank voor je antwoord. Toch zie ik dat meningen hieromtrent verdeeld zijn (mits ik ze verkeerd interpreteer). In een gevonden artikel wordt gesteld dat dark current ook optreedt wanneer de sluiter gesloten is (bij het maken van darks);

PixInsight DSLR Workflow – Part 2a, Dark Frames

(zie eerste pagina). Misschien dat ik het eens moet uitproberen mét en zónder bias?. Echter mijn kennis van APP is denk ik nog te pril. Ik weet bijvoorbeeld niet hoe je een masterdark moet betrekken in de processtappen 1 t/m 6 binnen APP. Weet APP dat je deze hebt aangemaakt of moet je dat ergens kenbaar maken? Nog steeds merk ik ook dat afhankelijk van het gebruikte scherm het resultaat nogal divers is bij het bekijken. Mijn m42 zag er op de “aanmaak-computer” voor mij best goed uit. Maar nu ik hem op een andere computer (en scherm) bekijk, schrik ik een beetje van het resultaat (qua kleuren, hardheid etc). Klopt helemaal, dark current heb je altijd ;-) als de sluiter ook maar even open staat. Ook bij het maken van darks, dat is dan ook de reden waarom je darks moet maken als je een sensor in je camera hebt die een duidelijk dark current heeft met patronen (Fixed Pattern Noise) daarin. Het is belangrijk om te realiseren dat als je enkel een masterdark maakt van darks, dat je dan een masterdark hebt waarin de Bias Pedestal of Voet nog zit. Ik heb dit opgeschreven in een post op mijn forum. Als je die masterdark gebruikt voor calibratie van een light (of een flat) dan calibreer je zowel de read noise patronen uit je bias als wel de dark current patronen uit de dark. Dit komt omdat de bias in elke opname zit, dus ook in een Masterdark die bestaat uit een set dark frames waar geen MasterBias is vanaf getrokken. Ik heb alles opgeschreven in deze 2 links, een goed begrip van de Bias Pedestal doet wonderen voor je data calibratie, dus ik raad deze link sterk aan om goed te lezen: https://www.astropixelprocessor.com/community/tutorials-workflows/what-is-the-bias-pedestal-and-why-does-it-matter/ En een uitleg over de calibratie regels: https://www.astropixelprocessor.com/community/tutorials-workflows/astronomical-data-calibration-priciples-must-read/ Laat het me vooral weten als iets niet duidelijk is ;-)

"Ik weet bijvoorbeeld niet hoe je een masterdark moet betrekken in de processtappen 1 t/m 6 binnen APP. Weet APP dat je deze hebt aangemaakt of moet je dat ergens kenbaar maken?"

Misschien dat dit filmpje van Sara Wager dat verheldert? https://www.astropixelprocessor.com/getting-started-with-astro-pixel-processor-by-sara-wager/ En anders zal ik er werk van maken om dit netjes in een video tutorial uit te leggen ;-), laat maar weten of het duidelijker wordt of niet.

"Nog steeds merk ik ook dat afhankelijk van het gebruikte scherm het resultaat nogal divers is bij het bekijken. Mijn m42 zag er op de “aanmaak-computer” voor mij best goed uit. Maar nu ik hem op een andere computer (en scherm) bekijk, schrik ik een beetje van het resultaat (qua kleuren, hardheid etc)."

Aangezien APP voor het opslaan van kleuren foto's in JPG en TIFF formaat volledig werkt met ICC color management profiles, zal de oorzaak hiervan moeten liggen in het ontbreken van goede calibratie van deze verschillende computer schermen. Color management gebeurd op hardware en ook op software niveau. Dat betekent dat je zelf moet verifieren dat op de computer een correct ICC profiel is geinstalleerd voor de monitor (hardware color management) en als je bijvoorbeeld een plaatje bekijkt in een browser (software color management) moet je verifieren dat de browser gebruik maakt van ICC profielen die in de meta data zit van foto's. Firefox op windows bijvoorbeeld doet dit standaard niet. Gebruikers van Mac computers zijn hierin in het voordeel, want daar gebeurd dat vrijwel altijd correct. Op Windows moet je echt op letten. Ook de simpele image viewer van windows 7 zelf bijvoorbeeld interpreteert geen ICC profielen... Een voorbeeld: ik laat dezelfde foto in, in de windows foto viewer en in XnView dat perfect omgaat met ICC color management profielen. Plaatje is mijn logo dat ook een ICC profiel bevat, je ziet dat windows het compleet fout laat zien en XnView goed... en dat dat verschil heel groot kan zijn. Bovenaan de 2 windows kan je zien dat beide applicaties precies dezelfde PNG hebben geladen, maar het toch heel anders laten zien. Dat komt volledig door ICC color management.SoftwareICCColorManagement