Will test, could you give a bit more info on the flags and how the gaps/banding are removed? Can't find it in the commit logs or kdenlive CIA.

You cannot find anything in Kdenlive logs because the change took place in MLT the NLE framework Kdenlive is based on.
Have a look at this commit diff:
http://mltframework.org/gitweb/mlt.git?p=mltframework.org/mlt.git;a=commitdiff;h=797ac52b21273d378f2948dd24a68f08ed211859
And this log in general:
http://mltframework.org/gitweb/mlt.git

Slaps head, duh! It was late when I posted. :-)

Thanks for the links, altough I have no experience of such things, it looks like changes to improve the accuracy of the conversion calculations to reduce rounding errors and a slightly better interpolation.

I guess this is about speed of response on the timeline for playback and particularly when adding effects and transitions versus a 'better' or 'best' conversion to RGB and holding onto more data? A balance between costly calculations in time(depending on CPU/GPU power) versus what might be invisible loss to the eye?

Does Yxxx use less resources than RGB? Obviously RGB playback in the media player on a PC, through an LCD TV screen or projector?

Out of interest why not convert to RGB at import doing a 'best' conversion then go back to Yxxx at encode out (generally) and all the calculations of effects in between, which I guess are done in RGB space, done on best conversion from original Yxxx camera files?

I'd think it very rare for anyone to want to just edit and encode out staying Yxxx, if that's at all possible?. I'd assume a fully fledged NLE would be all about adding effects, colour correction, grading, transitions etc that are all done in RGB space or is it a back and forth from Yxxx to RGB to Yxxx each time an effect is added?

Is there other performace hits with regard to just doing a conversion to RGB at inport?

Sorry for the questions, not meant as argumentative. :-)

Ok, compiled kdenlive from svn and tested with same frame [210].

A lot of combing in kdenlive, is this is just the histogram code or kdenlives Yxxx to RGB conversion?

But good news (I think?) is a far higher unique colour count in Gimp, nearly the same count / colour fidelity as I get from AVISynth doing a full range conversion. But whether the Gimps tool is anything to go by in determining quality of conversion I'm unsure. Also the frame I extracted from kdenlive to test was via the 'Extract Frame' menu item. Does that frame capture method use the same conversion code?

Finally another thought, does kdenlive handle the full range [0 - 255] of Yxxx data in the conversion to RGB and leave the levels alone, passing them through or just 16 - 235 Yxxx expanded to 0 - 255 RGB then squeezed back again?

Dear Yellow,
I assume you are the author of the http://blendervse.wordpress.com/ blog?
I am working on improving color handling in MLT, and its usage of swscale. Thank you for your testing and feedback.

Re: does kdenlive handle the full range [0 - 255] of Yxxx data in the conversion to RGB and leave the levels alone, passing them through or just 16 - 235 Yxxx expanded to 0 - 255 RGB then squeezed back again?

Currently, it is scaling to and from full range RGB. Part of the reason for this is because it wants to accept full range RGB sources like rendered image sequences and digital photos and keep them compliant with ITU Rec 601 (and eventually 709) YCbCr broadcast limits when converted. Another major application of MLT is for video playout server via SDI and ASI at television broadcasters. Also, the color space converter does not know if RGB is full range or not, and depending on filters used, color space of source and output, it might have to do multiple conversions, so the conversions do need to be symmetrical.

Also, you should know that currently all YCbCr conversions are done according to ITU Rec 601, and not yet 709. However, I have been studying this, and I will be adding some things to MLT like new image types that indicate RGB gamut and YCbCr transfer function. Also, some source plugins will be modified to default to one or another based on heuristics like spatial resolution to guess at the correct YCbCr transfer as well as accept an override parameter. Finally, I will also need to add a color space to the profile to choose Rec 601 vs 709. Of course, this will take a little time, but I expect it to be done by end-of-year.

Dan

re blog, Yes, that's me.

Thank you for your time replying. Great news, on the MLT developments and progress.

Dan, regarding kdenlive converting HD sources using BT601 and contrast stretching, you mentioned that hopefully this will be addressed, earliest end of year, cooking the coefficients. Had you considered using a 3D LUT system for the conversions, this could handle 601, 709, linear, sRGB, log.

yCMS is a free colour management system that I currently use with AVISynth. http://forum.doom9.org/showthread.php?t=154719

I already have in a branch near ready for merge and push that adds a colorspace field to the project profile, reads input's colorspace, does colorspace normalization of inputs (e.g. 601<->709), and sets colorspace on output (not many encoders in ffmpeg utilize this). The "full range" luma option (not scaling) in my branch is half-baked. In swscale, it works going to RGB but not from, but also my version is a few months old.

I generally do like to have more than one implementation of fundamental services like this; however, I am low on bandwidth. I may look into that. I already heard about ColorMatrix as well. What do you think of that? yCMS is not open source, but there is t3dlut. Do you want to help port either of those? The fact that most AVISynth filters support YUY2 makes it rather easy since that is what MLT uses (besides RGB and RGBA).

I'm really sorry for the dumb question, I didn't want to start another thread: I'm exited by the new color correction tools but I really can't understand how to use them, I feel very dumb :-( I mean, looking at them it seems they have just a visual/statistic function. I don't have your knowledge about color depth and so on but I really can't understand where I have to go to tweak some sliders to change color values etc.
Can you please help this poor 2-years Kdenlive proud user? Maybe a little video tutorial just to understand where to put... the arrow of my mouse...
You'll never understand how dumb I feel... I've been waiting for so long for this features and now I cannot manage to use them!!!
Thanks so much for all your hard work,
Ignazio

http://kdenlive.org/users/granjow/introducing-color-scopes-waveform-and-rgb-parade
An entry about the Vectorscope will follow soon.

This is a very deep topic, and it took me days to learn the things I know now about scopes, color, etc. And it's still only a tiny part I know. No need to feel dumb.

Simon

Dan, that's very exciting news. Really excellent. Sorry I'm no coder. :-(

lordofthestrings, Granjow has done a great job with the tools and write on there use. The scope tools are really for analytical use first and foremost. Steve Hullfish / Jamie Fowlers book 'Color Correction For Video' is a good starting point.

But they're not only for attempting to 'correct' bad camera work. :-) Failure to expose sufficiently, failure to manual white balance before shooting etc which should be done in camera.

They also come in useful when for example you have numerous shots through the day or series of days with differing lighting conditions, especially exterior shots in uncontrolable lighting, at different times of day and you want them to 'look' cohesive after you've done the edit and rearranged them all out of sequence. The scopes give you another view of colour casts, light levels, etc to analyse how you approach unifying the clips in conjuntion with masks, curves, 3 way colour tool etc.

Take a look at www.prolost.com scroll down a bit to the recent Colorista II vimeo tutorials Stu Machwitz does, that will explain a little further the idea's and purpose of the then look how you can emulate those.

Thanks a lot Granjow and Yellow. Actually I read the article but I'll go over it again to better understand.
Anyway, I think I miss something: you wrote about a new effect: "SOP/Sat". Is this the reason I can't find where to tweak to get color grading? I don't have that effect... Should I have to upgrade someway my effect list? Is it a Frei0r plugin? Shall I have to uninstall Frei0r and get a newer version of the Frei0r plugins?
I'm sorry for my English (I'm Italian), I hope you understood what I was trying to ask.
Thank you so much,
Ignazio

Now I've found on this thread:

http://www.kdenlive.org/forum/color-correction

a post by user "ttill":

"Just a quick note: For those new color correction you do not only need a recent version of Kdenlive but also of frei0r."
Is that the answer I'm looking for?

Yes.

Thanks a lot man,
I just saw that the last Frei0r was released yesterday and read the release notes.
Just one last question, please:
I added the new Sunab repo to install the latest stable Kdenlive 0.7.8. Now I'm at work and can't verify on my home pc but should I expect an automatic upgrade notify from the Ubuntu update manager about Frei0r or should I add this repo I just found?
https://launchpad.net/~sunab/+archive/sunab2 (I don't know right now if it's different from the one I added yesterday, but It has Frei0r 1.2 - compiled about 5 hours ago)
Ignazio