1.8 closed alpha feedback

[Mike in Rancho]

I did just have an SVD crash in 505. Standard Startools crash, meaning the program just disappeared.

Was processing some CN user data, and opened as linear instead of center option because I think they channel neutralized despite saying it was just the plain stack.

I think it was a 533MC, so the square 3000x3000 or so. Cropped and binned to about 2000x2000. Wipe. AudoDev. Then I just went straight to SVD. While selecting squares it crashed out. I had maybe picked a dozen or 15 stars at that point? Maybe I selected too fast.

Windows 10, i7-8550U, 32GB, nvme SSD, with the 940MX chip selected over the Intel chip for ST to use.

As a second matter - though maybe this is already mentioned somewhere - if a star in apod has a green core, but then a tiny little red center or dot within that green core, is that a good star or a bad star?

[admin]

I did just have an SVD crash in 505. Standard Startools crash, meaning the program just disappeared.
Windows 10, i7-8550U, 32GB, nvme SSD, with the 940MX chip selected over the Intel chip for ST to use.

Dang
If it just disappears that is usually an out of memory condition or a driver issue. I haven't experienced anything like this here, but i'll keep an eye out. Thank you!

As a second matter - though maybe this is already mentioned somewhere - if a star in apod has a green core, but then a tiny little red center or dot within that green core, is that a good star or a bad star?

It is best avoided, but can be used if you have nothing else. It means that it is getting to close to being over-exposed. Being close to overexposure causes most sensors to respond non-linearly (and therefore making the sample less/not suitable for basing a PSF off, which needs to be perfectly linear).

A lot of these ringing star defects

Theory of gray holes....

Sometimes, over exposing star cores are not fully white, but rather a "noisy grey". This can be caused by the sensor, or the stacker (including on how flat frame calibration is performed).

I'm still thinking about how to deal with this better.

[Mike in Rancho]

Thanks Ivo!

I did run through the same data again with no issues, though I was more cautious about star selection speed. I imagine it's related to the fact that ST is always "getting started" immediately upon the change of any parameter - which of course is a nice thing. But you can kind of sense when ST starts grinding away from the little circle timer thing and of course the increase in CPU fan speed lol.

I haven't had a crash on this laptop since the 1.7 alphas and upping the TDR delay. But I had only made it 10 seconds. Just changed it to 30 so we'll see if that had anything to do with it.

That said, I've never had an ST crash that was anything other than just disappearing. My old desktop always does that too starting off the color module, despite an extended TDR (and the crash happens far sooner than the delay time anyway). On that I think it might be some kind of copy function in the GTX460? But no matter on that old thing.

Practicing with some of my own new data just now, I am noticing it indeed may be oversaturated stars that are giving trouble. For sure the larger stars, which would tend to be the overexposed ones of course. 1.8 is working great on things like nebula detail, and okay on smaller stars, but the big ones give it fits. They actually get larger rather than smaller or more resolved. I think it's the white ringing that was mentioned before which makes it seem like this.

To control them, I have been backing off the iterations, even down to just 5, which is too bad for nebular detail. On top of that a little extra dynamic range, increase the linearity cutoff, and max out the deringing (there's a lot of dark ringing). But even with that the stars are still a bit wonky and need some cleanup in layer module following denoise.

I don't know if it cuts against the philosophy, but it still seems to me it would be useful to have an apply/don't apply mask just like we had in 1.7 in order to keep the larger stars from going off the rails.

And speaking of masks - one thing that might be handy for the apod mask would be to match the zoom level and field of view to what one was working on when pressing the mask button. At times I've wanted to unmask a star that's too close to a nice green-core star that I want to blue box, but in switching from the reddish sample selection screen to the mask module it's like - wow, where am I?

[Stefan B]

Hi Ivo,

Yesterday I had a crash to with 505 during quickly selecting stars for SVDecon. FYI.

To control them, I have been backing off the iterations, even down to just 5, which is too bad for nebular detail. On top of that a little extra dynamic range, increase the linearity cutoff, and max out the deringing (there's a lot of dark ringing). But even with that the stars are still a bit wonky and need some cleanup in layer module following denoise.

I don't know if it cuts against the philosophy, but it still seems to me it would be useful to have an apply/don't apply mask just like we had in 1.7 in order to keep the larger stars from going off the rails.

Hi @Mike in Rancho ,

I agree that a mask for brighter star would be a useful feature. Meanwhile I've undone the deconvolution of brighter stars by using the layer module. A mask for brighter stars was applied and the 'Undone Fg' option used. Thus the effect was undone on the masked stars. Might be a workaround for you as well.

Best regards
Stefan

[Mike in Rancho]

Hi @Mike in Rancho ,

I agree that a mask for brighter star would be a useful feature. Meanwhile I've undone the deconvolution of brighter stars by using the layer module. A mask for brighter stars was applied and the 'Undone Fg' option used. Thus the effect was undone on the masked stars. Might be a workaround for you as well.

Best regards
Stefan

Excellent trick, thanks. I always forget about the undo in layer. As soon as I saw this on my tablet I had to try, but the laptop was busy acquiring data so I had to use the desktop. No color module available on that. But I went through SVD and then tried the reversal. You have to click through the warning about tracking of course.

I imagine this could be somewhat like adding RGB stars to NB - getting the mask and blend right will be key. Probably some fuzz needed. Without color later I couldn't tell. I also wonder what might be lost for the tracking by using layer, per the warning?

Much needed though. 1.8 SVD is doing amazing things for detail (I made a pretty decent grayscale Crescent Nebula for 3 hours of LeNhance data), so much so that I didn't use any contrast, HDR, or sharpen. Do we need to anymore? Maybe just very judiciously, knowing that SVD is still to come.

The star bloating is troublesome though, so glad to try out this fix for now. Even though it's "fuzzier," the core of the raw pre-SVD star is much tighter, surrounding by a fairly smooth halo.

I've also been making frequent use of the correlation filter in Wipe - another big new feature I like in 1.8. My last processing was really just Wipe, AutoDev, SVD, SS, and denoise. Then a slight layer blur of a couple ticks on star cores for cleanup. That's it!

[Mike in Rancho]

Another star selection crash in 505 just now.

Same 32GB i7 laptop. Data was about 3K x 2K after a 50% bin, wipe and autodev, then straight to SVD. I had picked maybe 5 stars by that point. Had gone into mask a couple times to remove green mask from a nearby star. I had just clicked a blue square to unselect it, then gone over to select a different star. Was not moving terribly fast actually, but perhaps a bit too much.

Also still a bit uncertain on guidance. The instructions state you can go into the apod mask to unmask stars that are too close to, say, a nice green core star that you want to blue box. But they also state not to select stars too close to other stars. Does that mean in general the surrounding background must be clean, the way it also states not to select those within nebulosity (sometimes not real possible), or does it just mean don't have more than one apod mask star circle within the boundary of single a blue box?

[admin]

Thanks Mike, Stefan,

Though the crashes/closures are hard to replicate, I'm taking some time to clean up multi-threading.
Lots going on behind the scenes that needs to be kept in sync between UI, CPU/worker threads and GPU threads!

Practicing with some of my own new data just now, I am noticing it indeed may be oversaturated stars that are giving trouble. For sure the larger stars, which would tend to be the overexposed ones of course. 1.8 is working great on things like nebula detail, and okay on smaller stars, but the big ones give it fits. They actually get larger rather than smaller or more resolved. I think it's the white ringing that was mentioned before which makes it seem like this.

I don't know if it cuts against the philosophy, but it still seems to me it would be useful to have an apply/don't apply mask just like we had in 1.7 in order to keep the larger stars from going off the rails.

This is one of the last outstanding major issues I'm still trying address, though the issue should usually only happen when trying to push the data too hard. If you'd like me to have a look at a particular dataset, I can maybe see if this is the case here?

And speaking of masks - one thing that might be handy for the apod mask would be to match the zoom level and field of view to what one was working on when pressing the mask button. At times I've wanted to unmask a star that's too close to a nice green-core star that I want to blue box, but in switching from the reddish sample selection screen to the mask module it's like - wow, where am I?

Thank you! This has indeed been requested before (@hixx ). Expect this to be included in the next alpha.

does it just mean don't have more than one apod mask star circle within the boundary of single a blue box?

Mostly that, however you will want to make sure that the stellar profile from any neighboring star does not "mix" with a selected star. All samples need to be well-isolated with a "text book" stellar profile that tapers off in all directions. E.g. you don't want it to ramp up again because some other star is nearby.

[Mike in Rancho]

Thanks Ivo! Good work going on here. I'm starting to take to 1.8 more and more.

I've actually been having better luck lately, even with the SVD settings at more or less their defaults. I just pick the stars. That may be because this is a more "typical" DSO image - Fireworks galaxy. Tiny even at 900mm! But with a very busy starfield and a nice open cluster off in the corner.

The data that gave me some large star trouble earlier was a glob, and the Crescent nebula. I will see if I can figure out what is behind it - maybe the pixel scale I am working at, or different uses of prior modules. And I'll also see if things still hold pretty good when I try to crop in on the Fireworks galaxy.

And thanks for the tips on the apod mask selection. So primarily keep other apod star circles out of the blue box, but preferably keep it clean overall. Of course, my data doesn't like to cooperate that way. I do sort of laugh at the SVD instruction page on that - three beautiful green core stars with nothing in their immediate background. Makes it seem like those should be found everywhere!

Maybe if the blue boxes were also variable...(kidding).

I also found another hidden default change - we should start a running list somewhere.

So far I think I have:
SS gamma .75 instead of .50,
Top denoise wavelet increased,
Auto star in mask at 6 instead of 8,
And the newest - deringing off in Shrink instead of 1.5

That had me a little baffled when things weren't doing what I expected, until I found that.

Anybody else find any?

[alacant]

Hi Ivo, everyone
Segfault when selecting stars for svdecon.
Sometimes, not always. Usually after around 10 stars have been selected.
kubuntu 20.04:

Jul 15 12:02:55 steve-desktop kernel: [ 4717.759915] perf: interrupt took too long (4954 > 4953), lowering kernel.perf_event_max_sample_rate to 40250
Jul 15 12:03:29 steve-desktop kernel: [ 4751.561728] StarTools-Linux[7029]: segfault at 7fbd3bd544a8 ip 000055c6c998732e sp 00007ffe3d874210 error 4 in StarTools-Linux64-GPU[55c6c9945000+22e000]
Jul 15 12:03:29 steve-desktop kernel: [ 4751.561739] Code: af fb 48 c1 e7 03 e8 a1 e6 fb ff 49 89 c4 49 89 46 50 48 85 c0 44 8b 5c 24 20 4c 8b 44 24 28 0f 84 ca f9 ff ff e9 eb f8 ff ff <49> 8b 04 c1 4a 89 04 d2 4c 89 d0 e9 26 fc ff ff 44 89 5c 24 38 48

Thought it maybe the GPU version but not so:

Jul 18 13:14:41 steve-desktop kernel: [19881.527059] StarTools-Linux[28570]: segfault at 7f3dfb222010 ip 00007f3e938407e0 sp 00007ffefd6ea988 error 4 in libc-2.31.so[7f3e936d7000+178000]
Jul 18 13:14:41 steve-desktop kernel: [19881.527069] Code: 16 c0 c5 fe 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff <c5> fe 6f 26 c5 fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0

[Carles]

I've just noticed that when clicking "X" key for screenshot, it overwrites the previous screenshots starting by ~1.
For instance, I had 4 screenshots done already in ST folder, I started ST fresh (1.8.505) and when done an screenshot with X , I was expecting the file screenshot-5.jpg... but instead the pop up window showed screenshot-1.jpg. I've kept pressing x and it kept overwritint the remaining existing 3 screenshots, then started making new (5, 6...) is that a bug? or a feature?

Regards

Carles.