Interest in SDR<->HDR tonemapping inputs

[FCLC]

Any interest in commands for SDR<->HDR tonemapping?

There's versions for vulkan, oneapi, cuda, OpenCL, and CPU

[zeh]

For sure!

I'll do more research once I'm ready for more complex recipes (after #1 is done) but in the meantime, any material or suggestions would be welcomed.

[FCLC]

Sounds good!

For tone mapping you'd need to filter inputs for:

Windows vs macos vs linux

Then if linux filter GPU vs CPU

Then if GPU, vendor=[intel, AMD, nvidia, other]

From there you have a few sub cases, such as dealing with HDR, HDR10 or Dolbivision

and you also have things like HW encoded pipelines.

For example, on the RPI4 you can decode in HW, but don't have many/any GPU accelerated filters (AFAIK)

[FCLC]

more information: it seems like FFMPEG.wasm doesn't support the full subset of ffmpeg libraries or features.

https://ffmpegwasm.netlify.app/docs/overview#libraries

It may be possible to get this working CPU only while (web)GPU support is added to ffmpeg.wasm

Typically a common CPU HDR tonemapping pipeline is ffmpeg -i INPUT -vf zscale=transfer=linear,tonemap=clip,zscale=transfer=bt709,format=yuv420p OUTPUT

That should work since Zscale is part of zlib, which is supported?

[zeh]

Yeah, compiling FFmpeg (the project) is an adventure and concessions have to be made for wasm I'm sure.

I haven't looked much into it, but it's seeing highly likely I'll have to recompile it myself (forking current wasm version probably), considering I'll likely need tweaks to memory handling on mobile too. I can investigate using other libs there.

Other random things that come to mind, for the future:

• At some point I want to expose ffmpeg info (e.g. ffmpeg -encoders, ffmpeg -codecs) so it's clear to power users what's being used and we don't have to rely on the docs
• We might have our own platform-specific issues since I'm not sure we get the full power of gpu encoding/decoding from the wasm version (we're a bit restricted)