Registered Member
|
Pardon my ignorance, but I just got the latest svn of kdenlive from the ubuntu repository and I now have a tab that is called vectorscope and I was wondering what it does.
Thanks, Lexen |
Moderator
|
Hi Lexen,
In the current SVN version there are 4 new tabs. They are basically all used for color correction.
The Vectorscope is mainly used for two things:
The way the vectorscope works is maybe new for most. Black is in the middle, but so is white. Actually everything with no saturation (all greys as well). The further away a point from the center, the higher its saturation. Independant of its brightness. The angle defines its color; Top left is red, right is blue, bottom left is green. You can put a sample YUV plane on the background for illustration. There are two points for every color; one for 100% saturation and one for 75%. Colors in videos for broadcast must not, as far as I know, exceed the 75% marks (See links at the end why.). But you may want to be as close to them as possible to get well saturated colors. By right-clicking on the scope you can also display a 75% polygone. This won't be of importance for most of us though :) And at the moment I don't guarantee for 100% correctness. In the image above I've shot a neon lamp at 5500 K, so it is not white but, yes, what? You can see it in the Scope. This can be corrected with e.g. curves or 3 point color correction. Latter could be improved to show 3 wheels with YUV background, so you just need to put the color selector in the same direction as the scope shows to remove the color cast. Gain is used to zoom in, allowing very precise corrections. The vectorscope is using the YUV color space.
For example, in the image above the luminance never reaches 0, so it could be stretched (e.g. with the Curves filter) to go from 0 to 255.
Which means that it is pretty mighty. Detecting the color of color casts is easier in the Vectorscope however. Imho :) Clipping happens if a color component (R/G/B) reaches the maximum brightness value (255 for 8-bit input) and would actually be even higher if it could. But it cannot, which results in loss of information (which you want to preserve as long as possible). In the above image the parade shows that in the left part of the image blue is quite low, and there are bright spots on the right with more blue (which is the sky). Here another image of the neon video, showing how the RGB parade exposes color casts.
What it does is just statistics. For R, it counts how many pixels have an R value of 0, how many have an R value of 1, of 2, etc., until 255. This leads to the graph above. The vertical bars visible there is not a fault of kdenlive but of the camera; I don't know what exactly it is doing there, perhaps some preprocessing I forgot to switch off. It does not show up on all videos. As Waveform, it can be used for
More on Wikipedia:
Further Reading: e.g. Color Correction for Video also on google books In all scopes, you can enable Auto-Refresh (via right-click), causing the scope to be refreshed for every incoming frame. Realtime makes the calculations faster but less accurate. And at the moment it is not working perfectly because it will make the monitor play faster. Simon Disclaimer: No guarantee for correctness, already past midnight. |
Registered Member
|
Just bumped into this thread, great to see some scopes being created for kdenlive.
Are your scope examples just straight video imports into kdenlive or have you applied any effects to them? |
Moderator
|
|
Registered Member
|
D90, by that I guess you mean video from D90? mjpeg?
|
Moderator
|
Stream #0.0: Video: mjpeg, yuvj422p, 1280x720, 24 tbr, 24 tbn, 24 tbc
Stream #0.1: Audio: pcm_s16le, 11025 Hz, 1 channels, s16, 176 kb/s ;) Why do you ask? |
Registered Member
|
Looking at the scopes, which are great btw. :-) It's clear that something is not right, the gaps in the histogram, the clipped highlights and blacks suggests either the Yxxx to RGB conversion method used for the scopes is stretching the levels or kdenlive is.
If the video in your example has had no filters / effects added then the scopes should reflect the levels within the source video files, there would be no stretching of levels. In reality, if one was to encode back out to a Yxxx video space, without applying any filters or effects the source levels should remain as input? but I don't think the scopes show source levels. Is FFmpeg being used to do the Yxxx to RGB conversion for the scopes, if so then that would explain the stretching, swscale is bad at doing the Yxxx to RGB conversion with regard to NLE use. However, what would be worse is if kdenlive does the same stretched conversion when it applies effects like the Frie0r plugins which work in RGB and at 8bit not 32bit float precision too I believe. Great scopes though. :-) |
Registered Member
|
Take a look at this discussion on kdenlive-devel:
http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTim4QJy6UcY9tYgAVddtP3ks_ToqA3GRFKi6tEX4%40mail.gmail.com&forum_name=kdenlive-devel You might want to point out your doubts on libswscale color space conversion quality there. |
Registered Member
|
It might just be that a 256 level histogram is drawn to more than 256 pixels wide, causing the gaps in the drawing, even when there are none in the video?
|
Registered Member
|
Scaling the Histogram sadly (would be better than loosing color information ;)) does not create any gaps. They are caused by some RGB -> YUV or vice versa conversions. You can also right click in the Histogram and check "Unscaled" to make sure scaling is not the problem.
|
Moderator
|
@yellow Thanks :)
It seems you know the ffmpeg internals regarding color spaces quite well? At the moment I'm receiving RGB images from mlt. No filter was applied to the scope above. So I guess it is no stretching but simply the loss of information of the color space conversion. And yes, everything is working with 8bit at the moment. Unfortunately. Would be great with 32bit. The original footage is available here: http://kdenlive.org/video-editor/nikon-d90 Interesting is, though, that e.g. 8:17 shows no gaps, but 8:18 does. 8:21-23 neither. Can you confirm that? Because that is weird. Granjow |
Registered Member
|
I was thinking about the cause of the histogram gaps, and I think I found a very probable answer: it is the MPEG quantization.
If you get your hands on some uncompressed video, try that. (maybe here is something useful: ftp://ftp.crc.ca/crc/vqeg/TestSequences/) |
Registered Member
|
Recently got back from vacation, Granjow, just looking at the D90 files now.
Marko, I don't think it's mpeg quantization, I have a lot of HD HDV mpeg2 and HDSLR mpeg4 (h264AVC) and see no gaps in the histogram in other editors. But then this is mjpeg. **EDIT** Looked at the berries shot, did a Yxxx to RGB conversion using AVISynth and I wonder if changes have been made to the histogram scope as I see no gaps in the histogram using the latest kdenlive-svn build. So AVISynth and kdenlive-svn conversion to RGB look very close apart from the kdenlive histogram having a very combed appearance compared to AVISynth which I put down to 8bit rounding errors compared to 32bit in AVISynth and that the kdenlive RGB frame has half the unique colour information compared to AVISynth version. Both attached are frame 210[8:18] |
Registered Member
|
Yeah, I forgot that the MPEG quantization is done in frequency space, so it gets somewhat masked in the IDCT.
|
Registered Member
|
This morning I made a commit in mlt git to add certain swscale flags that removes the gaps or banding that we were seeing above. Please give it a test.
|
Registered users: Bing [Bot], Google [Bot], lockheed, Sogou [Bot]