Tonemapping HDR to SDR with libplacebo

[ggarra13]

I am investigating using libplacebo for tonemapping HDR to SDR, as it seems the most capable library.
However, I need to integrate it with a custom pipeline using OpenColorIO and OpenGL.
Is there any way to output the shader code created by libplacebo into its own function (or to see what it does behind the scenes for debugging), like in OpenColorIO, so that my OpenGL wrapper code calls (in pseudo code):

// to convert from ocio's input space to linear space
outColor = ocioICS(outColor);

// do further color corrections on outColor like exposure/tint/contrast/etc..

// Operate libplacebo on linear space
if (toneMapEnabled)
{
   outColor = libplacebo_tonemapHDR(outColor);
}
// Take the resulting HDR tonemap colors to the OCIO Display (Usually Rec709 or sRGB)
outColor = ocioDisplayView(outColor);

?

[haasn]

Yes, this is supported. If you want to fully debug/dump the generated shaders, the most flexible way to do this is:

1. Create a dummy pl_gpu using <libplacebo/dummy.h>
2. Allocate a pl_shader object using pl_shader_alloc, passing the pl_gpu you created in step 1
3. Call pl_shader_color_map_ex on this shader object.
4. Finalize the shader with pl_shader_finalize when you are done.

The resulting pl_shader_res contains the GLSL function text in const char *glsl, callable with const char *name, alongside a list of all descriptors you will need to make available (with the given names). You can unpack the texture data with pl_buf_dummy_data.

Of course, for best results, you'll also want to run a separate HDR signal analysis pass using pl_shader_detect_peak, and optionally a HDR feature extraction pass.

Edit: Of course, I should point out, that if you're already using OpenGL, and you're comfortable with having libplacebo call into your GL context directly, you can vastly simplify the process of mapping all textures etc by just using a pl_gpu object created by pl_opengl_create. Then you can just pl_opengl_unwrap them and get your already-uploaded OpenGL texture objects ready to be used. This is what VLC does internally to do tone-mapping via libplacebo.

[ggarra13]

Can you explain to me how to get and pass the LUT textures into opengl from libplacebo when the pl_shader_color_map_ex()'s pl_color_map_args' state is set and the tone mapping function is pl_tone_map_spline or similar? It seems it creates some LUTs, but I cannot figure how to add them to my code or how to pass them on to the GL backend.

If you have sample or test code that you can point me to, it would be ideal. I apologyze for my dumb questions, but I am still new to libplacebo's great API. You should be really proud of yourself @haasn! You created a marvelous library!

[ggarra13]

Never mind. I figured it out by myself. I had to use the pl_tex* functions to extract the LUT data.

[wyup]

I have some questions:

Why does libplacebo bt2446a seem to use MaxDML instead of MaxCLL for default tone mapping upper limit? In my opinion it should use MaxCLL because that is the highest luminance limit of the content, MaxDML is not used so it reduces the effective tone mapping performance for a range that is not used.

Why does libplacebo use 203.0 nits by default for max limit for SDR tonemapping instead of standard 100 nits? Maybe it works better, but I have the doubt... Is it because it takes 0.2023 nits as minimum limit for SDR aswell? 203/0,2023 = ~ 100 units of dynamic range..

What default values does color_map_preset=high_quality change?

Thank you for this wonderful library.

[haasn]

Especially if it is done selectively as you request. For example if input mastering luminance would be an option, that this mean pl_options should also include input dimensions, input chroma location, input deinterlacing, input field order and all other input frames metadata?

That is my plan. I think we can support it pretty easily because pl_renderer already makes a copy of the pl_frame struct and applies overrides. If anything, I think this will make it easier for users to get predictable behavior, e.g. mpv could directly map the --target-* options to pl_options, and we could move the supporting logic there. (e.g. options like target_contrast, target_gamut, or even dither_depth).

[kasper93]

I don't see why libplacebo suddenly should include user application logic.

[haasn]

Well, in this case the benefit would mainly being able to share that logic between FFmpeg and libplacebo.

But maybe you're right, and we should just add this to vf_libplacebo directly.

[kasper93]

I see why you propose it. pl_options already maps to pl_render_params, not sure though it should really map to pl_frame and pl_target_frame with additional logic. It sound to me like something a caller should take care about, but if you feel like it. I would rather keep libplacebo scope limited.

[wyup]

Well, it looks libplacebo actually exposes those parameters since QSVEnc already implements them. It's only a matter for ffmpeg's vf_libplacebo to add them via its tonemapping_param. You shouldn't touch the input source container tags or hevc_metadata bsf.

I don't know what you mean with pl_options.