Click here to go to the first RED TEAM post in this thread.   Thread: Second Day Goodies

Reply to Thread
Page 17 of 18 FirstFirst ... 7131415161718 LastLast
Results 161 to 170 of 177
  1.   Click here to go to the next RED TEAM post in this thread.
  #161  
    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
    www.red.com - 6k Digital Cinema Camera
    Science enables stories. Stories drive science
    FLUT™, Image Processing, Colour Science and Demosaic Algorithms, REDRAY 4K delivery
    Reply With Quote  
     

  2. #162  
    Senior Member
    Join Date
    Jan 2007
    Posts
    2,962
    Quote Originally Posted by Graeme Nattress View Post
    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).
    Reply With Quote  
     

  3. #163  
    Apple get a grip and sort this out! god! grrrrrrrrrr
    --------------------------
    MatteBlackFilms
    --------------------------
    Space Digital Visual Effects & Post Production
    --------------------------
    Reply With Quote  
     

  4. #164  
    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*
    Reply With Quote  
     

  5.   Click here to go to the next RED TEAM post in this thread.
  #165  
    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
    www.red.com - 6k Digital Cinema Camera
    Science enables stories. Stories drive science
    FLUT™, Image Processing, Colour Science and Demosaic Algorithms, REDRAY 4K delivery
    Reply With Quote  
     

  6. #166  
    God I hope so Graeme. I for one am sick of it.. and I've only been using Apple for 6 months.. :-/
    --------------------------
    MatteBlackFilms
    --------------------------
    Space Digital Visual Effects & Post Production
    --------------------------
    Reply With Quote  
     

  7. #167  
    Banned
    Join Date
    Mar 2007
    Posts
    1,732
    Quote Originally Posted by Graeme Nattress View Post
    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.
    Reply With Quote  
     

  8. #168  
    Banned
    Join Date
    Mar 2007
    Posts
    1,732
    Quote Originally Posted by flameop View Post
    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?
    Reply With Quote  
     

  9.   This is the last RED TEAM post in this thread.   #169  
    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...
    ROBCODE Santa Claus @ RED

    "You get the chicken by waiting for the egg to hatch, not by smashing it with a hammer" - Jarred
    Reply With Quote  
     

  10. #170  
    Quote Originally Posted by Graeme Nattress View Post
    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.
    Reply With Quote  
     

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts