:-) Sorry, I didn't mean to say there was anything wrong with it. It's a nice way to encapsulate the metadata from a camera, which would otherwise be a pain to expression-link, etc.
And, it's still a nice way to carry that data into a gizmo, I'll give you that! ;-) > I wish there was a good way of handling this for those of us who are not > making plug-ins. Totally agree. Cheers, Ivan On Thu, Aug 11, 2011 at 7:51 PM, Michael Garrett <[email protected]> wrote: > Right - good point, Ivan. At least Erik was impressed. > My method would work where I want to put it into a gizmo in a lot of cases, > which is what I was thinking. I should probably look into doing your > Python-based Class test. > > I wish there was a good way of handling this for those of us who are not > making plug-ins. > > On 11 August 2011 19:07, Ivan Busquets <[email protected]> wrote: >> >> But by having a ModifyMetadata node inside, you're re-casting the >> output of that group to be an Image-Op, and therefore you wouldn't be >> able to connect its output to anything that requires a camera input? >> >> Using metadata is a nice workaround, but you still need to know what >> camera you're pulling from beforehand (or do a topnode or a recursive >> loop on the inputs). >> >> I wish there was a more straightforward way to do this for gizmos, >> though. (like it is in plugin-land, where you can just test for a >> certain input Class). >> >> >> On Thu, Aug 11, 2011 at 6:50 PM, Erik Winquist <[email protected]> >> wrote: >> > >> > pretty slick workaround, michael. >> > >> > nice one. >> > >> > erik >> > >> > >> > Michael Garrett wrote: >> > >> > I got something working that seems to enable metadata in the camera >> > pipe. >> > So you could add this right after the camera, where you don't need a Dot >> > to >> > keep things clean, then access camera values via metadata. Not ideal, >> > but >> > it could be helpful: >> > >> > set cut_paste_input [stack 0] >> > version 6.2 v1 >> > push $cut_paste_input >> > Group { >> > name AddCamMetaData >> > selected true >> > xpos -152 >> > ypos -129 >> > addUserKnob {20 User} >> > addUserKnob {41 shownmetadata l "" -STARTLINE T >> > ViewMetaData2.shownmetadata} >> > } >> > Input { >> > inputs 0 >> > name Input1 >> > xpos 61 >> > ypos -238 >> > } >> > ModifyMetaData { >> > metadata { >> > {set focal "\[value parent.input0.focal]"} >> > } >> > name ModifyMetaData1 >> > selected true >> > xpos 61 >> > ypos -176 >> > } >> > ViewMetaData { >> > name ViewMetaData2 >> > xpos 61 >> > ypos -150 >> > } >> > Output { >> > name Output1 >> > xpos 61 >> > ypos -40 >> > } >> > end_group >> > Blur { >> > size {{"\[metadata focal]"}} >> > name Blur3 >> > selected true >> > xpos -152 >> > ypos -103 >> > } >> > >> > >> > >> > >> > On 11 August 2011 14:59, Michael Garrett <[email protected]> wrote: >> >> >> >> Hi Ivan, great, thanks! I was just trying Camera1.focal >> >> >> >> >> >> >> >> On 11 August 2011 14:47, Ivan Busquets <[email protected]> wrote: >> >>> >> >>> Hi Michael, >> >>> >> >>> You can use tcl expressions in the "value" field of a ModifyMetadata >> >>> node. >> >>> >> >>> ex: >> >>> [value Camera1.focal] >> >>> >> >>> On Thu, Aug 11, 2011 at 2:40 PM, Michael Garrett >> >>> <[email protected]> >> >>> wrote: >> >>> > Do you mean expression link to the modifymetadata "value" field? >> >>> > How >> >>> > exactly do you do this? >> >>> > >> >>> > On 11 August 2011 14:36, Frank Rueter <[email protected]> wrote: >> >>> >> >> >>> >> You can expression link a camera's parameter to generically create >> >>> >> meta >> >>> >> data. But of course this creates the same problem. It would be good >> >>> >> to >> >>> >> have >> >>> >> multiple inputs for the ModifyMetadata node that allows any type of >> >>> >> input >> >>> >> type to do this sort of thing (I guess input 0 would be the type >> >>> >> being >> >>> >> passes through like a copy node) >> >>> >> >> >>> >> >> >>> >> On Aug 11, 2011, at 1:20 PM, Paul Raeburn >> >>> >> <[email protected]> >> >>> >> wrote: >> >>> >> >> >>> >> I wondered about that, but metadata node dont work in camera pipes, >> >>> >> so >> >>> >> I >> >>> >> ran into a dead end. Getting the name of the camera node node >> >>> >> world >> >>> >> be >> >>> >> great (as per Ivans recommendation). Ideally it would be great to >> >>> >> et >> >>> >> the >> >>> >> data from the camera pipe directly, so it can be modified by >> >>> >> downstream axis >> >>> >> etc, but I assume that a foundry question. >> >>> >> Any suggestions on how to access the metadata of the camera pipe? >> >>> >> >> >>> >> On 12 August 2011 05:51, Frank Rueter <[email protected]> >> >>> >> wrote: >> >>> >>> >> >>> >>> Try "[topnode]" which will give you the top most node of a stream. >> >>> >>> Obviously it won't work if the camera's parent pipe is connected. >> >>> >>> In >> >>> >>> that >> >>> >>> case you will need a script that walks upstream and returns the >> >>> >>> first >> >>> >>> camera >> >>> >>> node, then use that in your expression. Or use meta Data to make >> >>> >>> the >> >>> >>> camera >> >>> >>> info flow in the stream which is more elegant and probably faster. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> On Aug 10, 2011, at 8:24 PM, Paul Raeburn >> >>> >>> <[email protected]> >> >>> >>> wrote: >> >>> >>> >> >>> >>> > >> >>> >>> > We have been using references tot he input node and then values >> >>> >>> > to >> >>> >>> > get >> >>> >>> > values from a camera node. ie. NoOp1.input.focal >> >>> >>> > >> >>> >>> > This works fine but breaks if there is anything in between the >> >>> >>> > NoOp >> >>> >>> > and >> >>> >>> > the camera, so you can tidy up the script with Dots or end up >> >>> >>> > with >> >>> >>> > multiple >> >>> >>> > cameras just to be tidy. >> >>> >>> > >> >>> >>> > Is there a way to get camera stream directly, or even the name >> >>> >>> > of >> >>> >>> > the >> >>> >>> > camera node from the stream? >> >>> >>> > >> >>> >>> > thanks >> >>> >>> > >> >>> >>> > Paul Raeburn >> >>> >>> > _______________________________________________ >> >>> >>> > 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 >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > 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 >> > >> > -- >> > erik winquist >> > weta digital >> > >> > _______________________________________________ >> > 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
