Color gamut of an Epson 3880

[BobShaw]

If you have a Mac then open the Colorsync utility and you can display each profile (AdobeRGB, printer profiles etc) and twirl them around to see them from every angle.

I don't get what you mean by "The question is are they clipped to the edge of the Epson 3880 color space (relative colorimetric) or are they scaled to some relative color within the Epson space (perceptual)". Unless I am missing something that firstly depends on whether you select relative  or perceptual in the rendering intent. Relative calorimetric means that only the out of gamut colours are scaled. Perceptual means that ALL colours are scaled.

[Mark D Segal]

Although the out--of-gamut mapping in both Lr and Ps isn't that accurate, ...........There is nothing set in stone about artistic choice.

Brian A

Yes, I agree - it's a matter of taste and what in the photographer's vision best suits the photo.

However, I don't understand what you mean by the statement that the gamut mapping in LR/PS "isn't that accurate". How would you define "accurate gamut mapping" and how do you know relative to such standard that these applications are performing inaccurately?

[GWGill]

However, I don't understand what you mean by the statement that the gamut mapping in LR/PS "isn't that accurate".

Note that accurate gamut mapping must take into account the gamut of the input. (sounds obvious, but...)
By the very way that most ICC profiles are built, this can't be the case, since the profiling software has no mechanism to be told what the input gamut is going to be - the profiling software will assume some generic source gamut and/or generic gamut mapping, which won't be tailored to the gamut you actually have.

The process of achieving accurate gamut mapping in large gamut spaces has problems too - unlike smaller spaces such as sRGB or AdobeRGB, you can't just assume that the colorspace gamut is representative of the gamut you value in the image.

Accurate gamut mapping is achievable, but the workflow and tools have to be a little different...

[digitaldog]

However, I don't understand what you mean by the statement that the gamut mapping in LR/PS "isn't that accurate". How would you define "accurate gamut mapping" and how do you know relative to such standard that these applications are performing inaccurately?

It shows you an overlay for colors that are not OOG! I'd call that inaccurate Mark!
It's also unnecessary and useless in the form it's provided on top of being inaccurate.
How is blocking your image with an ugly overlay any better than viewing the effect of the soft proof and various rendering intents?
How is blocking your image with an ugly overlay that treats all OOG colors the same useful, what are you supposed to do now? Manually make them disappear? Bad idea.
OOG in Adobe products was fine before 1998 and ICC color management in Photoshop. It's not today.

[hjulenissen]

Note that accurate gamut mapping must take into account the gamut of the input. (sounds obvious, but...)
By the very way that most ICC profiles are built, this can't be the case, since the profiling software has no mechanism to be told what the input gamut is going to be - the profiling software will assume some generic source gamut and/or generic gamut mapping, which won't be tailored to the gamut you actually have.

Sounds reasonable

The process of achieving accurate gamut mapping in large gamut spaces has problems too - unlike smaller spaces such as sRGB or AdobeRGB, you can't just assume that the colorspace gamut is representative of the gamut you value in the image.

Not sure that I am getting this. If (e.g.) pro photo RGB is a superset of all practical input/output devices, and at the same time the numerical representation is such that quantization is no problem, then representing an image in that format together with output device profile ought to give the rendering application the (best available) knowledge about:
1) The color of the scene
2) The color abilities of an output device

What can be achieved by telling the output module about the gamut limits of the acquisition device? So I know that rgb[258,257,256] may in fact correspond to any value in an out-of-gamut volume that has been clipped. If the clipped number is the closest mapping, it still seems to make sense to use that value (outside of speculative gamut recovery)?

Accurate gamut mapping is achievable, but the workflow and tools have to be a little different...

Me think that "accurate" color is asymptotically hard/expensive to achieve and seldom 100% anyways. So for many of us (non-museum archivists) it may be a matter of getting "close enough" while having the resources to do the things that we set out to do in the first place.

-h

[Mark D Segal]

It shows you an overlay for colors that are not OOG! I'd call that inaccurate Mark!
It's also unnecessary and useless in the form it's provided on top of being inaccurate.
How is blocking your image with an ugly overlay any better than viewing the effect of the soft proof and various rendering intents?
How is blocking your image with an ugly overlay that treats all OOG colors the same useful, what are you supposed to do now? Manually make them disappear? Bad idea.
OOG in Adobe products was fine before 1998 and ICC color management in Photoshop. It's not today.

When I read Brian's statement I thought he was making a more general mathematical observation and not so much a judgment on the usefulness of the IG/OOG toggle in Photoshop, which does have the limitations you mention here. BTW, however, despite its limitations it's not useless for making comparisons between profiles reflecting different paper/printer combinations - it can be comparatively indicative - helpful to visualizing differences. But that kind of stuff I think is not what Brian's statement is all about - let us await his clarification.

[digitaldog]

BTW, however, despite its limitations it's not useless for making comparisons between profiles reflecting different paper/printer combinations - it can be comparatively indicative - helpful to visualizing differences.

I have much better software tools to do that. ColorThink Pro for one.

The function is supposed to be useful for image editing, it isn't.

[Mark D Segal]

Yes I also have ColorThink Pro and think it is excellent for what it does - essentially profile analysis. If you want to see the impact of relative gamut limitations on real photographs, this is not the tool for that. And I agree, I would not use Photoshop's gamut overlay tool for photo editing. The softproofing one however is very useful.

[digitaldog]

Yes I also have ColorThink Pro and think it is excellent for what it does - essentially profile analysis. If you want to see the impact of relative gamut limitations on real photographs, this is not the tool for that.

I disagree. One can sample down images and plot them in 3D within CT Pro. One can build color lists from that data. It's far more useful to understand the image gamut compared to any other gamut than anything in Photoshop.

[Mark D Segal]

Ah - OK - are you referring to the Color Worksheet tool? Normally I haven't been using this application for that functionality, but what you are saying looks attractive for exacting work.

[hugowolf]

Yes, I agree - it's a matter of taste and what in the photographer's vision best suits the photo.

However, I don't understand what you mean by the statement that the gamut mapping in LR/PS "isn't that accurate". How would you define "accurate gamut mapping" and how do you know relative to such standard that these applications are performing inaccurately?

I have had images that when exported from Lightroom in one space, and then soft proofed using that space profile, have shown out-of-gamut colors. Something not quite right there.

Brian A

[Mark D Segal]

I have had images that when exported from Lightroom in one space, and then soft proofed using that space profile, have shown out-of-gamut colors. Something not quite right there.

Brian A

Strange, I have not come across that problem - not saying it can't happen, but are you quite certain that before the file left LR all the colours (not only the luminance) were in-gamut for the embedded profile?

[hugowolf]

Strange, I have not come across that problem - not saying it can't happen, but are you quite certain that before the file left LR all the colours (not only the luminance) were in-gamut for the embedded profile?

I haven't tried it in a while, but export from edited raw to sRGB jpeg. Then viewed the jpeg in Lr and the soft proof showed out-of-gamut colors using the sRGB profile.

Brian A

[Mark D Segal]

I haven't tried it in a while, but export from edited raw to sRGB jpeg. Then viewed the jpeg in Lr and the soft proof showed out-of-gamut colors using the sRGB profile.

Brian A

Assuming when you edited the raw file to the sRGB color space before exporting LR was not showing any OOG colour, I'm wondering whether this happened because of JPEG compression.

[GWGill]

If (e.g.) pro photo RGB is a superset of all practical input/output devices, and at the same time the numerical representation is such that quantization is no problem, then representing an image in that format together with output device profile ought to give the rendering application the (best available) knowledge about:
1) The color of the scene
2) The color abilities of an output device

Right, but if the rendering to the printer gamut takes proPhoto as the source gamut, then the output will very likely not be pleasing, since you are squashing the very large gamut down to the printer gamut, taking your image with it.

If the profile has a very generic gamut mapping then this problem is avoided, but you also don't get to keep anything outside that generic gamut mapping, rather reducing the benefits of having your images stored in a large gamut space.

Of course you can manually reduce the gamut of your image into the printer space using an image editing package, and use relative colorimetric when printing it, but that's going to require a good deal more effort for each and every image.

What can be achieved by telling the output module about the gamut limits of the acquisition device?

I don't know - why would you want to do that ?

So I know that rgb[258,257,256] may in fact correspond to any value in an out-of-gamut volume that has been clipped. If the clipped number is the closest mapping, it still seems to make sense to use that value (outside of speculative gamut recovery)?

Sorry, I'm not following you. While technically clipping is a form of gamut mapping, gamut mapping is typically of interest when applied to achieving perceptually pleasing results, by compressing the gamut so as to trade absolute color accuracy in return for maintaining the distinction between different colors in the original image.

Me think that "accurate" color is asymptotically hard/expensive to achieve and seldom 100% anyways.

The original comment was about accurate gamut mapping, not accurate color reproduction.
Loss of accuracy can occur and many stages. One of them is in the maths/code used to implement gamut mapping, but also in the workflow chosen in making use of gamut mapping.

[GWGill]

I have had images that when exported from Lightroom in one space, and then soft proofed using that space profile, have shown out-of-gamut colors. Something not quite right there.

That's nothing to do with gamut mapping though. Seems more to do with the out of gamut warning calculations, since (by definition) an image stored in a particular device space can't be outside that device space.

[digitaldog]

That's nothing to do with gamut mapping though. Seems more to do with the out of gamut warning calculations, since (by definition) an image stored in a particular device space can't be outside that device space.

Exactly!

[hjulenissen]

Right, but if the rendering to the printer gamut takes proPhoto as the source gamut, then the output will very likely not be pleasing, since you are squashing the very large gamut down to the printer gamut, taking your image with it.

Is that not what I am doing in Lightroom, working in proPhoto, softproofing using a measured profile of my 3880/paper combo, tweaking until I am pleased, then pressing "print"?

If the profile has a very generic gamut mapping then this problem is avoided, but you also don't get to keep anything outside that generic gamut mapping, rather reducing the benefits of having your images stored in a large gamut space.

Of course you can manually reduce the gamut of your image into the printer space using an image editing package, and use relative colorimetric when printing it, but that's going to require a good deal more effort for each and every image.

I don't know - why would you want to do that ?

I believe that I was referring to your statement: "Note that accurate gamut mapping must take into account the gamut of the input. ". This appears to mean that input gamut has to be considered. I can't understand why that is a requirement if (rather) one can represent the image using a "super-gamut" (proPhoto?), then map that gamut to any desired output gamut?

Sorry, I'm not following you. While technically clipping is a form of gamut mapping, gamut mapping is typically of interest when applied to achieving perceptually pleasing results, by compressing the gamut so as to trade absolute color accuracy in return for maintaining the distinction between different colors in the original image.

Lightroom offers the "perceptual" vs "relative" intent. I was under the impression that these were automated "soft clipping" vs "hard clipping" of gamut, while soft-proofing allowed me to manually navigate within those limits.

I think that it is strange that (apparently) color choices are made by my paper (profile) supplier, my display calibrator/profiler software and my camera profile software. Would it not make more sense for all of these to rather provide objective/passive information about the devices capabilities, then (e.g.) Adobe could hire one more color scientist or two doing optimal mappings (with or without manual intervention), as the raw image editor is the hub that has access to most information and the natural place to ask the user about preferences?

-h

[GWGill]

Is that not what I am doing in Lightroom, working in proPhoto, softproofing using a measured profile of my 3880/paper combo, tweaking until I am pleased, then pressing "print"?

Probably not - because you haven't mentioned creating a device link or ICC profile with a gamut mapping tailored specifically to your source space or images. I'd guess you are using the generic gamut mapping created by whatever software created the ICC profiles you are using.

I believe that I was referring to your statement: "Note that accurate gamut mapping must take into account the gamut of the input. ". This appears to mean that input gamut has to be considered. I can't understand why that is a requirement if (rather) one can represent the image using a "super-gamut" (proPhoto?), then map that gamut to any desired output gamut?

It's a requirement from the definition of (real) gamut mapping - mapping one gamut into another. That implies two gamuts, a source and a destination, if the mapping is going to be accurate in this task. As I was alluding to, while you can get away with assuming your images completely fill a smaller gamut space like sRGB or AdobeRGB, assuming this with a large gamut space (like ProPhoto, scRGB, L*a*b* etc.) will give extreme compression, and it probably won't look very good if mapped to your printer space.

I think that it is strange that (apparently) color choices are made by my paper (profile) supplier, my display calibrator/profiler software and my camera profile software. Would it not make more sense for all of these to rather provide objective/passive information about the devices capabilities, then (e.g.) Adobe could hire one more color scientist or two doing optimal mappings (with or without manual intervention), as the raw image editor is the hub that has access to most information and the natural place to ask the user about preferences?

Makes sense to me. But that's not how things have evolved. Under the pressure of people demanding that "it just work", everyone in the chain has tried to make things look "really nice" without needing to judge or adjust or choose anything.

I generally roll my eyes when I come across yet another technical article about how to identify and then automatically tweak "key memory colors" like sky, grass, skin etc. in images to make the result "more pleasing". But then this sort of tweaking has gone on forever - none of the photographic processes reproduced color faithfully, they all tweaked it (using chemical "algorithms") to enhance saturation, contrast etc. etc. so that people liked what they saw, and make it better corresponded to what they remembered. Much of the digital workflow has emulated all that.

[hugowolf]

That's nothing to do with gamut mapping though. Seems more to do with the out of gamut warning calculations, since (by definition) an image stored in a particular device space can't be outside that device space.

Well call it a calculation/function/mapping/transformation, my point was that the out-of-gamut warning wasn't always accurate. But I still find it useful for comparing profiles before printing.

Brian A