In the course of an unrelated forum thread a query came up about use of the “Full Luma Range” option in the Advanced Clip Properties.

https://forum.kde.org/viewtopic.php?f=270&t=130542

I indicated that, being new to KDenLive, I was running some tests to evaluate the behavior of different input and output video formats with respect to luma levels in order to establish my own workflow. TheDiveO suggested I might post them, starting a new thread as he thought this would be a topic of wider interest, which is possibly is.

In doing so though I wish to stress that these are purely observations made with recordings off my own camcorder - a Canon HF-G10. So, I’m not trying to contend, assert or defend any particular point of view here, and it could well be that the experience of others with different video sources varies.

Also, since this post is a rather lengthy, to say the least, now might be a good time to put on a pot of strong coffee before commencing reading. So to begin......

Edit: OR SKIP TO POST #31 FOR MY SUMMARY CONCLUSIONS IF YOU DON'T WANT TO PLOD THROUGH THE ENTIRE MEANDERING VOYAGE OF DISCOVERY

The tests were carried out with KDenLive 15.12.0 running on Kubuntu 15.10 (AMD 64)

The source video for these tests was a native 1080/30PF (mts) clip straight from my Canon HF-G10 AVCHD camcorder. To evaluate the behavior of other input formats the clip was encoded to Lossless Mastroska (HuffYuv).mkv and DNxHD.mov (1080p 30fps 220Mbps) using the respective KDenLive transcode presets.

The respective YUV luma ranges were determined by importing the clips into AVISynth and examining the YUV histograms and values using the built-in Histogram and ColorYUV filters. For now, I do this in Windows, but the same could be done in linux using AVISynth and VirtualDub via Wine, or else VaporSynth which has it own port of the AVISynth Histogram plug-in.

https://github.com/dubhater/vapoursynth-histogram

Examination of the YUV histograms showed that both transcodes preserved the native 16-255 luma range of the source mts clip. Here’s a frame shot showing just what that looks like:

http://i.imgur.com/XHUIOwc.jpg

The brown vertical bars delineate luma values falling below 16 and above 235.

For each input format, the test clip was placed on the KDenLive time-line and processed in three different ways:

1.No effect applied at all - “pass-through” or “round-tripping” as some might call it.
2.Clip split into 3 parts and Distortion effect (Mirror) applied to the middle segment
3.Clip split into 3 parts and very light Luma curve applied to the middle segment

A new project was set-up for each of the input formats and each of the ‘treatments’, and each project was rendered out to Lossless HuffYuv (+flac).mkv and (“Intra”) H264 (libx264 +aac).mp4.

Analysis of the YUV histogram profiles of all of the rendered encodes revealed the same behavior for all three input formats, namely:

1.The renders from all of the “pass-through” tests retained the original 16-255 luma scale. Same as the frame-shot above.

2.The renders from all of the tests where the Distortion (Mirror) effect was applied also retained the original 16-255 luma scale.

Frame shot: http://i.imgur.com/Zx1Jfev.jpg

3.The renders from all of the tests where the light Luma curve was applied however showed a different pattern; in this case, the frames to which the effect had been applied showed a “clamped” 16-235 luma range, whereas the unaffected frames retained the 16-255 luma scale.

Frame -shot of ‘curve applied’ frame:
http://i.imgur.com/Evjyds3.jpg

Now the last case didn’t surprise me. The Curves effect is carried in RGB colorspace and so it is logical that the 16-255 luma would be clamped to 16-235 as a result of the Rec709 conversion to RGB and back. And this is “clamping”, not “compression”. In Rec709 conversion to 0-255 RGB, all YUV luma values below 16 are clamped (clipped, limited) to 16 and all values above 235 are clamped to 235. Compression, on the other hand, refers to deliberate down-scaling of the YUV luma to 16-235 and results in a lower gradient luma curve and associated reduction in contrast. Clamping or clipping preserves the luma gradient.

To illustrate that point, here are two more frame shots. In the first instance, I took the decode YV12 output from the source mts clip and (in AVISynth ) converted it to RGB24 and back to YV12 applying Rec709 color matrix coefficients.

http://i.imgur.com/3Svgswi.jpg

In the second case, I simply down-scaled the YV12 luma from 16-255 to 16-235.

http://i.imgur.com/alBBmrn.jpg

Notice the difference in the luma profiles and compare them with that of the frame to which curve effect had been applied.

So what about the case where the Distort (Mirror) effect was applied? Well the reasonable conclusion there is that the transform is actually executed in YUV color space, so preserving the 16-255 luma scale. If that is the case, what would interesting and of value would be to see which effects call for RGB and which don’t.

Now, this is where it gets really interesting. I then repeated the whole series of tests this time setting the (advanced) properties of the input clip with the “Full Luma Range” option selected (off by default).

The results are easy to summarize. In ALL of the renders the luma was clipped, not to 16-235, but to 32-235 and irrespective of whether an effect was applied or not. Here’s a representative frame shot:

http://i.imgur.com/AppuOku.jpg

What ? How come? But I thought.....? Well, here’s my interpretation of what’s happening, right or wrong. The “Full Luma Range” option invokes a flag that presents the 16-255 luma as though it were full range 0-255. This in turn prompts the YUV to RGB conversion process to apply Rec709 color matrix coefficients that are modified to accommodate full range luma. Then on conversion back to YUV, the standard Rec709 coefficients are applied, bringing the luma range to 16-235. The problem this presents for a 16-255 luma YUV source is that black point gets shifted from 16 up to 32. Not good. In this case the luma is most definitely compressed.

How could I think such a thing? Well because I can replicate it with AVISynth doing just that . The AVISynth Convert plugin has such a “special purpose” color matrix - tagged PC.709 - specifically for full range luma sources - if I apply it with the script below, the resulting YV12 luma histogram (virtually) matches that of the KDenLive YUY2 renders produced with “Full Luma Range” option selected.

AVISynth script:

Code: Select all

DGSourceIM("C:\..Path..\TestHFG10.dgi", silent=true) # Decode mts YV12
ConvertToRGB32(matrix="PC.709", interlaced=false)
ConvertToYV12(matrix="rec709", interlaced=false)
Spline36Resize(1280,720)
Histogram(mode="levels")

Frame shot: http://i.imgur.com/tirXrkk.jpg

Or converting to RGB via YV24 (YUV 4:4:4)

Code: Select all

DGSourceIM("C:\..Path..\TestHFG10.dgi", silent=true) # Decode mts YV12
ConvertToYV24(chromaresample="point", interlaced=false)
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32(matrix="PC.709", interlaced=false)
ConvertToYV12(chromaresample="point",matrix="rec709")
Spline36Resize(1280,720)
Histogram(mode="levels")

Frame shot: http://i.imgur.com/jBc5aWa.jpg

Now if that is equivalent to how the “Full Luma Range” option works, one might then say - why not just pre-scale the 16-255 luma to full scale 0-255 - surely that would avoid the black-point shift from 16 to 32?

That’s something I went on to test. Using AVISynth again (Smooth Adjust plugin) I scaled the YV12 luma range of the source mts clip to 0-255, converted to YUY2 and frame-served to FFMPEG for transcoding to DNxHD. Here’s a frame shot of the resulting encode:

http://i.imgur.com/HqxYUkt.jpg

I then loaded the “full-scale” DNxHD encode in to KDenLive setting the “Full Range Luma” flag in Clip Properties and, as before tested with no effect applied (Pass Through) and then after applying the same Mirror and Curve effects. All were rendered out to Matroska.mkv (only). Examining at the resulting YUV Histograms, lo and behold they all now exhibit 16-235 luma:

http://i.imgur.com/5cmAFYP.jpg

But look at the luma profile - the whole profile has now shifted down and in fact it's not that different from the one I showed above that demonstrated down-scaling (compressing) of 16-255 to 16-235 luma (as distinct from clamping/clipping) and compression is not what I want, as a general rule.

So, for my HF-G10 recordings at least I can see no justification or scope at all for applying the “Full Luma Range” option.

This leaves me pondering how best to process in KDenLive in a way that avoids outputs with a mix of 16-255 and clipped 16-235 luma. There are several options there, but I won’t elaborate on that at this point.

Just to stress again though, I haven’t posted this to seek advice; I’ve drawn my own conclusions. That said if someone does have further insight into the exact way the “Full Luma Range” option operates, it would be interesting to know.

I'm also in the process of carrying out parallel tests with 1080/30p H264.mp4 clips off my Nikon AW120 "all weather" camera, which records with full range 0-255 luma. A few surprises there also. I'll come back on that when I'm done.

P.S. Regarding:

Inapickle wrote:The respective YUV luma ranges were determined by importing the clips into AVISynth and examining the YUV histograms and values using the built-in Histogram and ColorYUV filters. For now, I do this in Windows, but the same could be done in linux using AVISynth and VirtualDub via Wine....

For anyone wanting to use that method for examining YUV luma levels, I'm still trying to get it working properly in Wine. I can load the AVIsynth scripts, but cannot seek on the VirtualDub timeline without the image corrupting. Once I've resolved that, I'll post the method.

I always thought the option was there for when kdenlive failed to recognise full-range video as full range video, and so expanded out 16-235 to 0-255, which is what I'd expect.

Of course if you have video with ref. black at 16 and ref. white at 255 you'll have issues, because that's an odd place to have them. I can see some black below 16 on your screenshot, is the device not simply 0-255, but with low contrast in the darks?

Thanks for these great insights Inapickle! This is a rather complex theme for me and you describe it very well so I can grasp a lot of it and at the same time thinking about how I m gonna alter my workflow to not "compress" my luma range without need etc.. Thanks again!

It s hard for me to find helpful information on that topic in the webs (except here in the forum). In my case I use a sony a7s camer with different picture profiles applied and I wonder how to process these files while editing, and couldnt really find a conclusion either.. for now i leave the "full range luma" box unchecked. ....

Thanks for your comments.

CorrosiveTruths wrote:I always thought the option was there for when kdenlive failed to recognise full-range video as full range video, and so expanded out 16-235 to 0-255, which is what I'd expect.?

I don't know, has that been your experience?

All I can do is report what I have found to be the case and offer my best explanation for those findings. The description of the "Full Luma Range" setting in the Manual I found a little perplexing:

https://userbase.kde.org/Kdenlive/Manual/Full_Luma/en

... in particular the statement "By setting the full luma on, which should only be done for camera sources known to be full range 0 - 255 or even 16 - 255 such as FS100, Nex5, HV20, HV30 and probably many more consumer cameras" - which is what prompted me to examine that for myself.

Every digital camcorder I have owned has recorded with, what I call, an "effective" 16-255 YV12 luma range, including the Canon HF-G10 I have now, a Canon HV30 and HV20 (PAL model) an two DV camcorders - Panasonic GS400 and Sony DCR-PC115E. So it's nothing new or unique. Indeed before the emergence and increasing popularity of still cameras with video capability, it was pretty much the norm, at least in the consumer/prosumer camcorder domain.

CorrosiveTruths wrote: Of course if you have video with ref. black at 16 and ref. white at 255 you'll have issues, because that's an odd place to have them. I can see some black below 16 on your screenshot, is the device not simply 0-255, but with low contrast in the darks?

Well, it might seem odd if you are not familiar with viewing YUV histograms; but I assure you it's quite normal. One thing to appreciate is that when software decoders decode YV12 sources the raw YV12 output is full scale - meaning they declare all "luma-deemed" signal values on the 0-255 scale. And that's what you are seeing on the YUV Histograms. So why, one might ask, if a camcorder, like my HF-G10, is recording AVCHD video in full compliance with Rec709/Bt.709 standards, do any luma values fall outside the 'valid' 16-235 luma range? Well the answer to that, and the points you raise, lie in the Rec709 standard itself, I'm afraid I don't have time this evening to explain that further. I'll endeavor to tomorrow, but for now I'll leave you with this summary of the Rec.709 standard which might answer some of your comments:

http://everything.explained.today/Rec._709/

See the section "Digital Representation"

Cheers.

kalimerox wrote:Thanks for these great insights Inapickle! This is a rather complex theme for me and you describe it very well so I can grasp a lot of it and at the same time thinking about how I m gonna alter my workflow to not "compress" my luma range without need etc.. Thanks again!

It s hard for me to find helpful information on that topic in the webs (except here in the forum). In my case I use a sony a7s camer with different picture profiles applied and I wonder how to process these files while editing, and couldnt really find a conclusion either.. for now i leave the "full range luma" box unchecked. ....

Likewise, thanks for your comments, but it troubles me a bit if you are basing that decision solely on an interpretation of how my findings might apply to your video sources, and especially if means radically changing your workflow.

Inapickle wrote:Thanks for your comments.

CorrosiveTruths wrote:I always thought the option was there for when kdenlive failed to recognise full-range video as full range video, and so expanded out 16-235 to 0-255, which is what I'd expect.?

I don't know, has that been your experience?

All I can do is report what I have found to be the case and offer my best explanation for those findings. The description of the "Full Luma Range" setting in the Manual I found a little perplexing:

https://userbase.kde.org/Kdenlive/Manual/Full_Luma/en

... in particular the statement "By setting the full luma on, which should only be done for camera sources known to be full range 0 - 255 or even 16 - 255 such as FS100, Nex5, HV20, HV30 and probably many more consumer cameras" - which is what prompted me to examine that for myself.

Every digital camcorder I have owned has recorded with, what I call, an "effective" 16-255 YV12 luma range, including the Canon HF-G10 I have now, a Canon HV30 and HV20 (PAL model) an two DV camcorders - Panasonic GS400 and Sony DCR-PC115E. So it's nothing new or unique. Indeed before the emergence and increasing popularity of still cameras with video capability, it was pretty much the norm, at least in the consumer/prosumer camcorder domain.

CorrosiveTruths wrote: Of course if you have video with ref. black at 16 and ref. white at 255 you'll have issues, because that's an odd place to have them. I can see some black below 16 on your screenshot, is the device not simply 0-255, but with low contrast in the darks?

Well, it might seem odd if you are not familiar with viewing YUV histograms; but I assure you it's quite normal. One thing to appreciate is that when software decoders decode YV12 sources the raw YV12 output is full scale - meaning they declare all "luma-deemed" signal values on the 0-255 scale. And that's what you are seeing on the YUV Histograms. So why, one might ask, if a camcorder, like my HF-G10, is recording AVCHD video in full compliance with Rec709/Bt.709 standards, do any luma values fall outside the 'valid' 16-235 luma range? Well the answer to that, and the points you raise, lie in the Rec709 standard itself, I'm afraid I don't have time this evening to explain that further. I'll endeavor to tomorrow, but for now I'll leave you with this summary of the Rec.709 standard which might answer some of your comments:

http://everything.explained.today/Rec._709/

See the section "Digital Representation"

Cheers.

The condescension is not warranted.

A simple, my device definitely captures 16-255, as do some other consumer devices, would have sufficed.

Inapickle wrote:http://everything.explained.today/Rec._709/

Thank you for the reference, an interesting read. Still unsure whether the developers at the various cam manufacturers really got everything correctly implemented...

CorrosiveTruths wrote:The condescension is not warranted.

A simple, my device definitely captures 16-255, as do some other consumer devices, would have sufficed.

OK, that's it. End of discussion for me. Precisely why I was hesitant about posting my findings. If you already understood what I took pains to explain and was prepared to elaborate on further, you wouldn't have raised the points you did. So not condescending at all actually. In fact, the other way round.

As for the tests I'm completing with full scale 0-255 luma video off my Nikon AW120, well I'll keep the results to myself. Wouldn't want to ruffle anyone's feathers explaining the findings. A relief actually.

Anyhow, I hope what I have posted will helpful to and appreciated by some.

TheDiveO wrote:

Inapickle wrote:http://everything.explained.today/Rec._709/

Thank you for the reference, an interesting read. Still unsure whether the developers at the various cam manufacturers really got everything correctly implemented...

Just to answer that point. A popular opinion is that camcorder engineers, from all of the major companies, exploited allowances in the Rec.601 and then Rec.709 standards for 8-bit encoding in the 236-254 range to accommodate filter overshoot, transient signals and specular highlights, and used this as a way of gaining a little extra dynamic range and headroom for grading i.e. bent the rules, so to speak. To what extent that's true or simply that full scale YV12 decoding co-incidentally reveals these "super-white" excursions, I'm not sure.

Inapickle wrote:

CorrosiveTruths wrote:The condescension is not warranted.

A simple, my device definitely captures 16-255, as do some other consumer devices, would have sufficed.

OK, that's it. End of discussion for me. Precisely why I was hesitant about posting my findings. If you already understood what I took pains to explain and was prepared to elaborate on further, you wouldn't have raised the points you did. So not condescending at all actually. In fact, the other way round.

As for the tests I'm completing with full scale 0-255 luma video off my Nikon AW120, well I'll keep the results to myself. Wouldn't want to ruffle anyone's feathers explaining the findings. A relief actually.

Anyhow, I hope what I have posted will helpful to and appreciated by some.

This isn't a healthy reaction and, on second thought, I'm not going to feed into that.

Please, talk to someone.

Inapickle wrote:

kalimerox wrote:Thanks for these great insights Inapickle! This is a rather complex theme for me and you describe it very well so I can grasp a lot of it and at the same time thinking about how I m gonna alter my workflow to not "compress" my luma range without need etc.. Thanks again!

It s hard for me to find helpful information on that topic in the webs (except here in the forum). In my case I use a sony a7s camer with different picture profiles applied and I wonder how to process these files while editing, and couldnt really find a conclusion either.. for now i leave the "full range luma" box unchecked. ....

Likewise, thanks for your comments, but it troubles me a bit if you are basing that decision solely on an interpretation of how my findings might apply to your video sources, and especially if means radically changing your workflow.

@kalimerox.

Just to follow-up on that - like I said in the Lift-Gamma-Gain thread, if you're in a quandary about what approach to take, really the best person to help you would be someone who owns an a7s and/or is familiar with the format. That said, if you want to put up a sample raw clip from your camera, or send it to me (ftp, DropBox etc), I'd be quite happy to look at it and run some tests to see how it behaves. Just a few seconds would suffice, but obviously it would need to cover the full dynamic range - something like a back-lit window shot. And ideally with the default camera settings i.e. not one of the picture profiles.

I had a scout around the web to see if there were any sample raw clips for download. Best I could find was this raw UHD/24p clip from a Sony a7s II shot in S-Log 3 mode:

https://vimeo.com/142412840

Looking at the YUV histogram it's difficult to gauge what the effective luma range is, and to what extent the S-Log may be influencing that skew:

http://i.imgur.com/TmH5LmD.jpg

Inapickle wrote:As for the tests I'm completing with full scale 0-255 luma video off my Nikon AW120, well I'll keep the results to myself.

I am asking you to post your findings here; I'm interested. If someone isn't interested in your findings then s/he is free to ignore your findings. I for one would like to get more information from different sources to maybe get a better understanding in the long run.

Just one final request. Reading the post that the description of "Full Luma Range" is taken from:

viewtopic.php?f=265&t=114887&p=280835&hilit=Full+Luma+Range#p280835

...I see there is a link there to another article that gives some further explanation of the "Full Luma Range" option:

http://blendervse.wordpress.com/2012/04 ... ange-flag/

Unfortunately the link is dead. Does anyone have a valid link or copy of the article on file?

The Wayback Machine will help: http://web.archive.org/web/201404021316 ... ange-flag/