1.8.525/526 MR1 Autodev, HDR, GPU acceleration in WIN11/10

[readerp]

Upgraded to WIN11 and here are some observations. Can't go back to WIN10 for a comparison. See attached pic.

Autodev leaves artifacts around the stars: a ring around the stars (this I noticed with winn10 also)

HDR seems to run a lot more slowly than Win 10, and I verified CPU running at near 100%, GPU running at 8% average.

HDR leave artifacts on the stars, a vertical line and dark dots in the center of the star

Hope these issues can be corrected.

Thanks
Pete

[admin]

Hi Pete,

Thank you for your report. Would you be able to point out the ring you are noticing, as well as provide a dataset and/or a method to replicate?

Your should find your HDR observations are all addressed in the documentation. The HDR module has been re-written, which comes with some changes in behavior; longer calulation times upfront, with near-realtime feedback thereafter. The nature of the calculations involved (lots of branching) means that they are ill-suited to GPU acceleration. Therefore, the HDR module remains CPU-heavy.

Thank you,

[Mike in Rancho]

Hi Pete,

I have yet to try W11. Only my laptop "qualifies" on hardware as it is, and just barely as an 8th gen i7.

Did you do a clean install rather than an upgrade, or perhaps after an upgrade?

A little search came up with a couple possibilities - might want to check if you have VBS etc enabled.

https://www.techspot.com/article/2349-w ... erformance
https://www.tomshardware.com/how-to/dis ... windows-11

But other than that I unfortunately don't know anything about why the same machine might be performing slower. Perhaps power usage/savings settings?

[readerp]

Hi Pete,

Thank you for your report. Would you be able to point out the ring you are noticing, as well as provide a dataset and/or a method to replicate?

Your should find your HDR observations are all addressed in the documentation. The HDR module has been re-written, which comes with some changes in behavior; longer calulation times upfront, with near-realtime feedback thereafter. The nature of the calculations involved (lots of branching) means that they are ill-suited to GPU acceleration. Therefore, the HDR module remains CPU-heavy.

Thank you,

Thanks Ivo,
Understand about the HDR speed.

The bright star in this cropped image has two artifacts
1. HDR: A vertical bar, on some other data the central disk gets a dark area rather than the vertical bar, or a dark spot in the center.

2. Autodev: If you zoom in on the brighter stars you can see a bright outer ring, or is it a dark ring within the disc about 80% out from the center. Film dev does not produce these artifacts. This I have noticed since 1.8 in general, also there when I was using WIN10. I have been working around it by replacing autodev stars with filmdev stars, but it would be nice if the artifact on the star cores was not there.

Ivo, I emailed you the stack, with detailed description of how I processed it. Hope that is useful.

CS
Pete

[readerp]

Hi Pete,

I have yet to try W11. Only my laptop "qualifies" on hardware as it is, and just barely as an 8th gen i7.

Did you do a clean install rather than an upgrade, or perhaps after an upgrade?

I did the upgrade, everything works fine. Ivo explained that HDR does not use GPU acceleration so this explains why it takes a while and why the GPU is sitting nearly idle.

CS
Pete

[admin]

Hi Pete,

Thank you for sharing the dataset with me.

With regards to AutoDev/ring; the "ring" you are seeing, is a real feature of your dataset and is not an artefact. This is usually caused by stacking light frames that vary in focus or seeing conditions. If you wish to avoid this, I would suggest culling the light frames that show poor focus/seeing. Filmdev merely hides these features by bloating the stars (as a result of the stretch that mimics chemical response of film grain), but that doesn't mean these features are not present. FWIW, there is also no real "ring" - when zoomed in, values only taper off from the centre but never increase.

Thanks to your dataset and instructions to replicate the HDR issue; I was able to confirm the HDR module glitch in over-exposing areas under certain circumstances.

I have just uploaded 1.8.527MR2 which should fix this issue. Any further trouble, do let me know!

[almcl]

Hi
Sorry to butt in on this, but I have just tried 527MR (GPU accelerated version) and SVD is still generating artefacts as per images below:

before SVD.jpg (39.71 KiB) Viewed 16639 times

after SVD.jpg (33.44 KiB) Viewed 16639 times

I can put the stack and a log in Dropbox folder if that would help?

[admin]

Hi Al,

Apologies for missing your post. This thread discusses two separate issues in AutoDev and HDR.
The SVDecon module is expected to generate some measure of artefacts depending on the settings chosen and the quality (and other characteristics of the dataset, such as linearity of your sensor's response). Deconvolution of close-to-overexposing areas is tricky and will never be 100% perfect.

If you'd like to share the dataset with me, I'd be happy to have a look at what sort of parameters would be suitable for that particular dataset.

Clear skies,

[almcl]

Many thanks, Ivo.

I've sent a PM with a drop box link to the stack and a few capture details.

Most grateful for any insights.

[admin]

Many thanks, Ivo.

I've sent a PM with a drop box link to the stack and a few capture details.

Most grateful for any insights.

Thank you for sharing the dataset with me Al.
I quickly processed it with bin (50%), crop, Wipe (defaults) and immediately went into the SV decon module.

This is the image before decon;

And this is the image after decon (default settings, with just a few suitable samples around the image clicked);

I cannot spot any significant artefacts and it appears to me stars (even over-exposing one) are being coalesced well, despite slight apparent differences in focus or seeing ("rings" in the non-deconvolved image, very similar to the ones mentioned elsewhere);

Might there be something else in your wofklow causing the issue you are seeing?