> 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 4444 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! > "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. > 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..... :/ 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 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. Disclaimer: I don't actually work on this any more, so I'm starting to wish I hadn't got involved :-). I'm not sure what happened between 6.1 and 6.2 in Nuke's QuickTime support apart from the support for 64-bit, but I'll try and answer some of your questions.... You're right that Nuke should respect the colr atom on read. Is it possible to use a Colorspace node to correct afterwards though? The gamma 1.8 default is used to deal with RGB codecs. We try and follow at least some of the wildly contradictory QuickTime documentation, and I believe this comes from http://support.apple.com/kb/HT2912?viewlocale=en_US where it states "Final Cut Pro assumes that all RGB image files are created with a gamma of 1.8". The gama atom in QuickTime movies is (as far as I can tell) meant to represent a simple gamma function of this kind. Now of course, as you say, most people will be using rec709 but we have no way of knowing unless the movie is tagged correctly. I think the big problem here is that none of this stuff was ever clearly documented in the past and every developer of software had different interpretations of the documentation, resulting in the big mess we have now. When I was working on this for 6.1, a Google search for the structure describing the colr atom resulted in a single hit which gave no indication of how you were meant to interpret it. I believe the reason that we use the r408 pixel format for ProRes is because the r4fl support is broken in some of the ProRes codecs, particularly ProRes4444. With regard to Shake, it seems that Shake uses the obsolete SequenceCompressor QuickTime APIs whereas Nuke uses the newer ICM APIs. Unfortunately, passing the exact same pixels to these APIs results in different colours and in the case of ICM, writing a movie and reading it back again results in colour shift due to QuickTime deciding to apply some sort of mysterious and undocumented gamma correction. This is why it's hard to get colours to stay the same between Nuke and Shake. We've been trying to support more pixel formats in order to stop QuickTime from ever doing this, but we're hampered by buggy codecs. Ideally, we'd use r4fl for every codec, but that happy day is far off. By the way, be wary of relying on the source code to movReader/movWriter. Since 64-bit support, the QuickTime code has been moved into a separate 32-bit application and the source code for that may vary. We all look forward to the announcement of a 64-bit QuickTime API, which I'm sure must be any day now :-) I'll do some chasing up on the colr atom support. 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
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
