Hi,

I wish to use the trajectory feature of video overlays to achieve a sort of "bouncing ball' effect over text overlay lyrics in a music video. Generating, placing, and timing the text overlay is no problem, nor is placing the "ball"-object video overlay and fixing its trajectory a problem. However, even tho' I reduce the size of this overlay object before establishing a trajectory, in the resulting video it increases in size toward its "default" size as it traverses the trajectory. The only way I've found to counteract this behavior is to manually re-reduce the size of the overlay object at each of several "stops" along the trajectory, and even with this sort of correction the object attempts to "grow" between such "stops."

1) Why does this occur? It does not seem like a behavior video developers would usually want, and therefore seem to me to be a bug rather than a feature.

2) Is there a more direct and/or less labor intensive and more effective way to prevent this behavior?

3) If it is indeed a bug, please acknowledge that an let us users know whether/when we can look for a correction, or at least a mechanism to force the initial user-set overlay object size to be maintained during a trajectory.

Thanks in advance for your prompt attention to this inquiry.

Stan Hall

To: stanwhjr

Could you possibly attach a screenshot showing the trajectory you have created (Video Overlay window). We'll try to reproduce the problem.

Thank you

To: nadin


Hi nadin, and thainks for responding. I can and certainly will supply ASAP a step-by-step description of creating a video that exhibits the problem I've described along with illustrative screenshots. Would it help more if I also or instead upload an actual brief (sya about 10 seconds) sample video to dynamically show what happens?

I've found AVS Video Editor, esp. with all the improvements realized in version 4 over version 3.5, to be a marvelous program, very easy to use in achieving nearly all the results I want. And while I do have a semi-acceptable workaround for this problem, a trajectory feature whos behavior is better aligned with intuitive expectations would mark yet another huge improvement.

In the past I've found support via this forum re the very few problems I've encountered using AVS products timely, attentive, and effective, and look forward to any dialog that will aid progress toward this problem's solution.

Stan

To: stanwhjr
Thank you very much for your feeback!

stanwhjr:

Would it help more if I also or instead upload an actual brief (sya about 10 seconds) sample video to dynamically show what happens?

Certainly it would.
If the video is bigger than 10 Mb in size, you can upload to our FTP. I'll submit the instruction on the support page.

Kind regards

nadin:

To: stanwhjr Thank you very much for your feeback! stanwhjr: Would it help more if I also or instead upload an actual brief (sya about 10 seconds) sample video to dynamically show what happens? Certainly it would. If the video is bigger than 10 Mb in size, you can upload to our FTP. I'll submit the instruction on the support page. Kind regards

Hi again, nadin.

In fact, while preparing an extensive step-by-step set of screenshots to illustrate the problem I discovered the simple solution to the problem I was having. The overlay editor is indeed handling overlay trajectories exactly as it is "told" to in that, if the overlay element is explicity sized at successive timestamp points it only changes size between those points to the extent that their programmed sizes differ. Therefore, if after initally placing the trajectory, the overlay object sized as desired at its two extreme endpoints, that size will be retained at and between any subsequently added "internal" timestamps without needing to explicitly resize at each. Of course, that the object can if desired be explicitly reisized at any of those timestamps is potentiallu very useful.

The Video Editor's help documentation doesn't specifically address this matter, but it might helpfully be amended to do so. I think many users may, like me, intuitively expect an overlay object, if resized at a timestamp point -- usually the first one --on a trajectory, to retain that size as the "default" unless/until resized at a later one. A full discussion of what by default does, and what can be programmed to, happen to an object moving along a trajectory might save users some initial frustration.

One other minor and unrelated matter I want to mention in passing has to do with the Chromakey effect. I've used it quite successfully to achieve "Green Screen" overlay effects, but the Chromakey slider seems to work in an all-or-none manner. That's to say the specified Chromakey color either disappears entirely or not at all. That's appropriate for most "Green Screen" uses, but I can imagine some instances in which partial transparency of the Chromakey color in the overlay might be desirable. That the Chromakey effect is activated vai a slider rather than, say, a checkbox, that capability is suggested, but it seems that any nonzero setting of the Chromakey slider forces teh selected color to complete transparency.

In any case, the more I use AVS Video Editor, the more pleased I am with its versatility, despite what seem some quirky bits of implementation. Nothing I've found elsewhere for a similar price comes anywhere near its range of features and ease of use. Kudos to the development team.

stanwhjr:

I think many users may, like me, intuitively expect an overlay object, if resized at a timestamp point -- usually the first one --on a trajectory, to retain that size as the "default" unless/until resized at a later one.

Your comments sound reasonable. I will report this suggestion to our developers, so that in future versions, if the overlay picture size is changed prior to setting the trajectory, it's new size is counted as default for all time stamp points of the trajectory path created.

stanwhjr:

One other minor and unrelated matter I want to mention in passing has to do with the Chromakey effect. I've used it quite successfully to achieve "Green Screen" overlay effects, but the Chromakey slider seems to work in an all-or-none manner.

It was already suggested by one of our users to implement a tolerance setting for chromakey. You must be talking about the same tool. We will do our best to offer it in future.

Once again thanks a lot for your feedback and useful comments! If there are any further suggestions, please feel free to post.