1.7
Hi everyone
How can I get the old behaviour of shrink (NOT tighten) which was a really good option in 1.6?
The one where I specify a number of pixels...
Cheers
shrink: 1.7 new module problems
Re: shrink: 1.7 new module problems
Set Regularization to 0, De-ringing to off, Iterations to 1, Mode to Dim, Color Taming to 0.
This should come very close to the less-sophisticated behaviour of the old module.
This should come very close to the less-sophisticated behaviour of the old module.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: shrink: 1.7 new module problems
Hi Ivo,
wouldn't these settings be worth a "Shrink" preset in the new module?
cheers
wouldn't these settings be worth a "Shrink" preset in the new module?
cheers
Re: shrink: 1.7 new module problems
Sure - if people would find that useful?
The behavior/purpose of the new module is quite similar to the old one, except that it is better at its job with fewer artefacts.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: shrink: 1.7 new module problems
Hi
Yes. The preset idea would be a great.
Finding the defaults on the new module too aggressive. Maybe start off with something milder?
Cheers and clear skies,
Steve
Re: shrink: 1.7 new module problems
Agree on the aggressiveness part.
I used the "Tighten" setting and while I found the module to produce less artifacts than the old one, the stars seemed to be reduced quite heavily (especially the mid size stars).
To take this one step further, instead of a constant value, the "aggressiveness" would need to be depending on the star size (FWHM). Big blown out stars would need more heavy treatment than dim ones. Not sure if this is doable, but it might be a thought.
I used the "Tighten" setting and while I found the module to produce less artifacts than the old one, the stars seemed to be reduced quite heavily (especially the mid size stars).
To take this one step further, instead of a constant value, the "aggressiveness" would need to be depending on the star size (FWHM). Big blown out stars would need more heavy treatment than dim ones. Not sure if this is doable, but it might be a thought.
Re: shrink: 1.7 new module problems
could the variable nature of stars suzes be done using successive masks that the user created to which the shrink was them applied?
Re: shrink: 1.7 new module problems
Hi all,
By popular request, 1.7.423 will have a "Classic" preset to mimic behaviour of the old module.
This module, at its core, relies on a morphological transformation. Unfortunately estimating FWHM for all stars accurately and reliably is pretty much impossible, particularly if they are small, over-exposing, if the image has been stretched or if they suffer from any sort of other distortion (CA, coma, etc.).
As with all modules, tweaking to taste is highly encouraged! If the defaults are too aggressive for your particular image, just dial down the number of iterations, experiment with the Regularization, etc.
I appreciate all the feedback! The main improvements over the old version indeed is its ability to shrink stars much more without artefacts cropping up.
The main motivation for improving the Shrink module is StarNet++. Not because it offers something StarTools cannot do (it can), but mainly because it seems to have popularised processing stars and background separately, which sadly, yields poor results in many cases.
As some of you know, I really dislike (most of) StarNet++ results because of the artefacts it tends to produces if not managed (very!) carefully. As I mentioned elsewhere;
What has made me most sad about StarNet++ is that these artefacts are passed off (and/or accepted) as real detail. As it is currently the seaon for the Veil nebula complex in the Northern Hemisphere, I've seen a good few widefield Veils being published with most of the nebulosity completely fabricated (in an attempt by the photographer to mitigate the many foreground stars - particularly in the visual spectrum).
IMHO StarNet's main innovation and use is star detection (e.g. for mask generation). However, it being trained on stretched datasets with manually inpainted replacement pixels means it will sadly only be good as those two constraints allow.
As I sum up;
By popular request, 1.7.423 will have a "Classic" preset to mimic behaviour of the old module.
This module, at its core, relies on a morphological transformation. Unfortunately estimating FWHM for all stars accurately and reliably is pretty much impossible, particularly if they are small, over-exposing, if the image has been stretched or if they suffer from any sort of other distortion (CA, coma, etc.).
As with all modules, tweaking to taste is highly encouraged! If the defaults are too aggressive for your particular image, just dial down the number of iterations, experiment with the Regularization, etc.
I appreciate all the feedback! The main improvements over the old version indeed is its ability to shrink stars much more without artefacts cropping up.
The main motivation for improving the Shrink module is StarNet++. Not because it offers something StarTools cannot do (it can), but mainly because it seems to have popularised processing stars and background separately, which sadly, yields poor results in many cases.
As some of you know, I really dislike (most of) StarNet++ results because of the artefacts it tends to produces if not managed (very!) carefully. As I mentioned elsewhere;
This is also a crucial difference between StarNet++ and, say, using the Heal module with a star mask in StarTools; the Heal module can be strictly parametrised to not introduce detail of a specific type. For example, it refrains from introducing higher frequency detail than what actually exists in the image (important if you want to use deconvolution on a healed dataset and not introduce ringing artefacts), while you can - crucially - also force it to always generate detail that is darker or lower frequency than what it replaces.I'm not a fan of StarNet++ for a few reasons. Intuitively star removal sounds like a great idea; remove the stars, work on what's "underneath", put them back again. However in practice the results are quite the opposite; I can almost always pick images that were processed (e.g. stars removed and then layered back in) using StarNet++ as they usually contain many artefacts and detail that doesn't actually exist in reality.
What has made me most sad about StarNet++ is that these artefacts are passed off (and/or accepted) as real detail. As it is currently the seaon for the Veil nebula complex in the Northern Hemisphere, I've seen a good few widefield Veils being published with most of the nebulosity completely fabricated (in an attempt by the photographer to mitigate the many foreground stars - particularly in the visual spectrum).
IMHO StarNet's main innovation and use is star detection (e.g. for mask generation). However, it being trained on stretched datasets with manually inpainted replacement pixels means it will sadly only be good as those two constraints allow.
As I sum up;
Improving the Shrink module should give people better control over the stellar profiles in their image, without the need for removal or separate processing (and thus hopefully providing an alternative to people who may be tempted to try StarNet++ for that purpose). The old module itself tended to introduce artefacts (creating a stringy appearance in low-sampled wide fields) when pushed too hard. The new module has much improved this as you (hopefully) agree.I actually really hope it is a fad that will go away soon. It is somewhat useful for star mask creation for applications that don't have decent tools (e.g. PI), but ST does, and all its modules are star-aware. Truth be told, I cringe every time I see an image where it was employed.That's just me though and it's a free world!
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: shrink: 1.7 new module problems
Ivo, everyone
Thanks for taking comments onboard. It is much appreciated and I'm sure it doesn't clutter things unnecessarily. One of StarTools' merits is that oh so clean and clutter free single window workspace instead of the usual windows with a histogram behind yet more windows with histograms mess.
Am totally in agreement about the current fad of starless or heavily star reduced images; let's hope it's just that and we can have images with proper stars once again soon. TBH, with the star control that AutoDev affords, I've not felt the need to remove them.
Cheers and clear skies,
Steve
Thanks for taking comments onboard. It is much appreciated and I'm sure it doesn't clutter things unnecessarily. One of StarTools' merits is that oh so clean and clutter free single window workspace instead of the usual windows with a histogram behind yet more windows with histograms mess.
Am totally in agreement about the current fad of starless or heavily star reduced images; let's hope it's just that and we can have images with proper stars once again soon. TBH, with the star control that AutoDev affords, I've not felt the need to remove them.
Cheers and clear skies,
Steve