<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 26, 2016 at 11:00 PM, Mattias Andrée <span dir="ltr"><<a href="mailto:maandree@kth.se" target="_blank">maandree@kth.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, 27 Dec 2016 16:25:20 +1100<br>
Graeme Gill <<a href="mailto:graeme2@argyllcms.com" target="_blank">graeme2@argyllcms.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Daniel Stone wrote:<br>
> > 'The size and depth' and 'the CLUT' are no longer<br>
> > applicable. Colour management units, incorporating two<br>
> > LUTs and a matrix (coarsely, degamma-transform-regamma)<br>
> > are becoming rather common now. These units can be<br>
> > present per-plane as well as per-output/pipe. Sometimes<br>
> > you have to make tradeoffs.<br>
><br>
> Just because some hardware is a lot more capable, is no<br>
> reason to ignore supporting currently expected<br>
> functionality.<br>
><br>
> Simple per channel hardware lookup tables have been<br>
> supported by graphics card software for a very long time<br>
> (Our X terminals in the late 80's certainly had them), so<br>
> this level of support can be assumed as almost universal,<br>
> and there are well understood reasons for using such<br>
> hardware to set the state of the display for color<br>
> management purposes at least (which I have articulated<br>
> elsewhere). Usage of further HW capabilities (matrices<br>
> etc.) are much less clear - no application interested in<br>
> fully utilizing a displays best possible gamut has any<br>
> use for them (since they can only reduce the gamut),<br>
<br>
</span>Ideally I think the display server should support sRGB,<br>
CIE XYZ, and the monitors' native RGB for input.</blockquote><div><br></div><div>What does "support" mean in this context?<br><br></div><div>sRGB is defacto on it's way out the door because manufacturers are pretty much all diverging from this color space now, while cameras purport to render image to it. So the situation is pretty awful for wide scale assumed color space workflows. You can reliably do assumed color space workflow internally in a tight closed loop situation; but for the broader open workflow every object and device has to be tagged with a color space or there will be partial data loss (color fidelity)<br><br></div><div>As for CIEXYZ, to literally convert pixels into this space, or even as an exchange space, it will require minimum 16 bits per channel or there will be noticeable quantization. It's a huge color space. You could maybe get away with 8 bit per channel CIE L*a*b* but even that's questionable these days. I'm pretty sure there is an agreed upon 8 bit encoding for Lab, but no agreed upon 8 bit encoding for XYZ.<br><br></div><br clear="all"></div><br>-- <br><div class="m_2513197850683100244gmail_signature" data-smartmail="gmail_signature">Chris Murphy</div>
</div></div>