The other important thing to bear in mind is that the steps so eloquently described in this process are also equally as valid for those using 'One-Shot'Colour' CCD imagers (except for any steps involving conversion from RAW to FITS, obviously)
However, I have been struggling with a SIGNIFICANT issue when I have been procsessing my images using this workflow - and the issue is specifically realted to Flats.
Bearing in mind that Flat Calibration involves 'dividing' your individual Lights by your Master(Calibrated)Flat, you have to consider the process in somewhat greater detail when working (as we are at this stage) with images that have not yet been deBayered. In a 'standard' (monochrome) process, we set about acquiring Flats with a typical maximum ADU level of around 32,000, and then we calibrate these with a MasterFlatDark image.
Importantly here is the fact that the MINIMUM ADU value for the Master(Calibrated)Flat should NOT be (anywhere near) 'zero' - otherwise the 'division process' is going to start creating all sorts of horrible 'infinity' values (which, fortunately can be 'trapped' by PI in any case - but still remain undesirable in the first place). And this situation is undesirable for either OSC or Mono imagers, and for DSLR users as well.
However, if you have managed to avoid the 'zero ADU' problem, and have a Master(Calibrated)Flat (for a mono CCD, for the moment) with values now ranging (say) from 1000 to 32000 - all will be well. PI will perform the division quite happily, and will even ReScale the output ADU values back into the [0.0, 1.0] internal working range - all automagically. Which is great.
Now we come to the 'OSC problem' (also the 'DSLR problem') - as I see it
Unless you have the luxury of illuminating your OTA objective with a light source that causes EVERY SINGLE PIXEL on the CCD - irrespective of its CFA filter colour - to respond 'linearly' to the incoming light spectrum, then you ARE going to have quite a strange resultant Master(Calibrated)Flat to work with. Basically, instead of the 'single peak' visible on the Histo panel (when examining a 'mono' Flat frame), you will (most likely) have FOUR esily distinguishable 'peaks' visible on the HT graph when you look at a Flat from an OSC camera.
And I am struggling to understand how, or even 'if', this has a knock-on effect when this type of Flat is used to calibrate an OSC 'Light' frame. I could see that, if each of the four 'arrays' of pixels could be 'flat-calibrated' individually, then the 're-scaling' functionality of PI would effectively eliminate the problem. But, because this obviously does NOT happen (as I understand), then the resultant 're-scale' operations affect each of the four pixel sets (one per colour in the CFA) DIFFERENTLY - leaving the final calibrated Light with quite horrendous colour bias.
Well, this colour bias problem has been what I have experienced anyway.
I have created a 'workaround', and it isn't THAT difficult to implement (in that it only has to be applied to the initial MasterFlat), but it does require around ten PixelMath applications to 'normalise' the four pixel-sets of the CFA (in fact, the process is easily applied by re-using a ProcessContainer that I devised, and now store on disk - it doesn't even require a PJSR - the only 'downside' being that eight 'interim' images that are created need to subsequently be deleted, manually).
What my process does is to 'split' the original MasterFlat into four images - each containing the pixel data from ONE of the colour filters of the CFA. Importantly, these images remain the SAME SIZE as the original MasterFlat, only they contain '0' for all pixel locations NOT assopiated with this colour of the CFA. I then apply (either) a SCALING or an OFFSET process to this 'extracted' image, such that the 'brightest' ADU value is moved up the luminance scale (to '1.0') - either by 'addition' for the OFFSET process, or by 'multiplication' for the SCALED process. Once the four 'extracted and normalised' images have been created, these are then simply 'added' back together (easily done, because all 'non-associated' pixel values were set to '0' during the CFA 'extraction' stage) to recreate a 'normalisedMasterFlat'.
So, in the normalisedMasterFlat, the 'brightest' pixel in each CFA sub-set is only ever '1', and the 'dimmest' will always be 'non-zero'. And, importantly, the four CFA pixel-sets are each 'equally as bright' as each other - irrespective of the spectral content of the light source used to create the flat in the first place.
What I now ask is that 'minds immeasurably superior' to mine have a think about the problem, and about the solution that I am currently using (for better or worse), and decide whether the problem really does exist in the first place, and whther my solution is effective at addreesing the problem, WITHOUT introducing subsequent additional problems of it's own making !
