On Tue, 27 Dec 2016 11:23:34 -0700 Chris Murphy <[email protected]> wrote:
> On Mon, Dec 26, 2016 at 11:00 PM, Mattias Andrée > <[email protected]> wrote: > > > On Tue, 27 Dec 2016 16:25:20 +1100 > > Graeme Gill <[email protected]> wrote: > > > > > Hi, > > > > > > Daniel Stone wrote: > > > > 'The size and depth' and 'the CLUT' are no longer > > > > applicable. Colour management units, incorporating > > > > two LUTs and a matrix (coarsely, > > > > degamma-transform-regamma) are becoming rather > > > > common now. These units can be present per-plane as > > > > well as per-output/pipe. Sometimes you have to make > > > > tradeoffs. > > > > > > Just because some hardware is a lot more capable, is > > > no reason to ignore supporting currently expected > > > functionality. > > > > > > Simple per channel hardware lookup tables have been > > > supported by graphics card software for a very long > > > time (Our X terminals in the late 80's certainly had > > > them), so this level of support can be assumed as > > > almost universal, and there are well understood > > > reasons for using such hardware to set the state of > > > the display for color management purposes at least > > > (which I have articulated elsewhere). Usage of > > > further HW capabilities (matrices etc.) are much less > > > clear - no application interested in fully utilizing > > > a displays best possible gamut has any use for them > > > (since they can only reduce the gamut), > > > > Ideally I think the display server should support sRGB, > > CIE XYZ, and the monitors' native RGB for input. > > > What does "support" mean in this context? That client can specify which colour space/model it uses. > > 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) > > 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 I think it is important when when any non-final colour space the resolution is at least 16 bits, and I'm fine with the final colour space having higher resolution than the size of the gamma ramps. > get away with 8 bit per channel CIE L*a*b* but even > that's questionable these days. I would reject CIE L*a*b* because it requires more expensive conversion and more than two conversion steps. > I'm pretty sure there is > an agreed upon 8 bit encoding for Lab, but no agreed upon > 8 bit encoding for XYZ. > I think native ‘float’s or ‘double’s should be used. They are only used internally on the computer (or between computers that share a display) and native representation will be cheapest time-wise. > >
pgpfst4nrkyI8.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
