ansaurus

Question

Transformation (rotation) of image using matrix - design-time vs. run-time rendering results

Answer 1

A:

How are you specifying your angle of rotation? in Degrees or in Radians?

Sometimes I get results like those you describe when I've accidentally specified my angle in degrees when it should've been radians (and as a result the object has been rotated several hundred degrees instead of a few)

I don't know for sure given your specific example, but its worth suggesting.

Phill 2009-07-14 09:16:43

Hi Phill, thank you for your response! Unfornutately this is not the source of the problem. The Matrix.RotateAt() method takes an angle argument that should be specified in degrees, which is what I have done.

Bernhof 2009-07-14 09:26:55

Answer 2

A:

Hm, my consideration is to try:

lMatrix.RotateAt(pAngle, new PointF((pImage.Width + 1)/2.0f, (pImage.Height + 1)/ 2.0f));

Mihail 2009-07-14 09:37:00

I tested your suggestion, but it simply offsets the entire animation. The irregularities at 90, 180 and 270 degrees rotation still occur in run-time. I'd like to think that the code works just fine as it is, since the animation already looks perfect in design-time. What I'm wondering is what's causing the difference in run-time results.

Bernhof 2009-07-14 10:05:43

That means I was wrong... So does the run-time angle values in 90, 180 and 270 placements are absolutely equal to that values?

Mihail 2009-07-14 10:13:59

The screenshot was taken at exactly 90 degrees rotation. At exactly 180 and 270 degrees rotation the image also seems to be slightly offset.

Bernhof 2009-07-14 10:24:58

Really strange. Is your step fixed? If no, may be you can change it a bit and see how it will affect run-time?..

Mihail 2009-07-14 10:36:13

Yes, if I use a step size that avoids the 90/180/270 angles, there is no problem. I have posted a workaround below, which ensures that these angles are avoided altogether. I'm still wondering why this is necessary, though.

Bernhof 2009-07-14 11:26:34

Answer 3

+2 A:

It might have something to do with differences in the Graphics object used at design time versus run time like the PixelOffsetMode.

BlueMonkMN 2009-07-14 11:35:08

Amazing! Changning Graphics.PixelOffsetMode to HighQuality caused the result to be even more satisfying than the current design-time results. The animation now looks perfect. Thanks a lot BlueMonkMN, you made my day :)

Bernhof 2009-07-14 12:49:42

PixelOffsetMode.Half also gets the job done in my case.

Bernhof 2009-07-14 13:17:23

Answer 4

A:

I think that should be a problem about the math being performed in floating point; when rounding back to integer coordinates.

One question that might be relevant... is your image completely square and the width and height an even number? Maybe the problem lies there.

Edit: In the first read I passed through the dimensions of the image... If that wasn't the problem maybe you could do a simple rotation by yourself:

angle = 90 : img[i][j] = img[j][w-i]
angle = 180: img[i][j] = img[w-i][w-j]
angle = 270: img[i][j] = img[w-j][i]

(I think the index swappings are ok, but a double check won't be bad)

fortran 2009-07-14 13:29:59

I believe the transformation actually supports rotation around a floating point e.g. (24.5, 24.5), when using matrices. The Matrix.RotateAt method only accepts a PointF struct anyway.I'm not sure how to use your example, but I solved the problem by setting the PixelOffsetMode property of the Graphics object to a higher value. This was the cause of the problem. If I wanted to use other means of rotating an image 90, 180 or 270 degrees, there is also the RotateFlip method on the Image class.In any case, thanks for your input!

Bernhof 2009-07-15 07:42:47

ansaurus

tags:

views:

answers:

Transformation (rotation) of image using matrix - design-time vs. run-time rendering results

related questions