StarTools

1.6.386
Hi everyone
Develop - Skyglow

Cannot add skyglow after a 'redo global stretch'. We need to close Develop then:
Develop - stretch images as is
Then we can add skyglow.

Not sure if this is the expected behavior.
Thanks

alacant wrote:1.6.386
Hi everyone
Develop - Skyglow

Cannot add skyglow after a 'redo global stretch'. We need to close Develop then:
Develop - stretch images as is
Then we can add skyglow.

Not sure if this is the expected behavior.
Thanks

Hmmm... Indeed. Looks like a bug - thank you for reporting this!

This should now be fixed in 1.6.387beta.
Thank you!

Thanks for the new update!

One query? Is there a reason that the Decon, Sharp and HDR modules have swapped places in the order on the side menu? (I've always done Decon before Sharp in the past and both these before HDR.)

almcl wrote:Is there a reason that the Decon, Sharp and HDR modules have swapped places in the order on the side menu? (I've always done Decon before Sharp in the past and both these before HDR.)

Yep! It's because the Decon module has had big update (documentation update to follow in the next few days).

Three reasons;

1. Due to signal evolution Tracking feeding Decon with the latest statistics on noise grain development, Decon will be able to achieve better results the closer you get to a final image. E.g. it will deconvolve more (or less) depending on how a pixel was stretched locally (and stretching locally is precisely what the Contrast, Sharp and HDR modules do!).
2. Reducing the Regularization parameter a little from 1.0 will - in good datasets - often allow you to bring out a tiny bit more detail at the expense of also bringing out noise grain with it. However, Decon now shapes this noise much like the new Grain Equalization Denoise (name still tentative module. E.g. it equalizes the noise grain by the same amount, everywhere. The equalization makes the noise a lot less distracting or even (virtually) invisible when the image is viewed at 100% zoom or lower (just like the Grain Equalization Denoise), analogous to image dithering. Zooming in will reveal the noise much more, so - again - the same considerations apply as with Grain Equalization Denoise; blowing up the image past its native resolution will reveal the noise grain, but viewing the image at native resolution or lower will hide much of it (much like image dithering). With all the above in mind, it is preferable to have that noise equalization not "meddled with" any further, as it has been optimised by Decon for the image as-is. Any further noise reduction is now smart enough to "communicate" with Decon about this and not touch the specific noise grain equalization contributions of Decon.
3. (this has always been the case, though is much improved now as well) Deconvolution is an ill-posed problem without a "perfect" solution. Ringing artefacts will always come into existence and most of the tweaking of the parameters in Decon is making sure that they are barely visible. The HDR module (and to a lesser extent, the new Sharp module) may exacerbate any remnant ringing artefacts. Therefore, running Decon after using these modules makes sure that this is not a (potential) problem.

Like color calibration, moving Decon so far down the processing workflow is really, really unorthodox when compared to other software. But the results and benefits should (hopefully) speak for themselves!
I've been testing the new Decon module with many datasets and - of course - have been comparing it to other implementations/results in other software. Honestly, I've been blown away by the results.

Great info, thanks Ivo!

Hi Ivo, how about putting the Decon workflow change explanation in a dedicated threat to alert more users? I stumbled over this by accident as a side not of a different topic.
Actually I feel this new workflow makes much more sense as the Stretching adjustments are now completed on all scales first before Decon hits in. Another advantage is the Inverse Star Mask that now may simply remain in place for both Sharp & Decon (and optionally Flux) modules

hixx wrote:Hi Ivo, how about putting the Decon workflow change explanation in a dedicated threat to alert more users? I stumbled over this by accident as a side not of a different topic.
Actually I feel this new workflow makes much more sense as the Stretching adjustments are now completed on all scales first before Decon hits in. Another advantage is the Inverse Star Mask that now may simply remain in place for both Sharp & Decon (and optionally Flux) modules

Spot on! 1.6 is still beta and the new Decon module is still under (final) development. This is actually still impacting the UI a little as well (e.g. there are some new parameters / options / name changes in the upcoming version).
I will be updating the docs soon. But until I'm sure things have been finalised, I don't usually make announcements (unless asking for beta testers/guinea pigs )

Its scope has been rather... ambitious But I got the cherry-on-top to work now as well; complete backward and forward propagation of the result during deconvolution for every iteration for the purpose of regularization. This separate algorithm is optional and definitely more taxing on your system, but it allows the regularization algorithm to evaluate an exact, stretched "hypothetical" human-visible result for each iteration. That said, the old (faster) method still provides very good estimates to the regularization algorithm of visible detail vs visible artifact/noise propagation without fully backward and forward propagating.