Custom monitor LUT profiles slow down PWP8 considerably.

[davidh]

For some reason, no longer known to me now, I have been using the Adobe RGB (1998) as the Monitor profile in Color Management in PWP8.

Now I changed the monitor profile to one of my custom ones made over the time using DisplayCal (+ Argyll) and found that the PWP8 performace has slowed down considerably. What took a fraction of second, now takes seconds. For example, reopening a simple dialog like Tint now takes about 4 seconds. Previously it was within a second. Reprocessing the tree which took about 25 seconds, now needs more the two and a half minutes.

After some more exploring I found that this performace deterioration seems linked to custom profiles based on a lookup table, but not to those based on a matrix only.

I do not find this problem with those "ready made" profiles like Adobe RGB, Bruce RGB, sRGB, etc.

I have been using LUT based monitor profiles in PWP7 without any performance problems, but of course, the architecture will be quite different.

I have switched back to the Adobe RGB profile and when I have time, I will calibrate the monitor to create a fresh custom matrix based profile to see whether it works well.

[jsachs]

First check to make sure proofing is turned off - this slows things down a lot.

If that doesn't solve it, can you email me a copy of the monitor profile?

jsachs@dl-c.com

[Charles2]

Perhaps not relevant, but a NEC PA series monitor with a custom calibration does not slow things down. The difference may be that its LUT is in the monitor, not in a graphics chip in the computer's video module.

[davidh]

the profile has been sent..

As regards Proofing ON/OF: with Adobe RGB and the similar the response may seem a negligable fraction of a second longer. With LUT profiles there seems no difference, or rather there may be a tiny difference too, but with that prolonged response it would only be guessing.

[jsachs]

I installed both profiles you sent and there is no delay running either of them here as monitor profiles. Can you send me a copy of your color management settings? Also, are monitor curves enabled?

[davidh]

Color Management screenshot sent.
Monitor/Printer curves disabled.

[jsachs]

I normally recommend setting all rendering intents to Maintain Full Gamut, but I used your setting and still did not see a slowdown. For non-printer profiles, this setting is generally ignored anyway.

What about your virtual memory settings - is it possible the slowdown is due to memory paging? Does the problem happen even on small files?

Also, try setting the Proofing Profile to None. Proofing for inkjets is not generally useful anyway -- it is more intended for output to a 4-color press or some other device with a limited gamut.

[davidh]

I normally recommend setting all rendering intents to Maintain Full Gamut, but I used your setting and still did not see a slowdown. For non-printer profiles, this setting is generally ignored anyway.

I usually print images that are worth it and the difference between Maintain Full Gamut and Preserve Identical Colors and White Point often does makes difference.

I will try to find out more and get back later with some results.

[davidh]

...What about your virtual memory settings - is it possible the slowdown is due to memory paging? Does the problem happen even on small files?...

The problem is not in individual size of the images. There is no difference between 260kB jpeg and 70MB tif when used in either simple, or complex workflow trees with multiple trees and/or branches. Their responses are fast or slow, respectively, more or less equally.

Maintain Full Gamut rendering intent or Proofing profile ON/OFF setting make no difference. I set Proofing to None as I do not use it anyway.

The problem is in the volume of the whole workspace. The bigger or more complex the workspace, the slower the response with LUT based monitor profiles. 4GB of RAM is not much nowadays and less so will it be in the future.

What is interesting is the almost striking response speed difference between lookup and non-lookup based profiles.
I do not insist on a LUT profile, so my solution will be to create a new matrix based profile for the nearest future.

[jsachs]

It does sound like a shortage of RAM. The architecture of PWP 8 definitely uses more memory than PWP7 since all the images in the workspace need to the loaded at once, so a large image tree full of large images will need a large amount of memory. Why one type of monitor profile should use more memory than another depends on the internals of the lcms color management system. Possibly it is creating a large lookup table to speed up color space conversions for non-matrix profiles. When designing new software it is necessary to aim for future computers which are moving towards larger amounts of RAM and multi-core processors -- unfortunately this can cause problems for older computers.