HDR Tone Mapping for Screen Sharing

(#940) Feature Under consideration video

Problem

When sharing a screen that contains HDR content (games on HDR monitors, photo/video editing software, HDR videos, macOS/Windows HDR desktops, etc.), the shared stream often looks washed out, overly bright, or loses shadow/highlight detail. This happens because Fluxer’s current screen sharing pipeline outputs in SDR (Standard Dynamic Range) without any tone mapping to properly compress the wide dynamic range of HDR sources. The result is noticeably worse visual quality compared to the sharer’s own display — especially frustrating for gamers, creators, and anyone with modern HDR hardware.

Proposed solution

Add proper HDR tone mapping to the screen sharing pipeline. -Automatically detect when the shared display/source is HDR-enabled.
  • Apply high-quality tone mapping on the sharer’s side before encoding the stream (client-side, using GPU where possible for performance).
  • HDR passthrough mode when both sharer and viewer have HDR displays via VP9/H.265 + HDR10 metadata if the underlying tech supports it.

Notes (optional)

Why this matters
  • HDR monitors are now mainstream (especially in gaming and creative communities).
  • Other platforms HDR streaming is still mediocre; Fluxer has a chance to do it right and stand out.
  • Screen sharing is already one of Fluxer’s strongest features this would make it class-leading.

5 comments

Sign in with Fluxer to comment and vote.
Comment by @N1ckstars
RexSystem 1 vote originally by @N1ckstars on GitHub
im commenting to boost this, as its one crucial feature i always use on discord. having the stream appear washed out does suck, and i hope this does get fixed as soon as possible, especially since im considering moving to fluxer entirely when self hosting comes out
Comment by @nathanieloon
RexSystem 1 vote originally by @nathanieloon on GitHub
are there any updates on this? given the latest discord discourse I'd love to push fluxer with my group but half of us use HDR screens and it would make it a lot easier to push for a migration
Comment by Hampus
HampusStaff 1 vote originally by @hampus-fluxer on GitHub 1 reply
This is inherent to using Chromium for capture. I will get this fixed in the new voice system though that uses native mechanisms for captures on Windows, but I can't give any ETA for that, I'm afraid. As soon as I can, since voice & video is what people complain about daily, apart from the self-hosting desktop update.
Comment by @nathanieloon
RexSystem 1 vote originally by @nathanieloon on GitHub
no worries, I'm just glad to hear it's on the todo list!