Legal Valid levels in RGB and YUV from analogue capture

[2Bdecided]

There are a whole range of values in YUV space that cannot be converted into RGB space - i.e. they give 8-bit RGB values less than 0 or greater than 255 in 8-bit integers.

So, for example, peak white and pure black can have no colour in RGB space, but can have a colour in YUV space (!). Those super saturated colours in YUV space get clipped in RGB space.


I assumed that all signals I would come across were legal and valid in both spaces, but I've hit a problem...


I'm capturing content from S-VHS camcorder tapes into DV AVI via a Canopus ADVC110.

The levels at first appeared to be way too high, but checking the actual YV12 data showed that there was very little clipping there; the U and V channels were fine, and the Y channel was only slightly clipped (I estimate that about 5 8-bit levels are lost off the top, and this is mainly overshoot on peaks in the original signal - I've checked on a video scope).

Black (blanking) is at 16; white hits 255; U and V stay well within range. Of course a normal YUV>RGB matrix="Rec601" (16-235 > 0-255) conversion clips the whites, so I'm using converttorgb(matrix="PC.601") instead.

Here's the problem. I know from watching these tapes on a TV that they have always been under saturated. It was just a feature of this camcorder, and the tapes looked just the same the day they were shot. On the TV, turning up the colour control worked really well, so I was hoping to boost the colour a little in AVIsynth. Tweak(sat=1.3) looks about right.

However, even without that tweak, the colours in RGB space are completely saturated and clipping. There are near-peak whites that are strongly blue, and clip the blue RGB channel severely. I have to back the Y channel off with coloryuv(gain_y=-60) and converttorgb(matrix="PC.601") just to get colours that don't clip in RGB. The result is a bit too dark, though of course the relative colour saturation is now good and I don't need to tweak that further.


It seems that there is a huge possibility of "illegal" colours in the YUV space (analogue, and digital). Do people normally avoid these? DVD players in Europe have RGB outputs, and it seem inevitable that such colours will get badly clipped.

What do people normally do about this? What can I do here?

I'm intending to encode to MPEG-2 using TMPGenc and burn to DVD. I want people to be able to watch the DVDs without fiddling with their TVs, and see the same picture that I see from the original tapes when I turned the colour up. However, this seems impossible! If so, what's the next best thing?

Cheers,
David.

[JohnnyMalaria]

Use Studio RGB instead of (computer) RGB.

Computer RGB does clip but it is really intended for final display.

If you are ultimately encoding to another YCrCb-type format, use Studio RGB (R'G'B'). This will permit conversion back to YCrCb without clipping problems. However, the intermediate RGB will look rather washed out etc.

(In this day and age, there's absolutely no reason for anything to be done in RGB - everything can be achieved whilst staying in YCrCb. Unfortunately, things are still a bit backwards.)

Anyway, the proof of the pudding is in the final material - not necessarily how the intermediate looks on the PC.

EDIT - Since you are using DV as your source, you can use our software to adjust the chroma (which is what you are trying to do) without ever going into RGB. You can do it on existing AVIs or while capturing new ones.

[2Bdecided]

Johnny,

Thanks - I will try your software (your website is still blocked at work - what a pain!). I fear TMPGEnc requires RGB anyway, so I'm a bit stuck.

By PC vs studio RGB, do you mean 16-235 > 0-255 vs 0-255 > 0-255? Because if so, that's what I'm already doing in AVIsynth.

It's the saturation of the colours which causes the problem. There are many possible colours in YUV that can't be converted into RGB e.g. luma=255, U and V anything other than 128! There are less extreme examples.

Cheers,
David.

[JohnnyMalaria]

Johnny,

Thanks - I will try your software (your website is still blocked at work - what a pain!). I fear TMPGEnc requires RGB anyway, so I'm a bit stuck.

By PC vs studio RGB, do you mean 16-235 > 0-255 vs 0-255 > 0-255? Because if so, that's what I'm already doing in AVIsynth.

It's the saturation of the colours which causes the problem. There are many possible colours in YUV that can't be converted into RGB e.g. luma=255, U and V anything other than 128! There are less extreme examples.

Cheers,
David.

Hi David,

If you send me your email address to johnATenosoft.net, I can send you the installer.

BTW, when you get a blocked message at work, does it say why? I might need to talk to my ISP.

John.

[2Bdecided]

It seems that this is how it's done...

http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=GB2198008
(That patent has lapsed)

Thanks to Jim Easterbrook at the Doctor Who Technical Forum for those links. (original post: http://www.rtforum.co.uk/read.php?id=221381 won't be there long though - that forum deletes old posts)

Jim Easterbrook
Re: SOT: Handling analogue YUV video levels in digital RGB
Thu Feb 28 2008 08:32:26
132.185.132.012

As you've discovered, "illegal" YUV combinations can lead to undefined (out of range) results when converted to RGB. The nicest way to deal with this is to scale back U & V, preserving the hue, to make a legal combination without changing Y.

There's quite a good discussion of this, with some helpful diagrams, in UK patent GB19860027863.

Edit: I forgot to mention that there is also a BBC Research Department report on this, which is more readable than the patent.

Does anything like this exist for AVIsynth, VirtualDUB, etc?

Cheers,
David.

[sh0dan]

You should perhaps take a more visual approach to your problem.

The most annoying artifacts to me are those you mention - saturation - usually from uneven clipping in the camera, causing flat, colored areas.

I usually use a combination of masks to gradually desaturate the image in very light and/or dark areas. If you have a piece of the source material, we could perhaps be more helpful.

Btw, you should take a look at HC or QuEnc if you are encoding to a DVD. Both have direct YV12 input and great quality.

[2Bdecided]

I usually use a combination of masks to gradually desaturate the image in very light and/or dark areas.I'd thought about that, but that's actually a "hacky" kind of way of getting close to the "correct" approach described.

The "correct" approach would be faster and better, if it was implemented. In the absence of that, I'll see what I can do.

btw, yes, I'll try to upload a clip some time.

I've attached a still. The answer is to fix the chroma, but to show how far off it is, I've dragged the luma down far enough to prevent clipping with the existing chroma - the luma has to stay below 190! The luma hits 255, rather than 235 - but black is at 16. I've dragged that black back to 0 for this comparison...

Cheers,
David.

[2Bdecided]

Another interesting thing: on normal TVs and normal DVD players, these invalid YUV values are handled just fine.

If using composite, S-video, or component, conventional TVs just do the best they can to represent the over saturated colours. If the DVD player outputs it, they handle the full 0-255 range of Y, U and V just fine. The results look quite acceptable. (I tested a CRT reference monitor - not sure what plasmas and LCDs would make of it).

If using RGB SCART, the DVD player I tested didn't expand the 16-235 range to fill the range of its DACs and so didn't clip where expected - in fact it accurately output up to 255 of the original range, but nothing below 16. So with RGB, many of the colours do get clipped (though at a higher level than a PC display which expands 16-235 > 0-255).


So it's only PC playback (and potentially modern TVs) where this is an issue.

Cheers,
David.

[scharfis_brain]

If I am capturing I adjust the brightness, contrast and saturation sliders of the capture card in a way that the live-histogram shows that the actual luma range is within 16...235.

When the capture was done in RGB, you can use
converttoyuy2(matrix="PC.601") to convert it without clipping and banding to YUY2.

[2Bdecided]

I'm using a Canopus ADVC110, so I don't have any controls.

I need to turn the luma down a little somehow, but if I was to turn the saturation down too, then the picture would look far too desaturated - if anything, the images need more colour saturation, and always have. That's just how this particular camera worked.

I can't decide now whether to get a proc amp to fix the luma into the ADVC110, or to get an actual capture card (rather than an ADVC110) to capture. I think I'll post that question in the appropriate forum!...

Cheers,
David.

[scharfis_brain]

Try to use a potentiometer in your composite signal to lower the luma while (mostly) preserving the chroma saturation.
I do this too in order to avoid my capture card is clipping the signal.

[JohnnyMalaria]

I'm using a Canopus ADVC110, so I don't have any controls.

I need to turn the luma down a little somehow, but if I was to turn the saturation down too, then the picture would look far too desaturated - if anything, the images need more colour saturation, and always have. That's just how this particular camera worked.

I can't decide now whether to get a proc amp to fix the luma into the ADVC110, or to get an actual capture card (rather than an ADVC110) to capture. I think I'll post that question in the appropriate forum!...

Cheers,
David.

Did you have any joy trying our software? You can turn the luma down while capturing and it is done in a completely lossless way (i.e., no recompression takes place).

I don't recommend the potentiometer option, though, since it will adjust the entire video signal including all the sync pulses etc etc.

[scharfis_brain]

Did you have any joy trying our software? You can turn the luma down while capturing and it is done in a completely lossless way (i.e., no recompression takes place).
Which software?
How does it work technically?

I don't recommend the potentiometer option, though, since it will adjust the entire video signal including all the sync pulses etc etc.
Since it just adjusts the signal a few by percents, the sync impulses will stay within the tolerance...
Even halving the signal amplitude had absolutely no impact on the syncs. (Remind that the signal is designed to be transmitted a looong distance)

[JohnnyMalaria]

Which software?
How does it work technically?


Since it just adjusts the signal a few by percents, the sync impulses will stay within the tolerance...
Even halving the signal amplitude had absolutely no impact on the syncs. (Remind that the signal is designed to be transmitted a looong distance)

The software is our Enosoft DV Processor.

At the heart of it is a proprietary DV codec that minimizes the amount of decoding required by exploiting the mathematical relationships between the data in the frequency domain and the spatial domain. Some functions - such as brightness and white balance - can be achieved with low CPU cost.

e.g., to adjust the brightness of an 8 x 8 block:

Traditional way (thousands of instructions):

Unpack DV frame
Run length decode to get quantized and weighted luma and chroma DCTs
Remove quantization and weighting
Perform IDCT to get spatial domain 8 x 8 image
(data are in RGB at this stage - typical for most editors)
Calculate new RGB value for brightness adjustment
Convert back to luma and chroma
Perform DCT to get frequency domain blocks
Apply weighting
Quantize (iterative)
Run length encode
Pack DV frame

Our way (one instruction):

Add/subtract required value for DC coefficient
(no unpacking, decoding etc)

[scharfis_brain]

but since this is done on the digitized data already, you will risk to introduce banding in almost flat areas if you alter the contrast.

That is why I try to manage the levels balancing before digitising the signal.

[JohnnyMalaria]

but since this is done on the digitized data already, you will risk to introduce banding in almost flat areas if you alter the contrast.

That is why I try to manage the levels balancing before digitising the signal.

No, adjusting brightness is the same across the whole image. In the spatial domain, it simply adds or subtracts a constant value across the whole image. Banding cannot occur.

But I agree that if you have an analog signal and you can process it with analog equipment (as long as it is high precision/low noise!) then why not.

If you intend to use some form a video editing software then the process will be mathematically equivalent to ours - just much, much slower.

[sh0dan]

You are getting off topic here. If you need to, please continue in the Capture section.