[Kdenlive-devel] Title Widget / Monitor scene speed

[Till Theato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Sun, Aug 22, 2010 at 12:11 PM, Till Theato <root at ttill.de> wrote:
> 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

No. The ideas I was throwing around were not that well thought than yours :)

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

Thinking about it again me too. Sorry for bugging you with this one.

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

This sounds intuitive and easy to use.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxy4cwACgkQzwEyz7QP6nQu7QCeLBrCNbkNxCp62ky6mvVKrbTK
81MAn0TGFWn4lJ5mB6DJNPGM32171LCw
=Hi+U
-----END PGP SIGNATURE-----