4 ms·

I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_colo

by Reelin 8y ago

I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.

kllrnohj 8y ago
Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.
- Reelin 8y ago
  Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.
  - kllrnohj 8y ago
    > My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. Non-linear blending is very common. Do a CSS gradient, for example, and it'll happen in sRGB gamma space not linear space, giving you incorrect results. Linear should be used more than it is, though, definitely. > I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace. sRGB can be both linear & non-linear. In the absence of something specifying sRGB assumes a non-linear gamma function of 2.2, but it doesn't always. Linear sRGB is very much A Thing. If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? If so, that's linear sRGB. If you wanted to output, say, Display_P3, then you need to use EGL_GL_COLORSPACE_DISPLAY_P3_LINEAR_EXT instead. But you can very much do a single color space. That'd be the linear extended sRGB I originally talked about, which is float in the range of -.5 to 7.5. Also called scRGB. Microsoft makes use of this as of Windows Vista.
    - Reelin 8y ago
      That CSS gradient example seems like a proper foot gun to me - I don't use CSS much, and I would never have expected that. > If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? ...I've just realized, are you talking about the EGL API (as opposed to OpenGL)? I don't actually use that - I nearly always restrict myself to an OpenGL or GLES core profile (no extensions) and use a support library (nearly always GLFW3) to handle all interfacing with the local system in a platform independent manner. It just keeps my code sane and manageable. :) So for me, to output 8-bit non-linear sRGB colors from a fragment shader I would attach a GL_SRGB8 formatted image to my FBO. Much more typically though I would simply use GL_RGBA8 and output on the range [0, 1]. > Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace. I was very confused by this statement and most of what followed it. After reading a bit, I think I was conflating color spaces and color models. If I understand correctly, all along I've been manipulating a linear RGB color model which was then mapped by my monitor on to (most likely) some approximation of the sRGB color space. So where I said linear earlier, I believe what I meant was any linear RGB color model (not space). Bonus points for using [0, 1] as the interval because it's easy to think about. What it comes down to is that as a programmer, I just want to get my code working. Linear models on [0, 1] are easy to process and think about - 0 is off, 1 is on, and 0.5 is half way in between. If you want to add things together, you just add them together. Remapping from one range to another is trivial. It all just works. Sure it doesn't match up with human perception the way you might expect, but that's what the graphics API, drivers, a color calibrated display, and possibly some complicated external libraries are for, right? At least in theory.

by Reelin 8y ago

kllrnohj 8y ago

Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.

Reelin 8y ago
Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.
- kllrnohj 8y ago
  > My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. Non-linear blending is very common. Do a CSS gradient, for example, and it'll happen in sRGB gamma space not linear space, giving you incorrect results. Linear should be used more than it is, though, definitely. > I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace. sRGB can be both linear & non-linear. In the absence of something specifying sRGB assumes a non-linear gamma function of 2.2, but it doesn't always. Linear sRGB is very much A Thing. If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? If so, that's linear sRGB. If you wanted to output, say, Display_P3, then you need to use EGL_GL_COLORSPACE_DISPLAY_P3_LINEAR_EXT instead. But you can very much do a single color space. That'd be the linear extended sRGB I originally talked about, which is float in the range of -.5 to 7.5. Also called scRGB. Microsoft makes use of this as of Windows Vista.
  - Reelin 8y ago
    That CSS gradient example seems like a proper foot gun to me - I don't use CSS much, and I would never have expected that. > If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? ...I've just realized, are you talking about the EGL API (as opposed to OpenGL)? I don't actually use that - I nearly always restrict myself to an OpenGL or GLES core profile (no extensions) and use a support library (nearly always GLFW3) to handle all interfacing with the local system in a platform independent manner. It just keeps my code sane and manageable. :) So for me, to output 8-bit non-linear sRGB colors from a fragment shader I would attach a GL_SRGB8 formatted image to my FBO. Much more typically though I would simply use GL_RGBA8 and output on the range [0, 1]. > Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace. I was very confused by this statement and most of what followed it. After reading a bit, I think I was conflating color spaces and color models. If I understand correctly, all along I've been manipulating a linear RGB color model which was then mapped by my monitor on to (most likely) some approximation of the sRGB color space. So where I said linear earlier, I believe what I meant was any linear RGB color model (not space). Bonus points for using [0, 1] as the interval because it's easy to think about. What it comes down to is that as a programmer, I just want to get my code working. Linear models on [0, 1] are easy to process and think about - 0 is off, 1 is on, and 0.5 is half way in between. If you want to add things together, you just add them together. Remapping from one range to another is trivial. It all just works. Sure it doesn't match up with human perception the way you might expect, but that's what the graphics API, drivers, a color calibrated display, and possibly some complicated external libraries are for, right? At least in theory.