Gamma Shift - None QT to 10bit uncompressed?
by Joseph Barnett
on
Oct 13, 2009 at 10:09:59 am
Hello,
Im hoping you can help me this is a problem ive been sniffing around for some time. We are a post/ VFX house that works in RGB and internally we communicate with DPX frames. Normally this is what we deliver, recently though we are getting more involved in TV masters and more clients are asking for QT on delivery.
Problem:
I cannot create a 10bit uncompressed QT from a None QT without a shift in Gamma (there looks to be some slight colour movements as well
-Programs used: FCP (AJA knoa 3)/ scratch/ fusion/ QTpro / Compressor
What i know:
A None QT works in a RGB colour space (therefore maintains our picture quality) the problem occurs going from RGB to YUV. The codec that keeps popping up for request is the Blackmagic 10bit. As far as i know this is the V210 codec which is the same as: aja uncompressed 10bit and apple uncompressed 10 bit. It is just how your software/ card decodes the qt. I have heard of people utilizing their HDSR deck, dumping to tape and capturing back. This apparently works but im after a software solution if anyone has one. Please do correct any of my statements if you know otherwise, this is info i have gleaned from many sources.
Re: Gamma Shift - None QT to 10bit uncompressed? by Rafael Amador on Oct 13, 2009 at 11:22:44 am
Hi Joseph,
Gamma and Color spaces is a big mess in QT and FC.
Try AE. Can properly handle those issues. FC don't.
[Joseph Barnett]"The codec that keeps popping up for request is the Blackmagic 10bit. As far as i know this is the V210 codec which is the same as: aja uncompressed 10bit and apple uncompressed 10 bit." Right. So to have all those QT Component together only cause problems.
Put the BM and AJA Uncompressed Component out of the QT Folder.
[Joseph Barnett]"A None QT works in a RGB colour space" Animation is the same but makes the files much, much smaller.
Rafael
Re: Gamma Shift - None QT to 10bit uncompressed? by David Roth Weiss on Oct 13, 2009 at 2:22:58 pm
None is an outdated legacy codec that really isn't being used any more. It's well known for its issues and huge unnecessary file sizes, and that's about all.
David Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los Angeles
POST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW's Apple Final Cut Pro, Business & Marketing, Indie Film & Documentary, and Film History & Appreciations forums.
Re: Gamma Shift - None QT to 10bit uncompressed? by Bram Tulloch on Oct 14, 2009 at 6:26:25 am
I'm not sure about the MAC world (I've just been trying to find the same settings on our Final Cut machine), but on our Premiere CS4 seats, we have AJA Xena 2K cards (same as Kona 3)
When we render out an AJA v210 quicktime out of QTPro or Adobe media encoder, there's an option to render CGR or SMPTE.
When we render SMPTE there's no gamma shift. CGR scales the values which is what is causing the gamma shift you're seeing.
What's happening is the YUV codec is scaling your RGB DPX frames to within broadcast limits.
In the Kona Control Panel, there's a "codec" tab which refers to colour space. Maybe try playing with those options and re-encoding. I'm not sure if these setting affect just the output of the card, or the encoding to the card's codecs, but it's worth a shot.
Re: Gamma Shift - None QT to 10bit uncompressed? by Joseph Barnett on Oct 14, 2009 at 11:35:19 am
Thanks for the input guys,
Ive been testing all morning with different options, I'm still yet to achieve a accurate conversion.
'When we render out an AJA v210 quicktime out of QTPro or Adobe media encoder, there's an option to render CGR or SMPTE. When we render SMPTE there's no gamma shift"
I only have options for AJA RGB in both FCP and Adobe media encoder. though interestingly if use the apple 10bit uncompressed it is far closer than FCP's attempts.
I will report back if i find the magic formula. I'm also looking at FFMPEG as an option.
Re: Gamma Shift - None QT to 10bit uncompressed? by Joseph Barnett on Oct 14, 2009 at 3:54:59 pm
Okay i have a near seamless workflow. If i use CS4 adobe media encoder i can get a nearly a perfect match. I'm assuming that this is because the media encoder is referencing the Aja card so therefore a hardware conversion. Either way it works and i managed to get our flint guy create an ouput and they are both exactly the same (using a difference matte you can see a tiny shift).
Another thing i came across is FCP use of 'NONE'. When i imported a none qt of the same media it appeared brighter and the scopes shifted accordingly. Where as the gluetools dpx import seemed to be accurate. But if use the same workflow i used before in adobe media encoder but use a 'NONE' qt instead of DPX frames i still get exactly the same conversion of the 10bit. So the interpretation of the 'NONE' file in FCP is incorrect. I'm getting the feeling that FCP really wants to work in a YUV space.
