I recently discovered that just about every Photoshop adjustment gives different results depending on the color space of the image. And I mean identical adjustments on identical images whose colors fit within the smallest color space, sRGB. With over 10 years experience in digital image processing and extensive coverage of various forums, I'm amazed and a little baffled that I've not seen this "problem" discussed, especially in the various debates over ProPhoto vs. Adobe98.

Having followed those debates, I had chosen to process in Abobe98. But recently I shifted to using ProPhoto. I started noticing some strange results from a few of my custom actions. Most noticeable were some custom gradient maps I use to adjust and normalize skin tones in portraits. Some testing disclosed the following:

1. When color adjustments are recorded in an action, the numeric values for the colors are hard wired for the color space the image is in at the time the action is recorded . When you run that action on an image in a different color space, the colors you get are wrong. I developed and recorded my actions while in Adobe98. If I run them on a ProPhoto image I get different (and wrong) colors.

However, I did find a fix for this problem. If you put the image in LAB color space before recording the action, the color values will be recorded and later applied as LAB values, even on an RGB image. Thus they get properly translated to the appropriate RGB values for any RGB colorspace.

2. Layer blend modes create different results. Actually, blend modes create identical results in sRGB or Adobe98, but quite different results in ProPhoto or LAB. To see the difference, create an Adobe98 document with two layers of different colors. Put the top layer in something other than normal blend mode (multiply, color, hue, soft light, etc.). Dupe the document, convert it to ProPhoto, and toggle to see the difference. I don't understand why this is and can't find a fix.

3. Things that map tones based on their grayscale value behave differently between Adobe98/sRGB and ProPhoto or LAB. Both ProPhoto and LAB map grayscale values at different locations. Create an Adobe98 document with a simple black to white gradient. Dupe it and convert to ProPhoto. Then apply the "Posterize" adjustment to each, using 4 or 5 poster levels. Look how the bands fall in different locations.

My gradient map actions suffered all three of these problems. The colors were hard wired as Adobe98 values, the blend mode was Hue, and the values fell in different locations on a ProPhoto image. Thus, a gradient map designed to add a "warm" skin tone in Adobe98 created an orange tone in ProPhoto.

In the many tutorials and actions I've studied, I've don't think I've ever seen anyone mention that results will vary depending on color space.

Actually, if you think about it, it's obvious that actions recorded in one color space will result in different results in other color space. Two issues; one if gamma, PP RGB's gamma is 1.8 and Adobe & sRGB are 2.2. This will have a material impact on any tone adjustments made. Second, the color gamut...numbers remain hard coded in an action but what the colors mean changes based on the color space.

When Martin Evening developed PhotoKit Color, he had to come up with actions that were specific to the color space of the images that they were run on.

One caution–converting images to L*a*b* has its own set of problems...round tripping from RGB to Lab causes color errors (rounding errors plus blue hue changes) the first time you do it (the color errors are essentially eliminated if you do multiple round trips). The fact you are recording the action in Lab will have an impact on the results depending on the color spaces involved...however, I suspect that the color errors introduced transforming the Lab recorded actions into various color spaces would be considerably less than the differences you see running the same action on multiple color spaces. So, this approach would probably be better unless you want to record separate actions on a per/color space basis. BTW, we've found the biggest changes are from PP RGB to any other color spaces...the differences seen between Adobe RGB and sRGB are far more subtle...

I suspect that this isn't widely discussed is because most people who record actions probably have a pretty refined color management workflow and avoid bouncing around to different color spaces...

I recently discovered that just about every Photoshop adjustment gives different results depending on the color space of the image. And I mean identical adjustments on identical images whose colors fit within the smallest color space, sRGB.

I recently discovered that just about every Photoshop adjustment gives different results depending on the color space of the image.

This has been known by many for more than a decade. In fact, in a paper presented in 2000 in Portland, Reference Input/Output Medium Metric RGB Color Encoding (RIMM/ROMM RGB), Kevin E. Spaulding, Geoffrey J. Woolfe and Edward J. Giorgianni, all of Eastman Kodak, noted that "The nonlinear transforms used in rendering will, in general, modify the relative ratios of the red, green and blue channel data. This can lead to hue shifts, particularly for highly saturated colors." and proposed as an advantage of what we now call ProPhotoRGB that it was better than sRGB and Adobe 1998 RGB with respect to the size of these shifts.

Is there a good, accessible (to the non-scientist) reference on the subject of color numbers, color spaces, profiles, bit depth, etc.? I find myself having to explain these things at length several times a year, and it would be a relief to point to a good resource.

Thank you starting this thread, it's an interesting topic. Forgive the obvious question, but are all conversions / adjustments taking place at 16bit? Was thinking if somewhere in your workflow 8bit had been invoked, ProPhoto might reveal larger shifts. Also if any files were being flattened when moving between color modes.

As to #2 and the color shift... If helpful to you, when I use the edit > convert to profile command, there is the option to flatten to preserve appearance. When checked and I complete your test, there is no visible color shift on screen.

I recently discovered that just about every Photoshop adjustment gives different results depending on the color space of the image. And I mean identical adjustments on identical images whose colors fit within the smallest color space, sRGB. With over 10 years experience in digital image processing and extensive coverage of various forums, I'm amazed and a little baffled that I've not seen this "problem" discussed, especially in the various debates over ProPhoto vs. Adobe98.

Hi,

Yes, absolute color coordinates mean different things in different colorspaces. Also the Gamma differences between colorspaces can muddle the results. BTW, I use a Linear Gamma setting in the "Edit|Color Settings..." menu, and select "Blend RGB colors using Gamma: 1.00" in the advanced controls section.

Thanks for the replies. I don't know whether to feel good at discovering this aspect of color spaces, or to feel like an idiot because, "it's obvious, totally to be expected, and known by many for more than a decade." I suspect that for the vast majority of Photoshop users, it is far from obvious, very unexpected, and known by few.

It probably goes unnoticed by the majority because, as Jeff mentioned, they don't bounce around between color spaces. However, I'm still struck by the number of people who publish techniques (and maybe actions) without mentioning the color space they used to develop their results. Others who implement their techniques or use their actions could likely be using a different color space. There is a lot of interest currently in "color grading", with many techniques being offered. Again, I've never seen a warning that "your mileage may vary" depending on your color space.

Jeff mentioned Martin Evening and PhotoKit Color. I had never used it, so I downloaded the trial and gave it a spin. The documentation clearly states that the effects "have been optimized for all the main RGB color workspaces commonly used in Photoshop." However, that was not my experience in a few tests.

I converted a few raw files to both Adobe98 and ProPhoto. Then I ran several of the PhotoKit Color effects on both versions. There were easily visible differences on screen. In each test, I copied the ProPhoto version and pasted it on top of the Adobe98 version, letting Photoshop convert the pasted copy from Prophoto to Adobe98. I put the ProPhoto layer in Difference mode and looked at the StdDev values in the histogram pallet. I got StdDev values between 0.9 and 2.0.

For a baseline, I did the same with the original image and got StdDev values around 0.45. So the PhotoKit Color differences were not only visible, they were measurable to a significant degree. In fact, these differences were in line with the differences I was seeing in my other tests.

I recently discovered that just about every Photoshop adjustment gives different results depending on the color space of the image.

I noticed this effect in the early 1990s, considering it the inevitable result of applying non-linear corrections to the color planes of gamma-compressed images. I focused not so much on the differences among the same corrections applied in various color spaces, but on the (color-space-dependent) color shifts. I was concerned about the problem to such an extent that I devised an algorithm to reduce the errors, and published it in this paper: “Efficient, Chromaticity-Preserving Midtone Correction for RGB Images,” at the Second Color Imaging Conference in Scottsdale, AZ, in November, 1994.

Here’s the abstract: “RGB Gamma adjustment, the standard method for control of midtone values, causes large changes in chromaticity. This paper presents an image transform algorithm that allows control of midtone values while producing chromatically-correct results. The exact algorithm requires computations only moderately more complex than those required for gamma adjustment. Approximations to the algorithm are simpler to implement than gamma adjustment, yet produce results which are more chromatically correct.”

I didn’t apply for a patent. Anybody who wanted to implement my technique was welcome to have at it. And what happened? Unless you consider Adobe’s “Luminosity” blend mode (and I have no idea of what the math for that mode is), nobody picked up the approach I suggested.

Now it’s moot, because we have so much processing power we can throw at the problem that we don’t need approximate methods. Still, one blend mode aside, there hasn’t been an attempt in Ps to reduce color shifts that arise through applying curves to RGB images. Upon consideration, I think that is A Good Thing. The reason is, over the years I have become a big fan of transparency in image processing, which I define as the user knowing exactly the processing steps that are performed on the image.

In the early days of image editing, there wasn’t a conflict between transparency and “do what I mean” transformations. Pretty much everything was transparent if the user knew a little about color science and image processing algorithms, and, if the results weren’t what the user expected, that was just tough.

Now, thanks to almost twenty five years of commercial success of desktop image editing and an incredible increase in desktop processing power, transparency is fading away. Powerful third-party plugins do their mysterious work magically -- Arthur C. Clarke said once that “Any sufficiently advanced technology is indistinguishable from magic" -- with algorithms that are secret. Lightroom started out with a “don’t worry about how we do it” mindset, and has become more opaque with each major release.

To some, that’s an unalloyed good thing. I have a more nuanced response. I like what the new plugins and the new Lightroom processing can do, but I can’t help but think that I’d be better at using the controls if I knew exactly how they worked.

That’s why I’m happy that there are still curves with normal blending in Photoshop. It’s the devil I know.

For a baseline, I did the same with the original image and got StdDev values around 0.45. So the PhotoKit Color differences were not only visible, they were measurable to a significant degree. In fact, these differences were in line with the differences I was seeing in my other tests.So I'm wondering, am I doing something wrong? Are my test methods flawed?

Again, this is to be expected, you're not doing anything wrong. The expectation that you'll get identical results from differing RGB working space is probably the issue. If you did an edit in say ProPhoto RGB and converted it to sRGB for web use, there would be differences. For example, I have a document made in Adobe RGB whereby each pixel represents 1 color that falls within Adobe RGB (1998). There are 988 such pixels of differing colors, again, all that fall within Adobe RGB (1998). I convert that to sRGB in Photoshop. I take both into ColorThink and build a Colorlist where each pixel becomes an RGB/Lab value and ask it for a dE report. I get this:

To BartvanderWolf - What is a "linear gamma setting in Edit/Color Settings." I can't find that (in Win7/CS6). I do see the "Blend RGB colors using gamma 1.0" and I tried it, but saw no difference.

That's the one, you've got it. I don't know what your actions do, but when adjustment layers are blended together, they are blended in gamma=1 space, which should prevent the errors that you get when blending in gammaspace 2.2 (Adobe RGB) or 1.8 (ProPhoto RGB).

I noticed this effect in the early 1990s, considering it the inevitable result of applying non-linear corrections to the color planes of gamma-compressed images. I focused not so much on the differences among the same corrections applied in various color spaces, but on the (color-space-dependent) color shifts. I was concerned about the problem to such an extent that I devised an algorithm to reduce the errors, and published it in this paper: “Efficient, Chromaticity-Preserving Midtone Correction for RGB Images,” at the Second Color Imaging Conference in Scottsdale, AZ, in November, 1994.

Here’s the abstract: “RGB Gamma adjustment, the standard method for control of midtone values, causes large changes in chromaticity. This paper presents an image transform algorithm that allows control of midtone values while producing chromatically-correct results. The exact algorithm requires computations only moderately more complex than those required for gamma adjustment. Approximations to the algorithm are simpler to implement than gamma adjustment, yet produce results which are more chromatically correct.”

That’s why I’m happy that there are still curves with normal blending in Photoshop. It’s the devil I know.

Jim,

The reference to your abstract is very interesting, but the abstract gives no details of your implementation. In an earlier post, you stated that color shifts are less prominent in ProPhotoRGB. My question is if these shifts can be eliminated by editing in a linear space (scene referred data)? Is the lesser error with ProPhotoRGB due to a gamma of 1.8 rather than ~2.2 with AdobeRGB and sRGB. Of course, Lightroom does its editing in a linear ProPhoto like space and gives histograms with an sRGB tone curve (Mellisa color space).

PS: I see Bart posed similar thoughts while I was posting this message.

That's the one, you've got it. I don't know what our actions do, but when adjustment layers are blended together, they are blended in gamma=1 space, which should prevent the errors that you get when blending in gammaspace 2.2 (Adobe RGB) or 1.8 (ProPhoto RGB).

Cheers,Bart

Nope,

Take multiply blending as an example: If a color is fully saturated in aRGB, then multiply will do nothing on the fully saturated channel, since it will be multiplying by 1.0. If you switch to pRGB where that same color is likely not fully saturated, it will do something as the value is lower than 1.0.

This is regardless of gamma encoding, although that error will be more pronounced in gamma 1.0 encoding.

In fact, I believe you shouldn't point users to advanced options like the blending gamma value unless you are absolutely clear that they know what they are doing. (No offence meant, obv).

"This paper attempts to devise image transforms for control of midtone values that produce chromatically-correct results while requiring only moderately-complex computations. Before discussing the transforms themselves, we must first investigate their goals. The simplest formulation is that the transforms should afford changes in luminance with no changes in chromaticity. Such transforms would be an improvement over those available today, but they would not be completely satisfactory. The effect of raising the luminance of part of an image can be likened to shining light into that section. The parallel is not perfect, since the operations described in this paper are all point-processes; that is, they operated on each pixel without consideration of any other pixel in the image, but the point is well illustrated if one thinks of an image as consisting of a group of solid-color patches. Raising the luminance of any one patch would be correctly performed if we were able to shine more light on that patch, and lowering the luminance of any one patch would be correctly performed if we were able to shine less light on that patch in the original scene. Such a change of illumination would result in a change of chrominance in a color space that correctly simulates the way that humans respond to color: as illumination increases, the hue of the object changes slightly or not at all, but its chroma increases. "

Here's the algorithm itself:

And, yes, the color shifts I'm talking about can be eliminated by editing in a linear space, but it's really hard to generate useful curves in a linear space. Lr end-runs that problem by presenting histograms and curves with the sRGB nonlinearity.

Is the lesser error with ProPhotoRGB due to a gamma of 1.8 rather than ~2.2 with AdobeRGB and sRGB.

In the RIMM/ROMM paper I referenced earlier, the Kodak people claimed that the reduction of chroma error in ProPhotoRGB stems mainly from the selection of primaries. They talk about the tradeoff between quantization errors, which are larger in a big RGB space, and chroma errors, which are smaller.

"There is a tradeoff between the color gamut of the primaries, quantization artifacts, and the extent of the hue shifts that occur during rendering. If the primaries are moved out so as to increase the color gamut, quantization artifacts will increase and the hue shifts introduced during the application of a nonlinear transformation will decrease. This results from the fact that the RGB values will be clustered over a smaller range, thereby reducing the impact of nonlinear transformations. If the color gamut is decreased by moving the primaries closer together, quantization artifacts diminish but hue shifts are generally larger and color gamut is sacrificed. During the selection of the RIMM/ROMM RGB primaries, an extensive optimization process was used to determine the best overall solution."

These days, with 16 bit quantization, we usually don't worry about quantization errors, and PPRGB looks even better.

By the way, I consider one aspect of PPRGB, the two non-physical primaries, to be a great example of thinking outside the box.

These days, with 16 bit quantization, we usually don't worry about quantization errors, and PPRGB looks even better.

By the way, I consider one aspect of PPRGB, the two non-physical primaries, to be a great example of thinking outside the box.

Jim

Don't be daft, the XYZ primaries on which pretty much the entire colorscience was build have always been considered non-physical primaries. If that's what Kodak thought of as out-of-the-box thinking, then it would explain a lot.

Incidentally, the misappropriation of Lab as a perceptually uniform space is primarily a result of the perceptual curves applied to the XYZ primaries. Hence, the colorconsistency of most RGB spaces is "better" in a gamma encoded form as opposed to its linear equivalent. (Think of HSB controls for example).

Don't be daft, the XYZ primaries on which pretty much the entire colorscience was build have always been considered non-physical primaries. If that's what Kodak thought of as out-of-the-box thinking, then it would explain a lot.

Agreed. Having "colors" that are not colors can be a big hurt me button in the wrong hands. The price we have to pay for a big honking RGB working space. But nothing to applaud!

Take multiply blending as an example: If a color is fully saturated in aRGB, then multiply will do nothing on the fully saturated channel, since it will be multiplying by 1.0. If you switch to pRGB where that same color is likely not fully saturated, it will do something as the value is lower than 1.0.

Hi Oscar,

I was talking about layer blending in gamma=1.0 space. Switching to another colorspace is something entirely different. As I said in an earlier comment, the absolute (RGB) coordinates mean something different in a different colorspace.

Quote

In fact, I believe you shouldn't point users to advanced options like the blending gamma value unless you are absolutely clear that they know what they are doing. (No offence meant, obv).

None taken, but it is unclear what the OP's action does. If it involves layer blending, then that is one potential source for errors which should be eliminated before addressing the switch to another colorspace, which is another potential source with different issues (perhaps even less suited for those not in the know). One should eliminate potential sources for errors one by one to stand any chance of finding the actual cause (if even avoidable), IMHO of course.

For those who are already familiar with my former experiences I've posted here in years past claiming sat/hue/luminance shifts of certain saturated colors created in ProPhotoRGB like cyans, blues, yellows and oranges after converting to sRGB on sRGB-ish gamut displays, I'm here to say this doesn't occur any longer after using newer ICC display profiles made by Xrite Colormunki Display compared to the previous older profiles created by the original Xrite i1Display using i1Match software.

The same colors now only slightly shift in luminance, barely noticeable. I tested this on two sRGB-ish displays, my old Dell 2209WA and my newer LG 27" which has a gamut slightly smaller than sRGB. I even refreshed Bridge's cache for the images in question and did a restart after connecting the Dell after removing the LG just to rule out the display profiles not being referenced correctly under the hood.

So it wasn't the color space the colors were created combined with the assumptions made here in the past of ProPhotoRGB>sRGB mapping errors referencing Lab but the lousy i1Match ICC display profiles causing the color shift issues.

However, I have to say I no longer get the more intense versions of the colors mentioned I used to start out with in ProPhotoRGB especially the cobalt blues and oranges which now I'm not even sure I remember correctly since I no longer have anything to reference against.

These ICC boys sure like to tweak things under the color management hood.

...I've posted here in years past claiming sat/hue/luminance shifts of certain saturated colors created in ProPhotoRGB like cyans, blues, yellows and oranges after converting to sRGB on sRGB-ish gamut displays, I'm here to say this doesn't occur any longer...

You are not the only one to report this but I believe I've posted in the past, you should not be seeing what you reported (as I and other's never did). Glad it ended up being poor display profiles instead of the actual data!