[Openicc] review of new wide gamut editing space

[Kai-Uwe Behrmann]

Am 21.03.12, 11:43 -0600 schrieb Chris Murphy:
> On Mar 21, 2012, at 11:30 AM, Chris Lilley wrote:
>
>> Isn't an L* transfer curve even worse for a 2.2/sRGB style system?
>>
>> The monitor reviews on prad.de seem to have the worst results when trying to profile to eciRGB_v2 which uses L*
>
> The entire paradigm of L* as a superior TRC for devices and intermediate 
> (editing) spaces is wholly absurd. I doubt even I could come up with 
> sufficiently insulting language for how utterly ridiculous it is. It's a 
> solution in search of a problem, which is worse than the problem.

Hehe, insults against colour spaces are not allowed ;-)

Anyway, I like the idea of the monitor gamma behaving like CIE*L . That is 
possible with the monitor internal gamma set to the same CIE*L with 
10+ bits.

> On Mar 21, 2012, at 11:32 AM, Chris Lilley wrote:
>
>> If the data is limited to 8 bits per component then sRGB seems like the 
>> obvious choice.
>
> 8bpc to deliver a wide gamut image isn't a big problem, so long as it 
> isn't going to be subsequently edited. If it was produced from a high 
> bit version, the conversion to 8bpc produces the "correct 8 bits per 
> channel" for the intended TRC.

Well, toolkits do more or less only 8-bit.

> Most any conversion of this image for subsequent display is going 
> through a minimum 16bpc transform anyway, so again quantization is 
> minimal.
>
> However, if we want to get color geeky about it, the ideal for the best 
> precision of an 8bpc wide gamut image, would be to establish a TRC 
> closest to that of the final display conditions, so even that 16bpc 
> conversion to display involves minimal quantization. That is probably a 
> TRC defined by the sRGB curve (or a gamma function of 2.2, I'm not sure 
> how relevant the toe really is in today's actual display conditions).

I have thought about a dynamic intermediate space as well. But this is not 
really simple.

kind regards
Kai-Uwe
-- 
www.oyranos.org