Color management in Photoshop

[Manfred M]

Sort of Dan, but not quite.

Your analysis of relative colormetric is right on. RGB Colour spaces are actually 3D (a red, green and blue axis). The shape of the surface is referred to as the "hull" of the colour space and any out of gamut colour is brought into gamut by mapping the specific R, G or B colour to the value of the hull. The "extra" colour data is discarded and hence the process is not reversible.

Perceptual is different as both the out of gamut colours and the in gamut colours are remapped to new values. The problem though is that there is no consistent approach on how this is achieved between different pieces of software. The software used is referred to as a RIP or Raster Image Processor, and each RIP will not have the same algorithm. Without knowing that, reversal is impossible. Even if it is known, there will be rounding errors (taking an Adobe RGB file that represents some 50% of the colours that humans can see, whereas sRGB is around 33%). If we are representing both colour spaces with the same number (256 x 256 x 256) values I see no possible way of rebuilding exactly the same data as in the original data set. Even this is only possible if the conversion algorithm is known; but taking say, the rendering profile from a OnOne or Capture One product and applying it with an Adobe product will not produce meaningful results.

That being said, this is NOT the way that colour space conversions work; these simply take the sRGB value and convert them to the equivalent AdobeRGB value, but within the hull defined by the sRGB colour space.

[DanK]

If I edit in ProPhoto working space and make them look really "pretty" in the review image - and then save as sRGB, gamut-clipping is almost inevitable.

That really puzzles me.

All but one of the software packages I use automatically maps to sRGB for displaying on my sRGB monitor, even though I edit entirely in ProPhoto or Melissa. So when I edit, I am automatically editing for a good appearance in sRGB space. The sole exception to that is Zerene, which tries to display whatever working color space I use, which results in very ugly colors on my sRGB monitor until I move back into something like Photoshop.

However, if one is working with a wide-gamut monitor, I can see the problem you describe occurring. One reason I haven't yet switched to a wide-gamut monitor is because I haven't decided how to handle that in my workflow. It seems to me that it may require two edits, one for printing (which I would keep in the widest gamut possible and then map to another space via softproofing), and a second for display on the web, which would be in the sRGB space.

Am I missing something here? If not, I would appreciate suggestions from people who use wide-gamut monitors about how they deal with this. I recently got the new computer that I want to pair with a better monitor.

[george013]

Sort of Dan, but not quite.

Your analysis of relative colormetric is right on. RGB Colour spaces are actually 3D (a red, green and blue axis). The shape of the surface is referred to as the "hull" of the colour space and any out of gamut colour is brought into gamut by mapping the specific R, G or B colour to the value of the hull. The "extra" colour data is discarded and hence the process is not reversible.

Perceptual is different as both the out of gamut colours and the in gamut colours are remapped to new values. The problem though is that there is no consistent approach on how this is achieved between different pieces of software. The software used is referred to as a RIP or Raster Image Processor, and each RIP will not have the same algorithm. Without knowing that, reversal is impossible. Even if it is known, there will be rounding errors (taking an Adobe RGB file that represents some 50% of the colours that humans can see, whereas sRGB is around 33%). If we are representing both colour spaces with the same number (256 x 256 x 256) values I see no possible way of rebuilding exactly the same data as in the original data set. Even this is only possible if the conversion algorithm is known; but taking say, the rendering profile from a OnOne or Capture One product and applying it with an Adobe product will not produce meaningful results.

That being said, this is NOT the way that colour space conversions work; these simply take the sRGB value and convert them to the equivalent AdobeRGB value, but within the hull defined by the sRGB colour space.

I had to find out what you meant with Raster Image Processor. What I learned it is a layer before using a graphical printer, a inkjet or laser. My administration software is still using PCL, printer command language. This has to be translated to a graphical page to be used for a common graphical printer. https://en.wikipedia.org/wiki/Raster_image_processor.
I don't see the relation with color management.

George

[Manfred M]

I don't see the relation with color management.

That is the stage where the rendering intent and the print profile are applied for output. That is the final stage of the colour managed workflow. In some photo editing software (Photoshop and Lightroom definitely do this), this is emulated in the soft proofing functionality.

[xpatUSA]

That really puzzles me.

All but one of the software packages I use automatically maps to sRGB for displaying on my sRGB monitor, even though I edit entirely in ProPhoto or Melissa. So when I edit, I am automatically editing for a good appearance in sRGB space.

Taking my Sigma Raw Converter as an example (not playing the Sigma/Foveon card, by the way):

As you say, it maps to sRGB for the review image so the images themselves look the same irrespective of the selected working space. Nothing new but the color-picker itself gives different values - wildly different for ProPhoto.

My view of that is: during conversion, the raw image data is converted to either Kodak RIMM or ROMM (I'm never quite sure which). Now, if I'm in sRGB W/S the unseen working file is converted from say RIMM to sRGB and the color-picker gives sRGB numbers. If I then change the W/S to ProPhoto, the working file is converted (in Adobe terms) to ProPhoto but the adjustment sliders stay unchanged and now the color-picker gives ProPhoto numbers even tho' the review image looks the same.

So here I am in ProPhoto and I've colored my red flower to some gloriously saturated red, say 240,30,10 RGB. That's a real color of XYZ = 0.723, 0.275, 0.00243. Try to show that real color in sRGB and Bruce Lindbloom's CIE calculator tells me sRGB = 338, -119, -30. Pretty hard to show on any device, eh?

[Manfred M]

Trying to show what different colour space conversions do for the photographer and overlaying the impact of rendering intents while outputting to the web is going to be problematic, but I will see if I can explain my experiences here and why I use the workflow that I do.

First of all, it is important to recognize that when we capture raw data, we are capturing the widest range of colours our cameras can capture. The actual values are going to vary based on the sensor capabilities and the ISO setting we are using. The moment we want to turn this data into an image, we have to make some decisions; the colour space we use and the white balance setting are two very important considerations here. While we still have the raw data, we can always go back and change our mind regarding what we have decided to do. If we shoot JPEG, we turn those decisions over to the camera's design team...

The other issue is the capabilities of our computer screens. Unless the manufacturer advises us in the specs that our screen is close to 100% to sRGB or AdobeRGB colour spaces, we don't know how well the devices are capable of displaying the colours. Further, unless the screens have been calibrated and profiled, we don't know that our screens are showing the colours accurately. Other than perhaps our eyes, our computer screens are often the weakest link in a colour managed workflow.

Our computers can be feed colours that are out of gamut (OOG) for the colour space we are using to the screen, so our computer operating system (and software) need to be instructed on how that eventuality has to be handled, so the user can set up or change these parameters in the settings. This is the Windows 10 screen where rendering intents are assigned:




This at least gives us an image to work with, regardless of the colour space we are using, but it is important to understand that our operating / software will be doing some behind-the-scenes work in handling these conditions.

In Photoshop (and Lightroom, I believe), we can use the software to "soft proof" our colour spaces. This is normally something done in printing, as the printer and paper selection will have different gamuts, as it is based on using an ICC profile, we can also do this for screen output. I have taken a "difficult" image and used three different colour spaces; ProPhoto RGB, Adobe RGB and sRGB to see what part of the image is OOG. The gray areas in the image show these problem areas. There is one issue with the OOG warning, it doesn't indicate how much it is OOG, it could be a little or it can be a lot. These are sRGB screen captures of what the soft proofing shows in Photoshop:


1. ProPhoto RGB - this is the widest colour space, so as expected this are no OOG areas identified.






2. Adobe RGB - As a considerably smaller colour space, there are significant areas of saturated reds that are OOG in this image





3. With sRGB, very little of the red colour is in gamut





Just out of interest, I have included a straight-out-of-camera sRGB JPEG to see how the camera's implementation of rendering intent handled this challenging image:



The image has a decided orange colour to the red dress.


Finally, here is how I brought the image into gamut by manually tuning it. Saturated, deep colours tend to be the ones that are OOG, so I reduced the saturation and brightness to get this result.




Moral of the story? There is no simple way of finding the "best" way of handling OOG colours. I prefer the manual, rather than automated approach, as the colours seem more accurate and "true" to the scene that I shot. Others might use a different approach.

So Dan, this is not a wide gamut issue per se, but rather one where personal choices come in. Your wide-gamut screen will give you more "accurate" colours in the saturated colours and if you plan to print, these colours will be a better match to what a photo printer will output especially on glossy and lustre papers, When it comes to output on the web and informed, purposeful decision making will be the best guidance there.

Vision, and especially colour vision, is a combination of physiological and psychological factors, so it really is up to you to determine how you want to handle OOG issues. This is why I do not subscribe to Ted's more numeric approach as it ignores these aspects of colour vision.

The default sRGB approach is a "lowest common denominator" way to proceed, and if that is what you want, that is fine. I prefer working in the widest possible colour space that gives me the results I want; Adobe RGB is generally a better choice than sRGB and in many cases, going with ProPhoto RGB is probably the best approach, but not everyone I knows agrees with me. Virtually everyone I know would suggest working in AdobeRGB is going to be better than sRGB, but one has to remember to reprocess the image to sRGB before output to the web.

[DanK]

Manfred,

A very clear example. thanks

Dan

[xpatUSA]

Vision, and especially colour vision, is a combination of physiological and psychological factors, so it really is up to you to determine how you want to handle OOG issues. This is why I do not subscribe to Ted's more numeric approach as it ignores these aspects of colour vision.

For the record Manfred, Bruce Lindbloom's calculator is firmly based on the CIE results of their 1931 tests which involved actual people twiddling knobs until, in their opinion, this color matched that.

I can not imagine anything that is more dependent than that on a "combination of physiological and psychological factors".

So, your comment really holds no weight with me, sorry.

[george013]

Manfred,
The question in this thread was if it was possible not only to go from a wider color space to a smaller but also to go from a smaller to a wider color space. This has not been answered. And no sign of RIP.

I think your screenshots show what happens with the image when going from a wide color space to a narrower color space using a specific rendering intent. What would answer the question is opening the out off the camera sRGB jpeg and compare that one when shown in a wider color space.

George

[Manfred M]

Manfred,
The question in this thread was if it was possible not only to go from a wider color space to a smaller but also to go from a smaller to a wider color space. This has not been answered.

I thought it had been answered. When a narrower RGB colour space is "upsampled" to a wider gamut one, the output will look exactly the same as the lower gamut one. The colour values that are used internally might change, but the two images will look identical.

And no sign of RIP.

https://en.wikipedia.org/wiki/Raster_image_processor

I think your screenshots show what happens with the image when going from a wide color space to a narrower color space using a specific rendering intent.

No, what I have shown are raw conversions to each of the three colour spaces and the OOG colours in each. I have not done any conversions from one colour space to another.

What would answer the question is opening the out off the camera sRGB jpeg and compare that one when shown in a wider color space.

George

That is exactly what I did in the first image and the fourth image:

This is what the SOOC JPEG looks like:




This is the ProPhoto colour space image generated from the raw data in Adobe Camera Raw:




The dress and balloons are more accurate from the ProPhoto data. They did not have the yellow / orange colours seen in the SOOC JPEG.

[george013]

I thought it had been answered. When a narrower RGB colour space is "upsampled" to a wider gamut one, the output will look exactly the same as the lower gamut one. The colour values that are used internally might change, but the two images will look identical.

They should look always the same, well nearly. That's due to the rendering intent. In your example perceptual.
From http://www.colourphil.co.uk/rendering_intents.shtml:

Perceptual:

This will attempt to render colours in a way which is natural to the human vision. The gamut of the source image colour space (typically a 'Working Space' or camera profile) is scaled to the output colour space (usually a printer profile). This will pull out of gamut colours into gamut. Colours at or near the edge of the gamut will also be pulled in to give a distinction between them. This will generally give a pleasing result. Different ICC-profiling software vendors achieve different results with the Perceptual intent. In particular, profiles generated with older software versions may exhibit a lack of saturation. Perceptual should usually be used for colour transparencies, and often also gives the best results for scans from reflection colour prints. For digital camera images you should try both Perceptual and Relative (WITH 'BPC'). Not recommended for use in 'hard' proofing.

But if you state that the colour values that are internally used might change than that means you can change to a wider gamut. It's not a "one-way"operation only where this discussion started with.






https://en.wikipedia.org/wiki/Raster_image_processor

Look at the examples given in that link. It's meant to convert non-graphic to graphic so it can be used by "windows printers". PCL is translated as Page Control Language, but I know it as Printer Command Language or Printer Control Language.

No, what I have shown are raw conversions to each of the three colour spaces and the OOG colours in each. I have not done any conversions from one colour space to another.



That is exactly what I did in the first image and the fourth image:

This is what the SOOC JPEG looks like:




This is the ProPhoto colour space image generated from the raw data in Adobe Camera Raw:




The dress and balloons are more accurate from the ProPhoto data. They did not have the yellow / orange colours seen in the SOOC JPEG.

I think I know what you tried to show us: showing the out of gamut ANALOGUE colors when converting to a smaller color space.
Back to the question of Marianne, if we have a sRGB image, can we convert that to Adobe RGB. Can we open a jpeg and convert that to a wider color space. I still think it's only a matter of changing the pixel values.

This does bring up another question. What is the color space of the sensor?

George

[Manfred M]

They should look always the same, well nearly. That's due to the rendering intent. In your example perceptual.

Actually no, I used relative colormetric rendering intents for these examples. I strongly suspect that Nikon uses perceptual as we see a strong colour shift, and that is how that rendering intent works.

All implementations of relative colormetric should give the same result as all they do is assign the values of out of gamut colurs. Perceptual reassigns ALL colours, so colour shifts do occur. These are usually not as severe as shown in my example

But if you state that the colour values that are internally used might change than that means you can change to a wider gamut. It's not a "one-way"operation only where this discussion started with.

I'm not sure if you understand what I have been saying George. If one takes an image with out of gamut colours and downsamples to a narrower colour space, the out of gamut colours will be remapped to new values that exist within the new colour space. It is possible to tell the software to reconvert back to the wider colour space, but the colours that have changed will be the ones that fit in the narrower colour space, so there is generally no benefit to using the wider colour space. Conversions go one way only; once a rendering intent has been applied, the old colour data is permanently changed.

Let me try to explain this with a different analogy. If I have a thermometer outside of my house that takes temperature readings. I then transfer that temperature data to a graph. Let's assume that the chart runs from 0 °C to 30 °C. Even if my thermometer reads from -40 °C to 40 °C, the lowest value I can record on my graph is 0 °C and the highest is 30 °C, even if the actual temperature readings are different. This is effectively how the relative colormetric rendering intent works; any value outside the range is assigned the maximum or minimum permissible value.

If some time in the future, I decide to use a new chart that goes from -20 °C to 40 °C and I want to take my old readings and copy them to this new chart. All the values I record will still be from 0 °C to 30 °C, even though my chart hand handle more values. This is effectively what happens if I take a narrower colour space and convert it to a higher one; I may have room for more data, but the data I have recorded is still only going to be what I had on my original chart.

Look at the examples given in that link. It's meant to convert non-graphic to graphic so it can be used by "windows printers". PCL is translated as Page Control Language, but I know it as Printer Command Language or Printer Control Language.

Again, I think you are missing the point. Post-Script and PCL are instructions to the printer to tell it what to do. Feed a new page, put a dot here, etc. That is still required, but what is missing is the DATA. A printer needs both to create output.

What the RIP does is turn image data from the editor to bitmap data for the printer to print. It also applies a rendering intent and printer / paper profile data to ensure that the colours are correct

I think I know what you tried to show us: showing the out of gamut ANALOGUE colors when converting to a smaller color space.

Yes and a bit more. What I tried to show is that in a wider gamut colour space there are fewer out of gamut colours than in the narrower one. The whole purpose of soft proofing is to identify the colours that cannot be managed in each specific colour space so that the user can make a decision on how to handle the colour rendering issues.

Back to the question of Marianne, if we have a sRGB image, can we convert that to Adobe RGB. Can we open a jpeg and convert that to a wider color space. I still think it's only a matter of changing the pixel values.

Yes, it can be done, but why would one as there is no advantage to doing so. That is the point I made to Marianne

This does bring up another question. What is the color space of the sensor?

I don't understand what you are asking. A sensor cannot have a colour space.

[george013]

I don't know where Nikon is getting involved, except with CaptureNx or ViewNx.
But if you compare a out of the camera jpg with a same image but converted with PS, then you're comparing 2 different raw converters and probably 2 different images. But that's another story.

All implementations of relative colormetric should give the same result as all they do is assign the values of out of gamut colurs. Perceptual reassigns ALL colours, so colour shifts do occur. These are usually not as severe as shown in my example

But we're using photo's. And what I've learned and seen in your screenshot post 26 perceptual is used for photo's.

George

[george013]

Of course a sensor has a kind of color space. The channels are sensitive for a range in wavelength for these colors. That must be known, otherwise it's impossible to translate those values to an output device.

George

[Manfred M]

I don't know where Nikon is getting involved, except with CaptureNx or ViewNx.
But if you compare a out of the camera jpg with a same image but converted with PS, then you're comparing 2 different raw converters and probably 2 different images. But that's another story.


But we're using photo's. And what I've learned and seen in your screenshot post 26 perceptual is used for photo's.

George

Those are the default setting for Windows. Once I switch over to the image editor, I get a different set of selections and by default Photoshop uses Relative Colormetric.

[Manfred M]

Of course a sensor has a kind of color space. The channels are sensitive for a range in wavelength for these colors. That must be known, otherwise it's impossible to translate those values to an output device.

George

No - an image sensor is just that, a sensor and there is NO colour space involved. Colour space assignment does not happen until the raw converter stage. Testing by the converter manufacturer on the individual camera is required before that can occur. While the camera manufacturer will add their camera to the converter that is shipped with the camera (View or Capture with Nikon), that is not true for the other commercial converters.

When I first got the D800 (I had one of the first ones shipped to Canada), I had to use View NX2 as my converter as it took Nikon a few months to add the camera to Camera Raw / Lightroom.

[xpatUSA]

Of course a sensor has a kind of color space.

Agreed, but only a "kind" of color space, George. Anything inside your "horseshoe" is a color; anything outside is not a color because we can't see it.

The channels are sensitive for a range in wavelength for these colors.

And not just "these colors" but also any radiometric energy between about 300 and 1150nm (ignoring CFA's for now). In other words, the bare sensor is sensitive to "pseudo colors" that are way outside of the XYZ triangle.

That must be known, otherwise it's impossible to translate those values to an output device.

Yes, indeed it is both known and it is possible. My cameras use a 3x3 matrix to convert from camera "space" to CIE XYZ true colors:



Since XYZ is the basis for all color spaces it can be converted to any other known space.

[george013]

Those are the default setting for Windows. Once I switch over to the image editor, I get a different set of selections and by default Photoshop uses Relative Colormetric.

I don't know why you made this choice. But for a further discussion it must be clear what your choice is and that the results are only for that choice.

When saying a sensor must have a kind of color space I don't mean an output color space. Just a range in wavelength it's sensitive for the r,g and b colors. And I know there're no composed colors.

I see Ted has posted. He is more in the figures, I try to keep it global.

I do believe it's possible to change color space from sRGB to Adobe RGB or others. There's is a relation between there digital values. Another question would be the why? If one wants to work on a photo so precisely why start with an 8 bit compressed jpg?

George

[xpatUSA]

So here I am in ProPhoto and I've colored my red flower to some gloriously saturated red, say 240,30,10 RGB. That's a real color of XYZ = 0.723, 0.275, 0.00243. Try to show that real color in sRGB and Bruce Lindbloom's CIE calculator tells me sRGB = 338, -119, -30. Pretty hard to show on any device, eh?

Judging from comments here, that may have gone over some people's heads. See the calculator here:

http://www.brucelindbloom.com/index....alculator.html

Any numbers in any color space can be converted to any other space including the white point (real reference whites, not histogram white levels).

Please recall that the XYZ space is used as the Profile Connection Space (PCS) used in most embedded Profiles, so XYZ should not really be unfamiliar to the cognoscenti here.

In a similar vein, one can enter a real XYZ or xyY color and get RGB values in any other space that you like. That means that I can show numbers for illustration as opposed to shooting a Real World scene but causing confusion by so doing.

Numbers work and can not be argued with. :|

[DanK]

But if you state that the colour values that are internally used might change than that means you can change to a wider gamut. It's not a "one-way"operation only where this discussion started with.

yes and no. It's important to distinguish between the numbers and the information.

If the conversion to a smaller space is a function--say, a compression of the space--it is reversible. The function can be inverted, and you end up exactly where you started. Same numbers, same data, same colors.

If the conversion to a smaller space is not a function and entails mapping more than one value from the larger space onto a single value in the smaller space--e.g., censoring, like relative colorimetric rendering--, then data are lost, and it cannot be recovered. One can label it with numbers from the larger color space, but one can't recover the data that was lost in collapsing two or more values into one.

Within a parametric editor (sorry George, but I think everyone else knows what I mean by this), the conversion to a smaller space should be reversible regardless of the algorithm, as one can simply delete that step in the set of mathematical instructions. The raw data are still there, unchanged. However, when one creates a jpeg, the data are NOT there any more. The mapped data have been burned into the new file, and that file does not contain the information needed to recover the larger space. You could devise a transformation that would map pixels from the smaller to the larger space, but doing so would map all of the pixels that are at that color value, including the ones that should be within the smaller space.

This is one reason why students in beginning stat courses are warned to avoid categorizing continuous variables. Doing so maps many values to one, and all of that information is then gone. There are ways of trying to estimate what the underlying, now latent continuous distribution was, but that's another matter entirely.

So yes, you can rescale to the larger color space internally, but you can't recover the data that have been lost.