First test for Infinite Zoom

[Wilhelm Sanke]

Alejandro,

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 
side.

Nevertheless, here are some observations mainly concerning "infinite 
zooming in":

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:

on mouseUp
   put the rect of grc "select" into trect
   export snapshot from rect(trect) of img "test" to img "test" as PNG
end mouseUp

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

<http://www.sanke.org/Software/ThumbsAndSlides09.zip>

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

<http://www.sanke.org/Software/SlideShow-Win.zip>

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 
jerky.
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.

Regards,

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