On Sat, Jul 31, 2010 at 5:27 AM, Simon A. Eugster <simon...@gmail.com> wrote: > On 22.07.2010 22:57, Dan Dennedy wrote: >> On Thu, Jul 22, 2010 at 12:09 PM, Simon Eugster<simon...@gmail.com> wrote: >>> 2010/7/21 Dan Dennedy<d...@dennedy.org>: >>>> On Wed, Jul 21, 2010 at 12:16 PM, Simon Eugster<simon...@gmail.com> wrote: >>>>> 2010/7/21 Dan Dennedy<d...@dennedy.org>: >>>>>> On Wed, Jul 21, 2010 at 10:51 AM, Simon Eugster<simon...@gmail.com> >>>>>> wrote: >>>>>>> Dear friends, >>>>>>> >>>>>>> I've just added an RGB parade to kdenlive. While testing I found >>>>>>> something interesting: Although I'm painting on a rect with height 256 >>>>>>> (as atm we're dealing with 8 bits per channel only) and scaling the >>>>>>> parade afterwards to the target height, I got kind of scanlines. >>>>>>> Compare these two images: >>>>>>> http://granjow.net/uploads/kdenlive/kdenlive-mlt-rgbparade-noeffect.png >>>>>>> http://granjow.net/uploads/kdenlive/kdenlive-mlt-rgbparade-witheffect.png >>>>>>> With the MLT effect there are scanlines, without it there are none. >>>>>>> >>>>>>> This is quite interesting, as this visualizes how color information >>>>>>> gets lost when converting between different color spaces (according to >>>>>>> [1], MLT is using YUV422, the input image is RGB). >>>>>> >>>>>> It does not operate exclusively in YUV422. The color/image-format >>>>>> conversion implementation depends on your build and your version of >>>>>> libswscale (>= 0.7.2) whether MLT uses libswscale or inbuilt routines. >>>>>> Maybe the problem is in the composite transition. >>>>> >>>>> libswscale is at 0..6 here in debian sid. >>>> >>>> I do not believe that is correct. Maybe you are looking at a package >>>> version. What does 'ffmpeg -version' show as the libswscale version? >>> >>> Something different. >>> libswscale 0.11. 0 / 0.11. 0 >>> >> >> So your MLT should be using libswscale for colorspace and image format >> conversion as well as scaling. This is generally a good thing. > > By the way, what happens when rendering to a file? If the input is in RGB, > and no filters/effects operating in YUV only are put on top of it, will it > remain RGB until being written to the output file?
Same thing happens regardless of output - it all depends. BTW, sdl_preview as used by kdenlive is both RGB and YUV. I can not be any more specific unless you are. -- +-DRD-+ ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
