Washed out blacks/Incorrect color range

[harritaco]

EDIT: My issue seems to be closely related to an issue opened for the standard NanoKVM. See: sipeed/NanoKVM#702

I really like my NanoKVM Pro but one thing that has bothered me over the last few months is the fact that the stream is slightly washed out. It's mostly noticable on dark or black images. I'm using the latest firmware and experience this behavior no matter what host I use, however it's currently plugged in to a RTX Ada 2000 GPU on Windows.

The remote host is outputting RGB Full with HDR disabled. Settings are similar on client side, RGB Full, HDR off.

I'm not totally sure how this could be improved, but here are some LLM inspired ideas.

• Input color range selector (Auto, Full Limited)
• Encoder range flags (Full/Limited)
• Possible post capture adjustments (Gamma, Brightness, Contrast)
• Explicit YUV vs RGB selection (RGB, YUV 4:4:4, YUV 4:2:2, YUV 4:2:0)
• Debug info showing the input color space, range, bit depth

I've included an image that shows a black image. On the left is the NanoKVM Pro (Any web browser) and on the right is a remote Splashtop session. Very noticable difference. Changing the Gamma and Brightness/Contrast unfortunately only improved it marginally.

Thanks for reading and I appreciate the work from the team.

[916BGAI]

Hi @harritaco ,

Thanks for your detailed report! Could you clarify which mode you were testing with? It would be really helpful if you could provide results for the following modes separately:

H.264

H.265

WebRTC

Direct mode

MJPEG mode

If possible, could you also try switching to PiKVM for comparison? This would help us better understand where the color range issue occurs.

Thanks again for your feedback!

[harritaco]

Thanks for the response @916BGAI
I did try all modes (H264 Web/Direct, MPEG). I haven't been able to get H265 working. The result is the same in all modes, including when running in PiKVM Mode.

I did some additional diagnostics in chrome dev tools, specifically when using h264 direct it appears to be using the correct encoder settings (range=2). Despite that I'm unsure why everything is still washed out.

[gnattu]

With Nvidia GPU on windows, have you tried to change the output range to Full in nvidia control panel?

[harritaco]

With Nvidia GPU on windows, have you tried to change the output range to Full in nvidia control panel?

Yes, I've tried a variety of different color settings with the same results. The only settings I can change that make a meaningful difference are the desktop color settings. I also tried using this with an Intel ARC GPU and the results are the same.

[harritaco]

JetKVM produces correct black levels under identical conditions, while NanoKVM’s WebRTC stream exhibits lifted blacks. The difference is in the encoder pipeline below WebRTC, not in the browser or GPU.

[916BGAI]

JetKVM produces correct black levels under identical conditions, while NanoKVM’s WebRTC stream exhibits lifted blacks. The difference is in the encoder pipeline below WebRTC, not in the browser or GPU.

Thanks for the detailed comparison.
Could you provide a comparison of the decoder pipeline between JetKVM and NanoKVM?

[gnattu]

I'm sorry but it is impossible for outsiders like us to dig deeper because the actual implementation part is not open-sourced yet which makes us impossible check the problem.

And from my own investigation, the problem is probably not from the encoding/decoding part but from the capture part. I cannot see the implementation so it is fully speculation but I do have some reasons:

• Changing the output rgb range does not affect the actual color
• Changing encoding mode does not affect the actual color either
• Not even pikvm handles this correctly

In any case we can config, the black is not at 0 and the white is not at 255, which indicates that the YCbCr range handling is wrong in the pipeline and probably before the video stream actually enters the encoder.

But the current behavior is still strange though, as changing output range does not affect the video stream being captured is something I really don't understand. Maybe the internal conversion of the LT6911 chip made something wrong? It has to be very wrong to behave like what we currently have:

• For Full range input, it discards signal below 16 and above 235, essentially never outputs real black and real white.
• For Limited range input, it first scales to full range and does the same thing, discard <16 and >235 signals.

Probably our config is wrong somewhere. But as I said previously we cannot help much with closed source implementations.

[harritaco]

Correct^

I was able to obtain datasheets for the capture cards used in both the JetKVM and NanoKVM Pro. Ultimately it seems like the issue most likely isn't silicon alone, however the silicon isn't helping either. I uploaded both datasheets to ChatGPT and Cluade with a ton of context and received similar feedback from both. This is out of my wheelhouse a bit.

Hardware comparison

• NanoKVM Pro uses the Lontium LT6911
• JetKVM uses the Toshiba TC358743XBG

I tested both devices side-by-side using identical conditions:

• same source machine and GPU
• same cables and monitor
• same browser and WebRTC decode path

Under identical conditions:

• JetKVM preserves correct black levels and color accuracy
• NanoKVM Pro consistently exhibits limited-range behavior with lifted blacks

Key architectural difference

The TC358743XBG is a capture-oriented HDMI receiver. Its datasheet explicitly indicates that it does not perform internal color space conversion, and instead forwards the source signal downstream (camera-style behavior).

The LT6911, by contrast, is a display-oriented HDMI receiver. Its datasheet explicitly lists:

• internal color space conversion (RGB ↔ YCbCr)
• panel-oriented output formats (RGB565/666/888)

For an IP KVM, the absence of implicit CSC is actually a feature:

• RGB Full (0–255) remains intact
• quantization range is preserved
• HDMI InfoFrame semantics are honored
• CSC happens once, downstream, where it can be explicitly controlled

With LT6911, the internal CSC appears to assume display/TV semantics (limited range). Once values are clamped at the capture stage, shadow detail is irreversibly lost — which aligns with what I’m seeing:

• WebRTC reporting range=limited
• consistently lifted blacks
• behavior persisting across resolutions and codecs

This does not appear to be a “bug”

The LT6911 seems to be operating as designed for display pipelines. However, for a capture / IP KVM use case, this behavior is destructive unless it can be explicitly configured or compensated for in firmware.

Potential fixes / areas to investigate
If possible, it would be helpful to determine whether any of the following are supported:

1. LT6911 capture configuration

• Ability to force RGB full-range handling
• Ability to disable or alter internal CSC behavior
• Exposure of HDMI input quantization / AVI InfoFrame range

2. Firmware-level compensation

• Expanding limited-range luma (16–235 → 0–255) prior to encoding
• Providing a “capture mode” vs “panel mode” option

3. Diagnostics / visibility

• Exposing capture color range / CSC state via /proc/lt6911_info
• Logging the effective input/output color space and range

I’m happy to test any firmware builds, configuration changes, or diagnostics that would help determine whether this is:

• a configurable LT6911 behavior
• or a hard limitation of the capture pipeline

Summary
JetKVM’s superior black levels appear to come from using a capture-first HDMI RX that avoids implicit color processing. NanoKVM’s lifted blacks appear to be an architectural consequence of using a display-oriented HDMI RX without capture-specific compensation.

[harritaco]

The NanoKVM Cube does not exhibit this lifted-black / limited-range behavior under identical conditions. The Cube is based on the SG2002 SoC, whose video input pipeline is camera/capture-oriented rather than display-oriented. This strongly suggests the issue on NanoKVM Pro is tied to the LT6911 HDMI receiver’s internal processing (CSC / range handling), rather than WebRTC, browser decoding, or client GPU configuration.

Perfect blacks

[mtahernia]

I have a NanoKVM-Pro and ran into this issue.

I have some observations to add.

The blacks are washed out only in WebRTC H.264 and MJPEG modes in Firefox,
but in Chromium, they are all washed out.

I have tried it both in NanoKVM and PiKVM modes.

I have included screenshots of the three modes in Firefox
You can use top and left margins which are outside the displayed screen and are perfectly black for comparison.

Direct H.264 (Firefox)

WebRTC H.264 (Firefox)

MJPEG (Firefox)

I think this may also be related to pikvm/ustreamer issue

[harritaco]

Interesting. I have the same issue with WebRTC and Direct in firefox.