> > > Unfortunately what we are doing is modifying the image in this node. >
Yeah, what I'm saying is, you may be able to modify the image by redoing your logic with standard nodes inside your gizmo (mults, adds, merge expressions, etc) that combine your image with your sampled colors. Does that make sense? And therein I think lies the problem. So each node, even downstream ones, > don't wait for the nodes above to finish? > It depends on what the node does. If the node needs the whole image to be computed before doing its thing, then yes, it will have to wait until all processing above is done. Otherwise, if it can do its job scanline by scanline (or using just a bunch of them, like most filters), then you will have multiple threads running through the tree in parallel. On Fri, Apr 8, 2011 at 11:45 AM, John Vanderbeck <[email protected]>wrote: > And therein I think lies the problem. So each node, even downstream ones, > don't wait for the nodes above to finish? > > Unfortunately what we are doing is modifying the image in this node. > > Sent from my iPhone > > On Apr 8, 2011, at 2:09 PM, Ivan Busquets <[email protected]> wrote: > > I see. > The problem I see with that is that, typically, trees are rendered > multithreaded, scanline by scanline, so your downstream nodes will usually > start doing their job long before an upstream node has finished processing > the whole image. > Do you need the result of those samples to be stored specifically in knobs? > Otherwise, you could use expression nodes inside your gizmo, do your > sampling there, get full-sized images with the color of your samples, and > use those as needed. > > Would that help in your case? > > > > On Fri, Apr 8, 2011 at 9:42 AM, John Vanderbeck < <[email protected]> > [email protected]> wrote: > >> What I need to do is sample various pixels in the image to provide data to >> a downstream node. This calculation needs to happen in pseudo realtime and >> transparently to the user. Unfortunately for various reasons it needs to be >> done as a python script and not as a plugin. >> >> This should be doable and in fact it all works fine EXCEPT getting the >> script fired off at the proper time. >> >> Sent from my iPhone >> >> On Apr 8, 2011, at 12:29 PM, Ivan Busquets < <[email protected]> >> [email protected]> wrote: >> >> knobChanged fires immediately after a knob is changed. It doesn't have >> anything to do with the frame updating or not, as it could be triggered by a >> knob that doesn't force your viewer to update (as in, a knob in a node >> that's in a different tree than the viewer, or simply moving a node in the >> DAG). >> >> What is it that you're trying to do? I assumed the calculations you need >> to do in your callback just needed to check for certain knobs in all nodes >> upstream, since you were using knobChanged, but it sounds like you want to >> sample pixel data from the image, right? >> Depending on what you need to do, I think you'll either need to make a >> plugin, or use nodes inside your gizmo to get the info you need from the >> image (like a Dilate/Erode if you need to get the max/min value, or an >> Expression node if you want to sample from a specific pixel coordinate, etc) >> If you need to do something more involved with the image data, though, you >> may need to go the plugin route. >> >> Cheers, >> Ivan >> >> On Fri, Apr 8, 2011 at 9:12 AM, John Vanderbeck >> <<[email protected]><[email protected]> >> [email protected]> wrote: >> >>> So what I am finding is that the knobchanged callback always occurs >>> BEFORE the frame is updated. I need a way to have my script called AFTER the >>> frame has been updated. Any thoughts? >>> >>> Sent from my iPhone >>> >>> On Apr 7, 2011, at 10:25 PM, Ivan Busquets < >>> <[email protected]><[email protected]> >>> [email protected]> wrote: >>> >>> Hi John, >>> >>> If you already have a callback that reliably fires up frequently enough, >>> you should be able to use node.opHashes() as Frank suggested. >>> >>> Not sure how you tested it before, but to my knowledge any change >>> upstream of a node should change the hash of that Op, as long as you have >>> your viewer somewhere downstream from it. The hash should change whether >>> it's an input change, changing a knob of a node upstream, moving to a >>> different frame (if there's a sequence or something animated upstream) etc., >>> but the Viewer must be somewhere below, or else those nodes won't be >>> validated, and their hash won't change. >>> >>> It seems to me that the trickiest part of it would be having a callback >>> that gets called "at least" as often as you want it to, but not too often. >>> If you have a global knobChanged callback targeting all nodes, this will be >>> triggered very often (not only on explicit knob changes, but also if you >>> move nodes in the DAG, connect/disconnect inputs, etc). If you're happy with >>> that, though, and all you want is to check whether a more intense >>> calculation is really needed, opHashes should work for that purpose. >>> >>> Not sure that will help you much, but it may give you some ideas. >>> >>> Cheers, >>> Ivan >>> >>> >>> On Thu, Apr 7, 2011 at 6:23 PM, John Vanderbeck >>> <<[email protected]><[email protected]><[email protected]> >>> [email protected]> wrote: >>> >>>> I have things working to some extent, but i'm not 100% happy with it. >>>> >>>> By registering a global callback with nuke.addKnobChanged(), and then >>>> filtering the events to only fire off if the calling node is upstream, i've >>>> got it mostly working. Performance could be better though, and I really >>>> wish I could just know if I really need to recalculate things or not. >>>> >>>> Anyway i'm now running into weird issues that I think are due to how >>>> Nuke handles the callback stack. randomly, but quite often, the callback >>>> seems to occur before the image data is really completely redrawn and thus >>>> my script's calculations end up wrong. I haven't found a work around for >>>> this yet :( >>>> >>>> A better way of re-calculating when the upstream changes would be ideal. >>>> >>>> >>>> - John Vanderbeck >>>> - <http://www.johnvanderbeck.com> >>>> <http://www.johnvanderbeck.com><http://www.johnvanderbeck.com> >>>> http://www.johnvanderbeck.com >>>> >>>> >>>> On Thu, Apr 7, 2011 at 10:02 AM, John Vanderbeck >>>> <<[email protected]><[email protected]><[email protected]> >>>> [email protected]> wrote: >>>> >>>>> Thanks Frank. My main issue is more with callbacks. How can Ivey my >>>>> script to even be run by Nuke in the first place when things change. I can >>>>> tap in with knobChanged on a global level but if I do that then i get hit >>>>> everytime anything changes, even if it isn't upstream. It's also global >>>>> and >>>>> I was hoping for something self contained in the node. >>>>> >>>>> I looked at opHashes and best I can tell, it only changes based on what >>>>> nodes are connected not if the knobs on those nodes change. IOW if you >>>>> attach a blur to the custom node's input, the hash changes. But if you now >>>>> adjust that blur the hash does not change. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Apr 6, 2011, at 9:45 PM, Frank Rueter < >>>>> <[email protected]><[email protected]><[email protected]> >>>>> [email protected]> wrote: >>>>> >>>>> have you tried checking nuke.selectedNode().opHashes() to see if it has >>>>> changed? >>>>> >>>>> >>>>> On Apr 6, 2011, at 3:17 AM, John Vanderbeck wrote: >>>>> >>>>> Hey all, sorry for what is probably a really noob question, but I'm not >>>>> finding the answer in the docs. >>>>> >>>>> I write little scripts for things all the time, but what I need to do >>>>> now is essentially make a custom node that runs a python script whenever >>>>> anything upstream is changed. How would I go about doing this? >>>>> >>>>> - John Vanderbeck >>>>> - <http://www.johnvanderbeck.com/> >>>>> <http://www.johnvanderbeck.com><http://www.johnvanderbeck.com><http://www.johnvanderbeck.com> >>>>> http://www.johnvanderbeck.com >>>>> _______________________________________________ >>>>> Nuke-python mailing list >>>>> <[email protected]><[email protected]><[email protected]><[email protected]> >>>>> [email protected] >>>>> >>>>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nuke-python mailing list >>>>> <[email protected]><[email protected]><[email protected]> >>>>> [email protected] >>>>> >>>>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Nuke-python mailing list >>>> >>>> <[email protected]><[email protected]><[email protected]> >>>> [email protected] >>>> >>>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>> >>>> >>> _______________________________________________ >>> Nuke-python mailing list >>> <[email protected]><[email protected]> >>> [email protected] >>> >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >>> _______________________________________________ >>> Nuke-python mailing list >>> >>> <[email protected]><[email protected]> >>> [email protected] >>> >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python><http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >> _______________________________________________ >> Nuke-python mailing list >> <[email protected]> >> [email protected] >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> _______________________________________________ >> Nuke-python mailing list >> <[email protected]> >> [email protected] >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > >
_______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
