[Openicc] meta data in test chart

Chris Murphy lists at colorremedies.com
Tue Jan 25 14:27:24 PST 2011


On Jan 25, 2011, at 5:16 AM, Scott Geffert wrote:

> Please consider testing eciRGBv2 as the handoff space. It is v2 and v4 compliant, and is slightly larger gamut than AdobeRGB.  Being L* based it seems more appropriate in this case. It is also being finalized as an ISO TS which fits the open source model better than a "corporate" color space. IMO sRGB limits the gamut as so many devices today are much larger gamut.


a.) The tone reproduction curve is irrelevant.

b.) The v4 version of eciRGBv2 doesn't use the PRMG so there's no point in testing it, it will have all the same perceptual weaknesses as any v2 profile does.

c.) The issue of sRGB's gamut relative to increasingly wider gamut display and print technologies means we shouldn't have intermediate color spaces in the pipeline causing a gamut bottleneck- i.e. normalizing everything into sRGB. I think such a workflow is not ideal, even for consumers, for the reasons I've previously mentioned. But eciRGB also has the same gamut bottleneck issue, so I would not recommend it as an intermediate space in a larger architectural framework for a platform either.

I don't think we should ask for the building of architectures that are obsolete or that have unnecessary bottlenecks out of the gate. A system wide available intermediate/editing space (as a library that the window server could one day tap into, as well as other applications), I'd propose would be 16bpc or 32bpc (depending on the hardware capabilities) float, and then use Rec 709 primaries. Then it effectively doesn't matter what the source image is, you don't have a meaningful bottleneck (yes you might have a small bottleneck for a 16bpc integer encoded ProPhoto image, being re-encoded as 16bpc floating-point encoded Rec 709/sRGB image but I think that's rather minor.)

Probably no matter what such things depend on hardware. But building out the least effort for the most performance and quality I think is the goal. I would not take a bet that the "force the hardware to be sRGB" paradigm even applies to mobile for much longer. There's an advantage for manufacturers to be able to have each unit capable of doing display compensation for everything that appears on the display. So a focus on optimization with minimal degradation of image quality for such products I think is inevitable.


Chris Murphy


More information about the openicc mailing list