I've done previous tests (not with color bars at that time) but it looks like ProRes has similar problems although maybe not as extreme? Think it was prores 4444 i tested then. So that's broken too, right? Are there any useful formats left in 6.2 that works then?
Cheers, J. On Mon, May 30, 2011 at 11:44 PM, Adrian Baltowski <[email protected] > wrote: > Well, it's always better to work with exr sequences than with any kind of a > quicktime file. But Nathan's solution contains a trap: with some > correlations of codec/formats, bug in movReader cause significant shifts in > hue- exactly as You noticed. And then you would have tons of sequences fu... > up from the beginning. So it's better to fix the problem before you will run > overnight render ;-) > > > Ok, if you tested your pipeline with color bars we know, where we are. > The problem is: to convert from YUV to RGB Nuke uses hardcoded 601 matrix, > no matter whether this matrix is correct or not. That's I mean that it's not > specific problem with 10 bit Uncompress codec- this bug affect all > YUV, Rec709 quicktime files. > Unfortunately there is no good solution of this problem in 6.2 (Nuke 6.2 > has entirely new but underdone movReader). But there is brilliant workaround > in Nuke 6.0 and 6.1, 32 bit version. You just need bypass wrong, internal > matrix conversion and apply proper Rec709 matrix. And you can do it by check > "raw" on the reader node. But- as I mentioned- In Nuke 6.2 this feature is > broken at all (as well as in Nuke 6.1, 64 bit version). But in Nuke 6.1-32 > bit, "raw" feature works fine (well, at least for r4fl pixel format because > for some other is broken and produces horizontally stretched picture). > > If "raw" feature works fine you should see weird-colored picture with > strong cyan tint. Then just after read node paste this group: > > > > set cut_paste_input [stack 0] > version 6.1 v2 > push $cut_paste_input > Group { > name Group1 > label "Rec709 matrix and transfer" > selected true > xpos 300 > ypos -66 > } > Input { > inputs 0 > name Input1 > xpos 180 > ypos -170 > } > Expression { > temp_name0 y > temp_expr0 (255*r)*0.00456621 > temp_name1 cb > temp_expr1 (255*g)-128 > temp_name2 cr > temp_expr2 (255*b)-128 > expr0 "max(y+(0.00703137*cr), 0)" > expr1 "max(y-(0.00083529* cb) - (0.00209019* cr), 0)" > expr2 "max(y+(0.00828235*cb), 0)" > name Expression1 > label "Rec709 matrix" > xpos 180 > ypos -130 > } > Expression { > expr0 "(r>=0.081)?(pow(((r+0.099)/1.099), 2.5)):r/7" > expr1 "g>=0.081?pow((g+0.099)/1.099, 2.5):g/7" > expr2 "b>=0.081?pow((b+0.099)/1.099, 2.5):b/7" > name Expression6 > label "Rec709 transfer with correction" > xpos 180 > ypos -84 > } > Output { > name Output1 > xpos 180 > ypos 16 > } > end_group > > > > This group contains proper Rec709 matrix and additional transfer function, > which replicate "Final cut studio color compatibility" feature in Quicktime. > Above matrix equation is correct only for '0-219' pixel formats. > > In Nuke 6.2 you can try of course invert wrong matrix and apply proper one, > but without "raw" feature it causes significant clipping. > And finally my personal solution: I rewrote movReader to remove above bug > ;-) > > > > > Best > Adrian > > > W dniu 2011-05-30 20:36:01 użytkownik Johan Boije <[email protected]> > napisał: > > I agree with you Nathan. I guess that is what I have to do in the end. I > just wanted to explore the possibilities. > > Thx, > J. > > On Mon, May 30, 2011 at 6:40 PM, Nathan Rusch <[email protected]>wrote: > >> Honestly, I would wrap a sequence conversion in a directory-walking >> script (or use a batch-ready or scriptable app if you have access to one) >> and batch convert them all overnight. I know this is exactly the kind of >> thing you don't want to do, but if it's automated, it shouldn't be too >> painful, and I can almost guarantee it'll help you avoid at least 1 or 2 >> more headaches later in your process. The last thing you want to end up with >> is a gazillion useless comps (even if they are "just" >> grading/treatment/cleanup work). >> >> Sorry this isn't really a direct solution or answer to your question, but >> having been down this road before, I can assure you that in the long run, >> the easiest and most bulletproof solution has always turned out to be >> avoiding Quicktimes. >> >> -Nathan >> >> >> *From:* Johan Boije <[email protected]> >> *Sent:* Monday, May 30, 2011 5:24 AM >> *To:* Nuke user discussion <[email protected]> >> *Subject:* [Nuke-users] Re: Quicktime Uncompressed 10-bit YUV >> >> >> And this is on OSX, Nuke 6.2v4 >> >> >> >> On Sun, May 29, 2011 at 9:46 PM, Johan Boije <[email protected]> wrote: >> >>> Normally I wouldn't go near quicktime but for reasons I can't control I'd >>> like to read Quicktime Uncompressed 10-bit YUV directly in Nuke. This will >>> introduce a distinct chroma shift so it's not possible. What's your >>> experience with this? Any solutions? >>> I Believe I've read numerous threads on this matter but didn't find >>> anything specific on 10bit uncompressed. I know it's complicated and that it >>> probably has to do with Nuke's "home-brew" of the quicktime reader. Normally >>> I wouldn't consider anything but file sequences in Nuke, or in the rest in >>> my workflow for that matter. But this time I have like a gazillion quicktime >>> files that needs to be treated and I'd prefer not to have to convert them >>> elsewhere previous to bringing them to Nuke. >>> What's your experience with this? Is it even possible to keep a >>> controlled workflow with any type of uncompressed Quicktime format? I've had >>> a look at ProRes before and that was problematic too with chroma shifts >>> introduced. >>> I hate hate hate hate Quicktime. From the bottom of my heart. Hate it. >>> Sorry.... now I feel better. >>> >>> Cheers, >>> J. >>> >> >> ------------------------------ >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
