Unacceptable lack of tone mapping config

[EatPrilosec 22]

at the risk of sounding rude, or like a karen/kevin, I'm going to be frank, this is now unacceptable.

a few years ago, this could be ignored. but if this isnt resolved in a few months, and i cant write a pugin to fix it, this organization going to be 5 bucks a month poorer

unless you can tell me how one fixes this?  but my instincts say "thats the neat thing; you dont!"

none of the three whole entire tone map options we have do anything close to something watchable for me.

I'm literally paying for color saturation, banding, and artifacts, while two free options can do this well

this MUST be addressed. 

And as a monthly paying customer for more than half a decade, the $500 of my money you have should get me more than this.

I feel i deserve an explanation for why it hasn't been addressed, and an eta for when it will be addressed.

i am a developer, i understand it takes time, testing, but the deadline is near, if not here.

[vdatanet 1656]

Before anyone can say whether this is a bug, a config issue, or a genuine gap, it would help a lot to know exactly what you're running. Could you post:

**Hardware / host**
- CPU and GPU (exact model — e.g. i5-12500 with UHD 770, or GTX 1660, or an AMD APU)
- OS, and whether Emby is bare metal, Docker, or a NAS package

**Emby config**
- Emby Server version
- Which hardware acceleration backend you have selected (QSV, NVENC, VA-API, AMF, none)
- Which tone mapping option you're using, and the values you have for the tone mapping parameters if you've touched them
- A transcode log from one of the bad playbacks — that shows the exact filter chain being built, which is the single most useful thing here

**Source and client**
- Is the source HDR10, HLG, or Dolby Vision? If DV, which profile? Profile 5 in particular has no usable HDR10 base layer, and washed-out or oversaturated output on that is expected behaviour rather than a tone mapping quality problem
- Bit depth and codec of the file
- Which client and device, and whether it's transcoding because of bandwidth, codec, or subtitle burn-in

With the transcode log and the source details, it should be fairly quick to tell whether you're hitting a known limitation, a missing runtime, or something worth filing.

[EatPrilosec 22]

i can configure jellyfin or vlc's (or haruna, or mpv) tone mapping to look like emby, but i cannot configure emby to look like i want it, unless im missing something in the form of custom parameters in an xml or something which ill gladly use.

server is an intel N100, debian, docker.emby version: 4.9.5.0.

backend is set as QSV, the lack of configuration options affects both qsv and vaapi based tone mapping settings,

i have not tried software tone mapping as it probably wont work with this size file on this dual core n100

i am using the extraT opencl for both qsv and vaapi, and the only paramater, singular, it has is an option to chose reinhard, mobius, or hable with a notable lack of, at the very least one option, BT.2390. and others include, linear, clip, gamma. the latter 3, I can see why the choice would be made to exclude them

transcode log is attached

source:
 

Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5.1@High
HDR format                               : Dolby Vision, Version 1.0, Profile 7.6, dvhe.07.06, BL+EL+RPU, no metadata compression, Blu-ray compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 3 h 35 min
Bit rate                                 : 48.9 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0 (Type 2)
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.246
Stream size                              : 73.6 GiB (91%)
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0001 cd/m2, max: 1000 cd/m2
Original source medium                   : Blu-ray

client was brave browser. transcoding because i set it to 4k 40mbps while testing configuration. but it looks wrong no matter why its being transcoded, or what device. 

ffmpeg-transcode-be75700c-e23c-4c08-9414-fab05eae32f3_1.txt

[vdatanet 1656]

Your hardware path is fine. The chain is hevc_qsv → vpp_qsv → hwmap to OpenCL → tonemap_opencl → hwmap back to QSV, running at 77 fps / 3.2x on an Alder Lake-N. No OpenCL device-derive failure, no software fallback. So this isn't the 4.9.3-era regression a lot of people hit. Your GPU is doing the work; you just don't like the result.

Which brings me to the part I think is the real answer to your question. You said none of the three tone map options is watchable. That's expected: the three options only swap the curve — hable, mobius, reinhard. Everything that's actually hurting you — 8-bit output, no dither, desat disabled, unknown peak — is identical across all three. Changing the setting cannot fix any of your three symptoms, which is why it feels like there's no fix.

[EatPrilosec 22]

9 minutes ago, vdatanet said:

which is why it feels like there's no fix.

the BT.2390 algorithm would be my preferred "fix" or preference for algorithm (not curve, "linear" is a n algorithm and is by definition not a curve) is and i am lacking that option. the fix would be to provide that option, as it is literally the industry standard for tone mapping color accuracy.

it would also be nice to have other parameters, but literally lacking an option for the industry standard for color mapping is unacceptable as a paying customer. again, unless i can set this in an xml somewhere, it must be addressed

Edited 13 minutes ago by EatPrilosec