3 ms·

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 o

by 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.
  - kllrnohj 8y ago
    > ...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. :) OpenGL/GLES don't directly do anything with color spaces or gamut. It's part of the integration with the windowing system that does it. Which in the mobile usage is typically EGL, but desktop tends to do something else like WGL. So sounds like you're just punting this decision over to GLFW3, and you're getting whatever behavior it felt like giving you. Which is probably sRGB or linear-sRGB. > 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. Easy to think about, but also wrong :) If you want easy, you want linear extended SRGB, aka scRGB. This gives you [0, 1] in the colors you are typically familiar with. And it means when you display pure white, you're not shoving 1,000 nits into the face of a user with an HDR monitor. But it means your valid range becomes [-0.5, 7.5] instead. > a color calibrated display It doesn't matter how calibrated the display is if the source content isn't color aware. When you say glClearColor(1.0, 0.0, 0.0, 1.0), which color red is the display supposed to give you? It'd be broken if it just gave you the reddest-red it can display, because then your colors will never match when going between different gamut displays. Anything that takes a color must also be given a colorspace or have a well-defined one. Otherwise nothing about color works. And if it's a well-defined single colorspace, that single colorspace needs to cover the entire visible spectrum (which extended sRGB does, but something like DCI-P3 doesn't), otherwise it'll just become obsolete when displays get wider color gamuts. All the legacy APIs that don't do this just behind your back say "this came from sRGB colorspace" because that's what used to happen. But anything new shouldn't be doing that, because then it won't work with HDR, wide-gamut mobile displays, etc... By which I mean "can't display the full range of colors possible on the display"

by Reelin 8y ago

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.
- kllrnohj 8y ago
  > ...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. :) OpenGL/GLES don't directly do anything with color spaces or gamut. It's part of the integration with the windowing system that does it. Which in the mobile usage is typically EGL, but desktop tends to do something else like WGL. So sounds like you're just punting this decision over to GLFW3, and you're getting whatever behavior it felt like giving you. Which is probably sRGB or linear-sRGB. > 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. Easy to think about, but also wrong :) If you want easy, you want linear extended SRGB, aka scRGB. This gives you [0, 1] in the colors you are typically familiar with. And it means when you display pure white, you're not shoving 1,000 nits into the face of a user with an HDR monitor. But it means your valid range becomes [-0.5, 7.5] instead. > a color calibrated display It doesn't matter how calibrated the display is if the source content isn't color aware. When you say glClearColor(1.0, 0.0, 0.0, 1.0), which color red is the display supposed to give you? It'd be broken if it just gave you the reddest-red it can display, because then your colors will never match when going between different gamut displays. Anything that takes a color must also be given a colorspace or have a well-defined one. Otherwise nothing about color works. And if it's a well-defined single colorspace, that single colorspace needs to cover the entire visible spectrum (which extended sRGB does, but something like DCI-P3 doesn't), otherwise it'll just become obsolete when displays get wider color gamuts. All the legacy APIs that don't do this just behind your back say "this came from sRGB colorspace" because that's what used to happen. But anything new shouldn't be doing that, because then it won't work with HDR, wide-gamut mobile displays, etc... By which I mean "can't display the full range of colors possible on the display"