Hi,

I've just started using KDenLive 15.08.1 on Kubuntu 15.10 (AMD 64).

Regarding the RGB Curves Effect - I'm perplexed as to why it does not seem possible to make independent curve adjustments in the Red, Green, Blue and Luma channels. Whatever adjustment I make in any one channel then gets replicated in the others. Is there some option I am missing to "unlock" the curves so that they can be adjusted independently ?

Thanks.

Curves works on a single channel only at a time. Here, channels are R, G, B, all three simultaneously (RGB), luma, hue, ... If you need to work on RGB components individually, you'll need to use the curves effect multiple times.

OK, thanks.

Yes, that's what I ended up doing as, what I thought, was a "workaround".

No, that's design. Or a feature.

Nicely put.

It just seemed a bit odd when you're used to being able to toggle between the channel curves. Still it does have the benefit of being able to view and work on more than one channel at the same time, with the minor inconvenience of having to move panes around to make space - but I prefer that than having piddly little curve windows like some NLE's do.

Another thing is getting used to 0-1000 scaled values. I'm used to 0-255. But at least it has input values and grids for fine/precise adjustments.

Cheers.

@ TheDiveO,

I have another question, this time the Bezier curves and specifically the RGB "Channel" curve.

Basically, I have a number of RGB curves in PS .acv format that I'd been using in my Windows colour grading workflow. The curves were created and/or modified using the VirtualDub Gradation Curves plugin, which is able to import and export .acv files:

http://members.chello.at/nagiller/vdub/readme.html

Active development of the plug-in ceased back in 2008, but it is still quite usable. To incorporate the curves in my AVISynth workflow, what I would do is load the AVS script in VirtualDub, pull-up the Gradation Curves filter, load the curve of choice, modify it as needed with Preview and then save as a VDub processing settings file (.vcf). I would then open up the vcf file Notepad and copy the curve configuration string into an AVISynth port of the VDub plugin inserted in the script. It worked very well, but was rather tedious and didn't make for easy back and to tweaking of the curve.

All this to explain why I'm now looking at KDenLive. That said, since there appears to be no way of converting the .acv files for import in KDenLive (I'd be delighted if there is one) I'm left with the prospect of re-creating the curves from scratch.

Some of the simpler curves I've now done. These are curves that affected only the individual R,G and B channels and so it was more or less a question of scaling the spline point co-ordinates from 0-255 to 0-1000 values and plugging them into the respective channels in the regular 'Curves' effect. Works just fine.

Others however are more complex and are a composite of curves made in the individual channels and the "RGB" Channel. Since the regular "Curves" effect does not have a "RGB" channel option, I'm left with the prospect of re-creating them with the Bezier curves tool, which does. Not something I particularly relish as I'm not that adept using Bezier handles and I'll probably have to go back into the .acv curves to derive more spline points as my best hope of getting accurate and smooth reproduction. But before I do, something caught my attention when reading one of your very helpful tutorials on KDenLive curves:

http://thediveo-e.blogspot.ca/2013/10/g ... rline.html

In the section "Protune Tonal Curve" you show an image of a KdenLive Bezier curve set to the "RGB" channel and in the text state "In the effect's properties window, Channel must be set to «RGB». As the Luma formula, select «Rec. 709» if not done already so. Otherwise you will experience a slight green tint".

Now this mention of "Luma formula" has got me a bit befuddled. The usual explanation given for what the "RGB channel" actually does (at least in PS) is that it applies the same curve values to each of the colour channels and modifies (on output) whatever curve modifications may have been made in the individual RGB channels accordingly. I've never been able to source a definitive reference that fully explains the calculations involved, but that's how I've understood it, in simplistic terms.

Just to complicate matters the VDub Gradation Curves filter actually offers two mode options for - "RGB" + R,G,B channel curves - a standard mode, stated (in the linked Read Me - under Processing Mode) to "behave similar to the curves function of painting programs", which I've always taken to imply PS and Gimp (where "Value" is used in place of "RGB" channel). And then there is a "weighted" mode, which according to the description uses derived Y value (from the "RGB channel") to apply weighting to the respective R, G and B pixel value transforms. Again, can't say I fully understand it, but I've always avoided using the "weighted" mode as it seems to imply that the calculations are dependant on the colour matrix used for the Y value derivation. And given that the plug-in was developed nigh-on 10 years ago, it's probably using Rec601, whereas I'm processing HD (Rec709) YV12 video. So I've always stuck with the 'standard' "RGB" + R,G,B channel mode, thinking it is not colour matrix dependant (maybe wrongly?)

So this mention of "Luma formula" and "Rec709" in your tutorial now has me wondering - does the "RGB channel" in the KDenLive Bezier curves actually use a similar "Y" value weighting in it's calculations or can I safely assume that spline values taken from the "RGB channel" of my .acv curve files are still valid (after scaling 0-255 to 0-1000) ?

Is there any reference that sets out the calculations involved ?

Sorry for such a lengthy post, but some background explanation seemed relevant to what I'm trying to do.

Cheers.

Thank you for bringing this to my attention. Mentioning Luma and R.709 in this form is probably misleading, it probably came from the fact that there were some time where the Bézier and Curve effects also had a R.709 check box. However, there is one important underlaying thing to know that is different from working with RGB files in Gimp, Photoshop, etc. As you already hinted at, video source material typically is encoded in "some" yuv space, that's a universe in itself. Now if I remember correctly, MLT can also operate in different color spaces, so there might be a conversion to the RGB space necessary in order to carry out the effect. And this formerly was the reason for an R.709 checkbox in Kdenlive for these two effects I mentioned above. But I surely need to revisit this section of this blog article and clear it up. Of course, from the perspective of the RGB Curve, there are just the RGB channels. I expect such things to also creep up to the surface with Gimp 3.0 with GEGL, as this can perfectly work in multiple color spaces, and needs to do so as some things cannot be easily done in RGB.

As for the whole video color space madness, I hightly recommend to buy this book, also available as PDF:
Charles Poynton, Digital Video and HD, Algorithm and Interfaces, 2012, 2nd ed, Morgan Kaufman/Elsevier, 978-0-12-391926-7.

OK thanks a lot for clarifying that.

TheDiveO wrote:Now if I remember correctly, MLT can also operate in different color spaces, so there might be a conversion to the RGB space necessary in order to carry out the effect. And this formerly was the reason for an R.709 checkbox in Kdenlive for these two effects I mentioned above........Of course, from the perspective of the RGB Curve, there are just the RGB channels.

Interesting you say that. I've wondered myself whether KDenlive actually processes YUV (typically YV12, YUY2) sources in YUV 4:4:4 (YV24) space, up-sampling to RGB as needed for the effect in question. Reason for that thought - my Canon HF-G10 like many 'prosumer' camcorders, records YV12 with an effective 16-255 luma range. If I edit native clips on the timeline, apply an effect and render out to any of the 4:2:0 or 4:2:2 formats, the luma range gets clipped to 16-235, as would be expected with a Rec709 conversion of YV12 to RGB and back to YUV. However, if I apply no effect to a clip and render out to the same formats, the original 16-255 is 'preserved'. Now how is it doing that? It's not 'smart rendering' in the usual sense, as obviously all frames are re-encoded at render - but if the engine is operating in and serving effects from YUV space, it's easy to explain how the luma scale could be preserved for those frames to which an edit effect has not been applied. Anyone from the development team who could clarify that speculation ?

My assumption about the Rec709/Rec601 checkbox option in Curves was that it is needed to calculate the correct values for the "Luma" curve specifically, which is surely still the case ? Some programs of course make that selection automatically on the basis of frame resolution.

TheDiveO wrote:As for the whole video color space madness, I hightly recommend to buy this book, also available as PDF:
Charles Poynton, Digital Video and HD, Algorithm and Interfaces, 2012, 2nd ed, Morgan Kaufman/Elsevier, 978-0-12-391926-7.

Thanks, yes, I've read some of Poynton's stuff. I'll maybe delve into it again....for a little bedtime reading.

Yeah, I need to reread Poynton again too. I only slowly start to put some pieces together he is so experienced with. The engine within Kdenlive is in fact MLT. I'm not sure but I somehow seem to remember that MLT can use YUV 8:8:8, but I also may completely wrong here, wildly guessing.

That would be because frame representaion is 8:8:8:8 with the fourth element being alpha. And so it can be either YUV or RGB. Now MLT does the conversion necessary within the pipeline according what color space an effect or transition works in.

There's a catch MLT cannot avoid and that you may notice in particular when you are working with composition transitions: unavoidable rounding/quantisation errors during color space conversions. You'll in particular see a slight color tint offset in those case where you apply a composite transition only to a part of a YUV clip and the overlay is RGB, such as a title clip. If I understand the bug reports and David Dannedy's explanation correctly, only higher internal precision, such as 16bit instead of 8bit would reduce such unwanted effects. BTW, this may affect affine also, I don't remember exactly.

Thanks again. I'll bare that in mind as and when I actually get around to putting a project on the timeline. Haven't even looked at transitions as yet.
For now I'm more focussed on examining the available tools for secondary colour correction and grading using test clips. Curves is one. Blend/mixing modes another - hence the comment I posted about opacity control. Likely there will be more 'newbie' queries as I work my way through the Effects list......next-up - probably selective color correction/grading.