Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)

[Wilhelm Sanke]

In the meantime I managed to have a look at the two stacks Scott and 
Capellan offered in this context.
 
Capellan had written:

> Hi Wilhelm,
>
> Take a look at the script of this stack,
> to check if some code is useful:
>
> http://www.geocities.com/capellan2000/mask_bitmap02.zip
>
> This version included the option to crop
> the image while masking. 

Your stack that demonstrates possibilities to use masks is surely 
impressive, but I failed to find a script in the stack that includes a 
cropping algorithm.
Could it be that "the option to crop" is contained in a different 
version of your stack?

===

Scott Rossi had offered a sample stack for cropping in his first post of 
this thread:

> "http://www.tactilemedia.com/download/crop2alphaRect.rev"
>
> The stack generates a random regular polygon and then creates a matching
> image cropped to the extents of the original graphic.

Thanks again for your contributions to this thread, Scott.

Your carefully scripted cropping procedure indeed manages to crop an 
image - snapshot-generated from a graphic - to its visual rect precisely 
to the last pixel.

I changed the polysides property in your script for higher values and 
learned that (with the exception of a rhomb - a 4-sided regular polygon) 
indeed all regular polygons possess "visual" rects that differ from  
their proper rects. In the case of a 13-sided regular polygon - given 
the size of your graphics in your sample stack - this difference still 
is one pixel, certainly negligible, but the difference is there.

My own approach to crop images to their visual rects has so far been a 
simple and manual one: I place a rect over the image, adjust it manually 
to the edges of the visual contents of the image, and then crop the 
image to the rect of the overlying rect.--

===

What has been overlooked to some extent in your responses was that my 
original question concerned the "cropping" of a *graphic* and as a 
*graphic* to its "visual" rect.

As selection tools (to access a portion of an image for further 
processing) I have used freely painted polygons - as distinct from 
"regular polygons" - for quite a long time in my image processing 
stacks. My G.W.Bush caricature, which I had presented to this list two 
years ago and which elicited very diverse responses, was produced with 
my "Photo Patchworks" stack using among other selection graphics also 
normal hand-drawn polygons.

With normal hand-drawn polygons there are *no* differences between rects 
and visual rects. The sense or the reason why "regular" polygons should 
possess such differences escape me. Maybe it is just a case of "sloppy" 
programming, "sloppy" meaning in this case that the relevant script 
parts of the engine could be easily improved to abolish such differences 
in regular polygons.

I have experimented a bit and offer here some thoughts and script 
examples how to convert "regular polygons" to "polygons" without rect 
differences:

Polygons have "points" that determine the shape of the graphic.
If you ask for the points of a "regular polygon" you just get the rect 
values. The shape of a regular polygon is defined by the polysides 
property and its angle.

You can convert a polygon to a regular polygon and vice versa by using 
"set the style of grc x to "regular" (or "polygon")".
If you convert a polygon to a regular polygon you inevitably get a 
four-sided rhomb, no matter how many sides your original polygon has 
possessed - unless you determine the number of polysides beforehand.

The other way round, converting a regular polygon to a polygon leaves 
you with an *empty* graphic, because the points of its rect are not 
acknowledged as valid points for the polygon.
But you can define the points of a regular polygon - for example by 
setting its "points" to the points of a normal polygon. Nothing will 
happen here when you set these points, until you then convert the 
regular to a normal polygon. After such a conversion you can switch 
between the two "styles" of the polygon (set the style of grc x to ..) 
and will see the different shapes of the styles.
Of course it is not reasonable to set the points of a regular to that of 
a normal polygon, because this normal polygon already exists and can be 
used for any purposes.

The question is, how do you compute the points of a polygon (that will 
extend to the full size of the rect of a regular polygon without 
differences between rect and visual rect) if you do not have a normal 
polygon as a template?

Example 1:

Create a regular three-sided polygon and set its angle to 30. You will 
get an upright triangle with a substantial transparent part at the 
bottom of its rect.
Get the dimensions of the rect, compute the points, and then convert it 
to a normal polygon using a script like this:

on mouseUp
  put the topleft of grc "Test" into TL
  put the bottomleft of grc "Test" into BL
  put the bottomright of grc "Test" into BR
  put the width of grc "Test" into twidth
  put trunc(twidth/2) into twidthhalf
  #=========set the points for the "free" polygon=======
  put empty into tpoints
  put (item 1 of TL + twidthhalf, item 2 of TL) into tpoints
  # for the first line of tpoints "put into"
  put CR&BL after tpoints
  put CR&BR after tpoints
  put CR& (item 1 of TL) + twidthhalf, item 2 of TL after tpoints
  #========================
  set the points of grc "Test" to tpoints
  set the style of grc "Test" to "polygon"
end mouseUp

Now you have got a polygon that extends to the size of the full rect of 
the former regular polygon, displaying *no* differences between rect and 
visual rect.

Now add two buttons for converting grc "test" from polygon to regular 
polygon and the other way round and you can see the effects

Example 2:

Create a hexagon, a six-sided regular polygon, then use this somewhat 
more detailed script:

on mouseUp
  put the topleft of grc "Test2" into TL
  put the topright of grc "Test2" into TR
  put the bottomleft of grc "Test2" into BL
  put the bottomright of grc "Test2" into BR
  put the width of grc "Test2" into twidth
  put the height of grc "Test2" into theight
  put trunc(twidth/4) into twidthquart
  put trunc(theight/2) into theighthalf
  #=========set the points for the "free" hexagon polygon==================
  put empty into tpoints
  put (item 1 of TL + twidthquart, item 2 of TL) into tpoints
  # for the first line of tpoints "put into"
  put Cr& (item 1 of TL, item 2 of TL + theighthalf) after tpoints
  put CR& (item 1 of BL + twidthquart, item 2 of BL) after tpoints
  put CR& (item 1 of BR - twidthquart, item 2 of BR) after tpoints
  put Cr& (item 1 of BR, item 2 of BR - theighthalf) after tpoints
  put CR& (item 1 of TR - twidthquart, item 2 of TR) after tpoints
  put CR& (item 1 of TL + twidthquart, item 2 of TL) after tpoints
   #========================
  set the points of grc "Test2" to tpoints
  set the style of grc "Test2" to "polygon"
end mouseUp

Add another two buttons for converting the styles of grc "Test2" like in 
the above example.---

What is obvious is that in the first place you do not need a regular 
polygon to compute the points of a polygon without differences between 
rects and visual rects, all that you need are just the dimensions of a rect!

The calculation of the points for other numbers of sides may require  
more effort, but seems to be feasable.

I conclude: I think it should be a relatively easy task for the 
programmers of Revolution (or Transcript, RevTalk etc.) to abolish the 
inconsistency of regular polygons of  having different sizes for visual 
rects and their proper rects as a graphic.

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>