Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Second Day Goodies

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
 
Graeme Nattress said:
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.....
Click to expand...

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).
 
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*
 
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
 
Graeme Nattress said:
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
Click to expand...

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.
 
flameop said:
God I hope so Graeme. I for one am sick of it.. and I've only been using Apple for 6 months.. :-/
Click to expand...

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?
 
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...
 
Graeme Nattress said:
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
Click to expand...

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.
 
Rob Lohman said:
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!
Click to expand...
Making this a sticky under Apple workflow might help raise the pressure for Apple to fix this problem.
 
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/WebObjects/RadarWeb.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)
 
Rob Lohman said:
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!
Click to expand...
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).

Rob Lohman said:
We are looking hard into work arounds but it is sort of out our hands at the moment. Everyone is having this problem apparently...
Click to expand...
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.
 
flameop said:
thing is I don't touch PC's.. and still have problems going from capture to comp to grade to output.
Click to expand...

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.
 
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.
 
You must log in or register to reply here.
Back
Top