Re: [CinCVS] Deinterlace: temporal field swap patch
It's a re-implementation of ideas that have been done in the free deinterlacers. Although instead of porting the exact algorithms, it just re-implemented one. When I have more time, I'll put a motion-based deinterlacer and my frame-rate converter ( http://jcornet.free.fr/linux/yuvmotionfps.html ) since it's more or less the same algorithm. Cheers, Jerome Andraz Tori wrote: will check it out as soon as possible! thanks. Is your solution based on one of the free deinterlacers or homebrewed ? bye andraz On pon, 2006-02-06 at 23:59 -0500, Jerome Cornet wrote: OK, I worked hard over the weekend, and here's what I came up with: an additional plugin that does a smart BobWeave. The algorithm is fairly simple: Keep each dominant line the same (Top or bottom, depending on the configuration) For the other line, check each pixel: if it is very different from the previous frame, interpolate from the line above and below (bob) if it's similar, keep it (weave) The similarity calculation is a fudgy calculation based on the Pot control on the configuration window In summary, for the static parts of the image you get the full resolution, and for the moving parts you get an interpolated, half vertical resolution block. It's pretty fast, not the best but really better than what's currently in Cinelerra. Also, the plugin interface was getting really crowded with all those additions, so I reworked it completely. I'd appreciate some feedback from whoever's interested (Andraz ? ;-) ) The patch to the current CVS is here: http://jcornet.free.fr/linux/download/cinelerra/deinter.patch.gz The full plugin code is there: http://jcornet.free.fr/linux/download/cinelerra/deinterlace.tgz Let me know what you think, Jerome Andraz Tori wrote: Ok i've commited this. If you have any time in the future, i'd _really_ appreciate if you manage to implement one of the smarter deinterlacers ... Cinelerra is really weak in this regard. And at least we at Cyberpipe would really need some better solution for deinterlacing inside Cinelerra. bye andraž ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Deinterlace: temporal field swap patch
On Wed, 08 Feb 2006 15:50:31 +0100, Jerome Cornet [EMAIL PROTECTED] wrote: It's a re-implementation of ideas that have been done in the free deinterlacers. Although instead of porting the exact algorithms, it just re-implemented one. When I have more time, I'll put a motion-based deinterlacer and my frame-rate converter ( http://jcornet.free.fr/linux/yuvmotionfps.html ) since it's more or less the same algorithm. Have you looked at Zachary Drew's motion estimation(1) for MLT(2) ? 1) Motion estimation http://www.tc.umn.edu/~drew0054/video.html 2) Mutton, Lettuce, Tomato http://mlt.sf.net/ -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] understanding chained tracks
Hi all, currently, I am exploring cinelerra's features (we are at the start of a large editing project). I am somewhat puzzled by the behaviour of chained tracks (is this the right term) when doing compositional work. Maybe someone can confirm if I did grasp the following correctly? My understanding is that I can use this feature in a chain of plugins on a track in order to derive a partially modified version of this track and overlay this on another track. A possible use (I am thinking off at the moment) would be, to blur and tint the image near the border of a mask (where the border of the mask is heavily automated with keyframes). Lets asume, we have the source footage in track A. I can then select and chose a shared track (context menu of the track or change.. in the context menu of a plugin placed alredy in track A). So I can select track B and get the display as if adding another plugin to track A. I can even reorder this track B with other plugins like -- say flip. Everything nice so far. At this point, the contents of track A as processed in the plugin chain up to the point where the track B entry is inserted, appear overlaid in track B, according to the overlay mode of track B (e.g. additive). This ist what I would expect. BUT, at the same moment there is a strange backlash: all plugins as well as the mask of track B gets inserted into the processing chain of track A. (at exactly the point where the track B entry sits) E.g. if I add a color balance to track B and use this to color track B heavily green, track A gets colored the same way. Is this intended behaviour? What is the rationale of such behaviour? OK I can get away by muting track A, but I like to understand the idea behind... Btw: I am still using the heroine 2.0 version of cinelerra (but I plan to try out the newest svn as soon as I get some time) cheers, Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] understanding chained tracks
On Wed, 8 Feb 2006, Andraz Tori wrote: The concept comes from audio... where there are many situations in stereo, where you want to apply the same effects with the same keyframes to both tracks at the same time, without managing keyframes for every track separately. The same could be used for video tracks when you are combining some material in multitrack and want to fix all the material in the same way (apply the same color correction for example...) no matter which track the material is in... But then what happens to the data from the shared track? As far as I can tell, when you use a shared track, it doesn't just apply the same plugins... it also composites one track into the other. I have yet to read a clear description of where the data actually goes, let alone why it's useful. Sharing just the plugins (like, share a track to automatically share all its plugins) would make sense to me. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: understanding chained tracks
On sre, 2006-02-08 at 20:15 +0100, [EMAIL PROTECTED] wrote: I am somewhat puzzled by the behaviour of chained tracks ... Andraz Tori wrote: The concept comes from audio... where there are many situations in stereo, where you want to apply the same effects with the same keyframes to both tracks at the same time, without managing keyframes for every track separately. The same could be used for video tracks when you are combining some material in multitrack and want to fix all the material in the same way (apply the same color correction for example...) no matter which track the material is in... Hi Andra, Ah, I see, this makes perfectly sense. Chained tracks seem to be an advanced feature overloded with several possible uses - sharing a processing chain on different material - deriving and overlaying different versions of the same source footage - accumulating several masks from different tracks - changing the order overlays are output to differ from the order of the tracks further possibilities? cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] understanding chained tracks
On Wed, 8 Feb 2006, Andraz Tori wrote: The same could be used for video tracks when you are combining some material in multitrack and want to fix all the material in the same way (apply the same color correction for example...) no matter which track the material is in... [EMAIL PROTECTED] wrote: But then what happens to the data from the shared track? As far as I can tell, when you use a shared track, it doesn't just apply the same plugins... it also composites one track into the other. I have yet to read a clear description of where the data actually goes, let alone why it's useful. Sharing just the plugins (like, share a track to automatically share all its plugins) would make sense to me. this was one of the points that puzzled me. Because this feature seems to combine several things, i.e sharing the plugins in backwards direction and at the same time sending the output in forward direction from track A to B. This seems a bit limiting, but there are workarounds: - if I am not interested in the plugin and mask sharing, I can mute the source track (track A) and only use the overlaid output on B - if I am not interested in the shared output then I can hide it by using the normal track overlay: lets assume, track A is below and track B is above. If the overlay mode of track B is set to normal or to replace, it will cover and thus hide the redirected output of track A (because it is calculated later and the redirected output is overlaied first, when calculating the data of track A -- did I guess this explanation right?) cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
