final cut X is not using quicktime X and thats all I can say about it. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ <http://www.linkedin.com/in/rslittle>
On Mon, Apr 18, 2011 at 10:52, Ned Wilson <nedwil...@gmail.com> wrote: > I've had a chance to dig a little deeper into this, and to be honest, I > really don't think that Final Cut X is going to solve any problems. Rather, > it will make them worse. > > I've been experimenting on a system that has the following configuration. > > - Fresh install of Mac OS Snow Leopard ( installed as 10.6.0, updated via > Software Update to 10.6.7 ). I know that certain configurations of Macs that > are upgraded from Leopard behave differently. > - After the fact install of Quicktime Pro 7. Since this machine was not > upgraded from Leopard, the legacy Quicktime player has to be installed > separately. > - Nuke 6.2v2 64-bit > - NEC PA271W-BK, calibrated with a Spyder3 Elite. Calibration targets: > 6500K, brightness 90 cd/m2. > > Quicktimes are authored from Nuke using the DNxHD Codec. Specifically, 36 > Mbps, 1080p/23.976. Quicktimes are written in the default colorspace ( Gamma > 1.8 ). > > If you take a look at the Quicktime files that are authored from Nuke, they > do not contain 'colr', 'nclc', or 'gama' atoms. I verified this with both > Atom Inspector and Dumpster. > > This is quoted directly from Apple's website: "QuickTime X takes advantage > of the proven capabilities of ColorSync to color-manage your media for the > best playback experience". > > Fail, fail, FAIL. > > What Quicktime X is doing under the hood appears to be as follows. > Apparently, you now have the ability to attach an ICC profile of sorts to > Quicktime movies. If you download a trailer from Apple's website, save it to > your desktop and Get Info on it ( Command-i ), it now has a Color profile > option. It would appear that Apple is setting these to HD (1-1-1). It would > appear that Quicktime X is checking to see if this profile exists in the > movie file. If it does, it will apply no gamma conversion. If it doesn't, it > will automatically apply a gamma of 1.212121 ( 1.8 -> 2.2 ). Next, and I > can't confirm this, but it appears to be applying a conversion LUT to get > the Quicktime to look correctly on your specific display. Since my display > is calibrated to 6500k, you can note a definite cyan shift in the Quicktime. > > I tried authoring with Shake, Nuke, and AfterFX, and they all produce the > same result: Quicktime files simply look different when viewed with > Quicktime Player X. > > Maybe I didn't look in the right place, but I was not able to find any > documentation on exactly what QTX is doing, nor was I able to determine how > to control it. I sent an email to a friend of mine who used to work for > Apple, and I posted this question to Apple's discussion forums. I have > gotten no response, so I really don't know what a solution would be at this > point. > > If Final Cut X is going to "solve" our problems... they had better publish > some documentation on exactly what the new Quicktime API is doing under the > hood, and they need to publish how we would control the behavior. > > -n > > On Apr 18, 2011, at 6:40 AM, Brad Friedman wrote: > > Can I suggest exposing all the internal settings as meta data recievers, > and then providing a gizmo for "foundry settings for QuickTime" that emits > meta data that foundry feels is "correct for most users"? That way you can > provide the simplified controls most users want, while allowing users like > Ned, Eddie, myself, and others I don't know personally, the control we need > to deliver consistently to clients across multiple shows and releases? I'm > getting very tired if having to read the nuke mov reader and writer > sourcecode every release. And unfortunately, client demands are getting > worse. Now not only am I expected to match editorial avid media, but I have > to deliver color critical iPad h264 files and h264 desktop files, for every > version of every shot of every feature in the facility across multiple > visions of nuke. > > That, or perhaps you could focus on making some write node functionality > that's really good at calling into other applications for post render > encoding? I would love a greased pipe into compressor, for example, as an > alternative. > > On Apr 18, 2011, at 7:11 AM, Jerry Huxtable <je...@thefoundry.co.uk> > wrote: > > We use QuickTime to read and write QuickTime movies, and always have, so > there's nothing to switch back to. The issue is that due to history of vague > documentation and dodgy codec and host software implementations, there is no > right way of doing things. If we write the colr atom out, then people will > complain that their movies look different in QuickTime Player and Shake. If > we don't write it out people will complain that their movies look different > in FCP and Shake (or something similar). If we provide the option, people > will complain that there's no way to set the option so that it works in all > other software. Some software ignores the colr atom, and some doesn't. Some > codecs ignore it and some don't. Some ignore everything and make the user > compensate. Some just make stuff up. There's really no correct solution > which fits all cases. We have the same situation on import - should we > ignore the colr atom like some software, or should we honour it...and how do > we know whether a codec has decided to take account of it or not? > > Jerry > > On 18 Apr 2011, at 11:58, chris wrote: > > yeah, unfortunately it seems to be a moving target, > sometimes it works then it breaks again... > > i thought the problem is solved with v6 (had good results > with 6.0v5 and 6.1) but then i had to write out ProRes files > as sRGB recently to get them looking right (Nuke 6.2vx as > far as i remember).. doesn't make much sense, so go figure. > > shake works pretty reliable as long as you account for the > 0.818 viewer gamma difference so i often use that for the > final DPX to QT conversion. > > i really really hope that when apple said "color management > though color sync" on the FCP X announcement that they found > a good way to tag all the codec variations and it carries > over to quicktime and eventually to all other applications. > it's just a pitty that adobe and the foundry took the effort > to write their own importer and now will have to decide it > they hand onto that or switch back again (not an easy choice > i imagine). > > ++ chris > > > On 4/18/11 at 11:47 AM, > <wou...@thefoundry.co.uk>wou...@thefoundry.co.uk(Wouter Klouwen) wrote: > > Unfortunately these are all bugs in different software > > packages. Even between the different Apple packages such > > as Shake, QuickTime Player and FCP there are differences > > in gamma. > > > _______________________________________________ > Nuke-users mailing list > <Nuke-users@support.thefoundry.co.uk>Nuke-users@support.thefoundry.co.uk > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > Jerry Huxtable, Senior Software Engineer > The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, > London. WC2H 7LT > Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 > Web: <http://www.thefoundry.co.uk/>www.thefoundry.co.uk > > The Foundry Visionmongers Ltd • Registered in England and Wales No: 4642027 > > > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
