Eric, you can see it pretty clearly. Create bars, and then reimport them. You'll see the shift. It's not huge, but it's there.
FWIW, the movie Dust to Glory was done with the Cineform codec, and the 35mm print came straight from the original files in the Cineform codec. The codec is THAT good.

Spot, is this an issue caused by a YUV to RGB and back conversion in the Cineform codec?

John

I don't know that's what it is, John. I suspect so, but not certain. If it is, it's just a matter of remapping, so hopefully it's not a big deal. Like I said, Sony is working on it, but we wanted to offer a "patch" now rather than wait.

Spot,
This issue has been discussed in great detail on SonyHDVInfo.com.
I'll post the link as soon as the board goes online again (it's currently offline).

The difference you see is related to ITU 601 colorspace versus 709 colorspace.
Cineform's codec will transform the 709 colorspace of the original HD m2t-file into 601 to make it compliant with the Vegas timeline.
Hence when exporting to HD-m2t Vegas should reverse the process - but it doesn't. Even though ITU 709 is listed on the "Advanced Video" tab for "Color Primaries" and "Transfer" those are just flags and don't trigger the actual conversion.
I assume Vegas 6 will solve the issue.

For the meantime David Newman of Cineform was so kind to present the following parameters for the Channel Blend filter that will reverse the color space transform:
Red 0.772 0.081 0.006 0.000 0.061
Green -0.081 0.996 -0.055 0.000 0.063
Blue 0.009 0.044 0.806 0.000 0.061
Normalize Rows off

While we're at it:
There is another issue with both CFDH and HD-m2t files that one should be aware of: Both formats come in ComputerRGB.
If you want to render your timeline as HD-m2t than that's just fine.
However for everything else (WMV, HD-Program-Streams, ...) you should apply a ComputerRGB to StudioRGB filter.

Please note that I don't use your VASST software. So I haven't been able to determine if your preset does the same thing.
Martin

First, you don't need the VASST software. It uses the FX chain features of Vegas.
Second, David got those numbers (I believe) from Mark Dileo.
I know what the problem is, the problem isn't the problem, it's the fix I was more interested in taking care of.
I've not spent much time on the SonyHDVInfo.net site, too many forums to visit as it is. :-)

Quote "I don't know that's what it is, John. I suspect so, but not certain."
Quote "I know what the problem is, the problem isn't the problem"
Please forgive me for not being able to follow you ;-)

Quote "it's the fix I was more interested in taking care of."
You've got it.
BTW, here's the link I promised: http://www.sonyhdvinfo.com/showthread.php?t=1007
As you can see I spent quite some time testing these things. The filter performs nicely.

What I mean to say is, I don't know where in the remap it's entirely gone wrong. There are two issues at play;
1. YUV to RGB
2. 601 to 709. (which is YUV only anyway)
So, two different maps, and Cineform is handling some of it, and Vegas is handling some of it. I don't know which is more responsible.
Again, I've not looked at your post on Sonyhdvinfo.net. It's a slow site and I'm on dialup, so haven't chased it down. I have talked with both David's at Cineform extensively about the issue, and have talked to the Sony guys as well. Cineform has a very good 601 to 709 conversion. But question is, is it just the RGB/YUV issue, or is it a combination of both issues and how they work together. Further, there are gamma issues that could be in play from either side of that fence too. So, there are too many issues for me to be willing to say "XXX is the exact problem and it's XXX's fault." having worked with the Cineform tool in another application, I suspect the problem lies with Vegas only.

I have also suspected an issue with gamma correction since there *is* a significant difference between 601 and 709. But it wasn't the problem.
However I'd like to add that there's a another issue when using native m2t-clips on the Vegas timeline (709 to 601 transfer need's to be done by another Channel Blend filter).
Again - when you find time for the thread on SonyHDVInfo.com there's much more on this.

But the bottom-line is: I've tested the two ChannelBlend-filters for CFHD-avi and m2t extensively (just as Cineform did, I suppose ;-). In the process I've not only looked at color (vectorscope) but at gamma as well (waveform-monitor and 1:1 comparison with color bars from a standard DV-camera). The correction looks perfectly fine for me.

That's what I'm hoping to hear from others too. Looks good to me, but with a variety of people testing a variety of images out there...is the more telling thing.

Ok, so now you got me really interested (forgive me - I'm only an electrical engineer with a huge instinct for playing ;-)

Here's what I did:
Certainly you know the nice, computer generated HD-testcharts from http://www.belle-nuit.com/testchart.html.

1) I loaded the chart on the timeline (project setting HDV) and took a frame grab.
2) I applied the suggested ChannelBlend filter
3) I rendered the chart as HDV-MPEG2-TransportStream using the supplied template.
4) I transcoded from HDV-m2t to CFHD-AVI using HDLink.
5) I loaded the transcoded avi on the timeline and took another frame grab.

Then I repeated the process but this time I omitted step 2).

In an ideal world you would expect the first two frame grabs to be identical and the third frame grab (without the filter) to be somewhat off.

Here are the results as found in various color and b&w areas of the chart by using the pipette-tool of my favorite photo-editor (all numbers are given (R,G,B)):

Original -> Transcode including ChannelBlend -> Transcode without ChannelBlend

(255,255,255) -> (255,254,255) -> (255,254,255)
(251,251,251) -> (250,249,250) -> (255,254,255)
(239,239,239) -> (239,238,239) -> (255,254,255)

(235,235,235) -> (235,234,235) -> (255,254,255)
(231,231,231) -> (230,229,230) -> (250,249,250)
(208,208,208) -> (207,206,207) -> (224,223,224)
(181,181,181) -> (180,179,180) -> (192,191,192)
(153,153,153) -> (152,151,152) -> (159,158,159)
(126,126,126) -> (126,125,126) -> (128,127,128)
(098,098,098) -> (098,097,098) -> (095,094,095)
(071,071,071) -> (071,070,071) -> (064,063,064)
(043,043,043) -> (043,042,043) -> (031,030,031)
(020,020,020) -> (020,019,020) -> (005,004,005)
(016,016,016) -> (015,014,015) -> (000,000,000)

(012,012,012) -> (012,011,012) -> (000,000,000)
(004,004,004) -> (003,002,003) -> (000,000,000)
(000,000,000) -> (000,000,000) -> (000,000,000)

(180,180,016) -> (180,179,014) -> (194,179,000)
(016,180,180) -> (013,179,180) -> (000,173,195)
(180,016,180) -> (178,014,178) -> (209,027,199)
(016,180,016) -> (014,179,015) -> (000,162,000)
(180,016,016) -> (179,014,014) -> (212,016,000)
(016,016,180) -> (014,014,179) -> (000,010,204)

The figures speak for themselves.
Obviously the filter doesn't perform a 100% correct transfer. But it's probably much better than could be hoped for - given the problems inherent to gamma, RGB/YUV, 709/601 etc.
The results without the filter are way off.

Please pardon what might be a really dumb question but isn't the core issue here that Vegas will not work in the 709 colorspace? Ideally shouldn't this kind of conversion be done only once and only if needed to minimise the risk of errors. From what I'm reading here we're going from 709->601->709, wouldn't the problem be avoided by staying in 709 and only converting to 601 when and if I'm going out to say 601 (DVD etc) or if perhaps intercutting with SD footage?
Bob.

Yes, you are right, Bob. Sony says they're working on it.