gamut warning changes pixels

Yes, I do see a very slight difference in near-black. Windows 10, CC2017, Epson papers.

I would never have noticed this, as I never touch gamut warning. It's a completely useless tool IMO. It has a certain threshold before it kicks in, and when it does it says nothing about how much. So it tells you absolutely nothing.

Still, there shouldn't be a difference. No idea what this is.

Well, you will see some differences when soft proof is turned on, long before gamut warning shows any clipping. That in itself is normal - it starts to clip, but not enough for gamut warning to show it.

If there is clipping, and the visual soft proof indicates I should do something about it, I take a more targeted approach. I look at the histogram to determine which channel is clipping, high or low end, and then examine that channel to see specifically what needs to be done. A wholesale desaturation always takes too much across the board.

Clipping in itself need not be a problem. But if it kills texture and general "air", it can often be fixed without any perceived loss of saturation.

Anyway, as far as I can see without running extensive tests, the non-gamut warning version appears to be the correct one. Even more reason to avoid it if you ask me.

You're right, this secondary discussion about the general usefulness of gamut warning does confuse the issue. So let's leave that for now.

I certainly don't see any banding or other artifacts in the shadows here, when turning soft proof on. It looks as I would expect it to look, corresponding to the print, IOW showing only the effects of the gamut clipping that actually happens. BTW I'm using an Eizo wide gamut monitor that mercilessly exposes any shortcomings that might be there.

The difference with gamut warning on is apparently wrong here. It causes a general lifting of deep shadows that neither matches the original or the print. It's a third variety coming out of nowhere.

I'll look more closely into it later today, and post some screenshots once I find a suitable original (showing the effect well). I'm on my way out and don't have time to dig into it right now.

I had this problem years ago with an Nvidia driver. It was an error seen when using the GPU code.

Noel Carboni had already raised the issue and found that switching the GPU mode to Basic (which forced the CPU to do the colour shading) resolved the issue in the short term. It may be worth setting the  GPU to Basic or even turning it off temporarily and see if you get the same.

See this:

Strange behaviour softproof and Gamut warning

Edit to add - I just checked and I don't see the issue on my current AMD card & driver with Advanced GPU mode checked

Dave

Ah, that seems to be it. I need to recheck this when I get home.

BTW the issue Noel referred to has been well known ever since he first reported it around CS5 or so. This manifests itself as colored shadow banding in ProPhoto files, with GPU at Normal or Advanced. This is where display color management is handled by the GPU. In the Basic setting it's shifted back to the CPU in the traditional way, and the banding disappears.

The effect varies a bit with the type of monitor profile used, but it happens even with sRGB/Adobe RGB as monitor profile. I haven't seen it lately, and assumed it was fixed. But maybe it just doesn't show up with my current monitor profiles (Eizo Colornavigator version 2, matrix).

I don't think this is the same thing, but it could be related, a different manifestation of the same underlying problem.

Yes, the GPU setting matters. In "Basic" mode there is no difference with gamut warning on or off. In "Normal" or "Advanced" mode something weird happens.

And yes, gamut warning on is the correct rendering. I didn't look closely enough before.

So this is obviously OpenGL inaccuracies, just like the ProPhoto bug we know from before. BTW that's OpenGL, not OpenCL which is something else. The OpenCL checkbox is irrelevant here. OpenGL is the engine that runs display color management in Normal/Advanced modes, among many other things.

Here's a simple gradient, divided into three horizontal strips. The file is Adobe RGB, video card NVidia Quadro K420, GPU Advanced:

I've always kept GPU at Basic on my work system because of the ProPhoto bug. Here I need absolute accuracy. All the more reason to continue that practice.

Unlike Open CL, Open GL is not a separate option in Preferences. It is enabled when you enable the GPU. The functions it is then used for vary by the drawing mode Basic, Normal or Advanced.

Dave

Just keep GPU at the "Basic" setting, and OpenGL is off. At least as far as color management is concerned.

That's what I'm going to do from now on, without exception. That thing is far too unreliable for critical work.