Posted By
TLC
on 2023-07-11
07:38:46
|  Re: Luma / Chroma crosstalk fix
Thanks, guys! 
@Charles I couldn't answer your question, I might only give some background and clues.
As you can see on the oscilloscope captures, luma is a baseband signal, but colour is not. (In a nutshell, the U and V colour difference signals are modulated onto a 4.43MHz carrier with QAM, more about that in the PAL and NTSC standards if you're interested). This is what they call a composite colour (composite chroma) signal. This setup (i.e. baseband luma, and carrier modulated chroma) has a couple of consequences.
1.) luma and chroma behave slightly differently. You can roughly think of the TV picture as a black and white (luma) overlay floating on top of a colour tone (chroma) background.
2.) Chroma's resolution is worse than that of luma. Pixels can have unique luma (unique brightness), but they can only have slightly common chroma (colour tone) with neighbouring pixels in the X direction.
3.) With regards to the Plus/4, the TED produces video output with luma to chroma phases fixed to each other. That means that 1.) there are fixed positions where pixels can be shown, 2.) there are fixed "colour slot" positions for chroma, and 3.) due to chroma having less resolution than luma, the two grids don't match each other in the X direction. In average, there is one colour slot for every 1.6 luma pixel slots for a PAL Plus/4 (in NTSC it's 2 pixels). If you scroll the screen horizontally by an 1-pixel resolution, the content's luma alignment vs.chroma background constantly changes. (I believe, this is the root cause to the effect @MIK was referring to earlier, with regards to RF, in his original thread. But I've yet to set up the really old colour TV set to see... and maybe capture.)
4.) Chroma needs to be demodulated before displaying, and there can be great differences amongst displays, as to how (...how well) this demodulation job is actually done. Smooth colour transitions are usually fine, but huge transitions can impose a challenge to some implementations, where, transition lines may have banding, false colours, anything. Similarly, there can be also artifacts around no-colour to coloured transitions (and vice versa), which is - practically - just also a sudden change in colour. Some implementations behave better to all that than others in practice. Then, already inferior demodulation results can be made even worse by "so-called" "enhancement" processes implemented in modern displays. In my experience, analog colour demodulators usually do a superior job to those implemented in modern digital displays. (That one might have something to do with the fact, that digital displays do colour demodulation and picture composition in the digital domain, on samples of limited sampling frequency.)
So, getting back to your video - yep, as you said, the colour artifacts and flashing can be hardly explained by chroma to luma crosstalk here. There could be some fine vertical banding out of that maybe, and a small bit of flickering with the screen moving (due to the vertical bars' positions changing), but not the colour outlines and blurs. (Note of warning: theoretically, Luma also crosstalks to chroma in the stock setup a bit, so, I said "theoretically", sharp luma transitions can result in a bit of chroma distortion too. In practice, I've never seen this "pronounced" (it was never so apparent than how chroma crosstalk to luma is), but who knows...) In digital displays, further questions arise due to the displays' nature of resampling the source signals, and doing signal processing on them in the digital domain. That can yield unexpected results depending on the sampling's and the picture content's phase - which, in your case, constantly changes while you X-scroll the content.
All in all...
Looking up and getting rid of any screen "enhancement" options in the display's menu, might generally help. (In my experience, usually the most basic setups give the best results here.)
For me, the "rainbow" coloured blue characters in the status line especially suggest that there's something weird going on around the colour demodulation process, especially that (judging from the screenshot you also shared) these characters are just supposed to show in plain blue. This surely can't be explained by chroma to luma crosstalk, and if someone asks me, not even luma to chroma crosstalk to this extent. Unless the connection schema is wrong (say, the display's chroma input happens to be fed from the computer's composite video output by mistake, just to name one possibility), this has to be entirely due to the display's (inferior) method to demodulate the colour signal. You could possibly get a clue, say, by using a different display for a test. That one can be a CRT display, another digital display, or, a PC video capture gadget, no matter which one, provided that they have s-video input. Also, if you put together and share some small example code that triggers the problems that you see, I can also try and capture the results on my setup (I mean the digital / PC involved one above) someday.
|
