I’m using Siril dev builds from the master branch, currently Siril-1.3.6+13512_arm64, and am trying out the Bayer Drizzle process with my Olympus E-M5 II. I’m using a script (attached below) which converts, applies pre-computed calibration masters, applies my camera’s CCM, subtracts background, registers (2-pass), and finally stacks. The debayering version debayers in the calibration step, while the drizzling version drizzles in the seqapplyreg step.
However, while the debayering version works fine as it always has, the drizzling version shows a brighter and purple-ish background. Also, the debayering version shows much more of the actual target (the Jellyfish Nebula). Here are autostretch -linked versions of both results (each using only the 10 60s-subs with the least background value):
The histograms of both results (as seen in the Stretches->Histogram Transformation… before applying any stretches) look very different in the 2 results: while in the one for the delayered result, the 3 colour curves peak in the same spot, in the drizzled version, the green curve peaks quite a bit to the left to the red and then the blue curve. Also, the drizzled version shows is more drawn-out to the left and shows strange “wavy patterns” there:
Are you just looking at a single Bayer drizzled sub? See the warning at the top of this page: Siril Manual - Drizzle.
Basically Drizzle should be regarded as a black box covering both registration and stacking. Siril does the two parts separately because that was the best fit for our existing internal workflow, but you shouldn’t take the drizzle-registered sequence and do anything with it except stack it. If you do look closely at the registered sequence you will see a variety of oddities - the reference frame looks quite different to the others because of exact alignment of the droplets with the output pixel grid, there may be weird patterns in other frames where pixels receive zero contribution from drops etc. These all resolve themselves during stacking. I’m not sure what debayering does to the colours because I didn’t write that code and haven’t really touched it, but it’s typical for the colour balance of a fresh stacking result to have a colour cast - this is easily corrected using SPCC.
And as you can see in my attached script above, I do stack right after registering. As also mentioned, I’m applying my camera’s CMM for colour correction, which works very well in the debayering flow.
Looking at your script, you are doing drizzle → linear background extraction → CCM → stack. I think the linear background extraction is the issue here, not the drizzle. I took a drizzled sub and performed a linear background extraction on it: look at the stats before and after.
Considering the medians, beforehand red is notably less than green which is notably less than blue whereas after red and green are essentially the same whereas blue is higher.
I suspect this is because the drizzled images have differing numbers of zero-value pixels in each channel and this is affecting the stats weighting during background removal.
However you should move the stage at which you do background removal. It should occur after calibration and before registration. For one thing, it is then removing gradient exactly as it hit the sensor rather than with a distortion applied, and for another thing it is being applied to the CFA images rather than the RGB images so it will save you a load of disk space. But most importantly, when background removal is applied to a CFA image it splits the CFAs out and applies removal from each CFA channel separately, and then recombines them back into background-extracted CFA images that can be taken on to the next step and have Bayer drizzle registration applied. This means it’s applying background removal to a complete, statistically valid subimage for each CFA subchannel and the whole issue with holes in the drizzle-registered output affecting the colour balance between channels should go away.
(I’ve just tested it with my CFA test sequence and doing bg extraction on the CFA sequence immediately after calibration does result in medians matching what I would expect from the “before” values in my screenshot.)
Yes you’re right, sorry I thought I had changed the order. I did that now (attached the updated script), but this keeps much of the green tint which should be removed by applying the CCM. This has been auto-stretched (linked):
I’ve seen this happening before when I applied the background extraction before applying the CCM. But now I can’t move the CCM to before background extraction because it needs to operate on 3-channel RGB images, not the CFA images.
I then removed the CCM step and used photometric colour calibration (I can’t use SPCC because the Olympus E-M5 II isn’t supported with it – how to add support for a camera?) instead after stacking, which worked to get correct colours again. Just auto-stretching it and no other processing does seem to create a bit more contrast for the stars than the debayered + CCM version above, but also less of the nebula:
So I conclude then that the workflow with the CCM just isn’t feasible when using drizzle instead of debayering, if I need to apply the CCM before extracting background?
I think you might be right. I’ll have a think about whether there’s a way to apply a CCM to a CFA image but it’s not obvious…
In the absence of a set of response curves to use SPCC with your camera, your best bet is probably to use PCC with the Gaia local database (you only need the astrometry local Gaia catalogue for this). This catalogue has a Teff field which gives the effective temperature of each source - the values should be really accurate as they are computed from all the Gaia spectral data, and from there there is a very robust way of converting Teff to CIE XYZ and then on to a colour space of your choice. It entirely sidesteps the need for camera sensor knowlege; the only limitation is that you’re stuck with the white balance of your destination colour profile, which isn’t a huge limitation.
