2010/8/31 Dan Dennedy <d...@dennedy.org>: > On Tue, Aug 31, 2010 at 12:06 PM, Simon Eugster <simon...@gmail.com> wrote: >> 2010/8/31 Dan Dennedy <d...@dennedy.org>: >>> On Tue, Aug 31, 2010 at 10:54 AM, Simon Eugster <simon...@gmail.com> wrote: >>>> 2010/8/14 Dan Dennedy <d...@dennedy.org>: >>>>> On Wed, Jul 21, 2010 at 10:51 AM, Simon Eugster <simon...@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 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
