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