Is there a reason for no height input on the "Make Scaled Layer" node? I get some weird results in a composition that I strongly suspect is because of this. I can use the "Make Layer" node instead, but then it won't stretch the same way.

Comments

(This was originally posted

jstrecker's picture
Submitted by

(This was originally posted in the Q&A section. I moved it to the Discussion section since it may not have a definitive answer and will presumably involve some discussion.)

The Make Scaled Layer node preserves the aspect ratio of the image, thus only one dimension (width) needs to be specified. What kind of weird results are you getting?

I eventually got it sorted

MartinusMagneson's picture
Submitted by

I eventually got it sorted out by using the make layer instead. The issue was that it with the initial crop settings I specified, a segmented image using several layers stacked would scale up the content of each cell to the point of a google image search of "nonose" (fun, but not intended). Correcting that gave black bars between layers with no way to get rid of them as there is no height scaling. If you swap out the "make layer" node in my latest reported maybe-bug-report with a "make scaled layer" you can see it in action, and the black bars will be there even when using the width of the window as the base for their size. This might be done away with by using the width of the image instead, but that is only given in pixels and not units.

But, the thing is that if I wanted a custom size for the composition/result, I couldn't have used the scaled layer to do so (I think), at least not with the current approach (which might be the wrong approach).

The black bars are

jstrecker's picture
Submitted by

The black bars are essentially the same problem as in your other post, Flickering when building items with video and cropping. Since Crop Image can't output an image with fractional dimensions, it rounds down the height to the nearest pixel. This means that Make Scaled Layer gets an image that's the right width (= the window width) but not quite tall enough.

The attached composition provides one possible solution. It uses an Arrange Layers in Grid node to position the layers — vertically centered on the window, with black bars across the top and bottom of the window as needed for the extra pixels. The Divide with Remainder -> Calculate nodes calculate the total height for the layers (minus the black bars) to feed into Arrange Layers in Grid.

Yes, I think I asked at the

MartinusMagneson's picture
Submitted by

Yes, I think I asked at the same time as looking at the problem (or a tiny bit before) in the same composition. The example you posted works really well! (Thanks!) But would it be a difficult matter to implement optional height for the layer as well? I could think of a few concepts that could benefit from this ability to kind of skewer the image in different ways. Ideally a different/new quad layer (with individual points for all the corners) would perhaps be ultimately beneficial, but I haven't seen it discussed before apart from in the projection mapping feature request. (Are there really any reason not to include it by the way? I think the Kineme GL quad was one of my goto nodes in QC).

There are a couple of ways to

jstrecker's picture
Submitted by

There are a couple of ways to squish/stretch a layer already:

  • Pass the image through Resize Image (Sizing Mode = stretch) before sending it to Make Scaled Layer.
  • Send the layer into Combine Layers with Transform and modify the transform's scale.

The difficulty with adding a Height input port to Make Scaled Layer is in making it optional. We'd have to add another port to say whether to use that port's value or the image's aspect ratio. That would make the node more complex, and you'd end up with an input port that sometimes doesn't do anything (a common point of confusion, for me at least, when using QC).

Any other ideas to make it easier to adjust a layer's height? Feel free to create a feature request.

My two cents -- QC

jersmi's picture
Submitted by

My two cents, as someone still coming from Quartz Composer.

QC combinations of resize/crop/scale caused a lot of creative roadblocks for me. I'd be happy if Vuo could make things like resize and crop more straightforward.

  • Good in QC: 3D tranformation patch (and other patches that had similar built in, Sprite, Replicate in Space, etc.).
  • Bad in QC: Billboard's Auto Height, Auto Width, Custom Height and Real Size -- maybe what's most relevant to this post.
  • Bad in QC: the Crop patch, especially trying to wrangle it in combo with Rendering Destination Dimensions, Image Dimensions and/or Image Resize.
  • Bad in QC: Image Resize stretch/fit/fill seems easy enough to understand, but so often confusing in use -- and now FCPX uses it (why?? confusing as ever, FCP7 was better).
  • Bad in QC: some filters use units, some use pixels.

Yes, I guess it is kind of a

MartinusMagneson's picture
Submitted by

Yes, I guess it is kind of a tradeoff between simplicity and complexity, but would you need a different port to set this? Couldn't the node just check if something was present at the Height-input port and only use it if there were something, and default back to aspect ratio if it weren't?

What I would want from the scaled layer is simple resizing and cropping for the applied image without having to go through pixel/unit conversion. You can get the image size, but only in pixels, and the crop node only works with units as far as I've understood, and I at least haven't figured out a way to get the aspect ratio of the image either (apart from going to the rendered layer bounds and introducing post-rendering data as well). So to keep the original height, but crop the width into one or several sections, you'd have to get the unit height and width to feed the crop node with and then possibly resize the image to not get any artifacts. It gets a bit fiddly as you have to go back and forth between images and layers instead of just dealing with all of it in the layer.

Maybe the fastest/simplest solution would be to just include units as well in the image size node? Maybe I've just overthought it to the point where I can't see a simple solution.

[jstrecker] The difficulty

smokris's picture
Submitted by

[jstrecker] The difficulty with adding a Height input port to Make Scaled Layer is in making it optional.

Another possibility (that we've used elsewhere in Vuo) is to have 2 nodes:

  • the existing Make Scaled Layer node preserves aspect ratio (only has Width input)
  • add a new Make Stretched Layer node that doesn't preserve aspect ratio (has both Width and Height inputs)

[magneson] What I would want from the scaled layer is simple resizing and cropping for the applied image without having to go through pixel/unit conversion […] include units as well in the image size node?

Just recently Team Vuo was discussing adding an input port to the Make Layer (real size) node to allow using either points, pixels, or Vuo Coordinates to specify the Center. Maybe we could add that to Make Scaled Layer, too (need to think through the implications of that).

[magneson] the crop node only works with units

Vuo has 2 crop nodes: Crop Image (Vuo Coordinates) and Crop Image Pixels (pixels).

Haha, ok, read before rant!

MartinusMagneson's picture
Submitted by

Haha, ok, read before rant! Got it.

Yes, that sounds like a nice solution. The Scaled Layer is very easy to work with when that's all you need, so perhaps a more extensive one for more detailed image editing could be an option?

A "Make Ludicrous Layer" in my mind would have something like the following inputs:

  • Name
  • Center (x/y)
  • Width (units)
  • Height (units)
  • Rotation
  • Opacity
  • Image
  • Image Anchor (px)
  • Image Width (px)
  • Image Height (px)

+1, @smokris:

jersmi's picture
Submitted by

It's sinking in and making sense how the Vuo team is taking care to set up scaling units/pixels/points, transforms, cropping, alignment, etc. Cool....

+1 for Make Stretched Layer and choosing scale type for Make Layer nodes. I might vote for some unit to/from pixel/point conversion nodes, too.

I think the clearest way to

George_Toledo's picture
Submitted by

I think one nice way to handle cropping/stretch type issues with the underlying texture, is to be able to directly control the uv (e.g "texturing properties") of the layer. Whether that would necessitate a different patch, attaching a shader to an object, or something else, I guess is debatable, and the best answer might vary depending on context...On the other hand, true cropping can be "better" if extensive image processing happens downstream.

By texturing properties of the layer, I guess I would include scale x/y, translate x/y, and maybe also clamp/repeat. It can also be useful to be able to discard fragments outside the texture if you clamp.

Good points, and I also

MartinusMagneson's picture
Submitted by

Good points, and I also realized there is probably a difference in what's preferred when it comes to working with images as well. I haven't started on the whole shader thing myself, so when it comes to images I'm so used to thinking in the "photoshop" way (or processing for that matter), where 0 - max pixels is used instead of transforms when it comes to images. For texturing (both layers and 2d objects) transforms does make a lot of sense. Maybe there should just be an "Transform Image" port, where you could use either a "Make Image Transform" or "Make Pixel Transform" or something like that?

With the "Anchor" port by the way, I'm thinking of that as the 0,0 pixel in the image. Anything "under" that would be cut/cropped, and any pixels outside the pixel width and height would also be cropped. Then the resulting pixels would be stretched across the layer.

Oh yeah -- I feel the benefit

jersmi's picture
Submitted by

Oh yeah -- I feel the benefit of being able to handle texturing properties. I've never been into shaders, too, but the texturing properties in QC had some nice benefits. Important to me -- it was clear how to use it.

[Magneson] Then the resulting pixels would be stretched across the layer.

Stretching pixels across a layer would be case by case, right? For example, one case for me where I would like both options: I have another QC patch on my list to bring to Vuo which makes a bounding box with mouse drags (locked to an aspect ratio, or not), crops to the bounding box, saves cropped image (or video), generates a list of the cropped images from the folder/url, then loads them into a "playlist" for video display. (I think the tools are present to approach this at present.) How to crop/transform the images at some stages can determine what/how images are displayed (e.g., stretch/fit/fill/real).

[@jersmi] I think the tools

jstrecker's picture
Submitted by

[jersmi] I think the tools are present to approach this at present.

Yes, you should be able to do all the cropping and loading you mentioned with Vuo currently.

One could also build Magneson's proposed "Make Ludicrous Layer" node as a subcomposition. And I think GeorgeToledo's proposed variant as well.

Another option for stretching/skewing layers, coming in Vuo 1.3, is Projection Mapping Node.

I will point out, without

George_Toledo's picture
Submitted by

I will point out, without breaking it all down, that QC's height/width units make complete sense - consider how they work in relation to aspect ratio, and gl scale. It's a fundamental type of representation that exists outside of QC as well. For instance, VUO really needs something that supplies unit scale info for images, so that something like a square can be readjusted to be the correct aspect ratio to match an input image without adding a bunch of math.

George, would you mind

jstrecker's picture
Submitted by

George, would you mind breaking it down a bit more? Since Vuo uses "Vuo coordinates" similar to QC's coordinate system for layers and scenes, and pixels for images, are you suggesting better conversions between pixels and Vuo coordinates? Could you post a Vuo and/or QC composition illustrating what you mean about readjusting a square (image? layer? scene object?) to match an image's aspect ratio?

Sure... as you write, I think

George_Toledo's picture
Submitted by

Sure... as you write, I think that the way VUO uses OpenGL based transform and scale, it essentially does the same thing as the QC coordinate system.

I think that when I have attempted to get the dimensions of an image, it is usually provided in only pixels, not in VUO coordinates.

So, if you have an output texture that you wish to interface with an object like a Make 3D Transform, and have it adjust to the same size as the incoming texture and not just be a 1x1, you have to do the math. Whereas in QC, the Image Dimensions patch, and also Rendering Destination Dimensions, always provided the pixel resolution as well as the QC (OpenGL) unit.

Not a really big deal or anything, just something I find myself setting up often.

If that doesn't make sense I can post a composition soon.

@jersmi i think many of the

useful design's picture
Submitted by

jersmi i think many of the things you listed in QC as bad or confusing were a necessary part of the system. Of course having both QC units and pixels can be confusing, but theres no other way. limiting QC to pixels only would be a serious limitation, and no use of pixels, disastrous!

I had my share of issue with needing to use the Crop in conjunction with Translate Image patch it could be mind bendingly obtuse at times. I think Auto-Width on billboards saved wiring up image dimensions patch, good and if you didn't want to use them they were not requires, you could use real size and do the auto-width auto-height or whatever in your own patches.

The thing about QC is that it

MartinusMagneson's picture
Submitted by

The thing about QC is that it made complete sense (with these sort of things). It might have been a nuance to wire up the image dimensions stuff, but to be honest, I didn't even have to think to set it up. Vuo has a few of these kinks that are intended to be easy, but they end up being a bit too easy so you have to patch up something custom for some tiny bit more tweakable solution, and then that part isn't always as straightforward.

Jaymie the combine layers trick works (mostly as intended) after some tweaking , check the attached node for something akin to what I described. I wonder a bit about the efficiency of doing it like this compared to a compiled C node though? What is the impact of doing it like this when using it in a lot of iterations?

Alastair the anchor is the 0-point of the image in pixels. In the attached comp it is using the "Crop Image Pixels" node to achieve this, so it's set to the top left corner of the image.

I think that when I have

jstrecker's picture
Submitted by

I think that when I have attempted to get the dimensions of an image, it is usually provided in only pixels, not in VUO coordinates.

GeorgeToledo, yeah, it does take some math to convert. We're planning to add an option to some nodes to pick the unit: points, pixels, or Vuo coordinates. Per your comment, we've added Get Image Dimensions to that list.

In case you haven't seen it, the Make 3D Object from Image node generates an aspect-correct quad.

Jaymie the combine layers trick works (mostly as intended) after some tweaking , check the attached node for something akin to what I described. I wonder a bit about the efficiency of doing it like this compared to a compiled C node though? What is the impact of doing it like this when using it in a lot of iterations?

Magneson, yay :)

A subcomposition should ideally be as efficient as an equivalent compiled C node, since the subcomposition also gets compiled. Though I think we're not at the ideal case yet because of some issues with multithreading. I think it was you who reported some bugs with subcompositions getting bogged down.

If you wanted to make the composition super streamlined, you could replace the Resize Image with a transform. Resize Image requires a pass on the GPU, whereas a transform would skip that.