So what does DSS do wrong?

[perdrix]

Ivo,

In reply to another of my posts you rather more than hinted that DeepSkyStacker committed what were in your view cardinal sins in the image processing sphere.

So, pray please expound - exactly what does DeepSkyStacker do that is so awful? The only stretching that's performed before the "post processing bit" which I don't encourage people to use is a 12/14 to 16 bit linear stretch of camera raw data which surely can't a problem.

David

[admin]

Hi David,

Thank you very much for engaging on this - it is much appreciated!
For those following along, David is (do correct me If I'm wrong!) addressing this request for review/comment;

While I have you, this has been my main gripe with DSS (as well as a source of many words of support emails, documents and tutorials); its defaults and workflow invite (or singularly introduce!) deviation from modern best practices. By "modern" practices, I mean practices and signal processing as performed by other software such as PixInsight, Astropixel Processor and some other free stacking solutions. I'd be happy to elucidate if it is helpful for DSS development!

Let's get one thing clear from the start; it's not so much DSS or its code that commits any "sins" (now that white balancing and matrix correction can be turned off) or is in any way "awful", it's the choice of default settings upon a fresh install that - unwittingly - makes a new user output data that is not usable for many other post-processing purposes (e.g. inter-channel noise analysis, deconvolution, color calibration, background normalization).

Before I expound on these, please note also that it is entirely possible these things may have changed or improved in the latest version(s).
Nevertheless, here are some suggested deviations from the defaults that would make DSS' output and workflow more in line with other programs and software and - possibly - less frustrating for people new to the hobby;

• DSS' default policy of "applying" a stretch rather than "embedding" a default stretch is (in DSS parlance), by far, the biggest bug bear and the source of most confusion and support requests. As you know, any non-linear operations make a dataset unsuitable for further processing by many algorithms and procedures, including - but not limited to - deconvolution, colour calibration, background modelling and subtraction, as well as many types of noise analysis reduction tools. It really trips up people, not just StarTools users, but also users of other post-processing applications (GIMP, Photoshop). Nonchalance about linearity vs non-linearity is something that an aspiring astrophotographer can ill afford - it is one of the first things you should be aware of when delving deeper into processing of astronomical images. EDIT: most other applications (StarTools excluded - it has Tracking) have the concept of a "screen stretch"; a non-permanent, controllable stretch that allows viewing of the linear data, with the understanding that the stretch - if so desired - can be made permanently. DSS clearly, implicitly, has the same functionality but the choice of whether the stretch was a "screen stretch" or a "real stretch" is only made retro-actively by choosing "embedded" or "applied". It would clear up a lot of confusion if this important functionality was not hidden in a file dialog, but instead was available along with the stretch functionality. EDIT2: This confusion/uncertainty of what is applied when, is likely also the reason why people prefer(ed?) to use the autosave.fts or autosave.tiff files and don't/didn't "trust" the save functionality.
• AHD Debayering attempts to reconstruct detail in single frames, and can/will introduced considerable "zipper" artifacts in individual frames in the presence of noise. What's more, such reconstruction is only useful/successful if a dataset is not oversampled. If these artifacts survive the rejection outlier process, they will introduce more noise at best and correlated (non-Poissonian noise) at worst (I remember a comment from Luc to this effect as well). For these reasons all other AP software packages I know of, do not offer AHD and rely on non-reconstructive VNG, bilinear interpolation or home-grown astro-specific debayering algorithms instead. Really, it is an option that doesn't belong in an AP-specific application and may cause photography veterans (but astrophotography newbies) to select it in a mistaken belief it will yield better results as it's the "most advanced" debayering algorithm on offer.
• Per Channel Background Calibration and RGB Channels Calibration may be necessary for the Kappa-Sigma Clipping rejection modes to function, however they interfere with a post-processing application’s ability to estimate inter-channel noise statistics as well as ability to recover colour (in the case of RGB Channel Calibration). A workaround may be to "undo" the effects of the normalisation once a sample has been chosen by the rejection algorithm. Having one of these settings enabled by default is by far the second biggest cause for support requests; "Q. Where has my colour gone? How do I get it back in StarTools? A. You can't. Go and restack."
• DSS' default policy of saving TIFFs with (a specific type of!) compression enabled by default is not consistent with the behaviour of other applications. I am unaware of any other applications that force compression (PhotoShop, GIMP, Nebulosity, etc.) by default. This choice reduces compatibility, not just with StarTools, but with any other reader implementation that implements TIFF 6.0, Part 1: Baseline TIFF only.

If any of the above points are not clear or require more information, please ask!

An example of a 3rd party tutorial that touches on most of the above points as they exist(ed) in 3.3.4;
https://astro.ecuadors.net/processing-a ... startools/

EDIT3: An example of zipper artifacting (AHD vs bilinear) in a noisy terrestrial scene. This scene is not oversampled and therefore AHD demonstrates superior detail recovery in the (more in focus) fronds, but at the expense of zipper artifact introduction in the (not in focus) shadows. In an oversampled scene (similar unfocused detail to the shadows), AHD would not improve detail, while only introducing artifacts.

AHDvsLinear.png (73.38 KiB) Viewed 4158 times

In general - if you are able - you may wish to evaluate applications such as PixInsight and/or Astro Pixel Processor to study some design decisions in these applications and see if you might find them useful for applying to DSS.

Perhaps some DSS users here (I know there are many!) might want to chime in here as well.

EDIT4: I just saw this analysis of DSS' stretching posted on CloudyNights a couple of hours ago. I'm still trying to digest the conclusions here, but it appears again there is confusion and/or discrepencies with regards to autosave.tiff, stretching and the result when saved.

Thank you again & wishing you clear skies!

[admin]

David,

I'm once again going through the same sort of DSS support with many emails back and forth to get a new AP enthusiast to produce something useful.
With his permission, you may find it useful if you are privy to the problems (seemingly, again, caused by unhelpful default settings) that we are facing?