Channel clipping and posterization

E.J. Peiker wrote:... The fact that the different rendering intents produced absolutely identical results is a big red flag. Also having such HUGE differences between other applications trying to do the same thing as Photoshop is another red flag.

Have you tried to see if different versions of Photoshop, such as CS3 vs. CS4, makes a difference. maybe something got broken in PS.

Interesting comment, E.J. Though it's New Year's night here , I couldn't resist just to convert the 16bit Prophoto-file to sRGB through PS CS2. The resulting histogram in sRGB is exactly the same compared to CS3. I can confirm that there's no difference between the RI in CS2 either. I have not yet installed CS4, though. But I would really surprised, if CS4 now shows a different algorithm. But you never know...

That all 3 rendering intents resulted in the same histogram accoding to Royce's findings, is strange, indeed.

Regards

Wolfgang

I don't know that I would go so far as to call it a bug in Adobe's color engine (ACE). No question that Adobe know what they are doing with color management. Right now I'm basically considering it an undesirable side effect of a behavior that I don't understand... but it still could be a "feature". How's that for political correctness? We do have an Adobe team member here, and hopefully he will have some time to comment on this thread in due course.

WJaekel wrote:Changing the color engine to MS ICM would never been an approach I would have considered ! The big question is now, if ICM is a better choice for the conversion at default - or should only be used for problems discussed here. I have no idea if you can run into different (color) problems for various kinds of images using ICM, because I always have left the PS setting at Adobe ACE until now. I don't know either how many photographers have changed the color engine for their workflow and could comment about their experiences.

I suspect very few photographers have used anything other than the default setting, ACE, for color space conversions within Photoshop. For one thing, I presume it will be consistent across platforms, operating systems, and the components of the Adobe tool suite; this can't be said for any other color engine. In the past, I have always used ACE within Photoshop and I've never had any reason to doubt its effectiveness until now.

I can't say whether MS ICM will have issues of its own, but given the upheaval that happened with the Windows color management system between XP and Vista, and that Vista itself might not yet be a stable platform for color management, personally I'd be reluctant to recommend switching to MS ICM for everything. (And yes, I realize that is a bit inconsistent since my image browser, ThumbsPlus Pro, almost certainly uses MS ICM as its color engine. But I only use it for prepping web files and other utility functions, not for anything in my critical image output workflow.) We'll need some more information, and I need to run some more tests including CS4, Vista and other things.

WJaekel wrote:It's interesting that the gamut (softproof) warning doesn't display any issues in the upper right corner of the image where I realized the posterization in the red channel at first.

The gamut warning does not show in the upper right corner because the blue sky color tones up there are within the gamut of sRGB. So there is nothing up there to warn about. However, when the color space conversion takes action, it is a global action affecting the RGB channels equivalently across the entire image. It is not a selective action that only impacts part of the image. Although one would think that Relative Colorimetric should leave the in-gamut colors alone, I guess there is some chance they may shift a little bit because the gamut volume of sRGB is so much different from that of ProPhoto RGB. Nevertheless, once the Red channel clipping in particular occurs, the posterization problem becomes most evident in the upper right corner because that is an area of what we expect to perceive as continuous tone. Posterization always is most visible in continuous tone, not in areas that contain detail such as the iceberg or ripples on the water -- though those areas have been hit by the Red channel clipping just as badly.

WJaekel wrote:People could think that the discussion on the photo displayed here is kind of picky and pedantic. But I hopefully could eplain that this a basic problem for many photos including deep blue tones. [...] As soon as I have installed my printer, I will do some additional tests.

Having looked at some of my own images, I now think this issue could be relatively common for people working with ProPhoto RGB. We do need to do some more digging to understand why this is happening and what other things could be done about it. And of course look at the situation with printer profiles, which I will be doing next.

I need to re-evaluate several of my images in light of this scenario, just to satisfy myself that I was getting the best quality I could get out of the printing workflow. Fortunately I do not print from Photoshop, but use Qimage, which initially looks like it might be not as significantly impacted by this situation. But certainly this may explain some issues or complaints I have heard about from other folks with respect to red shifts and sRGB conversions. It would be interesting to evaluate how much or if it happens with source images in Adobe RGB as well.

E.J. Peiker wrote:[...] I started thinking - bug in Adobe's rendering algorithms. The fact that the different rendering intents produced absolutely identical results is a big red flag. Also having such HUGE differences between other applications trying to do the same thing as Photoshop is another red flag.

I don't know enough yet to say whether it's a bug, but I hope we'll be able to get a read on that from our resident expert. I've thought a bit more about the identical results from Perceptual and Relative Colorimetric, and I guess it may or may not be an issue. In particular it may not be an issue with Photoshop's ACE color engine, since the other applications also produced identical output from Perceptual and Relative Colorimetric. But the other apps produce quite different results using Absolute Colorimetric, which was not the case with ACE. Because sRGB and ProPhoto RGB are synthetic color spaces that have been engineered, rather that created from measured values output by any specific device, the way their internal conversion tables for the various RI's work probably is different than is the case for profiles created for monitors and printers. I don't really have the tools for this level of internal profile analysis.

E.J. Peiker wrote:I have never run across this but that doesn't mean it hasn't happened. Have you tried to see if different versions of Photoshop, such as CS3 vs. CS4, makes a difference. maybe something got broken in PS.

I will check CS3 on Vista and CS4 on Vista as two more options, in the next day or two. I don't have CS4 on XP right now, as I was hoping to consolidate my upgrade to CS4 with a simultaneous move up to Vista 64-bit. But I don't have my new workstation built yet, so my workstation remains XP for now and I've been reluctant to possibly destabilize it by throwing CS4 in there. For now CS4 remains installed only on my new laptop running Vista 64-bit, with its abysmal LCD. I may need to put CS4 also on my old XP workstation, though, depending on how things go with the new workstation.

gradient wrote:What is interesting here is that there are "workarounds" to this problem....but a true solution seemingly lies within modifications to the conversion algorithm. Is anyone prepared to approach Adobe on this?

I should emphasize that, aside from whatever the ACE color engine is doing to the Red channel shadows, soft proofing and making output-specific image adjustments before (and possibly after) color space conversions is not a work-around. It is an expected part of the color managed workflow for anybody who wants the best quality they can get out of their images. No matter what automatic algorithms may or may not be doing and why they are doing it, nothing will ever beat the photographer taking and keeping creative control over the tools. The best we want from the tools is not to make our lives harder or get in our way by manufacturing extra work for us. But color spaces, especially ones that are designed to profile various devices like monitors and printers, will always have a wide variety of differences. Some level of double-checking and possible corrections should be expected when moving images from capture to print...

gradient wrote:
What is interesting here is that there are "workarounds" to this problem....but a true solution seemingly lies within modifications to the conversion algorithm. Is anyone prepared to approach Adobe on this?

Thanks Wolfgang for bringing this to light....Prost Neu Jahr!!!

Thank you ! - If we can confirm for more pictures, that the rendering intents ALWAYS make no difference for the histogram, it would indeed be a good idea to contact Adobe on this matter.

Happy New Year to you as well !

Wolfgang

Royce Howland wrote:I But certainly this may explain some issues or complaints I have heard about from other folks with respect to red shifts and sRGB conversions. It would be interesting to evaluate how much or if it happens with source images in Adobe RGB as well....

Here we go: I processed the raw-file of the iceberg image through CaptureOne to 16bit AdobeRGB tiff and converted this one to 16bit sRGB tiff now. All settings were left at default in C1 and identical to the processing to Prophoto discussed above. RI was set to relativ colorimetric but I tried perceptual, too. Again, the histograms of the sRGB files were exactly identical. So I only attached the one for the relativ colorimetric intent below.
You also get the red channel clipping in the sRGB file - maybe even a bit more -, but there was no shifting of the blue channel this time and only a slight change in the green channel. I had experienced the red channel clipping and posterization in the darker blues for a longer time when I still had used AdobeRGB for my master files.
Best Regards
Wolfgang

Thanks for that Wolfgang...
You just answered my next question of whether it was just a problem converting ProPhoto to sRGB and if AdobeRGB to sRGB would fix it.

Okay, well at least it's consistent.

This would also explain why in Photoshop, you can sometimes get a very large visible color shift when you convert from ARG to sRGB where in virtually all other apps you see almost no perceptible color shift on screen.

Fantastic thread.....hopefully Eric has read through it and he or someone else can shed more light...Thanks everyone for the learning...

I have yet to look at the printer profile side of this equation, but I haven't forgotten about it. Will be coming as soon as I have time to get into it...

Royce Howland wrote:When running the color space conversion in Photoshop using Edit > Convert to Profile, we have the option of picking a rendering intent. So the first thing I tried was selecting different RI's, expecting to see a difference between Perceptual and Relative Colorimetric, the two most commonly used RI's. Not only did I not see any difference between these two RI's, I also didn't see any difference with the Saturation or Absolute Colorimetric RI's either. All four of them produced identical results! Likewise if I enabled or disabled Black Point Compensation, which can potentially affect conversion of shadow tones -- in this case it had no effect at all. Every histogram in the resulting sRGB image looked exactly the same -- clipped Red channel, Blue channel shifted to the right, Green channel largely unaffected. This was really starting to seem odd to me.

This isn't surprising at all, it's working as it was designed to. The standard sRGB and ProPhoto RGB profiles are Matrix profiles which describe exactly one color transformation (thus you get the same results for the relative/perceptual/saturation intents). You need a LUT profile to support multiple rendering intents (almost all printer profiles are LUT profiles).

There is a LUT version of sRGB at (the ICC v4 download):
http://www.color.org/profdump.xalter
which has two conversion tables, one for perceptual and one for relative colorimetric.

Using the perceptual mapping of this profile on the posted sample shot avoids the red channel clipping (of course, you get the typical saturation/contrast loss you generally get using the perceptual intent).

-- Tilo

Thanks for the info on that, Tilo. My knowledge of the internal workings of ICC profiles is not nearly as deep as their "black box", externally observable results. Going from your link, I found this specific one regarding the new ICC v4 sRGB profile:
http://www.color.org/srgbprofiles.xalter

Specific statements about this new profile, which appears to be a "beta" version, include:

The advantages of the new profile are:

1. More pleasing results for most images when combined with any correctly-constructed v4 output profile using the perceptual rendering intent.
2. More consistently correct results among different CMMs using the ICC-absolute colorimetric rendering intent.
3. Higher color accuracy using the media-relative colorimetric intent.

For readers who may want more background, the ICC web site also provides what they call an "intermediate level" white paper describing use of the new v4 profile:
http://www.color.org/ICC_White_Paper_26 ... rofile.pdf

I haven't read up in depth or tested this new profile yet but will now add that to my burgeoning to-do list.

P.S., it seems clear now that the channel clipping problem highlighted in this thread is not a "Photoshop bug". Rather it's a side-effect of how the original (v2) sRGB color space works in combination with several different color engines and how they implement specific rendering intent transforms.

I just tested CS4 on Windows XP, and it behaves the same as CS3. I have not tested either on Vista yet.

Having just looked at the ICC v4 sRGB profile in Gamutvision, it seems... odd. Either Gamutvision is not handling the profile properly, or else it has some pretty extreme characteristics to it that produce very weird results -- not in a good way. The v4 version's gamut is very much reduced from the v2 version's gamut, creating across-the-board deltaE variances with Wolfgang's iceberg test image used in the examples above. Here are two views from Gamutvision, first showing gamut volume (wireframe is v2 sRGB, solid is v4 sRGB), second showing deltaE-00 of the v2 version vs. the v4 version. The first view shows that the v4 profile appears to have a lot less gamut in the darkest shadow tones, which is where the gamut volume loss mostly occurs compared to the v2 profile. This corresponds to the high deltaE values when directly comparing the two sRGB versions against each other in the second view.

If we compare the ProPhoto RGB color space to the v2 sRGB color space, we see how the deltaE metric maps out the areas of difference across the range of hues. This is what we potentially have to compensate for, normally speaking, when moving from the very wide ProPhoto RGB gamut to the very narrow sRGB one: But if we compare ProPhoto RGB to the v4 sRGB color space, we see something like the normal gamut variation plus two very bizarre, extreme "stove pipes" in the red-magenta and green-yellow midtone hues; I have no explanation for this but they don't look good : Here once again was the Gamutvision display showing what kind of deltaE metric exists across the iceberg image when converting from ProPhoto RGB to sRGB (v2 color space) via the Relative Colorimetric rendering intent: And here is the same view but converting to the v4 sRGB color space instead, also using Relative Colorimetric: And here is the view of converting to the v4 sRGB color space using Perceptual as the rendering intent: The same dark blue areas that were out of gamut before with the old v2 sRGB color space are out of gamut with the v4 profile too, but to a more significant degree. And far more of the image than before shows that a hit will occur across the conversion, most of it to a degree that definitely would be very noticeable.

The Perceptual rendering intent now produces different results than the Relative Colorimetric intent, as Tilo indicated. However Perceptual over-all appears "worse" from a color accuracy point of view, since it is shifting more colors across the image -- this is what Perceptual is designed to do. But both rendering intents with the v4 profile hammer the image to a pretty significant degree IMO. From talking to Norman Koren (producer of the Gamutvision tool), I'm pretty sure Gamutvision should be handling the v4 ICC profile okay.

Here is the histogram from converting the test image to the v4 sRGB color space using the ACE color engine with Relative Colorimetric + BPC in CS4: And here is the histogram from converting it the same way but selecting Perceptual + BPC instead: We can see that with the Relative Colorimetric rendering intent, the ACE color engine produces a result that is basically identical to what we got from the v2 version of the sRGB color space with any rendering intent. However with the v4 color space and Perceptual, we get a much better looking histogram. However the caveat is that the over-all deltaE impact on the image with the v4 sRGB conversion is much larger.

Now let's look at using CS4 with the Microsoft ICM color engine selected and v4 sRGB, first with Relative Colorimetric + BPC: And now switching to Perceptual + BPC: Lo and behold, the MS ICM color engine with Relative Colorimetric now clips the Red channel in the histogram almost identically to the clipping that occurs with the ACE color engine when it clips. The MS ICM color engine with Perceptual does not clip; but it avoids clipping with a different resulting distribution of tones than is the case when using this color engine with the v2 sRGB color space. With both rendering intents and the v4 color space, the MS ICM color engine produces results much closer to what is produced by ACE, than is the case with v2 sRGB.

This further reinforces that the channel clipping shown in this test case is not, I would say, a problem with Photoshop. It is an issue with the v2 sRGB color space; the MS ICM engine may be the one that has a bug or a quite possibly a special purpose "hack" designed to compensate for this very problem, given the ubiquity of sRGB. The v4 sRGB color space has some significant differences, including a Perceptual rendering intent that can be used to avoid the clipping that still occurs with its Relative Colorimetric intent. However the v4 sRGB color space has other issues, including a much reduced gamut that in this case I suspect would make it not a very suitable choice for this image because of the hit in the blues.

There might be other issues in attempting to pull the v4 sRGB color space into a workflow, including that some apps don't support v4 ICC profiles. Also most people don't have this v4 profile installed on their machines, so it couldn't be used purely as a replacement for the original sRGB color space as yet. It would more likely need to be used as an intermediary space for a two-stage conversion, though its gamut issues make that problematic. The ICC web site does refer to the v4 sRGB profile as a "beta", so perhaps it can & will be improved further...

Royce, thank you very much again for the fantastic work you did. Unfortunately, I have not the time right now to plunge deeper into the whitepaper #26 published by the ICC and to test the sRGB-v4-ICC profile extensively by myself. However, from the proofs you have shown here, it seems pretty clear to me, that sRGB v4 at its present release state cannot provide the solution. If I sum it up correctly - based on the Gamutvision displays and histograms, you either get about the same red channel clipping or - using the perceptual RI - you could avoid the clipping at the cost of a severe impact on the color accuracy. Additionally, I don't know anything about possible side effects, such as an incompatibility with other applications if v2 is replaced by v4. Though Tilo's comment and the link provided can shed some light on the identical results of all RIs we get if the file was converted from Prophoto to sRGB v2, v4 obviously is not the route to go. For now it seems to me, that the best way to address the problem either is the change of the color engine to ICM or to apply a curve prior to the conversion while staying with the v2.
Of course it's important how the prints look in the end. As soon as I've have the time to send them to the Printservice or print by myself, I will report about the results here.

Thank you very much again for all your efforts -this thread has become incredibly instructive.

Wolfgang

Wolfgang, I agree with your summary. I still have one outstanding issue to address with this example and that is the effects when considering color space conversion for printing. Hopefully I will have time this coming weekend to look into that and post some results...

Sorry I am late in responding to this thread ...

Yes, the issue is mostly a limitation of v2 ICC profiles. All of the v2 RGB working space profiles (e.g., sRGB, Adobe RGB, and ProPhoto RGB) are simple matrix-based profiles with no indication of how any gamut compression should be performed. Thus using Relative Colorimetric vs Perceptual vs Saturation intents with the Adobe Color Engine (ACE) in Photoshop makes no difference when doing RGB working space conversions with these v2 profiles -- they are all effectively doing Relative Colorimetric with Black Point Compensation. For the images in question, these have relatively high red-channel noise (open skylight + ice leads to very low red response on most sensors which are IR-filtered), and the red channel gets stretched a lot during the ProPhoto RGB to sRGB relative colorimetric conversion. The red primary of ProPhoto RGB is very far from the sRGB red primary, so a lot of stretching is required. (This doesn't happen with Adobe RGB to sRGB conversions, at least not so much, because the Adobe RGB and sRGB red primaries are the same.)

Color management modules (CMMs) or applications may perform gamut compression even when using v2 ICC RGB working space profiles. This is likely accounting for the differences that Royce found above when using different apps and CMMs to perform the PPRGB -> sRGB conversion. A simple example is looking at an image in Canon's Digital Photo Professional that is converted to Wide Gamut RGB vs sRGB. Consider a color that lies within both gamuts. You'd expect the results (visually) to be the same, right? But they're not. DPP does additional color rendering (typically a contrast and saturation boost) when the user has selected sRGB, to deal with the fact that sRGB is a smaller gamut. This is similar to how when you're preparing a print on matte paper vs glossy paper, you will often need a contrast or saturation boost for the matte print, compared to the glossy.

Hope this helps somewhat ...

Eric Chan wrote: For the images in question, these have relatively high red-channel noise (open skylight + ice leads to very low red response on most sensors which are IR-filtered), and the red channel gets stretched a lot during the ProPhoto RGB to sRGB relative colorimetric conversion. The red primary of ProPhoto RGB is very far from the sRGB red primary, so a lot of stretching is required. (This doesn't happen with Adobe RGB to sRGB conversions, at least not so much, because the Adobe RGB and sRGB red primaries are the same.)

Eric, thank for your comments and explanations. Though I see your point regarding the stretching of the red channel during the conversion from ProphotoRGB--> sRGB , the channel clipping and resulting posterization is even worse if the AdobeRGB colorspace is preset for the raw conversion and thus is used for the master files prior to the conversion to sRGB - at least according to my findings. You can also see this from the histograms I had added above in this thread and from the files provided through my second link. BTW, if I look at the red channel I don't see much noise in ProphotoRGB while it's sometimes there in AdobeRGB to a certain amount.
I had used AdobeRGB for years and had faced heavy posterization in some images with deep blue or cyan tones due to the red channel clipping -at the latest if they had been converted to sRGB for the Printservice which I had used at that time. Consequently, the prints had shown banding and patches. In the run of this discussion, I converted some of the critical raw files for a second time, now using 16bit ProphotoRGB-files as starting point and I was surprised that the results after the conversion to sRGB came out much better regarding the posterization though the issue was still there, at least as long as Adobe ACE was used.
The theoretical background aside, the most important point of this thread has been the question, how you can deal with this problem. Until now, I think the change of the color engine to ICM for the conversion can oftenly help to avoid the clipping and posterization. In addition to the red channel issue, the analogous problem occurs if photos with apparent (or "hidden" bright yellow tones - i.e. captures of bright green plants or yellow flowers - are converted to sRGB. In this case, the blue channel is clipped. And again, there's oftenly no clipping if I switch to Microsoft ICM. I don't know anything about the alorithms that cause the differences of ACE vs ICM nor the drawbacks of the switch to ICM for the critical files. But for now, I don't see any alternatives apart from the ones, Royce has pointed out. Before, I had no choice but to reduce the saturation of the critical colors which can result in a severe loss of the vibrance, of course.

Regards

Wolfgang

Hi Wolfgang, please keep in mind that if those colors are out of gamut with respect to sRGB then no matter which profile or CMM you use, you'll have to reduce the saturation of those out-of-gamut colors anyways. Either you do it manually, or the profile (or CMM) does it for you behind your back. It's sort of like the print resolution of the driver, e.g., the Epson 3800. You can either choose to resample the image to 360 ppi, or let the driver / operating system take care of it for you. Either way, it's going to happen.

The other thing worth doing is checking where these colors are with respect to your monitor gamut. You can do this in PS by choosing soft proof but selecting your monitor profile as the profile, instead of a printer profile.