DSS 4.1.1 - can white balance be disabled completely?

[steve72614]

Hi,
I'm aware that this is a Star Tools forum, not a DSS forum, but I'm hoping someone knows the answer to this.

I recently upgraded to DSS 4.1.1, 64 bit. Now that DSS 4.1.1 has been out several months, I wondered if anyone knows if DSS 4.1.1 white balancing can be completely turned off if using .CR2 files.

DSS 4.1.1 settings used --
In the RAW Files settings, both "Use Auto White Balance" and "Use Camera White Balance" are unchecked.
In the Stacking Parameters Result Tab, "Align RGB Channels in final image" is unchecked.
In the Stacking Parameters Light Tab, it says "No Background Calibration".

I read somewhere DSS 4.1.1 uses an updated DCRAW version internal to DSS.

With the older DSS (known white balance issues), I had been converting all the CR2 files to tiff before DSS and then Star Tools. Is this still necessary to avoid any white balancing, or is DSS fixed?

I know I will get better results with Star Tools if I use linear data.

All I can really say for sure is DSS 4.1.1 produces a redder image than the previous version with the options I list above.

Thanks,
Steve

[admin]

Hi Steve,

It's hard to say what is (or is not) going on inside DSS (bar inspecting the code).
Most DSLRs, when producing a visual spectrum dataset, tend to produce a distinct blue/teal signature/bias when first opening, rather than red...

It's not so much the version of dcraw that DSS uses, it's rather how it uses it. For example, PixInsight uses dcraw as well and does tend to produce a teal/blue bias as expected.

[steve72614]

Thanks Ivo! I did take a cursory look at the DSS source code in RAWUtils.cpp (function LoadRawFile at line 879), and see that when it calls dcraw, it leaves out the -w and -a dcraw options if they are not specified in the DSS options. However, it DOES NOT feed dcraw the custom white balance of "-r 1 1 1 1". I'll see if I can find a place to leave a note to the DSS author.

I see that I can also control debayering options in dcraw. AHD debayering (dcraw -q 3) is strongly advocated by an expert astrophotographer I know, as it can bring out more detail. I see elsewhere that it can also bring out noise. In the example dcraw calls I've seen posted on this forum, usually they use bilinear debayering (dcraw -q 0). What do you folks suggest for debayering?

For larger objects, if I intend to do 2x2 binning anyway, what about doing "superpixel debayering", (dcraw -h). I'm thinking this kills two birds with one command. Opinions?

Also, when doing dcraw conversions, I'd suggest everyone use the (dcraw -z) option to preserve the original date and time of the .CR2 file.

Steve

[admin]

it DOES NOT feed dcraw the custom white balance of "-r 1 1 1 1". I'll see if I can find a place to leave a note to the DSS author.

Nice catch - could be problem...

AHD debayering (dcraw -q 3) is strongly advocated by an expert astrophotographer I know, as it can bring out more detail. I see elsewhere that it can also bring out noise. In the example dcraw calls I've seen posted on this forum, usually they use bilinear debayering (dcraw -q 0). What do you folks suggest for debayering?

I would very much recommend against AHD! It's not so much that it brings out noise. It's that it interprets noise and creates artefacts out of it;

AHDvsLinear.png (73.38 KiB) Viewed 7454 times

Worse, these artifacts (aka "zipper artifacts") are now correlated noise, meaning that, unlike Poisson/shot/"random" noise they look like detail to most noise reducers (and actual people!).

Ergo, AHD creates detail where none exists.

Add to that, your stacker will try to align, calibrate and stack based on those artefacts as well (debayering happens before stacking of course). It's a recipe for noise and disaster.
Even if AHD would be some miracle/superior debayering scheme, the minute detail that AHD tries to reconstruct within a 2x2 patch is rarely there to begin with in astrohphotography; more often than not the data is oversampled, meaning that detail at the 2x2 patch level simply does not exist and, hence, would not benefit from any such advanced scheme to reconstruct it!

For larger objects, if I intend to do 2x2 binning anyway, what about doing "superpixel debayering", (dcraw -h). I'm thinking this kills two birds with one command. Opinions?

That definitely sounds like a good idea, though I am wary of the superpixel debayering implementation in DSS/dcraw. For some I've never had good results with it. Maybe I should try again.

Also, when doing dcraw conversions, I'd suggest everyone use the (dcraw -z) option to preserve the original date and time of the .CR2 file.

Ha! Nice one - I didn't know about that.

[micheleorsini]

I always found this white balance thing a little "too low level" for my laziness, so I've always followed carefully author suggestions without asking too many questions
Still, I have one curiosity: how does startools takes into account the information passed at the beginning?

I'm talking about these first two options

- Linear, not bayered or bayered + white balanced
- Linear and bayered but not white balanced

what happens differently inside startools if one picks one or the other option? and, btw, why this choice it is not reported in the log?

Michele

[admin]

I always found this white balance thing a little "too low level" for my laziness, so I've always followed carefully author suggestions without asking too many questions
Still, I have one curiosity: how does startools takes into account the information passed at the beginning?

I'm talking about these first two options

- Linear, not bayered or bayered + white balanced
- Linear and bayered but not white balanced

what happens differently inside startools if one picks one or the other option?

That's a great question Michele.

What happens is this;

For every 2x2 pixel patch of a mono sensor, a Bayer filter (which is overlaid on top of the mono sensor) allocates 1 red pixel, 1 blue pixel and 2 green pixels. So, if you have, for example, a 16MP camera, then you are really only recording 4MP red, 4MP blue and 8MP green pixels per frame.

A debayering algorithm "makes up" the missing 12MP of red, 12MP of blue and 8MP of green pixels in order to produce a 16MP color (not mono) frame.

The fact that a debayering algorithm needs to "make up" fewer green pixels (only 8MP made up) than red (12MP made up) and blue (12MP made up) pixels, means that the green channel is more precise than the red and blue channels; there are 2x as many green pixels describing detail "truth" than red or blue pixels.

If;

• the data was acquired using a debayering filter

and;

• the data has not been whitebalanced yet (e.g. the pixel values have not been multiplied or contaminated by taking values from the red and blue channels)

then StarTools can assume that the green channel is 50% less noisy than the red and blue channels. This means that Tracking can take into account that the green channel is more precise and that the green channel can be weighted to be a better source for detail than the red and blue channels.

Without all the above, StarTools has no choice but to weigh the channels equally for the purpose of detail extraction, which is technically sub-optimal. There are other channel-dependent noise considerations at play (for example light pollution prevalence in the red and green channels which makes those channels noiser again).

Your mileage, in terms of improvement, may vary. However, the more StarTools can "unpack", undo and Track noise influences the better; technically and mathematically, it is the optimal thing to do.

and, btw, why this choice it is not reported in the log?

It is as of 1.4.332!

Hope this helps!

[micheleorsini]

thank you for the clear explanation!

Michele