4 ms·

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 th

by 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"
- Reelin 8y ago
  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.

by Reelin 8y ago

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"

Reelin 8y ago
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.