Buy Mike Recommended
edit systems & gear
from Silverado Systems
Buy Books, Software, & More
at HD for Indies Amazon Store
Buy New Movies from
HD for Indies Amazon Store
Or, you can also support
HD4NDs by contributing
to the tip jar...
Help Support HD for Indies
Great HD Links
- HD For Indies Home Page
- HD For Indies FAQ
- HD 24
- Bare Feats
- 24p Entertainment
- Light Illusion (was Digital Praxis)
- OneRiver Codec Resource
- HighDef.org Info
- Understanding RAID
- Video Systems (Reviews)
- DV Film (DV=>Film)
- Plus 8 Digital (vendor)
- Digital Cinema Society
- Texas High Def (local F900 guy)
- Creative Cow (news & forums)
- Philadelphia FCP User Group
- Los Angeles FCP User Group
- Cinema Tech
- DV Info's forums
- HVX User
- Pro App Tips
- Bluesky Media - Instruction
- little frog in high def
- VideoMaker Learning Section
- Stu Maschwitz's ProLost
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
- March 2008
- April 2008
- May 2008
- June 2008
- July 2008
- August 2008
- September 2008
- November 2008
- December 2008
- January 2009
- March 2009
High Definition Video for Independent Filmmakers
A How To Guide for Digital Filmmakers
Welcome all! This is my blog to share my latest research,
thoughts, etc. on utilizing HD for independent filmmaking.
YES, I am available for consulting
Contact me at email@example.com
All content copyright 2004-2007 Mike Curtis.
Thursday, October 19, 2006
Take a captured DVCPRO HD clip in Final Cut Pro, and export it in the following ways:
(from his email):
(1) Final Cut Pro Timeline using Quicktime Conversion
(2) Open clip in the viewer - then export - changing codec to 8 bit uncompressed
(3) Open clip in Quicktime, Export to 8 bit uncompressed
(4) put clip in Compressor, and export to 8-bit uncompressed
Now, run these all out to a hardware scope, or use the Difference filter to compare them in FCP.
They are ALL DIFFERENT. Different from each other even.
And my friend didn't even try what I usually do - run it through Media Manager's Recompress To function.
And yes, he was using Final Cut Pro 5.1.2, and yes, he's someone I trust to know what they are doing and not make dumb mistakes.
Recent discussions indicate that QuickTime will truncate to broadcast safe (clip off sub black and superwhite), but the gamma shifts were supposed to have been addressed (at least for uncompressed codec going to AE and back). More issues clearly remain, and assumed gamma seems to be an issue as well. This article gives some clues:
Final Cut Pro, on the other hand, makes some assumptions about the gamma of QuickTime and RGB image files that are imported into a project. The gamma of imported QuickTime and RBG image files is treated differently in sequences set to render in 8-bit or 10-bit YUV.
users should leave the gamma of their monitors to the 1.8 Standard Gamma setting when working in Final Cut Pro
Final Cut Pro automatically lowers the gamma of sequences playing in the Canvas on your computer's display. The gamma of QuickTime images remains untouched when the sequence is output to video or rendered as a QuickTime movie.
Final Cut Pro assumes that QuickTime movies for codecs that support the YUV color space (including DV, DVCPRO 50, and the 8- and 10-bit Uncompressed 4:2:2 codecs) are created with a gamma of 2.2. This is generally true of movies captured from both NTSC and PAL sources. When you eventually output the sequence to video, or render it as a QuickTime movie, the gamma of the output is identical to that of the original, unless you've added color correction filters of your own.
However, during playback on your computer's monitor, Final Cut Pro automatically lowers the gamma of a sequence playing in the Canvas to 1.8 for display purposes. This is to approximate the way it will look when displayed on a broadcast monitor. This onscreen compensation does not change the actual gamma of the clips in your sequence
and this is good to know too:
Final Cut Pro assumes that all RGB image files are created with a gamma of 1.8. When RGB image files are imported into Final Cut Pro and edited into a sequence set to 8- or 10-bit YUV rendering, the gamma is automatically boosted to 2.2 in an attempt to match the other video files in your project. This boosted gamma is then used when the sequence is output to video or rendered as a QuickTime movie
OK, all together now....GROAN...
What say you all to this one?
I'm going to dig into this some more when I get time, but I don't have time right now, gotta go fetch my badge for Austin Film Festival (don't forget if attending I'm on panels Saturday at 9am and 2pm).
In the meantime, if you feel you have some technical huevos (and yes, I'm throwing down the gauntlet in challenge), post in the Comments section, starting with which workflow comes closest to the original.
Graeme, Stu, other Stu, Bruce, etc....bring it on!
tried to convert sequence with mediamanger from hdv to uncompressed before cc.
-> mediamangers translation stripped super values! - I wrote report to apple.
the workaround I found:
export whole sequence via QTexport(without conversion),
selecting Uncompressed8bit sequence setting.
-> all supervalues are saved into the new file.
but the result is one file for the whole sequence:
edit it into a V-track over the original edits and snap through them to
quickly redo all edits on the new file, giving seperate cc3's for each original shot.
Kind of retro offline/online process, but currently the software workflow is a negotiation between a headache and a heartbreak.
however, what i dont understand, as long as you're doing your CC inside FCP, why not just drop the original HDV clips into a 10bit uncompressed timeline, do all your color correction in there, render and lay back to tape. in fact fcp will smooth out the HDV compression artifacts quite nicely (which can be annoying sometimes, but usually it's a nice side effect)
obviously if you need to do stuff with other software, exporting is the only way to go as the quicktime importer will clip the original clips in all apps i tried so far.
First of all, Quicktime Player and FCP both display the same file differently (when using the 1.3.1 Apple 10 bit uncompressed). Our tests started with a .psd wth a ramp (R,G,B and White) going from 0-255 and 16-235 (in an 8 bit .psd). Then these were taken into After Effects, and rendered out to various codecs. Finally, all the resulting renders and original .psds were compared in FCP and in Quicktime Player. When viewed in FCP (5.1.2) we could get the Apple 10 bit to accurately reproduce the .psd, but when the same files are viewed in Quicktime Player, the ramp function doesn't exactly match.
That being said, my best guess is that Final Cut Pro has some workarounds (like the still image gamma selection pref), that really need to be incorporated into Quicktime to get accurate color across the architecture.
I don't know if that will help your situation, but it might be related, and worth checking out.
See my AE tests from this summer, I was doing 10 bit tests
Also, this quandary started with non-RGB footage - colloquially called YUV, but truthfully Y'CrCb - the color space transforms (not just the color sampling transforms) make this process all the trickier...
There's the root of the problem - I hate it when software developers try to be too clever and "assume" things about source footage without letting the user have complete control over the process.
So, I will submit my trite feature suggestion instead:
There needs to be a big switch in the Control Panel of the Mac.
It has two options:
1. Normal mode - try to manage gamma and color settings for me.
2. Expert mode - do not touch the darn pixels!
This would tell Quicktime, FCP, etc. to behave like Shake and not mess with color values.
Combine this with a LUT selection Widget for each screen / output device and we would be in business. We just select the LUTs appropriate to whichever color space we are working in.
Of course, the alternative is to have a true color-managed workflow. But let's face it, there will be bugs in this for years to come.
Sorry I can't offer much help with pragmatic solutions to current FCP issues. :(
We've been fighting Quicktime's esoteric handling of gamma over the last 18 months or so. It changes depending on both the codec and the platform - e.g. a photo-jpeg quicktime made under Windows will play back different than a photo-jpeg quicktime made under OS X. It was discovered (by Frantic Films) that OS X writes a "gamma" tag into the .mov header, this is read by Quicktime and the gamma is adjusted appropriately. If the tag is missing, Quicktime and FCP won't correct the playback.
Still, it drives us insane because sometimes what our client sees is different from what we see. For e.g., stills made from a quicktime are noticeably brighter than the actual quicktime itself, so you'll get notes back "needs more contrast".
With photo-jpeg, you'll find that the gamma jumps in the middle of an exported sequence rather randomly. You couldn't predict where. The only way to re "gamma-stripe" (as I called it) a movie file was to render out the finished sequence "recompressing all frames". We took the re-compression hit because our final delivery format is dpx.
We use Blackmagic 10bit RGB for uncompressed work because we don't want to be converting from RGB into YUV unnecessarily. We render from Shake into Blackmagic quicktimes and the gamma stays consistent. We don't correct it in either Final Cut Pro or when conforming. We just leave the monitor as is.
A few of our newer projects are using DVCProHD, so I'll be investigating any gamma issues as they arise. Still, my gut feeling is that FCP is making assumptions about gamma and is only correcting gamma on playback. Still, for real gamma accuracy and confidence, I'd probably "export to Shake" and use Shake to render to quicktime. It has a trusted colour engine around these parts. It ignores any gamma information in quicktimes and won't correct for display.
If I was working with HDV, I'd use Blackmagic 10bit as my final format - again, rendering out of Shake. If I didn't have the Shake option, I'd do lots of tests of the colour conversion from HDV --> Blackmagic. Experience has taught me to trust Blackmagic's gamma handling.
We're a film house and our base platform are linux boxen running monitors calibrated at 2.2 gamma (sometimes called 1.0) with CineSpace running for LUT management. None of the tools make any assumptions about colour-space and gamma. Operators take responsibility for gamma/colour-space issues. We like it that way. Final Cut Pro renders CineSpace a little useless. I concur with Bruce that Apple should allow you to disable gamma management, after all Shake needs to be run with a gamma of 2.2 in our environment, yet on the same box, FCP needs to be run with a gamma of 1.8 to produce the same looking pictures. Argh.
The biggest problem is the inconsistencies with how FCP and Quicktime deal with gamma - which is completely un-fucking-documented. You need to find a workflow and stick to it, which is difficult for us as our clients often dictate our workflows.
On the one hand, Apple makes products that start with a lowercase "i". These are Keep It Simple & Stupid products that are well-designed, well-engineered, and well-marketed.
On the other hand, Apple makes products that do not start with a lowercase "i": Pro Apps.
One thing that struck me when I first became a heavy Mac user was how friggin' small the options menus usually are in most OSX applications.
That's fantastic when my Mother wants to share out some photos on the Web without getting confused. But it is darned near insulting to the intelligence when I compare the menus in a Windows-based video encoder like, say, TMPEGEnc, or even a grey-area hacker app like the Gordian Knot suite. And just compare the depth of options in VLC Player to those of Quicktime "Pro".
Mike: I have to respectfully disagree 100% with you here -- if it is an ostensible Pro App then the only "assumption" the software should make is that it is being used by Pros.
I would be fine if Apple were to incorporate these "gamma assumptions" etc. as a default config but _also_ giving users a deeper level of menus (or even the ability to hack a config file for cryin' out loud) in order to turn every last bell and whistle.
(And then I would like the option to save all of these preferences along with Scratch Disk and other basic settings as part of my project file.)
Has anyone built a table of these behaviors? I am open to starting a collaborative spreadsheet on Google for us to get all of this stuff down...
...anyone else think we should talk to Marco Solorio from the One River Codec Resource Site as well?
At the moment, all it seems to confirm is that:
1. There are problems with Quicktime.
2. There are additional problems with FCP, which compound things.
If only Apple would un-break the Finder so that we could use image sequences properly, I would never use Quicktime again.
Links to this post: