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.