Feature Request: Explicit inverse tone-mapping in --vpp-colorspace filter (SDR to HDR)

[ghost]

When doing straight conversion from an SDR colorspace like Rec. 709 to HDR10 / smpte2084, levels are left as SDR levels; analysis of the output indicates a MaxCLL of around 100... this is expected / correct. The problem is there's no well defined way of doing an inverse tone-map to a wider range. After reading the code (and finding some mentions of inverse mappings but no explicit way of activating them), I noticed that Hable's math works out in either direction so I tried and I've found that the following works to produce something with a rough peak around 1000

--vpp-colorspace matrix=bt709:bt2020nc,colorprim=bt709:bt2020,transfer=bt709:smpte2084,range=limited:limited,hdr2sdr=hable,source_peak=100.0,ldr_nits=1000.0

But this is basically a hack and Hable was never meant for this operation, it just happens to handle the inverted parameters and produce something that doesn't look all that bad... Mobius just crashes. :D

A better way would be to make available a specific inverse tonemap option with suitable algorithms and the need to specify only a peak (SDR input peak would be assumed). Libplacebo has bt.2446a, linear, and spline as options for inverse mapping... linear doesn't seem particularly useful as it's just a dumb scaling but either of the others (preferably bt.2446a since it's more or less official) would be wonderful. :D The libplacebo/tone_mapping.c version of bt.2446a probably works as OpenCL code without much change, except maybe to use half precision, unless I've forgotten something.

Pretty much all of my encoding is SDR -> HDR, and for things that don't need x265's increased quality, I can GPU encode at low CQP... if I have to do the color conversions in ffmpeg via zscale which allows a nominal peak level to be specified, I encode at ~100fps. If I abuse hable and avoid ffmpeg it's 400fps, so you can see why I'd want to avoid doing the color processing in ffmpeg at all... :D