Second Day Goodies

[Jack Wester]

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!

Making this a sticky under Apple workflow might help raise the pressure for Apple to fix this problem.

[Simon Blackledge]

thing is I don't touch PC's.. and still have problems going from capture to comp to grade to output.

[Anders Holck]

It's so tragic. I remember when I read some of the punchlines of the upcoming Mac OS X back in '98. One sentence about Quartz/CoreGraphics read "All onscreen elements are colormanaged. Even Quicktime is rendered through Colorsync"
I found that truly revolutionizing what advanced colormanagement in a video architecture could bring us. Well that was 9 years ago, and still a pipedream apparently.

Reading a sentence like "The application assumes....to work around that" is just plain crazy.

Why assume anything when its wrong 50% of the time.
And dont get me started on the Field issues in FCP 6.
("Ok, your 1080psf material is now suddenly half res vertically after updating? Well that's because FCP 6 assumes you now want to de-interlace your psf material. Turn it off? no, you can't do that. But to work around that....")

Hopefully, The quicktime/FCP group will put some weight on your comments. At least you were featured on their web page.

(I have tried a few times to document the bugs I find through https://bugreport.apple.com/cgi-bin/....woa/wa/signIn

Well, reported about 6 in FCP 5.1, and a 4 in FCP 6.0. They haven't fixed a single of them yet so not a great statistic)

[Gavin Greenwalt]

This might work for you apple people:
http://support.franticfilms.com/wb/d...fid=14&read=74

edit: whoops nope that's for PCs only.

[laguun]

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!

Thats why i am warning since months that YUVfloat and 8bitRGB in FCP are a bad couple for RED. Works flawless with HD-SDI i/o, but with a format/bitdepth/colorspace powerhouse as Red One anyone exposes the issues of an not really format aware postproduction pipeline.

On the discreet systems or the sony cobra here, there are settings for -every- indivdual clip.
decode as lin/log.
which colorspace - handle as yuv/rgb.
apply level conversion before/after rendering pipeline.
apply level conversion before/after output to display.
apply level conversion before/after output to tape/disc.
souce has 8/10/16/float space. round/convert/maintain bit deptht/gamma.
use/don´t use LUT.
all simply checkboxes. All that stuff is, as of yet, not implemented in qt/fcp and would be, basicly, necessary in order to fully use the potential of red.

Furthermore, in the last version of fcp, i have come to the impression that its in/export are not consistent (as in level conversion done or not depends on source/target codec etc).

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

as far i observe and measure it here: Its not RED issue - its in the postprocessing pipeline of qt/fcp and how both decide to convert/not convert levels., which then again is a variable depending on which hardware/codec the customer uses.

Oh boy, i would love to have our red already delivered here in order to press it through all the etalished workflows. Another 10 weeks *sigh*

p.s.
i attached a screen with the relevant discreet i/o control missing atm in qt/fcp.

[laguun]

thing is I don't touch PC's.. and still have problems going from capture to comp to grade to output.

flameop, osx runs on pcs. there is nothing different about the hardware of an apple or a dell pc.
its just the os.
Simply install windows (in paralells its even a window without reboot). Highly recommended.
Same for discreet smoke/flame, quantel generationQ etc btw - they all are usual pcs as well, with aja cards in the case of dicreet.

p.s.
i really miss irix/sgi... ah the gool ole days.

[Emmanuel Cambier]

If you guys at Red can't make apple to solve this gamma shift, I mean… who will.
We tried for years, many of us.