Problem with Histogram and RGB Parade

Hello,
I have one problem with scope: Histogram and RGB Parade. Every time when I added movie I had the same values of colour (RGB):
http://img51.imageshack.us/img51/34/testcolor.png
But when I've used RGB Parade from Effect List, then screen showed proper values of colour:
http://img855.imageshack.us/img855/2680/testparade.png
What I did wrong?

I checked this on my system:
Ubuntu 11.10 with Unity.
Notebook Dell Precision M4300

A checked on other system on Virtual BOX like: Xbuntu 11.10, Ubuntu 10.04 and it was the same.

best regards,
Andrew

I guess this is down to the implementation of the calculation of RGB values of the YCC source if that's what your source is? for example color matrix and legal vs extended range both of which can be chosen from the scopes / clip properties.

I only use the kdenlive scopes which I find ok except I think there is possibly an issue with the waveform. I'd trust kdenlives over the Frei0r effect personally.

What is the source and what from?

File soyurce come from here: http://kdenlive.org/users/granjow/introducing-color-scopes-histogram
There is Sample files for download.
I used files from my canon 550D too.

My Kdenlive is newest 8.2.1 from: ppa:sunab/kdenlive-release.

Then you have an added implication of the way the RGB conversion is done with regard to handling of the full range flag. Try Full Luma on in the clips properties and see if that changes comparison between effect and kdenlives own scopes.

But think this is probably a color matrix thing. Canon sources are BT601 where as the usual for a HD source is BT709 could be the effect does not offer a choice and assumes 709 on pixel count. Could check that settings are the same between effect and kdenlive scopes dialogues.

Not at my machine to check, i also have a 550D/T2i

I've changed various settings in Kdenlive> clip properties >Advanced and Force colorspace, Full Luma range and it doesn't help me in my problem.

Well, it is simple:

your image != rgb parade image

In the first case you have an rgb parade of your image
In the second case you have an rgb parade of an rgb parade

Thr rgb parade MONITOR shows a rgb parade of what is in the project monitor.

The rgb parade EFFECT replaces an image with its rgb parade (in the project monitor too)

haha, if so. That's what I get for looking at the images on an iphone, rather than PC screen. :-)

**EDIT**

Looking at the images now I remember why I rarely used the Frei0r scope effect, as they replace the image frame in the timeline meaning had to keep enabling and disabling and why it was great to see Granjows scopes. :-)

Also notice that your Canon Source is an AVI?

Yes I agree with you Marko, but problem is on first case. Where is bad RGB Parade and histogram in comparison to: http://kdenlive.org/users/granjow/introducing-color-scopes-histogram There Granjow used the same clip and he obtained different effect on scopes.
Second case showed RGB Parade effect which is proper. You shouldn't watch on scopes there, they are only for comparison.

This is not my source file, It is from Granjow blog. I used my file from Canon (mov) but I obtained the same effect. It doesn't matter what file I use.

Using RMB menu on the scopes window, try setting the auto refresh to on and advance a frame or two forwards and back to get the scopes to respond and see what happens. Maybe scopes are just not responding and updating, I find this sometimes.

As an aside I'd suggest that Granjows scopes for the Candlelight.avi are bad not yours, spiky luma. :-) Looks like wrong settings for that file or just a bad conversion, re levels compressed, if the candlelight file was off his Canon DSLR. The Candlelight file is mjpeg not h264. :-)

Thanks for response.
When I swich on auto refresh then value of Luma change. But colour red, green and yellow have the same values and look the same (the same shape on the scope). Could you check it on your Kdenlive?

Not at my machine to check unfortuneatly, but will later today. I'd suggest though that your scopes are working correctly, but what the RGB scopes show will be based on whatever colormatrix ie:luma 601 or 709, whether full luma has been set in clip properties but all that depends on knowing the correct settings to suit the source.

For your 'native' Canon 550D files non transcoded and that's important, you should set full luma in clip properties to all clips and use BT601 luma cooefficients in the various scopes ie:Colormatrix in order to get a 'correct' histogram and scopes for your native sources, you can confident on them then.

But I will look later and get back to you.

Thanks for advice.
Now, I've installed version 7.8 Kdenlive and turn out that scopes are correct :)
Maybe it is some bug with version 8.2.1 or MLT.
Let me know what about you.

Seems like you ran into this bug: http://www.kdenlive.org/mantis/view.php?id=2478 which is fixed now.

Granjow

Also, the Frei0r vectorscope uses the scale for the analog NTSC video, so it is a bit misleading.

I have a plan to fix this - keep the nice scale which looks great to an old engineer, but adjust the chroma formulas. Might take some time (not the work itself, but before I start...)

Yellow, how do you make proper rendering for clip when you set full luma? When I set full luma then picture is displayed proper (eg in highlight place) because luma is 0-255. When I render to file eg. x264, then high luma details are lose (probably because luma is cut to 16-235).

Well from tests I've done its a little tricky and I've got a blog post setup to explain in a little more detail but basically ffmpeg assigns a yuvj420p pixel format, notice tbe 'j' to our Canon sources because of a little bit of metadata in the canon MOV container header called the fullrange flag, but yuvj420 is not the 'correct' choice.

What happens when we try to encode to h264 or other codecs which ffmpeg assigns a yuv420p is it complains about incompatible pixel formats yuv420p versus yuvj420 and as a result scales luma into 16-235.

The solution that gives a smooth unaffected histogram and maintains levels giving us a 'lossless' round trip back to h264 is to switch off the full range flag by doing a quick remux with a special patched build of an opensource tool called MP4Box, importing the remuxed files which ffmpeg then reads as yuv420p because the flag is off but ffmpeg scales what it thinks is a 16-235 source so we override this with forcing ffmpeg to treat as full range and we get our round trip.

Forcing full range on the original Canon MOVs leads to reduction in quality evident in the histogram and waveform.

I can update with a link to MP4Box build and my blog later if of interest.

**EDIT**

I've explained a little what's going on in a blog post today. http://blendervse.wordpress.com/?p=768&preview=true

Yaa i also facing this problem so give the solid solution.
Snake and Dagger Jeans