I have to admit the first obvious thing I thought of using metadata for when
it was announced for Nuke was moving camera data to or from from a Nuke
camera.

And, a Dot should be purely a UI element, although people do use the Dot
label quite a lot - also just a UI element, most of the time.



On 11 August 2011 20:15, Ivan Busquets <[email protected]> wrote:

> :-)
>
> 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
>
_______________________________________________
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