[Openicc] meta data in test chart

[Chris Murphy]

I'm unsure of the context, and that makes a big difference.

If we're talking about professional workflows, the image editing portion should be 16bpc float, or 32bpc float, depending on hardware capabilities. Since there is enough precision and it's floating point, the tone reproduction curve doesn't matter, you can define colors inside as well as outside of the sRGB gamut. And then you'd need a means of soft-proofing to an actual output-referred aimpoint, to render the image for that particular gamut and dynamic range. That's presently how we get the best results, specifically because we don't have dynamic gamut mapping, or spacially-variant luminance mapping. Yet.

For everyone else, their images are already output-referred to sRGB, or Adobe RGB. And the workflow I would honor is maintain the image in the space that it's rendered into. I wouldn't do a conversion on an 8bpc Adobe RGB file to sRGB and then display or print it. It's a waste of time, you don't get anything for it. Most of the time the colors are going to be the same anyway.

I think the notion that converting images to sRGB or monitor RGB is kindof a stupid workflow. I know why Microsoft and Apple chose that paradigm. But its flawed because it ignores all kinds of realities about the average user's ambient lighting and surround conditions. No one is getting soft proofing who does not put a lot of effort into it. Dumbing an image down from Adobe RGB to sRGB jto reduce the gamut of the capture a bit so that there's better correlation screen to print I think is a total fantasy. Most real scenes contain colors that happily exist in both sRGB and Adobe RGB (1998). A bigger difference is the quality/consistency of the in-camera rendering into sRGB or Adobe RGB, not the size of the color space itself.

So from those two workflows, just prior to printing you have;

a.) 16bpc floating-point or 32bpc-floating point, sRGB primaries (or whatever)
b.) 8bpc integer sRGB most likely, maybe 8bpc integer Adobe RGB (1998)

Images conforming to b.) can be printed as is they are, although I'd say there's no compelling reason on most netbook and better hardware to treat all of these images in their original space but drop them into the 16bpc printing pipeline. I wouldn't even bother with the 8bpc pipeline for such hardware. For tablets and phones, OK sure 8bpc print pipeline is the default.

Images conforming to a.) they're going to have to be rendered to output by the application that's editing them; probably best to convert them directly to output space, 16bpc integer encoding; or if a handoff is necessary then 16bpc integer in the widest supported color space.


Chris


On Jan 24, 2011, at 3:10 PM, edmund ronald wrote:

> Chris,
> 
> Would you mind making some workflow suggestions? Personally, I like
> the Mac's idea of choosing a handoff space and having a default
> handoff space of sRGB, because it works well for consumers. However it
> created an awful mess when their handoff space changed *from*
> genericRGB, and so it might be better to go straight to a big handoff
> space, maybe with a 16bit default workflow - which Gutenprint can
> easily do, but I think Gimp cannot -yet.
> 
> Or maybe one should not have a handoff space at all, and implement
> direct conversion, maybe even with an option of computing the gamut of
> the source image - which seems to be what Graeme suggests.
> 
> Your suggestions on architecture would be highly appreciated, I
> believe, by everyone here.
> 
> Edmund
> 
> On Mon, Jan 24, 2011 at 8:58 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> 
>> 
>> On Jan 24, 2011, at 5:57 AM, Graeme Gill wrote:
>> 
>>> 
>>>> The system above is actually not a bad design, but it would be even
>>>> better provided the handoff space were ProfotoRGB (very wide gamut)
>>>> or PRNG (all printable colors), and a 16 bit conversion were
>>> 
>>> I'm not sure that's a good idea with current workflows. The reason
>>> is that few if any workflows have, or communicate the concept
>>> of an image gamut. Unlike other smaller gamut color spaces, where
>>> typically the image has been rendered to just fit into that space,
>>> and therefore the colorspace gamut is a reasonable guide to the image gamut,
>>> a very wide gamut space like ProPhoto or L*a*b* cannot be used
>>> as a guide, because the images gamut will almost always be a great
>>> deal smaller than the space it is encoded in.
>>> 
>>> The reason this is important is gamut mapping. If an image is to
>>> be mapped well into the destination colorspace, the gamut it
>>> occupies needs to be known or anticipated. If the encoding colorspace
>>> no longer provides that information, where does it come from ?
>> 
>> Use of the PRMG would be useful here, in theory, because the idea is that the image is rendered scene-referred to output-referred once in something like ProPhoto RGB. The problem is that Adobe RGB and ProPhoto RGB do not come in v4 versions that make use of the PRMG. And then also there are no widely available v4 + PRMG output device profiles. So as far as I'm concerned ICC v4 and the PRMG are in a coma for mainstream users.
>> 
>> 
>> Chris Murphy
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>