Great Bustard wrote: What I'm wondering is if 16 bits representing a less expansive colorspace might not have advantages, on occasion, over 16 bits representing a larger colorspace, due to the finer gradations of the smaller colorspace.

You mean which color space makes better use of the available bits with histograms such as these (sRGB to the left, ProPhoto to the right)?

As far as I know, any issues that ProPhoto had with posterization went away when PS switched to 16 bits, so I would guess that if there is an advantage to the higher color resolution of the smaller space it is not noticeable in practice.

I'm not sure what you're talking about here, Cliff. If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen. If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

I'm not sure what you're talking about here, Cliff. If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen. If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

I'm not sure what you're talking about here, Cliff. If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen. If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments. Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space. It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting, or even skip ACR completely, for example when editing a film scan. In such cases the potential white balance issue is another "reason" to avoid sRGB .

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

Thanks, xpatUSA. Yes, those are the choices for an output space. So it would appear that XYZ is a possible output space, but it is not employed as a matter of course during processing, which is what I'd figure. It's like RPP allows LAB as a choice for an output space, but it doesn't figure in any of the basic rendering operations.

My mistake. As I understand color theory, XYZ is a color model and, as you probably know, color spaces are contained within a color model. XYZ itself is, as it were, dimensionless - often normalized to 1,1,1 for example. What Coffin does (at least with my X3F's) is transform the 3-channel raw data into 16-bit XYZ numbers, i.e. 1 = 65,553. Theoretically, he should do this internally anyway, irrespective of the output space but he's not forced to do so and I don't know if he does. When displayed on the monitor, his XYZ images come out very unsaturated as one expect. One of Coffin's profiles is ProPhoto linear gamma, so I suspect that he may use Kodak RIMM/ROMM as the working area. ArvoJ probably knows more about that than I.

Similarly, CIELAB is also a color model, not a space, so I'm not sure how it could be chosen as an output space although it is most certainly a PCS for some profiles.

I'm not sure what you're talking about here, Cliff. If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen. If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments. Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

The linearized ProPhoto RGB is ACR's internal working space, but, if you've chosen sRGB, or Adobe RGB, or ProPhoto RGB (non-linearized) as your "working" space, what you see on your monitor and the corresponding histograms are the version as rendered in that space.

Eric Chan :: ( http://www.luminous-landscape.com/forum/index.php?topic=60179.msg485409#msg485409 ) @ December 12, 2011 :The internal working space of ACR and LR is Referred Input Medium Metric (RIMM), which has ProPhoto RGB primaries with linear gamma. Temporary excursions are made to other color spaces and image decompositions, as needed, to suit the image processing.In ACR, there are additional options to set the desired output color space (which is used to drive the histogram and on-screen preview image).

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space.

As I said before, there will be equal or worse problems in converting at the end after using a broader space. This is not to say it's a bad idea to do so, but it is to say that your critique of moving directly to sRGB on this account is misplaced.

It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting

Of course. This is true simply as a matter of fact and not finessed by any other method. What's nice is that, with recent versions of ACR, it is possible to apply selective WB.

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

You're a better man than I. I've done just what you advocate -- did it for years. I processed in ProPhoto RGB as a matter of course and ended up with beautiful images on my wide-gamut monitor. Then when I went to "selectively desaturate" the OOG colors in soft proofing to reduce the space for printing or for the web, the degree of selective desaturation that was required to undo all the beauty that ProPhoto RGB created resulted in "selective colors" that were dull as dirty dishwater -- downright unpleasant.

I was better off in these cases simply printing from the ProPhoto RGB space using the printer's profile without any adjustments. The OOG colors were considerably less vibrant than on screen, but they were a heck of a lot better than the "controlled" adjustments of which you speak. Better yet were the same images processed in Adobe RGB, which more nearly matches my Pixma Pro 9000 II's gamut. Not much worse were those processed in sRGB. As to web-destined images, the same holds, except that Adobe RGB is not as useful.

So, I know what you're saying: it is, and has been, a common mantra. But, in my experience, it is not borne out in fact.

I'm not sure what you're talking about here, Cliff. If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen. If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments. Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

The linearized ProPhoto RGB is ACR's internal working space, but, if you've chosen sRGB, or Adobe RGB, or ProPhoto RGB (non-linearized) as your "working" space, what you see on your monitor and the corresponding histograms are the version as rendered in that space.

Eric Chan :: ( http://www.luminous-landscape.com/forum/index.php?topic=60179.msg485409#msg485409 ) @ December 12, 2011 :The internal working space of ACR and LR is Referred Input Medium Metric (RIMM), which has ProPhoto RGB primaries with linear gamma. Temporary excursions are made to other color spaces and image decompositions, as needed, to suit the image processing.In ACR, there are additional options to set the desired output color space (which is used to drive the histogram and on-screen preview image).

Clearly confirming what I said, and Eric said further down in that same message, "These color conversions are done at the end of the image processing pipeline, after the UI-driven controls (e.g., Exposure) are done."

That there is a convenient preview of the output does change the fact that the image processing is done in the internal space(s) and not in the output space.

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space.

As I said before, there will be equal or worse problems in converting at the end after using a broader space. This is not to say it's a bad idea to do so, but it is to say that your critique of moving directly to sRGB on this account is misplaced.

I guess this is where we disagree. I think it is worse to introduce hue shifts to an image that already suffers from out-of-gamut issues.

It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting

Of course. This is true simply as a matter of fact and not finessed by any other method. What's nice is that, with recent versions of ACR, it is possible to apply selective WB.

So there are reasonable scenarios besides the presumably unreasonable jpeg white balance one.

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

You're a better man than I. I've done just what you advocate -- did it for years. I processed in ProPhoto RGB as a matter of course and ended up with beautiful images on my wide-gamut monitor. Then when I went to "selectively desaturate" the OOG colors in soft proofing to reduce the space for printing or for the web, the degree of selective desaturation that was required to undo all the beauty that ProPhoto RGB created resulted in "selective colors" that were dull as dirty dishwater -- downright unpleasant.

If it didn't work for you, I can understand your position.

I was better off in these cases simply printing from the ProPhoto RGB space using the printer's profile without any adjustments. The OOG colors were considerably less vibrant than on screen, but they were a heck of a lot better than the "controlled" adjustments of which you speak. Better yet were the same images processed in Adobe RGB, which more nearly matches my Pixma Pro 9000 II's gamut. Not much worse were those processed in sRGB. As to web-destined images, the same holds, except that Adobe RGB is not as useful.

Output to a printer profile with its several available rendering intents is not comparable to output to the sRGB matrix profile.

So, I know what you're saying: it is, and has been, a common mantra. But, in my experience, it is not borne out in fact.

"A common mantra" of some of the experts whose books and articles I have read over the years. It certainly works for me with the tools I use.

Speaking of experts, here is a brief article by Jeff Schewe that shows some of the effects of gamut clipping in sRGB and ProPhoto.

One of the early articles that conviced me to use MelissaD65 as a working color space for years, despite the fact that the visible difference was and remains minimal. Several years later I have two questions in the context of this sub-thread (i.e. Camera-sRGB vs Camera-ProPhoto-sRGB)

1) Can you see a material difference between the two?2) Even if you did, which one would be more 'correct'?

If someone can answer these two questions without bait and switching to answering a different question (is ProPhotoRGB bigger than sRGB?) we may actually take a step further in the discussion. In the meantime this is the file in the article opened in ACR 6.7 sRGB, CEP3 Tonal Contrast applied at default settings (left); and the same file opened in ACR 6.7 ProPhotoRGB, CEP3 TC at default and converted to sRGB (right). I had to actually convert the right file to sRGB after applying TC in order for CS5 gamut warning (gray) to show.

Speaking of experts, here is a brief article by Jeff Schewe that shows some of the effects of gamut clipping in sRGB and ProPhoto.

One of the early articles that conviced me to use MelissaD65 as a working color space for years, despite the fact that the visible difference was and remains minimal. Several years later I have two questions in the context of this sub-thread (i.e. Camera-sRGB vs Camera-ProPhoto-sRGB)

1) Can you see a material difference between the two?2) Even if you did, which one would be more 'correct'?

If you are converting in the usual ways - relative colorimetric intent in PS, standard sRGB and ProPhoto profiles, and without any editing while in ProPhoto to ameliorate gamut clipping, I don't think there will be any visible difference. The correct way under these conditions would be the direct Camera->sRGB, to avoid an extra color space conversion.

Another way to do it is to use the v4 ICC profiles for sRGB and ProPhoto, which contain perceptual intent tables for the purpose of performing a proper gamut mapping to the smaller space. I remember trying them but not getting good results.

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

If someone can answer these two questions without bait and switching to answering a different question (is ProPhotoRGB bigger than sRGB?) we may actually take a step further in the discussion. In the meantime this is the file in the article opened in ACR 6.7 sRGB, CEP3 Tonal Contrast applied at default settings (left); and the same file opened in ACR 6.7 ProPhotoRGB, CEP3 TC at default and converted to sRGB (right). I had to actually convert the right file to sRGB after applying TC in order for CS5 gamut warning (gray) to show.

If you are converting in the usual ways - relative colorimetric intent in PS, standard sRGB and ProPhoto profiles, and without any editing while in ProPhoto to ameliorate gamut clipping, I don't think there will be any visible difference. The correct way under these conditions would be the direct Camera->sRGB, to avoid an extra color space conversion.

Ok

Another way to do it is to use the v4 ICC profiles for sRGB and ProPhoto, which contain perceptual intent tables for the purpose of performing a proper gamut mapping to the smaller space. I remember trying them but not getting good results.

I have a V4 profile for sRGB but not ProPhotoRGB. Is there a problem to mix and match?

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

Very interesting thread. Is it worthwhile to go through the double conversion process? Is anybody using his 'perfect' color space?

Upper left: ProPhoto RGB in ACR to acceptable rendering —> to ProPhoto RGB in CS6, adjustments (curves, selective saturations) made while soft proofing in sRGB with OOG indicator on to remove as much (90%) of OOG as possible (i.e., before it became absurd) —> sRGB.

Upper right: ProPhoto RGB in ACR to acceptable rendering —> make adjustments in ProPhoto RGB to predict conversion to sRGB (i.e., make adjustments, convert to sRGB, check histogram, if ok, fine, if not ok, go back make more adjustments, convert, check histogram, etc., until the conversion is good) —> sRGB.

I should note that the initial raw file here is about 1EV underexposed according to RawDigger. The ACR histogram shows a modest gap at the right when using ProPhoto RGB, and it is stacked hard against the right-hand edge when using sRGB.

I should also note that the bottom two look a great deal more like the original (viewed in ProPhoto RGB in ACR on a wide-gamut monitor). They are no where nearly as bright and vibrant as the original, but, as I say, much more like the original than either of the top two.

As to a choice between the bottom two, each has its value (but there is no question about which is the easier to produce).

I have a V4 profile for sRGB but not ProPhotoRGB. Is there a problem to mix and match?

I'm pretty sure they both should be v4 in order to make use of the perceptual Profile Connection Space. Here are v4 variations on RIMM RGB (ProPhoto's linear cousin).

Some implementation details can be extracted from this:

I haven't really studied this v4 stuff, so I hope I'm not steering you wrong..

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

Very interesting thread. Is it worthwhile to go through the double conversion process? Is anybody using his 'perfect' color space?

I haven't seen anything about it since that thread ended 2 years ago, nor have I used it since testing it back then, only because I seldom need to do those kinds problematic conversions. When I tested it, it did work and preserved hues well. We can try it on golliwop's flower and see how it does.