Color in Vegas a bit off.

[Deep G]

http://hv20.info/yopu/what-happens-in-vegas.jpg

Does anyone know if vegas is converting the color wrong from m2t files?
Check the picture above, vegas pinks are way out, the green screen is deader.

The source is from a pal version filmed at 25p. No special pull-downs.

I had a work flow plan of editing rough footage in vegas and exporting in Uncompressed or Lossless to After Effects to do the KEYING. Editing in AE straight from the M2t files was painfully slow but now it seems I'll have to.

[mik]

do a levels studio rgb to computer rgb and see if you find it ok
the difference is in the dynamic range, vegas' is more wide. if it was narrower you'd worry.

[Deep G]

Update, I found that Premier plays back m2ts in real time and is pretty much like AE in user interface. Does the color properly.
Haven't tried your suggestion yet but my analysis showed that vegas made the green un-pure. In a photoshop eyedropper test the green from vegas had 5 Magenta in it. Where as AE and Premier had 0 Magenta. Also when you made a difference overlay of a still frame from Vegas to AE There was major clipping going on in vegas, not just a gamma shift.

[Deep G]

A bonus with the Premier / AE workflow is I can open Premier files in AE with all the cuts visible on the original m2t files. Bonus is you can tweak your original edits and also avoid an intermediate video file / render.

[mik]

interesting thing with magenta. if you could post a 2sec cut of the unaltered capture i'd like to test that green problem.

[Deep G]

interesting thing with magenta. if you could post a 2sec cut of the unaltered capture i'd like to test that green problem.

Thanks mik, the short file of my green screen setup is here...
a short mt2 file (http://hv20.info/yopu/green.m2t)

[mik]

just a small test out of vegas (vegas as frame server to test it's import).

http://sharebee.com/7a64db03

i don't have AE or premiere installed to compare but i can look for color casts anyway. the green seems around 48/144/73. the cat is black enough, no casts. there is 0 magenta on the green from vegas. did you screenshot or how exactly did you measure?

[Deep G]

The top half of the first pic in this post are frame saves from the Vegas preview window (the floppy disc icon).
The bottom half are m2t files loaded in After Effects in separate Comps. I did a windows screen dump for the bottom half and opened that in Photoshop. The top frames were opened straight into Photoshop. I could have sent frame dumps straight from AE but didn't. I don't believe there is any windows / gamma / screen-dump issues here.

[mik]

i guess it is. i've frame served the uncompressed video out of vegas and it shows 0 magenta or no other tints. gamma differences are ok, progams display differently the image, using direcx or gdi, if they support monitor profiles or not etc.
my opinion is that you shouldn't go thru additional steps, the green is just fine. but if you find strange stuff post here.

[Deep G]

Here's the thing.
What is in an m2t file? I know the HV20 has a primary RGB filter in the optics, then it gets stored in YUV color space. What gives?
What did I film? Is After Effects and Premier telling me the truth about the m2t color? Or is Vegas showing me what realy is in the m2t.

Both Vegas an Adobe have to make a color space conversion as most apps are in RGB. (premier pro can do YUV naitive editing I think)

I don't know about you but I think I'm going to trust Adobe.

Even a free program Streamclip gave me 1:1 same color as Adobe.

If you want I'll send you 2 frame dumps from vegas.

[mik]

no need.
i could only say what i do. if the project is in vegas, the frames are served directly out of vegas (or saved uncompressed) and get into combustion then frame sequence rendered. i'm in an color calibrated environment (spyder sensor) and it's all fine. you could get the vegas frame server plugin to test.

but it doesn't mean there aren't other ways. and vegas could use other gamma than premiere or others... who knows. i think i'll have premiere cs3 when it's out and i'll check some more at that time.

the footage looks very well, hv20 didn't add compression crap
http://img176.imagevenue.com/loc373/th_61177_Capture_4_122_373lo.jpg (http://img176.imagevenue.com/img.php?image=61177_Capture_4_122_373lo.jpg)

i could test from avisynth, i'll post back in a day or two and see if it's better

[Deep G]

Thanks for the help on that, perhaps your frame server gives Vegas the right rgb as I did using Stream Clip. If you could only just import an m2t file straight into the vegas timeline so Vegas can do it's interpretation of the color.

The error can be replicated on a second PC here, I tried 7.0 7.0c 7.0e all the same.

[mik]

i did import the file directly into vegas. combustion doesn't like m2t, it is slow at decoding mpegs.
then using the frame server plugin got the video out of vegas in yuv or rgb to combustion. this way you don't have to render an uncompressed file to transfer video between them. get the thing here http://www.debugmode.com/frameserver/. i really wonder why vegas is different than premiere, even if it is only gamma.

and if you really hate sony's dv codec go to options and disable "ignore third party codecs" and/or check "use microsoft dv codec". that way you'll use whatever codecs you have installed, much like other apps do

[Deep G]

and if you really hate sony's dv codec go to options and disable "ignore third party codecs" and/or check "use microsoft dv codec". that way you'll use whatever codecs you have installed, much like other apps do

Did that, no difference.

[mik]

http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html

[Deep G]

Hey good link, it doesn't realy go in to bat for Vegas in anyway. Kind of pointing out my suspicions that Vegas will have a go but "you may need to manually wrangle all your color space conversions in Vegas". (so far I have not duplicated the color space resulting from Stream Clip or Adobe m2t conversions)
My main concern was for other HV20 users who plug in their cam to Vegas and get a fudged, slightly inferior result that what could be achieved buy using other more 'smart' software.

[mik]

smarter? this is entry level video editing, basics. both are "stupid" if you ask me.

-"If you are working with studio R'G'B' levels, these levels will not look correct in Vegas' video preview. You should output your video [...] to a calibrated external monitor. "
-"If you are working with computer R'G'B' levels, the video preview window will show your image correctly."

you actually get a wider dynamic range in vegas with the default studio rgb. it's a bonus if you like, not a loss. "This color space can be useful, since it will retain a lot of the useful illegal values from Y'CbCr signals."

i agree this it should have been more explained in vegas' help but now we've solved the puzzle. don't worry. see ya :)

[Deep G]

You just helped me see the light.
Now I must see if Adobe is keeping the whole range and only showing a smaller part (dont want to loose color depth). Yet my import back to Vegas show otherwise.
Check the gif below.
http://hv20.info/yopu/color-in-vegas.gif
I can see the Premier imported avi is clipped.
I see this is all like audio mastering and music mixing eq and dynamics. Trust a musician to dive head first into a high definition chroma key music video.

[mik]

you had a great idea with that gif.

yes, always look for spikes in histogram. regular repeating spikes show a previous color correction always. no "natural" video has regular repeating spikes. also when you shoot take care not to have full black areas or overexposed. that is lost information, better have a dull, low contrast video that can be altered anyway you like than lost color information.

as a side note you would still have been able to do chroma the other way too. these are rather small differences after all.

[Deep G]

Did all the chromas in AE, saved to Lagarith lossless avi's. I did not to any levels or color on them, just produced an alpha channel. I will try to see if color info was lost on those avi's. Like you said, might not matter in the end.