Fix operator precedence in the zoom-out expression - #33
Conversation
Each phase of a camera move is built by dropping a `progress` string into
`1+${progress}*${scale-1}`. The zoom-in's progress is a single term, so it
survives that. The zoom-out's is `1-(in_time-H)/D`, which gives you
1+1-(in_time-H)/D*(scale-1)
and ffmpeg binds `*` tighter than `+`. So for a 1.5x move the zoom-out
starts at 2.0 instead of 1.5, eases down to 1.5 instead of 1.0, then snaps
when the clause expires. The pan expressions divide by the zoom, so the
framing is off for the whole window too.
The fix is the parentheses that make `progress` one term, matching the
shape the zoom-in already has.
tests/camera-move.test.ts asserted `toContain('1+1-(in_time')` inside a
test about move chaining. The expected string looks copied from the output,
so it pinned the bug and the suite stayed green. Corrected, intent
unchanged.
The tests I added evaluate the expression instead of matching its text,
which is what would have caught this. Four of them fail without the fix.
Fixes shreyaskarnik#31
47dc6ae to
d636487
Compare
geeksilva97
changed the title
|
Thanks @geeksilva97 ! Really appreciate your contribution. Possible to add a before and after video of the feature so we can check the fix? |
|
Merged — thanks @geeksilva97, and glad Argo's been useful 🙏 This shipped in v0.38.1, now on npm as The precedence diagnosis is exactly right, and I verified the zoom-in clause and the chained-pan lerp ( Particular thanks for replacing the |
oh sorry, i missed this comment |
2 participants
Fixes #31
I've been using Argo for a week and it's been amazing. Sending this patch to fix the abrupt zoom out.