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

[Simon Eugster]

2010/7/22 Dan Dennedy <dan at dennedy.org>:
> On Thu, Jul 22, 2010 at 7:50 AM, Simon Eugster <simon.eu at gmail.com> wrote:
>> 2010/7/22 jb <jb at kdenlive.org>:
>>> On Wednesday 21 July 2010 15.49:47 Simon Eugster wrote:
>>>
>>>> What does not work yet is updating the scopes when e.g. adjusting
>>>> effect parameters. For example color temperature. There are very
>>>> interesting effects on the vectorscope when changing the temperature
>>>> btw :)
>>>> If someone could give me a hint which signal to use, I've been
>>>> searching for this event for half an hour or so but couldn't find one
>>>> yet.
>>>
>>> After thinking a bit about it, I just added a new signal to renderer.cpp,
>>> called:
>>>
>>> void frameUpdated(int)
>>>
>>> That signal is emitted every time the frame is updated without a seek event.
>>> Currently, the frame is updated not only when an effect is added, but also
>>> every time the monitor needs a refresh (for example when another window moves
>>> above it), so you will get a few extra calls, but that's also an occasion to
>>> track unneeded refreshes :)
>>
>> Thank you! Works now.
>>
>> Something else:
>> When activating realtime and auto-refresh in one of the scopes, the
>> speed when playing clips changes. I'm not sure, but perhaps this is
>> because of:
>>> m_activeRender->extractFrame(m_activeRender->seekFramePosition())
>> which I use for retrieving the current frame (perhaps there's a better
>> way?). Any idea? (I'd disable realtime for the release otherwise.)
>>
>
> Yeah, this is bad. First of all, the mlt consumer-frame-show event
> supplies a frame reference, which gets lost in the Kdenlive
> rendererPosition signal that its frame-show event handler emits. It
> appears that kdenlive signal was intended purely for position-oriented
> thing like updating a timecode label, but now you could say it is
> being abused. Interestingly, when I trace your logic for updating the
> vectorscope, that frame position is not used. Instead it is a trigger
> to get the position of the mlt producer for the active monitor. Using
> the producer's position is the second bad thing.

I just tried to change it. When pressing play, it kept on jumping back
in the monitor. The current version may work better because I'm
getting the most up-to-date position and not one that may have been
delayed for one or two seconds (for whatever reason).

> It is not the same
> position as that in the monitor (the mlt consumer). The producer may
> read ahead for some parallelism. While we currently keep this low for
> better latency handling, it is going to go up a little when additional
> parallelism is introduced. The third bad thing is that to get a frame
> object, it asks the producer to seek backwards when it may have
> already moved ahead! This might not be too bad right now due to some
> frame caching in MLT, but again, with increased parallelism coming, it
> may become worse. In summary, the scopes should be using the frame
> object from the mlt frame-show event and avoid jumping through so many
> hoops.

I see ... So if we'd pass the frame directly, we would a) gain
performance and b) be able to make use of the «original» (i.e. last
used) color space?

Simon