[Kdenlive-devel] Title Widget / Monitor scene speed

[Dan Dennedy]

On Sun, Aug 22, 2010 at 12:11 PM, Till Theato <root at ttill.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/22/2010 03:55 AM, Dan Dennedy wrote:
>> On Sat, Aug 21, 2010 at 1:01 PM, Dan Dennedy <dan at dennedy.org> wrote:
>>> On Sat, Aug 21, 2010 at 7:30 AM, Till Theato <root at ttill.de> wrote:
>> Starting in January 2011 I have the opportunity to write a research
>> paper (correct term?) for school. I have been thinking about writing a
>>>>
>>>> yes, correct term.
>>>>
>> MLT filter for masking using bezier curves (like masking using a
>> polygon) & and a Kdenlive GUI for it. Combined with your idea this would
>> be very useful.
>>>>
>>>> My concept would make "Set mask" be somewhat generic and take any
>>>> producer. So, for example, the editor would be a QGraphicsScene, and
>>>> Qt can generate SVG Tiny from the drawn shapes via QSvgGenerator paint
>>>> device. That SVG would be fed into the MLT qimage producer that is
>>>> used by the mask-setter. One could also use a file made in another
>
> While this generally sounds like a good idea if have doubts when it
> comes to keyframability. QtSvg as well as MLT would have to support
> animated SVG files. And masks without keyframes aren't quite useful for
> most cases.
> Please correct me if I'm wrong with this.

Dude, I'm just kicking around ideas. Look at how many 2D animation
programs there are for Linux - yeah, like almost none. So, you want to
whip out a 2D vector animation tool as a part of this? OK, maybe
something much simpler than SVG to which you can add animation will
suffice for this purpose.

With that said, SVG Tiny 1.2 has support for animations - declarative
and scripted, but not yet Qt:
http://doc.trolltech.com/4.5/qtsvg.html

>>>> tool - even a video. (Final Cut lets one drag a file from the clip bin
>>>> onto the filter's file widget.)
>>>>
>>>> Other properties on the mask-setter could use image attributes instead
>>>> of a producer - for example, all pixels that fall within a hue range.
>>>> Yes, it might be nice if this selection mechanism were extensible
>>>> entirely through the other filters, but I think that crosses the line
>>>> into the territory of node-editing and my head starts hurting because
>>>> I still have to figure out how to integrate the mask with the motion
>>>> tracking stuff.
>>
>>> Hmm, just playing around with the new Alpha selection effects, and I
>>> should add the option to use the alpha channel. Possibly, I could have
>>> a mask-define, which will snapshot the alpha and optionally clear it,
>>> then allow filters to operate on alpha until a mask-set, then allow
>>> filters that apply to primary image channels until mask-apply, which
>>> will finally composite the filtered image using the alpha channel over
>>> the snapshotted image (in mask-set), and restore the snapshotted
>>> alpha, and clear the mask. For example:
>>
>>> Levels
>>> Mask define
>>>     Alpha shapes
>>> Mask set (from self or file, using alpha or luma)
>>>     3 point balance
>>> Mask apply
>>> Contrast
>
> So in this way a bezier masking filter could also be used, as I would
> have used the alpha channel anyway.

My thought was that your bezier tool would be used at the "Mask set"
stage alongside the existing things I mentioned. So, basically, to use
a vector mask, one does not need "Mask define." In fact if the alpha
channel or luma of the image is already in a usable state, one does
not need a "Mask define" either. Mask define is mainly a branching
mechanism - to allow one to snapshot the image, and apply filters
necessary to "pull" the mask from the image without affecting the
image or its original alpha channel.

> However with everything you wrote I'm not sure if such a filter is
> useful at all. With this SVG mask defining thing definitely not.

I do not understand that.

MLT already supports a mask-like filter that accepts any producer
including SVG-based ones. It is called "Region," which is what JB
added into Kdenlive and ran into problems. I do not want to just fix
its bugs because I see greater usability problems with its current
approach. I definitely think the animatable vector mask is highly
desirable especially if you can draw directly atop the monitor. That
has far greater convenience and usefulness than a standalone vector or
image editor.

However, I am also thinking about other things people need like
"pulling" a key or mask in its absence. "Pulling" means to derive one
by using some image attribute such as a channel, and sometimes that
requires filtering to get the selected channel into the desired state.
This will also feed into a matte for the Composite transition (Mask
set would have an option to convert it into a matte.)

My biggest concern right now about the above proposal is the
usability. It is not obvious using the existing effects UI that you
would need to insert 2 or 3 special Mask effects to tie it all
together. This filter sequence might be fine at the MLT level, but the
UI should provide something richer and more obvious how to use (and I
definitely do not consider a node-editor to be the panacea). Maybe a
tree-enhancement to the existing effect list will work. A "Pull mask"
filter would have child filters used to prepare the channel of
interest (alpha, luma, potentially others), and a "Mask" filter would
have as children the filters to apply using the mask. Alternatively, a
single Mask filter could have two children. One child would be the
parent of the filters for pulling the key (if needed). The other child
would be the parent of the filters that are used with the mask.

>>
>>>>>>
>>>>>> Just some thoughts.
>>>>>>
>>>>>>> I guess what you mean is that e.g. moving objects has a delay of around 0.2 s?
>>>>>>>
>>
>> For me the delay is much longer 0.2 s. Maybe around 1s.
>>>>
>>>> I seem to recall some interesting blog posts on the Nokia Qt site
>>>> about QGraphicsScene performance.
>
> Could not find anything that results in a noticeable improvement, but
> while testing I figured out that the speed depends on the size. Not the
> size of the scene but of the view. So the smaller the monitor, the
> better/faster editing geometries works.
> I still have no idea what causes this behavior.
>
> regards ttill
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxxdnUACgkQzwEyz7QP6nStkACg0MLH0qmSLERHDlqpcHo3LHEh
> q4UAoKVo0THEf/9jQgwAlAPn2Yl6guzN
> =slxM
> -----END PGP SIGNATURE-----
>

-- 
+-DRD-+