Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

DPX with FCP, can it be 10bit RGB?

Lear about gamma shift and about calibration with your monitors or projectors.

Also windows users people are really have to go to school again!!!!!!!!!!!!!!!!

Or we are all screwed with zombies as it looks that we are right now in general!!!!!!!!!!!!!!!
 
Euh...

I dont follow you Sanjin...maybe my bad english...

...I'M on a Mac... :)

...and i'm pretty familiar with monitor calibration etc...

What i'm not familiar with are all sort of codecs that are not "referenced".

Antoine
 
This is not funny here...

Both AJA files look way darker than what it was looking in Color... :(

Oh well...

Antoine

Set display preferences to gamma 2.2 when you use color and 1.8 when you use final cut.
 
Set display preferences to gamma 2.2 when you use color and 1.8 when you use final cut.

then it is my bad english...

Luca,

I never watch the footage inside FCP (artificially darkened to compensate from 1.8 to 2.2, FCP presumes you use 1.8 gamma for displays)

Again, here's what i do:

Both my 2 displays prefs are ajusted to gamma 2.2
I send footage from FCP to Color.
In Color (always with 2.2 gamma display.. :) )
I CC until my footage look the way i want "IN" Color
Then i export DPX from Color (full 0-1023)
Then i wrap DPX images in a QuickTime file using AJA DPX to QT Translator, again full 0-1023.

THIS converted AJA 10 bit RGB QuickTime file looks WAY DARKER (in a QT window, not in FCP) than what i saw in Color.(always on my 2.2 gamma monitors)
(The DPX files look OK in Photoshop BTW)
So the problem seems to come from the QT Translator itself...not the DPX

If i export from Color the VERY SAME footage in Apple ProRes HQ, There is NO gamma shift in this QT file...

Antoine
 
then it is my bad english...

Luca,

I never watch the footage inside FCP (artificially darkened to compensate from 1.8 to 2.2, FCP presumes you use 1.8 gamma for displays)

Again, here's what i do:

Both my 2 displays prefs are ajusted to gamma 2.2
I send footage from FCP to Color.
In Color (always with 2.2 gamma display.. :) )
I CC until my footage look the way i want "IN" Color
Then i export DPX from Color (full 0-1023)
Then i wrap DPX images in a QuickTime file using AJA DPX to QT Translator, again full 0-1023.

THIS converted AJA 10 bit RGB QuickTime file looks WAY DARKER (in a QT window, not in FCP) than what i saw in Color.(always on my 2.2 gamma monitors)
(The DPX files look OK in Photoshop BTW)
So the problem seems to come from the QT Translator itself...not the DPX

If i export from Color the VERY SAME footage in Apple ProRes HQ, There is NO gamma shift in this QT file...

Antoine

DPX out of Color - DPX out of FCP= No gamma shift
Aja 10 bit rgb out of Color - Aja 10 bit rgb out of FCP=no gamma shift
 
i Just realized, for my purpose, I started thinking that it doesn't matter if FCP "display" the clips with wrong gamma.

My scenario is as follows;

The director edits with proxies and provide me the offline projects.
I conform the projects and send them to Color, then DP works on Color.
As Luca suggested, use AJA 10-bit RGB software codec to send back to FCP.
Mix composited clips (in this case we are receiving CineForm 444 or DPX, so maybe convert them to AJA 10-bit RGB software codec) with the graded timeline then send to Color again.
Fine adjust the composited clips, render in Color to DPX to submit it to DI.

So, the key is to render in Color at last so, what FCP display won't really matter.

As much as we need to have these gamma issues solved but I thought FCP always act as offline and use Color to render.
 
I tested back and forth on AJA 10-bit.
Graded some stuff and render with QT AJA 10-bit RGB, sent to FCP, and simply sent it back to Color. Although there was nothing I adjusted in FCP, the clip shifted more than 5% down. Also, AJA 10-bit RGB back from FCP in Color won't render in DPX! The problems are endless.
 
Maybe for compositing, I should go back to the original FCP timeline, reconform that in Color.
 
Euh...

I dont follow you Sanjin...maybe my bad english...

...I'M on a Mac... :)

...and i'm pretty familiar with monitor calibration etc...

What i'm not familiar with are all sort of codecs that are not "referenced".

Antoine

Antoine,

once more sorry (had a two glasses of Rémy Martin at that moment),

also with a hope that now all is going well.
 
I tested back and forth on AJA 10-bit.
Graded some stuff and render with QT AJA 10-bit RGB, sent to FCP, and simply sent it back to Color. Although there was nothing I adjusted in FCP, the clip shifted more than 5% down. Also, AJA 10-bit RGB back from FCP in Color won't render in DPX! The problems are endless.

Hi Kaku,

The bad new is that the problem seems to be real...

The good new is that i dont have hallucinations... :)

Antoine
 
DPX out of Color - DPX out of FCP= No gamma shift
Aja 10 bit rgb out of Color - Aja 10 bit rgb out of FCP=no gamma shift
I know there is gamma shift in the applications (fcp, color) but the dpxs out of color are equal to the dpxs out of fcp, and the digital master is a sequence of dpxs or an uncompressed files, so if you know it will be a gamma shift inside the applications the key is to make a color correction knowing what it will be the final result outside the applications. I know it's a bit empirical but it's the only way until apple will fix the gamma issue.
 
Hi antoine,

First rule of last year is:

Every thing is possible.

First year of the new year :

Every thing is possible.

No metter how many drugs you take the gamma shift is there for real!!!!

:):):)

Karilla,

Yep...I thought sobriety was the best but...

Antoine
 
I know there is gamma shift in the applications (fcp, color) but the dpxs out of color are equal to the dpxs out of fcp, and the digital master is a sequence of dpxs or an uncompressed files, so if you know it will be a gamma shift inside the applications the key is to make a color correction knowing what it will be the final result outside the applications. I know it's a bit empirical but it's the only way until apple will fix the gamma issue.


Luca,

Yeah...both are wrong :)

The final step before the very final step. :)

Why calibrate any monitor after all...

Unacceptable for professional use.

Antoine
 
Bob from GlueTools is online now so we hope he can figure our problems out.
 
Hi Guys,

Gamma Shifting is a result of MacOSX. Its a long story, but there is very little any developer can do to fix the issues. (If you have been looking at the rumor websites for MacOSX, search for Snow Leopard and Gamma. If the rumors are true, there is a fix in store for this problem.)

As for 10-bit. Final Cut Pro most certainly does deal with more than 8-bit imagery. You can select 32-bit Floats for internal processing. Here is the trick... When exporting using the menu command "Export->Using QuickTime Conversion..." will only use 10-bit 422, or 8-bit RGB. The code for this has been static for quite some time. Apple doesn't appear to have any plans to fix this. I am guessing that the reason behind this decision, is because Compressor exists. With Compressor 3.0.5, FCP can export high quality 32-bit Float YCbCr 444 data.

CineonDPX Pro for FCS2 has plugins for Compressor. My software will take the 32-bit Float imagery, and will convert it to 10-bit DPX.

Hope this helps..

bob.
 
Bob,

Thank you for the update, we need a person like you active in this forum, just like guys from CineForm. I can't go without CineForm and Glue Tools in processing R3D on Mac.
It's great for us users to be informed with structural possibilities and limitations from third party developers, so we know what we can expect.

Bob, what do you think it's the best way to monitor your DPX on FCP or Color so I can do proper grading?
 
If you have the deep pixel mode selected in Final Cut, it will request the Float YCbCr 444 pixel format from the source decode and pass it to the encode. At least it used to, we haven't looked lately. If you then use Remaster to convert the CineForm file to DPX, you get 10bit RGB.
 
Back
Top