Skip to content

tone_mapping: completely refactor tone mapping

Niklas Haas requested to merge tone_mapping_v2 into master

I was very unsatisfied with the old tone-mapping approach for a number of reasons:

  1. The requirement for all tone-mapping functions to be pure GLSL was very restrictive and made it so we had to start worrying about GPU performance.

  2. For the more complicated functions, using a LUT is vastly better. Using a LUT also opens us up to using more complicated functions overall, like piecewise splines, including exact inverses of other tone mapping functions, or functions based on dynamic metadata.

  3. Having this be an open-ended API in theory allows users to define custom tone mapping functions (e.g. perhaps one based on extra frame metadata).

I will probably still include GLSL fast paths for tone-mapping functions that are faster to implement in pure GLSL, but for now I plan on switching entirely to a LUT-based approach.

The major downside of this approach is that it doesn't afford us the ability to combine this style of tone-mapping with peak detection, but I'm unsatisfied with the complexity of peak detection overall so I'm not sure this is a huge loss in practice.

One way we could salvage the situation is by always using the detected peak merely to (linearly) adjust the output of the LUT, e.g. something like sdr = lut(hdr) / lut(peak).

Edited by Niklas Haas

Merge request reports

VideoLAN code repository instance