Vegas -> FCP -> Vegas RoundTrip levels issue?

fausseplanete wrote on 7/4/2010, 2:49 AM
Given a project in Vegas, want to use FCP's SmoothCam to smooth/stabilize a shot. So I exported the clip to Cineform Neo HD fornat inside QuickTime wrapper. NextI I copied that to HFS+ partition (so FCP-SmoothCam can write its movement analysis file alongside it). Then ran FCP with SequenceSetting=ProRes (as only have Cineform decoder, not encoder, on the Mac). Then in FCP applied SmoothCam effect. Exported that to a QuickTime movie (ProRes). Then copied that to NTFS partition (so Vegas can write its files (sfk/sfl etc.) alongside it). Then in Vegas did a Media Replace.

BUT the replacement media looks darker and more saturated than the original. It is fixable by ColorCorrector etc. I know but presumably at some loss of quality.

Any idea how to fix this "levels & saturation change" issue? Am aware of DNxHD (and will try that at a later date) but would still like to know what the problem is .

Tried other deshaking methods but not as good, for this particular footage.

Comments

musicvid10 wrote on 7/4/2010, 11:09 AM
The problem is the gamma difference between Windows (2.2) and Mac (1.8) standards. The shift is caused by the codecs. You import 2.2 and export 1.8, and the difference will be noticeable.

DNxHD solves the problem by being entirely consistent, at least in the transfer to->from FCP.

That's the 10 cent explanation anyway. Perrone Ford can give you a more detailed response.

A couple of tips re DNxHD:
-- 709 color level assumes 16-235, and RGB assumes 0-255.
-- Use the TR option when encoding source material that is anything other than square pixels. It offers a theoretical advantage.
fausseplanete wrote on 7/4/2010, 1:21 PM
Thanks musicvid, looks like its sensible to go with the DNxHD flow...

Following your reply, I googled [mac windows gamma standards] and found http://www.kenstone.net/fcp_homepage/gamma_mac_pc.html which shows how to mash it back using gamma and levels.

But if DNxHD is interpreted in a standard way on both systems then I'll go that way.

I haven't quite got my head around what exactly what interprets the gamma differently. Does it happen in the codec(s) ie Cineform and Prores - I expected them to follow a consistent decode algorithm. Or is it just in FCP etc.?

David Newman wrote on 7/4/2010, 4:37 PM
It is not a codec issue, it is the 8-bit RGB mode with FCP that get the gamma wrong. If you use deep YUV 10-bit or floating point rendering in FCP (using the CineForm codec) the issue goes away. Gamma issues + FCP + Quicktime are a well known issue.

David Newman
CTO, CineForm
Coursedesign wrote on 7/4/2010, 5:37 PM
The problem is the gamma difference between Windows (2.2) and Mac (1.8) standards.

That is correct for Mac OS X versions prior to 10.6.

10.6 Snow Leopard uses 2.2 gamma, so it's the same as Windows.

Now for After Effects with different codecs, that requires some thought (Adobe has major articles on their support site, as they didn't keep their codec info up-to-date).
musicvid10 wrote on 7/4/2010, 5:43 PM
David,
Thanks for adding depth and clarity to the discussion. Your 25 cent explanation is better than my 10 cent explanation.

Since maybe one in a hundred of my projects actually sees a FCP suite, I just go with what works. It is nice to know that Cineform also can work with FCP given the right render settings.

Now this raises a question for me -- will 8-bit RGB renders in DNxHD show the same problem?
PerroneFord wrote on 7/4/2010, 9:22 PM
According to the Mac folk I know on SL, even though the OS gamma has changed, the gamma shift issue STILL presents itself in FCP/ProRes. And is apparent when round-tripping even inside the FCS suite. Apple REALLY need to fix this. it's been a LONG standing problem.
PerroneFord wrote on 7/4/2010, 9:24 PM
I have not done a round trip with Cineform because I can't write the codec, but my 8-bit DNxHD files have not suffered the gamma shift issue at all. I did this on a film in the fall when I was handing off comps to an FCP user that I had colored in Vegas and encoded with DNxHD 36.
Coursedesign wrote on 7/5/2010, 11:56 AM
...even though the OS gamma has changed, the gamma shift issue STILL presents itself in FCP/ProRes

With FCP6 (previous version) in Snow Leopard, there are a few issues for the unwary.

With FCP7 on SL, there are issues with ProRes 4444 in particular, but few use that, and those who do are familiar with the proper settings in FCP that are meant to be used for this.

There are a lot of completely self-taught people also in FCP, and they frequently blame the software when they don't know how to use it (just like in this forum :O).