Hello, I am trying to create Super Mario 64 Machimania using Kdenlive. If you don’t know what SM64 Machimania is, it’s basically where you use a green screen mod for sm64 and green screen mario doing funny things in a video editor. The program I am using to generate mario and the green screen renders a pixel-perfect contrast between mario and the green screen background, so theoretically the green screen should be perfect. I also checked OBS, it doesn’t do any weird processing either. But for some reason, when I import any media, whether it be a screenshot or video recording, Kdenlive automatically compresses it or anti-aliases it or upscales it bad or something, because the green background is now blurred with marios edge pixels, creating a green halo around mario when applying the chroma effect. For example, in these images, you can see that the screenshot in libresprite (right) of mario is pixel-perfect, while the one in Kdenlive (left) is blurred.
Kdenlive: 25.12.2
Kdenlive
MLT: 7.32.0
FFmpeg
KDE Frameworks: 6.22.0
Qt: Using 6.10.1 and built against 6.10.1
Nobara Linux 43 (KDE Plasma Desktop Edition) (Wayland)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.19.2-200.nobara.fc43.x86_64
Here is a screenshot of Mario. You will notice that if you open this in a pixel-perfect image viewer (such as Libresprite) that Mario’s edge pixels do not blend with the Green 255 background. However, if you import this into kdenlive and zoom in on the image, you will notice that Mario’s edge pixels get blended with the green background, just like in my original screenshot. If you then apply the chroma effect to the image, you can see the green halo surrounding Mario as a result of the blended edge pixels.
I can’t say for sure what’s actually going on here, because as I noted in another post recently, I haven’t done a lot of work with chroma-keying - but a couple of things stand out which might help you get to the bottom of it.
This statement is suspicious and could be misleading you (emphasis mine):
Because as soon as you “zoom in”, there’s a pretty good chance what you’re looking at included interpolated pixels that weren’t there in the original - which depending on the interpolation used, may (and by default probably does) include some combination of the neighbouring pixels.
Which may or may not also be what’s going in when you zoom in with PSP? I’m not seeing the same sort of edge bleeding at 8x magnification in gimp.
If you really want to rule that out, the safest bet might be to create a larger still image, that matches the project size, padding the extra area with the same green. There’s lots of Really Wanting Things To Be The Same Size that goes on under the hood, even with that option enabled.
But if the image your browser downloaded/saved for you was indeed its own rescaled version instead of the actual original source clip (and not that PSP interpolated zoom explains the bleeding you see), then yeah that would also explain your test results.
And doing an extremely quick test of that - importing the source png from above, creating a project which is the size of that image, placing that image in the timeline over a simple red colour clip background and then adding the chroma-key ‘advanced’ effect, it seems to perfectly key away all of the green.
If I then zoom in on the monitor (or blow it up to full screen), I see (as expected) an image rescaled and interpolated with something other than nearest-neighbour, which gently bleeds the blue into the red background, but no sign of any remaining green.
So my first guess is that you’ve got unintended rescaling going on somewhere in the pipeline and it is to blame for the spill - so you probably either need to fix that, or try to despill it.
Just as I suspected, it seems the KDE CDN compressed/processed the image when it was uploaded. Here is a screenshot in libresprite of the original image I uploaded, and the image after I downloaded it from the CDN:
You are correct, when I switch the project to be the same size as the image it does not seem to upsale it at least not that bad. However for the content I am making the size of the project size sort of has to be 1080p, and it does have the halo effect at that project size.
The left instance of kdenlive is the size of the image, the other is 1080p:
I don’t think it did. If I “save Image as” I get a clean 422x602 image with sharp edges and no interpolation. But if you try to “view it” in your browser it upscales that for some reason.
if by “not that bad” you mean “not at all”. It cleanly removes all the green background.
However for the content I am making the size of the project size sort of has to be 1080p
It doesn’t matter what size you want it to be, you can make it any size you please. The song remains the same. If your source material matches your project size, it won’t be rescaled, if it doesn’t, it will. QED.
That’s not “weird processing”, that’s Making Things The Size You Asked For. If you’d have given us a clean 1080 image, I’d have got the same result doing the same test with it, but you didn’t so I just tested it with what you gave us.
