ITU709 vs ITU601 Vegas and JVC HD110
 

It appears from the diagnostic provided by DVRack, with my JVC HD110 plugged in, that the HD110 erroneously reports its color space in the HDV mode as ITU601. In reality, Tim Dashwood has confirmed that it really is ITU709.

edit: I stand corrected, DVRack correctly reports color space as ITU709. However, I still ask the following...

This has set me to wondering how Vegas sets the color space, because there is no option to manually select it. If the color space is set by a signal from the camera, there is a possibility Vegas is setting the color space erroneously. If, on the other hand, Vegas sets the color space according to whether it is in DV or HDV mode, irregardless of the camera, then all is well in Vegas HDV land.

I recall(and I could be wrong) that ITU709 uses the full RGB color map, 0 to 255, while ITU601 uses 16-235(lab color). If I record the HD110 generated color bars(generated in HDV mode of course) in Vegas and examine them in the Sony Waveform monitor, I see that the the color map is RGB 16-235. Is this correct? Shouldn't it be 0-255?

Does anyone know how Vegas selects the color space?
Spot?

Things get curiouser and curiouser.
If I capture the color bars generated by my HD110 in HDV mode onto an m2t file, then drop the m2t file on the timeline and look at the Waveform monitor, I see that the waveform extends from RGB16-RGB235. Furthermore, the color bars don't line up with the preset values on the WFM.

Now, if I convert the m2t file with cineform HDlink, and make sure the cineform codec is set to ITU709, then drop the CF intermediate on the timeline, I see that the waveform still extends from RGB16-RGB235, but now, the colorbars line up perfectly with the preset values on the WFM.

What's going on here? It looks like Vegas still doesn't map m2t files to the correct color space.

I ain't got no spots, but here's how I do it. Note the Studio RGB bit. Frankly, color management support in video applications is sorely lacking. After Effects just got it in CS3. I doubt you will see it in Vegas any time soon.

Bill, I haven't played with the camera but I can tell you about what Vegas does and what might be going on.

A- The luma values (1s and 0s) are encoded according a formula of the form:

Luma (Y') = r * Red + g * Green + b * Blue
where the lowercase r g and b are the luma co-efficients. Where co-efficients is simply a fancy math word.

For Rec. 601 video,
r = 0.299
g = 0.587
b = 0.114
So the formula is: Y' = 0.299 R' + 0.587 G' + 0.114 B'
( Luma / Y' is also multiplied by a scale factor and has an offset added to it. Ditto for the chroma components. I ignore it here, though it is an issue when you decode the values incorrectly.)

To decode the values, there is a set of reverse formulas. (Which I won't get into.)

For Rec. 709, they changed the luma co-efficients (which wasn't smart, but that's what happened).
r = 0.2126
g = 0.7152
b = 0.0722
So suddenly the set of reverse formulas is different.
If you apply the wrong set of formulas, the values will be decoded incorrectly and you'll get a big color inaccuracy (though it's hard to spot, even though the numerical difference is huge).

2- It might be that the JVC footage is flagged to indicate what luma coefficients were used to encode the footage. (I think this may be allowed in the spec.)

A good decoder will be able to figure out the right set of formulas to use, and be able to decode the values correctly.
In Cineform, the signal path is HDV (Rec. 601 values) --> Cineform (RGB color space) --> to Vegas as RGB values already decoded correctly.

The Vegas HDV decoder probably just assumes that HD footage always uses Rec. 709 numbers. So it is decoding things wrong because of that. Just my guess anyways.

No. You can download the specs yourself by taking advantage of ITU's 3 free downloads. (Though the specs are difficult to read/understand... they aren't self-explanatory.)

Rec. 709 and Rec. 601 both call for values in Y'CbCr color space. The legal range for Y' is from 16-235 (for 8bit formats), while the legal range for Cb and Cr is 16-240 (which is kind of silly, but that's what it is).

"Lab" color is not involved at all.

The Y'CbCr values have to be decoded to RGB to work in Vegas.... to either 0-255 computer RGB or 16-235 studio RGB range. Which range is used depends on the codec. Both have tradeoffs and deficiencies (sort of; but lets not get into that). Vegas tends to decode to studio RGB for video formats (formats that originate on video tape or from the video world), and decoding to computer RGB for computer formats (like JPEG, PSD).

Thank you, Glenn, for taking the time to write a detailed reply.

Vegas doesn't need color management per se.

For video work, you only have a single target output device- a broadcast monitor. Because there is only a single target output device, you can just get a broadcast monitor and you are done.

For other types of work like film output, you have multiple target output devices with different color gamuts and such. (Where the output device is a combination of film printer and film stock.) So that's where color management is needed.

2- I think Bill's issue is more about converting the format correctly.

Which is why I think changing the Rec. 709 luma co-efficients was a bad idea, since you run into these issues.

Thanx, Glenn. It's obvious the issue isn't simple, which is why mistakes in coding are made. You're quite correct, I'm not concerned with color management. The issue, here, is a technically correct conversion within Vegas. I don't give a rats ass about Adobe and how it handles things since I use Vegas exclusively.

I'm afraid there's something quite wrong with the Vegas conversion. It's been suggested on the Sony Media forum that the issue is related to how the Vegas Waveform monitor displays the data, and that, in the end, everything works out right. I need to render out some files as a test, to find out if this is, in fact, true.

So, if I understand part of what you're saying, RGB values of 16-235 are related to the 8-bit nature of Vegas. Does this mean a full range of 0-255 could be realized if Vegas went to 10 bit?

And, as a side issue, I have a working knowledge of mathematical coefficients, especially as relating to mathematical curve fitting (linear regression). In any quadratic equation of the form y=ax*2 +bx+c, the coefficients a,b and c can be non-unique solutions, and can, therefore be changed. In any linear equation of the form y=a(R)+b(G)+c(B), it makes no sense, mathematically, to change the coefficients. That's just asking for trouble, as you so adequately point out.

Edit: OK, I rendered out an m2t file in Vegas and the final render retains the RGB values of 0-255, as measured with an eyedropper tool outside of Vegas. So, it appears the Vegas WFM is being jacked around to show data consistent with RGB16-235, but, on render, the full color range is restored to 0-255. Very very hokey. I am now very distrustful of what the Vegas scopes are showing.

Hang on, I may be wrong here, but won't you pick up 0-15 and 236-255 values with the eyedropper whether its rendered correctly or not?

If the above ranges are stored as headroom data, then if they are incorrectly reproduced, they will appear as the lower end of the black range and the upper end of the white range respectively. The actual white will appear dimmer than intended and the actual black will appear lighter, with a relative shift across the palette.

If the are correctly rendered then the true black and white will be shifted to 0 and 255 respectively, and you will still pick up values with the eye dropper. Or am I confused?

In a Y'CbCr signal, legal white will have Y' at 235. You can also have values above that... e.g. Y'=254. This value is whiter than white. Almost all cameras shoot values like that.

If you convert from Y'CbCr (always 16-235 range for legal values; for 8-bit) to computer RGB (0-255 range for legal values), then
Y' = 235 maps to 255 255 255 RGB. (assume neutral chroma in all examples)
Y' = 236 to Y' = 255 all get clipped to 255 255 255 RGB.

If you convert from Y'CbCr to studio RGB (16-235), then
Y' = 235 maps to 235 235 235 RGB.
Y' = 236 maps to 236 236 236 RGB.
Y' = 254 maps to 254 254 254 RGB.
So studio RGB handles values above whites (AKA superwhites) and also values below black. Though there are some Y'CbCr values which will get clipped.

2- The scopes can be setup in different ways. It's confusing.

3- Vegas will display the studio RGB values directly in the video preview window, so the image will look off. The best thing to do is to monitor on a broadcast monitor (mostly for various other reasons).

If you want to know the exact math:
Y' formula was given.
The recorded Y' has a scale factor and offset to put the values into a 16-235 range.
Recorded Y' = scale factor * Y' + offset

Cb = ( B' - Y' ) * scale factor + offset (to put the values in a 16-240 range)
Cr = ( R' - Y' ) * scale factor + offset (ditto)
Note that these scale factors are different if the luma coefficients change.

You can work out the reverse formulas yourself, or look them up in Charles Poynton's book.

But basically the issue is that you need to apply the right set of formulas, which differ depending on what luma co-efficients you are using. The studioRGB versus computer RGB issue is unrelated.

That's not true because you can have multiple sources, types of video files.

Robert...

You may be right, which would further complicate the issue. As a sanity check, I also measured the errant color chart with the eyedropper and confirmed that the eyedropper read 16 and 235. It also confirms that the color bars have very odd RGB values.

Just for reference, this is the eyedropper tool I used:
http://www.hikarun.com/e/

I can't think of a Vegas independent method of measuring the luma values and I don't have an analog WFM.

Glenn...

Yeah, I've noticed that I get much better results doing CC to taste rather than to the Sony WFM. So, the preview window shows Studio RGB? That's interesting when editting HDV. So, is the WFM just a toy? And it seems the preview window is likewise less than dependable. There really is no way to calibrate it, as there is in DVRack, which has quite a nice calibration procedure, including the ability to select color space. The math algorithms notwithstanding, I am really beginning to doubt that Madison has applied the transforms correctly, or more likely that they've taken incorrect shortcuts to force the software to work. After all, they do advertise that you can load DV and HDV clips on the same timeline.

and to make it a little more complicated ...

"DV cameras use the 601 color space, DVCPro HD cameras use the 709 color space, and HDV cameras are split between the 601 color space and 709 color space. "

from
http://help.adobe.com/en_US/OnLocati..._color_19.html

Yes.

If you use the "external" preview, you can use a windows secondary display with studio RGB converted to computer RGB. Though it's more ideal to use a broadcast monitor.

It can be confusing as to the correct way to set it up due to the 7.5 IRE setup confusion.

It also has no line at 7.5 IRE like analog scopes do... but it can be setup to emulate one. It's silly.

I don't think so. It may (or may not) be that it doesn't do the right thing when it is presented with HDV material encoded with Rec. 601 luma coefficients. But to encode HD material with Rec. 601 luma coefficients is kind of oddball/non-standard.

2- If you take the color bars (assuming they are the 75/0/75/0 type, not 100/0/100/0), do they look the same as Vegas' color bars generator?

You're talking about getting the formats converted correctly? I would not refer to that as color management.

Glenn...

Using the Vegas split screen preview window, I followed your excellent suggestion and compared the original m2t file with the camera generated color bars to the Vegas NTSC Test Pattern. I did the same thing to compare the Cineform generated intermediate to the Vegas Test Pattern.

What I found was that the CF Intermediate and the Vegas generated color bars agreed exactly. The original, native m2t color bars had an apparent "much" higher Luma content than the Vegas color bars, however, the white and black patches are identical. This further confirms that Vegas isn't handling m2t file color space correctly(using the wrong multipliers). This might be by design, I don't know.

I will note that I never add pedestal to anything I produce. This is another huge "can of worrms" that I don't want to open, right now. Suffice it to say that all the non-professional DVD players I've experienced, add pedestal automatically, without telling the user anywhere in the user manual, what they do. So that if I add pedestal in processing, I end up with washed out displays at the destination.

By the way, I must apologize for my past use of the term "Lab Color". What I meant was Studio RGB.(I've spent too much time with Photoshop, lately)

It's might be the fault of the HDV codec that Vegas uses (it should read the flags and figure out the right set of luma coefficients to use).

Considering that Cineform gets it right, then I suppose the Vegas HDV codec might be deficient. Though it could be that JVC is doing something non-standard... encoding HD with Rec. 601 luma coefficients is odd. I haven't read the HDV spec so I don't know if it allows that. Still, the smarter thing to do would be to use the Rec. 709 luma coefficients.

2- In regards to pedestal and 7.5 IRE setup...

Hopefully this clears up any confusion:
http://glennchan.info/articles/techn...5IREsetup.html