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