New article on color management

Started Apr 26, 2013 | Discussions thread
crames Regular Member • Posts: 192
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

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 :: ( ) @ 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.

But, as the old saying goes, "suit yourself."


Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow