I know I can rotate an image by [rotate] or [rotateXYZ] before [pix_texture].

But I was playing with pix_lumaoffset and I would love for it to work at an angle (currently it's only vertical). This could be done by rotating the pix as a pix, applying the effect, and rotating back.

But it seems there's no pix_ object for rotating?

How would one do this?

hjh

To rotate the pixels of an image with gem it could be possible to do it within a [gemframebuffer] and copy the pixels back to cpu with [pix_snap]. Here is an example.

Rotate-pixels-FX.zip

@60hz

Thanks! I'm traveling without my computer now -- I'll take a look later this week when I'm back home.

hjh

@60hz

Very cool technique!

It will take me some time to understand the sequence -- offhand, it looks like:

1. Abstraction's [t a a] right branch: Read the pix_buffer (containing the already-rotated image), reverse-rotate, and display.

2. Abstraction's [t a a] left branch, next [t a a]'s right branch: Rotate and render the original image, but [gemframebuffer] is in force at this time, so you don't really see this one.

3. Abstraction's left branch: [pix_snap] the rotated original image into the pix_buffer.

I guess when I talk it through, it makes more sense.

#1 needs to be first because #2 sets up a [gemframebuffer] and (I'm guessing here) you can't un-framebuffer a rendering chain after putting one in... right? Based on the [gemframebuffer] help file which uses two [gemhead]s.

Murky but maybe making a bit of sense.

hjh

For posterity -- I managed to simplify it a little, and make the rendering more stable.

There are a few safety tips missing from the help patches.

1. [gemframebuffer] appears to default to the screen size, rather than the window size. Because of that, for a while, I was getting the image that was supposed to be pix_snapped appearing in a reduced size in the lower left of the frame.

2. [pix_snap] help says the default snapshot size is "window size." It doesn't seem to be the actual rendering window size. I found I could get correct behavior only by explicitly initializing the third inlet.

So the key was:

[gemwin]
|
[route dimen]
|
[t a b a]

where the [t]'s c/ right outlet goes to [pix_snap]'s third inlet; b/ middle outlet bangs a "0 0" list for [pix_snap]'s middle inlet; and a/ left outlet --> [dimen $1 $2( --> [gemframebuffer]'s inlet.

With that, I get exactly what I was after: the image stays exactly in place, while the [pix_refraction] effect spins around (or could be [pix_lumaoffset] or anything).

Cool tip!

Hope the fine print about [gemframebuffer] and [pix_snap] is useful to someone.

hjh

And... couple of months later, I generalized this into an abstraction.

[pixbufsnap buffername scale originX originY width height]

Where the buffer name is required and the other arguments are optional (though, as in the demo patch, if you don't supply width and height as arguments, then you should get them from the gemwin).

It does assume a square pix, so maybe not totally general. But you can do any arbitrary operations before it renders into the pix_buffer, not only rotation.

But maybe it's helpful -- the logic with [gemframebuffer], [pix_snap], [pix_buffer_write] is very easy to get wrong, so, wrapping it up in an abstraction makes some sense.

hjh

two-stage-demo.pd pixbufsnap.pd