Rotating an image changes its dimensions?

[[-hh]]

That is an authorative answer
Do you remember the 'accuracy' of the first intel chips?

[thatkeith]

Fascinating stuff. But I do think that some of the answers have gone off on a slight tangent (pun intended) that doesn't necessarily relate to the problem I observed. Setthing the angle of something to 1 will of course mess with its size, but that's not what I was doing. Try this:

1. Drop an image item onto a card. That image will be 120px square.
2. Test it by querying:

Code: Select all

put the width of image 1

3. Now is 'set the angle' to set the angle of that image to 90 degrees. Note: I am NOT setting it to 1 degree first or setting it to 91 degrees. It's being set to precisely 90 degrees.

Code: Select all

set the angle of image 1 to 90

4. Now check the image item's width. It will be 121px, as will its height.
5. Set the angle to 180 and it grows another pixel. Set it to 90 again and it grows a further 1 pixel.

I totally understand that rounding is a factor when setting the angle of something to a non-right-angle, er, angle. But why is it even a consideration when the angle is 90, 180 or 270 degrees?

[dunbarx]

Hi.

I just tried a few things:

1- I verified that my earlier test image increased by 1 pixel only at -90.
2- Then I changed height/width to 120,120.
3- Noticed no change at all anymore, setting angles to successive 90° increments.:

Code: Select all

on mouseUp
   set the angle of img 1 to the angle of img 1 + 90
   put the width of img 1 && the height of img 1 into fld 2
end mouseUp

But never saw what you did, that the increment accumulated, growing the image over successive settings.

4. Locked the loc.
5- Now I get 1 pixel increment at 180 AND 270. Sticks when I unlock the loc.

6- imported a new image, set its ht/wd, and locked loc. Ran the angle setting thing, Now it stays at 120,120 all day.

On LC 6.7, OS 10.9

Craig

[[-hh]]

@Craig
If you lockloc the size of an image then it should rotate inside that locked box and LC should adjust its size to fit in that locked box, this is just a different game.
An image of locked size 120x80 must stay at size 120x180 whatever angle you rotate it to.

@thatkeith
did you check that your image has no threeD or border activated?
I tested with the attached image at 0 and 90 degrees.
8.0.0-dp15: No change (200x150 rotates to 150x200)
7.1.2-rc3: No change (200x150 rotates to 150x200)
6.7.9-rc3: No change (200x150 rotates to 150x200)

In LC 8 (has a slider) one can watch the image changing its angle while the rect is visible.

In case this depends on OS/Hardware:
Above tests made with Mac 10.11.3/IntelHDGraphics4000.

[[-hh]]

Hi all,

now I have an example, that changes size here with LC 6/7/8 and a rotation by -90 degrees.
Supports your hypothesis of a bug, because after rotating the point changes where the OFFSET occurs.
1. Take the attached rectangular picture
2. Rotate it by 90 or -90 degrees
3. The size switches from 12x484 to 484x13.

Why may this be a bug and not a a rounding error?

Look at the attached screenshot. The offset I see here is marked (two times).
Now make a line graphic (as my red one) and drag that over and along the image: the offset location of the image changes. You can even push the offset along the image like a fold.

Do you also see such offsets with your example image, or reports it simply a changed size?

Hermann

[bn]

Just wanted to add some fine arts to the discussion about rotate command and images:

use the slider and slide it about 15 to 20 times back and forth and enjoy.

Kind regards
Bernd

[[-hh]]

Hi Bernd,

the most beautiful demo of the cumulative effect I've seen until now.
We could use this as a wanted "exploding effect".

If we use
     -- sum up trunc(pValue) in a variable SumValue
    set angle of img "aball.png" to 0; add trunc(pValue) to SumValue
    set angle of img "aball.png" to SumValue
instead of
    rotate image "aball.png" by trunc(pValue) --> Bernd shows with that cumulative errors, see attachment

there is here close to no error visible (using scalefactor 2).

Hermann

p.s. Did you already write the report to QCC?

[bn]

Hi Hermann,

p.s. Did you already write the report to QCC?

no, I think they can not do anything about it and the lesson is to use "angle" not "rotate"
I think there is somthing about rotate in the QCC

As an aside: did you know that the big bang really was a multidimensional "rotate" command running in a endless loop.

Well here in the Forums they tell you the truth and prove it with sample stacks...

Kind regards
Bernd

[[-hh]]

This is more interesting than all other work.

Code: Select all

on mouseUp
  set the text of image "aball.png" to the text of image "origImported"
  set the loc of image "aball.png" to 200,300
  repeat N
    repeat with i=1 to m
      rotate image "aball.png" by i
    end repeat
  end repeat
end mouseUp

N=4, m=360 yields an 1256 x 1408 image, looks chaotic.

N=0, the base is an 48 x 48 image:

N=0, the 'base' image

N=0.png (5.96 KiB) Viewed 7040 times

N=1, m=360 is an 146 x 171 image:

N=1, m=360

N=1.png (12.4 KiB) Viewed 7040 times

N=2, m=360 is an 319 x 291 image:

N=2, m=360

N=2.png (37.04 KiB) Viewed 7040 times

I'm currently thinking about how to determine N and m when a goal is given, say closest to 400 x 400. May be this requires chaos theory ...

WOW, from a simple ball, without own math, simply "rotate by", what a software!
Bernd, this is a highlight in your little-stacks-collection!
Must go to THERE!

[bn]

Hermann,

please be careful with N. See above comment about "Big Bang"

The Universe is going to fill up with "Red Matter"



Kind regards

Bernd

[[-hh]]

Bernd, your warnings always sound for me like "This is very interesting, you should try that".

So I did.
Reporting from my full-red-screen (very active colour!):

N=6 yields an 6027 x 6798 image
N=7 still running, takes 6GB (of 8GB) RAM ...

Just now LC crashed, and didn't say any word ... Perhaps a dimension overflow (the 65535-limit for coordinates, that limits every object).

Still cannot see a clear pattern behind that "explosion effect", until now it's "main stream clustering" seems to approximate a logarithmic spiral, should have more N, up to 8, for testing that.

hh

Back to clean my desktop, I set a deadline for that ...

Nice: Writing "(up to 8" & ")" yields a smiley: (up to

[bn]

For ThatKeith,

here is a stack that lets you turn an image by 90 degrees counterclockwise without changing its dimensions.

It just turns the imageData. In case you have a png with varying transparencies one would have to turn the alphaData also.

Kind regards

Bernd

[[-hh]]

@thatkeith
Was a really valuable thread you opened!
You should report the one-pixel offset as bug, we can confirm that.

I learned especially the fact that drawing lines between rotated vertices (=graphics) is producing less errors than rotating the pixels of vertices AND of the lines between them (=images). It's obvious now but I didn't see that when reading thatkeith's opening post.

@Bernd,
This is a valuable stack for a lot of users. Should go as a special case into the engine:
The (randomized) one pixel offset could be (at least partially) solved by handling the rotation by multiples of 90 degrees as special cases.

Why not a 'little stack' here and in your collection with all multiples of 90 degrees (for imagedata and alphadata)? You have it already nearly complete ...

Hermann

[thatkeith]

Hi all,

I'm using 'rotate image 10 by -90' instead of setting the angle and it's working fine. I'm very happy to have helped unearth this bug/buglet, but re reporting it... I don't know if I could possibly explain it as well as recent posters have with those 'big bang' examples. (Which look spectacular btw - I think we're not far from creating a virtual Large Hadron Collider!)

I'll look at the reporting process later, but don't let that stop anyone from doing it themselves.