FCP 6 ProRes Export Produces Gamma Jumps in QT Player

[Gary Adcock]

When I play the movie back in QT Player (7.6.4 or 7.6.6 on same machine or a different machine makes no diff) the movie has jumps in gamma level in the vicinity of dissolves (15f, 1 per 64f) .

RT extreme always renders @8bit, your RT renders is not forced into 10 bit until you use the HQ or 4444 version of ProRes.

What was your originial acquisition format?

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Technology Development
Quality Assurance Assistance

Chicago, IL

https://blogs.creativecow.net/24640

[Jeff Coleman]

I’m missing the relevance of RT Extreme in this case.

Original acquisition is a mix of ProResHQ and ProRes footage.

[Neil Sadwelkar]

I’ve observed this in FCP 6.0.x. With an HD 1080p24 ProRes sequence with subtitles. It would jump in brightness in this sections that subtitles. Strangely, the exported QT showed these artifacts within QT Player on the Mac screen. But the same expiated QT when imported back into FCP nd played out as video in a timeline out through a Blackmagic Multibridge, it was clean.

Could be wrong but I haven’t seen this in FCP 7.0.2

———————————–
Neil Sadwelkar
neilsadwelkar.blogspot.com
twitter: fcpguru
FCP Editor, Edit systems consultant
Mumbai India

[Jeff Coleman]

Neil,
Thanks for the post.
Good to hear a confirmation.
I too haven’t noticed this in FCP 7.0.2.
Thanks again.

[Jeff Coleman]

notice Fredy’s similar problem in this post:
https://forums.creativecow.net/thread/8/1094526

[Gary Adcock]

[Neil Sadwelkar] ” With an HD 1080p24 ProRes sequence with subtitles. It would jump in brightness in this sections that subtitles.”

[Jeff Coleman] “I’m missing the relevance of RT Extreme in this case. “

do you have RT extreme turned on in your timeline?

if so you are using it for all of your renders, that is where the problem lies since your codec is 10bit but you are telling the time line to render in 8bit by using the RTX engine. The addition of the subtile has triggered the gamma issue because titling is seen by FCP as an RGB+ alpha file, and those are issues not fixed until FCP 7.

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Technology Development
Quality Assurance Assistance

Chicago, IL

https://blogs.creativecow.net/24640

[Jeff Coleman]

Let me see if I have that point correct regarding RT Extreme in FCP.

If I create a 10bit timeline (ProRes, Uncompressed, etc.),
BUT I have RT Extreme turned on, then my movie output will be rendered as a 10bit movie from 8bit renders within it? The clip is 10bit, but that effect between them is rendered as 8bit. When QT Player sees a 10bit clip against an 8bit render the gamma jumps. When Compressor or FCP see it, they’re happy as clams. In other words, it doesn’t matter what the timeline codec is (in terms of bits), or what you’ve set the video processing tab to be (again in terms of bits) as long as RT Extreme was turned on when you rendered any effects. So RT Extreme trumps Video Processing settings?

Have I summarized accurately?

How do you turn off RT Extreme? My selections are “Safe RT” or “Unlimited RT”. I don’t seem to have an OFF selection.

[Gary Adcock]

[Jeff Coleman] “If I create a 10bit timeline (ProRes, Uncompressed, etc.), “

OK. there is no RTX with uncompressed formats.

[Jeff Coleman] “BUT I have RT Extreme turned on, then my movie output will be rendered as a 10bit movie from 8bit renders within it?”

not the video itself, but anything that is generated or altered( filters or CC) inside of FCP may be effected, ESPECIALLY when working with FCP6 that is still using the older QT engine ( and while Neil in FCP 7 is not seeing the same issues)

“When QT Player sees a 10bit clip against an 8bit render the gamma jumps.”

The graphic overlay is at the heart of the issue, internally graphics are created as RGB+alpha-

Add that RGB data and that transition between clips would be something that highlights the gamma issue since you are moving from a 10bit PR image + an RGB graphic into an 8 bit transition (due to RTX processing) and then back to 10bit video content –

Anytime that QT jumps from 10bit to 8bit around a RGB clip there always seems to be issues.
Note that the QT player always plays back as 8bit on both platforms.

[Jeff Coleman] ” So RT Extreme trumps Video Processing settings? “

You overrode what you thought were your settings were by using the RTX engine, you told the app that it was OK to handle everything at 8bit.

You made a decision- it gets down to do you want speed or quality?

Avid, Adobe and Apple all handle video processing in this general manner with regards to 10bit material with accelerated video processing. as Neil said FCP 7 does solve a good number of these color conversion issues.

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Technology Development
Quality Assurance Assistance

Chicago, IL

https://blogs.creativecow.net/24640

[Jeff Coleman]

Thanks for that clarification.

How do you turn RT Extreme off then (see previous post)?

[gary adcock] “you are moving from a 10bit PR image + an RGB graphic into an 8 bit transition (due to RTX processing) and then back to 10bit video content -“

I’m not. I’m just dissolving from a 10bit ProRes to a 10bit ProRes, perhaps at times dissolving from a 10bit ProRes to a 10bit ProRes(HQ). Color correction is applied to the clips.

Why does FCP and Compressor play that movie back with no gamma shifts, while QT Player 7 does show gamma shifts?

[Jeff Coleman]

The venerable Mr. Jordan has provided the following answer to the question regarding how to turn RT Extreme Off.

“You turn off RTExtreme by going to the top left corner of the Timeline and setting the RT Menu to “Safe” and make sure the top setting says “Dynamic” and the bottom setting says “Full” or “All.”

This is how I’ve had my settings:

So I think RT Extreme has been off this whole time. While this has been an enlightening discussion, I don’t think it’s shed any light on this particular issue.