Eliminating white balancing when using DSS

[admin]

I still can't see an advantage of going the longer TIFF route to be able to use the "not whitebalanced" option in ST

In this case, me neither!

Thanks for uploading the median stacks.

It definitely looks like something funky is going on during stacking - the data simply isn't as deep as the "regular" non-pre-debayered stack. No question.

I don't know what the cause of that could be. I assume you pre-debayered any calibration frames as well, right?

I'm not sure if related, but by coincidence, I noticed a faint, but noticeable cross-hatch pattern in the AutosaveTIFFmedian data on 1st AutoDev, which happened to scale the image at 26% to fit the image (intentional aliasing is one of the features of the scaling algorithm in StarTools). StarTools showing a pattern like this betrays an underlying pattern (repeating artefact) at a different frequency. It's possible that it is not significant, but it's not present in AutosaveRAWmedian and I thought I'd mention it;

crosshatch.jpg (425.27 KiB) Viewed 9724 times

As a sanity check, I did two processing runs of AutosaveTIFFmedian with the exact same parameters + settings, however with the only difference choosing between the two different options when loading/activating Tracking. As expected, the option that weighs channel precision as 1:2:1 for R:G:B (because a camera with a Bayer matrix records 2x more green samples) rather than 1:1:1, provides a tiny (tiny!) bit more small detail and definition (and has the nice side effect of killing more red hot pixels than it emphasises green hot pixels). With the data quite noisy the improvement is really marginal and you'd have to look closely while before/after toggling to appreciate it though...

[ecuador]

Yes I did the same DCRAW command on all calibration frames, weird, huh? I'll do the process again. This time I'll use an M31 set, DSS 3.3.4 (I thought 3.3.6 gave a bit better result processing RAW, but perhaps it has bugs and that's why it was pulled, so I'll go back to 3.3.4) and I'll use your command "-r 1 1 1 1 -4 -T -S 32767 -k 0 -o 0 -q 0 -t 0" instead of "-r 1 1 1 1 -4 -T -o 0 -q 0 -t 0" on all frames (it did not seem to be better with the Heart Nebula set, but perhaps I was too hasty in my judgement). I'll keep it at median for light and calibration frames.
I am preparing a tutorial for my local club and everyone doing astrophotography is using a DSLR under the same skies as I do, so the noise situation will be similar, hence I am testing with these sample sets to make sure I'll give the best advice. If I can get an advantage with the TIFF process, I will put it in the tutorial for people who want to do it. And I'll follow it myself of course

DSS has at times given me some funky results so it is a bit "temperamental", perhaps a different set will make a difference. The same (being "temperamental") is true about a few other astro-software (registax comes to mind immediately), so it seems they are written by people who know about algorithms, but are not software engineers. On the other hand, StarTools shows that the developer knows about software engineering in addition to image processing and I have said this before but I consider it silly that the 1.4 version is still marked as "alpha". Leave it at "beta" if you feel you haven't decided on the feature set, but "alpha" at such maturity is very old school IMHO

[ecuador]

Hmm, I don't know. Here is the TIFF and RAW-processed of M31: https://drive.google.com/open?id=0B1c3j ... W5QZWJ6Qkk.
On the one hand, the TIFF seems to have some easier to handle noise. On the other hand, when I try to get up to the faint edge of M31 and then make that edge more prominent e.g. with "moderate" or "heavy" life, the RAW gives me more of what I want (more cowbell anyone?). Anyone feels like looking at them, I'd welcome a comment.

Don't mind the weird purple artifact on the left, it appeared in both the sessions I tried using the TRF-2008 reducer, so it is probably from that. Strange though, a TeleVue lens causing reflections, but I've never seen it without that reducer.

On an unrelated note, how come the autodevelop that wipe shows temporarily, gives a much more proper development than the actual autodevelop without a ROI? It happens often for me.

[ChrisLX200]

...
Don't mind the weird purple artifact on the left, it appeared in both the sessions I tried using the TRF-2008 reducer, so it is probably from that. Strange though, a TeleVue lens causing reflections, but I've never seen it without that reducer.

Do you have a LP filter between the reducer and the camera? I found I could not use my IDAS filter together with a reducer (Televue NP127is and Televue 0.8x reducer) due to reflections. The filter was the source of the reflections and the reducer is fine without it.

ChrisH

[ecuador]

Do you have a LP filter between the reducer and the camera? I found I could not use my IDAS filter together with a reducer (Televue NP127is and Televue 0.8x reducer) due to reflections. The filter was the source of the reflections and the reducer is fine without it.

ChrisH

Yep, I did have a CLS filter between the reducer and the camera. That's unfortunate if I can't use it there - it works fine if it is between the camera and the field flattener. Thanks for the tip, I have only used the reducer on one session, it's been dreadful weather since then, so I haven't been able to do any testing.

[steve72614]

I've got a Canon T6 that produces 14 bit data in the .CR2 files.
I've been using dcraw to eliminate white balancing by generating tiffs as input to Deep Sky Stacker with this command --
dcraw -v -r 1 1 1 1 -4 -T -o 0 -q 0 -t 0 -k 0 -S 16383 *.CR2

I'm interested in the best possible output from Deep Sky Stacker to input to Star Tools.

This website describes stacking methods and shows that Kappa Sigma produces the best results.
http://www.clarkvision.com/articles/ima ... g-methods/
In figure 8 on this webpage, the top line is stacked with Kappa Sigma using 14 bit data.
In figure 8, the second line is stacked with Kappa Sigma using 14 bit data multiplied by 4 to produce 16 bit data.
The third and fourth lines are even better, but I'm not trying to go that far. In my mind, the 16 bit data is much better than the 14 bit.

Quotes from the webpage ---
A second set of 100 was computed as from a DSLR with linear 14-bits per pixel, then scaled by 4x to scale the 14-bits to 16 bits like that from some raw converters.
...
Bit precision and method are important in stacking. The averaging methods are superior to median combine. As digital cameras get better, with lower system noise, including read noise and noise from dark current, and as more images are stacked, the output precision of the stack must be able to handle the increase in the signal-to-noise ratio. Simple 14-bit precision is inadequate, as is 14-bits scaled to 16-bits (only a 4x improvement in precision) when stacking more than about 10 images.


I'd like to feed Deep Sky Stacker with 16 bit tiff data generated from the 14 bit .CR2 file. In other words, I'd like the least significant 2 bits of the data to be '00'. That way Deep Sky Stacker Kappa-Sigma can interpolate the data with more accuracy to remove the more noise. Of course I still want the non white balanced data, just want to multiply it by 4.

I'm not seeing how dcraw can do the multiply. Is there some free software somewhere that can multiply the .tiff pixels by 4, or do I need to study the .tiff spec and write it myself?

Thanks for reading!
Steve

[admin]

Hi Steve,

There is no nice way of saying this, but if astrophotography, signal processing and/or mathematics are of interest to you, then I'm sad to say that the website you visited contains mostly nonsense...
It has done (and continues to do) a lot of damage of informing astrophotographers new to the field (the author has a knack for spamming links to his site at every opportunity).

With this article in particular, the are a number of grave errors and logical fallacies.

Fort starters, the test data is flawed as the noise being used in the "test" is not applied Poissonian (like real shot noise) but additive Gaussian - this already demonstrates the grasp of the subject matter of the author. The distinction between applied and added noise is especially important the the very thing the author is trying to "investigate" (e.g. low signal areas).

It is abject nonsense to proclaim one statistical outlier rejection is "better" than another (it's like arguing a hammer is better than a drill), while comparing differently processed images is entirely useless, especially with the lack of a way to reproduce (a basic tenet of scientific experimentation).

To add insult to injury deconvolution is applied to stretched data (again showing the author's tenuous grasp of the basic mathematics involved).

Conclusions are then drawn - with apparent authority - based on non sequiturs, flawed test data, flawed methodologies and opaque processing. It may all sound plausible, but if you have a deeper look at what is offered, claimed and said, virtually every "article" on that website falls apart.

My humble advice to you is to close your browser tab and forget everything you have read on that site!