Since Noel is back with us, I thought this header might catch his attention. He was the one who first reported it six or seven years ago.
The reason I'm bringing this up now, is that someone in the Lightroom forum had this problem just yesterday (he was sending ProPhoto files to Photoshop and couldn't understand the cyan cast in his dark grays). There's no doubt it's the same issue.
This made me dig up my old ProPhoto test gradient file. I don't use ProPhoto all that much, so I haven't really looked for it in a while. To recap, this is an example of what it could look like (this is an old screenshot that I've kept). Open and view against a darkish background:
But when I opened the test gradient now, there was no trace of it, zero. The gradient is smooth as silk. That surprised me, because while the effect can vary, it always seemed to be there in some form.
Technically, this is an inaccuracy in the conversion from ProPhoto into the monitor profile. This conversion is performed by OpenGL in the GPU when you have the PS preference set to Normal and Advanced modes. In Basic mode it's shifted back to the CPU, which is more accurate so the problem disappears. And you only see it in ProPhoto files because ProPhoto is very compressed in the shadow values compared to other color spaces. The stratospheric gamut has a price, and that's it. With this compression, inaccuracies get amplified.
So what has changed on my system over the last 12 to 24 months? Not much. I still use Eizo Colornavigator as I did then, still producing similar matrix monitor profiles. But one thing has changed - going from GeForce to Quadro, and with that, 10 bits per ch output.
So Noel, if you're reading this - I understand you have Quadro GPU too, and running displays at 10 bit. Do you still see it?
Anyone else?
Explore related tutorials & articles
80
Replies
My inner geek voice has always whispered a suspicion that there must be a stage in the transform calculation in which, even though GPUs use floating point math, a number near an integer may be subtracted from a nearby integer (e.g., 1 - 0.9999999), which is a sure way to cause precision loss. Another thought is that maybe there are tone curves that differ by a very small amount for each of the colors. An amount some profile designer thought was inconsequential 20 years ago.
It is possible the monitor profile is involved, though I have verified seeing the issue using anything from the age-old sRGB v2 profile to newer v4 display profiles as a display profile.
It's clearly got to do with using the ProPhoto profile as a working space, because another, similar profile (e.g., ColorMatch RGB) doesn't cause it - which led me to wonder further... Could there now be more than one ProPhoto RGB profile around? Could you have somehow gotten an updated one, Dag, that no longer causes the precision loss?
I looked on my hard drive and I saw that I actually have accumulated multiple copies of the ProPhoto profile (not surprising), BUT... I do have two different renditions. Most are ProPhoto.icm (including the one in C:\Windows\System32\spool\drivers\color, which is the one that matters), dated anywhere from 2005 to 2015. the one that's different is ProPhoto.icc (note the different file extension) dated 2012, and located in a folder created by a different photo editor (ComputerInsel Photoline). Turns out it's described as "ProPhoto RGB (linear)" and it isn't another rendition of the same profile, exactly, but its existence DOES support the possibility of there being alternate versions of ProPhoto.icm running around in the world.
Dag, is your copy of C:\Windows\System32\spool\drivers\color\ProPhoto.icm the same size as mine?
If so, next we can devise a way to see if they contain the exact same binary data.
-Noel
Yes, down to the last byte (940/4096).
But even if the gradient looks fine, there's something funny going on all right. I drew a marquee and cranked saturation all the way up. Why is it consistently red when it should just be neutral with increased color noise? What's that cyan peak in the histogram?
Yeah, it could be the PP profile spec in itself. Now, I'm a practical man. I know how things work, but whenever someone tries to drag me into the Hogwarts Color Science Lab, I'm off chasing butterflies. I know nothing about the internal anatomy of a profile - except the broad principles of Profile Connection Spaces. I know there's a table somewhere (way up in the Scottish Highlands), which can be based on either XYZ or Lab. Could this be where the dragon is buried?
I have both an .icm an .icc ProPhoto RGB profile on my Windows 7 system, but in PS Color Settings I only see one ProPhoto RGB selection. They appear to be identical so it shouldn't matter. The date showing in ICC Profile Inspector is 1998/12/1.
Hm, that might imply your gradient isn't pure gray, Dag, BUT... There is definitely some additional weirdness going on!
I tried raising the saturation of my grayscale PNG to +100 and got this:
Then I did it AGAIN and got this cute little result. 
After undoing all the above, I did Image > Adjust > Desaturate it, then two iterations of +100 saturations and got this:
This implies the PNG actually has some values that are non-gray (by a tiny bit). And here I thought PNG compression was lossless - but I guess not! The funny thing is that this little revelation seems to be entirely separate from the ProPhoto cyan cast display bug.
The plot thickens! I'm going to save my test image as a PSD and use that from now on. I hope THAT's lossless.
-Noel
These are my Performance settings
Multiple applications of the +100 Saturation makes no difference—the RGB values remain equal, which is expected.
If you add Color Sample marks to your Saturation selection do the RGB values change? Saturation shouldn't have any affect on equal RGB values. Are you testing in 2019?
I tested above in 2019, but I've seen the ProPhoto cyan cast issue before in 2018 and earlier versions, going all the way back. Apparently it's appearance is dependent on something we've yet to nail down.
The second issue, which I just uncovered above, may be my fault. I re-opened the PNG file I posted above and I haven't been able to reproduce bringing out any weird colors with any number of Saturation steps. I may have opened a different test file from my History to get the effect with the neat patterns.
Here are reproductions of the ProPhoto cyan cast problem, with settings like yours...
Photoshop CC 2018 "girl in drug cloud splash screen edition":
Photoshop CC 2019 "cloud headed dude splash screen edition":
As you can see, even with the same settings you're using (e.g., no 30 bit in my case) the color banding remains.
The samples all show equal R, G, and B values, whether or not point samples or averaged samples are made. It must be purely a monitor display issue.
The cyan banding issue doesn't show up in the Navigator display, by the way. I believe Photoshop must always use CPU color-management for that.
-Noel
No. Could be on Mac; not on Windows. Unlike MacOS, Windows doesn't touch this stuff. It's strictly application.
(EDIT: what made me pick this up again now, was a Mac user on the Lightroom forum three days ago having this exact issue. He's on Mojave and PS 20.0)
Anyway, Noel, you were right of course. Once I punched in the numbers and double-checked with 16 bit readout that R=G=B, I got this, and that's 100+ saturation on the actual finished screenshot. A few stray pixels, that's all:
On the upside, this is as close to perfection as it'll ever get. So yes, it can work.
It has to be somewhere in the conversion from ProPhoto source to monitor RGB.
but going to ProPhoto is jumping off the edge of the world. It's huge.
When it comes to CMYK print output I can see some advantage of the larger ProPhoto gamut, but I'm having a hard time finding the downside.
Here's the shadow gradient we've been looking at, which is obviously in gamut with both ProPhoto and AdobeRGB, and is also inside any CMYK gamut. The three color swatches are inside the ProPhoto and GRACol Coated CMYK gamut, but are out of the AdobeRGB gamut. The bottom capture is a Relative Colorimetric conversion of the Prophoto file to AdobeRGB.
If I convert both to GRACol I get identical output numbers in the shadow gradient, but the numbers for the saturated colors are different—the AdobeRGB colors have been somewhat clipped.
https://forums.adobe.com/people/rob+day wrote
If I switch to Adobe RGB the results are considerably different and less accurate (reds more saturated). Not sure why since there is very little image area out of Adobe RGB gamut.
That would be expected if you capture the same RGB values but then assigned (rather than convert to) different profiles. Try capturing with ProPhoto and then do a Convert To AdobeRGB.
Nope. I'm using 'Covert to Profile' for the ProPhoto RGB conversion to Adobe RGB.
It probably is due to the Auto Curves function rendering the image differently due to RGB channel differences (see below). Processing color film images in LR/PS can be a PITA due to the mask and color characteristic differences of the various color film types. However, using ProPhoto RGB with the Auto Curves function works quite well to color correct the film images.
https://forums.adobe.com/people/rob+day wrote
On a conversion I would expect the histogram and image RGB values to change as you are showing, but not the color appearance. What happens to the histograms if you convert the two versions to the same CMYK output profile?
'Convert to Profile' U.S. Web Coated (SWOP) v2 for both produces identical Histograms with Cyan and Black channels clipped.
AdChoices