Sorry, I guess I assumed the implied avoidance of Nuke was clear enough in my
message... That’s why I said “use a batch-ready or scriptable app if you have
access to one” instead of “use a Nuke Python script.”
There’s no trap at all. To use Nuke for the batch conversion would totally
defeat the purpose.
-Nathan
From: Adrian Baltowski
Sent: Monday, May 30, 2011 2:44 PM
To: Nuke user discussion
Subject: RE: Re: [Nuke-users] Re: Quicktime Uncompressed 10-bit YUV
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
Sent: Monday, May 30, 2011 5:24 AM
To: Nuke user discussion
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
