-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Sun, Aug 22, 2010 at 12:11 PM, Till Theato <r...@ttill.de> wrote: > On 08/22/2010 03:55 AM, Dan Dennedy wrote: >>>> On Sat, Aug 21, 2010 at 1:01 PM, Dan Dennedy <d...@dennedy.org> wrote: >>>>> On Sat, Aug 21, 2010 at 7:30 AM, Till Theato <r...@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----- ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel