Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Apple Final Cut Pro Legacy My New Year’s Resolution to fix Final Cut Pro

  • My New Year’s Resolution to fix Final Cut Pro

    Posted by Jack Tunnicliffe on January 10, 2009 at 7:20 pm

    I am determined to resolve the gamma and color shifts that plague Final Cut Pro when round tripping to After Effects, Motion and other applications that convert YUV to RGB and back. I will head up the charge but I need your help as Final Cut users because Apple will simply ignore one voice but will find it difficult to ignore a community.

    Some history. Our facility has used Final Cut since its inception. Before that we used Media 100. Our voyage into HD was with the Digital Voodoo card which functioned in RGB so round trips were never an issue. When Final Cut moved to more of a YUV model we switched to AJA and we currently run Kona 3 in several suites.

    As we were doing ongoing series that required much compositing and effects work, round trips to applications like AE, Motion, etc, were paramount. One film series is posted in HD and we dust bust the entire show, painting individual frames that automated systems don’t fix. To fix a fleck of dust in a shot we only want to replace one frame, not the entire shot, so again the round trip must be perfect. Unfortunately the round trip was horrible using the Apple Uncompressed 10 bit codec. The result was a color and gamma shift.

    To resolve the problem we talked to the engineers at AJA. I can’t say enough about these guys. Their tech support is unmatched. If we ever have a problem with a card we have a replacement the next day without issue. So, we talked to their engineers but they couldn’t do it on their own as they would have to work with Apple engineering. I used up a big favour and a friend got me through to the product manager for Final Cut at the time. He agreed to have Apple engineers work with AJA to resolve this issue. I believe the only reason I was able to push this through was because the same colour and gamma shifts that happen in AE and other applications also happened when using Apple’s Motion, as it also functions in RGB color space.

    Out of this came the AJA v210 10 bit uncompressed codec and an 8 bit codec which does the round trip YUV/RGB/YUV conversion mathematically, perfectly. With this codec a single frame repair can again be cut back into a FCP sequence without issue.

    Unfortunately this codec does not fix the entire world of problems. As a post facility we attempt to remain in a 10 bit uncompressed world for everything we do as we know we can maintain the quality throughout the process. Where this falls down is that we are delivered productions to finish that are DVCPRO HD or HDV, etc by Indy producers with low budgets.

    Rendering HDV or DVCPRO footage through AE results in colour shifts. Using a huge uncompressed v210 (uncompressed 10 bit) codec to go round trip does not make sense. The files are huge compared to the source files and of course they are not real time and have to be re-rendered back in Final Cut Pro to play in real time.

    I am currently beta testing a new product for a Swedish developer. I can’t tell you any details as I would be breaking the terms of my non disclosure agreement but I can tell you that they are appalled with the Apple codec issues. Passing a 10 bit uncompressed export through their product results in the same old gamma or color shift issues going back to Final Cut. They have attempted to do their workaround for the codec, but to date have not resolved it.

    If you open a 10 bit sequence and look in the color tabs Apple even has a disclaimer that re-rendering YUV material in an RGB color space may result in color shifts. How many other applications are functioning in YUV colour space. I don’t own any others. There has to be a way to do the conversion accurately.

    Back to my friends at AJA for help. I now call it their formula for Cocacola. The big secret to do this conversion. I asked if they would release their engineering notes to the Swedish company so I could use their product. I was told the problem with the codecs was Apple’s responsibility and you know what, it’s true. What else is a codec to do but retain accurate colour and gamma information throughout a post process.

    Are we the only facility in the world fighting these issues. Sometimes I think so. We have to create workarounds for DVCPRO and HDV footage. We can’t use a wonderful new product from Sweden, even with v210 codec from AJA so I am very frustrated. I would love to hear from some others and if you are interested in pursuing this with me, I will once again attempt to talk to the Apple product manager and ultimately the engineering staff to try and fix these problems.

    Would love some feedback on this post.

    Thanks,

    Jack Tunnicliffe
    Java Post Production
    Canada

    Jeremy Garchow replied 17 years, 3 months ago 7 Members · 33 Replies
  • 33 Replies
  • Archie Cruz

    January 10, 2009 at 7:54 pm

    Not sure why you would need to convert from YUV to RGB so as to use Photoshop. Can’t you simply import files to Photoshop in LAB color space? That should preserve your colors when you export back out to Final Cut, unless FC doesn’t recognize LAB color space. Just a thought as I only edit color in LAB in photoshop. This gives me the best finesse of color control & Gamma so that I can convert to CMYK for pre-press or RGB for Web.Never done the round trip thing to Final Cut though.

  • Jeremy Garchow

    January 10, 2009 at 8:24 pm

    As a test, remove the AJA Uncompressed codec from LIbrary > Quicktime before you launch After Effects.

    Launch After Effects.

    Render.

    Check it out. This is presuming that your media does not have AJA UC as it’s codec.

    Jeremy

  • Jack Tunnicliffe

    January 10, 2009 at 11:24 pm

    Interesting concept. I’ll give that a try. Also, there was a response where the reader was confused about Photoshop. I never mention Photoshop in my original post, only Adobe After Effects and motion for doing motion graphics with video. However as it was mentioned, last time I tried exporting video to the extended version of CS3 I also got a gamma shift.

  • Dino

    January 11, 2009 at 1:30 am

    Hear hear. I agree with and thank you for everything in your post. I too am astounded at what has been an 8 year battle to move media between Final Cut and other applications. The idea that at this point there are still problems with most any workflow, unacceptable. QuickTime help create the desktop revolution. Now it seems to be the source of much frustration. Unfortunately, I think it has become baked into the process. I see most people pay it no heed and just accept what ever ends up in their timeline.

    When it actually becomes a problem for someone I am then stuck with the difficult task of explaining to them (probably with their client in the room) that they have been wrong all along and need to convert the files in After Effects, maybe add a gamma adjustment. Oh, but they don’t know how to use AE!

    This is one of those areas that I have to give the nod to Avid. the Avid process is inherently more time consuming. The upside being the results are generally proper. Plus, Avid provides realtime support with embedded alphas. the only way I can even get an embedded alpha into FCP is with a codec that will give me a gamma shift, plus, I have to render. I’ll take the import and export time on the Avid side.

    Now wait, this isn’t just Apple bashing. Avid sucks in all kinds of ways too. It’s just, when Avid is right on something, it’s usually a big something. Ideally for me, both programs would end up awesome and moving between all the different tools I use would be seamless. Chances are though, a big part of that would be through the use of QuickTime. If Apple could just finally come up with a valid framework to deal with identifying and adjusting any of the RGB and component structures…

    Actually I’d like to see a lot more from QuickTime. Why isn’t there a universal metadata framework that all the apps use? Things such as timecode, frame-rate, pixel aspect, tape name, etc… these should be accessible and editable. Easily. We are past the point where proprietary should force a platform choice. Everything now is both proprietary and universal. It does me no good if there is a ‘more right’ codec as chances are I will have deal with five or dozens of formats and codecs on any one project. Lets have it so that all of them are right.

    Peace.

  • Rafael Amador

    January 11, 2009 at 4:44 am

    [Dino Sanacory] “the only way I can even get an embedded alpha into FCP is with a codec that will give me a gamma shift, plus, I have to render.”
    You have” Sheer” as well.. You will need to render back in FC off course, but at least no Gamma problem, files half the size of Apple/AJA 10b Unc, and always with Alpha available. Also play in PCs.
    Probably the best available option in the market but no Apple support at all.
    Cheers,
    Rafael

    http://www.nagavideo.com

  • Jack Tunnicliffe

    January 11, 2009 at 5:55 pm

    When exporting footage from Final Cut I almost always use Automatic Duck. In After Effects I get all the Final Cut Layers, transitions, some effects, markers, etc. In this way there is not conversion of the media, AE is accessing the source media files. Also handy for when you collect and archive a project as all media files are collected. Photoshop is another issue. Didn’t think I would get into that one on this thread. It wasn’t mentioned in my original post.

  • Jack Tunnicliffe

    January 11, 2009 at 6:10 pm

    Peace, like wow! We’re definitely on the same page. I was so happy to read your post this morning. We’ve felt like we’ve been living on this little island and everytime we ask somebody else about these issues they go, we don’t see any problems. We see colour and gamma shifts in everything we do outside the one and only workflow that works. I speak of the AJA v210 codec. We’ve created levels pre-sets that we apply in AE to compensate for a render back to FCP. It’s just so depressing some days. We have so much to get done and yet have to fight all these little issues along the way.

    And then there are the After Effects issues, too. To run AJA files through properly you must remember to use None for your color set up and select the “use legacy quicktime” setting in project settings or your gamma is totally messed up in CS3. I was working on an HDV project last summer and I almost went nuts. There was no way to get files to go round trip without a gamma shift. Adobe finally admitted there was a problem with HDV round trip. Grrrrrr! It still hasn’t been fixed as I tried it the other day. Maybe we’re supposed to all buy CS4 to get the fix.

    We have so much invested into FCP suites I can’t ever see us switching over to AVID. I started on Avid when non linear first came along and I’m never going back. I liked Media 100 but then they fell apart as a company and couldn’t keep up with quality and along came FCP which allowed us to work uncompressed and HD. Anyway, that’s another story for another day but lets try and band together and get some Quicktime issues fixed.

    Jack

  • Archie Cruz

    January 11, 2009 at 6:50 pm

    My fault. I didn’t read the original post carefully enough.
    Sorry about that.

  • Rich Rubasch

    January 11, 2009 at 8:11 pm

    Same problem here too. I thought we had a DVCPro50 workflow that was solid, but I’m not sure. My question: What is Adobe’s role in getting this fixed? Should AE be updated to work natively in YUV color space, since most of what it does originates in YUV? Surely Apple is the core of Quicktime and the management of codecs, but how about apps that use QT as a wrapper? What is their responsibility?

    So you have Apple, AJA, and Adobe. And it seems this is in the most basic sense, a math problem.

    In my opinion, AE has to be updated to natively work with any particular codec and retain it’s gamma and color balance. I think Quantel is one of the big guys who figured out how to work natively in YUV. I know that the AVID codecs allow you to flag a clip with either RGB or YUV space. Seems to work pretty good.

    It is my opinion that we have had Quicktime and Codecs for more than 15 years or so and we still haven’t bullet-proofed it. Why is it taking so long?

    Color shifts are one of those things that make you feel like you are editing on a toy, and to a client it makes you look like you don’t know what you are doing. My earlier thread about scaling HD footage in an SD sequence is another one of those things.

    Big question…..will Apple engage this dialog and actually seek a proper solution?

    Rich Rubasch
    Tilt Media

  • Jack Tunnicliffe

    January 11, 2009 at 8:22 pm

    Thanks for your post. Will Apple engage? I don’t know but if we don’t try I swear nothing will ever happen. That’s why I made it my New Year’s resolution. I don’t have the time. I am a really busy person and that’s mostly due to inability to accept compromise. My clients appreciate that we are perfectionists about every aspect of what we do, but damn it’s hard in a Quicktime world.

    I do have a few inside contacts. I can sometimes get a message to people who will carry the torch but I don’t want to even attempt until I know there are others like yourself who are truly concerned.

    AE in YUV. I think that’s a great suggestion. Why not? I’ll post something on the AE user list today and see if I can start some dialogue. They have all this color management built in now so why not YUV color space. Maybe it means re-writing AE from the ground up? What about other applications that only work in an RGB color space. It still wouldn’t solve that problem. The majority of what we do is in AE outside of FCP but there are a handful of other applications that work in RGB space.

    Monday I will run the test with removing the AJA codec to see how the 10 bit uncompressed codec round trips without AJA involved. We’ll go from there.

    Jack

Page 1 of 4

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy