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.
(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.
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 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 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.
@MartinusMagneson in your Make Ludicrous Layer node, what was image Anchor? is that an offset from centre of image co-ordinate for the centre (x,y) to be offset by or something else?
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.
@jstrecker 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?
@useful_design 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.
Magneson.ExtendedLayer.vuo (7.47 KB)
Maybe you should call “anchor” > “Image Origin”?
Perhaps, I’m just used to anchor as it is called so in Photoshop. There it does default to center though, but it is a minor tweak to achieve it in the comp as well. I also think that it is evident by now that I really shouldn’t name stuff…
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.
@George_Toledo, 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.
@jstrecker 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?
@MartinusMagneson, 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.
In Vuo 1.2.4 we added a Make Image Layer (Stretched) node that allows changing a layer’s width and height independently.
I still miss an “auto width” layer like there is an “auto height” one.
For example if I have a row of images with different heights, and I want all the layers to have the same height, but the image ratios to be fine and the layers to fit a given heigh, how should I do that?
Sure I can use the stretched layer now, but have to manually calculate the image ratio each time (and I’m getting different results in Vuo 2beta4 compared to 128, see Calculate image layer different results Vuo 128 - 2b4).
With the .c nodes available in Vuo 2, the non-coder in me thought “let’s just edit the make layer stretched, replace “width” with “height” and maybe that will do the job ;)”
But a) I can’t drag the node to the canvas (I can still put it in the modules folder and then it’s recognised), and b), the node doesn’t retrieve any errors, but the composition starts but doesn’t display any window.
So I looked in the API / SDK and see that for “VuoLayer VuoLayer_make” one can specify the width, but not the height. So is this not possible because of the API ? Would some changes need to be made for this to work ? Or should I change the code with some more difficult math to manually calculate the image ratio ?
I get the point of not having an empty height port, but I think for the scaled layer, one could have a “layer size” input rather then a “width” input, and another port to select the width OR height (and have auto width or auto height).
Same Height Row.vuo (4.91 KB)
In Vuo 2.1.0 we added the ability to specify a fixed height for Make Image Layer (Scaled), Make 3D Object from Image, and Make Unlit 3D Object from Image.