5 ms·
“Linear” is in practice the official name. The only additional specificity you can have is to give the scalar conversion factor from your linear colors into phy
by dahart 4y ago
“Linear” is in practice the official name. The only additional specificity you can have is to give the scalar conversion factor from your linear colors into physical units like lumens or candela or watts per solid angle or surface area. What linear means is that you’re working in a scaled set of physical units. The scale factor is the only thing missing.
You might not ever need the physical scale factor, it doesn’t generally matter. You probably didn’t set your light or color intensities in three.js using physical units in the first place, and even if you did you might be simply scaling the values until things look right. We usually scale the inputs and outputs manually anyway, so the absolute scale of the intermediate linear color space in CG is frequently irrelevant.
HDR is mostly referring to whether your values are conceptually [0..1] or [0..infinity]. Sometimes people are also referring to how many bits get used per color channel. (But note that the R is HDR is referring to ‘range’ and not to ‘resolution’.) 8 bit color values that represent [0..1] are unambiguously LDR, while 32 bits per channel color values that represent [0..inf] are unambiguously HDR. If you use 16 bit colors and your range is [0..3] to allow for headroom and glare effects, it’s not really considered HDR, but it’s not exactly LDR either. It mostly only makes sense to work with HDR values in a linear color space, but it’s not strictly or by definition necessary.
“Linear sRGB” gets used sometimes, and what it means is that a color was converted from sRGB into linear. So the space is actually just linear. It’s useful to know if a color came from sRGB sometimes, because there’s less worry about going back into sRGB if you know it came from sRGB originally, and it helps you understand something about the scale and brightness of your linear values. If you have linear values and don’t know where they came from, you have no point of reference, and no idea if a value of 0.1 means invisible black, blinding white, or just middle gray. But unless I scale the linear colors, I do know a linear sRGB value of 0.1 is a dark gray that’s visible, because I know that the range of color is approximately [0..1] because it came from sRGB.
- mncharity 4y ago> You probably didn’t set your light or color intensities in three.js using physical units in the first place, Nod... unless you're using a color space, like Jzazbz, with an absolute (not relative) transfer function. Application context then motivates the nit pick. So a Jzazbz HDR of [0..10k], might get a daylight 1k nits picked for diffuse (non-highlight) white. Thus I appreciate it when color libraries provide a distinct Absolute XYZ D65 data type.
- dahart 4y agoThis is a good point! Jzazbz is a good example of the (somewhat rare) application of perceptual response functions in high dynamic range. I’d be curious to hear what reasons you have to use Jzazbz. The color space seems best at scenarios where you need to compute HDR color differences. Most people don’t need that, but some advanced users like you do. Worth noting in this context that Jzazbz is non-linear, and even though it’s HDR, it still requires conversion to a linear space in order to blend colors physically. I want to elaborate just slightly on what I meant. In CG, like in real photography, the photographer almost always sets some combination of their exposure, aperture size, and/or white balance values manually, regardless of how well they’re controlling inputs and color spaces. As a simple example, I can always dim the lights by a factor of 2 power, and also either expose for twice as long, or open my shutter by one f-stop. When I dim lights by half and expose by double, then nothing about the image changes. Even if you know the physical luminosity of your lights, the overall process (usually) still cancels scale factors and at the end reduces to an arbitrary scaling that essentially sets the output white and output black to the brightest and darkest colors I want to show, respectively. With real film, there are additional arbitrary scaling values like the film development process, and lighting conditions when viewing. With digital, the display’s scaling is frequently unknown, and thus arbitrary; you might use 1k nits for your daylight diffuse, but that’s not what your monitor actually shows you. There are legit use-cases for wanting absolute physical values in the intermediate stages, and using a “linear” color space for blending is, in a way, emulating exactly that desire but still with an arbitrary scale because the input brightness and/or output brightness are being tuned by hand.
- mncharity 4y ago> I’d be curious to hear what reasons you have to use Jzazbz I needed a color space for teaching, so I'm using it to kludge wide-gamut hue linearity onto CAM16UCS. I wish I knew of something better to do. Backstory is, I've long struggled to find community of interested and discussion, around the idea of transformatively improving science education content by collaboratively applying vastly greater-than-usual domain expertise. I thought to troll with a worked example, and chose "color". Even though "I'm building hard thing solo, because I really don't want to build such things solo?!?"... sigh. Color is pervasively taught in early primary, but with such poor content and outcomes, that foundational confusion persists even among first-tier physical-sciences graduate students. So: might color be taught more clearly by emphasizing spectra, in early primary? With web interactives? It seemed a question to explore. So I needed a perceptual color space optimized for learning color. A rather different objective than usually drives color space design. Computability doesn't matter, as small lookup tables suffice. But noticeable features from eyeballing the space should be "yes, that's color perception", not "oh, no, that's an artifact of the model - try to ignore that aspect". The usual art/science education "one part careful, nine+ parts misleading bogosity" just doesn't end well. CAM16UCS is generally good at avoiding "that... doesn't look plausible". Better than other UCSs I skimmed. But... hue gets curvy near its edges, especially badly in blue. Jzazbz regrettably fails the "space looks plausible" test, but is wide-gamut, and has nice hue linearity. So I'm using it to kludge greater linearity onto CAM16UCS, between sRGB gamut and visible boundary. Which aids understandably coupling space to spectra. Getting from daylight to banana to spectra and apparent spectra and color space, provides a lot of opportunity to get things wrong. And from interactive draw-a-spectra. Swapping in Jzazbz for end-to-end HDR physical units provides the warm fuzzy of sanity check. Thus three.js intensities in nits, and an opportunity for Sunday punning. It's just a silly niche use case, rather than advanced use, but modulo burn out, I'll be back at it tomorrow. Also... there's an order-of-magnitude luminance "why don't you see a sky full of stars" interactive somewhere on my infinite todo list, so getting perceptual luminace right had additional motivation. Though that will have to handle meso and scotopic perception... sigh. Appreciated your comments.