Cannot find correct new oordinates of a rotated image!!

[troller]

Hi everybody, I'm having some quite of struggling here since last friday...

Let's assume I have a picture that is a green rectangle of 400x300 pixels, and the position of the top-left corner pixel is of course 0,0, and the bottom right is 399,299.

Now with imagemagick, using either -rotate or -distort SRT or other, I rotate the picture 20° clockwise, and I obtain a new picture that has a total area of 479x419 pixel, with white background at the sides of the green area.

I want to obtain the new coordinates of any given pixel of the old picture.

By using the -affine sx,rx,sx,sy,tx,ty and the common fomulas:
x' = x * sx + y * ry
y' = x * rx + y * sy

using tx and ty at zero, I do not get the correct new pixel positions that I want.

For example, using the formula above, for instance, the "old" 0,0 pixel is STILL 0,0 in the new picture, but in my mind it should be roughly instead in the position 103,0.
In my mind, the "new" 0,0 should be the top-left corner of the new picture (white pixel), and the "old" 399,299 pixel (bottom right of the green picture) should be now roughly 375,418.

HOW do I get such new information for any given pixel starting from the location information of the old image pixel?

Thanks!!

[snibgo]

using tx and ty at zero, I do not get the correct new pixel positions that I want.

tx=ty=Zero would be fine if you were rotating about (0,0). But you are not. The default centre of rotation is the center of the image.

If you want to rotate about (0,0) then:

Code: Select all

convert -size 400x300 xc:green -virtual-pixel None +distort SRT 0,0,1,20 g.png

... without a +repage.

[fmw42]

see http://en.wikipedia.org/wiki/Rotation_(mathematics)

with regard to Two Dimensions, where

x'=x*cos(angle)-y*sin(angle)

y'=x*sin(angle)+y*cos(angle)

You may have to change signs of both sin(angle) terms depending upon how the rotation is defined as positive and whether y is up or down.

[troller]

using tx and ty at zero, I do not get the correct new pixel positions that I want.

tx=ty=Zero would be fine if you were rotating about (0,0). But you are not. The default centre of rotation is the center of the image.

If you want to rotate about (0,0) then:

Code: Select all

convert -size 400x300 xc:green -virtual-pixel None +distort SRT 0,0,1,20 g.png

... without a +repage.

mmm honestly I don't care if I need to turn around (0,0) or the image center, as long as I can then compute new pixel coordinates starting from the NEW image top-left corner (and not the old one).
But with the distort SRT 0,0,1,20 am I not just "moving" the 0,0 pixel from 0,0 to 1,20 without any rotation? Why did you use +distort and not -distort?

Thanks!

see http://en.wikipedia.org/wiki/Rotation_(mathematics)

with regard to Two Dimensions, where

x'=x*cos(angle)-y*sin(angle)

y'=x*sin(angle)+y*cos(angle)

You may have to change signs of both sin(angle) terms depending upon how the rotation is defined as positive and whether y is up or down.

I think I have played already with those + and - somehow, I have to double check... thanks

[snibgo]

"-distort" crops the image and zeroes the offsets. "+distort" doesn't crop, so you get the entire rotated source, and doesn't zero the offsets.

Try opening the result in Gimp. With my command, you'll see the top-left of the rectangle has stayed at (0,0).

Use "-verbose" to get the six affine parameters. You don't need to calculate sin and cos yourself.

[fmw42]

x'=x*cos(angle)-y*sin(angle)

y'=x*sin(angle)+y*cos(angle)

These are relative to the center of the image. So you need to compute the center of the output image and add that back to x',y'

[troller]

With my command, you'll see the top-left of the rectangle has stayed at (0,0).

That is exactly what I would not want. I want to have in 0,0 the top-left of the whole new image, which will be on the white background "behind" the rotated rectangle.

[snibgo]

Okay. I'm not sure what you want, but this might help:

Code: Select all

F:\web\im>%IM%convert -verbose -size 400x300 xc:green -virtual-pixel None +distort SRT 1,20 g.png

xc:green=>green XC 400x300 400x300+0+0 16-bit sRGB 0.000u 0:00.000
Affine Projection:
  -distort AffineProjection \
      '0.939693,0.342020,-0.342020,0.939693,63.364497,-59.357922'
Affine Distort, FX Equivelent:
  -size 480x420 -page -40-60 xc: +insert \
  -fx 'ii=i+page.x+0.5; jj=j+page.y+0.5;
       xx=+0.939693*ii +0.342020*jj -39.241546;
       yy=-0.342020*ii +0.939693*jj +77.450136;
       v.p{ xx-v.page.x-.5, yy-v.page.y-.5 }' \
xc:green=>g.png XC 400x300=>480x420 480x420-40-60 8-bit sRGB 8.82KB 0.344u 0:00.046

From the line '0.939693,0.342020,-0.342020,0.939693,63.364497,-59.357922':

x' = 0.939693 * x - 0.342020 * y + 63.364497
y' = 0.342020 * x + 0.939693 * y - 59.357922

So (x,y)=(0,0) becomes (x',y')=(63.364497,-59.357922).

But, if you are doing a +repage, you need to subtract the offsets given in the final line. These are (-40, -60).

(63.364497,-59.357922) - (-40, -60) = (103.364497, 0.642078). This is the final new coordinate for the top-left corner.

[troller]

Ok thanks for the clarification.

So it seems that even if I don't want to use offsets, they just exist and appear...

It seems from this method that I have to manually look for the parameters using -verbose:info and then write them in the code for the new coordinates calculation, both the Tx, Ty and the Offsets. What if I wanted that the DOS shell program saves them as a variable and I can recall them automatically when needed? Like %tx% %ty% %offx% %offy% ?

Because I would have a set of images that need to be rotated, depending from image to image, with different angles (already automatically calculated).

Is there a way of saving as variables all the affine parameters and the offsets?

thanks for help.

[snibgo]

What if I wanted that the DOS shell program saves them as a variable and I can recall them automatically when needed?

You would write a script. You can easily get the offsets (-40 and -60) from IM "-format" escapes. See http://www.imagemagick.org/script/escape.php . The 6 affine parameters are more awkward. I would use a Windows FOR loop, skipping the first 3 lines.