Wide Gamut Monitor and photo editing question

[pschlute]

First post here on this very informative website - thank you.

I have a wide gamut (99% AdobeRGB) monitor. Say I have an image with some very vibrant greens. I do a RAW conversion using AdobeRGB colour space, and the image viewed on my screen faithfully reproduces those vibrant greens (as long as I am using colour managed software).

Now say i want to post the same picture on the web. I will want to use sRGB colour space for this. Is there any difference between:

1. Converting and editing the RAW file in AdobeRGB colour space, then at the end of the process use Photoshop "convert to profile" (sRGB)

2. Converting and editing the RAW file in sRGB colour space.

From my limited experimentation so far I notice that the vibrancy of the greens is reduced when I "convert to profile" (sRGB). This is obviously due to the narrower sRGB gamut. Intuitively it would appear to me that the best approach would be to to use method 2 so that I can see the final colours all the way through the process. Or am I missing a trick?

Peter

[DanK]

Welcome to CiC. Can you please go to the top right of your screen and edit your profile to include your name and location? We use real names here, and people's locations are often helpful in targeting responses.

I don't yet have a wide-gamut monitor--I am currently shopping for one--but I believe the short answer is "neither." The best way to edit is in the widest possible gamut, which provides more "headroom" for edits--that is, it lessens the chance of artifacts from severe edits. The worst option in that regard is your #2. So even with an sRGB monitor, I always have Photoshop set to edit in ProPhoto. Lightroom gives you no choice, AFAIK. At least, it didn't last I checked. It uses "Melissa" internally, which is a variant of ProPhoto. The software is translating to the color space of your monitor while you are working, so you are should be seeing pretty much what it will produce when it embeds the narrower-gamut color profile at the end. (We generally take this for granted, but there are software packages that don't do this, producing horrible colors on screen because the sRGB monitor can't produce the ProPhoto gamut.) To display on other people's screens, you save (or export) to the color space of the monitors on which people will view it, which means sRGB, since that what most people have.

Printing is another matter. Since printers can print a wider gamut than sRGB, you wouldn't want to be working in SRGB if you print your own. In that case, you soft proof to get the best estimate your monitor can show of what the printer will produce, and if you have everything set up right, the software will map to the gamut of the printer. It gives you options for handling out-of-gamut colors. If you are sending photos to a lab, it's another matter; most ask for files in sRGB, although some will accept Adobe RGB.

Of course, the question is how much this matters. There are people here who do everything in sRGB. Manfred, who is clearly very careful with his work, posted some time ago that he edited in Adobe RGB but was beginning to experiment with ProPhoto.

There are some color experts here who might chime in and correct some of this if they see something off-track.

[Manfred M]

Hi Peter - welcome to CiC. Would you mind hitting the "My Profile" button at the top of this page and entering at least your first name and where you are from into your profile?

There are a lot of different views on this subject out there and a lot of the opinions are "suspect" because people have not thought through what the various work flows actually do to the data and the final image quality. If I were to limit my answer to question you have asked only, then option 1, work in 16-bit AdobeRGB and then convert as a final step into an sRGB file before posting would be better than working in sRGB.

The reason is that when you do a colour space conversion, it is a "one way street"; you are throwing out colour data and once that is done, there is no way to get it back. If you work in AdobeRGB, any out-of-gamut (OOG) colours in the sRGB colour space will be manipulated outside of your final gamut and any artifacts generated by working on these colours will be eliminated during the conversion to sRGB, with the chosen rendering intent taking care of how the OOG colours are handled. If you work in sRGB, then artifacts generated by using the smaller gamut colour space will be part of the final image.

The reason you "see" the less vibrant colours when you convert from AdobeRGB to sRGB is that the latter colour space contains about 50% less colours and this is in fact what one would expect to see; less vibrant colours. When you do the up-front conversion, your eyes never actually see this step of losing the vibrant colours, so your visual system does not register that it is happening, but it does, all the same.

I hope that this makes sense to you and in fact that you might want to change your workflow to not use AdobeRGB at all, but rather use the even wider ProPhotoRGB colour space. The same arguments apply and there is no file size penalty between working in 16-bit ProPhoto RGB and 16-bit AdobeRGB. The upside is that if you ever decide to print an image on a photo inkjet printer (which actually has a wider gamut than your 99% AdobeRGB screen), those vibrant colours will be preserved and show up in the final output. The default workspace that Adode has set for Lightroom is slightly modified ProPhoto colour space, and that is why they have done so.

[Manfred M]

Of course, the question is how much this matters. There are people here who do everything in sRGB. Manfred, who is clearly very careful with his work, posted some time ago that he edited in Adobe RGB but was beginning to experiment with ProPhoto.

I guess I either did not mention it or you missed my posts, but I have been working 100% in ProPhoto for a few years now. The only time that ProPhoto should not be used is when preparing images for offset press printing in CMYK. This is something that very few members are ever likely to do, but here an AdobeRGB to CMYK work flow ends up producing better colours, based on my discussions with some commercial photographers I know that create output for the commercial printing press.

[pschlute]

Thanks very much to both of you for your responses.

Every time I think I have a good grasp on colour managed workflow I quickly realise i havn't !

I understand now the benefit of editing in the widest gamut possible and converting to sRGB at the end , if posting online. Many thanks again.

[george013]

Thanks very much to both of you for your responses.

Every time I think I have a good grasp on colour managed workflow I quickly realise i havn't !

I understand now the benefit of editing in the widest gamut possible and converting to sRGB at the end , if posting online. Many thanks again.

I still don't understand it. If it's a wider gamut sec, the range between the steps is bigger with an equal bitdepth.
And if you want to use a bigger bitdepth, you can use it in sRGB too.



George

[Manfred M]

I still don't understand it. If it's a wider gamut sec, the range between the steps is bigger with an equal bitdepth.
And if you want to use a bigger bitdepth, you can use it in sRGB too. George

Yes you can George, but the difference is the size of the colour space. In a narrower colour space, the distance between two adjacent colours is quite small, so if one uses an 8-bit integer to represent a colour, the difference in the colours of two adjacent colours will be quite similar. If one uses a wide gamut colour space, there will be quite a difference between the actual colours, so the change between two colours will be quite large.

If one does nothing to the image, it will look fine, but the moment one does some editing, one changes the values of the two adjacent colours, the difference can become quite large and quite obvious. This is one of the things we refer to as "artifacts".

By going to a higher bit depth, the steps between two colours becomes much smaller and any incremental changes (as a percentage basis) also are much smaller, so these changes of artifacts will not be visible. One can usually get away with using 8-bit colours in sRGB. It is often okay in AdobeRGB, but is one is working in ProPhoto RGB, these issues become very apparent, especially in large areas with similar colours like the sky.

Each increment in 8-bits means there is a 1/256 change in value. In 16-bit it is 1/65536 change in value. In practice, I don't think we actually need to get to this level of resolution, but as our computers work in 8 or 16 (i.e. 2 x 8) bit increments, we don't have any choice on how this is addressed if we want to work in something greater than 8-bit.

[Polar01]

Peter: I like Manfred use the ProPhoto colour space to work in. I do convert to sRGB profile if posting to web or presenting at our local photo club. There are some colours that just drop out and look @($&% ugly, but there is a fix or work around to help with the problem. Two items that usually drop are Vibrance and Saturation, so the work around is this.

You have just converted to profile (sRGB) and it happens, go to history then step back to before you converted, now go to Image>Duplicate click on Duplicate this will make a copy to the file, so you now have two. Now to the "copy file" do your convert to profile, now you should be able to compare it to the original file. Now using adjustment layers; hue/saturation, vibrance, curves some or all, adjust the copy to get it closer to the original image. Once done save it as the web image.

This was the work around I did as I use to print on a high end printer Epson 4900 with 10 colours, the reason was because what you see on the screen does not always transfer to the paper and as each paper will print differently. I would let Photoshop manage the colours to the printer, so the colour space was always set to ProPhoto.

Cheers: Allan

[george013]

We've been here before. I make a distinction between gamut and bit depth. That are two different items.
That's why I wrote

If it's a wider gamut sec, the range between the steps is bigger with an equal bitdepth.

The color space you're working with must be related to the output device. If your screen shows colors in AdobeRGB then the digital info of your pixels must be corrected for that range. The shown colors must be as realistic as possible, not beautiful.

Peter has an AdobeRGB monitor. Very fine for him, but now he wants to show that picture to the world. And he doesn't know what monitor the others are using. So despite the wide gamut he has he has to bring it back some way to sRGB.
I would say convert the final result to sRGB. Doing the editing again will give different results.

I don't know much about colors. I'm just missing to much logic in all these discussions.

George

[Polar01]

George I do not know if you saw my post #8, where I stated that you need to do a work around, this is not always the case however, it is sometimes when viewed on a monitor. It happens most of the time when printing no matter what the colour space use be it sRGB, AdobeRGB, Prophoto or any other colour space there is. So in some ways it is not the device but the substrate that determines the final look of the finished image. That is why those who print do colour proofs using the proper ICC profiles from the paper manufactures, printer manufactures or make custom profiles ourselves as I did.

Cheers: Allan

[george013]

The posts crossed. Mine was more an answer to Manfred. Now speaking of Peter in the third person looks a bit strange.

The output device is not the printer but the printed paper. I can't see an image on the printer itself. It's obvious that different papers and different ink and different printers will give different results if you don't anticipate on it. Just like monitors

George

[DanK]

The output device is not the printer but the printed paper. I can't see an image on the printer itself. It's obvious that different papers and different ink and different printers will give different results if you don't anticipate on it.

This could get confusing. In English, paper would not be called a "device." Here's one online definition:

a thing made for a particular purpose; an invention or contrivance, especially a mechanical or electrical one.

However, your point is correct: the software has to adjust for both the characteristics of the device--the printer--and the characteristics of the paper. Paper manufacturers provide ICC profiles that are specific to a combination of the particular printer and the output device, and it is that single profile one uses for both soft proofing and printing.

[xpatUSA]

Yes you can George, but the difference is the size of the colour space. In a narrower colour space, the distance between two adjacent colours is quite small, so if one uses an 8-bit integer to represent a colour, the difference in the colours of two adjacent colours will be quite similar. If one uses a wide gamut colour space, there will be quite a difference between the actual colours, so the change between two colours will be quite large.

By going to a higher bit depth, the steps between two colours becomes much smaller and any incremental changes (as a percentage basis) also are much smaller, so these changes of artifacts will not be visible. One can usually get away with using 8-bit colours in sRGB. It is often okay in AdobeRGB, but is one is working in ProPhoto RGB, these issues become very apparent, especially in large areas with similar colours like the sky.

Each increment in 8-bits means there is a 1/256 change in value. In 16-bit it is 1/65536 change in value. In practice, I don't think we actually need to get to this level of resolution, but as our computers work in 8 or 16 (i.e. 2 x 8) bit increments, we don't have any choice on how this is addressed if we want to work in something greater than 8-bit. ***

Would like a bit more clarification, please Manfred. Like George, I'm a bit puzzled.

I guess it's because gamuts are normally expressed in a different color space than RGB, say CIELAB.

For example, in another forum I just converted one 8-bit step in one RGB channel and found that step to be less than the CIELAB 'Just Noticeable Difference' (JND), i.e. 0.7 vs 1.0 CIELAB unit. As you likely know, a JND is a Euclidian distance in a 3D gamut diagram. Some even say that one JND is 2.3 CIELAB units.

Perhaps the differences being discussed here are to do with large-ish round-trip edits in a non-parametric editor and are more noticeable.

*** time for a new computer, Manfred, my cheap 64-bit Dell is working quite happily in 32-bit floating point . . beware the trap, different meanings for "bit"

[pschlute]

very much appreciating all the replies, thank you.

[pschlute]

A further question or two if I may.......

Assume I do RAW conversion to Prophoto colourspace 16 bit, and edit that in Photoshop as a TIFF, adjusting colour/curves etc. I have not yet applied output sharpening.

I want to finish up with a web friendly file (jpeg/sRGB) so I need to :

1. Convert to 8bit (or does this happen automatically when saving as jpeg)
2. Convert to sRGB
3. Resize to a web friendly pixel resolution.
4. Apply output sharpening

Does it matter in what order these tasks are undertaken?

My workflow to date has always been to apply output sharpning (USM) as the last process.

[Manfred M]

A further question or two if I may.......

Assume I do RAW conversion to Prophoto colourspace 16 bit, and edit that in Photoshop as a TIFF, adjusting colour/curves etc. I have not yet applied output sharpening.

I want to finish up with a web friendly file (jpeg/sRGB) so I need to :

1. Convert to 8bit (or does this happen automatically when saving as jpeg)
2. Convert to sRGB
3. Resize to a web friendly pixel resolution.
4. Apply output sharpening

Does it matter in what order these tasks are undertaken?

My workflow to date has always been to apply output sharpning (USM) as the last process.

Yes the order does matter.

1. Resize to web size in the original colour space. Any artifacts that show up due to resizing will be done in the larger colour space. I tend to go with the "standard" Facebook maximum size of 2048 pixels on the long side. When I downsize for photo club entries, I go ensure that the longest width is no wider than 1920 pixels or higher than 1080 pixels, as per club rules.

2. Convert to sRGB. This will result in a 16-bit image in the smaller colour space.

3. Save as jpeg. The 8-bit conversion will occur here.


I generally do not do any output sharpening when posting to the internet; although I do use input sharpening and in-process sharpening. First of all I downsize a 36MP file to a 2MP file, so the image is generally sharp enough. Also I work on a 27" screen, so this is larger than most laptop, tablet, phone and many computer screens, so I have no idea as to what device the image will be displayed on, so it's impossible to optimize. I generally only output sharpen when I print, and given the relatively small amount of sharpening I do here, I'm comfortable in my workflow,

[Manfred M]

George, knowing your love of diagrams, I have created a couple to try to explain visually what I cannot seem to get through to you in words. I have created a fictitious slice of part of a 2-D representation of a couple of colour spaces. The boundaries happen to be straight lines and the colours are what they are. What I am trying to demonstrate is why bit depth matters (more) in a wide gamut colour space when it comes to real life editing issues. Ted, this has nothing to do with all the various colour spaces you brought up in your questions, because it really doesn't matter, and no, it is not a perfect analogy to the real world issue I am trying to describe graphically.

In the first diagram I have created two "colour spaces". The first one is a "narrow gamut colour space" and the area shows a limited range of colours and colour depth. Each of the squares in a 6 x 6 (which represents the bit depth) is more or less a contiguous colour and when I look at it visually each square is more or less the same colour.

When I apply the same 6 x 6 grid to a "wide gamut colour space" to the larger square the squares are no longer a relatively pure colour. This is especially noticeable when we see where the green and red colours start to interplay with each other. This is the real world issue I have been trying to explain; a small bit depth is not granular enough to represent the individual colours in a wide gamut colour space and we run into technical issues when manipulating the data that results in artifacts.






The second diagram shows the same wide gamut "colour space" that I used in the first diagram. The square on the left is identical to the one on the right hand side of the first diagram. The square on the right is identical to the one on the left except that rather than a 6 x 6 grid, I have overlaid a 24 x 24 grid. The right hand grid represents what happens when we increase bit depth and the amount of data we have increases. The colour in each individual grid element is much more consistent than what we see in the 6 x 6 grid. Increasing the bit depth gives us more granularity, which in turn lets us define the colours more precisely. This mirrors what happens in the real world when we use a higher bit depth; we get little to no artifacts when we use a higher bit depth when using a wide gamut colour space.

If bit depth does not matter, think about cutting the 8-bits in half and try to describe all the colours using a 4-bit definition. With 4 bits, we get 2 x 2 x 2 x 2 = 16 bits per channel; or with 3 channels; 16 x 3 = 48 colours. So bit depth does matter...

[pschlute]

Many thanks again Manfred.

[Manfred M]

Would like a bit more clarification, please Manfred. Like George, I'm a bit puzzled.

I guess it's because gamuts are normally expressed in a different color space than RGB, say CIELAB.

For example, in another forum I just converted one 8-bit step in one RGB channel and found that step to be less than the CIELAB 'Just Noticeable Difference' (JND), i.e. 0.7 vs 1.0 CIELAB unit. As you likely know, a JND is a Euclidian distance in a 3D gamut diagram. Some even say that one JND is 2.3 CIELAB units.

Perhaps the differences being discussed here are to do with large-ish round-trip edits in a non-parametric editor and are more noticeable.

*** time for a new computer, Manfred, my cheap 64-bit Dell is working quite happily in 32-bit floating point . . beware the trap, different meanings for "bit"

Ted - the CIE Lab colour space is a very important colour space in terms of effectively defining all the colours that a human can see and the other colour spaces are for the most part a subset of it. It does have a role in editing images and Dan Margulis has written a classic book on how and when one should use it as part of the editing workflow. That being said, it remains a fairly niche use and few people that I know have actually done any work in Lab at all. We did spend an hour or so working with it when I took a colour correction course at the local college. It is definitely a non-intuitive workspace to edit in.

Most mainstream edits are done in sRGB, AdobeRGB, ProPhoto RGB and in the case of work being prepared for offset printing CMYK. For the most part site members generally work in one of the first three in this list, so the other colour spaces are generally of little more than academic interest for most of us.

[xpatUSA]

Ted - the CIE Lab colour space is a very important colour space in terms of effectively defining all the colours that a human can see and the other colour spaces are for the most part a subset of it. It does have a role in editing images and Dan Margulis has written a classic book on how and when one should use it as part of the editing workflow. That being said, it remains a fairly niche use and few people that I know have actually done any work in Lab at all. We did spend an hour or so working with it when I took a colour correction course at the local college. It is definitely a non-intuitive workspace to edit in.

Probably a misunderstanding here, if I understand correctly. I was not recommending CIELAB as a working space to anyone, although my editor does have a good few dumbed-down Lab sliders and an Lab color-picker.

Most mainstream edits are done in sRGB, AdobeRGB, ProPhoto RGB and, in the case of work being prepared for offset printing, CMYK.

Of course.

My converter offers those but certainly not CIELAB.

For the most part, site members generally work in one of the first three in this list, so the other [working] colour spaces are generally of little more than academic interest for most of us.

Indeed, and I including myself in those "site members" and in "most of us". I work in sRGB in the raw converter then export as ProPhoto 16-bit TIFF which is the default RawTherapee working space.

That 'sRGB first, then ProPhoto' probably won't sound right to you. Working in sRGB in the converter lets me see gamut problems before export. It does not have a out-of-gamut warning function. My eyeballs and the color-picker serve that purpose. Case in point:

I shoot a colorful flower. In capture, it's gamut is outside sRGB. If I view and edit in ProPhoto working space, the out of sRGB gamut colors will not be noticeable in the converter. If I export as ProPhoto to RT, they will not be noticed there either. After editing in RT and exporting as sRGB for posting here - suddenly they become visible to my pedantic eye and I get to start over.

For trivial stuff, I'll often export as sRGB 8-bit TIFF to FastStone Viewer.

BTW, thanks for the explanatory diagrams you posted separately for George.

Now I see what you meant to say in the first place, without necessarily agreeing.