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