Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: smthopr on November 23, 2015, 02:10:07 pm
-
I was recently editing a photo in ProPhoto working space on a wide gamut display calibrated to REC709 (I'm doing some video work).
I flattened the image and converted to sRGB space and noticed a color shift. The image is low saturation and should be completely in REC709 space. But there is a slight color shift upon conversion.
Why?
-
I flattened the image and converted to sRGB space and noticed a color shift. The image is low saturation and should be completely in REC709 space. But there is a slight color shift upon conversion.
We need low rez examples to examine. There should be no 'color shifts'. The color appearance could change slightly depending on the gamut of the two but not a shift.
-
I was recently editing a photo in ProPhoto working space on a wide gamut display calibrated to REC709 (I'm doing some video work).
I flattened the image and converted to sRGB space and noticed a color shift. The image is low saturation and should be completely in REC709 space. But there is a slight color shift upon conversion.
Why?
When converting from a wide gamut to a narrow one you may get different colors because of clipping. Conversion is done by a matrix and when the RGB values that occur after conversion are negative they are clipped to 0. This can cause slight shifts hue and significant decreases in saturation but also increases luminance and often that is the largest effect. The opposite can occur as well. When RGB levels are clipped at 255 luminance is decreased.
This effect is not observable when the monitor is in the same space as the conversion target since the clipping is the same for both. So, rather counterintuitively, folks that notice this are those that run wide gamut monitors. If one runs a profiled monitor at sRGB and converts to sRGB they will remain blissfully unaware of the changes.
What is printed from ProPhotoRGB is different. ProPhotoRGB is first converted to Lab and most, but not all, colors as ICCLAB limits a and b to values in the range of -128 to 127. This isn't the primary limitation as most realizable ProPhotoRGB colors can be defined in those limits. All , non-specular, reflected colors are within that space.
The problems with printing directly from ProPhotoRGB v first converting to sRGB (or any other matrix type space space) is that the path is different. After the color is converted to Lab, lookup tables map the color to what a printer can actually print and that can be a color that is outside or inside both sRGB and AdobeRGB. This process is completely different. Worse, the way colors are mapped when they are outside the printable gamut are undefined. Even for printable colors they are undefined using Perceptual Mode. It's basically up to the profile software peeps who try to create "pleasing" colors. At least it's within the context of a defined viewing environment for the more recent V4 profiles. It may, or may not match one's expectations.
-
We need low rez examples to examine. There should be no 'color shifts'. The color appearance could change slightly depending on the gamut of the two but not a shift.
Here's the screen shot... Look at the road in the lower right. It's more red or magenta in the sRGB version
-
Here's the screen shot... Look at the road in the lower right. It's more red or magenta in the sRGB version
Look identical to me, hence the suggestion for the actual but low rez file. Oh well.
-
Look identical to me, hence the suggestion for the actual but low rez file. Oh well.
They are not identical. Open in photoshop and use the eye dropper to measure and you'll see. To make it obvious, cut the image in half, and superimpose them as layers, and turn one off and on to see the difference.
Since I posted, I also noticed a change in overall gain of the image as well. Sky is obviously lighter in the sRGB version and gives a different impression.
When I'm in ProPhoto space, photoshop is doing an "on the fly" conversion to my monitor space using relative colormetric intent, yes?
But converting to sRGB, which is darned close to my monitor calibration, using relative colormetric intent, causes a different appearance. Yes subtle, but different. Why is that? I don't think this image challenges either gamut... Or, do those little bright red tail lights cause some shifting of all the colors in the remapping to sRGB?
-
I think you'll find that the conversion to your monitor space is perceptual.
-
If different conversions look different on screen, it's the display profile. ProPhoto to monitor is a different calculation than sRGB to monitor.
Recalibrate, and leave the monitor at native primaries and whatever white point you have it set to.
-
They are not identical. Open in photoshop and use the eye dropper to measure and you'll see.
I'd certainly hope they are not identical! Converting from ProPhoto RGB to sRGB should produce differing values. But what's the point? I asked for data to test and you're providing screen captures. IF and when you're ready for assistance, follow the instructions and I'll try to help you. Otherwise, I'm done.
-
I'd certainly hope they are not identical! Converting from ProPhoto RGB to sRGB should produce differing values. But what's the point? I asked for data to test and you're providing screen captures. IF and when you're ready for assistance, follow the instructions and I'll try to help you. Otherwise, I'm done.
Sorry to bother you then... I was just curious about the effect and I thought others here also would be.
-
Sorry to bother you then... I was just curious about the effect and I thought others here also would be.
You got an answer in the 2nd post: There should be no 'color shifts'. The color appearance could change slightly depending on the gamut of the two but not a shift.
-
I was recently editing a photo in ProPhoto working space on a wide gamut display calibrated to REC709 (I'm doing some video work).
I flattened the image and converted to sRGB space and noticed a color shift. The image is low saturation and should be completely in REC709 space. But there is a slight color shift upon conversion.
Why?
I looked at the image and attached profile. Attached profile is a standard Eizo s/w one with a matrix.
The screen grabs have the monitor's profile attached. There are a lot of jpg compression artifacts that makes it difficult to compare pixel to pixel. Screen captures should not be compressed to evaluate subtle differences.
There clearly is a difference, though small, in the captures. Even if the original was 8 bit the differences are too large to explain.
The differences are not due to monitor profile issues unless one screen capture was interpreted as sRGB. The attached image is tagged with the monitor's CX271.... profile.
I created a dark gray image in ProPhotoRGB then added random color noise but within smaller gamuts. After converting a duplicate to sRGB and comparing the ProPhoto and sRGB overlays in photoshop there was no visible difference at all and I am also using Eizo.
It's not a gamut or monitor profile issue per se but some sort of process issue possibly in the "flattening" step which could well be shifting colors.
-
The differences are not due to monitor profile issues unless one screen capture was interpreted as sRGB
They can if the profile is somehow defective.
But actually, on closer inspection, I suspect that what we see here is the well-known Photoshop bug that causes heavy red/cyan banding in the shadows in ProPhoto files. It can take different forms with different display profiles, but never goes entirely away. It happens even with sRGB/Adobe RGB as display profile, so there's no doubt the bug is real.
This color banding happens only in (16 bit) ProPhoto files, with GPU set to "Normal" or "Advanced" modes. In "Basic" mode, the display color management logic is shifted back from the GPU to the CPU, and the banding disappears. ARGB and sRGB are not affected.
This bug has been well documented on the Adobe Photoshop forum from 2012 on. Chris Cox said they'd "look into it", but nothing's happened.
So try to set GPU to basic and check again.
-
They can if the profile is somehow defective.
But actually, on closer inspection, I suspect that what we see here is the well-known Photoshop bug that causes heavy red/cyan banding in the shadows in ProPhoto files. It can take different forms with different display profiles, but never goes entirely away. It happens even with sRGB/Adobe RGB as display profile, so there's no doubt the bug is real.
This color banding happens only in (16 bit) ProPhoto files, with GPU set to "Normal" or "Advanced" modes. In "Basic" mode, the display color management logic is shifted back from the GPU to the CPU, and the banding disappears. ARGB and sRGB are not affected.
This bug has been well documented on the Adobe Photoshop forum from 2012 on. Chris Cox said they'd "look into it", but nothing's happened.
So try to set GPU to basic and check again.
I believe you nailed it. Not a profile or gamut issue but an Adobe bug. I've also seen this in proofing 16 bit LAB files. Have had GPU turned off for some time now.
-
This color banding happens only in (16 bit) ProPhoto files, with GPU set to "Normal" or "Advanced" modes. In "Basic" mode, the display color management logic is shifted back from the GPU to the CPU, and the banding disappears. ARGB and sRGB are not affected.
I see no differences with any of those settings on this end.
-
It is dependent on the display profile to a certain extent. Lots of people chimed in to confirm when it was discussed on the Adobe forum, but people saw it differently. Most saw cyan banding, some cyan/red, and others just luminance banding.
So perhaps some configurations go entirely clear, I don't know.
I did see it on an NEC P232/SV II, but IIRC only as luminance banding. Matrix is usually better than LUT.
In any case, I believe it's the problem here.
-
So perhaps some configurations go entirely clear, I don't know.
NEC PA272W. I might need to see what shows up on the MacBook Pro screen but since the two are so vastly different and I don't care all that much what 'critical' color looks like on the Retina, not a big deal. Maybe I need to relaunch PS after each setting? Tried it once, saw no difference. ProPhoto gradient from black to white looks neutral. Running latest version of Photoshop CC.
-
Don't see it on the Retina display either. Gradient isn't anywhere as smooth as the SpectraView as expected. But it appears neutral. Maybe the latest version of CC fixed the bug?
I wonder if Dither when creating the gradient plays a role?
-
Quick testing it again now (Eizo/Colornavigator), it seems OK here too...maybe it is fixed? It would be about time. I need to look more closely at this (I currently only have matrix profiles).
But to recap - the interesting thing wasn't so much the banding you did see in these ProPhoto files, but the fact that it disappeared immediately when switching to "Basic" mode or GPU off. So that was instant confirmation and you could pretty much rule out any other causes.
I've also seen other issues than banding with this, most notably black clipping to level 5 or 6 in PP. That's also visible in the examples I posted above. Again the problem went away in Basic mode or GPU off.
-
But to recap - the interesting thing wasn't so much the banding you did see in these ProPhoto files, but the fact that it disappeared immediately when switching to "Basic" mode or GPU off. So that was instant confirmation and you could pretty much rule out any other causes.
GPU bugs are nothing new for Adobe :'( . I hope indeed the Photoshop bug you reported is now fixed.
-
Huh...for a minute there I really thought it was fixed. With my working matrix profiles there is no banding whatsoever, in any GPU mode.
Then I made a LUT profile....annnnd....there is still a little, although not nearly as much as I saw before. You can just make out one fairly broad cyan band on the right side below. If the screenshot survives the conversion to sRGB, it should be evident that the left side (no GPU) is perfectly smooth.
Not really sure what to make of this. I stopped making LUT profiles in Colornavigator a while ago, because Firefox clearly didn't like them. No banding there, but massive black clipping. So I generally don't trust LUT profiles.
This was originally reported by Noel Carboni in the Adobe forum, a man notorious for insisting on sRGB as display profile come hell or high water. So we could immediately disregard a bad calibration/profile as the source, and we all took notice right away.
EDIT: the screenshot displays a fair amount of banding in Firefox, not present in Photoshop. Just goes to show how difficult this is to demonstrate...
-
I stopped making LUT profiles in Colornavigator a while ago, because Firefox clearly didn't like them.
And I never made em to begin with so that's probably why I can't replicate. I have to wonder if all LUT profiles behave the same.
-
The OP's color/luminance shift problem has nothing to do with the Eizo CN profile. The tagged profile is a completely standard CN matrix one with identical gamma=2.2 TRC curves in all RGB channels. The curves start at 66 (out of 65535) indicating the monitor's BP was set at .1, a standard setting for the 1000:1 monitor he used.
The only possible explanation that wouldn't be a straight Photoshop bug is if the image was taken at high ISO and had enough out of sRGB gamut pixels that the large amount of LP filtering that goes with major downsizing first converted the pixels to sRGB then ran them through a LP filter. Clipping these before filtering will increase slightly the luminance post filtering.
The only way to know for sure is to get the image before downsizing while still in ProPhotoRGB. It would be nice to know for sure.
That said, my inclination, and Occam's Razor, suggests the problem is the low luminance GPU related Photoshop bug.
-
The only way to know for sure is to get the image before downsizing while still in ProPhotoRGB. It would be nice to know for sure.
Exactly. But that's not happened so I guess we'll never really know.
-
The OP's color/luminance shift problem has nothing to do with the Eizo CN profile.
Nobody said it was caused by the display profile, least of all me. But the display profile indirectly affects how the Photoshop bug appears on screen. How, I don't know, but the whole problem is that something in the ProPhoto > monitor conversion doesn't have the required precision and returns inaccurate values.
I've tested this with a lot of different display profiles and they all appear slightly different from each other. I've used Eizo and NEC monitors, Colornavigator, Easypix, Spectraview II, DispcalGUI and i1Profiler. I've tried matrix profiles and LUT, the version2 spec and the version4 spec. All have displayed the bug, but all differently.
Currently I'm using Colornavigator on Eizo CG246 and CX240, producing v2 matrix profiles. That seems the best of the lot. The worst was an Eizo Flexscan SX with Eizo Easypix. That was horrible (I think Easypix makes LUT profiles with no option for matrix. The software doesn't tell).
-
Nobody said it was caused by the display profile, least of all me. But the display profile indirectly affects how the Photoshop bug appears on screen. How, I don't know, but the whole problem is that something in the ProPhoto > monitor conversion doesn't have the required precision and returns inaccurate values.
I've tested this with a lot of different display profiles and they all appear slightly different from each other. I've used Eizo and NEC monitors, Colornavigator, Easypix, Spectraview II, DispcalGUI and i1Profiler. I've tried matrix profiles and LUT, the version2 spec and the version4 spec. All have displayed the bug, but all differently.
Currently I'm using Colornavigator on Eizo CG246 and CX240, producing v2 matrix profiles. That seems the best of the lot. The worst was an Eizo Flexscan SX with Eizo Easypix. That was horrible (I think Easypix makes LUT profiles with no option for matrix. The software doesn't tell).
Ok, perhaps we could find a specific profile that will reproduce a significant shift under defined conditions. I don't like these little variations that seem to be from Adobe's S/W. As it is I've disabled GPU acceleration due to some printer proofing strangeness. There is still some strangeness but I've got workarounds. I crosscheck monitor proofs with actual prints using a spectro and I really get bugged when things don't match up within some reasonable tolerance.
There are a few anomalies, some I've been aware of for years, with Photoshop and one of these could be causing the OP's issue. Photoshop allows selection of either Adobe or Microsoft's ICM. They do not behave the same. Further, the Microsoft ICM does some strange things converting ProPhotoRGB to sRGB.
For instance, creating a PPRGB patch in 16 bit at RGB(10,10,10) reads 1414 in the 16 bit RGB info readout. Converting it to sRGB changes only the "G" value which goes to 1542. Very strange behavior. Appears the calculations are being done in 8 bit or something.
-
Quick testing it again now (Eizo/Colornavigator), it seems OK here too...maybe it is fixed? It would be about time. I need to look more closely at this (I currently only have matrix profiles).
But to recap - the interesting thing wasn't so much the banding you did see in these ProPhoto files, but the fact that it disappeared immediately when switching to "Basic" mode or GPU off. So that was instant confirmation and you could pretty much rule out any other causes.
I've also seen other issues than banding with this, most notably black clipping to level 5 or 6 in PP. That's also visible in the examples I posted above. Again the problem went away in Basic mode or GPU off.
Thank you Mr. Fosse! I turned off the GPU and the issue is gone. Not sure if this is an adobe bug, of something with the graphics card though...
Now, what am I loosing by turning off the GPU? Will things slow down?
And, Mr. Fosse, thank you so much for your insight and complete lack of a snide tone of voice in your response. It is much appreciated :)
-
So there it was, once again. I wonder why it's not possible to get this fixed - they are aware of it, and Chris Cox is a senior engineer who actually wrote much of Photoshop's color management code. Probably something in the OpenGL engine, and there's nothing they can do.
I've had the GPU setting in Photoshop at "Basic" ever since this was reported. I'd actually noticed the weird cyan shadows in ProPhoto files a little before, but didn't understand what it was until Noel Carboni clearly demonstrated what was happening. And I've also seen some other irregularities when the GPU handles the display transforms. So I want no part of it and keep it off.
Theoretically the GPU is supposed to speed things up. Haven't really seen any of that, and as far as I can tell you don't lose anything, or at least not in normal operation. With 3D stuff it would probably make a difference.
-
The GPU does speed some things up, one notorious is the Liquify filter. Setting GPU to Basic does not turn it off completely, so you still get some of the speed advantages.
-
I just updated Photoshop to the latest version and the conversion from 16 bit PP RGB to sRGB is still hosed using Microsoft's ICM Conversion image. Stick with Adobe.
Worse it appears the 10 bit monitor is not working at all. It worked in the prior version of Photoshop albeit with the Microsoft ICM color banding flaws. It may have had color banding but at least the display was the smooth 10 bits..
-
There's no reason to ever use ICM. ACE is the default, just leave it alone.
-
There's no reason to ever use ICM. ACE is the default, just leave it alone.
Last week I would have agreed with that about 95% of the time. This week 100%. Last week it was the only way I could get 10 bit color. While never a problem on photos, artwork gradients were annoying. But to get completely smooth gradients I had to live with small conversion errors and low freq color banding in deep shadows. Now, I don't even get 10 bit smoothness so ICM has only one place that it is even potentially useful. It doesn't adapt to white point changes (like D65 to D50) in Absolute Colorimetric printing. The only reason one would ever want to do this is to print a screen image so that when illuminated with D50 the print appears as if it was illuminated with D65. ICC specs now require that Absolute Colorimetric processes adapt to illuminant and monitor white point changes (but not paper white point) as Adobe has done all along.
-
ICC specs now require that Absolute Colorimetric processes adapt to illuminant and monitor white point changes (but not paper white point) as Adobe has done all along.
Yep - they sure wrecked Absolute colorimetric intent in V4. If you want adaptation to the white point, use Relative colorimetric - that's what it's for. There was no need to cripple the usefulness of ICC display profiles by wiring Absolute to Relative.
-
Yep - they sure wrecked Absolute colorimetric intent in V4. If you want adaptation to the white point, use Relative colorimetric - that's what it's for. There was no need to cripple the usefulness of ICC display profiles by wiring Absolute to Relative.
For my document copying work I need AbCol. RelCol scales 100 to the white point and I like to spot check workflow with a spectro which complicates that. AbCol is the easiest way to do that since it doesn't scale. Lab in, Lab out. At least if within gamut. L93 gets you L93. As for D65<>D50, I really prefer working in a modified sRGB D50 space. For day to day computer use D65 is just too blue for me. I switch to ProPhoto and high gamut on the monitor when the image requires it and I'm in a color managed program. Monitor is always in D50.