ColorMatrix v2.3

[Wilbert]

@tritical,

So if you want to use hints on a telecined source, your only option is to use interlaced=true in ColorMatrix?

[foxyshadis]

The interlacing part kind of confused me. I always though colomatrix worked like levels, where every value mapped to only one output value, and neighboring pixels had no influence. I guess I'm wrong about that? It should only effect interlaced chroma differently if a pixel's vertical neighbors are taken into account.

[Wilbert]

The interlacing part kind of confused me. I always though colomatrix worked like levels, where every value mapped to only one output value, and neighboring pixels had no influence. I guess I'm wrong about that? It should only effect interlaced chroma differently if a pixel's vertical neighbors are taken into account.
Good that you mention Levels. I never thought about Levels in relation to interlaced stuff. I can't imagine it works correctly on an interlaced clip?

As for ColorMatrix
I always though colomatrix worked like levels, where every value mapped to only one output value, and neighboring pixels had no influence.
For YV12, the chroma is adjusted for 2x2 pixels. For interlaced stuff you need to pick different 2x2 pixels than for progressive stuff. (Internally, SeparateFields().stuff().Weave() is done when interlaced=true.)

[tritical]

So if you want to use hints on a telecined source, your only option is to use interlaced=true in ColorMatrix?
I'd say at the moment that would be the only save solution. i.e.

mpeg2source(info=3)
colormatrix(hints=true,interlaced=true)
otherstuff()

Or use an ivtc solution that wont mess with the hints. I'm not aware off hand of which could be guaranteed not to and under which circumstances they wouldn't. Though if you use a script such as:

mpeg2source(info=3)
ivtc()
colormatrix(hints=true)

and it doesn't complain about there not being hints then it should be fine.

@foxyshadis
As Wilbert said, the calculations require both luma/chroma to be considered together, so in interlaced YV12 the luma values that go with each set of chroma pixels is different for interlaced vs progressive.

[canuckerfan]

^If that's the case, to use the interlaced parameter for telecined material. Wouldn't the progressive frames be handled incorrectly?

[foxyshadis]

Ah, that makes sense then. Levels (and color/coloryuv) acts independantly on each channel, so I was confused. Thanks.

[tritical]

^If that's the case, to use the interlaced parameter for telecined material. Wouldn't the progressive frames be handled incorrectly?
They wont be handled as well as they could so to speak, but it wont really change much overall. It's a lot like using converttoyuy2(interlaced=true) on progressive YV12 material. The difference between that and using converttoyuy2(interlaced=false) on the same material isn't that great. However, using converttoyuy2(interlaced=false) on interlaced YV12 material will give quite a big difference vs using converttoyuy2(interlaced=true)... at least in areas of motion.

The reason is that when you use interlaced=true you're making luma lines 0/2 use chroma line 0, luma lines 1/3 use chroma line 1, etc... instead of making luma lines 0/1 use chroma line 0, luma lines 2/3 use chroma line 1, etc... as would happen with interlaced=false.

The difference between those two isn't going to matter much when used on progressive material since everything comes from the same point in time. However, with interlaced material where every other line could be from a different point in time the mixing of chroma from one field with luma from another (which happens with interlaced=false) can cause very visible artifacts.

Unless you have clips with changing colorimetry that you need to handle, I would recommend using:

mpeg2source("d2v.d2v")
ivtc()
colormatrix(d2v="d2v.d2v")

I've only seen a handful of clips with changing colorimetry, and most of those just had small sections at the beginning of pure black frames which had a different colorimetry than the rest of the clip. In those cases, where the difference doesn't really matter, I just change the first line or two of the d2v so that the colorimetry matches the rest of the clip.

[canuckerfan]

Thanks for the explanation, tritical. Btw, really appreciate all the hard work that's been put into TDeint and TIVTC. Here's hoping you'll have time in the future to continue the magic plugs.:thanks:

[Alain2]

Thanks for the very detailed answers, got it all now :D

[anne_so78]

I've noticed that the ColorMatrix filter makes the picture more yellowish. Although I like the warm tinge, I don't want anything distorting my videos. I'd like the encodes to stay as true to the original as possible (Encoding from VOB to x264 using meGUI). So, should I enable or disable the ColorMatrix filter? Thanks.

P.S- I've tried reading these pages but I couldn't figure out the ColorMatrix filter...

[Wilbert]

1) Does it produce different results as ColorMatrix1?

2) Post output of

Mpeg2Source(..., info=1)

What kind of colorimetry info does it give?

[anne_so78]

1) I don't know. I've used the ColorMatrix filter that comes in the latest version of meGUI.

2) When I add info=1 to the avisynth script I get an error, something like "No hints found"

I've looked at the log of meGUI but I couldn't find any colorimetry info...

[Wilbert]

Could you post your script?

[plugh]

colormatrix plugin is cool - fills a definite need.

I'm wondering if its conversions are strictly correct...

(please reference ISO/IEC 13818-2)
an mpeg2 stream includes an optional 'sequence display extension'
It is optional in that if not present, certain defaults are assumed.
This extension defines the following:
colour_description -- A flag which if set to ‘1’ indicates the presence of colour_primaries, transfer_characteristics and matrix_coefficients in the bitstream.

colour_primaries -- This 8-bit integer describes the chromaticity coordinates of the source primaries, and is defined in Table 6-7.

transfer_characteristics -- This 8-bit integer describes the opto-electronic transfer characteristic of the source picture, and is defined in Table 6-8.

matrix_coefficients -- This 8-bit integer describes the matrix coefficients used in deriving luminance and chrominance signals from the green, blue, and red primaries, and is defined in Table 6-9.
the colormatrix plugin focuses on Table 6-9
Table 6-9. Matrix Coefficients
0 (forbidden)
1 Recommendation ITU-R BT.709
E¢Y = 0,7154 E¢G + 0,0721 E¢B + 0,2125 E¢R
E¢PB = -0,386 E¢G + 0,500 E¢B -0,115 E¢R
E¢PR = -0,454 E¢G - 0,046 E¢B + 0,500 E¢R
2 Unspecified Video
Image characteristics are unknown.
3 reserved
4 FCC
E¢Y = 0,59 E¢G + 0,11 E¢B + 0,30 E¢R
E¢PB = -0,331 E¢G + 0,500 E¢B -0,169 E¢R
E¢PR = -0,421 E¢G - 0,079 E¢B + 0,500 E¢R
5 Recommendation ITU-R BT.470-2 System B, G
E¢Y = 0,587 E¢G + 0,114 E¢B + 0,299 E¢R
E¢PB = -0,331 E¢G + 0,500 E¢B -0,169 E¢R
E¢PR = -0,419 E¢G - 0,081 E¢B + 0,500 E¢R
6 SMPTE 170M
E¢Y = 0,587 E¢G + 0,114 E¢B + 0,299 E¢R
E¢PB = -0,331 E¢G + 0,500 E¢B -0,169 E¢R
E¢PR = -0,419 E¢G - 0,081 E¢B + 0,500 E¢R
7 SMPTE 240M (1987)
E¢Y = 0,701 E¢G + 0,087 E¢B + 0,212 E¢R
E¢PB = -0,384 E¢G + 0,500 E¢B -0,116 E¢R
E¢PR = -0,445 E¢G - 0,055 E¢B + 0,500 E¢R
but does it factor in the meaning of table 6-7?
Table 6-7. Colour Primaries
0 (forbidden)
1 Recommendation ITU-R BT.709
primary x y
green 0,300 0,600
blue 0,150 0,060
red 0,640 0,330
white D65 0,3127 0,3290
2 Unspecified Video
Image characteristics are unknown.
3 reserved
4 Recommendation ITU-R BT.470-2 System M
primary x y
green 0,21 0,71
blue 0,14 0,08
red 0,67 0,33
white C 0,310 0,316
5 Recommendation ITU-R BT.470-2 System B, G
primary x y
green 0,29 0,60
blue 0,15 0,06
red 0,64 0,33
white D65 0,313 0,329
6 SMPTE 170M
primary x y
green 0,310 0,595
blue 0,155 0,070
red 0,630 0,340
white D65 0,3127 0,3290
7 SMPTE 240M (1987)
primary x y
green 0,310 0,595
blue 0,155 0,070
red 0,630 0,340
white D65 0,3127 0,3291
Specifically, that the definition of R G and B used in the colorspace conversions also varies?

[Wilbert]

Table 6-7. Colour Primaries
(...)
Specifically, that the definition of R G and B used in the colorspace conversions also varies?
I have to admit i don't understand the concept of the colour primaries vary well. Apparently it has to do with how colors are perceive by people.

As I understand it, it is not the case that the definition of R, G and B in the different colorspaces conversions vary, but they differ for the different color systems. I mean you shouldn't get different R, G, B values given a color in the YCbCr format and given a colorspace conversion.

Here is some info about it:

http://www.ph.tn.tudelft.nl/Courses/FIP/noframes/fip-Color.html
http://en.wikipedia.org/wiki/Color_vision

Now, i don't understand how and when primaries come into play when displaying RGB stuff on your monitor. Perhaps you can change the primaries when calibrating your monitor?

[tritical]

The colour_primaries and transfer_characteristics values are for device dependent color space conversions... implying that you know the display device's chromaticity coordinates and transfer function. If you do, then you proceed as follows:

1.) convert yuv to gamma corrected rgb (R'G'B') using the matrix_coefficients values

2.) convert R'G'B' to linear rgb (RGB) using the inverse of the source transfer function

3.) convert RGB to CIE (device-independent) colorspace (XYZ coordinates) using the chromaticity coordinates of the source (colour_primaries)

4.) convert XYZ to RGB using the chromaticity coordinates of the display device

5.) convert RGB to R'G'B' using the display devices transfer function

When your device displays the new R'G'B' values it automatically performs the inverse of its own transfer function... so you should end up seeing exactly the same image as the source device captured.

This is based on my limited understanding anyways.

[acebrain]

1) I don't know. I've used the ColorMatrix filter that comes in the latest version of meGUI.

2) When I add info=1 to the avisynth script I get an error, something like "No hints found"

I've looked at the log of meGUI but I couldn't find any colorimetry info...

i am also getting the same error.

[tritical]

Could you post the script you're using?

Using hints pretty much requires that colormatrix comes immediately after mpeg2source() (though there are some filters that can be put inbetween).

EDIT: I overlooked the fact that for the second point it says "When I add info=1". dgdecode will only write hints into the video with info=3... info=1 just draws the info on the frames. So if you attempt to use info=1 with colormatrix(hints=true) then you will definitely get the "no hints found" error because there wont be any hints in the video.

[Renzz]

I've found a problem with using interlaced=true in 2.0 - it seems to change the field order.

If I use this script

loadplugin("C:\Video\dgindex\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\AutoGK\filters\ColorMatrix.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\leakKernelDeInt.dll")

mpeg2source("EastEnders (BBC 1 London) 2006-12-31 Sun 13.57-17.25-a.d2v",info=3)

info

ColorMatrix(hints=true,interlaced=true)

...rest of code.

the info output tells me it's Top Field First.

If I then move the info statement to after Colormatrix like this

loadplugin("C:\Video\dgindex\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\AutoGK\filters\ColorMatrix.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\leakKernelDeInt.dll")

mpeg2source("EastEnders (BBC 1 London) 2006-12-31 Sun 13.57-17.25-a.d2v",info=3)

ColorMatrix(hints=true,interlaced=true)

info


the output then tells me it's Bottom Field First.

Ok, so I can add a ComplementParity() after Colormatrix, but isn't this a bug?

[Boulder]

I don't think the field order actually changes. Just add AssumeTFF() after ColorMatrix and it'll be ok.

[tritical]

For interlaced mode colormatrix invokes AssumeFrameBased(), then SeparateFields(), does the processing, and then invokes Weave() on the output. Currently, AssumeFrameBased() resets the field order so that is why it's changing. I'll change it not to use assumeframebased() in the next version.

[tritical]

ColorMatrix v2.1 (http://bengal.missouri.edu/~kes25c/ColorMatrixv21.zip). Only 2 changes:

1.) When interlaced=true and the input is YV12, ColorMatrix will no longer invoke AssumeFrameBased(). If the input is fieldbased it will simpy throw an error and then the user can handle things however they want to.

2.) Added multithreading support (threads parameter).

[Jeremy Duncan]

The html document in the 2.1 version is corrupt and won't open.

[Alain2]

The html doc open fines here...

[Jeremy Duncan]

I still can't open it. I'm using I.E 7.

[Hans Ohlo]

you have to extract it first. i also had problems opening it from winrar.

[Jeremy Duncan]

I extracted it and I still got a error opening it.

[tritical]

Works fine me. Don't have I.E. 7, but tested with I.E. 6 and firefox on both of my computers. Colormatrix.htm should be 18699 bytes, crc of F6E98EA9. What error do you get when you try to open it?

[Jeremy Duncan]

I can open it now.

[Sharro]

If anybody is having trouble downloading with google I found out that:

http://web.missouri.edu/~kes25c/ColorMatrixv21.zip

Works.

:-)

All the best,

Sharro

[henryho_hk]

Can ColorMatrix derive the "interlaced" parameter from specified d2v file?

Search => http://forum.doom9.org/showpost.php?p=890791&postcount=246

[Wilbert]

No, it can't. Afaik you can't decide on basis of the d2v whether your clip is interlaced or progressive.

[Sharro]

No, it can't. Afaik you can't decide on basis of the d2v whether your clip is interlaced or progressive.

No, because the stream might not be progressive. And no, DGIndex cannot rely on the pogressive frame flag as it often lies.

Wilbert and neuron2 should be right :)

All the best,

Sharro

[12monkeys]

What should I set the interlaced parameter to if I am dealing with progressive encoded as interlaced?

[Guest]

That's controversial. I'm in the camp that says to treat it as progressive. My AutoYUY2() filter is interesting in this regard:

http://neuron2.net/autoyuy2/autoyuy2.html

[Jeremy Duncan]

If I calibrate my monitor to Rec.601, and use colormatrix to then convert the Rec.601 to Rec.709.
Will my monitor calibration transfer from Rec.601 to Rec.709 ?
So it's as if I calibrated my monitor to Rec.709 specifications ?

:confused:

[new7up]

all link bad, I can't downland it.can repair it?

[Guest]

Which link are you having trouble with?

[Jeremy Duncan]

If I calibrate my monitor to Rec.601, and use colormatrix to then convert the Rec.601 to Rec.709.
Will my monitor calibration transfer from Rec.601 to Rec.709 ?
So it's as if I calibrated my monitor to Rec.709 specifications ?

:confused:

What I do (I'm not sure this is the correct way), is calibrate my monitor to Rec.601 then use colormatrix. I tried to calibrate my monitor using Colormatrix and a Rec.601 calibration disk and I couldn't do it.

Colormatrix is a color upconverter. So I'm figuring it'll upconvert a monitor calibrated to Rec.601, to Rec.709 or HDTV standard.

So far I like the results.

Can somebody please confirm if my meathod is correct ?
Please. :)

[Jeremy Duncan]

Tritical, Your colormatrix.dll version 2.1 is broken.

Link (http://www.avsforum.com/avs-vb/showthread.php?t=570937&page=5&pp=30)

The 601 and 709 matrices only effect colors. Cb and Cr are equal to 128 when there is absence of color (black, white, gray, BTB, WTW). Both matrices will output the same RGB values when Cb and Cr are 128. Just look at the equations:

601
R = Y + 1.371(Cr - 128)
G = Y - 0.698(Cr - 128) - 0.336(Cb - 128)
B = Y + 1.732(Cb - 128)

709
R = Y + 1.54(Cr - 128)
G = Y - 0.459(Cr - 128) - 0.183(Cb - 128)
B = Y + 1.816(Cb - 128)

When Cb and Cr are 128, both equations become R = G = B = Y.

Ron

The BTB, and WTW changes with Colormatrix version 2.1
I've tested bt601tobt709.dll (http://rennfast.dns2go.com/Public/HTPC/ffdshow/avisynth/bt601tobt709.zip) and there was no change in BTB, WTW when I tested Rec.601, Rec.709

[tritical]

You can test for yourself using blankclip that colormatrix does not alter luma values when both chroma planes = 128, regardless of source/dest. Perhaps you have scaling=0 (which clips input and output to 16-235/16-240) when you actually want scaling = 1 or 2?

[Jeremy Duncan]

Tritical,

My Dell Notebook LCD cannot calibrate the Contrast as well as a expensive monitor, and the very light colored bars in the Getgray Caldisc contrast pattern are not visible unless I use FFDshow Levels.

So I set FFDshow levels and the very light Contrast color bars were visible.
I then lowered the Levels tweak, so that I could just barely see the lightest contrast bars.
I then set the Colormatrix version 2.1 into FFDshow's avisynth.
I set it to convert Rec.601, to Rec.709.

Now, I have the Levels set so that the contrast pattern is barely showing it's lightest white bars. And I have Colormatrix ready to use.
- I check the FFDshow Avisynth box and activate Colormatrix.
The lightest white bars Disappear !

I do the very same test with the other plugin I linked to, and the lightest white bars did not disappear.
Both plugins did change the rgb colors too.

So I don't know what test you did, but I saw it with my own eyes.
Maybe you better double check.

Edit. I'm only using this code;
ColorMatrix(mode="Rec.601->Rec.709")

[tritical]

I tested that using colormatrix on a black and white clip (both chroma planes = 128) is a nop, as it should be. However, if you set scaling = 0 (which is the default value) then the input and output luma values will be clipped to 16-235 range. This is probably why the lightest bars disappear. If you want to keep the full 0-255 range then use scaling=1 so that the clipping doesn't occur.

ColorMatrix(mode="Rec.601->Rec.709",scaling=1)

The scaling parameter is explained in the readme.

[Jeremy Duncan]

I tested that using colormatrix on a black and white clip (both chroma planes = 128) is a nop, as it should be. However, if you set scaling = 0 (which is the default value) then the input and output luma values will be clipped to 16-235 range. This is probably why the lightest bars disappear. If you want to keep the full 0-255 range then use scaling=1 so that the clipping doesn't occur.

ColorMatrix(mode="Rec.601->Rec.709",scaling=1)

The scaling parameter is explained in the readme.

That fixed the problem. Thank you very, very much Tritical. :)

[Sharro]

I tested that using colormatrix on a black and white clip (both chroma planes = 128) is a nop, as it should be. However, if you set scaling = 0 (which is the default value) then the input and output luma values will be clipped to 16-235 range. This is probably why the lightest bars disappear. If you want to keep the full 0-255 range then use scaling=1 so that the clipping doesn't occur.

ColorMatrix(mode="Rec.601->Rec.709",scaling=1)

The scaling parameter is explained in the readme.

Tritical is it my eyes tricking me on for no clipping + unscaled should be scaling=2 ?

From the readme:


o 2 - no pre/post clipping and unscaled coefficients

All the best,

Sharro

[tritical]

You're correct that scaling = 2 is needed for no clipping + unscaled coefficients... scaling = 1 also has no clipping but uses scaled coefficients. In his case the difference doesn't matter since he is using a greyscale clip and both will give the same result (the output will be exactly the same as the input). If it wasn't a black/white clip then he'd have to determine which one is actually correct based on the origin of the clip.

[Sharro]

I got it tritical...but now I got confused, I always do my D2V's with PC Scale which I is full range 0-255 and mostly I'm doing Rec709 to Xvid so Rec601 and should be full range also.

Should I always use scaling=2 ?

Thanks.

Sharro

[Wilbert]

I got it tritical...but now I got confused, I always do my D2V's with PC Scale which I is full range 0-255
The range is always [16,235] YCbCr. So that PC Scale setting doesn't do anything, unless you use dgvfapi (which converts it to RGB).

[HeadBangeR77]

I got it tritical...but now I got confused, I always do my D2V's with PC Scale which I is full range 0-255 and mostly I'm doing Rec709 to Xvid so Rec601 and should be full range also.

Should I always use scaling=2 ?

Thanks.

Sharro
I've done some sample encodes using colomatrix, and haven't spotted any difference between those 3 scaling settings, although I sould have, actually. :confused:

Does the fact, that so called PC-Scale is suggested in my every d2v project could have an ifluence on that?

@ Wilbert: I've just marked your post: so what's the point in choosing between PC and TV-scale while doing a d2v project with DGIndex?

[tritical]

Yes, the PC scale setting in dgindex is somewhat strange and is only used if dgdecode is delivering rgb (either by dgvfapi or upconv=2). With pc scale it converts yuv->RGB(0-255) with tv scale it converts yuv->RGB(16-235). The conversion routines in dgindex/dgdecode all assume yuv 16-235 range (i.e. they use scaled coefficients). However, dgindex/dgdecode never actually clamp values to that range (either on output or on input to the color conversion routines), which makes it similar to scaling=1 in colormatrix.

Should I always use scaling=2 ? If you are working with dvd footage then you should use scaling=0 or 1.

The thing to remember is that colormatrix simulates a yuv->rgb->yuv conversion. If you use scaling = 0 you are simulating yuv(16-235/16-240)->rgb(0-255)->yuv(16-235/16-240), where the yuv values are clamped before and after. With scaling = 2 you are simulating yuv(0-255)->rgb(0,255)->yuv(0-255). Scaling=1 is the same as 0 except that the yuv values aren't clamped to the 16-235/16-240 range before and after the conversion.