gamut_mapping: refactor perceptual gamut mapping

Based on a radically new approach of transforming hue leaves into a new bespoke colorspace called "tone saturation hue", which is designed to represent colors in a hue-leaf-relative representation.

Every color with a tone (T) parameter above 0.0 is subjectively brighter than the maximally saturated color of this hue, while every color with a tone below 0.0 is subjectively darker. This means that all colors crossing the T=0.0 plane are basically on the same intensity as the maximally saturated color for that hue.

Similarly, the saturation (S) parameter has been normalized so that S=1.0 always corresponds to the maximally saturated color of that hue leaf. So all of the vertices of the RGB cube have S=1 T=0, with differing values of hue.

This is combined with a simple smoothstep to protect the in-gamut region from being warped, alongside a final RGB softclip pass to combat clipping as a result of differences in the hue leaf shape, resulting in a nice, smooth colorimetric mapping.

Overall represents a major improvement (YMMV).

Supersedes: !497 (closed)

reverse gamut mapping needs more work, it has sharp discontinuities near the blues in some samples I found

added 8 commits

• 3268d57c - shaders/colorspace: add pl_color_amp_params.inverse_gamut_mapping
• 038ce23e - gamut_mapping: fix hue shift margin direction
• d2e8e80f - gamut_mapping: factor out hue shifting code
• 5968ecde - gamut_mapping: safety clamp on desat_bounded()
• 381af5c8 - gamut_mapping: protect against UB in softclip()
• d770bfba - gamut_mapping: refactor perceptual gamut mapping
• f38e9cbf - tests/tone_mapping: increase test accuracy
• 95a58b40 - gamut_mapping: add pl_gamut_map_softclip

Compare with previous version

added inverse_gamut_mapping toggle to avoid stretching gamut out of the box. Though, one thing I'm not happy about, is that this will currently still inverse gamut map in the even that the two gamut boundaries somehow intersect. A more principled approach is needed..

I don't know what to do about this anymore.

I guess we probably want to limit this to only decreasing saturation for now, and removing the bidirectional tag. To be on the safe side.

added 70 commits

• 95a58b40...f54fcf02 - 63 commits from branch videolan:master
• 83aefae7 - gamut_mapping: fix hue shift margin direction
• 02d3024d - gamut_mapping: factor out hue shifting code
• e0057b68 - gamut_mapping: safety clamp on desat_bounded()
• e53e4d7e - gamut_mapping: protect against UB in softclip()
• 6a122de7 - gamut_mapping: refactor perceptual gamut mapping
• 9c545d9f - tests/tone_mapping: increase test accuracy
• 82d56f0e - gamut_mapping: add pl_gamut_map_softclip

Compare with previous version

resolved all threads

I ended up rewriting this to not expand the gamut overly aggressively, which should hopefully help resolve the issues here. Although it also means you can no longer use it to get nice deepfried anime on your wide gamut monitors, I guess saturation still serves that job well enough.

It still slightly distorts colors when using e.g. an ICC profile that has different source primaries, as a result of the hue shifting code. Though I'm inclined to think this is now an intentional effect, or something. YMMV.

Turns out this problem is worse than I thought, making me believe this approach is almost completely unworkable as-is.

closed