[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
>  > On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill <graeme2 at argyllcms.com>
>  > said:
> 
>  > a display may not have a single native colorspace. it may be able to
>  > switch. embedded devices can do this as the display panel may have extra
>  > control lines for switching to a different display gammut/profile. it may
>  > be done at the gfx card output level too... so it can change on the fly.
> 
> That's not a typical situation though, but nothing special would be
> happening - a new profile may be installed by the user as well,
> in which case an application should re-render to accommodate
> the change.

the user at most should be interacting with compositor settings/tools to
configure a specific profile for a display (let's assume a fixed profile for
that screen), so a compositor tool to tell the compositor the profile changed
(pressed a button on the monitor to change it). when they alter the compositor,
then compositor can tell applications.

>  > yes. compositors right now work in display colorspace. they do no
>  > conversions. eventually they SHOULD to display correctly. to do so they
>  > need a color profile for the display.
> 
> For enhanced color management yes. But core comes first, and is necessary
> for many color critical applications, because the compositor will never
> have the color transformations they require.

they will have to have them, or then not support that colorspace at all.

>  > it may be that a window spans 8 different screens all with different
>  > profiles. then what?
> 
> As I've explained several times, what happens is that the application
> is aware of this, and transforms each region appropriately - just
> as they currently do on X11/OS X/MSWin systems.

not in wayland. not acceptable. the app will never know which windows it is on.
as i have said - could be wrapped around a sphere or a room full of bunnies
bouncing about across 8 screens.

>  > with a
>  > proper color correcting compositor it can make them all look the same.
> 
> As will a color aware application given appropriate color management support.

it can't if it doesn't know how a window or buffer is transformed or mapped to
screens.

> The code is already there to do all that in color critical application.

then they get to pick a colorspace and render to that. attahc that to the
buffer. compositor will do whatever it wants. e.g. if that buffer is on the
screen it matches it'd do no transform. maybe it does no transforms at all. and
simply hovers some indicator above the serface telling you if the surface
colorspace matches the screens colorspace or not. maybe compositor disallows
the window to be moved off the screen that matches the colorspace. that can be
configured via the compositor.

>  > if i mmove the
>  > window around the client has drawn different parts of its buffer with
>  > different colorspaces/profiles in mind and then has to keep redrawing to
>  > adjust as it moves.
> 
> Yes.

and now you just hit "unacceptable in wayland land" space. which is why i tell
you that this is not acceptable.

>  > you'll be ablew to see "trails" of incorrect coloring around the
>  > boundaries of the screens untl the client catches up.
> 
> It's damage, just like any other, and color critical users using
> color critical applications will take "trails" over wrong color
> anytime. No "trails" and wrong color = a system they can't use.

and totally unacceptable for wayland space. so a big fat no to that kind of
design.

>  > the compositor SHOULD do any color correction needed at this point.
> 
> Not at all. That's a way to do it under some circumstances yes, but
> it's not satisfactory for all.

it is up to the compositor. if the goal is to make colors visibly as uniform as
is possible given the displays that exist then it should. not all compositors
will. they may do things differently like above. maybe limit location of a
window/surface or place an indicator above a window when it is fully on the
correct screen for its color profile, and/or they may transform colorspaces.

>  > if you want
>  > PROPER color correction the compositor at a MINIMUM needs to be able to
>  > report the color profile of a screen even if it does no correcting.
> 
> Yes - exactly what I'm suggesting as core color management support.

but it doesnt have to tell you which screen it is nor tell you which screen
your window is on. it's an option of 1 of various colorspaces to be able to use
given a specific compositor.

>  > yes you may have
>  > multiple screens. i really dislike the above scenario of incorrect pixel
>  > tails because this goes against the whole philosophy of "every frame is
>  > perfect".
> 
> "Every pixel being perfect" except they are the wrong color, isn't perfect.

IF the compositor is doing the transformce of colorspaces, then you can acheive
perfect pixels.

> There are multiple ways of doing the best thing possible - you can't re-render
> a frame in the compositor if it doesn't have the pixels needed to render it,
> so you can 1) not re-render until the application provides the pixels
> needed 2) Render the wrong color pixels until the application catches up
> or 3) (if the compositor has some color management capability and
> the application sets it up) get it to do an approximate correction to
> the pixels until the application catches up with the correct color.

thus compositor only supports the colorspaces/profiles is knows how to
transform if it is doing this, or it is passive and just reports what is
available  doing no transforms and maybe saying "get monitors that share the
same color profile if you really care".

reality is compositor do have to do transforms to get 601,709 and the new 2020
colorspaces right for video anyway.

>  > you
>  > cannot do this given your proposal. it can only be done if the compositor
>  > handles the color correction and the clients just provide the colorspace
>  > being used for their pixel data.
> 
> And a compositor can't know how to transform color in the way some
> applications require. This trumps such goals.

if it doesn't know, and it wants to display by transforming, then it shouldnt
offer.

>  > being able to  modify what the screen colorspace is in any way is what i
>  > dislike.
> 
> That's the reality of how displays work. The user presses a button on the
> front that says "emulate sRGB" or "native" or "Preset 1" or something else.

i mean control by applications. by wayland clients.

>  > only the compositor should affect this based on it's own decisions.
> 
> And color critical users will scream bloody murder at anything related
> to color that isn't under their control, if it affects the accuracy or scope
> of the color workflow.

that's what compositor tools are for. the compositor settings are going to be
how you load/configure color profiles for a display. not via protocol.

>  >> No, not supported = native device response = not color managed.
>  >
>  > and for most displays that is sRGB.
> 
> Not in the slightest. Having (ahem!) profiled a few displays, none of them
> are exactly sRGB. Some may aspire to be sRGB, they may approach sRGB,
> but (because they are real devices, not an idealized norm) none are sRGB.
> [ Black point alone is miles out for most LCD based displays. ]

of course they are not exact. they are approximately srgb which is vastly
different from adobe or wide gammut etc. no display other than insanely priced
professional displays is going to be EXACTLY sRGB or adobe rgb etc. it's going
to be a bit off and thus some color profile adjusting via either some table/lut
with interpolation is going to be needed.

>  >> No compositor is involved. If the application doesn't know
>  >> the output display profile, then it can't do color management.
>  >
>  > it can assume sRGB.
> 
> That's up to the user. The user may have something else they can
> assign if they are unable to profile the display (EDID derived
> profile, model generic profile, etc.)

that's the compositor that deals with this internally. via its own tools and
settings. not some generic user tools or photoshop app etc.

>  >> Please read my earlier posts. No (sane) compositor can implement CMM
>  >> capabilities to a color critical applications requirements,
>  >> so color management without any participation of a compositor
>  >> is a core requirement.
>  >
>  > oh course it can. client provides 30bit (10bit per rgb) buffers for
>  > example and compositor can remap. from the provided colorspace for that
>  > buffer to the real display colorspace.
> 
> It's not about bit depth, it's about algorithms. No compositor can
> do a transformation that it doesn't have an algorithm for.

and then it doesnt offer it if its display methodology is to transofrm to get
colors uniform. pretty simple.

>  >> Relying on an artificial side effect (the so called "null color
>  >> transform") to implement the ability to directly control what is
>  >> displayed, is a poor approach, as I've explained at length previously.
>  >
>  > but that is EXACTLY what you have detailed to rely on for color managed
>  > applications. for core color management you say that the client knows the
>  > colorspace/profile/mappings of the monitor and renders appropriately and
>  > expects its pixel values to be presented 1:1 without remapping on the
>  > screen because it knows the colorspace...
> 
> Yes, a switch (Don't do color management) is far cleaner than trying
> to trick a constant color management compositor into not doing color
> management by feeding it a source profile that is (hopefully)
> the same as the destination profile (and how do you do that
> if the surface spans more than one Monitor ?)

you need a bunch of "enums" or values for colorspaces provided plus some
matching LUT or transform adjustment data. it makes far more sense for sRGB/709
(the assumed default right now) to be part of this list with no lut/adjustments
rather than a special single flag.

>  >> No compositor should be involved for core support. The application
>  >> should be able to render appropriately to each portion of the span.
>  >
>  > then no need for any extension. :) compositor HAs to be involved to at
>  > least tell you the colorspace of the monitor... as the screen is its
>  > resource.
> 
> As I've explained a few times, and extension is needed to provide
> the Output region information for each surface, as well as each
> outputs color profile, as well as be able to set each Outputs
> per channel VideoLUT tables for calibration.

that's not going to happen. it's a wayland design premise that applications
should not know this.

>  >>> this way client doesnt need to know about outputs, which outputs it spans
>  >>> etc. and compositor will pick up the pieces. let me give some more
>  >>> complex examples:
>  >>
>  >> That only works if the client doesn't care about color management very
>  >> much - i.e. it's not a color critical application. I'd hope that the
>  >> intended use of Wayland is wider in scope than that.
>  >
>  > how does it NOT work?
> 
> It doesn't work when the compositor doesn't have the color transform
> capability that the application requires.

see above.

>  > let me give a really simple version of this.
>  >
>  > you have a YUV buffer. some screens can display yuv, some cannot. you want
>  > to know which screens support yuv and know where your surface is mapped to
>  > which screens so you can render some of your buffer (some regions) in yuv
>  > and some in rgb (i'm assuming packed YUVxYUVxYUVx and RGBxRGBxRGBx layout
>  > here for example)... you wish to move all color correct rendering,
>  > clipping that correct (yuv vs rgb) rendering client-side and have the
>  > compositor just not care.
> 
> Let me give you an example. The application has a ProPhotoRGB buffer,
> and wants to render it with image specific gamut mapping into the display
> space. It has code and algorithms to 1) Gather the image gamut, 2) Compute
> a gamut mapping from the image gamut to the Output Display gamut, invert
> the A2B cLUT tables of the Output display profile to floating point
> precision with gamut clipping performed in a specially weighted CIECAM02
> space.
> 
> I'm not quite sure how the Wayland compositor is going to manage all that,
> especially given that the application could tweak or change this in
> every release.

app provides the above mapped data. it ends up being an R, G and B value for
one of the compositor supported colorspaces - e.g. one of them is monitor #3.
when on monitor #3 the compositor does passthrough of that buffer. it displays
with no changes (for example). but when it is on another screen the compositor
maps FROm the colorspace of that monitor TO another. yes. this can b e lossy.
you can dither of course (and even do temporaly dithering) to approximate
colors. it will look best on that display. it'll look "as good as possible" on
other displays. the compositor doesn't need to know or care what original data
is if it's prophotorgb or anything else. it just does its best to map colors
for 1 output colorspace to another *IF* it does remapping. if it doesnt then
you get what you get. but the compositor knows what colorspace a buffer is for
and CAN try and get it right.

>  > the point of wayland is to be "every frame is perfect". this breaks that.
> 
> A pixel is not perfect if it is the wrong color.

flickering/trails is worse.

>  >> If you don't care so much about color, yes. i.e. this is
>  >> what I call "Enhanced" color management, rather than core.
>  >> It doesn't have to be as flexible or as accurate, but it has
>  >> the benefit of being easy to use for applications that don't care
>  >> as much, or currently aren't color managed at all.
>  >
>  > how not? a colorspace/profile can be a full transform with r/g/b points in
>  > space... not just a simple enum with only fixed values (well thats how i'm
>  > imagining it).
> 
> A color profile can be quite complex, including scripted in the case of
> something like an OCIO or ACES profile 
> <http://www.oscars.org/science-technology/sci-tech-projects/aces>.
> 
> But the device profile is only half the story - it does nothing on its
> own, it needs to be linked with another device profile. And the flexibility
> at that point is unlimited.

and the device end is all a compositor cares about.

>  > profide a list of 1 colorspace -
>  > the monitor native one. application renders accordingly. if colorspace of
>  > rendered buffer == colorspace of target screen, compositor doesn't touch
>  > pixel values.
> 
> Bad way of doing it, for reasons I've pointed out multiple times.
> Be explicit rather than rely on a trick - use a switch.

it's not a trick. its a standard null op. src fmt == dest fmt. no conversion
needed.

>  > color management require introducing such things. BT.601, BT.709, BT.2020.
>  > the compositor MUST KNOW which colorspace the YUV data uses to get it
>  > correct.
> 
> Sure, but that's not an aspect I've mentioned. Ultimately the display
> is RGB, irrespective of the encoding using to carry that information
> to it.

without a colorspace attached to yuv buffers you cannto know how to transform
them to rgb (srgb) values correctly at all. ignoring screen output colorspce
differences entirely here. just plain math to srgb space.

>  > i'm literally starting at datasheets of some hardware and you have to tell
>  > it to use BT.601 or 709 equation when dealing with YUV. otherwise the
>  > video data will look wrong. colors will be off. in fact BT.709 == sRGB.
> 
> Sure - complexity in managing encodings. But that has nothing
> directly to do with color management, which is about colorspace
> differences.

its the same thing - it's mapping a set of colors to another set in order to
get correct physical colors.

>  > now here comes the problem... each hardware plane yuv may be assigned to
>  > MAY have a different colorspace. they also then get affected by the color
>  > reproduction of the screen at the other end.
> 
> To be fare, I'm not that aware of how the hardware presents itself
> in regard to such things (data sheets seem hard to come by, and I
> have gone looking for them in vain on a few occasions), but for many color
> critical uses, it's not an immediate concern because such applications
> are not going to be using yuv buffers. (Exception might be a video
> editing/color grading application sending previews to a TV or
> studio monitor - but all that is about encodings rather than
> colorspaces.)

tell the people building millions of smart tv's that yuv color correctness
doesn't matter for that tv they are selling for $20,000+. :) hell even over
$100k. yuv color correctness matters just as much.

>  > any list of colorspaces IMHO should also include the yuv colorspaces
>  > where/if possible.
> 
> I don't think so. If you look at the video standards, the color spaces are
> all specified as RGB. YCbCr is a different encoding of the same color
> space with a precise definition of the transformation to/from.

well the 3 i mention are always associated with a yuv encoding of video data
specifically. as i have mentioned srgb/709 are the same rgb colorspace. 2020 is
closer to wide gammut rgb.

>  > my point was i don't think it's needed to split this up.
>  >
>  > compositor lists available colorspaces. a list of 1 sRGB or null-transform
>  > or adobe-rgb(with transform matrix), wide-gammut, etc. means thathat is
>  > the one and only output supported.
> 
> I'm not quite sure of the context here - the display system only
> knows about color spaces it has been told about. Someone has
> to tell it what the color profile of its displays are, and
> the application is the thing that knows what the color spaces
> of the input spaces it deals with are.

the compositor will have configuration/tools/data. it will be configured to
have a specific profile/LUT/mapping for a specific screen. it may come with an
edid database for "professional monitors" and known color profiles or something
else... but it's not the place of a general client protocol to do this.

>  > not as i see it. given a choice of output colorspaces the client can
>  > choose to do its own conversion, OR if it's colorspace of preference is
>  > supported by the compositor then choose to pass the data in that
>  > colorspace to the compositor and have the compositor do it.
> 
> Yes. But one is not the equivalent of the other, if the compositor
> doesn't have the same color transformation capability.

and as above. don't advertise the colorspace if you can't transform it properly
and no display supports it, or limit otherwise indicate to the user that the
window is on the correct display or can only be there etc. if you don't
transform.

>  > *sigh* and THAT IS WHY i keep saying that the client can choose to do it's
>  > own!
> 
> I'm in furious agreement with this bit. I just want to make sure that
> it is a core capability.

but they can't be guaranteed the compositor won't do more on top - eg adjust
colors when on a different screen not matching that profile. copmpositor may or
may not. as above.

>  > BUT this is not going to be perfect across multiple screens unless all
>  > screens share the same colorspace/profile. let's say:
> 
> This is an already solved problem in other systems, including X11.
> 
>  > 1 screen is a professional grade monitor with wide gammut rgb output.
>  > 1 screen is a $50 thing i picked up from the bargain basement bin at
>  > walmart.
>  >
>  > dumb compositor example:
>  >
>  > compositor reports 2 colorspaces:
>  >   null transform RGB
>  >   BT.709 YUV
> 
> Why is it reporting an encoding rather than a colorspace,
> and why isn't it providing the two display profiles ?

it doesnt know them from a stick in the mud. it's a dumb compositor.

>  > smart compositor:
>  >
>  > compositor reports 5 colorspaces:
>  >   null transform RGB
>  >   wide gammut RGB
>  >   sRGB
>  >   BT.709 YUV
>  >   BT.601 YUV
> 
> I don't see how extra encodings are useful without their
> corresponding color spaces.

as i have said before. the colorspace is a color transform WITH adjusting
constants/matrix/LUT etc.

>  > in the dumb case your app can't do much.
> 
> In the dumb or core case, it has two display profiles, one
> for the professional grade monitor with wide gammut rgb output,

no. the dumb case is "compositor has no idea. so i do rgb and yuv". it has no
clue otherwise.

> and the other for the bargain basement bin display from walmart.
> It can then transform source images in whatever colorspace they
> are tagged with, into the appropriate display colorspace,
> in the way the application and user needs it to be transformed.

it has no clue what the bargain basement bin monitor displays. the dumb
compositor isn't even going to try.

in the smart case the compositor at least knows what color profiles exist and
advertises them. it may or may not transform them from screen to screen for you.

>  > the point of wayland is "every frame is perfect". you want clients to
>  > rendering their content differently based on what screen their window is on
>  > then a compositor can NEVER get this right no matter how hard they try
>  > because clients are fighting them and making assumptions they absolutely
>  > should not. i already told you of more realistic cases of windows in
>  > miniature in pagers that are not on the same screen as the full sized
>  > window (as opposed to the silly bunnyrabit example above, but it's meant
>  > to make a point).
> 
> If this is really the case, then the conclusion is that Wayland is
> not suitable for serious applications, and certainly is not a replacement
> for X11. I don't actually think that that is true.

multiple people have told you this by now. applications are not going to know
what screen(s) their buffers span. it's abstract. equating this to "then
wayland is not for serious use" is sticking your head in the sand because
wayland does not work like every other display system that is 20 years old.

>  > you HAVE to abstract/hide this kind of information to ALLOW the compositor
>  > to get things right.
> 
> I doubt that. You just have to make some allowance for the
> application being able to determine the RGB values sent to the
> display, if it wishes to. Given that this is basically
> the case without compositor color management, and that
> in the compositor there is a definition of how surfaces
> get mapped to displays, I don't see at all why this is
> now impossible, when it is supported in other serious
> graphics systems.

see above.

>  >> A color critical user won't put up with such things - they expect to
>  >> be in control over what's happening, and if a system has proper
>  >> color management (core + enhanced), there is absolutely no
>  >> reason for them to run the display in anything other than it's native
>  >> gamut.
>  >
>  > a user actually should not have to deal with most of these issues at all.
>  > even a color critical one. they likely shouldn't have to remember which
>  > one of their 16 screens has the best colorspace support for that image.
> 
> Ideally, yes - but few have the money to get a full set of 16 EIZO displays.

even if it's 2 screens. the principle holds.

>  >> No, it's a list of N output display colorspaces, one for each display.
>  >
>  > see above. it should not be per display.
> 
> How can there be any color management unless the
> colorspaces of each display is recorded somewhere ???

as i have said several times. colorspace includes the details of the mapping.
e.g. a LUT or matrix or whatever blob sufficiently describes the mapping.

>  > sRGB is the colorspace of every HD display (or should be). how does it not
>  > come into it?
> 
> Because that's not actually true. Each real display has it's own
> response. That's why I write tools to profile displays, and why
> people use those tools.

yes. i know its slightly off and correcting input can make it look right (to
some extent). i'm talking braodly that most displays are nominally sRGB, or
nominally adobe rgb, or something else. there is a small bit of adjusting to do
to make them "close to perfect" and thats where your colorimiter plus doing and
actual profile of the display and recording the data helps. or maybe there is a
manufacturer provided file for that already...

>  > you don't need anything special for color calibration beyond a null
>  > transform and a compositor that won't go ignoring that null transform
>  > anyway for the purpose of color calibration (when used by a calibration
>  > app).
> 
> Agreed, + control over calibration curves.

no out-of-compositor tool will control those curves. likely they will provide
some calibration file that the compositor consumes and either adjust output or
monitor to correct it, or transforms pixel data to correct, OR it can pass that
data back to clients via the colorspace list.

>  >> It's the simplest possible support, (hence calling it "core").
>  >> It's needed internally anyway for a compositor to implement CMM
>  >> operations for "enhance" color management.
>  >
>  > it's also broken when you attach the color profile to a specific output.
>  > see above.
> 
> No it's not - it already works on X11/OS X/MSWin.

not in wayland. bunny rabbits.

>  > that's out of scope for wayland.
> 
> Exactly, which is why you can't hope to cover all possible
> client application requirements with color management
> done in the compositor.
> 
>  > HOW it is transformed is either done
>  > client-side to present whatever source data in a given output colorspace
>  > to the compositor OR it's done by the compositor to fix colorspaces
>  > provided by clients to display as correctly as possible on a given screen
>  > + hardware.
> 
> Right - so the client-side needs proper support for doing this, which
> is what a "core" color management extension provides.

which is just a list of colorspaces (as i've sayd - they contain transofmr data
such as matrices, lut tables etc.).

>  >> Hmm. Not really. Mostly a lot of other stuff has to go on top of that
>  >> to make things turn out how people expect (source colorspace definition,
>  >> white point mapping, gamut clipping or mapping, black point mapping etc.)
>  >
>  > source definition is out of scope.
> 
> It can't be out of scope if the compositor is to do color management.

compositor adjusts from an output colorspace to another. source is not
important to it. it also may not adjust/map and just add some indicator.

>  > that's up the the app (e.g. photoshop). the
>  > colorspce defintition indeed covers what you say. and it is about
>  > adjusting. i was saying the exact same thing. i am not unfamiliar with
>  > colorspaces, color correction and mapping. it's necessary for YUV->RGB and
>  > is fundamentally the same as RGB->RGB
> 
> I'm now wondering if we are talking about different things.
> The color management protocol I'm commenting on, is about
> transforming between different device color spaces,
> defined by ICC profiles etc. You seem to be referring
> mainly to color encoding transforms, although you are then
> throwing in references to sRGB, which is a colorspace definition.

no - i'm talking the device rgb colorspaces (yuv happens to be included too as
video colorspace definitions with yuv values map to specific defined rgb
output).

>  > 1 colorspace which is the screen's output space is NOT the same? is that
>  > not the same as a single screen system with the display colorspace on that
>  > 1 screen? how is it not the same? it's 1 colorspace exposed by compositor
>  > to client in both cases. the SAME colorspace. how is this not the same?
>  >
>  > the difference is that i dont think it should be per monitor.
> 
> The whole point is that each display has a different color response,
> and incoming color should be transformed to compensate for these
> differences. So each display (ideally) should have an associated
> color profile.

but clients shouldnt know which output it's for or which output they are on.

>  > and that is why when a compositor DOES know the display colorspace it would
>  > list that likely in addition to a null transform (there is basically no
>  > downside to listing a null transform. it's the compositor just doing
>  > nothing which is about as efficient as it gets).
> 
> This isn't typically true. A->B + B->A is not actually a null transform
> for (say) a cLUT based ICC profile, since the B2A is not an exact inverse of
> A2B. So you have to add a hack, that declares it a null transform.

eh? client rendered data for output given a specific colorspace/profile ... if
the monitor it is displaying on matches that... how does this not equate to a
null transform? the data is already in the correct colorspace...

>  > if the colorspace of a provided buffer == colorspace of output then it IS
>  > effectively a null transform for the compositor and it does (or should do)
>  > just that.
> 
> This depends on technical details of the profiles. Some
> sorts of profiles will be very close to null transforms, and some
> will not. (See above).

i'm not talking close. i'm talking "i used colorspace 36 in your list for this
buffer". and colorspace 36 is the exact profile of monitor B. and the window
now is displaying ONLY on monitor B. no transform needed at all for display
there.

>  >>   is a profile "exactly" invertible (i.e. to floating point
>  >>   precision). Use a LUT for the per channel curves (such as the
>  >>   original sRGB profile), and it's not quite perfectly invertible
>  >>   (although it may be to low precision). Use cLUT based profiles,
>  >>   and it certainly isn't. So it has to be declared to be
>  >>   a special case and assumed to be a null transform.
>  >
>  > no one is asking anyone to transform anything (thus invert or anything
>  > else) with a null transform.
> 
> That's what a null transform is though - a forward conversion
> (Device space to PCS) followed by an inverse transform
> (PCS to Device space).

which is inputpixel == outputpixel. nothing changes. no transform is done at
all.

>  > at startup a compositor would load the color profiles that were
>  > configured/stored from any previous execution that it knows match the
>  > displays
> 
> That's not possible if there was no previous execution.

it could have a database of every monitor in the world and edid matches and get
it right first go. for embedded use the device maker would pre-configure the
device with the correct profile at the factory.

>  > it has. you mean at setup time - like when someone buys a new monitor...
> 
> There may be no profile initially, - one is only available after
> the system is running, and the user is able to profile it.

nope. see above.

>  > > i'd have the compositor use a null transform (do nothing to rgb values)
>  > > UNTIL
>  > it has calibration data for that screen. you dont have to "create" a null
>  > transform. it's just listed in the colorspaces supported. it is the "do
>  > nothing" colorspace.
> 
> There's no colorspace to "list" without a profile though.

yes. and profile can be pre-shipped, some database etc.

>  > let me roll back in time. long ago in a land far far away i was working
>  > with x11 systems...
> 
> Hey - so did I. I was hacking on Labtam X terminal cfb code in the late
> 80's/early 90's, making sure we had the fastest X terminals in the
> world :-) :-)

i remember our labtams... shame about that coax... :)

>  > i do not want to see this kind of thing happen again in wayland land.
>  > that's why it matters to me. it leads to a frustrating user experience.
> 
> I'm not sure of the relevance. There are many color managed applications
> written for other graphics systems, and while there are things can trigger
> color management issues (OS X is somewhat notorious for issues caused
> by Apples API changes), I can't see how the situation could be analogous
> to the 1bpp/8bpp/24bpp X11 situation you illustrate above.

as long as it's not necessary to support it and applications run even if their
colors are a bit off.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com