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 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!
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 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 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
