Second Day Goodies

[Graeme Nattress]

You could make a quicktime from a tiff sequence instead of the quick export? Or from a DPX seq into After Effects. You'd get better quality anyway than the quicktime codec (for now).

As I say, it's a big issue with Quicktime that we're looking into deeply.....

Graeme

[Joel Kaye]

You could make a quicktime from a tiff sequence instead of the quick export? Or from a DPX seq into After Effects. You'd get better quality anyway than the quicktime codec (for now).

As I say, it's a big issue with Quicktime that we're looking into deeply.....

I vote to Test DPX vs. TIFF sequence and check quality vs. file size. You should be able to bring either format into Photoshop CS3 as well. (I think).

[Simon Blackledge]

Apple get a grip and sort this out! god! grrrrrrrrrr

[Gavin Greenwalt]

The best 'work around' is a *.wmv or divx and giving apple the finger until they get their act together. It's been like that for at least 5 years! Every time I update quicktime I always wonder to myself "Maybe today will be the day that they finally fix it." so I export a short clip.... nope! All of our clients want quicktime roughs... and I always have to attach a disclaimer "Quicktimes change the brightness and saturation, do not judge colors off of this file."
*Grumble grumble grumble*

[Graeme Nattress]

Gavin, it's only through a concerted effort from all members of the digital imaging community will this get changed. There's a new feature in FCP that could / should help and we're looking into it. That feature came about because of high-end user feedback, if memory serves me right.

Graeme

[Simon Blackledge]

God I hope so Graeme. I for one am sick of it.. and I've only been using Apple for 6 months.. :-/

[laguun]

Gavin, it's only through a concerted effort from all members of the digital imaging community will this get changed. There's a new feature in FCP that could / should help and we're looking into it. That feature came about because of high-end user feedback, if memory serves me right.

Graeme

i agree.
we never cared about really de-bugging that problem in detail, but one thing is for sure: QT overrides and/or ignores several (correct) YCbCr settings.

The workarounds are to have an external 3hrd party codec correcting this (blackmagic, aja), or as we (and it seems most of the older posthouses) do using 10-16 single frame sequences (dpx/tif) and avi.

I have to admit that i don´t understand why such issues as only 2k in FCP or the QT decoding-madness have not been adressed by apple. They have put so many manyears in so many features in many solid update cycles - why not in fixing the basics? Doesn´t make to much sense IMHO.

Hopefully red and its clients will provide a wakeup call to the people in charge in the near future.


p.s.
graeme - a good part of my concerms regarding a mixed YCbCr/rgb workflows relates to these issues. Its a great deal of additional logistics to keep track and manage all these conversion and rounding errors through a long and complex postproduction pipeline involving dozens of systems.

[laguun]

God I hope so Graeme. I for one am sick of it.. and I've only been using Apple for 6 months.. :-/

We are using FCP since v3 iirc, embedded in discreet / sony / avid / adobe. This nasty bug/issue/whatever they call it has always been there. For us its less of a problem, as we use fcp only as offline/conversion and will probably continue doing so until they implement a solid colorhandling (rgb>=10, xyz).

By adding 3hrd party hardware (which replaces the faulty codecs/libraries/whatever) you can wipe the problem out if you use only hd-sdi - however in a mixed format environment that adds another layer of possible problems.

I don´t know btw -- does the new FCP handle lin and log?

[Rob Lohman]

Evin: read the included readme file with the software ;)

We're outputting rec709 gamma. We inform QuickTime we're doing this and then QuickTime Player and Final Cut Pro will convert it to 1.8 gamma for display :(

Apparently this is "how it's supposed to work".

Shake & After Effects don't do this, for example.

For more info: http://docs.info.apple.com/article.html?artnum=93794

You will most easily see this difference in the dark regions or in under exposed images.

You should not see this problem if you go out to an external monitor through say an AJA Kona. Whenever the incoming data is Y'CbCr it will assume it's rec709 (in HD) and convert that to 1.8 for viewing only (should not adjust it for rendering). With RGB data (which FCP will usually not request from the codec) it will do a 1.8 to rec709 gamma conversion on output apparently.

It's a mess, and I'm sorry it's there. If we have any updates on this situation or work around we will keep everyone informed!

We are looking hard into work arounds but it is sort of out our hands at the moment. Everyone is having this problem apparently...

[Gavin Greenwalt]

Gavin, it's only through a concerted effort from all members of the digital imaging community will this get changed. There's a new feature in FCP that could / should help and we're looking into it. That feature came about because of high-end user feedback, if memory serves me right.

Graeme

No I've given up. I've emailed Apple for years. I've posted on their support forums. It doesn't matter. I get the same answer every time.

For gamma shifts on a PC. "It's a problem with DirectShow and we would have to do a bunch work blah blah blah... we don't care... maybe some day.... we don't really care all that much... more pressing matters to address like the iphone... blah blah blah."

:ranting2: Quicktime "Pro" my ass.