HDR→SDR Tone Mapping in Emby Is Technically Inferior and Inconsistent (vs Jellyfin)

[Encho 1]

I’m running Emby and Jellyfin side by side on the same hardware (Intel Arc A380), and the difference in HDR→SDR tone mapping is frankly embarrassing for paid software.

In Emby, the available tone-mapping algorithms are mostly legacy filmic curves (Hable, Mobius, Reinhard). These are scene-referred approximations and are fundamentally wrong for PQ display-referred HDR video. The only algorithm that actually preserves highlight intent and midtones correctly is BT.2390 — which Jellyfin exposes cleanly and consistently.

In Emby:

• BT.2390 is missing, hidden, or conditionally exposed depending on:

  hardware vs software path

  ffmpeg build

  client UI

• Hardware tone mapping actively removes correct options

• The UI gives no indication which path is active or why options disappear

• Behavior varies between users with the same “version”

In Jellyfin:

• BT.2390 is available

• CPU usage does not spike noticeably

• Output is stable, predictable, and standards-compliant

I’m a VFX artist working with color grading daily. I deal with PQ, SDR transforms, and reference behavior professionally. BT.2390 is not a “preference” — it’s the correct algorithm for HDR→SDR. The difference is immediately visible.

All of the above — silent beta enrollment, opaque behavior, broken tone-mapping choices — is unacceptable for paid software, especially when a free alternative implements this correctly.

Emby needs:

• Clear separation of decode vs tone-mapping paths

• Proper exposure of BT.2390

• Transparency in the UI

• Standards-based defaults, not filmic hacks

Right now, Jellyfin is technically ahead where it matters most.

All of this is unacceptable for paid software, especially when compared to free software.

[RanmaCanada 494]

To be fair, no one should be tone mapping, EVER.

[ebr 16168]

@softworkz

[Reaper47 11]

@EnchoI'm not exactly sure what you mean by "paths". I personally find tonemapping config page to be quite clear - once you enable hardware transcoding you get to configure it. Once you enable software transcoding, separate settings for it appear. Only thing that might be a little unclear is whether it is possible to use software tonemapping even if transcoding itself is done by hardware, but I thint it isn't. Also not sure what you mean by "Behavior varies between users with the same version" and CPU usage spikes. As someone who was using Jellyfin before recently getting Emby Premiere (still running it in parallel), I actually find Emby to be very easy in setup. I simply installed it in Docker, activated Premiere, enabled tonemapping and everything works well so far.

Now what I will agree with you on, is that Jellyfin offers much more options to tweak tonemapping parameters, as well as has more algorithms to choose from, including BT.2390 in hardware. So you should be able to fine tune tonemapping quality in Jellyfin more than Emby, if you know what you are doing. I personally would like if those other algorithms and advanced settings were added to Emby.

I like how Emby did it with transcoding settings. There is separate "advanced" setting that lets you configure decoders and encoders. Both hardware and software encoders can be further configured by clicking the "gear" symbol. There is a clear disclaimer that those settings shouldn't generally be changed and there is "return to defaults" option. This way the settings page isn't messy or confusing and there is little risk people without knowledge accidentally mess something up. Even when they decide to play around with advanced settings, thay can always easily revert to defaults. More advanced users get the benefit of fine-tuning settings for their liking. It would be great if such thing was added for tonemapping page, as well as some other aspects (for e.g advanced audio transcoding settings would be nice).

@RanmaCanadaWhile you are generally right  (it is always better to play HDR mastered content on HDR screen and vice versa with SDR) it simply isn't always an option. For e.g my main screen is HDR so I mostle get my content in HDR. Not every UHD bluray contains SDR bluray copy. Plus, I'm currently limited in disk space, so I would have to keep 2 copies for many movies, which becomes problematic the bigger my library gets. So if there is room to improve tonemapping, I'm all for it, even if there isn't anything really wrong with it right now.

 

 

 

Edited January 5 by Reaper47

[softworkz 5065]

@Encho

First of all - what's not right is "depending on ffmpeg build". We are using the same ffmpeg build for almost 3 years now. There have been only three minimal patches since then, none of them being about tone mapping. 

This also explains the remainder of your findings: While we've been ahead of the competition like 3-4 years ago - we are clearly behind right now. As a consequence of a number of unfortunate decisions, there have been focus changes, including myself, and we fell behind.

In the area of tone mapping - especially open-source implementations thereof - there have been substantial advances during the past years. Our FFmpeg is from 2023, which means that our tone mapping capabilities are reflecting what has been possible and available at that point - that's the simple truth. BT.2390 hasn't been implemented everywhere, so we could only offer it for selection where available.

This:

On 1/2/2026 at 4:59 PM, Encho said:

Emby needs:

• Clear separation of decode vs tone-mapping paths

...is one of the things which doesn't make any sense. 

What needs to be understood beforehand is why so many different tone mapping implementations exist: Because video processing operations can become quite expensive easily - which is why you always try to do it in the most efficient way that is available to save resources for processing more streams in parallel or other things.
Video processing requires memory and compute power and the latter should always have direct access to the former. Means: system memory for CPU-based processing or GPU memory for GPU processing. What you want to avoid by all means here - as long as possible - is changing from one to the other in a single transcoding pipeline, because memory transfer (which is then about uncompressed frames) is expensive. That's why you don't want anything like a "Clear separation of decode vs tone-mapping paths" but rather the opposite: When you are running on an Nvidia GPU, you want to use Nvidia CUDA based tone mapping, when doing sw transcoding, you do sw tone mapping - plus there a vendor-independent subsystems like OpenCL or Vulkan, where other tone mapping implementations might be available and which you might prefer in certain cases.

The bottom line is: there are many different implementations and all have different options and capabilities. Meanwhile, these have become more consistent than in 2023 and that's the reason for the discrepancies you are seeing.

Now for the individual points:

On 1/2/2026 at 4:59 PM, Encho said:

In Emby:

• BT.2390 is missing, hidden, or conditionally exposed depending on:

  hardware vs software path

Actually, depending on which hardware path or whether sw.

 

On 1/2/2026 at 4:59 PM, Encho said:

• BT.2390 is missing, hidden, or conditionally exposed depending on:

  ffmpeg build

No, that's always the same.

 

On 1/2/2026 at 4:59 PM, Encho said:

• BT.2390 is missing, hidden, or conditionally exposed depending on:

  client UI

No. This doesn't affect how server transcoding is done.
Though, what makes a change of course, is when the client is direct playing without server transcoding, then it's the client settings which are controlling tone mapping.

 

On 1/2/2026 at 4:59 PM, Encho said:

• Hardware tone mapping actively removes correct options

No. It doesn't remove anything. It always offers what is available - only.

 

On 1/2/2026 at 4:59 PM, Encho said:

• The UI gives no indication which path is active or why options disappear

When you install the Diagnostics Plugin, you get a "User Sessions" view on the Server Dashboard, which shows exactly and graphically what's happening:

 

 

 

On 1/2/2026 at 4:59 PM, Encho said:

• Behavior varies between users with the same “version”

No idea what that means.

 

On 1/2/2026 at 4:59 PM, Encho said:

BT.2390 is not a “preference” — it’s the correct algorithm for HDR→SDR. The difference is immediately visible.

No doubt, even though users often consider it "too dark".

 

Edited January 6 by softworkz

[Reaper47 11]

@softworkzThanky you for explaining. Is there any chance we get advanced settings for tonemapping (such as tuning tonemapping parameter etc) and possibly more algorithms in future updates? Somwhere in the forum I saw that new ffmpeg build is being worked on, is there any chance it includes those?

[softworkz 5065]

2 minutes ago, Reaper47 said:

Is there any chance we get advanced settings for tonemapping (such as tuning tonemapping parameter etc)

When we introduced all the tone mapping stuff a few years ago, we started with a small group of testers for gathering feedback. We also had exposed TonemapParameter
and DesaturationStrength (OpeCL/VAAPI/QSV, CUDA and CPU) as options but there was little interest at that time so we hid it for simplicity and not to overwhelm users with tons of parameters.

These are all still there, just commented away. Could be quickly re-enabled, in the UI hidden by an "Advanced" toogle.

Not sure what @Lukethings about it...

 

19 minutes ago, Reaper47 said:

and possibly more algorithms in future updates? Somwhere in the forum I saw that new ffmpeg build is being worked on, is there any chance it includes those?

Maybe not every single parameter but algorithms for sure, there wouldn't be much point in updating without making use of the added features.  

 

[Reaper47 11]

28 minutes ago, softworkz said:

These are all still there, just commented away. Could be quickly re-enabled, in the UI hidden by an "Advanced" toogle.

I think that would be great, just as it is now with configuring encoders. Best of both worlds, the main page would still be simple and understandable for everybody, but users could still access these settings. Even if there were little interest, I think quite a few users would be happy and find it useful (me included ).

34 minutes ago, softworkz said:

Maybe not every single parameter but algorithms for sure, there wouldn't be much point in updating without making use of the added features.  

Nice to hear this, looking forward to this update. 2026 is looking really exciting for Emby's future 

[softworkz 5065]

1 hour ago, Reaper47 said:

I think that would be great, just as it is now with configuring encoders.

Uhm, that's a bad example - it took me three years to get it into the UI (developed in Jan 2020, added to the beta in May 2023 - that's innovation on the fast lane)  

[Reaper47 11]

Okay then, so I guess it's better to just keep it as a simple "advanced" toggle