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

[Dan Dennedy]

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. 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.

-- 
+-DRD-+