[Openicc] meta data in test chart

[Chris Murphy]

On Jan 26, 2011, at 11:12 PM, edmund ronald wrote:

> On Thu, Jan 27, 2011 at 6:14 AM, Graeme Gill <graeme at argyllcms.com> wrote:
>> Chris Murphy wrote:
>>> 
>>> On Jan 25, 2011, at 4:49 PM, Graeme Gill wrote:
> 
>>> be ideal. Yet that's the current workflow. Most photographers who use
>>> ProPhoto RGB are
>>> relatively satisifed by the results they get with existing profiles.
>> 
>> I'd be fascinated to know how they manage that. The few occasions people
>> have brought it to my notice, they had problems with dull looking
>> results until they moved to an image gamut workflow.
> 
> This actually corresponds to my experience: Use ProPhotoRGB as target
> to do your initial Raw conversions with ACR/PS and work in it, print
> directly to inkjet, and your prints will be pretty bad.
> 
> Of course, my workflow was probably wrong, but the whole point of
> workflows seems to be that the user is always wrong.


For what it's worth, the Lightroom imaging pipeline, which is immutable in that it's not user changeable, converts the de-mosaic'd Raw image data from what I will call "camera RGB" space to linear ProPhoto (linear TRC, ProPhoto RGB primaries), with 32bpc floating-point precision. There the image remains through all edits to successfully render the image. Once the user is done rendering the image to their satisfaction, if they use an ICC based printing workflow in the Print module, the conversion is directly from linear ProPhoto to the inkjet's RGB output device profile using the rendering intent of choice, usually relative colorimetric + black point compensation.

This is a rather common workflow these days as it's a pretty popular product. So I'm a little mystified how these dull and/or bad prints are occurring when converting from ProPhoto RGB to print space.


Chris Murphy