StarTools

Hi,
I use a Canon T6 DSLR, and then follow either path A or path B depending on how big my target is.

Path A for smaller targets
1. convert all .CR2 to full resolution .tiff with dcraw bilinear debayering
2. Deep Sky Stacker
3. Star Tools without any binning. Crop smaller area of interest.

Path B for larger targets
1. convert all .CR2 to one quarter as many pixels with dcraw -h. This generates a superpixel with values (R,(G1+G2)/2, B) from (R,0,0), (0,G1,0), (0,G2,0) and (0,0,B) input pixels.
2. Deep Sky Stacker
3. Star Tools without further binning.

I noticed that Path A results tend to be noisier than path B results.
I understand that binning reduces noise if all the pixels each have a (R,G,B) value. What I don't understand is why this is true for bayered images, which don't have a (R,G,B) value for every pixel.
When doing bilinear debayering of the camera .CR2 values, the missing values are interpolated. No new image detail is produced in the debayered image.

There is Path C for larger targets, which I have not used.
1. convert .CR2 to full resolution .tiff with dcraw bilinear debayering
2. Deep Sky Stacker
3. 2x2 Bin in Star Tools.

I have gone thru from Craig Stark's website regarding SNR measurement, camera gain and read noise measurements for my path B processing flow. I'm interested in the mathematics of how the SNR of bayered images is changed by path A, B,and C. When 2x2 binning is done with only (R,0,0), (0,G1,0), (0,G2,0),(0,0,B), how could that reduce noise for the red or blue channels? I do see that it could slightly improve the green information. I would be interested in the applicable equations or a link to a good explanation.

Thanks!

Steve

Hi Steve,

Great questions on an important subject!

I understand that binning reduces noise if all the pixels each have a (R,G,B) value. What I don't understand is why this is true for bayered images, which don't have a (R,G,B) value for every pixel.
When doing bilinear debayering of the camera .CR2 values, the missing values are interpolated. No new image detail is produced in the debayered image

The Bin module documentation goes into this.

When debayering, the interpolation causes single-pixel noise to change scale; due to the interpolation, the error bleeds into neighbouring pixels (this is especially complicating things when using "smarter" debayering strategies than bilinear interpolation). I'm sure you've, for example, seen the effect of interpolating a hot pixel in the red or blue channel. Such an aberrant value bleeds into neighboring pixels to become a multi-pixel patch. Binning 2x2 will roughly undo the change of scale, so that the error once again is - roughly - confined to a single pixel.

The recommendation to use bilinear interpolation is precisely because "undoing" the bleeding in that case is still somewhat possible. VNG or AHD try to be "clever" in ways that make it impossible to attempt to reverse the operation.

It should be noted that this "bleeding" (regardless of debayering strategy) is somewhat mitigated if enough images are stacked with proper dithering between frames. In a roundabout way, this then becomes roughly similar to Bayer drizzling. The latter is the preferred way of Debayering if your dataset is not significantly oversampled (otherwise the quarter resolution method will suffice). Proper Bayer drizzling requires many frames that have been dithered at the sub-pixel level through precise guiding with a dithering strategy that exposes all pixels equally.

Does that help?

Have you tried as a comparison
Path D
1. Deep Sky Stacker using the raw CR2 files from the camera
2. Star Tools with binning. Crop as required

Or what gain are you getting by first converting all CR2 to tiff rather then using StarTools on the DSS fits output from the raw CR2 files?

Hi Ivo,
Thanks for the explanation. I wonder if when I use

my Path B) dcraw -h to create superpixels with values (R, (G1+G2)/2, B), and feed that into StarTools and choosing "Data was bayered and not white balanced",

how the SNR compares to

my Path A) dcraw -q 0 to do bilinear debayering, then Star Tools and choosing "Data was bayered and not white balanced", and then doing a 2x2 binning.

I understand how to analyze the SNR for Path B output of dcraw, and get good results. I don't understand how to analyze the SNR of dcraw bilinear debayered tiffs that I use in Path A.

Do I lose any SNR with the dcraw superpixels going into Star Tools?

Hi Happy-kat,
DSS white balances the .CR2 because when it calls dcraw to import the .CR2 raw files, it leaves out an essential dcraw option of '-r 1 1 1 1'. This means that dcraw does white balancing, which Ivo has stated elsewhere in the forum, that is messes up Star Tools processing. When DSS went open source, I found the actual error in the DSS source code. So I don't use Path D anymore.

Also, to measure the gain, the data must be linear. Craig Stark describes a method of measuring gain by taking pairs of flats at different exposures, and analyzing the images using a program called ImageJ. Look at the 2009 articles here, SNR parts 1 thru 5. Part 3 describes how to measure gain and SNR.
http://www.stark-labs.com/craig/articles/articles.html

Steve

Thanks Steve.
Does the very new DSS version still do that ?

Happy-kat,
It looks like DSS 4.2.0 still does white balancing when processing .CR2 files, either Daylight or Camera settings.
See the DSS announcement here --
https://stargazerslounge.com/topic/3378 ... nt-3676948

So I'll still be using dcraw first, before DSS. I like using dcraw -h to create 2x2 superpixel tifs first. It speeds up DSS a lot, and I get good results that way.

Steve

steve72614 wrote:Hi Ivo,
Thanks for the explanation. I wonder if when I use

my Path B) dcraw -h to create superpixels with values (R, (G1+G2)/2, B), and feed that into StarTools and choosing "Data was bayered and not white balanced",

how the SNR compares to

my Path A) dcraw -q 0 to do bilinear debayering, then Star Tools and choosing "Data was bayered and not white balanced", and then doing a 2x2 binning.

FYI, I just released 1.5.366. This version now uses the Compose mode for "Data was bayered and not white balanced". It is now exactly the same as importing your DSLR stack into the compose module, choosing "L + Synthetic L from RGB, RGB" for "Luminance, Color", and giving the green channel double the exposure time of the blue and red channels.

I understand how to analyze the SNR for Path B output of dcraw, and get good results. I don't understand how to analyze the SNR of dcraw bilinear debayered tiffs that I use in Path A.

The two paths should yield - in theory - the exact same results.

Do I lose any SNR with the dcraw superpixels going into Star Tools?

All thing being equal, you shouldn't lose any signal. One image (Path A) is just "scaled up" by dcraw, then "scaled down" by StarTools. The other was never scaled up by dcraw, nor scaled down again by StarTools.

The only differences may be attributable to star alignment being better or worse (or the same) in the superpixel vs bilinear image, possibly having some marginal effect on stacking.

DSS white balances the .CR2 because when it calls dcraw to import the .CR2 raw files, it leaves out an essential dcraw option of '-r 1 1 1 1'. This means that dcraw does white balancing, which Ivo has stated elsewhere in the forum, that is messes up Star Tools processing. When DSS went open source, I found the actual error in the DSS source code. So I don't use Path D anymore.

Would you have the line numbers where the error exists? I don't have a Windows development machine, nor Visual Studio, but perhaps we could at least log the issue with the developers?

Also, to measure the gain, the data must be linear. Craig Stark describes a method of measuring gain by taking pairs of flats at different exposures, and analyzing the images using a program called ImageJ. Look at the 2009 articles here, SNR parts 1 thru 5. Part 3 describes how to measure gain and SNR.
http://www.stark-labs.com/craig/articles/articles.html

Craig is the man! His videos and articles are excellent.

Hi Ivo,
Very good. I will switch to your new version 1.5.366 of Startools, and stick with dcraw -h superpixel debayering before DSS and then Startools!

I have info here for DSS-4.1.0. Based on the announcement for DSS-4.2.0, I don't believe anything has changed with regard to white balance for raw files. I could be wrong. I'm sticking with 4.1.0.

In DSS-4.1.0-Release\DeepSkyStacker\RAWUtils.cpp, line 879, the function

BOOL CRawDecod::LoadRawFile(CMemoryBitmap * pBitmap, CDSSProgress * pProgress, BOOL bThumb)

assembles the dcraw command line to import the .CR2 files. It also sets some globals with a call to SetWhiteBalance() at line 996. Those globals aren't use in the dcraw call, though.

Here are the white balance options LoadRawFile sets for dcraw. The '-r 1 1 1 1' is not to be found in the function.
bValue = FALSE;
workspace.GetValue(REGENTRY_BASEKEY_RAWSETTINGS, _T("AutoWB"), bValue);
if (bValue)
{
// Automatic WB
argv[argc] = _T("-a");
argc++;
};

bValue = FALSE;
workspace.GetValue(REGENTRY_BASEKEY_RAWSETTINGS, _T("CameraWB"), bValue);
if (bValue)
{
// Camera WB (is possible)
argv[argc] = _T("-w");
argc++;
};

if (!m_bColorRAW)
{
// Document mode
argv[argc] = _T("-d");
argc++;
};

Clear skies,
Steve

Much appreciated Steve!
I opened an issue with this information on GitHub.
You can find it here.
Here is hoping the maintainers take it up.

Hi Steve,

Thanks to you, David Partridge has evaluated an agreed to our request to add an option to turn off white balancing.
He is saying it is scheduled for the next release, which would be 4.2.3.

Cheers!