The way I see it we have two possibilities:
- use a set of well-known colorspaces (tags)
- allow the client to define its own colorspaces
The first possibility has the problem that clients can’t just pass in arbitrary colorspaces, might have to do color conversion on their own (e.g. a display with wide gamut and a measured ICC, compositor only advertises sRGB, client has to convert its image to the ICC if it wants wide gamut).
The second has the problem that the colorspace has to be communicated somehow. Creating our own format can result in really stupid mistakes and requires new tools and libraries, reusing an existing standard also has drawbacks (which standard to choose, which subset of the standard is valid for the use-case).
No solution seems particularly good.
I don’t think that’s an issue.
There is three levels:
- No conversion required (noop)
- The color conversion pipeline can be described by a bunch of matrices (easy for shaders and usable for the hardware)
- All other pipelines can be applied on some values on the CPU that are later used to form a 3d lut on the GPU (can’t be offloaded to the display hardware)
( ignoring EOTF/OETF but that’s not a problem either)