Has anyone noticed luma shifts when importing RGB material into FCP recently? We've always had it here to some degree but could fix it by setting sequence video processing to "Always Render in RGB" (RGB files look brighter than YUV stuff, the old quicktime RGB-YUV error which never gets fixed... why?) That fix still works on FCP 4.5/Panther boxes but on our Tiger (5.0.4 - 5.1.1) boxes it no longer fixes it. We have a lot of machines here at various versions, on two of them I was able to fix it by setting the effect handling for uncompressed 10bit to none rather than FCP or Decklink but on two others that fix didn't work. If anyone has time please render a quicktime to Blackmagic 10bit from after effects and then export the last frame as a tiff or other rgb file (I can see it with animation codec too so you could render the same thing twice to Blackmagic and Animation codecs too), Import both files to an uncompressed 10bit sequence and see if they match, I need to know I'm not the only one seeing this,
Welcome to the small club that both sees the gamma shifts AND actually cares. Unfortunately, I don't think Apple is a member of the club. You may be seeing one of two things. There has been for a LONG time a gamma shift when importing a RGB still image into FCP. FCP assumes that your still has the wrong gamma and "fixes" it for you. There is no preference for changing this, it just does it. Does it in DVD Studio Pro too. The other thing you might be seeing is a gamma shift when using 10-bit material rendered from AE to FCP. I did a BUNCH of testing with this in the past and I think my conclusion was that the shift was actually occuring on the way in to AE rather than on the way out. It is a 10-bit bug in quicktime and/or in the BMD codec. One of my machines uses a Kona 2, and they have implemented some work arounds in their system to deal with the flakiness when rendering to 10-bit; I don't think it helps with the stills. Do a search here on the cow either for my name or for something like "luma shifts" or "gamma" and you will see much discussion on this matter.
I too think there may be a bug in the Blackmagic codec, at least the codec embedded in their drivers (but apparently not with their standalone codec). Rather than repeat myself I would refer you to my posts (and responses) starting 8 June in the thread entitled
Uncompressed 422 delivers a fix for changes in color-space and/or gamma when moving clips between Final Cut Pro and Adobe After Effects and addresses a codec issue leading to drawing errors in 16bpc After Effects projects. It also fixes discrepancies found between former AltiVec and the current Intel (scalar) code and delivers some performance improvements on Intel-based Macs.
Can it be true? Finally fixed? I would be amazed. . .