x.v.Color and the future

Velcro Face wrote on 6/10/2010, 8:51 PM

This may be off-topic, but I edit in Vegas, and I'm wondering what experiences others have had working with video recorded in x.v.Color. I just got a new camcorder that has this capability. It's supposed to capture a wider gamut, but few televisions apparently have the capability of displaying it, and shooting in x.v.Color may cause odd color shifts on those monitors. However, that seems to be the way the industry is heading. Should I take advantage of shooting in x.v.Color? If so, what should I do within Vegas to make sure the output works well with all monitors?

--
Michael

Comments

ushere wrote on 6/11/2010, 3:39 AM

not really off topic.

http://en.wikipedia.org/wiki/XvYCC

i'm interested to hear opinions as well. i've sort of read up on it a bit, but to be honest couldn't really fathom any benefits to be gained using it NOW, (or how vegas uses / utilises it)

then again, since it's yet anoher colour space, it might end up being as widely used as sRGB, or as narrowly as prophoto.

it might also end up like hd-dvd - another 'also ran'.

btw: interesting reading:

http://www.homedvd.ca/pdf/upload/xvycc-What%20wrong%20with%20this%20picture.pdf

Jay Gladwell wrote on 6/11/2010, 3:50 AM

"xvYCC is not supported by DVD-Video or Blu-ray, but is supported by the high-definition recording format AVCHD and PlayStation 3."

You can read more here.

ushere wrote on 6/11/2010, 3:59 AM

hi jay,

read that too....

so, does that mean i'll get a more 'colourful' end product if i use x.v on projects destined solely for the net, as in .mp4?

mind you, a lot of my end products might benefit from being more 'colourful' anyway ;-)

Jay Gladwell wrote on 6/11/2010, 4:19 AM

"... does that mean i'll get a more 'colourful' end product if i use x.v on projects destined solely for the net, as in .mp4?"

No.

In a nutshell, and I'm probably not explaining it properly, it's another codec/format supporting a wider color gamut--16-bit, as opposed to 8-bit. It cannot provide any more information than was present in the original footage, meaning you can't shoot in 8-bit, render to x.v.YCC, and expect "more color." The viewing device, a color monitor, must also be x.v.YCC enabled in order for it to display properly.

I have no doubt there are a few here who can explain it far better than I can.

Christian de Godzinsky wrote on 6/11/2010, 4:35 AM

Hi,

I have also been unsure about the use of x.v.Color (I have one such cam). The results looks really stunning compared to the normal mode, when viewed on a Sony Bravia TV capable of x.v.Color (via hdmi).

But the question remains:

Would it be possible to import this xv.color to the timeline (ex in a 10-bit format) and the on rendering out - use an ordinary color system?

One would assume that preserving as much information as possible before the final render - would produce also better results...

Christian

ushere wrote on 6/11/2010, 5:01 AM

hi jay, thanks for that.

however, i'm wondering like christian - if my camera shoots it (z5), do i get any benefit from it using it on the tl?

and, showing my ignorance, i thought x.v was 8bit - though the wiki doesn't mention any bit depth.

leslie

GlennChan wrote on 6/11/2010, 11:10 AM

With Y'CbCr encoding, a lot of the codes represent illegal colors. Normally these codes wouldn't be used. However, in the xvYCC system, those illegal colors instead represent colors that lie outside the normal color gamut.

2- Bit depth: Ideally, you want a higher bit depth because the flaws with a low bit depth start to become apparent with the new system. So 10 bits would be better than 8 bits.

3- If you shoot with xvYCC enabled and send that output through a non-xvYCC system, I believe that the illegal colors will get clipped and the results won't look so good.

That being said, I only know some of the theory behind this and don't have practical experience in the matter (e.g. I don't have a xcYCC camera or TV set).

If you want to run your own test, use a CD and record the light reflections off of that CD as those are extremely pure colors that exceeds the color gamut of normal video systems.

4- xvYCC may be well into the future before it really gets practical. That is if it even takes off.

john-beale wrote on 6/12/2010, 8:56 PM

I'd like to test it out, I have two cameras with x.v.Color capability, but no capable display (as far as I know). Note that the existing AVCHD cameras that offer x.v.Color do not use any more bit depth, they simply make use of some otherwise unused color codes (analogous to how video luminance is usually 16...235 instead of 0..255)

Do we know for certain that shooting in x.v.Color is actually any worse than not, on older displays? After all, if you try to record a color that exceeds the gamut of your display, it's not going to be displayed no matter what. I guess the question is does the entire range get rescaled allowing a smoother transition, or do just the saturated colors get hard-clipped as they reach the edge of the gamut? How do older video cameras deal with that? I suspect they just hard-clip(?)

farss wrote on 6/12/2010, 10:06 PM

From my understanding of x.v.color:

1) It is NOT a new codec. Many Sony cameras record it into the existing HDV codec.

2) Out of gamut colors do display, just not correctly e.g. out of gamut red can end up as brown(ish).

3) Older video camera effectively map out of gamut colors into their color space. Out of gamut reds don't turn out black, the actual sensors in a video camera know nothing about color, they're strictly photon detectors. Bandpass filters are used to limit the wavelengths of light they see. Those filters have fairly gradual rolloffs and overlap.

4) One simplistic way to consider these questions is this. We all talk about R,G,B but exactly which Red, Green and Blue is the issue. It's somewhat compounded by the increasing appearance of unnatural light sources and dyes. The television system was never designed to cope with these.

Bob.

Nx wrote on 6/16/2010, 7:08 PM

I have obtain such answer from SCS while asking for the workflow to follow from an HDV cam supporting x.v. Color to Vegas to bluray reader and lcd display (all supporting x.v. color).

This is the answer I got:

'The problem is in our software. Our software can render out the full range of colors, no problem. However, what the program is failing to do is mark the colors as xvYCC. Basically, all it is missing is that flag that says, "this is xvYCC. The actual xvYCC color is there, it's just not being marked by the program. This is something we hope to fix in an update.

Whether the colors will display correctly is completely up to the display itself. Some displays will read the color fine and do not need the flag. Others require the flag, and therefore will not read the colors correctly. So whether it plays back correctly completely depends on whether your display can display the color without the flag telling it to do so.'

I agree that straigh out of the cam to LCD display via hdmi looks much better than the transcoded stuff...

john-beale wrote on 6/17/2010, 8:26 AM

Just tried an experiment last night, but with inconclusive results. I took some video clips of a vivid pink rose, and a very deep dusky red rose. Both perfectly "natural" by the way, but strong saturated colors that I do not see on the video screen. For example, looking at the viewscreen by itself the red rose seemed "red", but comparing it with the real thing, the screen looked like a dull muddy orange, so that color is outside the viewscreen gamut, anyway.

I tried recording both roses with the x.v.Color mode on and off, on two different cameras (Sony and Panasonic). I played back the video using an Avisynth histogram filter that shows the YCbCr components to see if I was recording any of the nominally "illegal" color ranges in the Cb or Cr components- and I was not; the color histogram did not extend very far either way towards the boundaries. But I suppose it is possible that something in the software (DGAVCDecode or Avisynth) was rescaling the video ranges (?)

By the way, if I want to construct a test video with specified values of Y, Cb, Cr for pixels, how could I do that? I can generate RGB and convert that into a YCC video, but I'm not sure how to work directly with YCC if I want to work with Cb, Cr values outside the usual 16-240 range, that might correspond to negative R, G or B components . Maybe I could use ffmpeg to synthesize a clip from raw Y, Cb, Cr bitmap files (?)

Note to self, see also: http://en.wikipedia.org/wiki/YCbCr and http://en.wikipedia.org/wiki/XvYCC