[Openicc] meta data in test chart

Graeme Gill graeme at argyllcms.com
Thu Jan 27 00:24:36 PST 2011


Chris Murphy wrote:
> 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.

Ahh, that explains it. They aren't actually ever rendering to ProPhoto, it's
just being used as a working space. They need to manually tune their
image to their chosen (real) output/printer space (presumably using trial and
error, or print preview), and then using colorimetric to avoid any
automatic (wrong) gamut mapping.

> 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.

That's what happens if you store an image as ProPhoto, and then gamut
map to your output space, on the assumption that the image has actually
been rendered into ProPhoto. Having it rendered to some printer space,
but stored in ProPhoto breaks conventional perceptual rendering workflows.

Graeme Gill.


More information about the openicc mailing list