I’m using the newest version of kdenlive (24.08.0 at the time of this post) and tried it in the windows and the linux version and in both programs it is the same situation:
I use a simple wipe as a transition between my video parts for a tabletop battlereport. The wipe method I use is Diagonal Top Left, but I’ve tried several others, all behave the same way.
The thing is, that the checkbox Invert doesn’t do anything. In all tutorial videos and the official help center for kdenlive for wipe is says, that invert changes the direction of the wipe transition. No it does not. Doesn’t matter if I check this box or not, the transition is always the same I can’t change the direction. But for what I want to do in my video I need to.
Is this a known bug, does anyone else noticed that? Could anyone please try and confirm? Am I doing something wrong?
Not sure if it’s actually related (and I always use ‘traditional’ transitions, so it hadn’t occurred to be it might be specific to that) - but for a very long time now (at least 2020 maybe earlier), only a portion of the wipe methods have worked at all for me with the appimage.
The set occasionally changes a little, and the ‘/2’ copies of the working ones appeared a few releases ago - but all the wipes with an icon image work just fine, but the others (which includes Diagonal Top *) at best do some weird interleaved approximation of what they say they should be.
I’ve always assumed it’s missing files, but it’s long been on my “one day someone will fix it” list of things that aren’t pressing for me because I don’t use the wipes that don’t work …
Screenshot is from 24.08.0 appimage. Invert works just fine for the ‘working set’ of wipes but not for the others.
That is indeed strange. First, I can confirm that Invert works only for the Wipe Methods with an icon image; second, using the latest version there is only one instance of each Wipe Method (flatpak and appimage alike).
As far as the “weird interleaved approximation” is concerned I am afraid I don’t understand what you are saying. All of the Wipe Methods work just fine and as expected and do not introduce any artifacts or interleaved lines.
The ‘/2’ copies of the wipe methods are because I’m using the appimage, but also have a (debian) packaged version of kdenlive and its deps installed that I built from git head for experimenting with gyroflow and a few other things that the appimage won’t load from system dirs outside the appimage tree.
I’m ok with that - I consider it a Feature to be able to use ‘system’ luma files I can add there with the appimage - so we can call that bit “my fault, and not a bug”.
The difference between “wipe methods with an icon” and those without, appears to be that the ones with an icon come from ‘luma’ files in <root-dir>/usr/share/kdenlive/lumas/ (so ‘inverting’ them is just interpreting the grey scale in the opposite direction) - while the others appear to be ‘internal’ without any associated file, so I assume they are implemented algorithmically in mlt.
Which might mean there’s a flag not being passed correctly to mlt (anymore?) to ‘invert’ these, or possibly just that this has never worked?
Which also seems to help explain the ‘interleaving’ I’ve been seeing. I’d started to create a screenshot of what I was seeing, just with a simple transition between two contrasting colour clips - then realised this was our old friend the confused coordinate systems …
If the ‘preview resolution’ of the project monitor is set to 1:1, then I see what you see, those ‘internal’ wipes also work as expected (other than ignoring invert).
But since I’m usually editing 4k video - when the monitor is just a widget inside the larger editing window, I’ll often dial that back to 720p or so, since it’s scaled down anyway and makes scrubbing and playback a bit smoother much of the time. And when you do that, the internal wipes appear to get the coordinates for where they should be all wrong and what you see on the project monitor is a bit of a mess.
Which should be enough for you to confirm that now too - but if you can’t, I’ll post a screenshot and we’ll see what else might be contributing to that.
By my count that makes two real bugs with the ‘internal wipe methods’: They ignore invert with traditional compositions. And they don’t scale correctly for preview resolutions. (which I suspect means they could get messy for clips that aren’t the same size as the project resolution too)
AFAIK, there is a general issue with how project monitor resolution settings are used “under the hood”. It appears to mess up other things as well. IIRC, the devs are already looking into this …
There is an issue with the composition.
When you add the composition on staked clips, the workaround is, that you have to switch to Luma, then invert is working.
When you have a mix with a composition, Luma is the default method.
Oh that’s interesting - because using a ‘luma’ instead of ‘wipe’ doesn’t have the coordinate and scaling problem when the preview resolution is not 1:1 too …
Which is doubly surprising since as Bernd noted, that is a known issue with some subset of effects - so the difference between luma and wipe there might be, well, illuminating, and a fix less complicated than I’d suspected it might be
