Bug 436895

Summary: Rotoscoping not working right
Product: [Applications] kdenlive Reporter: Roxane <roxane.petrot>
Component: Effects & TransitionsAssignee: Vincent PINON <vpinon>
Status: RESOLVED FIXED    
Severity: normal CC: bgaidioz, fritzibaby, julius.kuenzel, snd.noise, stefano.droghetti
Priority: NOR    
Version: 21.04.1   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed In: 21.04.3
Sentry Crash Report:
Attachments: Rotoscope_Alpha_show_black.png
Rotoscope_Shape.webm

Description Roxane 2021-05-10 20:44:44 UTC
SUMMARY
Rotoscoping isn't working well, the hidden box doesn't match the red box.
https://youtu.be/6xK3oX163vE

STEPS TO REPRODUCE
1. make a box with rotoscoping and move it with multiple keyframes (see video)
2. 
3. 

OBSERVED RESULT
https://youtu.be/6xK3oX163vE

EXPECTED RESULT
everything matches

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Appimage
Comment 1 Benjamin Gaidioz 2021-05-20 19:39:17 UTC
Hello,

A couple of days ago I've stumbled on a similar problem with 21.04.0 too. I could track my problem to a the detail I describe below. Hope this helps.

Literally I was implementing the popular laser saber effect. Every once in a while I would play the video to see how it looked. At some point, the interpolation of the masking behaved as if only keyframes N and N+100 had been entered: totally ignoring in between ones, although the spline path was correct.

I opened the .kdenlive XML project file see if I could recover something:

In the faulty rotoscoping section, I noticed the JSON object representing the multiple keyframes of the spline had keys ordered _alphabetically_ (keyframes "100" to "150" would show right after "10" and before "11") and not numerically.

By manually reordering these keys in numeric order, the masking got to follow the spline again. I'm still editing the video and periodically I go fix the file, it still happens, my fix must be not totally perfect.

Regardless if this is the exact root cause of the buggy rendering, what triggered this state? No idea so far. I haven't tried to reproduce this separately, but I have kept a copy of the wrong file.
Comment 2 emohr 2021-05-24 08:12:03 UTC
I can confirm the behavior from Roxana and the keyframe issue numbering from Benjamin (Tested with master).
Comment 3 emohr 2021-05-24 08:24:33 UTC
Created attachment 138733 [details]
Rotoscope_Alpha_show_black.png

Another point is that the alpha channel of a PNG file is not shown transparent with Rotoscope applied.
Comment 4 Roxane 2021-06-01 07:57:04 UTC
(In reply to emohr from comment #3)
> Created attachment 138733 [details]
> Rotoscope_Alpha_show_black.png
> 
> Another point is that the alpha channel of a PNG file is not shown
> transparent with Rotoscope applied.

for this, the solution is to change "write on clear" to "minimum"
Comment 5 emohr 2021-06-01 17:44:06 UTC
Created attachment 138925 [details]
Rotoscope_Shape.webm

Thank you Roxane for the hint. But still the mask is not following the rotoscope shape.
Comment 6 stefano.droghetti 2021-06-06 18:00:15 UTC
Confirm. Still not working on 20.04.1
Comment 7 farid 2021-06-10 21:11:52 UTC
Patch submitted: https://invent.kde.org/multimedia/kdenlive/-/merge_requests/221
Comment 8 Roxane 2021-06-11 07:56:05 UTC
(In reply to farid from comment #7)
> Patch submitted:
> https://invent.kde.org/multimedia/kdenlive/-/merge_requests/221

this is great, thank you!