Tonemapping for previews

[caffeineshock 18]

Is it possible to generate preview images of HDR content with correct tone mapping?

I'm currently working with HDR video recordings (in this case, gameplay footage captured in HDR), and I'm noticing that the generated preview thumbnails don't reflect the proper tone-mapped look—they appear either washed out or incorrectly exposed.

I've attached example screenshots showing the difference between the preview image and the actual video playback.

This issue doesn’t seem limited to just game captures—I've seen similar problems with other HDR sources as well.

For reference, my system is capable of hardware tone mapping (RTX 3070).
Is there a way to ensure that previews are generated with the correct tone mapping applied?

Thanks in advance!

 

[rbjtech 5284]

From memory, the preview images use a 'quick' version of tonemapping to speed up the process as it's very intensive when properly tonemapping every image.   It used to use some type of gamma/colour correction that was even quicker (but looked poor), but tonemapping was added and tbh, I've been ok with the result.

 

Prior to this, I added tonemapping to the bif creation myself via a script - to note, the MediaInfo plugin also has that same ffmpeg code/syntax under the BIF Generator tab.  That does the full tonemapping which may produce better results - but test first as I haven't looked at that code in a long time since it got updated in the Core.

Adding @softworkzwho added it - he may be able to provide further info.

btw - it's also worth added the generated preview log file - as that will show the ffmpeg syntax used.   It may simply be that the tonemapping algorithm default (hable) does not work well with the game graphics output, but others are available.  (the plugin allowed you to change it) 

Edited April 7, 2025 by rbjtech

[caffeineshock 18]

Alright, issue resolved.

Turns out the problem was caused by the tone mapping algorithm selected in the transcoding settings

I switched it from Hable to Mobius (both for software and CUDA), and just like that — problem gone

From what I’ve read, Mobius is slightly slower than Hable, but with an RTX 3070, performance isn’t an issue at all

(This  is the new thumbnail)

Edited April 8, 2025 by caffeineshock

[softworkz 5066]

14 hours ago, rbjtech said:

From memory, the preview images use a 'quick' version of tonemapping to speed up the process as it's very intensive when properly tonemapping every image.   It used to use some type of gamma/colour correction that was even quicker (but looked poor), but tonemapping was added and tbh, I've been ok with the result.

That's correct. That simple color boost was an interim solution. Meanwhile we use software tone mapping - including the parameters that are set under Transcoding >> Tone Mapping >> Software.

The requirements are:

• The ffmpeg version being used, includes the 'supertonemap' filter
• In the Diganostics plugin, DisableTonemappedExtraction is not checked

otherwise it would fall back to the contrast/gamma/saturation method.

[caffeineshock 18]

the thumbnails are software-tonemapped?

[softworkz 5066]

1 hour ago, caffeineshock said:

the thumbnails are software-tonemapped?

Correct. The whole thumbnail extraction process doesn't use hw acceleration because it wouldn't really benefit from it. SW tone mapping is normally expensive but there's a quadratic relation between computational cost and image size. Thumbnail images are small and - of course - scaled down _before_ tone mapping.