Question on the use of wide-gamut monitors

[DanK]

In response to a question raised on another forum, I found this advice about photo editing in the NEC Spectraview User's Guide:

Typically if a color managed application is being used, then the Native (Full) color gamut should be used since this will allow the application to make full use of the color capabilities of the display. This applies even if the image, document, etc. is intended for another color gamut such as sRGB or AdobeRGB. The color gamut should not normally be set to that of the color workspace of the application, if it is color managed. Likewise the color workspace should not normally be set to the color gamut of the display.

For non-color managed applications a specific color gamut such as sRGB can be selected to make the display appear as if it has such a color gamut. In this case, all of the necessary color conversions are done automatically within the display.

In another section, they specifically reference doing this when working in Photoshop.

This makes no sense to me.

While I understand the principle of retaining as much color information as one has, I can't see the value of editing in a color space that is wider than the output device can display, as that could give you a misleading representation of the colors that will be produced in the end. So I have been editing in Adobe RGB when I intend to print and sRGB when I intend to display on the web. (Spectraview's Native gamut is larger than Adobe RGB, and while I haven't used it much, I did play with it one time before printing, and my reaction was that I got better results with Adobe RGB. I have to go back to that question again. However, the question I have doesn't depend on that; it is whether it makes sense to edit in a wider gamut than the output display can handle.

Along similar lines, no one I know leaves their software unmapped so that the output devices display that without conversion to a smaller gamut. I have one piece of software that does that, and I can't evaluate color in it at all.

Any thoughts?

Thanks

Dan

[pschlute]

Dan

This is not my area of expertise at all, and indeed I have asked the same questions myself in the past.

What I have concluded from replies on here is that editing (including downsizing) in the widest possible colour space means that you have less unwanted artefacts in your image. So process the raw file from your camera in the widest profile that your camera/software will allow (profoto ?) Only after you have done your edits, convert the profile to what is required by your utput medium.

Prepared to be corrected by those who know a lot more about this than me

[DanK]

It's definitely best not to reduce the color information, that is, to work in the largest possible color space. However, this is a question about how to display that as you work on it. Here's a question about it that I posted for Andrew Rodney, a color expert, who also said there is usually no reason to calibrate to a smaller color space:

Suppose one is editing a photo that contains substantial colors that lie outside the sRGB gamut, and one intends to display on the web or send a JPEG to a lab that asks for sRGB. And you calibrate the monitor for the largest gamut it can provide. Won't one then see those colors that lie outside the sRGB gamut differently on your monitor than they will appear in an sRGB output? For example, you might have a color that is outside the sRGB gamut that would compel you to choose between relative and perceptual rendering, while on your monitor, nothing will seem out of gamut at all.

[DanK]

Andrew Rodney's answer was to edit in the widest possible space and use softproofing at the end to make adjustments for smaller gamuts like sRGB.

[Manfred M]

Dan

This is not my area of expertise at all, and indeed I have asked the same questions myself in the past.

What I have concluded from replies on here is that editing (including downsizing) in the widest possible colour space means that you have less unwanted artefacts in your image. So process the raw file from your camera in the widest profile that your camera/software will allow (profoto ?) Only after you have done your edits, convert the profile to what is required by your utput medium.

Prepared to be corrected by those who know a lot more about this than me

Peter - I wish it were that easy and there are many different opinions out there (and many of them based in incorrect premises).

1. If you are only going to post on the internet, then I would suggest that one should have an sRGB compliant screen using 16-bit AdobeRGB as the default workspace.

2. If you are planning to print a fair amount yourself using a "pro" photo ink jet printer, then an Adobe RGB compatible screen and one of the wider colour spaces would make sense. Using Lightroom, my default workspace would be ProPhoto RGB and out of Adobe Camera RAW using L* a* b* is a viable option, as well as one of the other wide gamut colour spaces like ProPhoto RGB or Adobe RGB.

The main reason is that these printers, especially on a coated paper (lustre, Baryta, etc.) will capable of outputting a wider colour envelope than Adobe RGB. One might not be able to tell when looking at a screen (even an Adobe RGB compliant screen), but vivid colours will print properly.

On the other hand, if one sends work out to most commercial printers, they will use chromogenic printers because they are much less expensive to run than the ink jets and they are limited to the sRGB colour space and most shops want 8-bit data. The same story appears to be true for digital presses (like Blurb books); again sRGB only. Custom inkjet print shops can handle the wider colour spaces, just like doing the printing one one's own "pro" photo inkjet printer, but they tend to be a costly alternative.

The other issue with the wider colour spaces is related to the difference in hue between two values. We have the same number of integer values to represent a much larger number of values, which means the "gap" between two discrete colour values is larger in the wider colour spaces. We see this when we edit in 8-bit data and the edits give us banding and other artifacts if we push the colours "to hard". I have experienced the same type of issue when working in both ProPhoto RGB and in L* a* b* colour spaces (very occasionally). Stepping back to a point before the problem occurred and converting to a narrower colour space worked in those instances.

Another way to look at things is to remember that a wider gamut colour space is not going to be of much use if the colours in your image do not require a winder colour space.

When it comes to an Adobe RGB screen and working in sRGB, I have never found an issue in what my sRGB image looks like on the wider gamut screen. For all intents and purposes, the sRGB colour space nests inside the Adobe RGB colour space and when doing a conversion, the sRGB image looks just fine on my Adobe RGB screen. Just for fun, I run a dual-monitor setup; one screen is Adobe RGB (my main working screen) and the other sRGB (where I put all my menus), so I can look at an image on screens with these colour spaces, so I'm fairly comfortable in my statements.

[DanK]

The other issue with the wider colour spaces is related to the difference in hue between two values.

Yes, that and the issue of out of gamut colors is why I had been using an sRGB target to edit for the web. But Andrew Rodney's suggestion of using soft proofing for that purpose might suffice.

My NEC's native gamut is larger than Adobe RGB, so I think I should do another calibration with that as a target for editing for printing. It came with a factory calibration for the native gamut, but as you pointed out some time ago, one should calibrate oneself, in the context in which you are using it.

[Manfred M]

Yes, that and the issue of out of gamut colors is why I had been using an sRGB target to edit for the web. But Andrew Rodney's suggestion of using soft proofing for that purpose might suffice.

My NEC's native gamut is larger than Adobe RGB, so I think I should do another calibration with that as a target for editing for printing. It came with a factory calibration for the native gamut, but as you pointed out some time ago, one should calibrate oneself, in the context in which you are using it.

I've actually never found that to be an issue. All of the RGB colour models are tri-stimulus models and mapping the values (outside of the whole issue of handling out-of-gamut (OOG)), provides a simple one-to-one relationship for the most part.

Things get a bit tricky with handling OOG colours. With the relative colorimetric rendering intent, I've never had an issue with colour shift and all the colour outside the "hull" of the wider colour space are mapped to values on the "hull". The perceptual rendering intent does create colour shifts as it redistributes the OOG colours, so I only look at it when printing, not for colour space conversions.

The only colour space that really messes up is when going to CMYK, where multiple mappings can occur, depending on the rules of how cyan (which is an "inefficient" colour in printing are we require about 30% more than M and Y) as well as the way to distribute the K values. I understand the mapping of sRGB and Adobe RGB are reasonably good, but ProPhoto RGB (and I suspect L* a* b*) can give strange results. This is of current interest as I have been asked to deliver some image that will be printed on an offset press and I haven't done any of that in almost 2 years, so I'm just a touch rusty.

[xpatUSA]

... I understand the mapping of sRGB and Adobe RGB are reasonably good, but ProPhoto RGB (and I suspect L* a* b*) can give strange results ...

Manfred, I'm wondering why L* a* b* got slipped in there because a) it is not a tri-stimulus space and b) it is one of the commonly-used Profile Connection Spaces which as we know are device-independent, as in they are good for any output device, including printers.

[Manfred M]

Manfred, I'm wondering why L* a* b* got slipped in there because a) it is not a tri-stimulus space and b) it is one of the commonly-used Profile Connection Spaces which as we know are device-independent, as in they are good for any output device, including printers.

Sorry that I wasn't clear enough. I was referring to ProPhoto RGB and L* a* b* to CMYK only.

A number of sources who have worked in preparing photographs for offset printing have told me that the ProPhoto to CYMK is problematic. Because L* a* b* is not commonly used in preparing work for offset press print work, there is a likelihood that the same wide-gamut to narrow gamut mapping issues could found there too.

I was recently asked to prepare some images for a offset press work so I have been reviewing some the conversions from the RGB colour spaces to CYMK. My usual workflows use either ProPhoto RGB or L* a* b*, hence the current interest.