Content Type Api & LUT file defined in HyperHDR Settings? (Piccap / Flatbuffers)

[Dak0r]

Hi,
so recently switched from a USB Grabber to Piccap on a rooted LG TV.
It's working great, though for perfect results, I have to apply different LUTs for SDR and HDR/DV.

I see in v19 an option for this was introduced to the JSON Api:
{ "command":"videomodehdr", "HDR":1, "flatbuffers_user_lut_filename":"sdr_lut.3d" }

It's currently not being used by Piccap, so I cloned the project and added support for it. I considered making a PR, though, with the Api call mentioned above, I had to hard-code the LUT filenames in Piccap (sdr_lut_lin_tables.3d and hdr_lut_lin_tables.3d). It works, but feels hacky.

Now, I feel like these settings should rather be part of the user's HyperHDR config and Piccap (or possibly future USB grabbers, too) is just telling HyperHDR the type of content that is being displayed. I think ideally it's all in HyperHDR and Piccap is not controlling the tone mapping directly at all.

Like:

{
  "command":"videomodehdr",
  "contenttype":"sdr"
}

With contenttype being one of: sdr, hdr, dolbyvision.

As a first iteration, the LUT names could then be hard-coded in HyperHDR, like:

• If the content type changes to 'dolbyvision' and tone mapping is enabled and dolbyvision_lut_lin_tables.3d exists,
  • use custom LUT instead of the default one (same for sdr and hdr).

In the future (maybe once there's a way to detect the content type with USB grabbers), a UI could be added to define different options per content type. But I'd keep it simple for now.

It was just an idea I had, so I wanted to hear some more opinions, before I'm spending any time looking into it.
What do you think?

[awawa-dev]

Hi
Thanks for the idea. thanks to the ingenuity of the community, HyperHDR was first introduced to Dolby Vision on webOS, due to the fact that it is a closed format that can only be accessed on occasions like this where root access was possible. However, from what I see, the LUT was adapted to also improve the quality of the captured video even for this format. I'm open to some solution, although as you noticed HyperHDR only provides an HDR LUT (HDR10) for grabbers. At some level, the state had to be translated into a hard file name.

However, I am slowly getting to the point where the module responsible for managing LUTs in memory would be separated as a single instance, because now it is implemented: one in flatbuffer/protobuffer, 3x grabbers for Windows/Linux/macOS (mostly unified) and, additionally, we also have a DirectX grabber and such new functionality for switching LUTs would have to be implemented at the same time in many fragments of code, which is neither pleasant nor correct, and would have to be rewritten later anyway. However, when refactoring the LUT module, I will keep your suggestion in mind.