Flat frames and OSC cameras

[jmtanous]

Hi,

Is there any way to get rid of the color information of the flat frames using pixelmath?

I've been trying to calibrate my frames using Vicent tutorial but I have an OSC camera (star shoot pro). I've tried to debayering the master flat using super pixel method then extract the L channel and finally 2x resample. But the resulting master flat looks somehow *sharp*

Is there a better/easier way to get rid of color information of the flats? Something like 4 pixel average filter?

Cheers,

Jose

[Niall Saunders]

Hi Jose,

When you are working with a 'One-Shot-Colour' (OSC) camera, and are trying to tackle the problem of full calibration of your images, then this is the procedure that I ahve been using, and would recommend to others:-

Capture ALL of your frames in RAW mode - this includes Lights, Darks, Flats, FlatDarks and Biases (assuming that you choose to collect all of these individual tyoes of sub-frame)

At this stage, just totally IGNORE the fact that the data has been obtained from an OSC camera. Treat the frames exactly as they are, i.e. MONOCHROME, SINGLE-CHANNEL images.

So, you can then proceed to create your MasterSubs according to your chosen workflow - personally, I create a MasterDark, and a MasterFlatDark. I then use the MasterFlatDark to calibrate the Flats, before then creating a MasterFlat. I can then finally use the MasterDark and the MasterFlat to calibrate all the Lights.

Once you have your calibrated Lights, now - and ONLY now - can you deBayer these into three-channel colour images. It is a total waste of time doing this any earlier (and doing so can actually degrade the image quality because you are introducing the errors associated with the imperfect deBayer process far too early in the procedure). And, you CANNOT leave it any later in the process because deBayering requires you maintain registration of the image to the pixel array. So you MUST deBayer your data BEFORE you 'align' or 'register' the images.

An aside here : I have often wondered why this is always stated to be the case? Surely if all of the 'mono', non-deBayered, data is subsequently aligned and stacked, then the geometrical relationship has NOT actually been 'lost' - providing that all the Bayered images are aligned to an image which was, itself, one of the Bayered images, and which therefore still retained its geometrical correlation with the on-chip CFA?

That would then mean that the 'lossy' deBayer routine would only need to be applied once - to the stacked result, which - by its very nature - contains 'statistically more robust' data in the first place.

Anybody care to comment?

Anyhow - assuming that we follow convention, you will have now 'Batch deBayered all of your Calibrated RAW Lights and would now be ready to StarAlign the, by now, 'colour' images. Finally, you would then ImageIntegrate the aligned, coloured, calibrated Lights, producing your final masterpiece ready for you to work the rest of your PixInsight magic on.

HTH

Cheers,

[jmtanous]

Niall,

Thanks for your answer. By the way I do follow a similar workflow when I calibrate my lights.

However I am asking a different thing. Let me give you an unrealistic example to better illustrate my question.

Imaging that you take a picture of an object that is completely red using an OSC camera. Then you use green screen to take your flats. If you use your flats as if they were monochrome you wont be able to apply them to the lights. If you use a perfect white screen for taking your flats you won't experience this problem.

One way to get rid of this problem inherit to OSC cameras is to average a bayer cluster RGGB that way any chromatic cast of your flat surface/screen will be gone. The cost of this operation is a softer master flat, but usually you want to use flats to compensate for low frequency illumination imperfections so it really doesn't matter.

Cheers,

Jose

[Harry page]

Hi

Sorry using a osc flat as raw does not work with my sx m25 camera

I use AA4 to destroy the matrix before debayering and I believe maxim has the boxcar filter to do the same thing

I do not know how to do this inPI , but I have requested such a thing from mr Juan

Harry

[Niall Saunders]

Hi Jose,

OK, let me try and understand your problem - without using the red/green 'limiting' scenario, as that WOULD be foolish.

So, you set out to take Flats for your OSC, but your light source is NOT 'chromatically neutral'. Let us assume that you do actually have a PERFECTLY FLAT source of light, and that your optical train suffers from just exactly ONE 'dust donut', and that the effect of that 'donut' is to reduce the incident light 'underneath it' by a 'perfect' 25%.

Let us assume that the fact that your light source is not 'neutral gray' gives you a CCD response (for an RGBG CFA) where Red responds 60%, Green responds 40% and Blue responds 30% (these figures do NOT need to add up to 100%, by the way!).

Now, you adjust the intensity of your light source to get the 'maximum ADU' of around 32,000 (1/2 full well, and thus 'inside' the linear response zone for your CCD) - and you do this whilst also keeping exposure times long enough to be able to take effective FlatDarks at the same exposure time as well (so, typically a few seconds, or so)

However, the max ADU' reading will have been for a Red pixel - because the 'colour' of your incident light was more Red (60:40:30, remember) than Green or Blue. This doesn't actually matter - as I hope I am going to be able to explain.

Think about your light source causing Red CFA pixels to read 32,000, Green CFA pixels to read 40/60ths of that (say 21,300) and your Blue CFA pixels to read 30/60ths of that (16,000) - all of these for where the dust donut was NOT having any effect. What you do NOT need to worry about is the fact that the CCD may actually be TWICE as sensitive in the Green part of the spectrum. It doesn't matter - this extra sensitivity will have ocurred irrespective of whether the photon arrived from M82 or that cheap flashlight bulb you are using in your lightbox.

Now, where the 'magic donut' HAS had an effect, the ADU intensities for Rd, Gn and Bu will have been attenuated (by 25%, as I postulated above). So the 'obscured' ADU values for Rd, Gn and Bu respectively then become 24,000, 16,000 and 12,000 (-ish).

And, remember, nothing has been deBayered at this stage - nor will anything be deBayered until the very end.

What now needs to happen (we are assuming NO effects from 'Dark' noise - we don't need to confuse things here) is that the 'Flat' that we are talking about will be 'divided into' each of your lights. However, this Flat is not really in an effective state for being used as a denominator in a division process - especially not in the world of PI, where all internal operations are performed using data in the [0.0, 1.0] range. So, we need to convert the six ADU values that exist in our image into the 'internal' range.

The 'un-obscured' values change from [32000, 21300, 16000] to [0.500, 0.325, 0.250]
The 'obscured' values change from [24000, 16000, 12000] to [0.366, 0.250, 0.183]

Now, let us pick a random pixel intensity for some pixel location on one of our Light frames - let's make it 0.45678 (i.e about 29935 in 'normal money')

If that pixel was under a Rd filter in the CFA, and was un-obscured, then the 'division' process would change the value to 0.91356 (i.e. 0.45678 / 0.500)

Had it been under an un-obscured Gn filter, the result of the Flat division  would have been 1.40548 (0.45678 / 0.325). And un-obscured Bu would have resulted in 1.82712 (0.45678 / 0.250)

In summary, this would have produced these three results 0.91356, 1.40548 and 1.82712 for Rd, Gn and Bu respectively
For the 'obscured case' the three results would have been 1.24803, 1.82712 and 2.49607 for Rd, Gn and Bu respectively
(ignore the fact that we have now left the [0.0, 1.0] range - PI would have kep this under control on our behalf)

What can be seen is that the ratios between these six results have NOT been altered (other than by my 'rounding errors')

MOST IMPORTANTLY, what can also bee seen is that, because the MasterFlat is LACKING 'blue spectral light' the result of the Flat division will be heavily biased TOWARDS Blue (in the 'inverse' of the original 60:40:30 ratio, i.e. in a (100/60):(100/40):(100:30) ratio, which will also emphasise GREEN over RED as well.

But, the reality of this just isn't really a problem. Although your calibrated RAW lights now have a colour cast that is the INVERSE of the light spectrum that was used to illuminate the Flats - you are in any case about to deBayer these RAW images - and the deBayer process itself imparts its OWN 'colour cast' as it removes the CFA.

So, you end up with a final image, after aligning and integrating, that just looks 'horrible' as far as colour is concerned. Sure, if you knew that you would be able to keep the (horrible) spectral content of your flat light-source 'constant', then you could spend hours imaging one of my 'test-cards' and tweaking the deBayer 'colour matrix' to try and recover a close approximation to 'natural' colour. And then you would just always invoke that array whenever you deBayered your data after flat-fielding.

Alternatively, you could just use PixInsight to sort things out - by specifying an area of the background of your image and using BackgroundNeutralisation to 'neutralise' the colour casts to make that area 'grey' - effectively then also removing the nasty colour casts from the remainder of the image as well. And, obviously, you can go another step forward by also telling PI to use ColourCorrection to make the 'average' of a selected foreground area 'white' as well.

I know this probably has not been the 'clearest explanation' - but for a light source that has, more or less, 'some' ouput covering 'most' of the spectrum, my experience has been that it just is not worth worrying about too much. The 'inverse colour cast' that you see where spectral output was weakest is at least a LINEAR CONSTANT throughout all subsequent processing, and can be dealt with once you start working with your final image.

As I have said elsewhere - if you think deBayering an OSC image from a RGBG (or RGGB) CCD is difficult, try and imagine the exponential extra layer of difficulty you encounter with a CMYG colour-filter-array as found in cameras such as the popular DSI-IC and DSI-IIC imagers. There you have a 'mixture' of primary and secondary (additive and subtractive) filter colours - so all bets are off!

But, my sub-5$ lightbox (relying on a 'dim' single 12V torch-bulb filament, shining through several layers of el-cheapo printer paper) which must have the most horrible spectral response imaginable, still allows me to create a perfectly acceptable colour image from my CMYG one-shot colour imager.

What I firmly believe is that you CANNOT destroy the CFA data by 'boxcar filtering' your MasterFlat, and then trying to use that to calibrate your still-RAW Lights.

HTH
(and apologies to everyone who got totally lost, or bored, or fell asleep, during this ramble)

Cheers,

[Harry page]

Hi

sorry Did you say something 

I probabley did not make my self clear after creating a masterflat in AA4 it is used as a raw unbayered file !

AA4 averages the surrounding pixels to create its flat and with my sxv m25 I use a max adu of around 20000 as above this the chip looses its linerality 

Don't always know the maths , but I know what works 

Harry

[Niall Saunders]

I probabley did not make my self clear

Hi Harry - I don't think I did either

I seriuosly thought about just hitting 'back-page' and dumping the whole reply. I felt I lost the plot, but I still thought I knew the point I was trying to make.

Bottom line - I just have never got 'hung-up' about the spectral quality of my lightboxes. I use them, and deal with the colour-cast issues in PI, and don't give a hoot about what the image looks like until after I DynamicCrop, DBE, BN and CC.

But, then again, I am still a DSI 'rebel'

Cheers,

[Harry page]

Hi

By averaging the surrounding pixels the colour gets lost and if the file is not debayered there is no colour to affect the light images


Harry

[Niall Saunders]

Right, that has just 'clicked' in my feeble brain.

You are forsaking spatial resolution in the RAW Flat, in order to eliminate the artifacts due to colour (or poor spectral behaviour).

A 'flat' actually only needs to know 'where' the image is 'darker'. Vignetting and dust are not prejudiced by the colour of light used to detect them.

And, we do NOT need to create a Flat with 'absolute pixel accuracy' - even at the 2x2 'superpixel' level, the Flat would still be more than accurate enough to identify vignetting gradients and typical dust-donuts.

I would need to run a comparison (time permitting) to see how this approach compares to my current methods.

Cheers,

[Harry page]

Ah

You have seen the light 


harry

[Niall Saunders]

Yes,

But why is it such a funny colour

[Harry page]

Hi

If you want to see how I do it in astroart heres the video http://www.harrysastroshed.com/AA4flat.html I did this as its a question that gets asked a lot

Now the powers that be I only did one for Astroart and then I saw the error of my ways 

And when the new fixed version of Pi comes out I will do one for Pi , you know the one that reads my astro art files 

Also do not forget that , how to make a osc flat in Pi button 

Harry

[jmtanous]

@Niall,

Thanks for taking the time to write such a detailed explanation...

I get your point. As long as your flat screen/surface is more or less white you'll end up with a color cast in your calibrated lights that you can correct latter in the processing pipeline.

@Harry, Nebulosity does the same as AA4, it averages the 4 surrounding pixels to destroy the color. I don't like to deal with heave color shifted images...

I am trying to get away from nebulosity and do all my processing in PI, that's why I am asking this kind of questions.

If you debayer your master flat using the super pixel method and then extract the L channel you'll end up destroying the color, but your flat will be 2 times smaller than your lights. If you 2x resize the super-pixel-debayerd-master-flat and apply it to your lights it doesn't work.

After reading Niall's post, it comes to my mind the idea of neutralizing the color of the master flat, then extract the L channel and use it to calibrate my lights. This method will lead to minimal color shift in my calibrated lights... Let's see...

Cheers,

Jose

[Harry page]

Hi

I have tried the luminance thing and used that as a flat and it does not work as well as the averaging method , I think its because there is to much info still
contained ( ie pixel to pixel variation )

Let me know how you get on

Harry

[Nocturnal]

Hi,

the ideal way of flat fielding an OSC image is to do each channel individually. This can be done without debayering, that should be obvious. The Handbook of Astronomical Image Processing describes this in more detail, DeepSkyStacker implements this.

That said, if you're willing to give up resolution and color dependent calibration then using a downsampled flat frame should be 'fine'. Not ideal though