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>
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
