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>




_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to