Resizing track motion

whydahlog wrote on 10/4/2007, 5:20 AM
Not sue if this is a bug VMS 6 or I have missed a trick somewhere.

The requirement is to resize a 'window', set up through track motion, that is almost full screen to a 'window' somewhat smaller in the top left of the screen.
I have activated track motion, turned off the 'size about centre' and set the new size and position. The start and end keyframes are just what I want but when the clip is run and actually resizing, the top left corner of the 'window' does not keep to position and moves around the screen by a few pixels (10 to 20). The whole result is very scruffy and untidy.

Is this a bug in the system or have I missed a trick? I am about to upgrade to Pro 8, so if it is a bug, has it been fixed?

I hope I have explained the problem well enough to understand, or replicate, and that someone has the answer.

Thanks.

Comments

rustier wrote on 10/4/2007, 7:16 AM
I have no problem with it. I didn't bother to turn off scale about center. Perhaps that is it. I did a fast transition and it was fine. A slow transition does appear to make the edge scruffy. Have you done a short render of the section to see if this is really the case?
If you are doing a really slow transition you may want to try a small border to hide the "scruffyness". You might want to play with the keyframe type to see if that helps.

This is the first I have heard of anyone having such a problem so I don't think it is a bug. Good luck with it.
Chienworks wrote on 10/4/2007, 7:45 AM
The keyframe smoothness is probably the culprit. Set the smoothness of all keyframes to 0% and see what happens.
whydahlog wrote on 10/5/2007, 5:19 AM
Thanks for the answers guys and I will try reducing smoothness to 0%, but I don’t think I have explained the problem very well.

What I want.
I have a clip running in a window that is almost full screen (a picture with pseudo border around it). I now want that window to shrink to a smaller size over a second or so and be positioned top left of the screen. During the shrinking, the top left corner of the window must not move but remain static and anchored to the spot.
What I did.
Using track motion I set the size and initial position of the window, set the timeframes at which I want the shrinking to start and stop, and set the final window size also at the stop timeframe. I have turned resize about centre to OFF. I expect the top left corner to remain static, and the bottom right corner to simply move towards top left until the specified size is reached.
What I got.
When the sequence is run and the image resizes, the top left corner of the window is not static but wanders around the top left of the screen until the final timeframe is reached. At this point the window is in the correct position and at the correct size.
Have I missed a trick somewhere? Is there an option to anchor a corner?

One answer of course is to run the sequence fast enough that the ‘error’ is not noticed, but this is a cop out and not really an option in this sequence. However, I still feel that this is a bug, or maybe VMS can not handle this scenario.

Any ideas?
rustier wrote on 10/5/2007, 6:47 AM
I don't think its a bug. Apparently finding the edge of a shrinking clip and panning at the same time while keeping it pinned to the corner is hard (for VMS).

If you don't mind losing a slice of the edge I would suggest you adjust your track motion width and height at the beginning of the clip to say 750 x 500 (assuming this is standard video) and shift your x coordinate minus 10 - or whatever number places the "edge" out of view.

One other thing to consider, if this is going to be shown on a TV the odds are strong this activity at the corner will be out of the field of vision. Perhaps if you rendered a short loop of the point in question you could confirm this.

Hope that helps

Good luck with it.
whydahlog wrote on 10/8/2007, 5:05 AM
Thanks Rustier. I also think that the reequriement is outside the capabilities of VMS.
Don't see why it should be difficult, simply a matter of vectoring. Maybe Sony will pick up on it and resolve it in a future release.
Giisty wrote on 10/10/2007, 3:00 AM
I have also had similar issues with this exact challenge. I also thought that i must have been missing something because, in theory, it should not be hard to accomplish
Michael.