[Openicc] meta data in test chart

[Chris Murphy]

On Jan 24, 2011, at 10:47 PM, edmund ronald wrote:
> 
> 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.

Well technically I'd say that it should honor the embedded profile (or EXIF color space, or other metadata if no ICC profile), period. If there is no color space metadata, then assuming sRGB is the source makes sense. 

And for bitdepth it depends on hardware optimization. Most display pipelines are 8bpc. But some are 5 or 6bpc for mobile devices, and on the desktop we're seeing 10bpc. I would defer to hardware to determine the bitdepth of the compositing space (used for the window server for example). And then for printing it would be either 8bpc or 16bpc, again depending on the hardware - mobile devices and maybe even netbooks could use an 8bpc printing pipeline (always), and then better hardware would always use a 16bpc pipeline.

My point is that I wouldn't give users a GUI option to decide bitdepth or intermediate space. For example Epson's 16bpc checkbox in the print driver. It's ridiculous. It should always be 16bpc, without a checkbox, because there's no advantage of 8bpc on the hardware the driver runs on. And there's no advantage to color space normalization to some smaller gamut (i.e. sRGB or monitor RGB) prior to printing.



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

I would only consider sRGB as the assumed source space for untagged content. For tagged content, simply honor the tag and convert to display RGB or printer RGB or printer CMYK, as the case may be.

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

Yeah for either wide-gamut or HDR they need 16bpc floating-point as a minimum for the compositing/editing/intermediate encoding space. And I'm suggesting if it's floating-point instead of integer encoded, they don't really have to have a very long conversation about what set of primaries to base it on because it's a minor issue, but Rec 709 primaries are favored for this.

I'd have them look at OpenEXR which has 16bpc and 32bpc floating point implementations for HDR images, and just use the Rec 709 primaries (same as sRGB).

Chris Murphy