HLG stands for Hybrid Log-Gamma, and the name describes exactly what it does: for darker signal values it behaves like a familiar gamma curve (compatible-ish with how SDR already works), and above a certain point it switches to a logarithmic curve that extends into HDR headroom. It was developed by the BBC and NHK specifically for live broadcast, where you can't always guarantee every downstream device understands HDR metadata.
Relative, not absolute — the opposite of PQ
This is the core difference from PQ. PQ is absolute: a code value means a specific number of nits, everywhere. HLG is scene-referred and relative — what a given signal value actually displays at depends on the system gamma applied at render time, which itself depends on the display's peak brightness. The tradeoff: HLG needs no extra metadata to produce a reasonable image on an SDR screen (it just looks like a slightly different gamma curve), while PQ needs a capable display to interpret its absolute values correctly at all.
Where it shows up
HLG is common in broadcast and streaming contexts — live sports, some streaming platforms, camera HDR modes on phones that prioritize broadcast compatibility. It's paired with Rec.2020 color primaries in the full Rec.2100 HDR TV standard, the same way PQ is.
Where we stand with it
We implemented and validated the HLG math (OETF, inverse OETF, and the OOTF that maps scene light to display light) on its own — deliberately not merged with the PQ code, since mixing an absolute and a relative transfer function in one code path would hide a real difference between them. That said, we haven't built HLG into the actual encoder or inspector yet: the gain-map JPEG path our Encode tool uses doesn't need it, and confirming real HLG rendering support needs more browser-level verification than we've completed so far. We'd rather say that plainly than claim support we haven't proven.