Custom monitor LUT profiles slow down PWP8 considerably.

Please use this forum to post bug reports, feature requests, tips, etc. for beta versions of Picture Window Pro 8

Moderator: jsachs

Locked
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Jonathan Sachs
Digital Light & Color
Charles2
Posts: 225
Joined: November 24th, 2009, 2:00 am
What is the make/model of your primary camera?: Fuji X-Pro 2
Contact:

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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?
Jonathan Sachs
Digital Light & Color
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by davidh »

Color Management screenshot sent.
Monitor/Printer curves disabled.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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.
Jonathan Sachs
Digital Light & Color
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Custom monitor LUT profiles slow down PWP8 considerably.

Post by 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.
Jonathan Sachs
Digital Light & Color
Locked