Bug 473160

Summary:	bluescreen0r can't be used as a masked effect
Product:	[Applications] kdenlive	Reporter:	past.hat7551
Component:	Video Effects & Transitions	Assignee:	Jean-Baptiste Mardelle <jb>
Status:	REPORTED ---
Severity:	normal	CC:	berndmj, luzpaz
Priority:	NOR
Version First Reported In:	23.04.3
Target Milestone:	---
Platform:	Other
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description past.hat7551 2023-08-08 16:29:56 UTC

SUMMARY
***

I'd like to use bluescreen0r in combination with the Rotoscoping mask effect. Basically, I want to be able to specify a small area where the bluescreen0r should alpha out pixels, which can be useful when using material that wasn't green-screened to remove pixels of a given color, but also only in a given region.

So the effect chain is quite simple:

1. Rotoscoping (mask)
2. bluescreen0r
3. Mask Apply

However, this doesn't seem to work correctly. In this setup, the bluescreen0r plugin doesn't do anything at all. I suspect that this is because bluescreen0r is also classified as a masked effect, even though it's just a filter in frei0r.

As a workaround, I have been using "Key Spill Mop Up" in place of bluescreen0r to change the target pixels to `#00ff00` (since Key Spill Mop Up doesn't support setting an alpha channel, though perhaps that should be a separate issue). However, this can leave green "bleed" on some areas unless the tolerance of bluescreen0r is set to be sufficiently high, which may also have other unwanted side-effects.

STEPS TO REPRODUCE
1. Add Rotorscoping effect
2. Add bluescreen0r effect
3. Add Mask Apply effect

OBSERVED RESULT
Nothing

EXPECTED RESULT
The bluescreen0r effect should be active on pixels in the given rotorscoped region.

Comment 1 past.hat7551 2023-08-08 16:35:15 UTC

Also, I did a bit of investigating regarding the Key Spill Mop Up plugin, since an acceptable workaround would be to use that plugin but to set the target pixels to be transparent. I'm not 100% sure where kdenlive gets this plugin from, but if it's from frei0r, then we're out of luck because the target pixel (see https://github.com/dyne/frei0r/blob/49f759d9e153a4e2850127e368f7aa6f40d59aaf/src/filter/keyspillm0pup/keyspillm0pup.c#L664) is defined as a f0r_param_color (see https://github.com/dyne/frei0r/blob/49f759d9e153a4e2850127e368f7aa6f40d59aaf/include/frei0r.h#L416-L421), which is a 3-component RGB `struct` with no alpha channel.

Adding an alpha component to this struct, which is used quite widely in frei0r, would probably be an unwelcome addition and at the very least a big change that would require thorough review. So it would be nicer if kdenlive would allow effects such as bluescreen0r to function with the rotorscoped mask effect. :)

Comment 2 luzpaz 2026-01-28 19:32:25 UTC

(In reply to past.hat7551 from comment #0)
> OBSERVED RESULT
> Nothing
Can you please check if this is still the case for v25.12.1? Thank you.

Comment 3 past.hat7551 2026-01-29 09:12:13 UTC

(In reply to luzpaz from comment #2)
> (In reply to past.hat7551 from comment #0)
> > OBSERVED RESULT
> > Nothing
> Can you please check if this is still the case for v25.12.1? Thank you.

Sorry, I don't use kdenlive anymore, so you can close this issue if you feel it's been addressed.

Comment 4 Bernd 2026-01-29 19:31:13 UTC

(In reply to luzpaz from comment #2)
> (In reply to past.hat7551 from comment #0)
> > OBSERVED RESULT
> > Nothing
> Can you please check if this is still the case for v25.12.1? Thank you.

It's still there: Any effect adding an alpha channel or working with it do not work when inside a Rotoscope (Mask) - Mask (Apply) sandwich.

Not sure whether this is by design. Needs JBM to look into.