[Kdenlive-devel] Color spaces and MLT

[Simon Eugster]

2010/8/31 Dan Dennedy <dan at dennedy.org>:
> 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

With the difference that no information gets lost due to rounding to
{0,...,255}.
As Luma is actually defined by RGB values (and designed for RGB), I
cannot see another way than going the kind-of «via RGB» way either.
But isn't this accurate anyway (except for the fact that after the
transformation you again have to round to integers)? Because the
values for 601/709 Luma are exact (by definition).

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

Are there even digital videos using 601? (I really don't know the
current state.)
Best would be to have 10+ bits per channel ;) But I'd also vote for
correctness.

Simon

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