[Kdenlive-devel] Color spaces and MLT

[Dan Dennedy]

On Thu, Jul 22, 2010 at 12:09 PM, Simon Eugster <simon.eu at gmail.com> wrote:
> 2010/7/21 Dan Dennedy <dan at dennedy.org>:
>> On Wed, Jul 21, 2010 at 12:16 PM, Simon Eugster <simon.eu at gmail.com> wrote:
>>> 2010/7/21 Dan Dennedy <dan at dennedy.org>:
>>>> On Wed, Jul 21, 2010 at 10:51 AM, Simon Eugster <simon.eu at 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.

-- 
+-DRD-+