Clip Color range

Help
1

When I ffprobe videos my cameras Nikon Z6II and GoPro Hero 8 make, I get this results:

color_range=pc
color_space=bt709
color_transfer=bt709
color_primaries=bt709

So I need somehow to tell kdenlive that my files are using full range, color_range=pc instead of color_range=tv in order to get normal contrast of the video.

If I go to Clip properties / Edit / Color range = Full (JPEG), nothing changes. Video still stays low-contrast looking.

Also, I am not sure what to choose Monitor / Monitor Config / Monitor Gamma / [ sRGB | Rec.709] . I guess sRGB for a display on my computer display monitor. Anyway, with both options I don’t see the change.

2

If I play those videos with ffplay or VLC player, they will appear much more contrasty. But I am not sure should that be my reference to what is the “original” look :thinking:

3

I have some old footage here from a Hero 8, and in the 25.08.0 Appimage it’s defaulting to BT.709 / Full (JPEG) for me …

I guess sRGB for a display on my computer display monitor.

The right answer there probably depends on what your monitor is configured to expect, most of mine give me a choice of multiple standards - but sRGB or REC.709 are probably the most likely to be least surprising when you play what you edited on something else.

4

Yes, kdenlive recognize clip as a full range, but I am more concerned does it represent gamma correct, after marking the clip as full range. Does kdenlive represent it as low-contrast, unadjusted representation, or correct representation. And that is what matters at the end.

But before we can know answer to that, first we need to have a reference how “correct” display of the video looks like. Here are 4 screenshots of the same frame in 4 different video players. This is the video from Nikon Z6II.

VLC (best looking in gamma, and color in my opinion)

vlc-swatch
vlc-swatch1920Ă—1080 99.5 KB

ffplay (less contrast)

ffplay-swatch
ffplay-swatch1920Ă—1080 89.2 KB

kdenlive (same gamma as ffplay, but different colors, most noticable on primaries swatches. Also green tint of entire picture (that is another topic I want to open in another thread)

kden-swatch
kden-swatch1920Ă—1080 94.5 KB

Dragon player (overly saturated)

dragon-swatch
dragon-swatch1920Ă—1080 98.2 KB

5

I would like to add that on Windows 10, ffplay and VLC look indentical, but in Debian 13 Plasma they aren’t. Screenshots from previous post are from Debian

6

I am going to go out on a limb here, and place my bet on “When all is said and done, it probably does not”.

Partly because so much of that is out of our control (ie. it’s handled in libs that kdenlive uses but does not directly maintain) - and partly because of the simple and eternally enduring truth of “anything that isn’t tested is broken”.

So until someone shows me a rigorous test of correctness for this, I’m going to bet that writing one will shake out a whole rainbow of interesting things that need fixing!

before we can know answer to that, first we need to have a reference how “correct” display of the video looks like. Here are 4 screenshots of the same frame in 4 different video players.

And before I can trust what I’m seeing in these reference shots - I need to be able to trust that my browser and DE and hardware chain are showing them to me with perfect fidelity - which they too almost certainly are not. : (

But I do like the way you are thinking here - so I also really hope we can somehow harness what you know about this, and how much you care about it, into somehow auditing and providing some sort of testable provenance through as much of the video chain as we are able to assess and report bugs / provide patches to.

I would like to add that on Windows 10, ffplay and VLC look indentical, but in Debian 13 Plasma they aren’t

ffplay probably uses SDL to render to your screen while VLC probably does not and has many options for that - so again your original could have passed through multiple colourspace conversions and other interpolations before it actually arrived at some approximation of the one your display is expecting.

Which means you might see some interestingly different results by tweaking VLC video output through the alternate display renderers it has available on your machine.

And you don’t mention if you’re using Wayland or X11 and if you see any difference between them…

For some known issues off the top of my head to help kick this off, theres (at least):

Gamma correction for Wayland? - #3 by ngraham (note the timeline of progress there)

and this subthread: Kdenlive and vector graphics - #28 by Ron
where the addition of alpha removes any doubt about whether what my eyes are seeing on my screen is the same as what yours are seeing on yours…

7

Screenshots are from Wayland session. I will try X11, diferent VLC outputs you suggested, also repeat the test with same input video but encoded to limited/tv/legal color range with ffmpeg

8

I will also try with mpv, as after little bit of research I found that VLC media player is not considered a fully color-managed video player, so not a really a good reference for being a reference player :smiley:

9

The pipeline though mpv probably isn’t very different to ffplay - so it’s worth checking, but it will be more surprising if they don’t produce the same result than if they do.

1 Like