I apologize in advance if this is the inappropriate place for this question, and I further apologize if the ultimate cause of this comes down to user error on my part.

My limited understanding of the Rotoscoping effect is that it can be used to apply a keyframed/moving mask on either a video clip or an image clip. My intended result here is to have an admittedly low-quality reflection of a particular image in a character's glasses during a particular sequence.

Since the character moves, I figured my best option would be to have a keyframed Transform of the image so that it sits at an appropriate size to fit roughly over the character's glasses, and moves roughly with them, then use a keyframed Rotoscoping effect to clip the image to the borders of each lens, manually matching the Rotoscoping border to the movements in the video clip.

At the start of the clip, the Monitor preview shows what I would expect - the border of the Rotoscoping effect matches the cut-out portion of the image:



However, as the clip plays out, the border continues to track as I would expect, but the cut-out portion of the image gradually deviates away from the border itself:



Additionally, I believe there may be an underlying bug with regard to how the grab-handles and borders for effects such as Rotoscoping and Transform are drawn when the Monitor has a zoom level applied. For example, when I have the Rotoscoping effect properties selected for my clip, then subsequently zoom in via Monitor -> "Zoom in monitor", the grab-handles and edges seem to be where they should be.

However, when I then click onto the Transform effect properties, then back to the Rotoscoping effect properties, the positions of the grab-handles and borders for the effect move to an entirely different position on the Monitor, as shown here:



If I then zoom out one step by selecting Monitor -> "Zoom out monitor", the grab-handles and borders return to the expected position:



Lastly, if I zoom back in again, the grab-handles and borders remain in the expected position. That is, until I select the properties for another effect, then select the Rotoscoping properties again, after which the grab-handles and borders re-appear at the incorrect location.

While I'm currently running with 200% DPI scaling, both of these issues occur when running Kdenlive with my desktop environment set up to have 1:1 (100%) DPI scaling, so I do not believe that this would be the root cause of either of these issues.

Any assistance is appreciated, even if turns out I'm just doing something massively incorrect.

There's currently an issue with rotoscoping, i reported it, but no news yet. You can possible add a comment to it. https://bugs.kde.org/show_bug.cgi?id=436895

Arkengheist wrote:There's currently an issue with rotoscoping, i reported it, but no news yet. You can possible add a comment to it. https://bugs.kde.org/show_bug.cgi?id=436895

I may have a proper fix for the issue, I'm currently building Kdenlive. If it works, I'll see what I can do to submit a pull request upstream.

It took a bit longer than I'd have liked to get Kdenlive compiling on Windows, but yes, I have submitted a fix for the Rotoscoping issue: https://invent.kde.org/multimedia/kdenl ... quests/221

As an added bonus, any affected project saves are not permanently munged. Once the merge request goes in, they can be re-saved with any Kdenlive binary built with the fix included and the preview will magically pop into alignment with the Bézier outline.

The issue with the Béziers being unaligned when first selecting the Rotoscoping (and, for that matter, Transform) effect when zoomed in on the Monitor view is still there, but since it can be fixed just by zooming out and back in again, I can live with that.

amoogle wrote:It took a bit longer than I'd have liked to get Kdenlive compiling on Windows, but yes, I have submitted a fix for the Rotoscoping issue: https://invent.kde.org/multimedia/kdenl ... quests/221

Arkengheist will love you for that

Wow. That is the sort of use we like at Kdenlive. Reports a bug. Fixes a bug. submits a patch. Awesome