ST Modules and Scale

[Mike in Rancho]

This topic arises out of Martin's concurrent SVD thread, wherein I believe I've learned I need to maintain a lot more resolution (perhaps no bin at all) in order to get post-SVD star shapes that I find palatable.

However, I still very much need to implement the SNR-increasing bin -- at some point, obviously subsequent to SVD.

This does take a long time and stresses the computer as, at minimum, I have to go though Wipe, AutoDev, and then SVD at full res. Possibly one of those Tracked Saves mentioned in another post could allow me to only do that once, and then use that saved file as a new starting point for various different processing attempts? But that's maybe for the future...

The current issue is, how do the various ST modules react to the binning scale, especially as ST is dynamic and always looking at the pixels?

In a thread earlier in the year I believe it was noted that the Wipe parameters should have the same effect whether binned before or after. SVD, we now know, is not the same and will act differently based on the scale, at least as to the stars (I haven't yet experimented as to the non-star target detail). I am curious if that also means that, at full resolution and not yet binned, I could perhaps increase the SVD parameters?

Likewise as to things like Contrast and HDR - does the scale matter depending on whether I perform them pre or post bin? Or to get the same ultimate effect, if I do them pre-bin (taking a long time but allowing SVD to "see" what has happened), would I need to increase various sliders and settings?

Does the concept make sense, or am I chasing my own tail here?

[admin]

Scale matters in so far that it (assuming you used binning to scale) affects signal-to-noise. This in turn will make modules behave differently. It also will - for obvious reasons - impact any module that has one or more controls that specify the scale on which you wish to operate.

With regards to the SVD star shapes, would you be able to give some examples? (a small crop of a dataset would be fantastic)

[Mike in Rancho]

Thanks again Ivo. Yes I always use binning within ST as my understanding is the module is superior. Only after I am done with ST will I use something like Gimp for resampling to CN-allowed sizes and selecting the jpg quality export % to also fall within the kb limitation.

You are right of course and the binning/SNR level is affecting ST's very dynamic module results. I tried to match processing last night with a binned dataset, as I would normally do, versus one kept at native resolution through Wipe, AutoDev, and a quick Contrast before going to SVD, after which I binned to the same scale to continue with HDR, Color, etc. And I couldn't get them to be identical (apart from the expected SVD differences which was the main testing goal). I might have to try things in a bit different sequence. Or it may not be possible.

I will have to come up with some better examples and screenshots, but I did quickly make these of a normally binned down and processed dataset once I reached SVD. Before and After button. The DSO target data (though mostly off screen here), as always refines very nicely in SVD, perhaps even better when binned before than if binned after SVD. The problem is I like stars, and want them looking nice along with the DSO. And certain stars, perhaps the medium and larger ones, will end up bright, blocky, and oddly shaped. Sometimes with weird lumps appended to them (not hidden double stars, I've checked!). I'm not sure what SVD is picking up on.

Wizard bin2k SVD bef.jpg (254.64 KiB) Viewed 5969 times

Wizard bin2k SVD aft.jpg (267.18 KiB) Viewed 5969 times

So, I'm trying to find a way to avoid this, either with my workflow of binning or processing pre SVD, or SVD itself. The data is weak no doubt, with limited integration and perhaps tilt and backspacing issues at the edges, but it's the most recent I have and was easy to access. I can try to find some better data in my archives but I've been changing a lot of hardware lately so I'd have to see what's available.

Still, even though noisy, and seemingly plagued with a bad OIII halo on a mag 5 star that I have to now figure out the source of, the DSO itself comes out not-half-bad. At least in the high SNR regions and using SNR-recovering binning, but then that scale difference seems to lead problems in SVD.

Link to my pathetic data if anyone wants to take a peek and perhaps point out where I might be handling it wrong: https://drive.google.com/drive/folders/ ... sp=sharing

That said, when looking over the Features and Docs again today, I noticed that even in the first sample image posted there at the top (blue and white nebulous region), the "after" side on the right is starting to show blocky and squared off star shapes -- though not nearly as bad as the really wonky star shapes mine turn into.

[admin]

Many thanks Mike,

This is very helpful!

The problem here appears to be that SV Decon is running into the limits of what the data can bear;

NGC 7380, 2022-08-06, 21x300L, Orion 6 95xCC, (Ha), ZWO ASI2600MM Pro_stacked_aligned_mul125.png (449.34 KiB) Viewed 5953 times

(a 125x linear multiply, allowing stars to unceremoniously over expose, so the stellar shapes can be better evaluated)

There is a fair bit of shape correction required, in order to make the stars in to neat points, and the samples are invariably noisy. For the deformities to go away, lots of iterations are needed, but with more iterations comes more "noisy" artifacts. It's a bit of a catch 22.

On the way to point lights, the deformities keeping morphing until they go away to become points. You can sort of see this behavior by increasing the dynamic range extension and turning off deringing, while upping the iterations.

The problem, right now, is that we have to abort half way before noise/artifacts become too objectionable.

Your dataset and the SV Decon module's behavior however, gave me some new ideas for improvements to the highlight handling in this scenario. I've implemented these and am currently testing.

The improvements may help make the deformities less obvious, and the Linearity Cutoff may no longer be required (it may be replaced with something else that helps control artifacts in over-exposing star cores better).

Thank you!

[decay]

Hi Mike and Ivo, this a very interesting and constructive discourse. Thank you both, a lot to learn here.

I would like to draw attention back to the other topic in this thread: bin vs./and deconvolution and suitable ST workflows regarding this issue. I’m not sure, Ivo, if your first reply answers Mike’s question – at least maybe not directly? I already addressed this also in some older threads/posts. e.g.:

viewtopic.php?p=12869#p12869

Regarding binning:
dx_ron wrote: ↑Mon Jul 25, 2022 2:12 pm if "bin-late" vs "bin-first" affects tracking's view of the noise term for any pixel
From my understanding of StarTools and the use of this module I would assume exactly that and therefore Bin should be used at the beginning of the workflow. I'm curious, if someone has other thoughts.

As for binning vs. deconvolution I can confirm what Mike wrote: With my images I have to leave enough resolution (bin down to 50% at 6000x4000 px sensor pixels) to get deconvolution to work. But these images seem to be a bit oversampled at the end and so I shrink them afterwards a bit further (not necessarily with ST). I think that’s some kind of trade-off or dilemma. In fact I would like to bin down enough at the beginning of the workflow, so that ST can take advantage of the additional SNR, but I can’t, because I have to leave enough resolution for SVDecon. I have no solution or idea for this.

@Ivo, would you agree to (Mike’s? and) my thoughts or am I on a wrong way? So what would be a decent workflow?

AutoDev →(Bin) → (Crop) → Wipe → AutoDev → (Contrast) → (HDR) → (Sharp) → SVDecon → Bin → Color → …

So, like Mike wrote, a second Bin after SVDecon? I tried that a couple of times with varying results. (And I sometimes had the feeling that ST had problems with the changed scale as the result of the second bin, e.g. wrong scales in the Denoise module. But I cannot confirm this at 100% right now.)

If this would be a reasonable workflow, it still shows the problem that the second AutoDev (final stretch) may not be the desired stretch as at this point there’s SNR missing which is only gained later on as a result of the second Bin.

(@Mike: regarding this:

This does take a long time and stresses the computer as, at minimum, I have to go though Wipe, AutoDev, and then SVD at full res. Possibly one of those Tracked Saves mentioned in another post could allow me to only do that once, and then use that saved file as a new starting point for various different processing attempts? But that's maybe for the future...

I often use Guy’s fine STReplay tool to get up to this point again. So, of course you have to wait for this to end, but STReplay does the work for you ...
)

And I guess, what Mike wanted to know, is if we had to work with ‘post bin’ (so working with not or little binned data and then do a Bin at the end of the workflow), would this hamper the resulting overall quality because ST’s (other) modules may not work that well on too less binned data?

Best regards, Dietmar.

[KlausKlaus]

Hi,

I guess it all depends on how each module‘s instance is put onto the stack. E.g. you can call Shrink several times w/ different presets which are each added to the stack individually. But for other modules I believe calling them again updates their existing instance down in the stack. W/o source code it’s hard to know which module belongs to either group…

CS, Klaus

[Mike in Rancho]

Ivo, Dietmar, Klaus, thank you for your thoughts!

Ivo, very interesting and useful description of the "inside the box" steps that deconvolution is making, iteration by iteration, on it's path to clarifying the data. I will read that again a few times.

I admit I never thought of blasting a stretch in order to reveal the acquisition flaws in those stars that SVD is picking up on bit by bit. Not that I know how to do a 125x linear multiplier...

Some wonky shape is indeed very much there, likely some combination of collimation, coma corrector backspacing, and tilt. Alas, my drawtube's visual back cannot be changed to a threaded connection or even a clicklock, so absent new focuser I may not be able to correct everything.

I believe the star you chose is towards the edge, so for sure things will be worse there. However, I have also seen "wonky blocky" SVD results towards the center, where those errors are far less, and the nearby SVD samples will be of better quality as well, unless I do SVD at the full resolution without binning - in which case SVD does seem able to turn even my stars into much more circular points.

Your image with star multiplier is also showing something well that I have been starting to see hints of, but have not been sure about yet, and that's the concentric ringing. Obviously not the rings around an Airy Disk, though they seem to act like them (brighter to fading). I think it must be some repetitive reflection, possibly involving the sensor surface glass, AR cover, and maybe filter wheel. I think at this point the coma corrector is too far away, on the other side of the EFW. Query what SVD thinks of those - it does seem to sharpen their resolution. Which actually is fine with me, just as it would for the spider vane spikes.

Dietmar, two things from your additions. One, in the workflow, I tend to use Crop before binning. Although both are, I believe, what one would call permanent modifications, ST remembers the crop settings upon data reload, as long as you don't close ST. So, if needed, you could give up, reload the file(s), use the same crop since it's already set, and then choose a different binning scale next.

Second, what I have been trying to do (and will work on this some more!) is come up with a way to get to SVD early at full res, then bin, and then utilize the other modules once the higher SNR is obtained. Yes I would rather use the "proper" carving down of detail via Contrast-HDR-SVD, but the weird stars bug me lol. Until what I've been doing is handling them via Shrink, or at the end sometimes heal, but usually a Layer blur on a mask that selects just beyond the little squares, trapezoids and pentagons that my stars turned into. But I'd rather do it in a different and better way. I will post up if I learn anything with more testing of early SVD (so far...it's noisy!...but the bin immediately after does help).

I tend to use logs, but yes I need to download the more current release of STReplay than the one I have which I think might be on my laptop. However, I think what I really need to help things along is a better GPU card.

[admin]

Ivo, Dietmar, Klaus, thank you for your thoughts!

Ivo, very interesting and useful description of the "inside the box" steps that deconvolution is making, iteration by iteration, on it's path to clarifying the data. I will read that again a few times.

The iterative nature of this type algorithm (Richardson-Lucy decon being the granddaddy of all these algorithms) is really helpful. It allows us (advanced algorithms) intervene if something is going the wrong, or re-adjust some parameters/assumptions we made at the start.
The PSF Resampling in StarTools is an example of this. It effectively resamples the PSF samples as they appear in the newly deconvolved image iteration. This way the "new" PSF samples can be used in the next iteration, and so on, and so forth.
Essentially, you keep showing deconvolution examples of what's "perfectly" wrong (a blurry point). And knowing that it needs to look like a perfect single-pixel point, it calculates a transformation that gets you closer to that perfect point.

Mathematically, it is a super simple operation, but the problem is that, due to noise and rounding errors, it destabilizes after as little as 1-2 iterations on real-world data. Keeping the algorithm from destabilizing is where all the work is.

I admit I never thought of blasting a stretch in order to reveal the acquisition flaws in those stars that SVD is picking up on bit by bit. Not that I know how to do a 125x linear multiplier...

It's a total hack.
Layer Module;

• Layer Mode set to Multiply Foreground Only
• Crank Blend Amount up to 500%
• Copy
• Paste Foreground (now you got 2500%)
• Copy
• Paste Foreground (now you got 12500%)

It's not something that is needed often, but it may come in handy now and then.

Some wonky shape is indeed very much there, likely some combination of collimation, coma corrector backspacing, and tilt. Alas, my drawtube's visual back cannot be changed to a threaded connection or even a clicklock, so absent new focuser I may not be able to correct everything.

Nothing too terrible. It's just that, the more the shape needs correcting, the more can go "wrong".

I believe the star you chose is towards the edge, so for sure things will be worse there. However, I have also seen "wonky blocky" SVD results towards the center, where those errors are far less, and the nearby SVD samples will be of better quality as well, unless I do SVD at the full resolution without binning - in which case SVD does seem able to turn even my stars into much more circular points.

Your image with star multiplier is also showing something well that I have been starting to see hints of, but have not been sure about yet, and that's the concentric ringing. Obviously not the rings around an Airy Disk, though they seem to act like them (brighter to fading). I think it must be some repetitive reflection, possibly involving the sensor surface glass, AR cover, and maybe filter wheel. I think at this point the coma corrector is too far away, on the other side of the EFW. Query what SVD thinks of those - it does seem to sharpen their resolution. Which actually is fine with me, just as it would for the spider vane spikes.

I've seen these before from other scopes - they seem to be part of the diffraction pattern as you surmise. I wouldn't be too worried about them.

As I said in the other thread though, ask yourself whether you need sampled deconvolution at the scale you are targeting. You may be better off with the pristine synthetic models instead. E.g;

NewComposite_presynthdecon_crop.jpg (209.89 KiB) Viewed 5904 times

NewComposite_synthdecon_crop.jpg (221.71 KiB) Viewed 5904 times

That's from the current development version though with better highlight handling, but I don't think the current 1.8 version is too far off... (if anyone really wants I can send a PM with a link to a development version).

[Mike in Rancho]

I had a chance to play with some of this stuff the past couple nights

The Layer hack was kind of interesting. I didn't even know we had copy and paste in there. My rendition was a lot brighter than Ivo's though, maybe I should have Wiped first.

More interesting was experimenting with SVD, using both this Wizard data and some even lower-integration and noisy East Veil SHO data.

I went right into it with cropped and binned data as I typically would, normal module workflow of Contrast and HDR before SVD. The chosen AutoDev for sure affects the quality colors of the apod mask. It also seemed to me that sometimes (maybe often?), the normal apod is a better choice than the more sensitive mask.

I used a lot of samples to try to help myself with the quasi "drizzle" effect discussed, and per the other thread also took plenty of red stars with no green or yellow when and where needed. Close inspection was sometimes needed. Plenty of stars seem to frequently be hiding a small double in very close proximity. I assume we do not want those within the white outlines? I avoided those entirely when I found them.

Then I tried out iterations higher than 10, up to about 22. Indeed, many stars do keep resolving in towards a point, and some of the odd shapes and bulges go away. At the expense of enhanced noise. Neat! And here I've always gone the other way -- backing off deconvolution settings -- in the face of unusual artifacting. So obviously that was something important that I needed to learn.

The added noise is trouble, but not surprising with these weak datasets. Plus, it does seem that the tracked denoise seems to have a decent handle on it anyway. Might need a bit of a boost by lowering scale and/or increasing brightness detail loss.

A couple things I do need to look into more. One is that some smaller stars seem to get to say, a hard-edged rectangle, and are stuck there, not rounding off. The other is the inclusion of some dimmer pixels within what should be the brighter resolved and more circular cores, on the larger stars. This becomes very noticeable once you've gone through Color. I am uncertain why that would occur. Might be answered already I just have to go re-read it.

I didn't yet try extending dynamic range nor did I alter linearity, but I don't know if either would keep any of those pixels from dimming down/coloring in that way.

[admin]

I went right into it with cropped and binned data as I typically would, normal module workflow of Contrast and HDR before SVD. The chosen AutoDev for sure affects the quality colors of the apod mask.

Hmmm... That should really not be the case. The quality colors are based on the linear, unstretched data. There is some translation to the on-screen stretched data (e.g. luminance inheritance) but that's really it. The created apodization mask, however, will differ per stretch. Is that what you're seeing?

It also seemed to me that sometimes (maybe often?), the normal apod is a better choice than the more sensitive mask.

In an idea situation, this should be the other way around. "Ideal" being stars nicely spaced out. The more pristine stellar profile you can catch, the better. But in a crowded field, that is a bit harder and you have to be careful not to include other stars.

Plenty of stars seem to frequently be hiding a small double in very close proximity.

That indeed makes things tricky.

I assume we do not want those within the white outlines?

Correct.

Give the AltStars preset a try. In my development build, I have moved SV Decon over to using that instead of the "regular" star mask generation. The algorithm behind it looks for tapering off pixels, so you can be much more certain that faint other stars are not included. It also incorporates some other quality measures that ensure better PSFs. It was a last-minute inclusion into StarTools 8, and I really wanted to explore its usefulness further, which I'm doing now.