AE render weirdness in FCP5

[Felix Mack]

Hi –

sure, there is going to be some change from the rgb – yuv conversion, and that is to be expected. However, what we are seeing is a drastic gamma shift – something that never happened with FCP4.5 and quicktime 6. So this is a new issue. Before FCP5.0 the conversion was pretty tight. Now the files turn out considerably brighter than they should.

Thanks,
Felix

[Peter Litwinowicz]

[Felix] “sure, there is going to be some change from the rgb – yuv conversion, and that is to be expected. However, what we are seeing is a drastic gamma shift – something that never happened with FCP4.5 and quicktime 6. So this is a new issue. Before FCP5.0 the conversion was pretty tight. Now the files turn out considerably brighter than they should.”

Actually, in the test case you mentioned (a grey ramp going from 0 to 255) there *should* be no change in rgb to yuv. Y is sampled every pixel, and has 8 bits to boot. It’s when there’s some chroma involved that you will start seeing the problems. In fact, when reporting bugs to Apple and Adobe on this front, I often resorted to a grey scale ramps simply to elminate the YUV<->RGB conversions they told me were probably to blame.

Of course, know that doesn’t solve your problems with gamma that you seem to be having.

Pete Litwinowicz
https://www.revisionfx.com

[Peter Litwinowicz]

[Felix] “over in the blackmagic forum we are having some weirdness with FCP5.0 and AE. It looks like RGB files rendered out of AE into 10bit quicktimes come out brighter than they should once imported into FCP5.0. Video captured from FCP5 put into AE and rendered again seems to come out fine.”

Oh, now that I reread your post I think I might be able to shed some light on this

FCP assumes that RGB input sequences have 2.2 gamma and YUV input sequences have 1.8 gamma. Upon input into FCP, FCP is converting the RGB input from a gamma of 2.2 to 1.8 when it does the RGB to YUV conversion. (so it is related to a RGB<->YUV conversion, but it is not tha RGB<-->YUV conversion per se, but QT codec conversion that assumes the two have different gamm).

However, I’m confused. You say that you output 10 bit QTs from AE in an RGB format. Didn’t know that was possible to do with an RGB format. Go figure. If FCP isn’t causing the problem, perhaps the RGB to 10 bit QT within AE is causing the gamma shift (not AE’s problem per se, but a system related QT conversion problem within AE that may be the codec’s or QT’s fault).

You are not seeing this problem with images captured in FCP, because FCP is capturing in YUV format already, which will have an assumed 1.8 gamma when you export it and reimport it roundtrip through AE.

Pete

[Felix Mack]

HI –

sorry, I didn’t mean to make it sound like I am making 10bit RGB qt files – what I meant is that RGB based items, such as PSD layers and stuff created in AE, which are then rendered to a 10bit YUV quicktime, get the gamma shift. For example, if I have a video captured in FCP, add some graphics to it in AE and rerender to the same codec, the video will show up fine in FCP, but all RGB elements that were added will have a gamma boost.

This was never a problem in FCP4.5 using the blackmagic codecs. Gamma was consistent between AE and FCP. I’m not sure I like that FCP or QT make ‘assumptions’ about gamma. I want them to not touch it at all and leave it to me to decide what I want.

As you said, FCP converts gamma for RGB inputs, which is annoying enough, but when I input qts from AE, they are already YUV 10bit qts – so it shouldn’t really do anything to it. I’ve noticed this gamma shift has been an issue across many an apple app, including DVDSP, Compressor and the DV, as well as 8 & 10bit uncompressed codecs. I just wish there was a way to switch this ‘gamma mangement’ off.

I have to match RBG stills with YUV Video files daily, which is frustrating enough – I don’t like the extra headache of worrying about different gamma in each app. . .

It was all good back in 10.3/FCP4.5, and I am seriously considering downgrading to avoid the whole hassle.

I apologize if this post sounds pissy, but this whole thing has been going on for a few months now with no solutions in sight. Any help is appreciated.

[Peter Litwinowicz]

Actually, you don’t sound pissy to me at all.

The fact that some codecs do “automagic” gamma correction, and some don’t , and some apps do and some don’t is very confusing and often counterproductive. Based on what you report, there also a dependency on what version of the app you are running. Like you, I feel there should always be a setting (for codecs and apps alike) that is basically “I know what I’m doing, please don’t touch the original values” setting.

I feel your pain.
Pete