First test for Infinite Zoom
sanke at hrz.uni-kassel.de
Tue Nov 17 12:50:21 CST 2009
I finally found the time to look at your "Infinite Zoom" stack. After
some changes to your code - I hope they were the right ones, i.e. not
being counterproductive to your own intentions - I managed to start your
stack, but using 6 images of my own in a folder "images"
I understand that in your stack "Zoom_infinite.rev" you "zoom out" a
sucession of images in a stepwise fashion to achieve a decreasing size
of the images which finally converge towards an "infinite" point, and
after that you start all over again with a big-sized image.
At first, before I had tried your stack, my understanding had been that
your perspective was how to implement an "infinitely" continuing zoom
into or out of images (the latter of which, decreasing the size of an
image until it vanishes, would be of course quite simple). I therefore
looked at a number of scripts for (proportional) resizing of images I
had tried in various image-processing stacks.
What I am going to mention here, may well beside your specific point of
view concerning "infinite zoom" and meet with limited interest from your
Nevertheless, here are some observations mainly concerning "infinite
1. The only procedure with which you can really "zoom-in infinitely"
into an image is to take a continuing and everlasting succession of
snapshots from a smaller rect of an image.
Place a rectangle graphic (the graphic can be even hidden) on top of an
image that has its "Lock Location" set to true (to preserve the size of
the image) and then apply the following two-liner:
put the rect of grc "select" into trect
export snapshot from rect(trect) of img "test" to img "test" as PNG
You could also put the snapshot line inside a repeat loop to achieve a
stepwise zooming-in effect remotely similar to the effect in your stack,
but in this example with only one image. The "quality" of the zoomed-in
images will of course depend on the set "resizequality" of the image.
Although you indeed could continue such a procedure "forever", it makes
sense only up to a certain point.
2. On the "slides page" of my stack
you can enlarge or shrink the selected images proportionally in steps.
If - when enlarging and therefore "zooming in" in the visible windows -
you reach a size of about
width = 18000 pixels, height = 14000 pixels
Revolution will crash immediately and silently without an error message,
simply vanishing from the screen, stack and IDE (Tested on WindowsXP
with Rev 3.5 and 4.0).
3.On the slideshow card of my old sample stack
you can smoothly and proportionally zoom in and out of an image using a
slider. I have restricted the maximal size here to about 3000 x 2500.
The smoothness of the zooming procedure ist best with the resizequality
set to "normal". "Good" for the resizequality is still smooth and
tolerable on a fast computer, with "best" the zooming process begins to
slow down considerably in the upper size range.
To test the "crash limits" found above in example 2 I put an image and a
zoom-slider on a card - with the end value of the scrollbar set to
19000 and zooming an image with equal values for width and height.
With "normal" resize quality the zooming was nearly smooth up to the
value of 4000. Above 4000 the zooming process became increasingly more
With the resizequality set the to "best", zooming above 4000 was
virtually impossible, whereas zooming stepwise in the "ThumbsAndSlides"
stack occurred without a noticeable time lag even with resizequality
"best" and up to the crash size of 18000 X 14000.
When using the zoom-slider, the crash of Rev - as described above -
occurs at an image size of about 16000 X 16000, meaning that Revolution
can "accommodate" images up to 256 million pixels, at least if there are
blown up to such a size inside Revolution.
More information about the use-livecode