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.
(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 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 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.
scanlineTest 2016-01-15.vuo (11.3 KB)
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 squish/stretch a layer already:
- Pass the image through
Resize Image(Sizing Mode = stretch) before sending it toMake Scaled Layer. - Send the layer into
Combine Layers with Transformand 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, 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 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 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 Layernode preserves aspect ratio (only has Width input) - add a new
Make Stretched Layernode 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! 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)
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 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 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 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.
[@MartinusMagneson] 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 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 @MartinusMagneson’s proposed “Make Ludicrous Layer” node as a subcomposition. And I think @George_Toledo’s proposed variant as well.
Another option for stretching/skewing layers, coming in Vuo 1.3, is Projection Mapping Node.
1 Like
(I didn’t really mean it should be called Ludicrous layer, lol)
I can almost do it with a subcomp. I still don’t get to decide height of the layer without manipulating image height and preserving aspect. Or at least I can’t figure out a sane way to do it.
To set height in the “Make Layer with a Lot of Options” (better? ;) subcomp, could you use Combine Layers or Combine Layers with Transform as in the attached composition?
stretch-layer.vuo (2.58 KB)
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.
1 Like
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?