> On Apr 18, 2011, at 7:11 AM, Jerry Huxtable <jerry at 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
I can't agree with this, sorry. Quicktime is problematic but Nuke has big problems with Quicktime. Should Nuke respect 'colr' extension? YES, of course! Currently Nuke ignore it at all and (most badly) it doesn't respect actual matrix what cause significant color shifts wit Rec709 files. This is most irritating problem because currently there is no workaround for this- raw functionality in movReader was fu...up from Nuke 6.2... And what is Gamma1_8.... ?!?! This simple pow. function is not correct for no any kind of mov files which I know. Most packages use complex rec709 equation (with or without additional pow. correction on RGB) or it's sRGB derivative. Lack of "knee" can cause visible banding. There are differences but there are rules also. Some applications like Shake and Combustion are old, older than some modern codecs. For instance they import 10bit Pro Res as 8bit because they don't recognize modern pixel formats (like r4fl). Nuke 6.2 use 408 pixel format for Prores. Is this for compliance with Shake also...?! I use Nuke from 5.0 version and I' am coder also. I observed evolution of movReader.cpp and movWriter.cpp in Nuke and at some points I 'am really surprised. Nuke 6.0 was a big step forward, Nuke 6.1 had the best mov support ever but in 6.2 is really bad. I know about 64bit problems but Quicktime is one of the most important formats in postproduction world; it's impossible to ignore it. Those problems should be well described in manual and yes- movReader should have more options; compositors are not the children. BTW. Sorry for my english :) Best Adrian _______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
