[Kdenlive-devel] Color spaces and MLT

[Dan Dennedy]

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.

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

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

-- 
+-DRD-+