I will acknowledge that if we're forced to select only a single color space to work with, scRGB is an elegant drop in solution due to the value overlap. However as a developer, I really don't want to be forced to work with 16-bit color depth in all cases and I'd much rather write algorithms to process data on the interval [0, 1] due to the reduction in complexity of both thought and code.

> Easy to think about, but also wrong

Not at all! It's only wrong if there isn't a way to tell the API what color space the data is in, ie how the data is meant to be interpreted. You keep describing a data format that is color space aware, while I'm describing an API that is color space aware coupled with a data format that is generic.

What I'm arguing for here is a clear separation between image data and the color space used to interpret that data, such that algorithms don't have to be customized to fit a specific (likely platform dependent) color space. I think that data storage and manipulation should happen using a simple linear model such as [0, 1], with a separate mechanism for communicating to the API what color space the data occupies.

So yes, I do think that a hypothetical clearFrame(1.0, 0.0, 0.0, 1.0) function call should result in the reddest red possible - within the currently configured color space. Separately, it should be possible to do something like setColorSpace("AdobeRGB") and thereby change the meaning of (1.0, 0.0, 0.0, 1.0) to the API. Of course the graphics stack and underlying hardware then have to work together to actually display that data correctly. It could well be that the display doesn't support the particular color space that was specified and will need to convert appropriately, but the entire point here is that the algorithms written by the programmer don't have to be tailored to a specific color space.

As clearly illustrated by your HDR example, sane defaults are a necessity for any system. Given the history, it seems that a reasonable API ought to assume sRGB in lieu of an explicit selection, which it seems they already do for the most part. Thus in the example you provide, the color (1.0, 0.0, 0.0, 1.0) would result in a perfectly reasonable shade and intensity of red on any device.

Note that the entire problem of obsolete APIs you refer to is due entirely to making assumptions about which color space the caller is using. The approach I've described here completely avoids this - you can bolt on new color spaces later in a clean and fully backwards compatible manner. More than that, you can even convert existing APIs in a fully backwards compatible manner because you can reasonably assume that they were already using linear sRGB unless otherwise specified.

>> a color calibrated display

> It doesn't matter how calibrated the display is if the source content isn't color aware.

Well yes, naturally. I was only meaning to note the need for the entire stack to handle things properly, from driver through to display device. My line of reasoning was that if your API sends non-linear sRGB data to a display expecting, for example, linear Adobe RGB data, or if the display isn't color calibrated in the first place, or ..., then things obviously aren't going to work correctly. I never meant to imply that my color calibrated display could read my mind! You say that "Anything that takes a color must also be given a color space or have a well-defined one.", and I completely agree.

> OpenGL/GLES don't directly do anything with color spaces or gamut.

Actually OpenGL specifically supports the use of non-linear sRGB textures as a special case. Otherwise though your point is well taken, by default it indeed operates with colors that occupy a generic linear vector space.