[Kdenlive-devel] Color spaces and MLT

[Simon Eugster]

2010/8/31 Dan Dennedy <dan at dennedy.org>:
> On Tue, Aug 31, 2010 at 12:06 PM, Simon Eugster <simon.eu at gmail.com> wrote:
>> 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
>
> meant 3x3 here :-/
>
>>> 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.)
>
> Definitely. Certainly all DV (except DVCPRO-HD), of which I and others
> have large amounts. People record stuff from TV using SD analog
> capture cards and rip DVDs - all of which are SD 601. Then, there is
> files in their personal libraries and from Internet that signal this
> in their metadata.

Okay. That's interesting. Need to get my fingers on such one. DVD rip
shouldn't be too difficult. Gotta examine that ;)

>> Best would be to have 10+ bits per channel ;) But I'd also vote for
>
> more than 8-bits requires a rewrite of basically all image processing
> functions including all of frei0r, but you already know that and the
> effort that will take.

And that the difference in the final result might not even be
recognizeable by the human eye except for extreme situations …

>> correctness.
>
> OK, I agree. That puts it beyond this next release for sure, which
> means I can focus on merging the autoprofile branch for the release.

Glad we're not working for some business with deadlines :)

Simon