Rotating an image changes its dimensions?

[thatkeith]

I know if I set the angle of an image by some angle other than 90, 180 etc I can expect the size of the object to change. But when I set the angle of image 1 to -90 and test the width and height, it should remain the same but in fact it has increased by one pixel. Try this with a simple image object: drop it on a card, check the width and height, set the angle to 90, check the width and height again: it will have increased by 1. Set it to 180, it increases once more. Set it to 90 again, it increases yet again.

Is this a bug or some kind of expected behaviour? Any thoughts on working around it? Simply setting the size to what it should be doesn't seem to have any effect on the output.

(The context is six square bitmap images that need to be placed butted up together horizontally in a row, but with the third and fourth images rotated -90. When I don't rotate any of them it works perfectly. When I do, the exported bitmap is slightly taller and wider than it should be, the non-rotated images are up by one pixel, and the rotated ones are also offset by one pixel. Odd.

[dunbarx]

Hmmm.

Confirmed here. Continuous "rotate" commands on a image do not change its width and height. But setting of the angle to -90 (and you can get there by one change of -90 or three changes of +90) do increase both properties by one pixel. It reverts back to the original as you go around, only increasing at that -90 value.

I would send this along to the QCC.

Craig Newman

EDIT:

If you set an image width and height to, say, 100/100, and "rotate", those properties stick. If you then set the angle to -90, the new values are 101/101. If you then "rotate" some more, you are stuck at 101/101. If you then set the angle to 0, say, the values revert to the original 100/100.

So it is ephemeral, only at -90, and does not change the properties per se, but rather only "expands" at -90.

[thatkeith]

Heh. Dangit, not the answer I was hoping for! Okay, could someone remind me what the bug reporting URL is?

[dunbarx]

Hi.

Read my edits.

Report to:http://quality.livecode.com

Craig

[thatkeith]

In the meantime it looks like "import paint" rather than setting the fileName of an image object might be a solution.

[Dixie]

Does it help if you...

Set the margins of the image to 0
lock the size & position
Group the image
Set the margins of the group to 0
lock the size & position

I have just taken an image 182 x 182 pixels and done the above... then duplicated it 5 times...
When rotating them or setting the angle I do see them moving out of line, as it were...

[[-hh]]

Hi all,

this is due to rounding errors. The rotation is computed using trigonometric functions and rounded at end. This may lead to 1 pixel errors. There is no special handling of rotations of objects for multiples of 90 degrees.

We have to do such special case by our own --- and we know the exact result in advance.

Also:
Continued rotations lead to continued errors that may fully sum up in worst case, as you describe. My method is here, to remember the "base angle" of an object as a property and then rotate for example from that base by 30,60,90,120 degrees instead of four times by 30 degrees. By that we have at most the 'one-time-error'.

Hermann

[dunbarx]

Hermann.

I knew you would find the likely culprit.

But then why does only a -90 cause the error, and not +90?

Craig

[[-hh]]

But then why does only a -90 cause the error, and not +90?

It's probably (roughly) like that: Imagine to rotate from 12 o'clock (horizontal value 0) one time to 3 o'clock (to a positive horizontal value and the other time to 9 o'clock (to a negative horizontal value). If the math library now both times rounds UP then this may result in a 1-2 pixel difference.

That's why some use, instead of round(), statround() which is somehow better "averaging" errors.
[And which is, as I read just now in the dictionary, HyperTalk's round()].

... Hey Craig, are you already back from your triumphal procession?

[dunbarx]

Hermann.

... back from your triumphal procession?

I am back from lunch.

So it's the old HC trick? I think this derived from financial concerns, where millions of rounding errors were split into two groups depending on whether the last digit before the decimal point was even or odd, so that the total aggregate would end up not accumulating (or depreciating) and bankrupt the US economy.

The error has to be exactly half a pixel, no? It cannot be 0.55 or 0.45, since these would not engender the odd/even split.

Craig

[[-hh]]

Yes of course.
But it's not *so* seldom because you have two coordinates, horizontal and vertical, where the error may occur and the values are typically of type "large integer" radius and "small real value" (float) sin or cos multiplied (r*cos(x), r*sin(y) what is additionally a source of small errors.

'statround()' doesn't avoid such errors but is suited better for narrowing error ranges if rounding (and adding) a lot, as you say.

My strategy to ignore rounding errors is to take off my glasses and increase the lineSize.
Some call this effect "blurring", is again 'trendy' in CSS3. [Sorry, I had already half a glass of real good french wine.]

Craig, have a nice weekend!

[thatkeith]

this is due to rounding errors. The rotation is computed using trigonometric functions and rounded at end. This may lead to 1 pixel errors. There is no special handling of rotations of objects for multiples of 90 degrees.

Okay, if you say so!

But seriously, I'm afraid I don't understand why rotating (setting the angle) by 90 leads to non-whole numbers. If something's 120 pixels tall and rotated 90 degrees it should be 120 pixels wide, no? Additionally, if I set the angle to 180 the image object grows by one pixel! To me, something's wrong there.

[FourthWorld]

But seriously, I'm afraid I don't understand why rotating (setting the angle) by 90 leads to non-whole numbers.

You could find out straight from the source:
https://github.com/livecode/livecode
https://skia.org/



Given that LC uses the popular Skia library for its graphics subsystem, I suspect it's not a bug but a feature, or more specifically that it's related to the resolution-independence, the need to translate coordinates between conceptual space and physical pixels.

Just a hunch. It would be nice if someone on the dev team (or anyone who's taken the time to go through the Skia source) could comment authoritatively on this.

[[-hh]]

But seriously, I'm afraid I don't understand why rotating (setting the angle) by 90 leads to non-whole numbers. If something's 120 pixels tall and rotated 90 degrees it should be 120 pixels wide, no? Additionally, if I set the angle to 180 the image object grows by one pixel! To me, something's wrong there.

This depends on the points that define the rectangle of the object and thus width and height. (Of course, mostly, if "directly" computed, you will have that theoretical result true in your graphic.)
[Also think of how width and height are computed: From rounded integers. The "more exact" width and height may have changed (before rounding) by only 0.01 px.]

Example of changing size when rotating by 90 degrees:
Take a triangle (3-regularPoly) of radius 100, rotate it to 1 degree, clockwise from 12 o'clock. Then "width x height" is "177 x 156". Rotate it by 90 degrees to 91 degrees. Then "width x height" is "155 x 177".

I wrote a script for "direct" computation of the points of a regular poly.
That's standard math, nothing can be different in correct libraries.
I attached below the stack (one of "Raspi-stacks"), that now shows the points rounded to 2 decimals and also "width x height" (at midLeft).

If you don't wish to use the stack, here are the points
[radius 100 around the origin (230,230), lineSize=3]
[Edit: NOTE that if linesize=3 then 4 pixels, 2 from each 'side', are added to width and height given by the points.]

• Unrotated (0 degrees): width 178, height 154
  230.00,130.00
  316.60,280.00
  143.40,280.00
  230.00,130.00
• Rotated to 1 degree: width 177, height 156
  231.75,130.02
  315.72,281.50
  142.54,278.48
  231.75,130.02
• Rotated to 91 degrees: width 155, height 177
  329.98,231.75
  178.50,315.72
  181.52,142.54
  329.98,231.75

((If we compute more 'exact' then we get 178.496 instead of 178.50 and the width is 156.
OK, then you'll find a changing example if you use tenth of degrees, and so on ...))
This always remains the same problem, at a "closer-look-level" when using high-res displays and huge libraries:
The difference is then not 1 px but, say and be lucky, 0.01 (current) px.
Also Skia and maximal blue advertising can't divide your physical pixels.
And the formula remains 'simple' math, also when using high-res displays and huge libraries:

Code: Select all

-- n = num of vertices; a = angle cw from 12 o'clock, may be negative
-- r = radius of enclosing circle; x0,y0 = origin
function regularPoints n,a,r,x0,y0
  put 2*pi/n into cn
  -- n vertices --> n+1 points if 'closed' polygon
  -- usually done by setting last=first
  -- This is here true as sin(0)=sin(2*pi) and cos(0)=cos(2*pi)
  put empty into pts ; set numberformat to "#.00" --> added for this demo here
  if a=0 then
    ## compute unrotated n+1 vertices of the n-sided regular polygon
    repeat with j= 0 to n
      put CR & ((r*sin(j*cn)+x0),(-r*cos(j*cn)+y0)) after pts
    end repeat
   else
    ## compute *rotated* n+1 vertices of the n-sided regular polygon
    put sin(pi*a/180) into s; put cos(pi*a/180) into c 
    repeat with j= 0 to n
      put ( r*sin(j*cn)) into sx; put (-r*cos(j*cn)) into sy
      put CR & ( ((x0+c*sx-s*sy),(y0+c*sy+s*sx)) ) after pts
    end repeat
  end if
  return char 2 to -1 of pts
end regularPoints

Now I'm really looking forward to an "authoritative" answer, whatever this should be.
Math is true or not true, independent of an "authority", Richard

[Edit. Sorry, the first version had wrong point lists for the rotated: copy/paste-error...]

[FourthWorld]

Well, there's math, and then there's the weird things computers do to simulate math.