HD For Indies

last week I had to color correct a HDV shooted movie, for uncompressed output to HDCAM.
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.

kurt hennrich
 

@ Kurt: there has to be a better way than exporting, re-importing, and re-creating edits. Anyone?
 

Yeah I want to know about this too -- what about using "Batch Export" to export the files? Does this also result in stripped super-whites? I have a DV project that I need to bump up to Uncompressed, or at least DV50 -- my impression has been that Final Cut will correctly do DV25 to DV50 via Media Manager...but wondering about the uncompressed stuff. Others have been using PhotoJPEG at 75% or higher as an online codec, and I have verified that supewhites are definitely stripped if you use Media Manager's "Recompress To" with that codec as your destination.
 

The best way, in terms of quality, to uprez HDV is to use Miranda's (or others..) box to convert to HD-SDI on recapture.
Kind of retro offline/online process, but currently the software workflow is a negotiation between a headache and a heartbreak.
 

i was about to say that HDV doesnt have superwhites (check the scopes in a HDV timeline) but drop them into an uncompressed timeline, lower the highlights a bit and hello, there they are. kinda weird. (thanks to kurt for even make me think of trying that)

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.

++ chris
 

I have been watching the progression of color space handling in QT7 very intently. We incorporate After Effects into our workflow, and have been intently watching the outputs for accurate color.

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 vaguely recall seeing a tip somewhere that described similar color shifts during video export. It laid the blame on ColorSync. IIRC it recommended that you not use any custom Colorsync profile, but instead, use only the default profile. No, not the default profile for your monitor/LCD (which will be autoselected for most screens the system can detect) but the plain vanilla uncalibrated profile.
I don't know if that will help your situation, but it might be related, and worth checking out.
 

Anonymous 2 posts up:

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...

-mike
 

"Final Cut Pro assumes that..."

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.
 

Alan - I hate it too, but that has to be balanced against dolts that have NO idea what they're doing...which is the vast majority of users...
 

Mike, I hear your call but cannot answer it as I am working on a computer without FCP today.

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. :(

Bruce
 

Heya Mike,

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.
 

Re: Alan Okey's comment -- This shows in strong relief the internal philisophical contradictions in Apple's corporate culture.

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.)
 

I can confirm Stu's problems with Apple's Windows version of Quicktime not having the same gamma behavior. Also, his LUT suggestions are great. I THOUGHT that was how the pros do it...

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?

Bruce
 

Okay, I attempted to make a table of our knowledge. Please email me at boacinema@gmail.com if you want me to invite you to edit it.

http://spreadsheets.google.com/ccc?key=pTHtTubTnsJ-u8l3k-u9cMA

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.

Bruce
 

情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情趣,情趣,情趣,情趣,按摩棒,跳蛋,充氣娃娃,情境坊歡愉用品,情趣用品,情人節禮物,情惑用品性易購,A片,視訊聊天室,視訊,視訊聊天,視訊交友網,免費視訊聊天,聊天室,UT聊天室,免費視訊,視訊交友,免費視訊聊天室

免費A片,AV女優,美女視訊,情色交友,免費AV,色情網站,辣妹視訊,美女交友,色情影片,成人影片,成人網站,A片,H漫,18成人,成人圖片,成人漫畫,情色網,日本A片,免費A片下載,性愛

A片,色情,成人,做愛,情色文學,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色,情色視訊,免費成人影片,視訊交友,視訊聊天,視訊聊天室,言情小說,愛情小說,AIO,AV片,A漫,av dvd,聊天室,自拍,情色論壇,視訊美女,AV成人網,色情A片,SEX,成人圖片區

情趣用品,A片,免費A片,AV女優,美女視訊,情色交友,色情網站,免費AV,辣妹視訊,美女交友,色情影片,成人網站,H漫,18成人,成人圖片,成人漫畫,成人影片,情色網


情趣用品,A片,免費A片,日本A片,A片下載,線上A片,成人電影,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,微風成人區,成人文章,成人影城,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,臺灣情色網,色情,情色電影,色情遊戲,嘟嘟情人色網,麗的色遊戲,情色論壇,色情網站,一葉情貼圖片區,做愛,性愛,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,美女交友,做愛影片

av,情趣用品,a片,成人電影,微風成人,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,愛情公寓,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,aio,av女優,AV,免費A片,日本a片,美女視訊,辣妹視訊,聊天室,美女交友,成人光碟

情趣用品.A片,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,色情遊戲,色情網站,聊天室,ut聊天室,豆豆聊天室,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,免費A片,日本a片,a片下載,線上a片,av女優,av,成人電影,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,成人網站,自拍,尋夢園聊天室