-
BMCC alternate workflow
-
I must have missed that thread Oliver.
Be interested to see if it works with 16bit tiffs. I exported a BMC dng (with adjustments) as a16 bit tiff from Aperture, imported into FCPX and compared it with the Aperture preview file (8 bit jpeg, quality 12, no chroma subsampling) that’s brought in when you drag from the media browser. FCPX optimised both to ProRes 422 files of about the same size. Images looked identical on my monitor, slight difference in waveform/histogram, you could push the exposure up and down on both images without much degradation. I noticed a difference when making a secondary color correction using the color board’s HSL keyer. It felt a little more precise pulling a key from the 16bit tiff.
So at the very least I think FCPX is processing 10bit plus media at 10bits.
-
[gary adcock] “I wanted people to note that handling the files in this manner will truncate the working color space down to the QT players native 8bit.”
[Oliver Peters] “What we don’t know, though, is whether that applies to FCP X. This may only be a limitation of other software using the QT conversion.”
I did a quick test, and Gary’s right: FCPX is truncating reference movies referring to 16-bit TIFFs.
However, Oliver is right, too — FCPX is apparently not using QuickTime in its processing path. More on that in a moment.
Here’s my test methodology — and I welcome all thoughts and criticisms in case I’ve missed anything:
In After Effects, I created a black solid over a white solid, animated its opacity from 100% to 0% over 1024 frames, and rendered to a 16-bit TIFF sequence — giving me 1024 sequential images of linearly increasing RGB values. This gives me 10 bits of precision for the test.
I opened them as an image sequence in QuickTime Player and saved a reference movie.
I imported the reference movie into FCPX and cut it into the primary storyline. Then I advanced one frame and cut it in again as a connected clip, then changed the composite mode to “difference.” Finally, I added blank title as an adjustment layer and cranked the gamma with a published Levels filter from Motion to exaggerate the result of the difference blend.
If the full depth of the original media were preserved, I’d see a consistent gray as a result of the exaggerated difference between any one frame and its neighbor. If it were truncated, I’d see 3 frames of black (no difference) followed by a flash of gray for a single frame (difference). This cadence is due to the one frame offset of two instances of the test movie and the division of 1024 (my 10-bit equivalent in a 16-bit render) / 256 (8-bit video) = 4. I see the latter, indicating truncation to 8-bit.
Interestingly, I get a different result bringing the reference movie back into a QuickTime-using application like QuickTime Player or AE. In these, I’m don’t see truncation; instead, I seeing dithering. (Of course, bringing the native TIFF files directly into AE shows the correct constant difference.)
While FCPX does not seem to be using QuickTime to read the reference movies (as Oliver suggested), it is still limited to an 8-bit processing path somewhere (as Gary suggested).
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
That is a genius post. I think we need a little icon for a post that is purely genius.
Rich Rubasch
Tilt Media Inc.
Video Production, Post, Studio Sound Stage
Founder/President/Editor/Designer/Animator
https://www.tiltmedia.com -
[Rich Rubasch] “That is a genius post. I think we need a little icon for a post that is purely genius.”
Ha, thanks, Rich. It can be right next to the button for posts that are overcomplicated…
While I had aimed to do the proof entirely in FCPX to eliminate external variables, this test can be greatly simplified or verified (if you trust AE, which I do) by simply importing the “temporal grayscale ramp” TIFF sequence reference movie into FCPX and immediately exporting it back out to a deep lossless format (like a 16-bit TIFF sequence). Open that in AE, work in 16bpc, hover the mouse over the footage with the info panel open, and step through one frame at a time. You’ll see no change in the RGB values for a pixel over four frames in a row, indicating truncation as I explained above. Zooming in and bumping up the viewer’s exposure, as well as mousing around with an eye in the info panel, will show no change within a single frame, indicating no dithering.
For the sake of completeness, creating the temporal ramp in FCPX (black solid over white solid, animating opacity from 100 to 0 over 1:09:23@29.97) and exporting as a TIFF sequence (correctly) shows a brightness change on every single frame in AE when checked with this same method, proving that the truncation is not in FCPX’s rendering or exporting pipelines.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Walter,
Did you render this in X or only go by the real-time display? If rendered, did you test the options, like HQ, 4444 or 10-bit uncompressed? If so, does it alter the results?
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “Did you render this in X or only go by the real-time display? If rendered, did you test the options, like HQ, 4444 or 10-bit uncompressed? If so, does it alter the results?”
No render in my initial tests — I looked at the real-time display for the first test (offset difference comparison), and I looked at no-render exports via “Share > Export image sequence…” for the second test (simple read in and write out).
Rerunning the test now, rendering to any of the options first doesn’t change the results.
I want to correct something I wrote above for anyone playing along at home; 1024 frames at 29.97 fps is 34:03, not 1:09:23 as I wrote. I read the timecode off from the wrong project when writing the post, and clearly wasn’t thinking about the math while I was writing — apologies for any confusion!
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Hi Walter,
I think the test is consistent and shows that there is something wrong on how FCPX manage QT Reference files or at least the contain.
Are you able to import directly the 16b TIFF as stills (no QT Reff) and see how they behave in FCPX?
rafael -
[Rafael Amador] “Are you able to import directly the 16b TIFF as stills (no QT Reff) and see how they behave in FCPX?”
When importing a series of stills to FCPX and exporting to deep formats from FCPX, verifying in AE shows no 8b truncation as it did with the reference movies.
Interestingly, FCPX’s 16b TIFF export and the original 16b TIFF sources differ slightly on brightness values; I would have expected them to be identical. Perhaps there is something going on with FCPX’s color management system that is foiling a perfect roundtrip?
I am also seeing noticeable shifts from the originals in AE with 10b Uncompressed 422, ProRes 422, and ProRes 4444. (10b Unc 422 and ProRes 422 look to be identical; perhaps a faulty RGB/YUV transform somewhere? Perhaps I’m doing something wrong?)
ProRes 4444 shows dithering in addition to the shift (but again no truncation). The dithering here strikes me as extremely odd.
And with that, I am back to having more questions than answers…
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Walter, I have no FCPX installed, so I can’t make any test, but I would like to send you something to try.
is an small file. May I post it to “info keenlive”?
rafael -
[Walter Soyka] ”
I did a quick test, and Gary’s right: FCPX is truncating reference movies referring to 16-bit TIFFs.However, Oliver is right, too — FCPX is apparently not using QuickTime in its processing path. More on that in a moment.
While FCPX does not seem to be using QuickTime to read the reference movies (as Oliver suggested), it is still limited to an 8-bit processing path somewhere (as Gary suggested).
“Thanks Walter for the confirmation, since I do all of this in hardware, I am seeing the differences on scopes not on files. I was traveling to IBC and not able to reply in a timely manner.
A have been told that this is a legacy hook left as part of the process used when creating a QT Ref movies.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
follow me on Twitter
@garyadcock
Reply to this Discussion! Login or Sign Up