This morning I saw the new RC was out, and just to do a quick check on performance I downloaded it on my work laptop, loaded a large (~40MP) image, and did some quick operations to see how things shook out.  Everything was pretty smooth, even better than the current stable version on my desktop.

Then today I got home, installed the RC on my home desktop, which is a significantly beefier machine (32-core thread ripper, 32GB of RAM), loaded up a similarly sized image, and found it completely unusable.  It hangs simply trying to zoom in and out of the image. Running the wavelet decompose takes minutes.  And curiously, even though the window frequently stops responding and the process makes my computer fans sound like a jet engine, on the new dashboard display the CPU is never ticking above 3% and I'm sitting at around 70% of the 12GB of cache I gave it used (it was below 50% before I started running the plugin).  This seems to be the case regardless of how many threads I enable or whether OpenCL is turned on.

I assume this has to be a bug, since I'm running the same software and getting the exact opposite of the results I'd expect running it on different machines, but what can I do to diagnose it and get some data that might help resolve it?  The error console isn't showing anything, here's what I get in my terminal when opening an image and running wavelet decompose, if that helps at all: https://pastebin.com/TCEgYqPr

Seeing color management stuff in the console did make me think to try turning color management off, which did make basic image operations run faster, but wavelet decompose is still running intolerably slow.  And of course retouching with color management disabled isn't an ideal long-term solution.  Any ideas?

Thanks, Robert

How would I tell?  I just generated my monitor profiles with Ubuntu's color management control panel section: I'm still not as much of a power-user in that area as I'd like to be

So is there any chance that your monitor profile at home is a LUT profile? What about the image's assigned profile - was it possibly a LUT profile? And/or was soft proofing somehow activated?

How would I tell?  I just generated my monitor profiles with Ubuntu's color management control panel section: I'm still not as much of a power-user in that area as I'd like to be

Also, try operating at 32f instead of 16i, which will eliminate some internal precision changes. And try disabling opencl and setting the number of threads to "1".

Interesting.  I'll give that a shot too, although I was definitely in an integer mode when testing on my laptop and didn't experience any noticeable perf degradation, so I'm guessing that's not the culprit

Thanks for that Elle, I followed up personally about the profiles.  Going back to the list, one thing I should add is that currently for my workflow on the same machine I'm using Gimp 2.8 with the same sized images, same monitor profiles, and it works more or less okay.  I wouldn't say it's _fast_, and it gets a little crashy sometimes, but I think it's doing a pretty decent job for a single-threaded program processing buffers this big. It's miles faster than the 2.9 RC, so I'm guessing there's probably something other than that going on

On 03/27/2018 07:04 PM, Elle Stone wrote:

On 03/27/2018 09:35 PM, Robert Bieber wrote:

How would I tell?  I just generated my monitor profiles with Ubuntu's color management control panel section: I'm still not as much of a power-user in that area as I'd like to be

So is there any chance that your monitor profile at home is a LUT profile? What about the image's assigned profile - was it possibly a LUT profile? And/or was soft proofing somehow activated?

Hmm, well, probably the easiest way is to send me a private email with your monitor profile attached, and perhaps export a very small jpeg of the image you were working on, with the image profile embedded, and I'll look at them.

If you are interested in learning more about color management, perhaps starting with "how to tell what kind of profile it is, LUT or matrix", probably the best thing to do is start a thread on the pixls.us forum.

If you want, you can catch my attention on the pixls.us forum by mentioning @elle, but quite a few people there can help with figuring out what kind of profiles you are using, and maybe some of them even use Ubuntu's color management control panel (I don't).

I'm about to shut down the computer for the evening, so might not see your profiles (if you send them) until morning.

Best, Elle

Big thanks to Elle, it turns out the integer precision was the issue.  On the laptop I was in integer precision, but it was 8 bit because I'd loaded the image from a jpeg.  Switching to 32-bit float makes things much more usable on the desktop

On 03/27/2018 06:35 PM, Robert Bieber wrote:

How would I tell?  I just generated my monitor profiles with Ubuntu's color management control panel section: I'm still not as much of a power-user in that area as I'd like to be

So is there any chance that your monitor profile at home is a LUT profile? What about the image's assigned profile - was it possibly a LUT profile? And/or was soft proofing somehow activated?

How would I tell?  I just generated my monitor profiles with Ubuntu's color management control panel section: I'm still not as much of a power-user in that area as I'd like to be

Also, try operating at 32f instead of 16i, which will eliminate some internal precision changes. And try disabling opencl and setting the number of threads to "1".

Interesting.  I'll give that a shot too, although I was definitely in an integer mode when testing on my laptop and didn't experience any noticeable perf degradation, so I'm guessing that's not the culprit _______________________________________________ gimp-user-list mailing list
List address:    gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives:   https://mail.gnome.org/archives/gimp-user-list