Bug 377191 - Chroma key variance not working
Summary: Chroma key variance not working
Status: RESOLVED FIXED
Alias: None
Product: kdenlive
Classification: Applications
Component: Effects & Transitions (show other bugs)
Version: Appimage - Refactoring
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Vincent PINON
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-04 07:15 UTC by Alexander van der Merwe
Modified: 2021-03-17 06:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
fritzibaby: Brainstorm+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander van der Merwe 2017-03-04 07:15:46 UTC
At least in the last few versions of kdenlive, the variance in the chroma key effect isn't working for me.

I finally got round to compiling kdenlive to try and find the issue, and found that in the melt module filter_chroma.c the 

mlt_properties_get_double( MLT_FILTER_PROPERTIES( this ), "variance" )

always returns 0.

So, no matter what I set the variance too in the gui, it only matches the precise pixel color.

For me the issue is resolved when changing kdenlive chroma.xml parameter type from "constant" to "double".
Comment 1 Alexander van der Merwe 2017-03-04 13:36:53 UTC
After removing my debug outs, I'm now unable to get it working again. Seems like the parameter type change unfortunately isn't the solution.
Comment 2 Wegwerf 2017-03-13 19:46:54 UTC
Erm, since this is a double ... that raises the question: which locale do you run Kdenlive in, and which locale is signalled in the Kdenlive project file? Please check the root element in the Kdenlive project.
Comment 3 Alexander van der Merwe 2017-03-13 20:42:04 UTC
I started to suspect the locale might be wrong. I assume kdenlive will use the system locale? I'm using kde as desktop manager, with en_ZA.UTF-8 locale. But I've tried both en_US.UTF-8 and en_CA.utf-8.

But there is likely a global issue with my setup, since I've noticed the frei0r effects are also not responding when I change the parameters in the gui.

Also, in my last build, I was able to get the chroma working again, by changing the factor to 1 (from 1000), and then dividing by 1000 in the filter_chroma.c file. Perhaps this is some comma vs dot decimal separator issue, I don't know.

Building kdenlive with my build script also takes very long on my machine, so it takes quite some time to debug.
Comment 4 Wegwerf 2017-03-13 21:13:29 UTC
Actually, MLT uses the locale indicated in the Kdenlive project file; which is badically an MLT XML file anyway. The UI uses the system locale or the locale set when starting Kdenlive; but you can switch at least the UI language. I suspect a locale issue of some form, but this seems to be triggered by something in the South African variant; with my de_DE locale, the decimal separator is also different, but projects with floating point properties work correctly.
Comment 5 Alexander van der Merwe 2017-03-14 08:51:23 UTC
I've gone through my kdenlive project file, but I don't see any locale. Can you give me a valid example of a locale value in the kdenlive project file please?
Comment 6 Wegwerf 2017-03-14 12:41:19 UTC
At the top of any Kdenlive project file, you'll see:

<mlt ... LC_NUMERIC="...">

That is instructing MLT which numeric locale to use.
Comment 7 Alexander van der Merwe 2017-03-14 13:17:12 UTC
Ok, mine was LC_NUMERIC="C", and changing it to "en_US.UTF-8" worked!

All the plugins now respond like they should with an unmodified build of kdenlive.

Thank you very much, I really appreciate it.

For me the issue is resolved, but, I have this issue with the package versions of kdenlive in both Debian and Manjaro. New users will assume all the effects are broken.

Is this something that works for other people out of the box? To me it looks like some patch will have to be done.
Comment 8 Wegwerf 2017-03-14 13:38:47 UTC
I'm moving this to unconfirmed for the moment; we need to triage later whether this is a downstream issue for Debian and manjaro.
Comment 9 emohr 2018-12-28 12:27:35 UTC
I think this is a general Kdenlive/MLT problem about the character set. It pops up in many combinations. See here Bug 377010 and here Bug 375710. And under Windows with ascii as well.
Comment 10 Julius Künzel 2021-03-02 18:25:39 UTC
There was a effect cleanup for version 20.12 and the comma/point issue is fixed since 20.08. Can you please check whether this is still relevant?
Comment 11 Bug Janitor Service 2021-03-17 04:33:33 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 12 Alexander van der Merwe 2021-03-17 06:10:08 UTC
I confirm. This issue can marked as resolved. 

Tested on two machines with version 20.12 with new projects. Working 100%.

Thanks.