Convert RGB to the composite video / S-video (math)

Question

I used to do it in circuits with CXA1645 or AD725.

But this question is not about soldering, it is about math and digital processing.

Imagine I am designing the entry-level graphics processor using FPGA, which outputs RGB using 5-bit DACs (currently considering R2R) with maximal resolution of 640*480, at 50 or 60 Hz.

The easiest and proven solution is attaching AD725 to the FPGA, and be happy with composite and S-video outputs.

However there's another possible way to consider - instead of feeding analog data to AD725 and let it play with this data, use FPGA's internal digital - precise and synced - data, to generate digital composite and S-video signals.

I can not come to conclusion if this is a good idea or not by browsing tons of resources on the internet, and have questions, asking for your experience and appraisal:

1. Is it actually beneficial? I suspect NTSC/PAL composite (over standard RCA cable) may not be able to display 640*480 in proper way, even if math is done in digital and then converted to analog with dedicated DACs?
2. RGB outputs are 5-bit, yielding 32768 colors. How wide composite DAC should be? Looking into nice pictures about IRE, color levels etc I am unable to even closely have an idea what it would be.
3. Did you see related math anywhere to convert RGB to composite (as I understand target is called HCL)? I have seen it is required to convert to XYZ first, and only then to HCL...
4. Pictures like this look cool, is there an explanation for dummies? While I can get how sync and luma work, I have difficulties with hue and chroma, and how to make them from RGB data.

I suspect all these may require lots of background, will be very happy for references to the texbooks to get it.

Answer 1

1. Sure it is beneficial. You can skip the analog RGB generation part, and instead of three 5-bit DACs, you only need to have one DAC for composite output, or two DACs for S-Video output. But of course, 480p60 is not possible, as composite interface needs to be 15 kHz 60 Hz or 50 Hz signal, meaning, you can either output 480i60, 576i50, 240p60, or 288p50.

2. 8-bit DAC is sufficient for consumer use, 10-bit DAC is sufficient for studio use. With 5-bit RGB, it could be even less than 8-bits, but you can of course simulate the results.

3. Yes, the math is all over the place, in various standards for NTSC such as SMPTE-170M, FCC laws about NTSC transmission and even Wikipedia, or ITU-R REC-BT.470 for PAL. There even exists a digital composite standard which is sampled at 4 times the colour subcarrier, 4xFc. I have no clue what you mean by HCL, but converting RGB to CIE XYZ is definitely not needed. Typically, it's called YUV, the real YUV for NTSC, so not just any random things that are also incorrectly called YUV. However, even YUV is supposed to be rotated by 33 degrees to get YIQ, which also happens to be the sampling for NTSC digital composite. PAL is somewhat easier, it's the same YUV and PAL digital composite is sampled as YUV.

4. You have luma and sync, and then the UV or IQ quadrature modulated by colour carrier is added to it. As the whole signal is 140 IRE, that's NTSC. From the amplitudes, that's 100% colourbars, which is sort of bad example. The colour burst phase is incorrect though - it's 180 degrees on NTSC, and in PAL it alternates between -135 and +135 degrees. The phase degree of the colour carrier is the colour hue, while the amplitude is the saturation.