[Felix Mack]

https://www.blackmagic-design.com/support/detail.asp?techID=78

check towards the bottom:

Blackmagic 8-bit (DV10) – this codec provides legacy support for 10-bit files in the Digital Voodoo format. This format is not compatible with v210 and should only be used when working with legacy media in this format.

[Felix Mack]

Thanks – help on this matter is greatly appreciated.

-Felix

[Felix Mack]

For the sake of science, I installed 10.3.8, QT6.5.2, FCP4.5 and BM 4.8.1 on a fresh drive.

I did the same test as before, and it is a thing of beauty. While there is still a minute shift between AE and FCP, it is negligible compared to anything I have seen on 10.4/FCP5.

A ramp from AE is linear in FCP and vice versa. RGB material from AE renders properly. All is well in 10.3.8!

So the question remains, why did this work before and now it is kaputt?

[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.

[Felix Mack]

Hmm –

I don’t think this is a QT7 issue. I just tried the ramp test on OSX 10.4 with FCP 4.5/BM4 and the newest QT 7.0.2 from today, and the ramp looks fine. This is a qt rendered to the old BM10bit codec (BM4).

Of course, you arent supposed to use FCP4.5 on 10.4, but this is just for testings sake. So I think this is all just an FCP5 issue at this point.

I’ll try the ramp test on 10.4/FCP5/BM5 with the new QT7.0.2 download next when I am back at that computer.

[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

[Felix Mack]

About Motion –

the ramp you can make in Motion seems to be very S-curvey, so it’s hard to say, but the RGB grayscale I have gets the same boost in gamma. What about your findings?

[Felix Mack]

I think I remeber trying to render the grayscale I made in PS from Motion with the same gamma shift. I’ll have to try it again to verify that, though.

I just think that this is an awesome ‘feature’ built in to quicktime. For people who use DVDSP, you’ll notice if you import a still menu you get the same gamma shift as in FCP. So it’s probably more of a global quicktime issue.

More on Motion after I test it out.

[Felix Mack]

Hi –

thanks for trying it out.

However, both BM10bit and the Apple codec introuce the gamma shift to rgb material from what I can tell.

If you go try the same test on a FCP 4.5 system, you will see that the apple codec still does a gamma boost, but the Black magic 10bit codec does not. It’s new as of FCP5.0 that the BM10bit also has a gamma shift.

https://www.kenstone.net/fcp_homepage/video_levels_nattress.html

Check out the link above and see how FCP kindly introduces a gamma boost to all the stills you import into FCP.

[Felix Mack]

Thanks for checking into it.
I’ve tried some more stuff, and you are right – the new codecs preserve the gamma of video files originating from FCP5, but not rgb files from AE. I made a ramp in FCP, and added a grayscale made in PS. AS you can see below, while the video has the correct gamma, the RGB is too bright in BM10bit. The opposite is true for DV10, where the RGB is handled correctly, but the video is now too dark.

My issue is that I use AE to add titles and other graphics to video daily, so both of these don’t work for me.

Now if only we could get DV10s RGB handling with BM10s video handling, we would be happy like we were with FCP4.5