Ken Burns Effect Algorithm-Functions

[Sivakatirswami]

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

Can anyone improve  on the smoothness of this zoom function, just  
import an image into any stack and add this buttondddddddddddd

local tRatio

on mouseUp
# set up  a reset  for testing purposes
   if the uOriginalSize of img 1 is empty then
      set the uOriginalSize of img 1 to the rect of image 1
   else
    set the rect of image 1 to the uOriginalSize of img 1
   end if

   put the height of image 1/the width  of  image 1 into tRatio
   zoomIn
end mouseUp

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.

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


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