I see. I also read a previous post of yours and now I start to see things more "clearly" :-). Just for fun I tested the same uncompressed quicktime but now in the format 960x540 and the image matches, well except for the format. So indeed there seem to be the wrong matrix applied (for some formats). Do you know what theFoundry is standing in all of this? Bug or not?
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
