5 ms·
More bits to store more color/brightness etc makes sense. I think my main confusion has usually been that it all feels like some kind of a… hack? Suppose I set
by radicality 2y ago
More bits to store more color/brightness etc makes sense.
I think my main confusion has usually been that it all feels like some kind of a… hack?
Suppose I set my macbook screen to max brightness, and then open up a normal “white” png. Looks fine, and you would think “well, the display is at max brightness, and the png is filled with white”, so a fair conclusion would be thats the whitest/brightest that screen goes. But then you open another png but of a more special “whiter white”, and suddenly you see your screen actually can go brighter! So you get thoughts like “why is this white brighter”, “how do I trigger it”, “what are the actual limits of my screen”, “is this all some separate hacky code path”, “how come I only see it in images/videos, and not UI elements”, “is it possible to make a native Mac ui with that brightness”.
In any case, thanks for the answer. I might be overthinking it and there’s probably lots of historical/legacy reasons for the way things are with hdr.
- wongarsu 2y ago> there’s probably lots of historical/legacy reasons for the way things are with hdr That's pretty much it. If you use a HDR TV it will usually work like you describe. It would display the same white for a normal white PNG and an "even whiter" "HDR" PNG. Apple's decision makes sense if you imagine SDR (so not-HDR) images as HDR images clipped to to some SDR range in the middle of the HDR range (leading to lots of over- and underexposure in the SDR image). If you then show them side-by-side of course the whitest white in the HDR range is whiter than the whitest white in the SDR image. Of course that's a crude simplification of how images work, but it makes for a great demo: HDR images really pop and look visually better. If you stretched everything to the same brightness range the HDR images wouldn't be nearly as impressive, just more detail and less color banding. The marketing people wouldn't like that
- crazygringo 2y agoIt is all extremely hacky. Because HDR allows us to encode brightnesses that virtually no consumer displays can display. And so deciding how to display those on any given display, on a given OS, in a given app, is making whatever "hacky" and totally non-standardized tradeoffs the display+OS+app decide to make. And they're all different. It's a complete mess. I'm strongly of the opinion that HDR made a fundamental mistake in trying to design for "ideal" hardware that nobody has, and then leaving "degraded" operation to be implementation-specific. It's a complete design failure that playing HDR content on different apps/devices results in output that is often too dark and often has a telltale green tint. It's ironic that in practice, something meant to enable higher brightness and greater color accuracy has resulted in darker images and color that varies from slightly wrong to totally wrong.
- duskwuff 2y ago> So you get thoughts like [...] “what are the actual limits of my screen” [...] Some of the limitations, at least in Apple's displays, are thermal! The backlight cannot run at full brightness continuously across the full display; it can only hit its peak brightness (1600 nits) in a small area, or for a short time.
- suzumer 2y agoWhile one commenter had it somewhat right that HDR has to do with how bright/dark an image can be, the main thing HDR images specify is how far ABOVE reference white you can display. With srgb, 100 percent of all channels is 100 percent white (brightness of a perfect lambertian reflector). Rec 2100 together with rec 2408 specify modern hdr encoding, where 203 nits is 100 percebt white, and above that would be anything brighter (light sources, specular reflection, etc). So if a white image encoded in sdr looks dimmer than hdr for non specular detail, that is probably encoding or decoding error.
- dahart 2y agoOne motivation for HDR is having absolute physical units, such as luminance in candelas per square meter. You can imagine that might be a floating point value and that 8 bits per channel might not be enough. The problem you’re describing is that color brightness is relative, but if you want physical units and you have a calibrated display then adjusting your brightness is not allowed, because it would break the calibration. Another reason for HDR is to allow you to change the “exposure” of an image. Imagine you take a photo of the sun with a camera. It clips to white. Most of the time even the whole sky clips to white, and clouds too. With a film camera, once the film is exposed, that’s it. You can’t see the sun or clouds because they got clamped to white. But what if you had a special camera that could see any color value, bright or dark, and you could decide later which parts are white and which are black. That’s what HDR gives you - lots of range, and it’s not necessarily all meant to be visible. In computer graphics, this is useful for the same reason - if you render something with path tracing, you don’t want to expose it and throw away information that happens to get clamped to white. You want to save out the physical units and then simulate the exposure part later, so you don’t have to re-render. So that’s all to say- the concept of HDR isn’t hacky at all, it’s closer to physics, but that can make it a bit harder to use and understand. Others have pointed out that productized HDR can be a confusing array of marketing mumbo jumbo, and that’s true, but not because HDR is messed up, that’s just a thing companies tend to do to consumers when dealing with science and technology. I was introduced to HDR image formats in college while studying physically based rendering, and the first HDR image format I remember was Greg Ward’s .hdr format that is clever- 8 bits mantissa per channel and an 8 bit shared exponent, because if, say, green is way brighter than the other channels, you can’t see the dark detail in red & blue.