I installed the newly released Windows port of KdenLive 16.12.1 on Windows 7 x64 a couple of days back. Testing it out with DNxHD transcodes of some 'full range' (0 - 255) HD-AVC clips I noticed that applying the forced 'Full Luma' option (in Clip Properties) brought about clipping (clamping) to 'Limited' 16-235 range. With the linux version of 16.12.1 (on Kubuntu 16.10 AMD64) the observed behavior is compression (scaling) to 16-235, which is the expected outcome and has been since the 'Full Luma' option was first introduced.

Just a little background to put this issue in context. Some while back I conducted an in-depth study on how KDenLive treats the luminance levels of different sources, in part to understand what the 'Full Luma' option actually does and when it should be applied:

viewtopic.php?f=272&t=130641

To deduce the behavior I used an independent method (AVISynth YUV Histogram) for examining the YUV profiles of the different inputs and rendered outputs. This also gave insight into what the KDenLive Videoscopes actually represent. The thread that chronicled that meandering voyage of discovery is rather a heavy read, so I'll summarize the main points as they pertain to full range sources.

Native HD-AVC clips recorded on digital cameras with full ('swing') range (0-255) YUV luma are distinguished by the pixel format designation yuvj420p, where 'j' represents 'jpeg scaling'. KdenLive treats such clips in accordance with the default decode behavior of ffmpeg/MLT, which is to compress (scale) the full luma range to 16-235 range - so called 'Limited' or 'Broadcast' range. And it is in that compressed form that the imported frames are passed through MLT each with it's own format attached, converting to and from the particular formats required by the different effects and transitions - and, for the most part, that involves conversion to and from RGB via applied Rec709 color matrix coefficients. As such, the compressed 16-235 range persists through to export unless the render format is one that facilitates scaling back out to full 0-255 range.

Native full range clips that have been transcoded to compatible 'edit intermediate' formats (like DNxHD, ProRes, UTVideo) with ffmpeg, or transcode presets in KDenLive, exhibit the same behavior. The difference in this case is that the compression occurs in the transcode operation itself. These transcodes do not carry the corresponding 'full range' pix_fmt flags (yuvj422p, yuvj422p10le) and so on import to Kdenlive the 'pre-compressed' 16-235 luma range is transferred without further compression.

Another scenario arises however if the clips are transcoded in a way that does preserve the full range luma. There are ways to do that in ffmpeg using -vf filters. Transcodes generated in other systems using Quicktime or VFW codecs also fall into this category. These transcodes also lack the 'full range' pix_fmt designations. What happens in this case is that the full range luma is preserved on input to KdenLive and if no effects are applied it is passed through to output. So if the editing is limited to cutting/trimming this provides a way of preserving the original full luma range in the rendered edit.

However, if an effect or transition is applied that requires or is mediated via RGB (as most effects do), the application of Rec709 conversion coefficients will result in 'clipping' to 16-235 range which is rather different to compression, and to my mind the less desirable outcome of the two. Compressed 16-235 luma can at least be expanded back to full 0-255 range at rendering using custom x264 formats that specify the respective full range pix_fmt. Clipping however 'clamps' all luma values below 16 to 16 and all values above 235 to 235, and that lost data cannot be recovered. What's more, if the edit includes sections where no effects are applied, you will end up with a mix of full and clipped luma range frames on rendering, which is hardly desirable.

This is where the 'Full Luma' option comes into play because it forces the input luma to be reckoned as full range (substituting for a 'full range' pix_fmt flag) and applies compression to 16-235. But for some reason that is not happening in the Windows port of KDenLive 16.12.1. Instead when the 'Full Luma' option is applied it results in uniform clipping to 16-235 and specifically with YUV 4:2:2 input formats - including DNxHD (8 or 10bit), ProRes, HuffYUV, UTVideo (YUY2) Raw (Uncompressed) 4:2:2 and x264 in 4:2:2 format.

As an example, here are the results obtained with a full range (0-255) YUV greyscale gradient clip (10-bit DNxHD) created with DaVinci Resolve (windows version). KDenLive Clip Properties showed the pix_fmt to be yuv422p10le, so it is not flagged as full range.

Taking first the behavior observed with KDenLive 16.12.1 on Kubuntu 16.10. The greyscale clip was first loaded onto the timeline and, with no effects applied, rendered out to 8-bit DNxHD. Examination of the AVISynth YUV Histogram of the DNxHD render showed that the full (0-255) luma range was preserved. That is the expected default 'pass-through' behavior. The test was then repeated after applying the 'Full Luma' option in Clip Properties. In this case, the YUV Histogram of the DNxHD render showed that the luma range had been compressed to 16-235 range. Again, that is the expected outcome. Here are frame grabs of the respective AVISynth YUV Histogram profiles:



The top Histogram is the Luma (Y) component. The Histogram displays the full (0-255) data range. The vertical brown bars mark the limited (16-235) range boundaries.

But here's what the KDenLive Waveform monitor showed when the greyscale clip was loaded on the timeline with and without the 'Full Luma' option:



This illustrates why reliance on the KDenlive scopes can be misleading. The luma (Y) values for the WFM (and Luma Histogram) are not taken directly from the YUV frames as they 'sit' on MLT. They are derived indirectly via RGB by applied Rec709 conversion co-efficients. So although the scopes are scaled 0-255, what they actually represent is Limited 16-235 range. And you can see that there with the grey-scale clip where the 'Full Luma' option was not applied. The WFM appears to show clipping at the 0 and 255 scale points, which is not possible. What you are actually seeing is the full luma range clipped to 16-235 as a result of the Luma (Y) values being derived by Rec709 calculation. Same goes for the greyscale clip with the 'Full Luma' option applied. What you are seeing is compressed 16-235 range displayed as if 0-255 range. This is an issue that was brought up a good while back:

viewtopic.php?f=279&t=130705

Anyhow, the exact same test was then carried out using Windows port of KDenLive 16.12.1 (on Windows 7 x64). When the 'Full Luma' option was NOT applied to the greyscale clip, the YUV Histogram of the DNxHD render likewise showed that the full luma range was preserved on output. Again that is the expected behavior. But when the 'Full Luma' option was applied, the YUV Histogram of the render showed uniform clipping (clamping) to 16-235 range:



Yet, looking at the KDenLive WFM, at face value, there would appear to be no difference between the two i.e. it looks the 'Full Luma' option is doing nothing.



Again, the reason for that is because of the way Luma (Y) values are derived for the KDenLive scopes. In effect, when the 'Full Luma' option was applied it brought about clipping to 16-235. So when deriving the Luma (Y) values for the WFM there was nothing left over to clip.

So I think this change in behavior observed with the 'Full Luma' option in the Windows port of KDenLive represents a bug and it needs to be resolved as quickly as possible. In the Windows environment, users might well want to use transcodes of full range video clips that have been generated in other systems and it is important that these can be made to to conform to same behavior as native clips in KDenLive. It is also important that the behavior is consistent when moving clips and projects between the Linux and Windows environments.

I've filed a bug report:

https://bugs.kde.org/show_bug.cgi?id=375303