FCP > Shake & AE workflow suggestions?


#1

Hi all,

I’m hoping to open up a bit of a discussion about the best way to export files from Final Cut to Shake (and AE/Comb/DF for that matter) and then back again? Exporting is a pretty fundamental step in the process but I’m still finding out the various pro’s and con’s of the formats. I’ve searched the issue but have found little in the way of straight-forward advice on the net or through the highend mailing list.

For example, at work we’re capturing digi beta via a decklink and matching the offlines in FCP (like half the world). We would ideally like to keep the vision as lossless as possible and 10 or 16 bit colourspace. When I export from FCP as a Quicktime None Shake refuses to see the vision (recognises the duration, but the vision appears black). I’m not even sure the ‘None’ codec is 16bit. And if I try the Uncompressed 10bit QT codec I get some gamma shift between FCP and Shake, resulting in significantly darker clips once they come back into FCP (some white/super white issue I’m guessing, but don’t know how to fix). So I’ve been settling on exporting as TIFF Quicktimes, but unlike in AE7 FCP doesn’t give me the option of setting the colour depth so I have no idea if they’re going out as 8, 16 or 32 bit.

So, my main questions for anyone kind enough to shed some light on the issue would be:

  • Is it best to keep to one codec throughout the entire process (conform>comping>final assemble)? If so that kind of rules us out of using image sequences with FCP, since after we add about a dozen sequenced clips it slows to a halt and takes minutes to update a simple change.

  • Which codecs have a bona fide +16bit colour space?

  • If one was to render out sequences for Shake, what format holds the most data? I’ve heard the Maya IFF format used in connection with Shake a lot - is it more than 8 bit? I’m not concerned about space - I just want maximum quality.

Thanks for reading and I hope others won’t mind sharing any solutions they’ve found for this kind of small studio setup.


#2

What are you doing that needs to be float as a transport colour space ? Where are you working ?

Float support in FCP is limited ! We have a DI pipeline based on FCP and shake which is based around 10bit 4:4:4 blackmagic Hardware, Sony SR 1080p hardware and .dpx for shake. It’s not flawless but we are putting a fair bit of film through it !

Gamma issues between Final Cut and other apps are discussed in the release notes of Final Cut Studio. I would strongly advise using quicktime as a transport format in and out of shake. ‘None’ is generally apple animation codec, a big and slow way of transporting data.

Are you comping in float in shake ? If not this could be where you are losing data ! ?


#3

The trouble is that many YUV codecs don’t properly recognize superwhite and will chop out below 16 and above 235. The guy from Apple suggested exporting using the BitJazz codec. Also make sure you have superwhites turned on in FCP’s render settings. Sequence > Settings > Video Processing

http://www.bitjazz.com/

There is a thread on the highend listserve about this. Scroll down to the second to last answer. He lists which codecs clamp and which don’t.

http://www.highend3d.com/shake/list_servers/shake_list/archive/8691.html


#4

Thanks for the replies, guys - most helpful. The Highend thread clears a lot of things up and is duely bookmarked for prosperity.

It’s not that I’m looking to export out of FCP in float - I just want to try and make sure I’m using all of the 10 bit colour coming off digi, rather than inadvertently clamping it down to 8 bit via the export codec.

Now that you mention it I think I’ve had Shake set to 16 bit - I’ll push it up to float in future - thanks for the heads up (man, I gotta get some formal Shake training some time…)


#5

I believe he meant that you don’t need to use float, 16 bit will do.


#6

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.