[Kdenlive-devel] Color correction tools: How and where to implement them?

[Dan Dennedy]

On Wed, Jul 14, 2010 at 9:00 AM, Simon Eugster <simon.eu at gmail.com> wrote:
> I have added a Vectorscope to kdenlive now.
> Re-using it in a different project would require only few changes
> given that the other project works with Qt as well, it would mainly
> mean copying the widget and adjusting some values.
> I will look into other color displays now if time allows it (exams in 3 weeks).

great!

> 2010/7/11 Dan Dennedy <dan at dennedy.org>:
>> On Fri, Jul 9, 2010 at 12:29 PM, Simon A. Eugster <simon.eu at gmail.com> wrote:
>>> What still needs to be improved:
>>> * Curves is not really useful at the moment because of the
>>>   chosen interpolation method. For example, this curve is
>>>   impossible for now:
>>>   http://granjow.net/uploads/kdenlive/gimp-curves.png
>>>   Also it is limited to only 3 points, which is not enough
>>>   for earnest color correction.
>>
>> More than likely it was useful to the person who wrote it.
>
> Should be improved nevertheless :)
>
>>> * 3-Way color correction works basically quite well,
>>>   but the usability is terrible.
>>>   If you want to change the blacks, you have to rise the black
>>>   value to see colors in the color picker, and at the end make
>>>   it nearly black again. Would be much better to just chose a
>>>   color and not having to worry about black.
>>>   Also is it not very convenient not to have a live preview.
>>
>> All Kdenlive effects have live preview. So, a simple enhancement to
>> toggle that would help.
>
> Well, there is live preview as soon as the color has changed in the
> widget. But this is only the case when the color picker has been
> closed already. There should be a built-in color picker.

Yeah, like I suggested for white balance.

>>> * White balance: You cannot click into a monitor to pick a
>>>   neutral color from there.
>>
>> Yeah, why is that? Is that due to the Qt dialog mode? It would be nice
>> to have the "eye dropper" directly in the effects panel instead of
>> having to open the dialog.
>>
>>>   You should also be able to change the color temperature
>>>   as this also belongs to white balance.
>>
>> Internally, the color selection sets the temperature, and I feel most
>> people should use it by interactively selecting the color to be
>> neutral. I can expose temperature as a parameter, but then I  need a
>> way to pass invalid color and temperature values to prevent one
>> parameter from clobbering the other. Otherwise, I will need to add
>> another parameter to let one choose the defining parameter.
>
> I'm pretty sure it is not the color temperature. The white balance
> here changes to magenta for low values, and to green for high values.
> It should rather be blue for low temperature, orange for high
> temperatures.

I think you are referring to the green tint parameter, which appears
as a sliding widget and is different that temperature. I do not really
know color correction. This filter is based on code I had forked from
digikam a few years ago first for Kino, then frei0r. On each
iteration, it went through some simplification, but this combination
of green tint alongside temperature (via color selection) comes from
its digikam lineage. If you say it is valuable to directly expose
temperature as a parameter, then I will make that change. Then, is it
also useful to have the temperature presets for the common different
types of lights?

>> parade and vectorscope are available in frei0r, but they do not make
>> sense as general video effects. They require special integration into
>> Kdenlive monitor, but it is not implemented yet.
>
> Ah, that's why they don't show up in the effect list anymore. They
> used to be there some months ago :)
>
>
>>>>     What is the current status?
>>
>> I do not believe digikam/showfoto's image processing or widget code
>> exists as a library to facilitate reuse. No one has contributed gegl
>> integration into MLT, and I have been working on higher priority
>> tasks. Meanwhile, frei0r integration has already addressed many of
>> these needs. There is no simple and clean integration that exposes all
>> of the capabilities of one these other tools. You can, however, export
>> a series of stills (Kdenlive could make this easier) and process them
>> with the Gimp Animation Plugin or blender and then load the result of
>> that as a clip.
>
> Okay.
>
>>>>     The point is also, I would like to do it interactively. Means, if I
>>>>     e.g. have a levels display[1] I would like to be able to select the
>>>>     lower 25 % of the curve (all dark pixels) and have them highlighted in
>>>>     the kdenlive project monitor. So I guess neither frei0r nor MLT would
>>>>     be suitable for that at the moment? (I don't know MLT yet, and frei0r
>>>>     only partially) Could MLT probably be extended this way, or is this
>>>>     not intended?
>>
>> The frei0r filters that apply need to be enhanced to support that, or
>> the way frei0r is integrated into MLT could be enhanced to support
>> that for all filters (currently, the MLT frei0r module acts as a
>> simple bridge between MLT and frei0r). At that point you have only
>> addressed the image processing pipeline and not any UI. Any UI change
>> would need to be done in Kdenlive as that does not exist in MLT or
>> frei0r.
>
> At the moment the second option sounds quite good to me. This would
> not require applying a frei0r effect (e.g. for the vectorscope I wrote
> for kdenlive) to a clip to get the highlighting, if I understand
> correctly.

This part of the conversation confuses me. It did so from the
beginning. In my initial response I thought you were referring to a
split screen preview. What exactly do you mean by "highlighted in the
monitor?" Does that mean you just want to apply the filter only across
some fancy way to select pixels (i.e. by X, Y or Z), or do you to make
those pixels "stand out" for feedback purposes only?
In the case of HSV value ranges, then the mlt frei0r filter does not
really have a way to isolate those to only filter them, and I am not
sure the best way is to enhance that mlt filter to specifically do
just that. Perhaps this really would fall under the topic of filter
masking (aka region) where the value range of an image defines the
mask.

-- 
+-DRD-+