Flat correction in One Shot colour work flow?

[mcgillca]

Hi - I recently got a one shot colour camera to use with a mobile scope (I normally use a mono camera and filter wheel).

While I've been getting images that are not bad for a suburban location outside of London, I've been struggling with the colour balance - my images are looking too red.

I've spent the morning trying to work out why - turns out that for whatever reason, the red pixels in my flats have about half the exposure of the green and blue pixels. As a result, when the flat is applied, the red pixels are scaled to about twice the value of the blue and green pixels - this seems to persist through colour calibration.

I enclose two images of M31 - the first using the standard flats and about 5 hours of data - as you can see, the image is pretty good, but there is a red/brown tinge to the galaxy, hardly any blue at all.

For the second, I used Python to multiply red pixels by a constant amount in the flat so that the median value was about the same for red, green and blue pixels, then reprocessed one night's subs.
The processing is not as good (it was just done quickly), but as you can see, the colour balance is much better.

This made me wonder if the process for correcting flats for OSC is correct - should the various colours be scaled independently to avoid this effect?

Colin

[mcgillca]

I think this is definitely an issue - I've repeated the experiment with an M33 image - again, the first image shows too much red.

I've enclosed the Python 2.7 script I used to correct the median values for each colour - you'd need to save the file in FITS format, then run the script with the flats file as an argument - it will produced a median corrected flat file which you can use to correct the flats if you have the same issue. It has a hard coded bayer matrix of GRBG - you'd need to alter lines 27 to 30 for other bayer matrix types.

Colin

[pfile]

one low channel in OSC flats is pretty common, red especially if you happen to be using one of those LP filters. one way to deal with it is to modify the color of the light used to make the flat, for instance, by using a pinkish-colored T-shirt over the telescope aperture.

the only risk in having one dim channel in your flats is that the SNR of that channel of the flat is low, which then makes the SNR of your red channel low. i think something must have gone wrong in your color calibration step, or else the red data has been trashed by the weak SNR of the flat. i don't think it should be necessary to rescale the data. and if it were i don't think you have to resort to python - LinearFit would probably get you back in the ballpark.

even with your mono camera + filter wheel i'm certain that if you create a linear RGB image and lock the channels and do STF, you'll have a crazy color cast. happens to me all the time... obviously BN + ColorCalibration or PCC can remove that cast. i don't see why the OSC case is different.

rob

[mcgillca]

Thanks, Rob - as you say, you typically get a crazy colour cast with a linked STF.

I was fully expecting the colour calibration to take care of it - I tried using PCC, then the old fashioned way using BackgroundNeutralization followed by ColourCalibration, then with PCC with different colour references to make it as blue as possible - nothing shifted it until I tried with a modified flat - as you can see the difference is very obvious.

I use an EL panel for flats - the SNR is still pretty good even for red (I have about 40,000 ADU for blue and green, 20,000 for red), so would rather find a software rather than a hardware solution. I will try linear fit and see if that helps (though the Python trick was a good excuse to practice since I'm trying to learn Python!).

The factor of two in the flats makes this stand out - but I think this is probably present in OSC processing generally. By multiplying the red channel by two it increases noise (though not SNR) AND decreases the dynamic range.

Colin

[pfile]

did you export background and foreground reference images when calibrating? i still feel that somehow the channels were not sampled properly when computing the white balance. do the stars seem similarly saturated in each channel? i am just wondering if the thresholds need to be tweaked somehow.

anyway yes, a good excuse to learn new things. i have a mental block against python due to the fortran-like indentation rules

rob

[mcgillca]

Dear Rob,

Hi - no I didn't export the white and black masks - but I used the same adjustments to both sets of data, and they were set using the approaches I normally use, so I don't think there were any errors.

I've uploaded the two images to dropbox - if you'd like to see if you can find a solution, that would be great.

The one below is the master with the standard flat:

https://www.dropbox.com/s/ote7kg8zfuke7bm/light-BINNING_1_call.xisf?dl=0

This second was prepared using the corrected flats:

https://www.dropbox.com/s/8cdbgc09bqh28mo/light-BINNING_1_median_corrected.xisf?dl=0

Let me know if you have any more luck (or more likely, skill!) than I did.

Colin

[pfile]

ok have had a cold for the last few days so maybe can't work on it right away but will try

rob

[pfile]

Hi - no I didn't export the white and black masks - but I used the same adjustments to both sets of data, and they were set using the approaches I normally use, so I don't think there were any errors.

this is very likely the problem... i don't think i've ever used the same values for the background in any two images, even from the same system and sky. they always differ.

anyway as usual i got all the way to the end of this image and realized that i had not worked hard enough on the DBE step. being an OSC image the blue channel seems a little out of focus, or perhaps it's just plain old 'blue bloat'. so it's not perfect processing, but i think the color balance was corrected fine by BN and CC. i've attached the first 4 process icons: crop, dbe, bn and CC and you can check them out. i think you will find that in your original BN and CC that nothing actually happened to the image as the upper and lower limits for the background and foreground were probably not set right.



rob

[mcgillca]

Well, that looks a lot better than mine, even with the median corrected flats. I'll take a look at your settings and see what I did wrong. As I said, superior skill 

Thank you very much, Rob!

Colin