Possible DSLR_RAW bug in applying white balance

[johnpane]

I think there may be a bug in how white balance multipliers are applied by DSLR_RAW in the presence of overexposure. I have struggled with pink star cores in my images for some time, but the problem really became apparent recently when I was working with eclipse photos, some of which deliberately overexposed the inner corona to capture far reaches of the corona. All overexposed regions are coming out pink.

The attached screen shots show:
1. The RAW image loaded into PixInsight with "Camera white balance", illustrating the pink coloring in the overexposed region.
2. The RAW image loaded into PixInsight with "No white balance", showing that colors are incorrect without white balance correction.
3. White balance manually applied to #2 using PixelMath (as shown in 4th attachment)
In each case, the CIE L* component was used as a mask for HistogramTransformation stretch (identical for all three) to bring out some shadow detail.

My camera's white balance parameters are approximately 2.10, 0.93, 1.34. So, for a fully saturated pixel, red is boosted relative to the other colors, resulting in the pink tinge.

I think *maybe* these white balance parameters should be normalized to 2.26, 1.00, 1.44, and then, when applying them the result should be clipped to the maximum value dictated by the sensor bit depth (i.e., 2^14 for a 14-bit sensor). I am uncertain about this because it will clip some valid highlight detail. For example, RAW pixel values of 99% of each color should legitimately be pink but will come out near white if clipped in this way. Maybe there is a smarter away to avoid pink in overexposed regions without losing legitimate highlight detail?

[johnpane]

An alternative might be to allow the color-corrected pixel values to exceed 2^14 until one of them is saturated, in which case all get pinned to the same value determined by the largest of the multipliers, in this case 2.26*2^14. The logic here is to preserve as much highlight dynamic range as possible, but as soon as any color is saturated it is impossible to accurately render the color, so white should be used.

[johnpane]

I now realize that this work is done by dcraw and that the -H option offers some control over this. Specifying -H 0 (rather than -H 1) avoids the pink in blown-out areas, although it might not maximize dynamic range in the highlights. -H 0 is effectively obtained by unchecking the "No highlights clipping" option in DSLR_RAW preferences.

[pfile]

interesting, thanks for looking into that! i should try that on my data.

rob

[pfile]

oh but wait, per this thread https://pixinsight.com/forum/index.php?topic=8226.0

-H 1 only applies to data thats been debayered by dcraw. so that means unless you use superpixel debayering, you cant properly calibrate images.

dcraw is open source so a trip thru the source code might reveal what happens under -H 1 and then possibly it can be duplicated with pixelmath. it might simply be rescaling each channel to the full 16-bit wide space?

rob

[sharkmelley]

Pink star centres are a common problem in the final white balanced stacked image.  A quick and simple solution is to clip the data at the saturation level of the green channel (since white balance generally scales the R&B channels up).  Setting the "Highlights" level (i.e. the white point) on the HistogramTransformation would achieve that.

Mark

[pfile]

sure - what has me thinking about this is the trouble i had with HDRComposition on RGB eclipse images. obviously for an RGB image there is only one binarizing threshold and mask, so i think perhaps the statistical incompatibility of the red channel vs. blue and green must have something to do with it. separating the channels and processing them individually gave me  a much better result (though there was a tiny bit of residual banding.)

so i'm wondering what should be done to the image while it's still linear to make the channels more compatible with one another. expanding the data to fill the entire 16-bit range seems like a good place to start.

rob

[johnpane]

-H 1 only applies to data thats been debayered by dcraw. so that means unless you use superpixel debayering, you cant properly calibrate images.

VNG debayering is handled by dcraw.

so i'm wondering what should be done to the image while it's still linear to make the channels more compatible with one another. expanding the data to fill the entire 16-bit range seems like a good place to start.

With "No highlights clipping" turned off, the overexposed regions have pixel readouts of 1.0,1.0,1.0, indicating this expansion to the full range is already happening.

[pfile]

while dcraw can do debayering, it's not proper to allow it to do the debayering if you want to calibrate the images. calibration has to take place on the data in CFA (or bayer RGB) form. even calibrating superpixel debayered data is not technically correct because the two green pixels per quad have been averaged together, but it's probably close enough.

the Debayer process in PI can do superpixel, bilinear and VNG debayering.

rob

[johnpane]

while dcraw can do debayering, it's not proper to allow it to do the debayering if you want to calibrate the images. calibration has to take place on the data in CFA (or bayer RGB) form. even calibrating superpixel debayered data is not technically correct because the two green pixels per quad have been averaged together, but it's probably close enough.

the Debayer process in PI can do superpixel, bilinear and VNG debayering.

rob

Yes, you are right. But dcraw is used by ImageCalibration to read the RAW file, and white balance and the -H 0 or -H 1 features are applied at that time.

[pfile]

well, maybe i'm wrong about this but that thread i posted said that -H only does something when DCRAW is asked to debayer the image. if it doesn't debayer, the scaling is not applied.

No highlights clipping. When this option is enabled, highlights will be left unclipped resulting in various shades of pink. With this option disabled, highlights will be clipped automatically to solid white. This option is equivalent to the "-H 1" dcraw command-line argument, and only applies to de-Bayered images.

i read juan's sentence to mean that DCRAW must do the debayering or -H does not do anything. since you generally pass "raw cfa" as an image hint to ImageCalibration when dealing with DSLR files, i'd think that -H does not apply.  i'd be happy to be wrong though.

rob

[sharkmelley]

For what it's worth, this is how I "manually develop" a non-astro DSLR image in PixInsight.  It might give some additional insight.

1) Open raw file (using DSLR_RAW "Pure Raw" settings)
2) Debayer using PI Debayer
3) Subtract constant bias using PI PixelMath
4) Apply camera specific white balance using PI PixelMath
5) Apply multiplier using PixelMath across all channels to bring Green saturation level to 1.0 and clip R&B channels
6) Apply camera specific colour matrix using PixelMath
7) Apply gamma curve of approx 2.2 using PixelMath

The annoying pink appears in the saturated areas at stage 4.  The pink disappears at stage 5 because the saturated areas become saturated white. At stage 6 anything white is unaffected by the colour matrix.  Stage 7 could be improved by applying the proper sRGB tone curve (which is not constant gamma).

If instead in DSLR_RAW I untick the options "No black point correction" and "No highlights clipping" then DCRAW will do stages 1-5 and PixInsight presents me a colour image.  All I then have to do in PixelMath is stages 6-7.

Mark

[pfile]

thanks, yes i have been doing everything the same up to step 5, just didnt understand about the need for range expansion until johns post.

can you expand on step 4 and step 6 as they relate to exif data?

i should probably reprocess my eclipse images with the scaling but at this point im pretty tired of processing that image!

thanks

rob

[sharkmelley]

can you expand on step 4 and step 6 as they relate to exif data?

It's true that the white balance multipliers for step 4 will be found somewhere in the EXIF.

However, the colour matrix for step 6 isn't always in the EXIF because it is manufacturer proprietary information.  It's for this reason that Adobe calibrates its own colour matrices for its raw convertors, which can be found in the Adobe DNG file.  Similarly DXO calibrate their own matrices - an example is here:
https://www.dxomark.com/Cameras/Canon/EOS-600D---Measurements#measuretabs-7

The DXO matrices can be used directly but the Adobe ones require an additional transformation.

At the end of step 6 the colour image you have will appear quite oversaturated.  Part of the effect of the gamma curve in step 7 is to de-saturate it.

There are a few more details in a Cloudy Nights thread I started:
https://www.cloudynights.com/topic/529426-dslr-processing-the-missing-matrix/

However, at that time I had not fully appreciated the importance and subtlety of the gamma applied in step 7. 

Mark

[pfile]

thanks - i will go read that. i havent used a DSLR for astro work in years so this eclipse processing has me scrambling.

rob