Thanks for the suggestion Jonathan, but unfortunately that didn’t work. I’m about ready to just write a NoIop to inject a controllable metadata value where I need it, but I would love to have an idea of what voodoo is going on to get that written hash.
-Nathan From: Jonathan Egstad Sent: Tuesday, June 14, 2011 12:51 PM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Write::getHashOfInputs() vs. Op::hash().getHash() Did you try getting the hashes for the input Ops at different views and hashing them together? Try Op::node_input() as it takes an OutputContext argument. The order in which it's done would be important too. -jonathan On Jun 14, 2011, at 11:52 AM, Nathan Rusch 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
