Eyeon Talk:Script/Reference/Applications/Fuse/Classes/Image/Attributes

From VFXPedia

< Eyeon Talk:Script | Reference/Applications/Fuse
Revision as of 21:23, 5 March 2012 by Tilt (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

How do I reference the Canvas Color? --Chad 18:03, 14 September 2009 (EDT)

Good point. I've added GetCanvasColor() and SetCanvasColor() functions for build 475+, and documented them.

Is there an corollary for the IMG_CopyChannels that would let me create a 4 channel image from a single channel one? Right now I'm using a contructor to make a new image identical to the input, but with 4 channels. I can't use IMG_Like, and I have to use CopyChannelOf to move the alpha data to the rgb. It works, (other than losing the canvas color in build 473) but it seems inefficient. Is there a better way? --Chad 09:55, 15 September 2009 (EDT)

The description for IMG_CopyChannels seems to indicate that setting it to false will output a monochannel image. But I can't seem to get that to work. I still have to add { IMG_Channel = "Alpha" }, along with the CopyChannelOf to copy Fg.A to A. --Chad 15:40, 17 September 2009 (EDT)
The description for IMG_CopyChannels is (was) wrong. If you specify IMG_CopyChannels = false, and then don't specify any IMG_Channels, you end up with an RGBA image. --Stuart 17:15, 17 September 2009 (EDT)

Is there a way to reference the ROI/DOD? I'd like to respect/pass that through my fuses as well. --Chad 09:55, 15 September 2009 (EDT)

This fuse should answer both questions. You can use IMG_Like in conjunction with other tags to override the original, but you'll still have to copy the original's channels, of course. You can use DataWindows (the rectangle of actual pixels in an image) if you have REG_SupportsDoD in your regnode, but if you do, be certain to never directly access pixels outside an image's datawindow. This can speed things up a lot, particularly if you're processing pixels directly. An image's datawindow can be found with the DataWindow member ({l,b,r,t} table), and set with the IMG_DataWindow tag on creation. --Daniel
Thank you. Yeah, I was hoping to avoid the CopyChannelOf, as I suspect that's what's slowing it down, but oh well. Stupid question though... Why are the brackets needed for the channels in the constructor? Are there any functions for modifying the DataWindow? Like scale, rotate, offset? Or do we manually modify the table? --Chad 10:53, 16 September 2009 (EDT)
It's a (lua) table, used to construct the Image. Without the extra set of brackets, each IMG_Channel table index would replace the one before it, and you'd be left with only a single IMG_Channel table entry. --Stuart 00:22, 17 September 2009 (EDT)

What's the proper way to query the channels? Like if I want to test to see if an image is mono or rgba? Or to see if it has Z or BG colors? --Chad 14:38, 17 September 2009 (EDT)

GetChanSize() has been introduced in Fusion 6.31

Ok, I hate to keep posting about the DoD stuff here, but I can't find a better place. How should we handle ProxyScale ~= 1 when we are explicitly editing the DataWindow table? --Chad 11:45, 24 March 2010 (EDT)

How are you 'explicitly editing' the DataWindow? For a non-source tool that bases its output image on the input image, you'd just be using the DataWindow obtained from the input image (which would automatically happen when you create a new image based on that input image), whether in proxy or not. In proxy, the input image will already have a smaller, proxy scaled DataWindow. Stuart 15:36, 24 March 2010 (EDT)
Ok, I sort of see how the Proxy is working, you get the ceil for the right and top, floor for the bottom and left... As far as 'explicitly editing', I am having an issue. I tried just doing something simple like "out.DataWindow[1] = 0" in the Process, but if I follow that with "dump(out.DataWindow)" the first index data isn't 0. What am I doing wrong? --Chad 15:31, 25 March 2010 (EDT)
You should never modify the DataWindow in an existing image. Things will go horribly wrong if it doesn't match the actual data in the image. As such the DataWindow member of an image is read only. If you want to change an image's DataWindow, you will need to create a new image, passing in a changed table for IMG_DataWindow, which will cause a different amount of actual pixel data to be created. Stuart 13:29, 26 March 2010 (EDT)
Ok, making adding the DataWindow attribute in the constructor is half working... I am able to set the "Data" but not the "DoD". What's the difference? Functionally it seems the same, save that you can't edit the DoD manually downstream, or show it in the viewer. --Chad 11:23, 29 March 2010 (EDT)
The DoD that is displayed in the viewer results from the DataWindow attribute that was set during the precalc request. The DataWindow of the process request's output can be smaller if the requested area is limited by RoI. --Tilt 16:23, 5 March 2012 (EST)