Rotation pivot point

[emery]

I am trying to rotate an ImagickDraw scene around a specified pivot point, but the rotate() API only takes an angle and assumes the origin. Thanks in advance.

[mkoppanen]

I wonder if setGravity affects that..

[wizards]

I too have the same problem.
Can you please any one give idea how to rotate an image with respect some point.

[emery]

I wonder if setGravity affects that..

Yeah all I'd have to do is convert my vector graphics into a font and use annotate, lol. =)

I've tried using translate() and then rotate() but translate() moves the origin as well, so that's not an option.

Is there some way to do this with affine()? I don't know the math well enough to figure this out myself, plus the documentation is spotty.


Please, I really need some help with this, I took time off work for 2 months to focus exclusively on this side project and this is the last thing I need to figure out before I release it to the community free of charge under a BSD 2-clause license.

[emery]

I think I could get it to work through translate() and rotate() if I knew the trigonometry necessary.

First of all calling translate() after rotate() seems to do absolutely nothing. Bug?

But by calling rotate() before translate with some fudged numbers seems to be able to rotate about the center of a rectangle.

Before

Code: Select all

		$draw = $this->createDraw(); // Returns ImagickDraw tool
		$this->drawShape($draw); // Calls $draw->rectangle()

rectangle.png (348 Bytes) Viewed 29865 times

After

Code: Select all

		$draw = $this->createDraw(); // Returns ImagickDraw tool
		$draw->translate(50, -25); // Fudged numbers
		$draw->rotate(50); // 50 degrees
		$this->drawShape($draw); // Calls $draw->rectangle()

rectangle_rot.png (1.17 KiB) Viewed 29865 times

I need to know how to calculate:

• The translation coordinates
• The rotate degrees
• The resulting bounding box of a rectangle that would result after the rotation (for clipping)

Given an X and Y pivot point of the rotation.

Can anyone help me with this?

[anthony]

I do not know if the Distort Image operator is available in IMagick, but the SRT (ScaleRotateTranslate) distort method would give you the most flexibility, including whether to save the result to an image of same image size, or to the best sized 'virtual canvas offset' image.

It seems that is see Mikko's Blog, so I recommend the use of SRT distortions for image rotation about specific points.

You can turn on 'best-fit' to prevent clipping by enableing the use of virtual canvas image offsets (watch those negative offsets!)

[anthony]

For Affine Matrix handling notes see the old IM examples notes in...
http://www.imagemagick.org/Usage/distorts/affine/

This goes though the meaning and calculations involved in using the affine-transform image operators.

[anthony]

Just as an extra note. Since the advent of the +distort AffineProjection method, the -affine -transform, has actually be equivelent to the +distort form. That is the 'best-fit' with correct 'virtual-canvas' positioning form of the General Distort Operator.

See General Distort
http://www.imagemagick.org/Usage/distort/#distort
Best-fit Virtual Flag
http://www.imagemagick.org/Usage/distor ... rt_bestfit
AffineProjection
http://www.imagemagick.org/Usage/distor ... projection

The -draw 'display warping' affine distortion
http://www.imagemagick.org/Usage/draw/#affine
still uses the older technique that does not have the extra controls of -distort.

[emery]

I worked it out myself.

Rotate about a specified pivot point:

Code: Select all

		$rads = ($degrees * pi() / 180.0); // Convert degrees to radians

		$tx = $px - ($px * cos($rads)) + ($py * sin($rads)); 
		$ty = $py - ($py * cos($rads)) - ($px * sin($rads));

		$this->matrix->translate($tx, $ty);
		$this->matrix->rotate($degrees);

Now I need to use affineTransformImage to complete the feature and it seems to just do absolutely nothing.... which is wonderful. So I'm resorting to using a separate buffer and ImagickDraw::composite + drawImage to transform an image with the appropriate transformation matrix, but low and behold, it loses the alpha channel is the process. Also wonderful.

Is there a reason why 90% of ImageMagick methods I've used throw away the alpha channel?

I'll probably eventually find a solution that involves four simultaneous buffers and eight composites. =)

[anthony]

because they are gray-scale operators that modify each channel individually.
such operators use the 'Channel' setting to determine what channels they should
restrict themselves to. The default channel setting is just RGB. In other words no alpha by default!

An example is NegateImage() which using the default RGB setting negates the color channels, but ignores the alpha channel. However is you set channel to RGBA, then it will negate the alpha channel too, effectively swapping opaque and transparent regions of the image.


Also images often do not have a 'alpha' channel which can be separately turned on or off. If turned off the alpha channel data will remain, but will be ignored regardless of the 'channel' setting.

This is very well explained in the Command Line API examples for individual operators and sections.

See IM Examples, Basics, Controlling Transparency
http://www.imagemagick.org/Usage/basics/#alpha

which pretty well covers this. Remember what is on the command line SHOULD also be in the other API's!!!!

[emery]

Ok, so it's most likely Imagick's fault for not providing the channel parameter in a lot of APIs, or making the correct assumption when it's unambiguous. There's a few like compositeImage that have it, but a lot don't.

[emery]

By the way anthony, as per your earlier suggestion to use SRT. I was working with vector graphics so I was hoping not to use scalar transformation methods. But SRT was perfect when I had to do a similar thing with images.

[anthony]

There's a few like compositeImage that have it, but a lot don't.

Actually while compositeImage() has it as a parameter... It doesn't use it!!!!!

None of the Composite Image operators make use of the channel parameter, and is present only because of backward compatiblity. It would break the API to remove it!!!

However while it is non-sensical to use channel for Duff-Porter Alpha blending operations, It actually does make sense to use it for the various mathematical operations. It is just that at this time it is not being done.



Recently (last few weeks) I re-coded much of Composite math functions, so as to ensure they follow the SVG (and other) specifications, and use 'Over' alpha blending (except for 'Plus', and related operators, which don't use 'Over' blending). I looked briefly at allowing the use of channel handling for math functions, but concluded that all it would do is slow down the compose methods.
As such I decided to continue to ignore the use of 'channel' in compositeImage()

ASIDE: During that re-coding I also added some new compose methods, LinearDodge (like 'Plus' but with 'Over' blending instead of 'Plus' blending) LinearBurn (the photoshop 'Minus' function, you negate the image to subtract, then LinearBurn it) VividLight, PinLight, PegtopLight.

I also finally fixed the broken compose methods SoftLight, ColorBurn.

Also added was a special DIY compose method 'Mathematics', as proposed by Fred Wienhaus.
http://www.imagemagick.org/Usage/compose/#mathematics