Ken Burns Effect Algorithm-Functions

[Alex Tweedly]

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
> use-revolution at lists.runrev.com
> 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