StarTools 1.9 preview

[decay]

Oh, and I just saw, that I used the GPU version with 1.8, but the 'CPU' version with 1.9 alpha.
Sorry! My fault.

[decay]

So this is my last post for today. Sorry for all this posts.
The ST 9 GPU version does not behave better than the CPU version (but it is much faster, anyway!) I've no idea, what could be wrong ... does anyone else have such problems?

Best regards, Dietmar.

[admin]

At full scale, SVD in 541 is a lot less objectionable on the artifacting and ringing, and a reasonable bump of DR to 65% or so from the default 50 was producing an acceptable result. And a subsequent bin, while not otherwise optimal as it sort of mushes things up, does not appear to resurrect the ringing and other issues that are showing up if binned first.

Interesting... I would very much think the opposite would be the case.

The "541 after with default 50 DR" overall result is indeed rather disappointing and not what I would expect from just 10 iterations.
Was this the result of deconvolving the entire ("All") image?

I would love to get my hands on that dataset to see if there is anything special about it.

The reason for the further tweaking of the deringing between 536 and 541, was that I found de-ringing was kicking in a little bit too quick, even in cases of mild deconvolution, which as you say, then leaves some detail on the table. This was particularly in bright DSO cores with lots of stuff going on. In my go-to test images this is now resolved, while de-ringing performance does not seem compromised. However, if there are cases where there is a regression in image quality, it is important to know about these cases.

@decay
I will try to further optimize the star PSF sampling mechanism and try to find some early abort opportunities. There's a lot that is going/kicked off when a new sample is added.

[Mike in Rancho]

Interesting... I would very much think the opposite would be the case.

The "541 after with default 50 DR" overall result is indeed rather disappointing and not what I would expect from just 10 iterations.
Was this the result of deconvolving the entire ("All") image?

I would love to get my hands on that dataset to see if there is anything special about it.

The reason for the further tweaking of the deringing between 536 and 541, was that I found de-ringing was kicking in a little bit too quick, even in cases of mild deconvolution, which as you say, then leaves some detail on the table. This was particularly in bright DSO cores with lots of stuff going on. In my go-to test images this is now resolved, while de-ringing performance does not seem compromised. However, if there are cases where there is a regression in image quality, it is important to know about these cases.

Oh boy, more files for the ol' "problem data" vault. Well, I suppose one must be famous for something.

The screenshot is an "All" image. I haven't used a deconvolution preview box since 1.6. GPU kind of obsoleted it, even with my old graphics cards and at my binning levels.

I will link my latest datasets below, but issues pop up in other data as well.

I was playing with some interesting M42 data currently posted on CN ("Reprocessing M42..."), and while not quite as harsh as it was with my most-recent NGC2403 set, I still ended up reverting to 536. Oh and again, I was binned to 35% so about 2000 pixels wide (maybe something to this binning?) Here's a screenshot from 541 --

MATx M42 451SVDscreen.jpg (281.4 KiB) Viewed 11328 times

There's still a fair bit of star ringing about the field. Turning on intra-iteration/centroid (as it is here) helped some, but added an interesting twist when I blinked the pre/post tweak. The deringing effect often ended up stronger on one side of the stars. If you look about, you can see what looks like flares on the side of quite a few. As said, that popped up with the change to intra-iteration, but with deringing already set to 50, I'm not sure of the true culprit and didn't keep experimenting. Ultimately I think a DR of about 65 was fair, but gave me fatter stars than 536 does (same settings except DR of 35).

Okay, as to my newest data. Linky: https://drive.google.com/drive/folders/ ... sp=sharing

Only 5 hours LRGBHa much like my M78, but not quite as bad. I could go either way in Wipe with Basic at 95%, or Uncal1 at 65/50 I believe it was. The RGB comes out pretty clean, as does the (faint) Ha, and the L is...interesting but not awful. It ends up with a shadow being created off to the side of the galaxy. Weird, but doesn't survive my OptiDev settings really. A big crop though, and everything is kind of perfect-like. No need for special Wipe settings, and no galaxy side shadow. Go figure.

For comparison purposes, I did a big crop so that I had just the galaxy and a few bright stars, and left it at 100%, no binning. Very different 541 SVD results compared to binned down. The stars at that scale and SVD do have some peculiar shadowing deep towards the core, but with a small bump in deringing overall I found them acceptable and quite nicely pinpointed actually. Who knows, at this scale could be it is resolving down to something in my optical train, or perhaps it's the way my Compose (L + synth L) plus the OptiDev set up the luminance going into SVD.

But...there's a box sitting here with a GPU in it, so maybe I can start processing at full scale. This galaxy does look pretty decent when processed at 100%. At least the higher SNR parts do.


Dietmar, most of the time I've actually been able to click on SVD star samples quickly and with impunity. But occasionally I get a set that seems to bog it down and then yes, hiccups and mini-freezes on selection, such that it acts like it wants to crash. I wait it out to make sure I don't crash it. I haven't done enough testing and note taking to discern the patterns yet, other than maybe it seems to be happening with OSC files more than my composed discrete filters? Even at similar binned resolutions.

[decay]

I will try to further optimize the star PSF sampling mechanism and try to find some early abort opportunities. There's a lot that is going/kicked off when a new sample is added.

Thank you, Ivo. I always wondered how you accomplish it to start processing while it is still possible to alter parameters (or set starfishies in this case). I assume, part of the calculations that are already done will be reused after adding a sample? Anyway, it's awesome

Dietmar, most of the time I've actually been able to click on SVD star samples quickly and with impunity. But occasionally I get a set that seems to bog it down and then yes, hiccups and mini-freezes on selection, such that it acts like it wants to crash. I wait it out to make sure I don't crash it.

That sounds very much like the way the 'old' ST versions behave for me, too. But this dramatically changed for me with one of the last alpha versions. (@Ivo, I could try to figure out, which version it was, if this would help). It's nearly unusable, the picking of the starfishies takes about 10 minutes But I do not understand, why this in not the case for you or for other users (for example Steve (@alacant wrote that it works fine on his i5, 8 GB. That sounds very similar to my system)). OK, my system is not a rocket, but I think it's OK and it works fine with ST 8 and with the early alpha versions of ST 9

[hixx]

Hi,
my suggestion to relief the mini hickup situation:
1) By default, the "Space"(Stars visible) preset would set Synthetic PSF to zero awaiting the user to click a sample star.
2) It would also preset to only 1 sampled iteration or two, until the user is has selected all stars.
3) Potentially it could have a break after 1 & 3 seconds in which it would check whether new samples got added. After 3 seconds without new sample star selected, it would start running the full number of default iterations (10).
not sure if any of that would be doable
clear skies,
Jochen

[Mike in Rancho]

Alrighty, I have a new 4K (UHD) monitor, and am already pulling my (sparse) hair out trying to get everything scaled in a way I like. Windows is thwarting me in many aspects of this.

Most icons and text I have to a decent size now, whilst having the overall W10 display scaling set to 100% in order to get the full resolution I paid for. The Taskbar and some stuff within File Explorer are still giving me grief.

As is ST, a little bit.

I tried highdpi and then largeui (are they the same?) from here: https://www.startools.org/downloads/tec ... k-displays

And then the extra stuff in compatability/dpi settings from here: viewtopic.php?f=8&t=1378

No joy. Then I tried it in 1.8, and it worked. So I think maybe it's just not enabled for 1.9a yet? I tried both 536 - last working SVD for my purposes - but gave it a shot in 541 also.

No worries if it is a final step and won't be on the to-do list until beta time or something.

[admin]

So I think maybe it's just not enabled for 1.9a yet? I tried both 536 - last working SVD for my purposes - but gave it a shot in 541 also.

Congrats on the new monitor and GPU!

You can find the high DPI and large UI stuff in the config file now.

[Mike in Rancho]

Congrats on the new monitor and GPU!

You can find the high DPI and large UI stuff in the config file now.

D'oh! I should have read that a couple weeks ago. DPI true but not both seems a good fit.

I never realized until just now what a nightmare dpi scaling can be. Most graphical type programs are more or less fine - ST now with the config, PI, XnView, Gimp - usable UI but images can show at true scale. I'm still fighting with Stellarium to get that how I want.

Mostly though it's browser trouble. I'm sure they all do it, but Firefox is upscaling images so that they are not true to dpi. CN, here, Astrobin. That's not good. And if I tweak the deep config of Firefox to use full 4K, the UI becomes a problem, as do many webpages, though you can scale up text only. ST's main site too.

Grrrr.

[happy-kat]

have some fresh data, comet, o enjoying using 1.9.541 cpu
optidev / crop / wipe / optidev / contrast / sharp / deconvolution all fine and save the mask
select colour startools bombs shut
repeated and exactly the same

i5 6 cores 48GB ram W11

deconvolution worked really nicely on the rich starfield, had loads of samples