Re: [Nuke-users] The DREADED Quicktime 'colr' atom
On 27 Apr 2011, at 15:42, Adrian Baltowski wrote: ... a file called 'GlobalSettings.csv'. (...) If you have problems with any of the codecs mentioned in these lines, you can comment them out, though beware as this can make your Nuke crash and burn. Ok, I have seen this mysterious file but first time I hear how to use it ! ;) I commented out Prores line and now Nuke uses r4fl for this. Good. But I still dream about something even a little similar to interpretation rules.txt in Adobe After Fx... Nuke 6.2 (...) uses the matrix and gamma transfer recommended in the Iceflow and QuickTime documentation. No, there are no any recommended matrix in quicktime! Appropriate primaries, transfer and matrix functions are tagged in 'colr' extension and differs from file to file. Nuke's movReader ignore this extension at all and uses the same, hardcoded 601 matrix for all YUV mov files. This of course cause significant color shifts with some files if actual matrix have to be different (this not happens if you use RGB pixel format buffer with YUV file because then Quicktime read out 'colr' extension and make proper matrix conversion automatically). And I know- Apple is a devil, is a monster, but ironically this feature is quite well documented on quicktime-dev site. The Apple technical note at http://developer.apple.com/library/mac/#technotes/tn2201/ defines the primaries, transfer curve and matrix for the r4fl pixel format. I'd also point out that QuickTime's interpretation of the colr atom is why we try and avoid using RGB formats for YUV codecs. The conversion that QuickTime does is different on different platforms. meaning that a movie written on Windows will look different to one written on the Mac. But you're correct: Nuke should be interpreting the colr atom on read and writing out the correct one on write. I will raise a bug on this so it doesn't get forgotten. PS. Sorry for issues but mailbox provider forced me to use new, fantastic, beta version. Best Adrian W dniu 2011-04-26 18:38:26 użytkownik Wouter Klouwen wou...@thefoundry.co.uk napisał: On 26/04/2011 14:32, Adrian Baltowski wrote: I believe that r408 is chosen in preference to b64a because passing an RGB pixel format to a YUV codec causes weird colour shifts (...) Ok, so Nuke 6.2 uses r408 and sacrifice quality of Prores to avoid gamma shifts. But then it applied wrong matrix and wrong gamma transfer... Nuke 6.2 prefers r4fl and uses the matrix and gamma transfer recommended in the Iceflow and QuickTime documentation. I think that priorities are upside down here. Problems with gamma, even if they are irritating, they are relatively simple to fix by experienced user. But degradation of quality caused for this case by r408 is irreversible and unable to fix. It's a painful problem especially because it affects very popular and useful codec. This is done on a codec-by-codec case. Some codecs simply are broken and have random crashes with r4fl or r408 but work fine with b64a. Our priorities are to give our users the best quality and most stable QuickTime we can. Unfortunately Apply hasn't made life easy for anyone including themselves. In order to make life easier for ourselves, starting Nuke 6.2v2, it is possible to drive the QuickTime plug-in to use different pixel formats. In your installation locate a file called 'GlobalSettings.csv'. This contains all of the quirks we employ for the different codecs that have problems. If you have problems with any of the codecs mentioned in these lines, you can comment them out, though beware as this can make your Nuke crash and burn. Please to email support with example footage so they can file a bug and we can make things better for everyone. Best Adrian HTH --Wouter PS: Your email client doesn't seem to be respecting threads, that makes this conversation very difficult to follow. -- Wouter Klouwen, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, WC2H 7LT, UK T: +442079686828 - F: +442074341550 - thefoundry.co.uk The Foundry Visionmongers Ltd - Reg.d 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 Jerry Huxtable, Senior Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, WC2H 7LT, UK Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 Web: www.thefoundry.co.uk Email: je...@thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
Re: [Nuke-users] The DREADED Quicktime 'colr' atom
On 22 Apr 2011, at 13:18, Adrian Baltowski wrote: Is it possible to use a Colorspace node to correct afterwards though? With access to raw YCbCr channels it was my solution, but currently in Nuke 6.2 the 'raw' acces in movReader is broken. Internal matrix conversion in Reader cause some min/max clipping so it's not fully reversible. And of course you must to know, which matrix should be applied. You need to inspect 'color' atom with Dumpster all the time. From my experience r4fl works perfect with ProRes 422 and 422HQ. If some problem occurs with there is b64a pixel format (Nuke uses it for dNxHD). It has no matter when raw access is abandoned in Nuke 6.2; r408 was the worst choice! I believe that r408 is chosen in preference to b64a because passing an RGB pixel format to a YUV codec causes weird colour shifts as QuickTime does the conversion for the codec and the method it uses is not documented. The shifts seems to roughly correspond to a gamma of 1.8 of the Mac and 2.4 on Windows but vary by codec, and according to whether hardware acceleration is in effect for H.264 (I think this last one was a bug that is now fixed). We try to avoid this conversion and do our won YUV conversion so we're in control. In addition, b64a comes fairly low down our priority list because so many codecs implement it incorrectly: some get the byte order wrong on Intel Macs, some get it wrong on Intel processors, some get it wrong on every machine, some put 8-bit data in the 16 bits, some get the RGB channels right but the alpha channel wrong Final Cut Pro assumes that all RGB image files are created with a gamma of 1.8. Well, the mentioned gamma 1.8 term is very ambiguous and it's rather label then actual value. Some months ago I tested it with animation codec and I noticed, that Final and most applications uses sRGB- like complex transfer curve also for RGB codecs (exactly like in case of Tiff btw); the 'gama' atom appears to be ignored at all. Sometimes there are simple pow functions on RGB channels but as addition to main, complex curve. But there was my personal tests only and I can't find clear answer in quicktime docs or apple mailing list. If there's anyone out there who has found a clear answer in QuickTime docs, mailing lists, tea leaves... we'd love to hear from you! Since 64-bit support, the QuickTime code has been moved into a separate 32-bit application and the source code for that may vary. I know and i'm scared... From long time I wrote my own versions of mov plugins to fix above problems (and few other as well). Now i'm helpless because mentioned libraries and header files are not included into Nuke bundle. This keeps me away from 64 bit OS X version because movReader is a nightmare there. BTW I hope Qtkit evolution will solve 64bit problems soon. :/ I'm dreaming of a new 64-bit, well-documented QuickTime API which works on Mac, Windows and Linux (while I'm dreaming, I might as well make the most of it) to be announced soon. Failing that, a 64-bit API which lets us read and write movies at all would be an advance. The 64-bit API is entirely geared towards people who just want to display movies on the screen. Jerry Best Adrian W dniu 2011-04-21 10:18:02 użytkownik Jerry Huxtable je...@thefoundry.co.uk napisał: On 21 Apr 2011, at 01:09, Adrian Baltowski wrote: 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
RE: Re: [Nuke-users] The DREADED Quicktime 'colr' atom
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
