HDR module in 1.8.515 Public Alpha is extremely slow
Re: HDR module in 1.8.515 Public Alpha is extremely slow
I'd agree that the results can be good at 50 pixels and below, but we all know what this hobby/obsession/addiction's like, right? I'd always want to know whether I can go to higher context size settings and squeeze more out of the image. It would be terribly frustrating if I couldn't.
I'm actually talking to my local PC build specialist, who put my music PC together, about the best way to upgrade, but before I do I'd like to see how the alpha version develops. If this version of HDR does make the stable public release, I'll have a little cry, then consider my upgrade options.
I'm actually talking to my local PC build specialist, who put my music PC together, about the best way to upgrade, but before I do I'd like to see how the alpha version develops. If this version of HDR does make the stable public release, I'll have a little cry, then consider my upgrade options.
Not so much boldly going as randomly stumbling where plenty of people have been before
Re: HDR module in 1.8.515 Public Alpha is extremely slow
These are some great (and helpful) analyses!
Like most algorithms, this one works by evaluating the immediate neighborhood of every pixel. The size of that neighborhood/window is "Context Size" x "Context Size" pixels. Which is obviously a exponential relationship; increase this parameter and the amount of operations your poor CPU has to perform grows exponentially.
The upshot is that it scales extremely well across CPU cores (of which a 4th gen mobile CPU only has 2!). Another downside, OTOH, is that depending on CPU cache size, certain window ("Context Size" x "Context Size") sizes start becoming too large for the cache, requiring to hit (slow) RAM more, which in turn slows things down quite a bit as well.
Indeed similar/related algorithms have typically used lower resolution input + interpolation. This works up to a point, except for fine detail.
@BrendanC I really, really hate the idea of forcing people to fork out more money on better hardware (it is important to me that AP remains accessible to anyone!), so I'm working on acceptable approximations of the algorithm for the next alpha. Particularly the local Gamma correction solver can very likely make do with a lower resolution and more aggressive interpolation.
Please bear with me as I try to figure out a solution!
Like most algorithms, this one works by evaluating the immediate neighborhood of every pixel. The size of that neighborhood/window is "Context Size" x "Context Size" pixels. Which is obviously a exponential relationship; increase this parameter and the amount of operations your poor CPU has to perform grows exponentially.
The upshot is that it scales extremely well across CPU cores (of which a 4th gen mobile CPU only has 2!). Another downside, OTOH, is that depending on CPU cache size, certain window ("Context Size" x "Context Size") sizes start becoming too large for the cache, requiring to hit (slow) RAM more, which in turn slows things down quite a bit as well.
Indeed similar/related algorithms have typically used lower resolution input + interpolation. This works up to a point, except for fine detail.
@BrendanC I really, really hate the idea of forcing people to fork out more money on better hardware (it is important to me that AP remains accessible to anyone!), so I'm working on acceptable approximations of the algorithm for the next alpha. Particularly the local Gamma correction solver can very likely make do with a lower resolution and more aggressive interpolation.
Please bear with me as I try to figure out a solution!
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: HDR module in 1.8.515 Public Alpha is extremely slow
A "Quality" parameter has been added to the HDR module in 1.8.516 (now up for download) to speed up local gamma correction solving, at the expense of some precision. Let me know if this makes the module more usable for you.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: HDR module in 1.8.515 Public Alpha is extremely slow
I've played around with this briefly and it does look like it's going to help quite a lot. In fact, I can't tell much difference in quality between low and high, but there's definitely a big improvement in time.
I'll be looking into this more tonight, trying to replicate the tests I did previously, but it seems that low and medium are doing a good job.
I'll be looking into this more tonight, trying to replicate the tests I did previously, but it seems that low and medium are doing a good job.
Not so much boldly going as randomly stumbling where plenty of people have been before
Re: HDR module in 1.8.515 Public Alpha is extremely slow
OK, I've been through the times and here's what I've found - graphic only, because I can't figure out how to copy/paste an Excel table or create an HTML one! Also, as before, I didn't go above 80px full screen because it was going to take too long.
Thoughts are:
* I think the quality setting helps, because I can go up through the levels ie look at a smaller area with ROI at a low context setting and low quality, and then when I'm happy, render the full picture (and go to mow the lawn).
* I'd have expected all the high quality times to match the previous times, but I guess this isn't an exact test, and I did have to redraw the ROI a couple of times.
* The times for low and medium quality are very similar overall. I wonder whether you could go lower with the low quality?
* In fact, I have great difficulty telling the difference between low, medium and high quality! I looked at three images, taking the defaults, at low, medium and high, and even pixel-peeking doesn't reveal anything, to my eye (just going as far as HDR, not then going on to sharp, decon, colour etc). This could say more about my acquisition than anything however (or my eyesight).
* I still don't know what spec of machine would be able to render a larger image at the 101 pixels context size and high quality within a reasonable time. Certainly not mine! Is there an argument for making 50px or 60px the maximum setting?
If it helps, the timings spreadsheet and low/medium/high examples are here: https://1drv.ms/u/s!AqovBuVZMwj3kZMprbU ... A?e=qAu5qv
Hope this helps!
Cheers, Brendan
Thoughts are:
* I think the quality setting helps, because I can go up through the levels ie look at a smaller area with ROI at a low context setting and low quality, and then when I'm happy, render the full picture (and go to mow the lawn).
* I'd have expected all the high quality times to match the previous times, but I guess this isn't an exact test, and I did have to redraw the ROI a couple of times.
* The times for low and medium quality are very similar overall. I wonder whether you could go lower with the low quality?
* In fact, I have great difficulty telling the difference between low, medium and high quality! I looked at three images, taking the defaults, at low, medium and high, and even pixel-peeking doesn't reveal anything, to my eye (just going as far as HDR, not then going on to sharp, decon, colour etc). This could say more about my acquisition than anything however (or my eyesight).
* I still don't know what spec of machine would be able to render a larger image at the 101 pixels context size and high quality within a reasonable time. Certainly not mine! Is there an argument for making 50px or 60px the maximum setting?
If it helps, the timings spreadsheet and low/medium/high examples are here: https://1drv.ms/u/s!AqovBuVZMwj3kZMprbU ... A?e=qAu5qv
Hope this helps!
Cheers, Brendan
Last edited by BrendanC on Fri Oct 08, 2021 7:59 pm, edited 1 time in total.
Not so much boldly going as randomly stumbling where plenty of people have been before
-
- Posts: 159
- Joined: Thu Jul 17, 2014 8:20 pm
- Location: Green Valley, Arizona
Re: HDR module in 1.8.515 Public Alpha is extremely slow
I'd like to offer a thought about the speed of StarTools. You can look at this issue from two points of view: the speed of individual tools, or the total length of time for producing an excellent, finished image.
I believe there is a paradox here. Even though some tools in StarTools are processor-intensive and require a lot of time, the aggregate time for creating a a high quality photograph is often remarkably short. Some of my colleagues in Sonora Desert Astro Imagers have been testing StarTools against PixInsight and they agree: for the complete processing job, StarTools can be dramatically fast.
Russ
I believe there is a paradox here. Even though some tools in StarTools are processor-intensive and require a lot of time, the aggregate time for creating a a high quality photograph is often remarkably short. Some of my colleagues in Sonora Desert Astro Imagers have been testing StarTools against PixInsight and they agree: for the complete processing job, StarTools can be dramatically fast.
Russ
-
- Posts: 1153
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: HDR module in 1.8.515 Public Alpha is extremely slow
That's for sure Russ. We've been spoiled by GPU for a while now, handling any number of tasks far faster than I read people posting about with other software.
Brendan I don't think 506 alpha had any context size in the old-HDR, at least not in a way so as to be comparable. Did you mean 515a, before the quality options?
And again that Intel 4600 has 20 compute units? I'm wondering how the GPU-intensive modules work, as it does not seem to benchmark very well. But in any event, HDR is all about the CPU.
If you want to also provide the underlying dataset and the log to get the data to the HDR module, maybe we can get some comparisons done between people with different hardware on the same file. Might also be good to time a SuperStructure on it, so that we can get a feel for different GPU's and not just CPU's.
Just an idea.
Brendan I don't think 506 alpha had any context size in the old-HDR, at least not in a way so as to be comparable. Did you mean 515a, before the quality options?
And again that Intel 4600 has 20 compute units? I'm wondering how the GPU-intensive modules work, as it does not seem to benchmark very well. But in any event, HDR is all about the CPU.
If you want to also provide the underlying dataset and the log to get the data to the HDR module, maybe we can get some comparisons done between people with different hardware on the same file. Might also be good to time a SuperStructure on it, so that we can get a feel for different GPU's and not just CPU's.
Just an idea.
Re: HDR module in 1.8.515 Public Alpha is extremely slow
You got me bang to rights on the alpha naming, apologies for that.
I've put the original FITS file and StarTools log file into the OneDrive folder.
Regarding the time, I agree that StarTools offers a super-quick way to get excellent results, but the HDR module seemed to go way, way, way beyond the processing requirements of all the other modules. It just seems very extreme, considering the requirements for the rest of the package. Still does, but Ivo's offered a way forward.
I've put the original FITS file and StarTools log file into the OneDrive folder.
Regarding the time, I agree that StarTools offers a super-quick way to get excellent results, but the HDR module seemed to go way, way, way beyond the processing requirements of all the other modules. It just seems very extreme, considering the requirements for the rest of the package. Still does, but Ivo's offered a way forward.
Not so much boldly going as randomly stumbling where plenty of people have been before
Re: HDR module in 1.8.515 Public Alpha is extremely slow
The old HDR module did indeed have something similar to context size ("Detail Size") but setting the parameter worked linearly (not exponentially) and the parameter's unit of measure was a bit odd. The old module effectively used a very low Context Size (you would be setting the Context Size squared and not Context Size itself). Really, the new module's "detail boost" part is only perceived to be slower because you were not able to push the Context Size in the old module very far (max square root of 2000=44.7 Context Size), the algorithms are definitely different, but run-times should be roughly comparable).
As mentioned a few posts back, the "Quality" feature only covers the Gamma correction part of the 3-part (see docs) signal flow. The "detail boost" part cannot be traded-off in the same way, because it absolutely requires fine per-pixel precision.
With regards to the quality parameter, you will notice some differences in images with lots of dynamic range changes across smaller areas (for example, very violent areas with lots of shock fronts such as the Cygnus Wall). You may not notice much of a difference at all if you only have a few larger-scale areas where local gamma correction is required.
To put everything in perspective;
As mentioned a few posts back, the "Quality" feature only covers the Gamma correction part of the 3-part (see docs) signal flow. The "detail boost" part cannot be traded-off in the same way, because it absolutely requires fine per-pixel precision.
With regards to the quality parameter, you will notice some differences in images with lots of dynamic range changes across smaller areas (for example, very violent areas with lots of shock fronts such as the Cygnus Wall). You may not notice much of a difference at all if you only have a few larger-scale areas where local gamma correction is required.
To put everything in perspective;
- The old module allowed you to switch between a Gamma Correction algorithm or a Detail Boost algorithm, both with very low Context Sizes.
- The new module combines Gamma Correction and Detail Boost into one pipeline, and allows you to vastly increase Context Sizes.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
-
- Posts: 1153
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: HDR module in 1.8.515 Public Alpha is extremely slow
Ah, that really helps, Ivo! Didn't realize you were tricking us the whole time with some square root thing.
So, roughly speaking since 1.8 HDR is new and improved, old-HDR was starting out at a context size of around 31 or 32.
Brendan I looked at your data and log, and they don't seem to match up. ?? Rather than the Cocoon, the FITS file is the Bubble.
And when I did my Cocoon, it wasn't super amenable to HDR anyway.
But I still ran things through and found out some stuff. The underlying data makes some difference, but not a lot it seems. Resolution, however, does. Makes sense.
I'll just type out the results, since I just write stuff on yellow pads. No nice code insert or spreadsheet like you and Guy have.
Testing was on an i7-6700, which I think is 3.4/Turbo 4.0; 32GB. If it matters, which it might not, while the data is opened from an HDD, the OS and ST are run off of an nvme 1TB 970 Evo Plus SSD, and the lame GPU is a GTX 745 OEM with some Afterburner.
I matched your bubble data with the same crop/bin/wipe/A-D/contrast defaults and went into HDR at 1779 x 1109.
Low Q: 50px - 0:46 60px - 1:35
Med Q: 50px - 0:47 60px - 1:39
HighQ: 50px - 1:42 60px - 3:44
I also ran at 40px at Med Q: 0:20, and High Q: 0:44, to compare with Guy's percentages. As you can see, I was showing in the low 40% range rather than his 50%, and that held up in further testing. Obviously this is all pretty ballpark-ish.
Then I accepted one, colored it with defaults, and ran SS, which took 0:28.
In order to compare to a busier dataset than your widefield bubble, which was pretty sparse, I loaded the ST Orion data, and binned/cropped to the same 1779 x 1109. Also, the M42 is far more amenable to HDR.
Low Q: 50px - 0:50 60px - 1:42
Med Q: 50px - 0:50 60px - 1:46
HighQ: 50px - 1:53 60px - 3:55
SS took 0:27.
Reviewing your numbers and mine, the percentages run fairly close, and we can probably add estimates to those Guy already made. Assuming context 50 to be 100%, context 60 takes about 200% time, context 70 360%, and context 80 640%.
Low and Med Q both take approximately 40 to 45% the time of High Q (lowering slightly as the context rises), but are in fact so close as to not really be worth using Low Q, except for some small gains as you increase the context level to maybe 75% or higher? Possibly then there's some room to make some adjustments here, because I'm not sure it's otherwise terribly useful to have the Low Q.
I then ran ST Orion again, but at double (quadruple really?) resolution of 3558 x 2218.
Low Q: 50px - 3:06
Med Q: 50px - 3:08
HighQ: 50px - 7:01
SS took 1:53
I didn't try out the other context sizes, but I think everything is already falling into place. Low and Med Q are in this case 44% of High Q. And everything is taking very roughly 4x what it took at the lower resolution.
It all seems fairly predictable, so if you try it out and get a certain amount of time for your machine at the default setting, extrapolating an estimate of processing time for different HDR context and quality settings can be done, including varying the resolution on another session with a different binning level.
That's all I got.![Very Happy :D](./images/smilies/icon/biggrin.gif)
![Laughing :lol:](./images/smilies/icon/lol.gif)
So, roughly speaking since 1.8 HDR is new and improved, old-HDR was starting out at a context size of around 31 or 32.
Brendan I looked at your data and log, and they don't seem to match up. ?? Rather than the Cocoon, the FITS file is the Bubble.
And when I did my Cocoon, it wasn't super amenable to HDR anyway.
But I still ran things through and found out some stuff. The underlying data makes some difference, but not a lot it seems. Resolution, however, does. Makes sense.
I'll just type out the results, since I just write stuff on yellow pads. No nice code insert or spreadsheet like you and Guy have.
![Sad :(](./images/smilies/icon/sad.gif)
Testing was on an i7-6700, which I think is 3.4/Turbo 4.0; 32GB. If it matters, which it might not, while the data is opened from an HDD, the OS and ST are run off of an nvme 1TB 970 Evo Plus SSD, and the lame GPU is a GTX 745 OEM with some Afterburner.
I matched your bubble data with the same crop/bin/wipe/A-D/contrast defaults and went into HDR at 1779 x 1109.
Low Q: 50px - 0:46 60px - 1:35
Med Q: 50px - 0:47 60px - 1:39
HighQ: 50px - 1:42 60px - 3:44
I also ran at 40px at Med Q: 0:20, and High Q: 0:44, to compare with Guy's percentages. As you can see, I was showing in the low 40% range rather than his 50%, and that held up in further testing. Obviously this is all pretty ballpark-ish.
Then I accepted one, colored it with defaults, and ran SS, which took 0:28.
In order to compare to a busier dataset than your widefield bubble, which was pretty sparse, I loaded the ST Orion data, and binned/cropped to the same 1779 x 1109. Also, the M42 is far more amenable to HDR.
Low Q: 50px - 0:50 60px - 1:42
Med Q: 50px - 0:50 60px - 1:46
HighQ: 50px - 1:53 60px - 3:55
SS took 0:27.
Reviewing your numbers and mine, the percentages run fairly close, and we can probably add estimates to those Guy already made. Assuming context 50 to be 100%, context 60 takes about 200% time, context 70 360%, and context 80 640%.
Low and Med Q both take approximately 40 to 45% the time of High Q (lowering slightly as the context rises), but are in fact so close as to not really be worth using Low Q, except for some small gains as you increase the context level to maybe 75% or higher? Possibly then there's some room to make some adjustments here, because I'm not sure it's otherwise terribly useful to have the Low Q.
I then ran ST Orion again, but at double (quadruple really?) resolution of 3558 x 2218.
Low Q: 50px - 3:06
Med Q: 50px - 3:08
HighQ: 50px - 7:01
SS took 1:53
I didn't try out the other context sizes, but I think everything is already falling into place. Low and Med Q are in this case 44% of High Q. And everything is taking very roughly 4x what it took at the lower resolution.
It all seems fairly predictable, so if you try it out and get a certain amount of time for your machine at the default setting, extrapolating an estimate of processing time for different HDR context and quality settings can be done, including varying the resolution on another session with a different binning level.
That's all I got.
![Very Happy :D](./images/smilies/icon/biggrin.gif)