mltframework / mltframework/shotcut
Filter Size, Position and Rotate buggy coordinates reference frame when rotating
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 15.2k
- Forks
- 1.5k
- Avg merge
- 11h 27m
- Merged PRs (30d)
- 5
Description
OS and Version (please complete the following information):
- Operating System: Windows 11
- Shotcut Version: 26.6.25
Describe the bug
When applying a rotation and a distort resize at the same time to a clip using this filter, the resize does not behave as expected as some aspects of resizing use local coordinate reference, while others use global.
This unexpected behaviour stays the same in preview and render.
It also stays the same if you split rotation and Size modification in 2 different superimposed instances of the filter.
Steps To Reproduce
Example : you have a vertical 1080x1920 video, you want to superimpose a squished and blurred version as a background to fill the black bars on the size to get a clean 1920x1080 version, but your phone wrongly recorded the video as 1920x1080 horizontal.
- On video track 1 you add your clip
- Apply Size, Position and Rotate filter to the clip in the timeline
- Assign a rotation of 90° to the clip
=> notice the resize handles in the video preview have disappeared as soon as you change the rotation - Assign an X size of 1080 to get a clean vertical video at the center of the frame (Zoom factor correctly calculates to 56.2% and Y size to 608)
- Add a second video track to your project and move it under track 1
- Copy and paste your clip from track 1 with the filter on
- In the filter parameters, switch Size mode to distort
- Change the Y size to 1920 instead of 608 to try to fill the frame
=> notice there is no change (if you hide track 1, you will notice that the video now stretched vertically instead of
horizontally as the reference point for Distort resize is local while the reference point for Fill resize is global) - You can set Y back to 608 and try to set X to 1920 for a check, but behaviour becomes even more erratic as scale is applied only at half of desired resolution.
- You can achieve desired output 1920x1080 by setting X size to 3840, Y size to 608, X position to -960 and Y position to 236, but this has no actual mathematical justification and is very counter-intuitive
Estimated correct behaviour
Size changes of a clip by modificating X and Y properties of a rotated clip should use consistent coordinate reference whichever Size mode is chosen, either always global (relative to video frame) or local (relative to rotated clip virtual frame).
In that case, distorting a 90° rotated clip to fill a 1920x1080 frame should accept either of these two inputs :
-
(local resizing, more versatile for general rotations not in 90° multiples)
Rotation 90
Size mode Distort
PositionX 420
PositionY 236
SizeX 1080
SizeY 1920 -
(global resizing, easier to apply for mod 90° rotations, but very weird for any other rotation)
Rotation 90
Size mode Distort
PositionX 0
PositionY 0
SizeX 1920
SizeY 1080
This raises another issue : when the clip is rotated to a random value not mod 90°, it becomes extremely difficult to estimate by intuition the PositionX and PositionY relative to the top-left pixel of the virtual rotated frame. It would be simpler to estimate it relatively to the rotation center, but this would most likely require to split the filter again to separate rotation from the rest.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Size, Position and Rotate filter and reproduce the 90° rotation with Distort resizing described in the steps. Compare the preview and render behavior, including the differing local and global coordinate references. Done means the filter uses one consistent coordinate reference for rotated clips and the intended behavior is covered by a regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100