Customizing Chroma and Colorspace

Changing color space

If your overlay looks pink and green, it may be that the video is in YCbCr colorspace instead of RGB. There is now a build that can address this:

cd ~/code/netv2-fpga
git pull
git checkout multires
cd testing-images
./testing-fpga.sh

cd ~/code/netv2mvp-scripts
git pull
./set_ycrcb.sh

The corresponding ./set_rgb.sh command reverts the colorspace to RGB.

Unfortunately, it is a violation of section 1201 of the DMCA for NeTV2 to automatically detect the colorspace of HDCP-protected video, because the packets which specify the colorspace of the video are also encrypted.

Changing overlay thresholds for YCrCb

The default configuration for NeTV2 supports turning an value less than RGB #141414 into video. This means UI elements drawn in not "black" will be rendered, which is suitable for the magic mirror interface.

For a more traditional chroma interface, you can try a "testing" version of the NeTV2 firmware. More specifically, for a chroma of 0xff00ff:

cd ~/code/netv2-fpga
git pull
git checkout ycbcr
cd testing-images
./testing-fpga.sh

pm2 stop netv2-status
cd ~/code/flterm
./flterm --port /dev/ttyS0 --speed 115200
# now inside flterm
json off
chromalo 0xeb00eb
chromahi 0xff10ff
chromapol 1
json on
# hit control-c to break out of flterm
pm2 start netv2-status

The pm2 commands keep the netv2-status daemon from gobbling up serial console characters, which makes debugging on the terminal hard. The json off/on command turns off the json telemetry reporting via the interactive shell which also makes it hard to debug.

Notes on the new chroma commands:

chromapol, when 1, means pixels between upper/lower map to video
chromapol, when 0, means pixels between upper/lower map to overlay
chromalo sets the lower bound for chroma testing as hex 0xRRGGBB
chromahi sets the upper bound for chroma testing as hex 0xRRGGBB

both values are inclusive of the setting, so using the same value passes just that one color.

Note that the Raspberry pi does some sort of funky gamma correction by default -- so the colors you specify to draw in your code or images aren't exactly the colors sent to the screen, because they are corrected with a gamma table.

I'm not sure how to turn it off, but that's why the chroma values don't exactly line up with the values you intend them to be, and this is why chroma is specified as a range instead of as a single value. I had to narrow into the demo chromalo/chromahi values by trial and error more or less, and it's possible that the color clipping may even be monitor-dependent, in case they are doing something like reading back the recommended gamma curve of the monitor and then compensating for it before sending the values on.

Note that the default settings would be chromalo 0x141414, chromahi 0xffffff, chromapol 0 -- in other words, most of the video UI colors are rendered, but everything that's almost black gets turned into video. This is a bit easier to work with in terms of the post-rendering gamma correction.