skyglow

Bugs, glitches and unexpected behaviour.
Post Reply
alacant
Posts: 222
Joined: Mon Jan 25, 2016 7:03 am

skyglow

Post by alacant »

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
User avatar
admin
Site Admin
Posts: 3381
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: skyglow

Post by admin »

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!
Ivo Jager
StarTools creator and astronomy enthusiast
User avatar
admin
Site Admin
Posts: 3381
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: skyglow

Post by admin »

This should now be fixed in 1.6.387beta.
Thank you!
Ivo Jager
StarTools creator and astronomy enthusiast
almcl
Posts: 265
Joined: Wed Jan 21, 2015 7:15 pm
Location: Shropshire. UK

Re: skyglow

Post by almcl »

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.)
Skywatcher 190MN, ASI 2600 or astro modded Canon 700d, guided by OAG, ASI120, PHD2
User avatar
admin
Site Admin
Posts: 3381
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: skyglow

Post by admin »

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! :thumbsup:
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. :D
Ivo Jager
StarTools creator and astronomy enthusiast
almcl
Posts: 265
Joined: Wed Jan 21, 2015 7:15 pm
Location: Shropshire. UK

Re: skyglow

Post by almcl »

Great info, thanks Ivo!
Skywatcher 190MN, ASI 2600 or astro modded Canon 700d, guided by OAG, ASI120, PHD2
hixx
Posts: 254
Joined: Mon Sep 02, 2019 3:36 pm

Re: skyglow

Post by hixx »

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
User avatar
admin
Site Admin
Posts: 3381
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: skyglow

Post by admin »

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.
Ivo Jager
StarTools creator and astronomy enthusiast
Post Reply