[Kdenlive-devel] Color spaces and MLT

[Dan Dennedy]

On Tue, Aug 31, 2010 at 10:54 AM, Simon Eugster <simon.eu at gmail.com> wrote:
> 2010/8/14 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).
>>>
>>> Basically I just wanted to show you this because it is interesting.
>>> But in the long term one of our goals should also be to avoid either
>>> conversion to other color spaces or the loss of information caused by
>>> the conversion.
>>
>> I just pushed some changes in mlt to fix this problem when using
>> libswscale - at least on my version. It adds some flags, but some
>> flags are needed for some color/pixfmts and different flags for
>> others. Use an incorrect flag, and the results are totally disastrous!
>> So, I am little worried that it might be version-sensitive. It would
>> be good if you and others could update mlt from git, test it, and see
>> if this problem resolves for you without introducing disaster.
>
> By the way, I changed the Histogram and the Waveform to use Rec. 709
> by default (can be changed in the context menu). They look much
> smoother now.  :)

I have partial support for Rec 709 is a local branch. I would say it
is about 35% done. Next up is to normalize producers of differing
YCbCr colorspace (luma transfer) to the project setting, For example,
I need to be able to convert between Rec 601 and 709. I was wondering
about how to do that without the obvious of going to RGB and back
using respective coefficients, which is obviously expensive. Poynton
claims it is an unavoidable 9x9 matrix multiplication, which suggests
the near equivalent of to-and-from RGB. That is, unavoidable unless
you choose to avoid it, which many tools do. For example, I could just
make all conversions use Rec 709 coefficients in a 709-based project
regardless of their source luma transfer.

What do you think? I am leaning towards correctness since I know
parallel processing is right around the corner. However, I will likely
just use swscale-based conversion to-and-from RGB to leverage its
vectorized implementations.

P.S. I do not expect to get this done in time for the release.

-- 
+-DRD-+