|Anonymous | Login | Signup for a new account||2014-03-12 02:27 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000320||Kdenlive||Effects||public||2008-11-08 20:12||2008-11-12 22:22|
|Product Version||Recent git|
|Target Version||0.7.0||Fixed in Version||0.7.0|
|Summary||0000320: Chroma Hold creates B&W of the Color Key color, not of everything else|
|Description||When I select a colour with the Chroma Hold and adjust the variance downward, the colour that I've selected is the first thing that starts to become black-and-white. These screenshots should help to explain it:|
http://picpaste.com/chroma_OFF.png [^] and
The "chroma_OFF" has screen artifacts from KSnapshot but i think you get the idea.
As I adjust the variance downward the blue from the jacket becomes the first colour to disappear, then the skin tones, and eventually the reds are the last to become black-and-white. It seems to me this is the opposite of what should happen -- I thought everything BUT my Color Key would become Black and White.
|Additional Information||SVN built 2008 11 08|
|Tags||No tags attached.|
|Attached Files|| chroma_ON.png [^] (291,461 bytes) 2008-11-08 20:12|
chroma_OFF.png [^] (348,031 bytes) 2008-11-08 20:13
|With this shot all of the variance above (it appears) about 40 have no effect, yet the slider can go upwards quite a lot. The slider should maybe be adjusted to only allow to move between 0 and 50 maybe? This may need some testing, but if most of the work for this effect wil have a lowe variance (0-10 range) there isn't a need for a high number there, I think.|
Acknowleding. See also this mail from jb:
|This is legit. The problem is that the hex for the key property starts with 'ff' for the alpha. This property does not take an alpha value, but if it did, it would be the last characters of the color spec.|
|So, what needs to be done to fix it? Is this an kdenlive or mlt issue?|
|This is a kdenlive issue. In MLT, all color values take the hex form 0xRRGGBBAA, but kdenlive is supplying 0xAARRGGBB|
|Thanks. Final followup question (I hope) is this just for this particular module, or something general for all modules that kdenlive tries to call in mlt? (Rephrase: Is this a general problem in kdenlive or specific to the interaction with this particular module?)|
|I think this is specific to chroma hold. Creation of color clips requires a color value in the same form, and it works ok.|
> is this just for this particular module, or something general
> for all modules that kdenlive tries to call in mlt?
Any chance this is the same reason Bluescreen doesn't work, because its calling the wrong colour hex value?
|jb: I am acknowleding this for 0.7.0 in the hope that it is a trivial one liner fix. Please ignore it, if not.|
Fix commited by jb in svn rev. 2697, tested: works. Closing issue.
I think this should also fix issues with blue screen, but I have not been able to test.
|2008-11-08 20:12||el_jefe||New Issue|
|2008-11-08 20:12||el_jefe||File Added: chroma_ON.png|
|2008-11-08 20:13||el_jefe||File Added: chroma_OFF.png|
|2008-11-08 20:15||el_jefe||Note Added: 0000912|
|2008-11-08 20:21||madsdyd||Note Added: 0000913|
|2008-11-08 20:21||madsdyd||Status||new => acknowledged|
|2008-11-09 01:05||ddennedy||Note Added: 0000926|
|2008-11-09 20:22||madsdyd||Note Added: 0000984|
|2008-11-09 20:36||ddennedy||Note Added: 0000986|
|2008-11-09 20:57||madsdyd||Note Added: 0000989|
|2008-11-10 03:25||ddennedy||Note Added: 0001010|
|2008-11-10 13:59||el_jefe||Note Added: 0001032|
|2008-11-12 11:41||madsdyd||Note Added: 0001156|
|2008-11-12 11:41||madsdyd||Target Version||=> 0.7.0|
|2008-11-12 12:51||madsdyd||Note Added: 0001159|
|2008-11-12 12:51||madsdyd||Status||acknowledged => closed|
|2008-11-12 12:51||madsdyd||Resolution||open => fixed|
|2008-11-12 12:51||madsdyd||Fixed in Version||=> Recent git|
|2008-11-12 22:22||madsdyd||Fixed in Version||Recent git => 0.7.0|
|Copyright © 2000 - 2014 MantisBT Team|