Sivakatirswami wrote:
OK... this leads to larger, more fundamental questions on video sprit
still animation of any object, be it pan-zoom photo or just any
object moving across the screen:
Since screens are made of pixels, I always thought that a "sub-pixel"
position was a "vikalpa" (the horn on the hare, the cheese in the
moon -- a idea that has no basis in reality) But if indeed you are
correct that the reason e.g. Flash animation is so smooth, is because
movement is calculated across sub-pixels points, then this means that
one might try, for example:
set the topleft of image 1 to 1.121,12.675
This just doesn't work in Rev... nothing happens, no error and no
change in the image loc
As for a zoom function, in Rev. I think we can only address video
pixels as whole integers and that screen positions really are never
more than whole integer pixel positions, in any context...
Well, you can set the rect of an image to non-integer values (see your
code below for an example :-)
I'm sure it gets rounded to an integer pixel when rendered - but using
the rect does allow you to avoid handling the rounding yourself.
Can anyone improve on the smoothness of this zoom function, just
import an image into any stack and add this buttondddddddddddd
on zoomIn
repeat 50 times
set the rect of image 1 to (zoomIn(the rect of image 1))
wait .5 millisecond
end repeat
# this is not too bad depending on the "continuoustoneness" of the
jpg.. the more "edges" the more pixelated the zoom appears.
I'm not sure there is any value in using a time period below 1
millisecond (in fact, I'm not sure it does).
end zoomIn
function zoomIn tRect
subtract 1 from item 1 of tRect
subtract 1 from item 2 of tRect
add 1 to item 3 of tRect
put ( (item 3 of tRect-item 1 of tRect) * tRatio) + item 2 of tRect
into item 4 of tRect
return tRect
end zoomIn
This won't work so well for non-square images.
The width increases by 2 on each step, so 100 total, keeping properly
centred.
But for a tall skinny image (say 4 times as high as it is wide), this
means the height goes up by 8 on each step - but the top changes by only
1 pixel, so the bottom moves down by 7. And conversely for a wide,
shallow image.
For images that are close to square, this "drift" won't be obvious - but
I think it will make the zoom less smooth.
You can avoid that by calculating the revised height, and then centering
that around the height.
function zoomIn tRect
put tRect into saferect
subtract 1 from item 1 of tRect
add 1 to item 3 of tRect
put ( (item 3 of tRect - item 1 of tRect) * tRatio) / 2 into
tNewHalfHeight
put (item 2 of tRect + item 4 of tRect) / 2 into tNewCentre
put tNewCentre - tNewHalfHeight into item 2 of tRect
put tNewCentre + tNewHalfHeight into item 4 of tRect
put saferect && tRect & cr after msg
return tRect
end zoomIn
Sivakatirswami
On May 15, 2006, at 1:19 PM, Wally Rodriguez wrote:
The Ken Burns effect, as used in other applications, has to be
calculated on a sub-pixel level so that it does not look jerky, that
is because some combinations of start point, size and speed could
yield sizes or motion that can't be rounded to one pixel.
There must be a way to do this smoothly on the mac, since the screen
saver does it, but I couldn't even start to tell you how.
_______________________________________________
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
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.6/340 - Release Date: 15/05/2006
_______________________________________________
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
