[css-color-hdr-1] Limiting "boosted SDR" HDR

[eeeps]

HDR is best used in moderation. Apple's video introducing EDR drives this home: HDR is for specular highlights and emissive surfaces, and should not be used to universally "boost" entire images.

The example in w3c/ColorWeb-CG#78 and my own experience browsing Instagram, make it clear to me that in the crowded attention market of the web, creators will often be incentivized to boost entire images, leading to terrible experiences for users.

I think we should consider features that don't only set a hard limit on the amplitude of the signal (as https://drafts.csswg.org/css-color-hdr/#controlling-dynamic-range does), but do so depending on how widespread HDR values are, within an image. So if a creator has simply boosted SDR white to HDR white, they will get limited in some way; if they only have a few glittering specular highlights, they can get as bright as the display allows.

[svgeesus]

Calculating that sort of luminance histogram analysis on the fly can be expensive, so it is typically pre-computed and stored as static metadata in the image, animation or video. This is how HDR10 does it; the relevant items are

• MaxFALL (maximum frame-average light level)
• MaxCLL (maximum content light level)

PNG recently added this capability, in the Content Light Level (cLLI) chunk.

AVIF also supports HDR10 static metadata and HDR10+ dynamic metadata

The definition of MaxFALL and MaxCLL is in CTA-861.3-A and the method of calculation used in practice is described in

On the Calculation and Usage of HDR Static Content Metadata. Smith, Michael D.; Zink, Michael. Society of Motion Picture and Television Engineers. 2021-08-05.

None of these specifications say how to use that information, so that is where CSS Color HDR could provide guidance.

[jonsneyers]

Relying on metadata provided by the creators themselves does not solve the issue since it is easy to just lie in the metadata.

Computing the average light level might be a bit too computationally expensive to do on the fly in the browser, but something computationally cheaper could be done like counting the fraction of pixels with RGB values above the SDR max value (e.g. above signal value 0.58 in the case of PQ).

Non-malicious HDR images might contain a somewhat larger amount of bright pixels, e.g. for outdoors photos at daytime, it may be desirable to have the sky brighter than SDR white, though probably most of it should still be kept at +1 stop above SDR white or so, not much brighter.

To catch 'malicious' HDR images, maybe a good threshold would be +2 stops above SDR white (or the simpler equivalent of that in individual R,G,B values, e.g. above signal value 0.75 in the case of PQ — even if some of those could be just very saturated but not very bright). The fraction of pixels above +2 stops should be small in any 'reasonable' HDR image, say no more than 2%.

This whole issue feels similar to the issue of audio loudness normalization.