What color space?

[jriker1]

I am taking the S-Video port on my VHS and running it into the ADVC110 S-Video port, then Firewire from the ADVC to the PC. The video is being captured by Sony Vegas 8.0b. Three questions:

1. What is the color space that I should expect the DV file to be in?
2. Is the ADVC or Vegas determining the color space of the initial DV capture?
3. In this situation Is there any chroma/luma sampling bug issues to wory about?

Thanks.

JR

[GrassValley_BH]

1. It's YCbCr color space, per DV spec.
2. The ADVC (technically the DV specification itself) determines the color space of the incoming data.
3. Early Microsoft DV codecs (pre-DirectX 9) had some issues with DV decoding. Current Microsoft DV codec decoding is OK as far as I know.


Addressing your other questions from the other thread here too, as it applies more...

So you're capturing (transferring) DV, resulting in a DV file (Vegas shouldn't let you do otherwise).
Then you're doing some initial edit, and saving the result as uncompressed.
You're doing more filtering and saving that filtered result as uncompressed.
Finally you're taking the uncompressed filtered result and compressing to MPEG-2 for DVD.

If I'm right in the above summary, your process makes sense.

Which leads me to believe you're asking about color space because you want to know what uncompressed format is best to use to avoid color space changes and color sampling reduction.

If that's the case, then you'll want to use AYUV, UYVY or YUY2 (in order of preferred to least - ref: http://www.fourcc.org/).
Going to a larger sampling space (ie, from 4:1:1 to 4:2:2 or 4:4:4 - 4:1:1 and 4:2:0 are just plain different) is OK (as long as it's the same color space) and better for preserving calculated results.

Note however that MPEG-2 for DVD is 4:2:0 sampling, so there will still be an unavoidable sampling change at the final stage of your workflow, but as long as you keep it there, you'll maintain precision throughout the filtering process at least.

[jriker1]

Thanks for the great reply. Exactly what I was wondering. My concern with Vegas was that from what I read, their DV Codec in the software saves DV footage as RGB. So if you render in Vegas as DV the resulting AVI file will be RGB which I obviously don't want. From that perspective was unsure if the initial captured footage would be RGB. Taking from your detailed response, I understand now that the answer is the color space of the captured video is not RGB but YUV.

Thanks.

JR

[GrassValley_BH]

Vegas might be processing internally in RGB space, which is less than optimal due to the differences in gamut and the inherent RGB<->YUV conversion shifts.

If Vegas does process in RGB, then what you might end up seeing is color "shifts" between processed and unprocessed segments of your video. In that case, it might be of worth to simply convert everything to RGB from the get-go, at least you won't have shifting in between.

Or you could do some editing in EDIUS or another editor that workings YCbCr space. Again, I'm not certain that Vegas processes entirely in RGB or not - it might just be certain operations.

[jriker1]

Or you could do some editing in EDIUS or another editor that workings YCbCr space. Again, I'm not certain that Vegas processes entirely in RGB or not - it might just be certain operations.

I have EDIUS, unfortunately it has two problems:

1. Can even get to the main screen after installed in Vista. Crashes everytime.

2. The NeatVideo plugin I use does not have a version that works with EDIUS.

Sony is confusing, or perhaps most work this way, that you do not know what color space they are working in. Perhaps if the codec doesn't say then it uses whatever the source is? Like "Uncompressed", it doesn't tell you what color space it uses anywhere. Then they have options like "Sony YUV Codec" and "Sony 10-bit YUV Codec" but not sure what exactly those are, if they are DV or what. Their standard DV Codec says "NTSC DV" for the format and that's it.

JR

[GrassValley_BH]

YUV, for modern intents and purposes is same as YCbCr. So if you see ____ YUV, then it's YCbCr. YPbPr is the analog representation of YCbCr, which is the digital version.

"Uncompressed" if it doesn't specify is usually safe to assume as RGB 4:4:4.

So the "Sony YUV Codec" is YCbCr, but it doesn't say what the color sampling is. Most likely it's 4:2:2 though.

"Sony 10-bit YUV Codec" is the same, except using 10-bit values instead of 8-bit values so it has higher precision.

[jriker1]

Right now I'm trying the Sony 10-bit YUV Codec with 32-bit color support. Guess it's supposed to help prevent gamma banding or something. Last time I picked the 32-bit support and did uncompressed the file was massive, however I may be smaller with the Sony codec. I hear it's a lossless codec so it should compress to some extent as opposed to uncompressed.

On another topic I mentioned before, there is a lot of talk about Canopus codec having a chroma/luma sampling bug which avisynth has a command to fix. Is that the case with the codec in the ADVC110 that I should utilize this fix in AviSynth or just the Canopus codec installed in Windows has this problem? Or no comment? :)

JR

[GrassValley_BH]

Early decode-only Canopus DV codec had a decoding problem. The current decode-only DV codec should be OK. You can't get the encode/decode Canopus DV codec without some kind of Canopus product installed. If you have one that encodes/decodes with a Canopus product installed, then it's likely not legit.

I'm not aware of any problems with the hardware Canopus DV codec.

[jriker1]

Early decode-only Canopus DV codec had a decoding problem. The current decode-only DV codec should be OK. You can't get the encode/decode Canopus DV codec without some kind of Canopus product installed. If you have one that encodes/decodes with a Canopus product installed, then it's likely not legit.

I'm not aware of any problems with the hardware Canopus DV codec.

Thanks for the info. Now for me to go searching how the heck to place the encoded video. WMP can't play this Sony 10-bit YUV codec. Lot of good it does to encode something and not be able to see it's quality one way or the other. Oh well. :(

JR

[GrassValley_BH]

There's always the tried-and-true HuffYUV. :)