Problems with DLSR Colour Balance

mcintyre_sj

Active member
Nov 1, 2009
44
0
I am having trouble balancing the colour for an image of the Veil Nebula taken with a Canon T2i with an Astrodon IR filter installed. I have 69 x 360s subs with bias, darks, and flats. I am following the drizzle integration workflow.

The subs look ok. Without the camera whitebalance, they are overly strong in green as expected.
If i manually apply the camera white balance formula, then the light sub has a colour balance that i expect with a reddish nebula and neutral background.
After stacking with all the calibration frames and using the drizzle integration workflow, the result is way too red, or way too little green.
I attempted a pixMath colour balance by normalizing the image to a reference image - linearly scale the background and star colours to match the reference image.
Then the background and stars look ok, although the background was neutral grey rather than redish.
But the nebula was green!!!
Nothing i do turns the nebula to the expected red.
As a faint hope, i swapped the red and green channels - RGB -> GRB.
And then the image colour looks ok. The nebula was now red with a little blue on the edge - as expected. The background was still neutral.
For reference, i stacked the image set with calibration frames using DSS. The colour balance from DSS was ok and matched the white balanced light frames.

For the images attached, i applied a curves function to stretch the images so things would show up better, but did not alter the colour balance. The colour therefore is what the process produced, less the stretch.

So what's going on here? How can swapping red and green channels produce a better looking image?
 

Attachments

Last edited:

pfile

PTeam Member
Nov 23, 2009
5,689
116
it could be that the T2i is one of the cameras for which the libRAW guys changed how they crop the file and thus changed the bayer matrix pattern from RGGB (which all canon cameras use) to GBRB. this model is not in juan's list here in this post (https://pixinsight.com/forum/index.php?threads/compatibility-update-raw-module.13667/) but there is still a chance it was affected by this problem.

so you might try changing debayer to GBRB, though i'm not 100% sure this is the problem you are having, as i think that auto should have handled it properly.

rob
 

mcintyre_sj

Active member
Nov 1, 2009
44
0
Thanks. Definitely something to do with how the sensor crop is aligned to the bayer matrix when the raw data is extracted from the CR2 file.

I debayered one of the calibrated lights using RGGB - what i would expect for canon - and it was off. There is a checkerboard pattern of "noise" in the RGB image and the nebula was green. I then tried RGRG as you suggested and no checkerboard pattern and nebula was red.

I have my own Cr2ToFits conversion program which uses libraw to extract the data from the CR2 file. Along with my own implementation of VNG to produce an RGB image. My home grown Cr2ToFits works fine. I am using libraw v0.19.2 released 2018-12-24 .

I don't know what i can do to work around this issue. I will look through the thread you suggested to see it there is a solution.
 

pfile

PTeam Member
Nov 23, 2009
5,689
116
well, i think that thread is just there to help people that had made masters with older versions of libRAW and wanted to use them with a newer version of PI. if you are starting from scratch with new lights/darks/bias/flats, then everything is OK if you just set the bayer pattern to GBRB - all the debayered CR2 files are self-consistent as long as the same version of libRAW is used to open them.
 

bulrichl

PTeam Member
Nov 2, 2016
855
65
La Palma, Canary Islands
Canon Rebel T2i = Canon EOS 550D, so yes, this camera is concerned by the LibRaw change.

This is an example of the console output when an image in CR2 format is opened in PixInsight 1.8.8-6 that uses LibRaw release 0.20.0:

Camera ........... Canon EOS 550D
Timestamp ........ 2010-03-18T16:17:22Z
Exposure ......... 1/60s
ISO speed ........ 6400
Focal length ..... 30.00 mm
Aperture ......... f/8.00 = 3.75 mm
CFA pattern ...... Bayer GBRG
Raw dimensions ... w=5344 h=3516
Image geometry ... x=142 y=52 w=5202 h=3464

Raw decoding parameters:
Output mode ............... cfa
Auto crop ................. enabled
Wavelet noise threshold ... 0
White balancing ........... disabled
Black point correction .... disabled
Highlights clipping ....... disabled
Auto rotate ............... disabled
Output image .............. w=5202 h=3464 n=1 Gray

Reading RAW data: done


With releases of LibRaw before '201910 snapshot' (released on October 31, 2019 ), the Image height was h=3465 and the CFA pattern was RGGB.

Bernd
 

mcintyre_sj

Active member
Nov 1, 2009
44
0
Works now. Thanks.

Debayering with "auto" correctly identified the bayer pattern. Where does auto get that information? I had been using RGGB as that's what Canon reports as being the bayer pattern for the camera.

I recompiled my own CR2ToFits program with the current libraw 0.20.0 and i see that it adds an extra row to the top margin. Which would shift the bayer pattern down one row. The image file size actually remains the same and is the same as what PixInsight uses to read a T2i (550D) CR2 file as a raw CFA image.

PixInsight console reports:
CFA pattern ...... Bayer GBRG
Raw dimensions ... w=5344 h=3516
Image geometry ... x=142 y=52 w=5202 h=3464

I will followup with libraw. The libraw library does not use [all] the image size data that appears in the exit meta data. So i guess they just make them up to suit what they think is correct.