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

Reply via email to