Problems with DLSR Colour Balance

mcintyre_sj

Well-known member
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

  • 01_veil_light_360s_10_RGB_noWB.jpg
    01_veil_light_360s_10_RGB_noWB.jpg
    319.1 KB · Views: 44
  • 02_veil_light_360s_10_rgb_wb.jpg
    02_veil_light_360s_10_rgb_wb.jpg
    326.9 KB · Views: 51
  • 03_veil_integrationDrz_noCB.jpg
    03_veil_integrationDrz_noCB.jpg
    362.5 KB · Views: 39
  • 04_veil_pi_colourBalance_RGB.jpg
    04_veil_pi_colourBalance_RGB.jpg
    392.2 KB · Views: 43
  • 05_veil_pi_colourBalance_GRB.jpg
    05_veil_pi_colourBalance_GRB.jpg
    384 KB · Views: 49
  • 06_veil_dss_RGB.jpg
    06_veil_dss_RGB.jpg
    368.1 KB · Views: 42
Last edited:
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
 
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.
 
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.
 
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
 
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.
 
Back
Top