[Openicc] meta data in test chart

[edmund ronald]

On Tue, Jan 25, 2011 at 3:32 AM, Chris Murphy <lists at colorremedies.com> wrote:
> 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


Chris,


If I understand rightly, you recommend that the workflow breaks down
into two parallel but separate pipelines, one for pros, and one for
consumers.

- (CONS) The consumer workflow would be attempting to go with sRGB or
AdobeRGB and a 16 bit pipeline.
- (PROF)the pro workflow would be all singing and dancing.

It's 6 in the morning, I'm not sure I'm very good at this :) However,
I think that
- (CONS) needs careful future -proofing so it doesn't make implicit
gamut assumptions, but we have available all the tools to do it. A
simplified UI is possible at system level because the only *real* user
decision is the basic workspace, and even that should be hardwired to
sRGB at distribution installation.

- (PROF) needs some consultation with the GIMP *functionality* guys
because Gutenprint can now do 16 bits easily, but they cannot provide
them, and they are going to be necessary or wide-gamut workflows will
be wrecking images at conversion time.

This just deals with the actual image data being passed around, it has
nothing to do with print settings or print profiles etc apart from the
fact that a 16-bit print chain should allow us to solve a lot of fine
linearisation issues with the dual hammers of ink limitation and
profiling.

My feeling is that at this point it is getting more and more urgent to
get the GIMP guys on board. Especially for the (PROF) workflow they
need to know what is going to be downstream so as to implement profile
conversions and image write-out with the required bit-depth which is
going to be essential to the print path.

Edmund