Nope. But for various reliability reasons (and because I just like it better
this way :P) I ended up writing a quick NoIop that embeds a view-unique tree
hash in the metadata stream wherever it gets dropped, so this isn't really
an issue anymore.
It would still be nice to know how Write::getHashOfInputs() is constructed
though...
-Nathan
-----Original Message-----
From: Deke Kincaid
Sent: Tuesday, June 14, 2011 6:23 PM
To: Nuke plug-in development discussion
Subject: Re: [Nuke-dev] Write::getHashOfInputs() vs. Op::hash().getHash()
I think I know why it doesn't match. If you look at the metadata in
your stereo file are you seeing a "nuke/node_hash" and a
"nuke/nuke/node_hash"?
-deke
On Tue, Jun 14, 2011 at 11:52, Nathan Rusch <[email protected]>
wrote:
I’m trying to make use of the “nuke/node_hash” metadata value in written
EXR
sequences. In my plugin, I’m fetching the value from the metadata stream
of
input1() and comparing it to the hash returned by
input0().hash().getHash().
This all works fine for mono comps; if I write out a comp at a certain
point
and then read it back in, the hash my plugin reports for the tree matches
the hash embedded in the written EXR’s metadata.
However, as soon as multiple views are introduced, everything breaks.
Looking over the exrWriter source, it’s using Write::getHashOfInputs() to
fetch the hash that gets embedded in the metadata. This doesn’t ever match
the Op::hash().getHash() return value in stereo situations (which doesn’t
vary per-view unless a split knob is changed for that view, even when I
append outputContext().view() to my plugin’s hash).
So my question is, what is Write::getHashOfInputs() doing differently to
fetch its hash? Is there anything I can append to my plugin’s hash to get
it
to match the getHashOfInputs() return? Or are my only options to A) invent
my own metadata hash that I can control or B) compile my own modified
exrWriter that embeds what I want? This has me righteously stumped, so I
would really appreciate any ideas.
Thanks,
-Nathan
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
