ColorMatrix v2.3

[Wilbert]

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders, with the result that DivX/XviD clips or mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors (which looks like a small difference in brightness ). This can be checked by opening the mpeg2 stream directly in VDubMod. More info can be found in the readme.

This filter recalculates the yuv values assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (mpeg2 or mpeg4) is displayed correctly.

http://forum.doom9.org/showthread.php?s=&postid=514595#post514595

Changelog v2.3 (by tritical),

- Calculate conversion coefficients for PB/PR rows from luma coefficients
- Added inputFR and outputFR parameters allowing for YUV range expansion/contraction
- Changed the clamp parameter from bool to int to allow specifying only pre clipping or only post clipping or both


more info: http://forum.doom9.org/showthread.php?p=887227#post887227

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

[malkion]

Wilbert, if this filter does indeed perform as you intended it, I would like to express some gratitude for future encodes.... :D

Now should I run limiter() before or after colormatrix() ?

[Teegedeck]

I've waited for this a long time! If only I had time right now to try it out...

A heartfelt 'thank you'. :)

[Boulder]

Thanks, this one will be very useful!

[Wilbert]

Now should I run limiter() before or after colormatrix() ?
If you get v1.1, you don't need to use limiter at all (not before or after the filter). The filter clamps input to [16,235] (and output also).

[sh0dan]

Made a few (easy) speedups - it should be a couple of times faster now.

Updated source (http://83.90.202.89/kpo/colormatrix_faster.zip).

- Use float instead of double. They have enough precision and are much faster. It can however be changed back by changing the typedef in ColorMatrix.h

- Simpler algorithms.

- Use internal limiter for output also, instead of very slow if-then.

- Better rounding (adding 0.5 for more exact float to int conversion)

No SSE/MMX this tim, though. :)

[jorel]

:cool:
thank you very much Wilbert !

i was "stuck inside a cloud" here trying to find a way for that problems!
now our encodes will get much, much more quality !
:)
downloading and testing! :D

[Wilbert]

@Sh0dan,

Thanks! I updated the version.

[Inc]

Thanks a lot Wilbert !

:)

[jorel]

Originally posted by Wilbert
@Sh0dan,

Thanks! I updated the version.

of course....

thank you too Sh0dan.:cool:

.seems that we posted at the same time and i saw your post after my last!

:)

[Dark-Cracker]

very nice work :)
just by curiosity does it will harm the final output if u apply this filter on HDTV source or on some raw avi input ?

++

[Wilbert]

just by curiosity does it will harm the final output if u apply this filter on HDTV source
I got a few hdtv sources. Marjority of them uses mpeg2 coefficients (checked with the newest GSpot). So, you should also use the filter on those sources.

However, a few of them uses mpeg1 coefficients. You shouldn't apply the filter on those.

on some raw avi input
Here, you shouldn't use this filter. DivX/XviD assume mpeg1 coefficients when decoding to RGB.

edit: btw, hdtv is YUV [0,255] of course. So you need to use ColorYUV("PC->TV") first.

[FuPP]

I have a question about colormatrix and speed. I use colormatrix() 1.2 and get the following results

with colormatrix : 16.5 fps
without colormatrix : 44.5 fps

should such a difference be expected or is there any problem ?

My script (source is 720x576) :

LoadPlugin("D:\video\avsfilters\yv12\DGDecode.dll")
LoadPlugin("D:\video\avsfilters\yv12\colormatrix.dll")

mpeg2source("d:\test\test.d2v",idct=6)

trim(30000,33000)
colormatrix()

FuPP

[Wilbert]

The problem is that the filter is not optimized. Since I'm not a good coder, I don't know how to do that. I hope someone has some time to do that :)

[Manao]

I added other easy optimisations ( no more float computations, only integer one ). Results *should* be the same as those given by sh0dan's version. It should be almost twice as fast.

http://jourdan.madism.org/~manao/ColorMatrix.zip

[Wilbert]

Thanks! Could you also add the correct source files?

[Manao]

I copy'n'pasted the wrong files :p

You can download it again.

[Wilbert]

Thanks, I added it to the first post! I didn't have time to test it though :)

[FuPP]

with colormatrix : 34.5 fps
without colormatrix : 44.5 fps

Far better ! Thanks a lot Manao ! And thanks a lot Wilbert for that filter :)

FuPP

[ltc]

How to properly use this filter?
Say if I want to re-encode a DVD to DVD-R for TV playing. I assume I should use YUV and TV scale in DVD2AVI. I can find the original matrix coefficient with GSpot which has following type:

I709 = type 1 = MPEG2 default
FCC = type 4 = FCC standard
I470 = type 5 = MPEG1 default
S170 = type 6 = SMPTE 1700M standard
S240 = type 7 = SMPTE 240M standard

I have some DVDs which has S170 coefficient. Should I use ColorMatrix before converting to ConvertToYUY2 for CCE and ConvertToRGB24 for TMPGE?

Some of my encodes are brighter than original. Could it be because I accidentally used RGB PC scale?

[Wilbert]

You need to use it in case your source is: MPEG2 default or SMPTE 240M standard (both set of coefficients are approximately the same).

The other set of coefficients are approximately the same and equal to the MPEG1 coefficients.

It doesn't really matter what your target is. If you use VDub or AviSynth, these matrix coefficient info is lost, and mpeg1 coefficients will be assumed during playback (at least for DivX/XviD/TMPGEnc/QuEnc, not sure about CCE).

Should I use ColorMatrix before converting to ConvertToYUY2 for CCE and ConvertToRGB24 for TMPGE?
Yes. Just directly after loading the source.

Perhaps you can make an avs script, encode it to MPEG2 with CCE, and post the coefficients for me?

[ltc]

Hmn, interesting. The source DVD is NTSC interlaced. Color coefficient is S170 (SMPTE 170M) according to GSpot.
I re-encoded to D1/2 size using KSVCD template. Encoded with tmpgenc the result video has FCC coefficient. Encoded with CCE, no coefficient present.

script:
Mpeg2Source("D:\TietNhonQuy_DVD\TietNhonQuy_01.d2v")
ColorMatrix()
#
crop(8, 0, -32,0)
GripCrop(352, 480, source_anamorphic=false)
GripSize(resizer="LanczosResize")

dgbob(FOrder(),mode=1 )
convert60ito24p(2,0)
DegrainMedian(mode=1)

converttoyuy2()

# Detect field order
function FOrder(clip c) {
fo= GetParity(c)? 1:0
return fo
}

[Wilbert]

Encoded with CCE, no coefficient present.
That's interesting. It means if you are doing DVD -> DVD using AVS_YUY2 -> CCE, the same coefficients are used (in both cases the default MPEG2 coefficients). Thus, in this case, you shouldn't apply ColorMatrix.

[Wilbert]

I put up a new version (v1.4). Changelog:

* Added a mode parameter (default is mode="mpeg2->mpeg1" which gives the same output as older versions).

In case you captured something or you have a XviD/DivX (both are encoded mpeg1 coefficients), and you want to encode it to mpeg2 using CCE (which assumes mpeg2 coefficients):

ColorMatrix(clip, mode="mpeg1->mpeg2")

* Added rgb=true, which converts to RGB24 using mpeg2 coefficients.

The following converts a YV12/YUY2 stream to RGB24 using MPEG-2 coefficients (which might be useful if you want to convert DVD to mpeg2 using TMPGEnc):

ColorMatrix(clip, rgb=true)

It should give the same results as

ColorMatrix(clip, mode="mpeg1->mpeg2")
ConvertToRGB24()

[Boulder]

Is rgb=true the default in the new version? The filter was slower than usual with just ColorMatrix(), adding rgb=false fixed that.

I'd also like to clear some things up, is this the correct way:

1) DivX/XviD clip to MPEG-2 in CCE : ColorMatrix(mode="mpeg1->mpeg2")
2) MPEG-2 capture (no coeffs shown) to MPEG-2 in CCE : ColorMatrix()

[Wilbert]

Is rgb=true the default in the new version? The filter was slower than usual with just ColorMatrix(), adding rgb=false fixed that.
Default is rgb=false.

Btw, rgb=true is the same as

ConvertToRGB(matrix="rec709")

which should be faster. I didn't know that when adding that option :)

1) DivX/XviD clip to MPEG-2 in CCE : ColorMatrix(mode="mpeg1->mpeg2")
Yup.
2) MPEG-2 capture (no coeffs shown) to MPEG-2 in CCE : ColorMatrix()
That's a tricky one. Of course, your cap application (assuming it's just an analog cap) doesn't know which coefficients should be used. Since pal/ntsc standards always (should) use mpeg1 coefficients (ITU BT.601-4), you should use
ColorMatrix(mode="mpeg1->mpeg2")

[Boulder]

Thanks, that cleared things up:)

[Wilbert]

I put up a new version. In the previous ones, the used coefficients were slightly wrong. Although the difference is not noticable in practice :)

btw, I corrected the naming convention. MPEG-2 coefficients are called Rec.709 and MPEG-1 coefficients Rec.601. Thus

ColorMatrix(clip, mode="Rec.709->Rec.601") (default)
ColorMatrix(clip, mode="Rec.601->Rec.709")

I advice you to use the internal

ConvertToRGB(clip, matrix="Rec.709")

instead of

ColorMatrix(clip, rgb=true).

Output is identical (thx IanB), but the former is faster.

[North2Polaris]

@Wilbert,

I recently used your filter on a Mpeg2 to Xvid conversion using AviSynth and VDubMod. The difference, to my eyes at least, was remarkable. I have wondered why past encodes were "less bright" than I expected and needed to be adjusted.

I took a look at the AviSynth plugins that come with Gordian Knot. I did not see ColorMatrix among them, which surprised me given the discussion in the current thread and the following threads:

http://forum.doom9.org/showthread.php?s=&threadid=78220&perpage=20&pagenumber=3

http://forum.doom9.org/showthread.php?s=&threadid=81191

Does Gordian Knot handle this problem another way or not at all?

Thanks for your work on this! Happy New Year!

North

[Wilbert]

Does Gordian Knot handle this problem another way or not at all?
No. Perhaps len0x is not aware of the problem. Did you ask him about this?

[North2Polaris]

Originally posted by Wilbert
No. Perhaps len0x is not aware of the problem. Did you ask him about this?

@Wilbert,

I just sent a PM to len0x about this.

I tried using LumaFilter in DGDecode to adjust the "brightness".

From DGDecode html,

Useful additional YV12 Filters :

To Darken Luminosity.

LumaFilter(-10,0.9)

To Ligthen Luminosity.

LumaFilter(+10,1.1)

Will lightening luminosity address the brightness problem addressed by ColorMatrix or just "cover it up"?

North

[Boulder]

The original problem is not actually the brightness, it's that the colors are off slightly.

[len0x]

Hm... Am I right in understanding that every DVD source needs to be converted to a proper color matrix before encoding into MPEG4?

*Edit* remark about RGB removed

[Wilbert]

Hm... Am I right in understanding that every DVD source needs to be converted to a proper color matrix before encoding into MPEG4?
Yup, well "to the same color matrix" as MPEG4 uses/assumes (Rec.601 coefficients).

[North2Polaris]

Originally posted by Boulder
The original problem is not actually the brightness, it's that the colors are off slightly.

@Boulder,

Thanks. When you don't know that the underlying problem is a color problem, it looks like a problem with brightness, which can lead to unsatisfactory attempts to correct it.

North

[len0x]

Originally posted by Wilbert
Yup, well "to the same color matrix" as MPEG4 uses/assumes (Rec.601 coefficients).

Bummer - now I have a dilemma since speed loss is at least 10% when doing correction so it might not be a good idea to make it default in GK/AGK...

Btw, do you have XML description of the filter? (I can add it to GK then)

[Wilbert]

Bummer - now I have a dilemma since speed loss is at least 10% when doing correction so it might not be a good idea to make it default in GK/AGK...
I wish I could do MMX :)

Btw, do you have XML description of the filter? (I can add it to GK then)
Not yet. I will do it this week and send you a pm.

[len0x]

Originally posted by Wilbert
Not yet. I will do it this week and send you a pm.

cheers

[Steve56]

ColorMatrix does virtually the same as BT709ToBT601 from http://mywebpages.comcast.net/trbarry/downloads.htm, or?

Steve56

[Wilbert]

I corrected the url above :)

Yes that's true, I noticed that too late. His plugin contains optimization code, so it might be faster. (btw, hdtv isn't always Rec.709 as suggested in his docs ...)

[Steve56]

Yes that's true, I noticed that too late. His plugin contains optimization code, so it might be faster. (btw, hdtv isn't always Rec.709 as suggested in his docs ...) [/B]ah, good to know ;-) I did now try to check with GSpot, if a certain MPEG-2 HDTV 1080i stream (Astra 1080 Konzert1), is encodet with the BT709 or BT601 matrix. But I don't know where to read this information from?!

Steve56

[Boulder]

Open the clip in GSpot v2.52b01.

[Wilbert]

1) That info is also available in 'DGMPEGDec 1.0.13 beta 11'. Using


mpeg2source(info=true)

2) Use latest beta of GSpot and look in the upper right corner. In the video section, the five boxes next to NVOP. The fives boxes are from left to right:

1) I709 (= Rec.709 coefficients)
2) FCC (almost the same as Rec.601)
3) I470 (= Rec.601 coefficients [an updated version of Rec.470-6, but coefficients are exactly the same])
4) S170 (= SMPTE 170M; exactly the same as Rec.601)
5) S240 (= SMPTE 240M; almost the same as Rec.709)

see table 6-9 page 56 of http://le-hacker.org/hacks/mpeg-drafts/is138182.pdf

If the boxes remain "black" then the used coefficients are not present in the header, and the default (which is Rec.709) should be assumed.

I hope it's clear now :)

[Steve56]

Wilbert: Thanks for the comprehensive answer!

Before that, I just did a color conversion judged by the look of it, when turned on or off. ;-)

[tritical]

Wilbert, is the source included in the zip linked to at the beginning of this thread the latest? I tried doing some simple optimization and got it running about 40% faster (about 210fps vs 145fps in YV12 on my comp) still with plain c code, but I'm wondering about a few things looking through it... in the constructor it checks mode against "Rec.709->Rec.601" and "Rec.601->Rec.709", yet in the main part it checks mode against "mpeg2->mpeg1" is this intended? In the YV12 mpeg1->mpeg2 it uses the "21" conversions and not the "12" conversions, but in the YUY2 code the mpeg1->mpeg2 does use the "12" conversions? Also, could you tell me or point me to a source that has the numbers for how the coefficients used were derived? I'm just curious, I tried to calculate them myself using coefficients from a few different websites, but they never work out to be exactly the same (usually off by 20-40 after multiplying by 65536). Thanks in advance.

Hm, must be because:

mpeg2source()
clip1 = last.colormatrix(mode="rec.601->rec.709")
clip2 = last.colormatrix(mode="rec.709->rec.601")
subtract(clip1,clip2)
coloryuv(analyze=true)

shows both clips to be identical :confused:.

[Wilbert]

in the constructor it checks mode against "Rec.709->Rec.601" and "Rec.601->Rec.709", yet in the main part it checks mode against "mpeg2->mpeg1" is this intended? In the YV12 mpeg1->mpeg2 it uses the "21" conversions and not the "12" conversions, but in the YUY2 code the mpeg1->mpeg2 does use the "12" conversions?
I corrected all that (v1.6). Thx very much. It's a bit stupid that I didn't notice this :confused:

Also, could you tell me or point me to a source that has the numbers for how the coefficients used were derived? I'm just curious, I tried to calculate them myself using coefficients from a few different websites, but they never work out to be exactly the same (usually off by 20-40 after multiplying by 65536).
I included a text file (coefficients.txt) which contains all calculations (if you know maple i can send you the worksheet). I hope that's clear enough.

Btw, some websites use slightly different coefficients, perhaps that could be the problem.

I tried doing some simple optimization and got it running about 40% faster (about 210fps vs 145fps in YV12 on my comp) still with plain c code
Great! Could you add those changes to v1.6?

[North2Polaris]

Originally posted by Wilbert
Yes that's true, I noticed that too late. His plugin contains optimization code, so it might be faster. (btw, hdtv isn't always Rec.709 as suggested in his docs ...)

@Wilbert,

Other than speed, any advantage to using ColorMatrix over BT709ToBT601?

North

[Wilbert]

Other than speed, any advantage to using ColorMatrix over BT709ToBT601?
Rec.601->Rec.709 conversion (useful for capping -> mpeg2) is possible in ColorMatrix :)

[Boulder]

Originally posted by Wilbert
Rec.601->Rec.709 conversion (useful for capping -> mpeg2) is possible in ColorMatrix :)
However, if you use CCE for encoding, no need to use ColorMatrix as it doesn't specify any coefficients for the encoded file for some reason?

[Wilbert]

However, if you use CCE for encoding, no need to use ColorMatrix as it doesn't specify any coefficients for the encoded file for some reason?
Only if you use CCE :) Remember pal/ntsc uses Rec.601 coefficients. TMPGEnc/QuEnc add fcc (approx Rec.709) coefficients to the mpeg-2 header.

[tritical]

I included a text file (coefficients.txt) which contains all calculations (if you know maple i can send you the worksheet). I hope that's clear enough.
That was exactly what I was looking for :), thanks.

Great! Could you add those changes to v1.6?
Yep, here: [link removed]... most the changes required rearranging things a good bit. You can just skim through it and see if you want to use anything from it. I also made mmx routines for the YV12 conversions (mainly stolen from tom's filter, with some minor changes). On my system the YV12 c code runs around 210-220fps, the mmx versions average somewhere around 350fps). However, due to rounding differences, the mmx and c output are not exactly the same. The maximum difference on the Y plane is +-2 and for UV its +-1. I included an mmx parameter to disable using mmx if you want to though (mmx=false).

[Wilbert]

Great! I updated the first post. Thanks very much :)

[Didée]

However, due to rounding differences, the mmx and c output are not exactly the same. The maximum difference on the Y plane is +-2 and for UV its +-1.[/B]
So, which one is closer to the "exact" value? With the actual performance the filter has reached by now, I don't care for the remaining speed difference (you know my scripts ;) ) - but the value differences could be of importance (ask jorel ... BTW, what happened to him?)

edit: forgot to say: Great work, thank you!

[Wilbert]

So, which one is closer to the "exact" value? With the actual performance the filter has reached by now, I don't care for the remaining speed difference
The c output, thus ColorMatrix(..., mmx=false).

[Dhampir]

I've done a screenshot using mmx and without mmx and I can't spot any difference between using mmx and not using mmx. Are the rounding errors just insignificant? Here are two screenshots.

MMX=false

http://img135.exs.cx/img135/9051/mmxfalse2aq.png

MMX

http://img141.exs.cx/img141/3314/mmxtrue3mj.png

[Wilbert]

The maximum difference on the Y plane is +-2 and for UV its +-1.
The difference is minor, you won't see it by visual inspection :)

[len0x]

Can this filter safely be used after resizing (for speed reasons) or better to put it before?

[len0x]

I just grabbed a bunch of DVDs I have at hand and actually only 50% of them are using default mpeg2 coefficients. There are considerable number of them that uses s170 and i470. Also I had one that uses FCC. So I guess its no good to just apply this filter to any DVD you have.

P.S. Is it possible to write a filter that returns coefficient type, so that conditional usage of ColorMatrix is possible?

[Didée]

Originally posted by Wilbert
The difference is minor, you won't see it by visual inspection :) OOOoooohh. Yes you will.

interleave(last.colormatrix(mmx=false),last.colormatrix(mmx=true))

Step back and forth, and tell me you see no difference. :)


edited stupidity ... grrr!

[tritical]

What about having dgdecode set a global variable colormatrix could read? To make it multi instance compatible the name would need to depend on the d2v file, so colormatrix would need the name of the d2v file as input as well. Good or bad idea?

Wouldn't it be:

interleave(last.colormatrix(mmx=false),last.colormatrix(mmx=true))

for Wilbert's point :confused:.

[Didée]

Originally posted by tritical
Wouldn't it be: Yes of course. Didn't have my brain with me. Corrected.

[Wilbert]

What about having dgdecode set a global variable colormatrix could read? To make it multi instance compatible the name would need to depend on the d2v file, so colormatrix would need the name of the d2v file as input as well. Good or bad idea?
Something like this should be possible. I will ask Neuron2 about it.

Can this filter safely be used after resizing (for speed reasons) or better to put it before?
Doesn't matter.

[jp80]

Hi,

I would like to use matrixcolor in Gordian Knot to encode an interlaced PAL DVD source to xvid. In order to do so I was told by len0x that I had to add this filter at the end of the AVS script. But as I'm a total newbie in modifying avs script with a filter in GK, could somebody please tell me exactly how to do all of those required steps :

-Which avs script should I modify, is it LastCompCheck.avs located at the GK root folder, or the one created after having set up the encoding options for a d2v file in GK? If it's the 2nd case, then at which moment could I do so? Because to me it seems GK starts the encoding as soon as the the customized avs is created?
-What do I need to write for colormatrix in the avs file, knowing that I want to output a 672x496 xvid from a interlaced PAL DVD ? For instance in this case, is it correct to write this?:

----------------------------------------------------------
LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\ColorMatrix\ColorMatrix.dll")
clip(width=720,height=576,pixel_type="YUY2",color_yuv=$954080).ConvertToYV12
ColorMatrix("Rec.709->Rec.601",mmx=false)
ColorMatrix("Rec.601->Rec.709",mmx=false)
ColorYUV(analyze=true)
-----------------------------------------------------------

And about the line "clip(width=720,height=576,pixel_type="YUY2",color_yuv=$954080).", should the width and height match the size of the input file, thus should I write width=720,height=480 for a PAL source? And does the name of "clip" matter and should have the same one as an intermediate file possibly created in the GK encoding process?

[gte024h]

Quick question:

If I am doing no colorspace conversions in my workflow (maintaining YV12 throughout) should I be using ColorMatrix?

From the readme, and the discussions here, it seems that the original MPEG2 source (DVD, DVB, etc.) should have one of many possible coefficient matrices declared in it's header and if not, Rec.709 is to be assumed. The problem is that the decoder (Divx or Xvid) assumes Rec.601. Would it be possible to just copy the flags in the source header into the output header (assuming there are no colorspace conversions in between), then hope that the decoder will honor those flags?

BTW, great work on this filter, thanks!

[Dark-Cracker]

@Wilbert

could you please let us know when DGindex will add a flag in the header of the .d2v file and when to apply colormatrix for the given flag :)

keep up the good work.

Bye.

[len0x]

Its not gonna be a flag, its gonna be a hint that ColorMatrix has to take advantage of (but that will work only for progressive sources).

@jp80

You complicate things a lot. I'm gonna reply to you in GK forum...

[Wilbert]

If I am doing no colorspace conversions in my workflow (maintaining YV12 throughout) should I be using ColorMatrix?

From the readme, and the discussions here, it seems that the original MPEG2 source (DVD, DVB, etc.) should have one of many possible coefficient matrices declared in it's header and if not, Rec.709 is to be assumed. The problem is that the decoder (Divx or Xvid) assumes Rec.601.
I think you gave the answer yourself here. If it's not clear you should propose specific examples, and then i will tell you if you should use it.

Would it be possible to just copy the flags in the source header into the output header (assuming there are no colorspace conversions in between), then hope that the decoder will honor those flags?
If you open your source mpeg2/avi directly in the encoder (application), then yes it should be possible to do this (i guess, but i'm not a coder). If you use AviSynth/dvdavi/vfapi/whatever in between then the frameserver should somehow preserve this info. We are working on this (see response of len0x).

[Dark-Cracker]

ok if colormatrix can find to enable it or not it's perfect i was thinking that a new field (somethink like matrix=709 will be added in the .d2v) thak you len0x for the answer :)

i will stay tuned :)

Bye.

[jp80]

Err did I do something wrong in my post, because I feel like everybody's ignoring it?

[Boulder]

jp80,

len0x told you that he will answer your question in the GKnot forum.

[jp80]

Oh ok sorry I didn't see his reply.

[len0x]

When comparing mmx=true vs false - it seems to me that mmx implementation always makes image darker. I wonder if rounding errors can be directed to make image lighter instead? (coz main usage of this filter will be to correct darker pictures). Mmx implentation is about 10% faster than C in my testing environment (i.e. overall speed of a script is considered), so its more attractive to use it, but not at a cost of still having darker image.

[Guest]

@Wilbert

DGMPGDec 1.2.0 RC1 hints the colorimetry now. Refer to the Decomb source code for utilities.c for reading the hints. Use FieldDeinterlace() as your model. The colorimetry field is now bits 2-4 inclusive (zero-based). Here is the new header file:

bool PutHintingData(unsigned char *video, unsigned int hint);
bool GetHintingData(unsigned char *video, unsigned int *hint);

#define HINT_INVALID 0x80000000
#define PROGRESSIVE 0x00000001
#define IN_PATTERN 0x00000002
#define COLORIMETRY 0x0000001C
#define COLORIMETRY_SHIFT 2
@Dark-Cracker

If you open the D2V in DGDecode(...,info=1), you can see the colorimetry type displayed.

[tritical]

When comparing mmx=true vs false - it seems to me that mmx implementation always makes image darker. I wonder if rounding errors can be directed to make image lighter instead? (coz main usage of this filter will be to correct darker pictures).
Yes, this is possible. Adding a small adjustment factor to the pixel values before multiplying would shift the resulting output upwards.

[Dark-Cracker]

@neuron2
thank u for the answer. but the result will be hard to catch for an external sofware.

@wilbert
do you think it's possible to made colormatrix to work like :
1) detect if it need to apply the matrix convertion
2) if the conversion is needed apply it
3) if the conversion is not needed only apply the "limiter()" function.

this could allow to always add the colormatrix in the avisynth script without problems.

++

[Guest]

Originally posted by Dark-Cracker
but the result will be hard to catch for an external sofware. Umm, what do you want, a telegram? :p

I output the info screen, the debug output, and hints. What else can I do?

[Dark-Cracker]

@neuron2
:) lol :) in fact i have to rewrite my previous msg :)

but the result will be hard to catch for an external vb6 sofware. :)

we have enough way to get the infos but in vb there is some limitations it's for that i have say there is no *easy* way to retrieve the info (for exemple somethink like a flag when you read the .d2v header).

but i am sure wilbert will come with an automatic solution and i will could add .colormatrix() in each my script and the filter will (like a big boy) speak with .dgdecode() and decid or not to apply the convertion.

and more :) this could avoid me to have to catch the debugoutputstring (note to myself : "i realize i am a lazzy guy").

++

[Guest]

Glad you have a sense of humor...

A header line in the D2V won't do because it can change during the stream. It gets yucky to start including more dynamic stuff in the D2V.

I'm sure Wilbert will do it because he is the guy that asked me to add hinting. :D

[Dark-Cracker]

i have a good sense of humor but english is not my mother tonge and my jokes often turn into somethink ...hum not really funny so i prevent myself to made a lot of jokes in this forum :)

i was not thinking the matrix info could change during the stream but i think this could made sense when there is advertisments or trailers at the strart/middle of the video stream.

to sumup all my hopes are in wilbert :)

++

[tritical]

Well, I've been debating putting this up since I don't know if Wilbert is planning to release a new version soon, but I'll just put it up temporarily for those interested in testing. [link removed]. I changed the mmx routines so the rounding is almost a 100% match with the c routine, the difference is now truely indistinguishable. It is slightly slower due to the needed changes but not much, and it seemed like matching the c output was more important.

It also includes experimental support for reading dgdecode hints and an internal interlaced mode so hints are supported for that as well. Extra parameters are: bool debug, bool hints, bool interlaced (defaults: false, true, false). When reading hints, if hints are found then the conversion is only applied when needed... i.e. if you specify mode="rec.709->rec.601" and hints indicate its already rec.601 it doesn't apply the conversion. If no hints are found in the stream, it acts as if hints=false and always applys the conversion. You can use debug=true to check that it is finding the hints.

[Guest]

Cool, tritical. Just wanted to remind people that they need DGMPGDec 1.2.0 RC2 and that they need to have info=2 on the MPEG2Source() invocation to generate the hints.

The interlaced/progressive hint just follows the pf bit, so if a frame is pulled down, it may not be accurate. I'm not sure how useful that hint is in a following filter. In Decomb it means something else.

[Guest]

Oops, info=3 is required to output hints.

[tritical]

Yep, I was wondering about the useability of the progressive/interlaced hint from dgdecode if the stream has rff flags. Anyways, the version I put up doesn't check that bit atm (just the colorimetry)... so the interlaced setting needs to be set manually. In fact, whether or not the stream is interlaced only matters for yv12... if the input is yuy2 then it doesn't make a difference and interlaced can be set to false regardless.

[Wilbert]

Well, I've been debating putting this up since I don't know if Wilbert is planning to release a new version soon, but I'll just put it up temporarily for those interested in testing.
Cool thanks! I was away this weekend, and the server was down yesterday evening, so I couldn't look at it :)

so the interlaced setting needs to be set manually.
That's fine. I prefer to use it if the video has combing (which needn't be the case for interlaced material, you know this progressive encoded as interlaced stuff ...).

[len0x]

Great! Will try that one asap :) (not that I need hints, but more accurate mmx routine is always welcomed)

[len0x]

@tritical

I've done some tests and your new version seems to be faster when not using MMX comparing to the official 1.7. Did you change anything in C code?

[Wilbert]

@tritical


Mpeg2source("F:\TestStreams\avs\AguileraGrammies.d2v",info=3) # Rec.709
ColorMatrix(debug=true)


doesn't show any text, although I used dgmpgdec120rc2.zip and

Mpeg2source("F:\TestStreams\avs\AguileraGrammies.d2v",info=1)

gives Rec.709, and although the Rec.709->Rec.601 conversion is done :confused:

[tritical]

Hm, should have said it was the simple/plain kind of debug output, via OutputDebugString(). It doesn't write any text on the frames or anything fancy. The OutputDebugString output is working for me here, if its not working for you not sure what's up.

gives Rec.709, and although the Rec.709->Rec.601 conversion is done
Hm, not sure what your getting at :confused:.

I've done some tests and your new version seems to be faster when not using MMX comparing to the official 1.7. Did you change anything in C code?

That's interesting cause its a straight copy of the 1.7 source. It should in fact be a little slower if you don't set hints=false cause it will spend a little time checking for hints. May be just compiler differences :confused:.

[EpheMeroN]

I am quite scrambled in the brain when it comes to fully understanding this awesome ColorMatrix Plugin. I read all the posts twice now. Can someone clear it all up for me please?

I have an XviD that came from an HDTV Source. I want to re-encode it to DVD. The GSpot Beta doesn't tell me what coefficients are used. Below is the script I'm working on. I'd appreciate it if someone could tell me if it's correct, and if it needs some changes :-) .

Video = Trim(AVISource("C:\Documents and Settings\Blank\Desktop\savages.avi"),0,1433).FadeIn(25).FadeOut(12)
Blank = BlankClip(Video).Trim(0,59).Amplify(0.0)
AlignedSplice(Blank,Video,Blank)

EnsureVBRMP3Sync()
BlindPP()
ColorYUV(Levels="PC->TV")
ColorMatrix(mode="Rec.709->Rec.601")
LimitedSharpen()
LanczosResize(720,480)
UnDot()

Here's a sample of the video as well:
http://users.adelphia.net/~l337/hdtv-xvid-sample.avi

[Wilbert]

Hm, should have said it was the simple/plain kind of debug output, via OutputDebugString(). It doesn't write any text on the frames or anything fancy. The OutputDebugString output is working for me here, if its not working for you not sure what's up.
Ah, that explains why i didn't see anything. I will check if it's working for me.


I have an XviD that came from an HDTV Source. I want to re-encode it to DVD. The GSpot Beta doesn't tell me what coefficients are used. Below is the script I'm working on. I'd appreciate it if someone could tell me if it's correct, and if it needs some changes :-) .
1) Do you still have the hdtv source?

2) What encoder do you use to make this dvd?

[EpheMeroN]

1) Do you still have the hdtv source?
No I do not. It was a clip of something that a friend send me.

2) What encoder do you use to make this dvd?
Well, I have not encoded it entirely yet. I've only run a 1-pass test in QuEnc. I also have CCE.

Did my avi sample provide any help at all in determining the coefficients?

[Wilbert]

Did my avi sample provide any help at all in determining the coefficients?
No, your avi assumed Rec.601 during decoding (which is always the case). These are or aren't the same coefficients as used in your hdtv source. You need the hdtv source to check that.

QuEnc -> fcc coefficients ~ Rec.601 coefficients, CCE -> nothing = Rec.709 coefficients.

So assuming Rec.601 are the correct coefficients for your avi:

1) QuEnc: don't need to use ColorMatrix
2) CCE: ColorMatrix(mode="Rec.601->Rec.709")

I hope it's a bit clear :)

[len0x]

Originally posted by tritical
That's interesting cause its a straight copy of the 1.7 source. It should in fact be a little slower if you don't set hints=false cause it will spend a little time checking for hints. May be just compiler differences :confused:.

When hints=true it is a LOT slower (overall time is ~15-20% more). But I was testing hints=false for that reason. Anyway I like your compiler much more than Wilbert's now :)

[tritical]

When hints=true it is a LOT slower (overall time is ~15-20% more). I noticed that as well, but couldn't find anything obviously wrong. It shouldn't be having that much of an effect... I'm gonna look in to it tonight sometime.

However, since the d2v now has the colorimetry info, it might make since for colormatrix to have a d2v="" option and to be able to get the info from there instead. That would be faster and the filter could be placed anywhere in the filter chain. That's assuming the colorimetry is the same throughout the clip.

[EpheMeroN]

So, if I encode this XviD AVI to MPEG-2 via CCE, will I still have to use ColorYUV(Levels="PC->TV") to squish the color range to 16-235? Or does ColorMatrix do this automatically?

[Wilbert]

However, since the d2v now has the colorimetry info, it might make since for colormatrix to have a d2v="" option and to be able to get the info from there instead. That would be faster and the filter could be placed anywhere in the filter chain. That's assuming the colorimetry is the same throughout the clip.
That's a good idea.

A small request though :) I think it's a good idea if hints=true gives an error when there are no hints. In case the user is using a wrong dvd2avi/mpeg2dec3 version without knowning or realizing that.

[Wilbert]

So, if I encode this XviD AVI to MPEG-2 via CCE, will I still have to use ColorYUV(Levels="PC->TV") to squish the color range to 16-235?
Your XviD is already [16,235]. (btw ColorMatrix *clamps* the luma range to [16,235])

[EpheMeroN]

Your XviD is already [16,235].
Really? I always was to believe all DivX / XviD AVI files were encoded at 0-255. Interesting...

[tritical]

Updated the zip file linked to in my earlier post. Changes include: hints now defaults to false, it throws an error when no hints are detected in the stream when using hints=true, debug output was expanded, added d2v="" option to read the colorimetry info from a d2v file (you can't use both d2v and hints at the same time, only one or the other), if the d2v has multiple types of colorimetry info then it throws an error and on d2v's that have no colorimetry or are not dgindex project files v07 or higher it throws an error. Quick example:

colormatrix(d2v="myd2v.d2v")

[fewtch]

Uggh, I can't stand the look of this filter's output... seems as though black levels are messed up, or something (maybe that looks good on a TV set, but IMO not a PC monitor). Instead, I add something like this if movies look too dark:

Tweak(0.0,1.0,10.0)

Does the trick for me every time.

Edit --

Originally posted by Wilbert
(btw ColorMatrix *clamps* the luma range to [16,235])
Well, no wonder. I hope everyone examines this more limited luma range to see if they like it, because personally I hate it. Would much rather just boost brightness overall. Looks fine to my eyes on a TV set too (probably the DVP-642 automatically performs this luma clamping, and assuming almost any hardware player would do so).

P.S. if Colormatrix filter always clamps to TV standards, how is this "correcting" any picture? If unnecessary, reducing a dynamic range is not an error correction -- rather, it's introducing error. I wouldn't highpass my music files at 80Hz and lowpass at 16KHz without any reason, so why this?

[Wilbert]

@tritical,

Great! Thank you very much!

P.S. if Colormatrix filter always clamps to TV standards, how is this "correcting" any picture? If unnecessary, reducing a dynamic range is not an error correction -- rather, it's introducing error.
Relax man. I will add a pc_range=true option for you. You do understand i needed to clamp it when people are feeding it [16,235] YUV video (and most of them do). If you convert it to DivX/XviD/MPEG it needs to be [16,235] anyhow.

[yaz]

Originally posted by Wilbert
You do understand i needed to clamp it when people are feeding it [16,235] YUV video (and most of them do).would u, pls, make it clear! say, how do u know what ppl feed into cm ? (e.g. i always feed the cropped stream which is never(!) tv scale) & how do u make that 'clamping'? is it a kinda rescaling (as were made w/coloryuv) or just dropping simply the outer range?Originally posted by Wilbert
If you convert it to DivX/XviD/MPEG it needs to be [16,235] anyhow. why should it be ? and what if the input is not tv-scale ?

thx
y

[Wilbert]

would u, pls, make it clear! say, how do u know what ppl feed into cm ? (e.g. i always feed the cropped stream which is never(!) tv scale) & how do u make that 'clamping'? is it a kinda rescaling (as were made w/coloryuv) or just dropping simply the outer range?
Dropping outer range.

why should it be ? and what if the input is not tv-scale ?
It should be possible to make mpeg with luma range [0,255]-YUV. But during playback the luma range will be clamped before decoding to RGB when displaying it on a RGB monitor. When encoding to DivX/XviD the luma range will be clamped to [16,235]-YUV (by the codec itself).

(e.g. i always feed the cropped stream which is never(!) tv scale)
Such as?

[yaz]

Originally posted by Wilbert
Dropping outer range.bad news. that messes my later yuv manipulations :-( would u, pls, make it explicit in the 'readme'.Originally posted by Wilbert
It should be possible to make mpeg with luma range [0,255]-YUV. But during playback the luma range will be clamped before decoding to RGB when displaying it on a RGB monitor. When encoding to DivX/XviD the luma range will be clamped to [16,235]-YUV (by the codec itself). still can't get it. who will clamp ? the encoder or the decoder ? or both ? or neither ?
so, u state that my finely y(uv)-balanced clips are 'blindly' clamped by xvid ? ooouch ... i must check it ...Originally posted by Wilbert
Such as? i always (try to) tune my clips w/coloryuv so as to get a 'bearable' y-scale cus my eyes can't stand if white is 'too white' and if black is 'too black'(of course, it's not the color but the luma) it means a quite arbitrary y-scaling fitting to my taste but it's never 16-234 but rather sg round 8-247.

thx
y

[AsTimeGoesBy]

First, thanks for colormatrix filter!
But about that color range issue, i'm also a bit confused now...

Some basic questions to make understanding the posts here:

1) The PC is using a luma range from 0 to 255 - or let us say a scale with 256 steps. Now all that issue here is caused because the common TV is only using the steps 16 to 235 on that scale? So a TV has less steps/values to 'express' a certain luma level?

2) A DVD content (optimized for TV) has to be expanded for use on PC, but during encoding to Xvid/DivX it will be reduced again on lower TV range of 220 steps/values?

3) A decoder on PC expands/increases the smaller TV range (stroed in Xvid/DivX) to bigger PC luma range?

[Wilbert]

bad news. that messes my later yuv manipulations :-( would u, pls, make it explicit in the 'readme'.
Ok, i will. I will also add a pc_range=true (as i said) which leaves the luma range untouched.

still can't get it. who will clamp ? the encoder or the decoder ? or both ? or neither ?
For XviD/DivX it's the encoder, and for MPEG2/MPEG1 the decoder IF you request RGB from it (it clamps before converting to RGB).

Just make a Y=0,U=128,V=128 clip with AviSynth and convert it to XviD/MPEG. Open your encodings in AviSynth to check it with ColorYUV(analyze=true).

But about that color range issue, i'm also a bit confused now...
Ok, let's confuse you a bit more. The main problem is that this stuff *is* a big mess.


1) The PC is using a luma range from 0 to 255 - or let us say a scale with 256 steps. Now all that issue here is caused because the common TV is only using the steps 16 to 235 on that scale? So a TV has less steps/values to 'express' a certain luma level?
You are right if you say "The PC can be using a luma range from 0 to 255 - or let us say a scale with 256 steps." Whether it does depends on the codec. But in general, codecs assume CCIR input (ie YUV [16,235]), or use the conversion YUV [16,235] -> RGB [0,255] during decoding.

I say 'in general', but this is not always the case. If you request RGB from certain dv-codecs for example, they will use YUV [16,235] -> RGB [16,235]. Also TMPGEnc has an option (which is off be default) which let you do RGB [16,235] -> YUV [16,235].

2) A DVD content (optimized for TV) has to be expanded for use on PC, but during encoding to Xvid/DivX it will be reduced again on lower TV range of 220 steps/values?
DVD content is always stored as YUV with luma range [16,235]. Like i said most codecs assume YUV [16,235] -> RGB [0,255] during decoding (except some dv-codecs).

a) if you don't convert it to RGB in the processing chain, the luma range remains [16,235] (also when you encode to XviD/DivX).

b) if you convert it to RGB and back with VirtualDub or AviSynth, they assume YUV [16,235] <-> RGB [0,255] (at least by default). So, there's no problem here.


3) A decoder on PC expands/increases the smaller TV range (stroed in Xvid/DivX) to bigger PC luma range?
Usually people mean YUV [0,255] when talking about pc_range. But the video is converted to RGB when it is displayed on a PC. I think i answered above what happens to the luma range.

[North2Polaris]

@Wilbert,

I know that this is getting to be a bit off topic, but given your post above, what would be a reason to use levels="TV->PC"?

North

[yaz]

@north2polaris
afaik, levels('tv->pc') will rescale the chroma plane too, but here only the luma scale is considered. or am i wrong (again)?
thx
y

[Boulder]

Originally posted by Wilbert

Ok, let's confuse you a bit more. The main problem is that this stuff *is* a big mess.

Not to mention the fact that many DVDs have values in the 0-255 range:confused:

[yaz]

Originally posted by Boulder
Not to mention the fact that many DVDs have values in the 0-255 range:confused: yep ... i've just checked (rip, d2v, avisynth) 5 dvds of mine (1.vob only) and all(!) of them produced full(0-255) y-scale in coloryuv :confused: :confused: :confused:
that's true that they all open w/(16,128,128) plain black. but afterward, on real scenes (say, on intro titles, white letters on black) the scale is 0-255. who to believe now ?

thx
y

[Wilbert]

I know that this is getting to be a bit off topic, but given your post above, what would be a reason to use levels="TV->PC"?
No, I don't. (Might be useful if you want to make [0,255] YUV clips for some reason.)

afaik, levels('tv->pc') will rescale the chroma plane too, but here only the luma scale is considered. or am i wrong (again)?
No, you are right. I will also rescale the chroma. If you source is trully [0,255] YUV you should scale also the chroma. But if needed, there are ways to scale the luma only.

@Boulder and yaz

yep ... i've just checked (rip, d2v, avisynth) 5 dvds of mine (1.vob only) and all(!) of them produced full(0-255) y-scale in coloryuv
that's true that they all open w/(16,128,128) plain black. but afterward, on real scenes (say, on intro titles, white letters on black) the scale is 0-255. who to believe now ?
I believe you if you say the intro titles are Y255,U=128,V=128, but the intro titles are not part of the movie itself. However you should look at the movie itself. Could you give some examples of movies where the luma range is trully [0,255] (for scenes in the movie itself)?

[Boulder]

From "The Life of David Gale" :

http://www.saunalahti.fi/sam08/gale_1.jpg
http://www.saunalahti.fi/sam08/gale_2.jpg

[len0x]

Which mpeg coefficients does the DVD above use?

[yaz]

@boulder
yep ... sg similar is here w/me :confused:

@lenox
no sign in gspot so i guess rec.709 ( so i would use colormatrix() if i dared ;) )

the bests
y

[Wilbert]

@lenox
no sign in gspot so i guess rec.709 ( so i would use colormatrix() if i dared )
Doesn't matter :) (and yes you should use colormatrix ...)


From "The Life of David Gale" :

http://www.saunalahti.fi/sam08/gale_1.jpg
http://www.saunalahti.fi/sam08/gale_2.jpg
I'm not really convinced that those are trully YUV [0,255]. Ok, the luma of some pixels are way below 16, but it's only a small part of the pixels as you can see by looking at the 'loose minimum'. The loose minimum is 15 in both cases, which means that 255/256 of the number of luma samples have luma larger than 15.

Limiter(12,235,show="luma") colors the samples for which the luma is lower than 12 (with latest binary). Perhaps you can post some screenshots for the values 10, 12 and 14.

[Arachnotron]

The right half of the lowest line of pixels in gale_2 is pure black, though the line above it is part of the grey sweater. It looks like it may very well be te origin of the Y<16 samples. Try cropping off a few pixels at all sides and see what happens.

[Wilbert]

The right half of the lowest line of pixels in gale_2 is pure black, though the line above it is part of the grey sweater.
huh? There's no black line beneath her sweather (the upper line is black though).

[Boulder]

Originally posted by Wilbert

Limiter(12,235,show="luma") colors the samples for which the luma is lower than 12 (with latest binary). Perhaps you can post some screenshots for the values 10, 12 and 14.

Limiter_10
http://www.saunalahti.fi/sam08/limiter_10.jpg
Limiter_12
http://www.saunalahti.fi/sam08/limiter_12.jpg
Limiter_14
http://www.saunalahti.fi/sam08/limiter_14.jpg

As we can see, there are very few pixels with luma below 10, but still there are some. But they shouldn't be there if the DVD was encoded in the 16-235 range? 99% of the dark areas are in legal range though.

Maybe this is just something in the decoding part and not the actual video itself?

[fewtch]

Maybe my eyes are bad (!) but there's something "wrong" with the look of my DVD encodings when using colormatrix... dark doesn't look dark enough, and bright portions look "dimmed" on my PC monitor. If this clamping was happening automatically or was already on DVD, I wouldn't notice it (maybe it's my imagination?).

I do have a fairly high end monitor (Iiyama Vision Master Pro 410), maybe I'm noticing something some people aren't? Anyway, muchas gracias to Len0x for keeping it optional in AutoGK.

[Arachnotron]

@Wilbert: open it in paint, zoom in to 800%, enable the grid and scroll down. It is there allright in the right lower corner.

@boulder:As we can see, there are very few pixels with luma below 10, but still there are some. But they shouldn't be there if the DVD was encoded in the 16-235 range? 99% of the dark areas are in legal range though.

Maybe this is just something in the decoding part and not the actual video itself?16 is the value where black is, the value that on playback will result in an 0 IRE signal(PAL). That does not mean you cannot have values below black (superblack) or that a DVD player cannot output those signal levels. In fact some test DVD's use this to tune a TV set by including pure black background with fields just below and above back. The TV set is ok when the superblack just blends into the background but you can stil see the fields above black.
16 is just a convention where to put the blacklevel. Though many DVD players clamp at 0 IRE, so often you will not see those values (and those test DVD's fail)

The distribution of those values is interesting though. Could this be the result of a sharpening filter causing ringing or something like that? Ringing at an edge at Y=16 might result in values above and below that surrounding the edge.

[edit] tried it out by sharpening a black y=16 object on a dark grey background. After sharpening, the edge is outlined by pixels with Y<16

[Wilbert]

I finally updated the documentation and released ColorMatrix v1.8.

Note that the luma/chroma of the input clip is still clamped in this version. I will add a pc_range=true in a following version.

[Wilbert]

@Boulder,


As we can see, there are very few pixels with luma below 10, but still there are some. But they shouldn't be there if the DVD was encoded in the 16-235 range? 99% of the dark areas are in legal range though.
I don't really know the answer to this, so i'm just guessing a bit. In principle this is true. But as Arachnotron notes, and this post

http://forum.doom9.org/showthread.php?s=&postid=205324#post205324

indicates, processing (sharpening, resizing or whatever) changes the luma range (pixels with luma < 16 can be created). Perhaps this has something to do with it. Perhaps also the compression itself can cause this. But, i don't know much about how the dvd's are created and if it the luma range is clamped after processing ... But, we should be able to find people who know about this.

@Wilbert: open it in paint, zoom in to 800%, enable the grid and scroll down. It is there allright in the right lower corner.
Ok, i see it now.


Maybe my eyes are bad (!) but there's something "wrong" with the look of my DVD encodings when using colormatrix... dark doesn't look dark enough, and bright portions look "dimmed" on my PC monitor. If this clamping was happening automatically or was already on DVD, I wouldn't notice it (maybe it's my imagination?).
I guess you compared it by openening the vob directly in VirtualDubMod?

[Boulder]

Originally posted by Wilbert
[B]@Boulder,


I don't really know the answer to this, so i'm just guessing a bit. In principle this is true. But as Arachnotron notes, and this post

http://forum.doom9.org/showthread.php?s=&postid=205324#post205324

indicates, processing (sharpening, resizing or whatever) changes the luma range (pixels with luma < 16 can be created). Perhaps this has something to do with it. Perhaps also the compression itself can cause this. But, i don't know much about how the dvd's are created and if it the luma range is clamped after processing ... But, we should be able to find people who know about this.

I agree, there's probably people around here who are in the business or know people are there.

I myself didn't do anything but load the d2v project and use Limiter so the "illegal" pixels are either already in the source or introduced when decoding. Maybe Don knows something about this as he's working on the MPEG-2 decoder in question. I don't believe it's a rounding error as the difference is just too big for that.

Nevertheless, it's not a big problem as the stray pixels are quite rare;)

[Jeffster]

It looks like a bug may have been introduced into the latest version (1.8) of ColorMatrix?
I noticed it while converting a DivX source file to MPEG-2 in CCE with the parameter ColorMatrix(mode="Rec.601->Rec.709")

Here is a screenshot of the original without colormatrix (http://homepages.ihug.co.nz/~jefx/temp/without_CM.png) and another screenshot using colormatrix1.7 (http://homepages.ihug.co.nz/~jefx/temp/colormatrix_1.7.png), no problems there... but here is the same script this time using colormatrix1.8 (http://homepages.ihug.co.nz/~jefx/temp/colormatrix_1.8.png) instead.

:confused:

May I make a small suggetsion while I have your ears... for the mode parameter, changing it to something short like mode=1 or mode=2 would be much easier to remember than mode="Rec.601->Rec.709". Currently I have to open the html help file and copy and paste that line each time I use it in a script like the one above.

[tritical]

It looks like a bug may have been introduced into the latest version (1.8) of ColorMatrix?
I noticed it while converting a DivX source file to MPEG-2 in CCE with the parameter ColorMatrix(mode="Rec.601->Rec.709") Indeed, it's an mmx overflow problem with the rec601->rec709 conversion, the other conversion isn't effected. You can use mmx=false for now, I'll fix it right away. I forgot that in the rec601->rec709 mmx conversion there is a 4x scale factor on two of the coefficients and the max it can be after the adjustment for rounding is 2x without risking overflow.

[Jeffster]

Thanks... just confirming that mmx=false corrects it :)

[tritical]

Fixed version... colormatrix 1.8 - mmx fix (http://bengal.missouri.edu/~kes25c/ColorMatrix-18mmxfix.zip). Only change was fixing the overflow in the rec.601->rec.709 mmx conversion. Sorry about not catching that before.

[Wilbert]

Thx! Released v1.9.

[Karyudo]

Originally posted by Jeffster
for the mode parameter, changing it to something short like mode=1 or mode=2 would be much easier to remember than mode="Rec.601->Rec.709".

Or how 'bout mode=6to7 and mode=7to6? Or 627 and 726? Or 67 and 76?

[Boulder]

Would it be possible to just check the first appropriate line in the d2v file and then assume the coefficients do not change during the clip? This would make it slightly faster, probably not much but at least some.

[tritical]

Not sure how that would be any faster then using the current d2v="" option :confused:. It parses the full d2v file once when the filter initially starts and that's it. Checking only the first line of the d2v would only save a second or two when the script is first loaded at most.

[Boulder]

Oh, I thought it processes the file line by line as the encode goes on. In that case, forget what I said;)

The docs could use slight tuning, currently it says that mode is overridden when hints or d2v parsing is used. It might be better to say that the conversion is done if necessary according to what mode the user has specified and what the hints or the d2v file tell.

[Wilbert]

The docs could use slight tuning, currently it says that mode is overridden when hints or d2v parsing is used. It might be better to say that the conversion is done if necessary according to what mode the user has specified and what the hints or the d2v file tell.
I will change that. (The former is still true though, but perhaps a bit confusing :))

[redfordxx]

Please can somebody react on my post 11th March 2005 17:50 in
http://forum.doom9.org/showthread.php?s=&threadid=91238&perpage=20&pagenumber=2

Tnx

[Wilbert]

Of course I poked before... saw many expressions of gratitude etc... that it
helps to repair colors...

But, still I see what I see (No metrics, Didée!).
The capture frame from xvid.avi w/o ColorMatrix is much more similar to
capture frame from vob, than capture frame from xvid.avi with ColorMatrix. I
made same test as Japhsoncross before, moreover with ColorMatrix. (XviD, Q1,
no Bframes) And, as Intervideo makes some postprocessing already, I played
vob with FFDShow too.

I have GKnot 0.35 so I suppose I have DGDecode 1.2.1.
When I look in d2v, first line I see is:
c00 1 0 2048 1 1 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
so I suppose it's ITU-R BT.709. Mpeg2source(...., info=1) confirms it.
So it should be ColorMatrix w/o param. However, I tried ColorMatrix(d2v="D:\record\rip\lotr tt\1\tt1.d2v") too and result the same:

XviD FFDShow capture with ColorMatrix is significantly "brighter" than both Intervideo and FFDShow captures of vob. Conclusion - one of following:
1. FFDShow and Intervideo capture MPEG2.VOB incorrectly
2. FFDShow captures XviD.avi incorrectly
3. ColorMatrix does not do the job I suppose.
4. ???
Which one is it? Suggestions?
Could you make a VirtualDubMod capture of your vob and compare that? I have no idea how ffdshow the YUV->RGB conversion does.

[Malcolm]

does anyone know if there's a standard recommendation (rec601 or rec709) for DVB broadcastings? Neither GSpot, nor dgdecode with info=1 tells me anything about the matrix coefficients in my dvb recordings. so i don't know what to use (rec601 -> rec709, rec709 -> rec601, nothing at all).

Thank you and greetings,
Malcolm

[Boulder]

If you don't see any, rec.709 is assumed IIRC. You can always test it though.

[khmann]

Hi. 2 questions:

1. does anyone know the native matrix of NTSC DV? I guess 601?

2. does anyone know a way to "patch" an MPEG-2 if my stupid encoder doesn't specify the correct matrix? I'd rather avoid conversions if possible...

some info: according to GSPOT 2.5, TMPGENC 2.524 does not set matrix when encoding MPEG1. When encoding MPEG2, matrix is set to "S170".

this chart may be useful to folks trying to diagnose codec colorspace or luma levels: http://www.belle-nuit.com/testchart.html

thankyou!

[Wilbert]

1. does anyone know the native matrix of NTSC DV? I guess 601?
I think it's Rec.601. I suggest you drop a post in that forum to ask for confirmation.

2. does anyone know a way to "patch" an MPEG-2 if my stupid encoder doesn't specify the correct matrix? I'd rather avoid conversions if possible...
No, not yet :(

some info: according to GSPOT 2.5, TMPGENC 2.524 does not set matrix when encoding MPEG1
MPEG1 is always Rec.601. The header doesn't contain such info.

When encoding MPEG2, matrix is set to "S170".
Thx for the info. It's exactly the same as Rec.601 (older versions of TMPGEnc used FCC).

[Daijoubu]

If we only need Rec.709->Rec.601, can we use BT709ToBT601 (http://forum.doom9.org/showthread.php?threadid=50588) instead?
It's faster but the output is slightly different

Which one is more accurate?

[Didée]

Originally posted by Daijoubu
If we only need Rec.709->Rec.601, can we use BT709ToBT601 (http://forum.doom9.org/showthread.php?threadid=50588) instead?
I haven't (re-)tested this one for a long time. But I remember that it once gave me strange results on e.g. some dark blue, noisy backgrounds. Looked somewhat like a mixture of blocking & swimming-wall-effect ... I stopped using it when I discovered that.

[Daijoubu]

Originally posted by Didée
I haven't (re-)tested this one for a long time. But I remember that it once gave me strange results on e.g. some dark blue, noisy backgrounds. Looked somewhat like a mixture of blocking & swimming-wall-effect ... I stopped using it when I discovered that.
Stil version 0.1.0.0, no update since 2003/04/07
I guess I can take your word on this and stick to the more recent ColorMatrix :)

[tritical]

BT709ToBT601 uses slightly different coefficients then colormatrix... I think the coeffecients from Wilbert's calculations are more accurate. Also, BT709ToBT601's mmx code doesn't do any correction for rounding, which is the main reason that is quite a bit faster then colormatrix's mmx code. Finally, BT709ToBT601 does not call limiter (or do any sort of value clamping), which colormatrix calls twice (once at the beginning and once at the end). So the output from BT709ToBT601 will definitely have some differences to that of colormatrix.

[redfordxx]

Originally posted by Wilbert
Could you make a VirtualDubMod capture of your vob and compare that? I have no idea how ffdshow the YUV->RGB conversion does. OK, finally I made these tests...
For VDM I made Printscreen.
For BSplayer I made captures by the SW.
Equations below:
= means (almost) same color
<> noticably different color

VDM:vob=XviD(ColorM.avi)<>XviD(WithoutCM.avi)

BSPlayer:Intervideo(vob)=FFD(vob)=XviD(WithoutCM.avi)=FFD(WithoutCM.avi)<>XviD(ColorM.avi)=FFD(ColorM.avi)

Morover when I set in BSP default color setting (i.e. Brightness=7,5) then
BSPlayer(ColorM.avi)=VDM(vob)

MPClassic has completely different colors than VDM or BSP and I don't know it that much to find some color settings...

Uh oh...

[redfordxx]

As somebody might know:), during my script I want to go to RGB32 to deblock my video...
Doing this and applying ColorMatrix makes three choices --- I think:

1)
ConvertToRGB32("pc.709")
ConvertBackToYUY2("pc.709")
*ConvertToYV12
ColorMatrix

2)
ConvertToRGB32("pc.601")
ConvertBackToYUY2("pc.601")
*ConvertToYV12
ColorMatrix

3)
ConvertToRGB32("pc.709")
ConvertBackToYUY2("pc.601")
*ConvertToYV12

*now I can't remember, whether I tested it with ConvertToYV12

I thought 1) and 2) should be equal and 3) better quality (one conversion less). But in 3) I mentioned sllllllight gradients here and there compared to 1) or 2). Weird...

[Wilbert]

1) bsplayer and ffdshow do it "wrong". I will ask the authors to do it correctly.

2) In theory, the scripts:

a)
ColorMatrix

b)
ConvertToRGB32("Rec709")
ConvertBackToYUY2()

should give the same results. Isn't that the case? Nb, your scripts (using "pc.xxx") make sense if your source is YUV [0,255]. But I don't know why


I thought 1) and 2) should be equal and 3) better quality (one conversion less). But in 3) I mentioned sllllllight gradients here and there compared to 1) or 2). Weird...

I have to look at that.

[redfordxx]

Originally posted by Wilbert
ConvertToRGB32("Rec709")
ConvertBackToYUY2()

should give the same results. Isn't that the case? Nb, your scripts (using "pc.xxx") make sense if your source is YUV [0,255].
when I have in dgdecode the option PCScale? Or should I have there better TVScale anyway?

[Wilbert]

when I have in dgdecode the option PCScale? Or should I have there better TVScale anyway?
That option doesn't do anything when you open the d2v in AviSynth (since no conversion to RGB takes place).

Btw, PC-scale means that the conversion YUV [16,235] -> RGB [0,255] *might* take place *if* a codec requests RGB from the d2v (like TMPGEnc or vfapi, but it doesn't work there (meaning they don't look at the scale setting , and thus the pc-scale is used since it's the default)). I hope this is clear :)

I tested this myself (one of the threads in the dvd2avi forum).

[ronnylov]

Mainconcept encoder 1.4.2 can set the type of colormatrix used at the encoding. Here's what the pdf manual say:


Color Primaries: This field specifies the x,y chromaticity coordinates of the source picture primaries. It is strictly an informative flag to the video decoder and does not affect the video encoding at all. DVD specifies a value of 2 (ITU-R BT.470-2 System M) or 4 (SMTPE 170M) for NTSC or 3 (ITU-R BT.470-2 System B,G) for PAL. See ISO/IEC 13818-2 section 6.3.6 for more information. This option is only valid for MPEG-2.

Transfer Characteristics: This field specifies the opto-electronic transfer characteristics of the source picture. It is strictly an informative flag to the video decoder and does not affect the video encoding at all. DVD specifies a value of 2 (ITU-R BT.470-2 System M) or 4 (SMTPE 170M) for NTSC or 3 (ITU-R BT.470-2 System B,G) for PAL. See ISO/IEC 13818-2 section 6.3.6 for more information. This option is only valid for MPEG-2.


I capture in PAL-B format as huffyuv and feed the avi file through avisynth which use MPEG1-coefficients as default which should be the same as option 3 above? If this is correct colormatrix should not be needed when creating PAL DVD or when opening PAL DVD sources in avisynth? Because for PAL DVD only option 3 is possible?

EDIT: I did a test. The original avisynth script opened in virtualdubmod looks exactly the same as the encoded mpeg-2 file opened directly in virtualdubmod. So I guess I don't need colormatrix in this case.

[freelock7]

THX Wibert!This filter recalculates the yuv values assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (mpeg2 or mpeg4) is displayed correctly.

Very fine results!
I noticed that CCE encoded colors was too satured before that.
So I think that the next release of avisynth could be corrected(?).

[charleski]

I only came across this yesterday after looking at the output of AutoGK and it gave me a bit of a shock.

I have a question, though. What about encodes from PAL DVB material? After scratching around a bit on the web, I get the feeling that these should already be using 601 coefficients. Is that right?

[Didée]

Probably not - check the colorimetry info. For most of the material I capture from DVB-S, DGindex is reporting BT.709 ...

/*hands over smelling salts*

[charleski]

Ah yes, you're right. d2V's made from remuxed mpegs were coming up as Colorimetry: Unspecified Video (2) in DGDecode, but I looked at an original capture and it's 709.

Aargh!

[Wilbert]

New version, v1.10. See first post for download and changelog.

[actionman133]

Hey, I have a question about the use of ColorMatrix. It seems like a simple one, but having searched through about 75% of this thread (and the others that link here too, it's all too big to read everything), I still don't have an answer.

I have a DVD source that DGDecode reveals to be stored using SMPTE 170M (6 in the d2v file). According to your table about the various colorimetrics, it's the same as ITU-R BT.601 (which I assume is the technical name for Rec.601).

My question is, do I need to run ColorMatrix on this clip (or for any clip where the original coefficients are the same as rec.601)? Logic says no, but I did a Subtract (Original.ColorMatrix (d2v = "blah.d2v", mmx = false), Original) and there are some discrepencies. Granted they are minor but I am video purist, and if ColorMatrix is throwing it off a little, I'd rather save the CPU cycles for better playback. :cool:

Thanks, and apologies if this has been answered before. Perhaps a FAQ is in order where ALL the information is. :)

[Wilbert]

Depends on your end format. But if you are encoding to DivX/XviD you don't need to run Colormatrix in your case.

Try the following script to spot any difference:

Original = Mpeg2Source(...).Limiter()
Subtract(Original.ColorMatrix (d2v = "blah.d2v", mmx = false), Original)

Your dvd can have luma values outside [16,235], which will be clipped by ColorMatrix. That's one of the differences you should see in your original script.

If you still see a difference, please upload a small part (20 frames) of that vob.

[actionman133]

Yes, it was for DivX at the end. And Limiter removed those little errors, so the difference was just your filter's clamping. So it's all good.

Thanks Wilbert. :)

[tritical]

I've made a test version of colormatrix that is able to do all colorimetry type conversions (not just BT.709->BT.601 and BT.601->BT.709) with exact coefficients. It also has 3 options for value capping and coefficient scaling:

0.) cap input/output to [16,235(240)] range, and scale conversion coefficients (219/255,224/255)
1.) cap input/output to [0,255] range, and scale coefficients to (219/255, 224/255)
2.) cap input/output to [0,255] range, and don't scale coefficients (255/255)

The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont :).

[colinb]

I'll shortly be using HC to encode some DV (camcorder) footage. I'll be feeding the DV AVI file to HC via an avisynth script.

Do I need to use colormatrix() in my avisynth script?

It's PAL DV if that is significant.

[TheBashar]

Just a quick note. I saw in the docs that you (Wilbert) had never come across a mixed colorimetry source. I've been transferring some of my TV DVD collections to x264 and I've found some of the season 1 SG-1 DVDs have mixed colorimetry. Thanks for the hints option!

[colinb]

I'll shortly be using HC to encode some DV (camcorder) footage. I'll be feeding the DV AVI file to HC via an avisynth script.

Do I need to use colormatrix() in my avisynth script?

It's PAL DV if that is significant.

Well, I tried loading both the original DV AVI file and HC encoded m2v files into VirtualDub side by side and they appeared identical - this was without a call to colormatrix.

This surprised me because after a bit of searching I found that DV is supposed to be Rec.601 while HC expects its input to be Rec.709, so I would have thought that a conversion rec601->rec709 would be required before feeding HC.

So I then tried passing the original DV AVI file through a colormatrix 601 to 709 conversion and displayed this in VirtualDub alongside the original DV file (without colormatrix conversion). They looked almost identical too. Neither looked darker than the other. I did notice that on frames with intense red/orange these areas seemed slight darker or perhaps just more saturated on the 601->709 converted footage. This was the first time I have tried colormatrix and I was expecting to see a slightly more noticeable difference.

Anyway it looks like for PAL DV at least I don't need to use colormatrix - but I'm not sure why.

[Wilbert]

Just a quick note. I saw in the docs that you (Wilbert) had never come across a mixed colorimetry source. I've been transferring some of my TV DVD collections to x264 and I've found some of the season 1 SG-1 DVDs have mixed colorimetry. Thanks for the hints option!
Great! Could you upload a small vob which has this mixed colorimetry info?

This surprised me because after a bit of searching I found that DV is supposed to be Rec.601 while HC expects its input to be Rec.709, so I would have thought that a conversion rec601->rec709 would be required before feeding HC.
Sounds right (and yes, the difference is small). Could you upload a small part of that dv (10 frames)?

[EpheMeroN]

I have HD content that I am encoding to DVD using CCE 2.70, and was looking into using ColorMatrix on my sources.

DGIndex reports back a Colorimetry = ITU-R BT. 701 (1)

CCE also, by default, assumes ITU-R BT. 701 (1) coefficients correct? So, is there any reason to still use ColorMatrix? Or do I have it all wrong?

[Wilbert]

CCE also, by default, assumes ITU-R BT. 701 (1) coefficients correct? So, is there any reason to still use ColorMatrix? Or do I have it all wrong?
No, you are correct.

[actionman133]

I've made a test version of colormatrix that is able to do all colorimetry type conversions (not just BT.709->BT.601 and BT.601->BT.709) with exact coefficients. It also has 3 options for value capping and coefficient scaling:

0.) cap input/output to [16,235(240)] range, and scale conversion coefficients (219/255,224/255)
1.) cap input/output to [0,255] range, and scale coefficients to (219/255, 224/255)
2.) cap input/output to [0,255] range, and don't scale coefficients (255/255)

The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont :).

If you created a more comprehensive and precise filter (not to say Wilbert did a bad job, it's a great filter!), I would definitely use it. I am a precision control freak, so those extra options would be much appreciated. :D

[EpheMeroN]

No, you are correct.
Good to know!

...but do you know if HD broadcasts use a range of 0-255 or 16-235?

[jsquare]

I have an old Samurai movie in B/W, when encoded with Xvid it looks a bit too bright and washed out, DGIndex is reporting the colorimetry as "ITU-R BT.470-2" and the frame type seems hybrid(it changes from Interlace to Progressive constantly). By adding ColorMatrix() to the script my encode looks acceptable, but I have a couple of questions:

Is the default command ColorMatrix() all I need or should I include some other settings?

Should I add ColorMatrix() to all my future encodes?

[Boulder]

Does ColorMatrix even affect BW stuff?

[jsquare]

Does ColorMatrix even affect BW stuff?
Probably not, but it seems to "clamp" Luma/Chroma to CCIR-601 values as stated on the docs.

[Boulder]

That's a job for Limiter()..I'm sure using it is faster than using ColorMatrix with B/W stuff.

[Oline 61]

I don't quite understand this. If I have a DVD that uses BT.709 according to DGIndex, do I need to use Colormatrix? If so, what settings?

[Wilbert]

What is your final format? What is your encoder?

As an example: If you are encoding to mpeg-4 (which uses BT.601), you will need the conversion.

[Oline 61]

I am just going AVISynth to MeGUI/x264 CLI. Another thing I just noticed is that when I preview the VOB in DGIndex it says BT.709, but after it finishes creating a d2v project file it says SMPTE 170M. So what would be the proper settings for me to use?

[Wilbert]

I am just going AVISynth to MeGUI/x264 CLI. Another thing I just noticed is that when I preview the VOB in DGIndex it says BT.709, but after it finishes creating a d2v project file it says SMPTE 170M. So what would be the proper settings for me to use?
If true, this would be a bug in DGIndex (since SMPTE 170M = BT.601, and SMPTE 240M = BT.709). Could you check this with the latest DGIndex?

[Oline 61]

Using latest DGIndex version:
The first picture is the windows after completely saving the d2v project.
http://img467.imageshack.us/img467/5964/untitled20tb.jpg
The second picture is a screenshot while running a preview.
http://img382.imageshack.us/img382/9803/untitled8br.jpg

[Oline 61]

Is there a definitive way to tell which of these colorimetries is correct?
BTW, when I try to use ColorMatrix(d2v="VTS_01_1.d2v")
it tells me that multiple colorimetry types were detected in the d2v file.

[Wilbert]

BTW, when I try to use ColorMatrix(d2v="VTS_01_1.d2v")
it tells me that multiple colorimetry types were detected in the d2v file.
Yes, neuron2 hinted at this possibility. You need to find out, by scrolling through the video, when the colorimetry changes. I guess the main movie is BT.709, but after the credits some black frames are SMPTE 170M? Please confirm.

If that's indeed the case, i would apply ColorMatrix to the whole movie (it doesn't do anything when a frame is black, since it corrects chroma).

[Oline 61]

Looks like your right. If I play it starting near the end it changes to 170M right before reaching the end of the file. Thanks for helping, I will use ColorMatrix()

[Boulder]

Another option is to enable hints output in MPEG2Source and set ColorMatrix accordingly.

[15081947]

After going through this entire thread I am trying to tabularise the colormatrix usage for Divx/Xvid conversion.

Anything -> Divx/Xvid
------------------------
Source Colorimetry--------ColorMatrix
ITU-R BT.470-----------------No
ITU-R BT.601-----------------No
ITU-R BT.709-----------------Yes
SMPTE 170 M-----------------No
SMPTE 240 M-----------------Yes

Please feel free to correct it.

Thanks

[Wilbert]

Please feel free to correct it.
It's correct.

[Ginsonic]

Hi Wilbert and Tritical,

Thank You for Your great ColorMatrix-Plugin !

@Tritical:
The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont
I would be very interested in such a version, it would be great, if You could release it.

[EpheMeroN]

I have an XviD file that was converted from an HDTS .ts file, but ColorMatrix was not used in the script.

Will adding ColorMatrix back in a script to do XviD to DVD correct the colors?

[Wilbert]

Depends. What are the coefficients of your original transport stream?

[EpheMeroN]

Depends. What are the coefficients of your original transport stream?
ITU-R BT. 701 (1)

[Wilbert]

... ITU-R BT. 709 i presume :)

In that case you don't need to correct it (the errors cancel each other out), provided you feed YUV to the mpeg-2 encoder (CCE, QuEnc or HC).

[EpheMeroN]

... ITU-R BT. 709 i presume :)

In that case you don't need to correct it (the errors cancel each other out), provided you feed YUV to the mpeg-2 encoder (CCE, QuEnc or HC).
Is YUV YUY2/YV12 colorspaces?

...and yes, you presumed correctly. :)

[Wilbert]

Is YUV YUY2/YV12 colorspaces?
Yes, it is.

[FredThompson]

How about adding the option to set clamping to either the default of CCIR-601 or simple overflow protection?

[Boulder]

Wilbert,

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.

See this one for more info: http://forum.doom9.org/showthread.php?p=788356#post788356

[tritical]

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.
The hint information is stored in the least significant bit of each of the first 64 bytes of the image. For YV12 that means the first 64 luma pixels (Y plane). However, in YUY2 it would be the first 32 luma pixels + 16/16 U/V pixels since YUY2 is a packed format (YUYV). Therefore, doing a YV12->YUY2 or YUY2->YV12 colorspace conversion will make the hints unreadable in the new colorspace. This could be avoided if hints were always stored in the first 64 luma pixels (not just the first 64 pixels), but not sure if its really worth the trouble. Also, any operation that could modify the values of the first 64 pixels could destroy the hints... so resizing, denoising, color correction, trimming that removes the top line or pixels off the left, etc... should all be avoided. Though if you really need to do this there is a filter in TIVTC called MergeHints() that can maintain these types of hints across such filtering and color space conversions by transferring the hint information from a saved clip to a new clip.

I would be very interested in such a version, it would be great, if You could release it. I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.

[Wilbert]

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.
That's normal. It's the same story with Decimate and Telecide and why neuron2 advices you to place the two next to each other.

I don't know precisely how it works, so i hope tritical will reply. But hints are added at the start of the stream. Sometimes filters will destroy those hints and sometimes not. I recall tritical made once a filter for this purpose, which can store those hints and pass them to a filter which comes later in the filter chain. I can't find that filter though.

edit: too late :)

[Boulder]

OK, I'll have to refrain from resizing before ColorMatrix.

I've learnt two new things today, not bad ;)

[Wilbert]

tritical, can i ask something stupid :)
The hint information is stored in the least significant bit of each of the first 64 bytes of the image.
(1) what does least significant bit means (i mean why not the first bit)? (2) so there should be one pixel visible (if you don't use the hints) which is actually garbage?

[foxyshadis]

LSB also means least important and least noticeable, ie, changing it only changes the pixel value +-1, below the noise threshold of most videos, whereas changing the first, the most significant, means +-128. Little more noticeable. :p Since it only changes a few pixels' values by 0 or 1, it should never have a noticeable effect on filters or output.

[Wilbert]

LSB also means least important and least noticeable, ie, changing it only changes the pixel value +-1
How does ColorMatrix know which pixel is altered and by how much? I guess i need to read the code again tonight :)

[foxyshadis]

Hinting just overwrites whatever was in the last bit of the first 64 bytes (pixels) of the plane. Then filters read only those last bits, ignoring the rest. They don't really care what was there before, or whether it was modified.

[FredThompson]

Ah, come on, Wilbert, gimme a nod, ok? I can whine if it will help :P

[Ginsonic]

I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.
Thanks a lot Tritical !

[jackiehcs]

If I use "TMPsource" instead of "mpeg2source" by importing d2v to tmpgenc, is it correct to use "ColorMatrix(d2v="xxx.d2v")" to correct the color difference?

[Wilbert]

TMPGEnc converts it to RGB24 for you. Thus TMPSource also delivers RGB24. TMPGEnc uses fcc coefficients (=Rec.601) for the YV12->RGB24 (and vice versa) conversion.


TMPsource("yourtprfile")
converttoyv12()


converts it back to YV12 using the same (ie Rec.601) coefficients. Ok, that's good and we don't have to worry about this conversion to RGB in between.

So the script:

TMPsource("yourtprfile")
converttoyv12()
ColorMatrix(d2v="xxx.d2v")

should be correct when encoding to XviD/DivX.

[jackiehcs]

I see, thanks.

[Ginsonic]

I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.

Knock, knock ;) Is there any news ?

[jmac698]

I did some research, and bbmpeg can set the coefficients in advanced settings. Now you just set it the same as your source. If you have dvb/s or hdtv, set rec709, for cap set rec601, and for properly made xvid set rec601.

Only one problem, bbmpg is an older program and we need to increase the motion vector length, and apply some good matrices.

I found that freeenc (based on libavcodec) has no option for color coefficients.

Ideally we need the option in restream, to set the whole stream to a coefficient.

There is one more problem of different coefficients in one stream, and the only solution so far is colormatrix. Use the coeff. of the main movie in the bbmpg settings, and use colormatrix with hints to convert 601->709 when 601 appears.

[Inc]

I found that freeenc (based on libavcodec) has no option for color coefficients.
IF theres an option in the Libavcodec XXXcontext settings to set the coefficients for the encode then this could be integrated in FreeEnc or Qenc as both are open source.

[jmac698]

I see nothing in
http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC9
relating to color coefficients. Any other ideas?
Also
http://mplayerhq.hu/~michael/ffmpeg-doxy/structMpegEncContext.html
Has a lot of info, I don't think it's there but I'm not sure.

[Hans Ohlo]

i read trough most parts of the thread. since a hdtv transport stream i recorded showed nothing in gspot i had to determine which coefficents were used. so i loaded the avs script into virtualdub took a screenshot and did the same with the mpeg in mpc. then i compared. i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright and i have to do the encode all over again. isnt there a way to determine for shure if to use colormatrix or not?

[Wilbert]

i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright
This might be a playback issue. What are you using to play it?

[Hans Ohlo]

This might be a playback issue. What are you using to play it?
CoreAVC (0.0.0.4 alpha)

[Wilbert]

i read trough most parts of the thread. since a hdtv transport stream i recorded showed nothing in gspot i had to determine which coefficents were used. so i loaded the avs script into virtualdub took a screenshot and did the same with the mpeg in mpc. then i compared. i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright

I guess the same happens when you don't use ColorMatrix?

[Hans Ohlo]

I guess the same happens when you don't use ColorMatrix?
no, i did a reencode without colormatrix and the colors are ok. strange is what i described before...

[jellysandwich]

1) 1) I709 (= Rec.709 coefficients)
2) FCC (almost the same as Rec.601)
3) I470 (= Rec.601 coefficients [an updated version of Rec.470-6, but coefficients are exactly the same])
4) S170 (= SMPTE 170M; exactly the same as Rec.601)
5) S240 (= SMPTE 240M; almost the same as Rec.709)

If the boxes remain "black" then the used coefficients are not present in the header, and the default (which is Rec.709) should be assumed.


I'm confused about this whole ColorMatrix thing. If the boxes are black, then I should assume Rec.709 was used, and I should use ColorMatrix (Megui x264)?

js

[Wilbert]

I'm confused about this whole ColorMatrix thing. If the boxes are black, then I should assume Rec.709 was used
Yes, indeed.

and I should use ColorMatrix (Megui x264)?
Yes again.

[Hans Ohlo]

Yes, indeed.


Yes again.
yep but in my experience in 90% of the time this is wrong and the colors (especially red) are to bright...

[Wilbert]

yep but in my experience in 90% of the time this is wrong and the colors (especially red) are to bright...
Could you upload a 10 frames vob somewhere showing this problem?

[Hans Ohlo]

it is no vob it is from mpeg2 high def ts streams.

[Wilbert]

Ok, could you cut it with some tool and upload 5-10 frames from that?

[HOLiC]

Hi, I have a quick question!
Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)

I'm trying to encode something using "tivtc mkv-vfr" method and I can't use colormatrix, since I keep getting an error about clip being not matched, or something like this:


Avisynth Open failure:
TFM: crc32 in input files does not match that of current clip...


So, I placed colormatrix after ivtc, and it seems to work fine:


mpeg2source()

TFM(mode=1,input="tfm.txt")
oldcount=framecount
tdecimate(mode=5,hybrid=2,input="tdec.txt",tfmIn="tfm.txt",mkvOut="timecodes.txt")

colormatrix(mode="Rec.709->Rec.601")

oldfps=framerate
averagefps=(float(framecount)/float(oldcount))*oldfps
assumefps(averagefps).Nicefps()


I'm just worried that if I do it like this, the filter won't do anything...
I would appreciated it if someone would confirm this.
Thanks in advance!!

[Wilbert]

Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)
Only if you use hints.

I'm trying to encode something using "tivtc mkv-vfr" method and I can't use colormatrix, since I keep getting an error about clip being not matched, or something like this:
I'm not sure. Perhaps tritical can comment?

[foxyshadis]

It's a special function of the tfm 2-pass file, it errors out if you don't use exactly the same filters before tfm as you did on the first pass. tdec has the same check. Colormatrix should have no effect, but tfm's trying to protect against random changes that render the stats useless.

To disable the check, all you have to do is remove the "crc=" section from the beginning of the stats files. (Leave the other info though!)

Colormatrix will still have an effect where it is now, though. It just won't be able to use hints to decide when it actually needs to be used, it'll just affect every frame (which is usually correct).

[jellysandwich]

Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)

When I was working on FLCL, I actually got small horizontal line artifacts in a few frames using Colormatrix before IVTC. Calling Colormatrix after IVTC fixed it.


js

[Wilbert]

Also, I just got a copy of Ferris Bueller. As it turns out, it's one of those rare DVDs that has changing colorimetry info. What's the recommended action for these types of DVDs? Leave it alone? Use colormatrix anyway?
A small request :) Could you upload a small vob (say 20 frames), where this changing occurs?

Does the change happen at the end or in the middle of the clip?

[rig_veda]

If an avisynth script outputs YV12 and I open it in VirtualDub, Vdub needs to make a YV12->RGB conversion for it's preview image. For this conversion, does it assume that the YV12 material is Rec.601?
In this case, if I process Rec.709 material in my AviSynth script, make a ColorMatrix() call along the line and feed it into Vdub, it would display correctly, right?

If I process Rec.709 material, make a ColorMatrix() call that converts it to Rec.601 and a ConvertToRGB() at the end and open this in Vdub, it would give the same result, right?

And if I process Rec.709 material and just do ConvertToRGB(Rec709) before handing it to Vdub, it would also be the same, yes?

The maximum differences i got from screenshots of vdub's display of these three cases was 3 (for RGB values in the 20-30 area), so i was wondering whether these are still due to rounding errors or whether my assumptions above are just wrong.. :D And, yes, which of the three method's display to trust most for proof viewing the output of a filter chain..?


Edit: I was using VirtualDubMod, not VirtualDub.

[Wilbert]

If an avisynth script outputs YV12 and I open it in VirtualDub, Vdub needs to make a YV12->RGB conversion for it's preview image. For this conversion, does it assume that the YV12 material is Rec.601?
Yes.

In this case, if I process Rec.709 material in my AviSynth script, make a ColorMatrix() call along the line and feed it into Vdub, it would display correctly, right?
Yes.

And if I process Rec.709 material and just do ConvertToRGB(Rec709) before handing it to Vdub, it would also be the same, yes?
Yes.

The maximum differences i got from screenshots of vdub's display of these three cases was 3 (for RGB values in the 20-30 area), so i was wondering whether these are still due to rounding errors or whether my assumptions above are just wrong..
For the last two cases, they are just rounding errors. The first one is wrong.

And, yes, which of the three method's display to trust most for proof viewing the output of a filter chain..?
It seems to me that ConvertToRGB(Rec709) would be the most accurate.
When using ColorMatrix and ConvertToRGB (VDub routines), you will make two rounding erros.

[unplugged]

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders, with the result that DivX/XviD clips or mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors (which looks like a small difference in brightness ). This can be checked by opening the mpeg2 stream directly in VDubMod. More info can be found in the readme.

This filter recalculates the yuv values assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (mpeg2 or mpeg4) is displayed correctly.
I appreciate your effort, but isn't better to implement an option to ffdshow or XviD decoder to pass YUV data through hardware overlay using the same ITU-R BT standard used in the DVD Player software?

If PC DVD Players show movies with the "right" brighteness and they almost always use overlay card function as well why MPEG4 DirectShow decoders can't simply dial with the overlay subsystem by simply imparting the same YUV->RGB color conversion scheme?

When we see a movie in our PC, most of times we see it through overlay output method. AFAIK "overlay" involves direct video card conversion of YUY2 / YV12 data *directly* into analog RGB signals.
(that's the reason because overlay mode exists, this makes a lot of difference on (analog) CRT displays)

IMHO this is better than manipulate YV12 data and than involve some erratic pixel requantization. (16-235 --> 0-255)

[foxyshadis]

Because the pc-playback streams suck and don't include any form of flagging for this. Same problem, but much worse, with tv/pc yuv translation. A simple bitflag for tv/pc would give decoders & renderers a way to correctly decode everything, instead of essentially randomly picking one method and destroying video that doesn't fit its mold. In this case, adding the colorometry flag of mpeg2 to mp4/mkv, or mpeg4 asp/avc raw streams would be a better way, but afaik it isn't there at all, and good luck calling up ISO and asking them to throw it in.

[Heini011]

hi,

many thanks for your work on colormatrix! but i have 2 questions. regarding to this line from manual:

This filter will clamp (= round) your input video to CCIR-601 compliant values (these ranges are 16-235 for the luma component and 16-240 for the chroma component).

first: i don't understand why luma and chroma limitting is performed and why it is not possible to disable. if i encode for playback on a pc via xvid, i would like to keep the full pc-scale [0..255] of luma and chroma.

second: if i process an avs script within avisynth and save a frame as rgb-bitmap, i got the full pc-scale on luma and corrected color. uhm.. ?

greetings.

[Heini011]

Hi,

many thanks for the working on colormatrix. i have 2 questions regarding to the following line in the docu:

This filter will clamp (= round) your input video to CCIR-601 compliant values (these ranges are 16-235 for the luma component and 16-240 for the chroma component).

1. is that mean tv-scale luma/chroma clipping? i don't want such clipping if i encode material for pc playback!

2. if i open an avs script with colormatrix within virtualdub and save a frame as rgb bitmap, i got the full luma range [0,255] - exactly what i want to have, but in opposite to the docu ?

btw: HCEnc is using ITU-R BT.709 colormetry already.
so i have (not) to use it for hcenc in the opposite way than xvid, right ?

greetings.

[Wilbert]

1. is that mean tv-scale luma/chroma clipping?
Yes.

i don't want such clipping if i encode material for pc playback!
tv/pc-scale has not much to do with pc playback. I know some people claim otherwise, but that's a bit misleading. The point is that the footage is clipped in YUV-space (and when the clip is played back, and thus converted to RGB, the luma/chroma range is expanded again by most players), so it is only a problem if the range of your YUV clip is [0,255].

2. if i open an avs script with colormatrix within virtualdub and save a frame as rgb bitmap, i got the full luma range [0,255] - exactly what i want to have, but in opposite to the docu ?
See above.

btw: HCEnc is using ITU-R BT.709 colormetry already.
so i have (not) to use it for hcenc in the opposite way than xvid, right ?
Yes.

[Ginsonic]

Sorry, that I ask again, but is there any chance to get a special version, which does not clamp to 16-235 ?

Thanks !

[Didée]

Can't decide if that makes sense at all ... but if you desperately must have it, you can do like

a = last
b = a.ColorMatrix()
c = mt_lutxy(a,b, yexpr="x 16 < x 235 > | x y ?",
\ uexpr="x 16 < x 240 > | x y ?",
\ vexpr="x 16 < x 240 > | x y ?", U=3,V=3)

and have the wished result in the "c" clip.

[Ginsonic]

Many thanks Didée, I will try !

[canuckerfan]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?

[unskinnyboy]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?
Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.

[Wilbert]

Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.
Don't forget to add mode="Rec.601->Rec.709" in that case. CCE assumes Rec.709 coefficients.

[G_M_C]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?

Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.

Don't forget to add mode="Rec.601->Rec.709" in that case. CCE assumes Rec.709 coefficients.


These three posts got me to thinking about the way DVD-RB opens its DVD files. This because DVD-RB uses all kinds of encoders, inclusing CCE and Procoder. To stream files to the encoders it generates an AviSynth script that ends with “ConvertToYUY2()”. At the moment it works like this:

Mpeg2Source (“<file>”, div.options)

<some further script options (resizing of instance)>

ConvertToYUY2()

Reading the above posts got me to thinking that something might go wrong there, because AviSynth assumes Rec.601 data when the “ConvertToYUY2()” is invoked (or another conversion), and most DVD’s i’ve checked use rec.709.

Wouldn’t it be wise to use colormatrix in DVD-RB, when opening files ? Like this:

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (hints=true)

<from here script as usual>

ConvertToYUY2()

I’ve made a posting in the DVD-Rebuilder part of this forum with this idea. But I am no expert (to say the least), maybe you can shed some light on it ?

Posting is @ : http://forum.doom9.org/showthread.php?p=879894#post879894

[unskinnyboy]

Wouldn’t it be wise to use colormatrix in DVD-RB, when opening files ? Like this:

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (hints=true)

<from here script as usual>

ConvertToYUY2()
It's better that you don't cross-post, because the answers can get scattered and discontinuous, but anyway..

Right way is :

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (mode="Rec.601->Rec.709", hints=true)

It would be wise to do this by default for the most part, yes. But not all DVDs are Rec.709 and also there is an overhead in checking for hints every time. I think it should remain optional.

[Wilbert]

@G_M_C,

These coefficients are only used in a RGB<->YUV conversion, thus not in a YV12<->YUY2 conversion (which you are dealing with when using DVD-RB).

ConvertToYUY2(matrix="rec709") might be needed when requesting RGB (by using upConv=2) from MPEG2Source. I say "might" because i'm not sure what coefficients are used by MPEG2Source to convert to RGB24.

@Neuron2,

Are the coefficients autodetected and used when requesting RGB24 from MPEG2Source?

[primusmp]

Ok I finished reading the whole post (It`s quite large..) didn´t find answer to my problem... So I`ll be testing tomorrow...

I have PAL DV edited at premiere exported to huffyuv PAL AVI then loaded in avisyth and converted to NTSC ...

Script is being modified now but it used to start with ConverttoYU2() before smoothdeinterlace was applied....

In the end it was fed to CCE... watching tha0 .avs in video player (BS player media playe.. winap.. all teh same.) played the correct levels... The CCE Mpeg 2 file produced VERY distorted levels (No noticeable change using 0-255 or 16-235) Changed CCe to "Try to use RGB" and I get the correct levels (now 0-255 and 16-235 are different also) but Encoding is slower. Tried using ColorMatrix() with several different options... (i.e 6to7 and 7to6) and it doesn´t seem to affect the cce encoding. Colormatrix() line is placed rigth after the resize...

NOTES: when I say "No noticealbe change" it actually means "It`s 2 in the morning and I do not have time to actually pay attention to minor changes" and when it says "VERY distorted" I really mean VERY distorted like oversaturated and really darker...

I`ll send some pics tomorrow and if I find out what the f**k`s going on I`ll let you know.

Please apologize my english It`s not the best it can get but hey... Ive been working for the last 48 ours straight and Im really tired.

[tritical]

@Wilbert
With upConv=2, dgdecode does detect and use the coefficients indicated by the matrix_coefficients value to perform the conversion to rgb. (This is not the case for previous mpeg2decx.dlls that could deliver rgb).

[tritical]

[link removed, read down for a newer version], finally finshed the new version I mentioned back in January. Changes from v1.10:
+ Rewrote a large portion of the code
+ Added ability to convert between any of: Rec.709, FCC, Rec.601, and SMPTE 240M
+ Added source and dest parameters
+ Added scaling parameter (optional clipping and unscaled coefficients)
+ d2v option supports changing colorimetry info (with trim() and frame rearrangement restriction)
- fixed a problem with calculated luma values that were < 0 being set to 255 instead of 0

Main items are ColorMatrix can now convert between any of: Rec.709, FCC, Rec.601, and SMPTE 240M... everything in the mpeg2 specs. The pre/post clipping with limiter is optional, and there is also the option to use non-scaled coefficients if desired. The d2v option supports changing colorimetry (though there are still a few restrictions with using trim() and the like beforehand -- see the read me). The new syntax is:

ColorMatrix(clip, string "mode", int "source", int "dest", int "scaling", bool "interlaced", bool "hints", string "d2v", bool "debug", int "opt")

[G_M_C]

The downloadlink times-out for me, guess the whole world is getting an update :P

[Adub]

Shouldn't you update the title of the thread?
And maybe your website?

[tritical]

hm, I had updated my website but the university's servers had a little outage around then and I guess something screwy happened. Anyways, it's updated now. I can't edit the thread title since it isn't mine. I opted not to post this in a separate thread so that all the ColorMatrix related info would stay together.

[Alain2]

A few questions..
- When using colormatrix with the d2v parameter, do we still have to specify the interlace parameter ?

If so:
- If a PAL interlaced source, for a progressive one I suppose the interlace parameter should be set to false ?
But for a NTSC source, if the d2v was done with honor pulldown flags", should the interlaced parameter be true or false ? Same question for a d2v in forced film ?

I have these questions because the d2v analysed is showing fields, not frames I think, so I am not sure how the interlace parameter is used..

Thanks

[Wilbert]

A few questions..
- When using colormatrix with the d2v parameter, do we still have to specify the interlace parameter ?
Yes.

for a progressive one I suppose the interlace parameter should be set to false ?
Yes.

But for a NTSC source, if the d2v was done with honor pulldown flags", should the interlaced parameter be true or false ? Same question for a d2v in forced film ?
That's a good one. You need to make it progressive first by inverse telecining it. Note that the first frame is not altered by the ivtc process (the first few bytes are altered in the first frame when using hints in dgdecode), so you can use ColorMatrix directly after doing the inverse telecine.

[canuckerfan]

I tried the above suggestion, to use colormatrix after IVTC, but it says no hints detected in red text. It worked fine when I called it before IVTC. here's my script:

mpeg2source("E:\Video\Hindi Movies\Dil.Chahta.Hai.2001.DVD9-bj1988\temp\slow.d2v",idct=5,info=3)

Setmemorymax(512)

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

ColorMatrix(mode="Rec.601->Rec.709",hints=true)

DeSpot(pwidth=65,pheight=65,p1=35,p2=14,mthres=25)
RemoveDirt()

Tweak(sat=1.12,cont=1.12,bright=10.4)

FFT3DFilter(sigma=2.2,ow=48/2,oh=48/2)
Dehalo_alpha()
LimitedSharpenFaster(Smode=4,Lmode=2,overshoot=14,strength=200)

Crop(0,48,0,-48)
AddBorders(0,48,0,48)

ConvertToYUY2()

[Alain2]

Ok, so if I understand well:

- in case of a d2v in forced film, then I get a progressive clip out of mpeg2source, and thus set interlaced=false in colormatrix ?

- in case of a d2v in honor pulldown flags, then I have a telecined clip. You say it's better to ivtc first (with tfm+tdecimate for instance) before applying colormatrix, so in that case the d2v won't have the same number of frames than what is fed through colormatrix.
-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
-- If I don't ivtc first but place colormatrix with d2v=.. and interlaced=true immediately after mpeg2source, would that be a worse solution and why ?

[Wilbert]

- in case of a d2v in forced film, then I get a progressive clip out of mpeg2source, and thus set interlaced=false in colormatrix ?
Yes.

- in case of a d2v in honor pulldown flags, then I have a telecined clip. You say it's better to ivtc first (with tfm+tdecimate for instance) before applying colormatrix, so in that case the d2v won't have the same number of frames than what is fed through colormatrix.
Yes.

-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
I never thought about this, but i guess that means yes indeed.

-- If I don't ivtc first but place colormatrix with d2v=.. and interlaced=true immediately after mpeg2source, would that be a worse solution and why ?
Yes, a little bit worse. The chroma of the clip will be blurred more in that case (because it's being treated as interlaced).

@canuckerfan,

I tried the above suggestion, to use colormatrix after IVTC, but it says no hints detected in red text. It worked fine when I called it before IVTC. here's my script:
I'm not sure why, but perhaps tritical can explain. In any case, you can store the hints in a different clip:


Setmemorymax(512)

mpeg2source("E:\Video\Hindi Movies\Dil.Chahta.Hai.2001.DVD9-bj1988\temp\slow.d2v",idct=5,info=3)
savedHints = last
AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

MergeHints(hintClip=savedHints) # add hints back for use with ColorMatrix
ColorMatrix(mode="Rec.601->Rec.709",hints=true)

DeSpot(pwidth=65,pheight=65,p1=35,p2=14,mthres=25)
RemoveDirt()

Tweak(sat=1.12,cont=1.12,bright=10.4)

FFT3DFilter(sigma=2.2,ow=48/2,oh=48/2)
Dehalo_alpha()
LimitedSharpenFaster(Smode=4,Lmode=2,overshoot=14,strength=200)

Crop(0,48,0,-48)
AddBorders(0,48,0,48)

ConvertToYUY2()

[tritical]

-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
You can still use the d2v parameter as long as the colorimetry doesn't change at some point in the d2v. The same number of frames requirement is only enforced if colormatrix detects that the colorimetry does indeed change in the d2v file. That requirement is checked for during filter construction, so if you are able to load the script without an error then everything is fine. In the case that the colorimetry does change, colormatrix has to correctly match up input frames to frames in the d2v file to determine which frames need which conversion... thus the requirement that the number of frames be the same.

@canuckerfan
The hints wont survive tfm because by default it writes its own hints into the same bytes that dgdecode uses for hints. Unfortunately, the mergehints() workaround that Wilbert posted wont work correctly either since the frames in the saved clip wont match up with the frames after ivtc... which would be required to correctly handle changing colorimetry. If the colorimetry didn't change, then it would be fine, but in that case you could just use the d2v parameter.

[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.

[HeadBangeR77]

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.
Thanks very much for your explanation. This has always been confusing to me. Please tell me, in simple words, if I think correctly then:
- the so called TV-scale bug while using VMR9 render always makes the colours look terrible (washed out, dimmed, undersaturated etc. - we all know that, don't we?);
- since dgindex/dgdecode assumes yuv 16-235 range (actually tv scale), though PC scale is selected (now I finally know why), then watching the material in overlay, or using VMR7 windowed, displays the actual source colour-range, which is in fact tv scale, right?
- why do the colours in VMR9 look so terrible then (unless we convert YUV to RGB, e.g. with ffdshow)? have they been scaled twice or sth?

Hope I haven't messed everything up too much. :o

If you are working with dvd footage then you should use scaling=0 or 1.
Again, thanks, got to remember that.

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.
But they are clamped to that range form the beginning, by dgindex/dgdecode, aren't they? So would using scaling=0 and scaling=1 would result in any visible difference?

Thanks in advance - I'm not a noob in general, but I'm a total noob to ColorMatrix. ;)

[tritical]

- why do the colours in VMR9 look so terrible then (unless we convert YUV to RGB, e.g. with ffdshow)? have they been scaled twice or sth?
My understanding (based off http://www.virtualdub.org/blog/pivot/entry.php?id=92) is that the problem arises because the renderer thinks the input yuv is 0-255 when it is actually 16-235/16-240. The yuv->rgb conversion in ffdshow assumes the input yuv is 16-235/16-240.

But they are clamped to that range form the beginning, by dgindex/dgdecode, aren't they? So would using scaling=0 and scaling=1 would result in any visible difference?
dgdecode does no clamping. So it is possible to get values in the range 0-255 out of dgdecode which will result in differences between scaling=0/1 in colormatrix.

However, now that I've thought about it, there shouldn't be any significant difference between using scaling=2 vs scaling=1 in colormatrix on yuv data that is 16-235/16-240 since it simulates a full trip from yuv to rgb and back. The incorrect assumption of 0-255 data wont matter since the conversion back will make the same incorrect assumption. Thus, the only differences should be due to rounding (+-1 maximum).

This same reasoning is true for using scaling=1 instead of scaling=2 on true 0-255 yuv data (that the incorrect assumption will correct itself on the way back to yuv), except that here the 16-235->0-255 mapping (or range expansion) will mean that values outside the 16-235 range wont be handled correctly. So there would be problems with using scaling=1 on true 0-255 yuv data.

EDIT: Actually, since colormatrix doesn't round anything until the final coefficient calculation, the scaled vs. unscaled coefficients should be unnecessary. Whatever scaling you used would always cancel itself out. So scaling = 1/2 should always be exactly the same regardless of the input. I'll have to test this theory out :).

[Jeremy Duncan]

Tritical,

I own the Getgray caldisk;
Link (http://calibrate.tv)

Using the green ramp color bars. I took two different screen shots using scaling 1 and scaling 2, then I compared the two to spot any differences.

The scaling=2 bars change in color tone from dark to light was different from scaling=1.
Scaling=2 seemed to have a better result.

[JarrettH]

Should I use ColorMatrix if I am watching XviD, DivX stuff? And should I use it all the time in MeGUI for making x264 encodes?

[tritical]

Using the green ramp color bars. I took two different screen shots using scaling 1 and scaling 2, then I compared the two to spot any differences.

The scaling=2 bars change in color tone from dark to light was different from scaling=1.
Scaling=2 seemed to have a better result.

Could you do:

source()
d1 = colormatrix(scaling=1)
d2 = colormatrix(scaling=2)
subtract(d1,d2)
coloryuv(analyze=true)

That way we would know what the actual pixel differences are instead of relying on looking at a picture.

Should I use ColorMatrix if I am watching XviD, DivX stuff? Depends on what the colorimetry is. If it was originally not Rec.601 and was encoded as is then yes (but you'd have to know the original colorimetry).

And should I use it all the time in MeGUI for making x264 encodes?
Yep, though if the source is already Rec.601 then it isn't truely needed (though that will be autodetected since iirc megui sets colormatrix to read hints from dgdecode).

[Sharro]

Just an alert here for those relying on Gspot to check colorimetry.

I already found two dvd where Gspot interpreted the colorimetry as I470 but after checking the d2v with mpeg2source(***,info=1) it turned out that only the logos of the studios were I470, the rest of the movie was BT709.

I also found two dvd's that were Rec.601 (Star Wars EP2 and EP3), I wonder if it's common...

@tritical: How much can we rely on the info written on the mpeg2 stream that the d2v reports on mpeg2source(***,info=1) and if it's a reliable source couldn't you create an "auto" mode with just the destination colorimetry desired ? As far as I understood only the ones that match source=* will be processed.

All the best,

Sharro

[Wilbert]

@tritical: How much can we rely on the info written on the mpeg2 stream that the d2v reports on mpeg2source(***,info=1)
Such questions are always nice questions to discuss :) I'm not aware of any examples which are wrong.

and if it's a reliable source couldn't you create an "auto" mode with just the destination colorimetry desired ?
Use hints=true, dest=0 or 2 (default) and interlaced=true for interlaced stuff.

[Jeremy Duncan]

http://img213.imageshack.us/img213/6321/bluecr6.jpg
http://img292.imageshack.us/img292/1154/blue2nl1.jpg
http://img452.imageshack.us/img452/7244/greenbh1.jpg
http://img452.imageshack.us/img452/131/redpk4.jpg

Rapidshare (http://rapidshare.com/files/14784872/Colormatrix.zip.html)

I took two blue pictures because the number was changing, but it's the same pattern on the Getgray Caldisc.
http://calibrate.tv

I'm using Media player classic, default output, and the dscaler video codec using output YV12.
I'm also using reclock and the FFDshow audio decoder, as shown in the walkthrough I made.
I used no other filter in FFDshow when I took the tests.
The input colorspace I used in FFDshow was all supported, the output colorspace was YV12.
I used FFDshow version clsid rev866, MPC 6.4.9.0, DScaler 5.0.0.8

This is the edited code I used in FFDshow Avisynth. I played the dvd directly without ripping it.
I get an error if I use source() as well.

d1 = colormatrix(scaling=1)
d2 = colormatrix(scaling=2)
subtract(d1,d2)
coloryuv(analyze=true)

[tritical]

Thanks. All of those pictures indicate that the chroma is exactly the same and the luma differences are limited to +-1, which would indicate that they are only due to rounding differences. I've gotten the same results. I'm not sure where the rounding differences between scaling=1/2 are coming from though. I'll have to investigate that. But since it appears that the coefficient scaling differences are unnecessary I'll probably replace the 'scaling' parameter with a boolean 'clamp' parameter in the next release that would simply control whether limiter is used before/after or not.

[Jeremy Duncan]

Tritical,

When you release the next version of Colormatrix with the change to Clamp. Could you please write in the readme which clamp setting to use for dvd's. :)

[leiming2006]

If I don't change the colorspace in avs scripts (like from mpeg2source to return all in YV12), do I still need to use this filter?
regards,
LeiMing

[Sharro]

Such questions are always nice questions to discuss :) I'm not aware of any examples which are wrong.


Use hints=true, dest=0 or 2 (default) and interlaced=true for interlaced stuff.

Thanks Wilbert.

I use the d2v="***.d2v" instead of hints but probably my question was just too short and I should have better explained it.

As far as I understood, the hints (or d2v=) with, for example, source=0,dest=2 will leave any colorimetry different than 0 untouched right ?

So I wondered that based on the hints (or the d2v=) we can't just define dest=* and any colorimetry different than dest would be converted to dest.

I had a movie with I470 (could be other colorimetry, this case was the studio logos but could be anything else) and BT709 (the movie itself) if I got it right with source=0,dest=2 just the BT709
was converted to Rec.601 right ? How could we convert any colorimetry (within the same mpeg2 stream) different than source=0 to dest=2 ? With ranges ? Couldn't it be done in an easier way ?

I hope to have better explained my idea.

All the best,

Sharro

[tritical]

@Sharro
hints/d2v already work as you are describing in your idea. They detect from the d2v or the hints what the source colorimetry is, and if it is different than the destination colorimetry then they apply the needed conversion (the conversion is changed on a frame by frame basis as needed in case the source colorimetry detected changes). hints/d2v pay no attention to what source is set to. Perhaps a better explanation is needed in the readme.

@leiming2006
It depends. If the source is not the same colorimetry as the software or hardware you will be using to play it back (whatever eventually does the conversion to rgb) assumes it is then you will need to use colormatrix. It all has to do with what colorimetry is assumed when the eventual conversion to rgb occurs. If rgb is converted to yuv using one set of coefficients and the yuv is later converted back to rgb using a different set then this is where problems arise and is the reason colormatrix exists (since most software/hardware assume one specific set of coefficients and cannot use others). In the pc playback chain rec.601 is almost always assumed, but the typical dvd uses rec.709.

[Sharro]

@Sharro
.... Perhaps a better explanation is needed in the readme.


I guess so, now that I read very carefully it is there, but could be a bit more clear.

Sorry.


@leiming2006
...In the pc playback chain rec.601 is almost always assumed, but the typical dvd uses rec.709.

Star Wars EpII and EpIII Pal DVD's were funny, they were Rec.601 all the way through, I've not found any other like these.

I have no idea how dvd players handle the colorimetry flags (do they make any conversion?), could anybody enlighten me ? I encode for PC and Standalone playback.

All the best,

Sharro

[wolfsoft]

If I don't change the colorspace in avs scripts (like from mpeg2source to return all in YV12), do I still need to use this filter?
regards,
LeiMing

Sigh~~I just said at popgo many days ago that you need not to use it for ripping the japanese anime dvd. However, you don't rip HDTV and American DVD, do you?

[wolfsoft]

Star Wars EpII and EpIII Pal DVD's were funny, they were Rec.601 all the way through, I've not found any other like these.

I have no idea how dvd's handle the colorimetry flags (do they make any conversion?), could anybody enlighten me ? I encode for PC and Standalone playback.


If there are the flags in the stream of MPEG2, DGindex will take the flags in it's hints. If there aren't, DGindex will set it to rec.709.

Many DVD's stream haven't been marked the flags of colorimetry, but they are exactly the rec.601, just like the Japanese Anime DVDs. If you take this kind of DVDs, and you deal with YV12, you would not to use this filter.

[wolfsoft]

For addtion that we can check the colormetry flags by Gspot

[Wilbert]

Many DVD's stream haven't been marked the flags of colorimetry, but they are exactly the rec.601
Could you upload a vob with about 10 frames of such a stream?

[Sharro]

For addtion that we can check the colormetry flags by Gspot

Do not trust Gspot for colorimetry flags, see a few posts up (#306).

Gspot reports only the colorimetry flags he finds in the first frames, if they change afterward it won't detect it or do it incorrectly.

I prefer mpeg2source(****,info=1) and play the avs in vdub or mplayerc.

Just my 5 cents.

All the best,

Sharro

[wolfsoft]

@Sharro,maybe the flags in the movie of your DVD are blank. I said that DGindex always marks the blank flags as BT709, despite it's exactly rec.601.You would encode some clips by CCE. It also be recognized as BT709.

@Wilbert,of couse I did. In fact, the Japanese Anime DVDs still store data by rec.601.

[Wilbert]

@Wilbert,of couse I did. In fact, the Japanese Anime DVDs still store data by rec.601.
? I just asked for an example vob, so that i can check myself.

[Bankis]

It's better to put ColorMatrix after IVTC, but
where is the best place for ColorMatrix of interlaced video material (NTSC)?

after mpeg2source:

mpeg2source(info=3)
colormatrix(hints=true,interlaced=true)
... deinterlacing...

OR after deinterlacing (with taking care of hints):

mpeg2source(info=3)
... deinterlacing... # somehow save hints ;)
colormatrix(hints=true)

OR at the script end:

mpeg2source(info=3)
... deinterlacing... # somehow save hints ;)
... denoising, downsizing & etc ....
colormatrix(hints=true)

? I have seen all cases, but not sure which one is correct?


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

[tritical]

There isn't really one correct way. I think you'd be hard pressed to spot the differences between using it before with interlaced=true or after with interlaced=false. Theoretically, if the deinterlacing was perfect then it would be better to use it afterwards since the sampling points for the chroma would be closer to the corresponding luma points (the same reasoning that says for telecined sources that it's better to field match and then convert to yuy2 with a progressive conversion than to convert to yuy2 with an interlaced conversion and then do field matching). Also, if the colorimetry doesn't change you'd be better off using d2v="" instead of hints since it is faster and doesn't require that hints make it through processing.

[Adub]

Yo Tritical!
Have you kept up with the MT avisynth thread?

If not, here is the deal. Colormatrix 2.1 and the latest version of MT Avisynth 2.5.7 create a crash.

Here are the specifics, including scripts that can produce the crash. Do you know how to fix this?

http://forum.doom9.org/showthread.php?p=945634#post945634


I looked into the crash report and it seems that Decomb.dll is choking on some output of Colormatrix 2.1.

[tritical]

I have been following the discussion, but my dual core comp is currently running some experiments that utilize avisynth.dll and that wont be finished processing for at least 4 or 5 more days. I can test it on my laptop (single core) using multiple threads and see what happens though.

EDIT: well, it wont crash on my laptop so I can't do any testing until my other comp is finished. Although I did notice one problem... in the first script in the post you linked to you are using colormatrix before doing ivtc, in which case you need to use interlaced=true in colormatrix.

[Adub]

Well the reason that I didn't do that, the interlaced=true part, is that I trusted MeGUI to know best and do what it was supposed to. Apparently, it doesn't add such a thing.

I will run a few tests with the interlaced=true bit and see what happens.

[DanielSun]

I'm confused about that "clamp" option,
what exactly does this option do and what purpose does it serve?
Or just put it in a easy way,should it be used when doing a DVD to XviD/X264 rip?

Thx!
Dan.

[kumi]

I'm going blind trying to see a difference between Rec.601 and Rec.709 with this script:

loadplugin("C:\Program Files\dgmpgdec\DGDecode.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix\ColorMatrix.dll")
mpeg2source("G:\temp\Rec.601.d2v")
rec601 = last
rec709 = ColorMatrix(mode="Rec.601->Rec.709")
interleave(rec601, rec709)

I've previewed this with various Rec.601 MPEG-2 streams in VDub/AvsP, but I just can't see any difference. Is Rec.601->Rec.709 supposed to be a such a subtle conversion? Maybe my eyes just aren't the spring chickens they used to be... ;)

Can someone upload a short Rec.601 clip that will show a difference when converted to Rec.709? I would greatly appreciate it.

Cheers

[HeadBangeR77]

Can someone upload a short Rec.601 clip that will show a difference when converted to Rec.709? I would greatly appreciate it.
You can't see any difference, and I can (if you want I could upload a few screenshots later on). However, using ColorMatrix (tried everything, with hints, with d2v, default, manual changes etc.) the samples look over-saturated to my eyes. Some colours really look better, while there's definitely too much red overall, what increases colour bleeding and stair-stepping, unless converted to RGB32. The source is MPEG-2, and it's Rec. 709 for sure.

:confused:

[kumi]

Thanks HeadBangeR77, screenshots would be nice.

Now that I think about it, maybe I'm comparing these clips in the wrong way. My whole purpose of converting to Rec.709 is to feed MPEG-2 into HC for encoding. So I should be comparing the original Rec.601 stream to the final HC-encoded product. Or does it not make a difference?

[HeadBangeR77]

Thanks HeadBangeR77, screenshots would be nice.
I'm gonna look for them on the 20 DVDs I've recently burnt (full of samples :D).

Now that I think about it, maybe I'm comparing these clips in the wrong way. My whole purpose of converting to Rec.709 is to feed MPEG-2 into HC for encoding. So I should be comparing the original Rec.601 stream to the final HC-encoded product. Or does it not make a difference?
The matter is, the original MPEG-2 stream is usually Rec.709 already (or some other colorimetry - have a look at the ColorMatrix documentation under "Colorimetry"), that is displayed as Rec.601 with some players (somebody more experienced plz correct me, if I'm wrong), and is encoded as Rec.601. So the idea that lies behind this plugin is to reconstruct the original colours (it's much better explained in the docs ;)). I don't think you're doing anything wrong by comparing en encode with, and without the ColorMatrix.

My samples comes from the source that's originally ITU-R BT.709, at least according to the info.

[HeadBangeR77]

1) VOB - MPC (latest Celtic Druid's build), ffdshow (I can't recall the revision, but it was from December/January) libmpeg2 decoding, high quality YUV to RGB32 conversion.

2) AVI - an old encode of mine, without ColorMatrix, ffdshow & RGB32 as above; looks the same as the original.

3) AVSP preview - default - just ColorMatrix("Rec.709->Rec.601") .

4) AVSP preview - with hints enabled, default scaling.

5) AVI - a sample encode with ColorMatrix("Rec.709->Rec.601") .

http://xasonline.info/headbanger/Colormatrix.rar

(should be active within a few minutes)

Oops, I've just marked you're doing "Rec.601->Rec.709", so exactly the opposite to what I was doing. Sorry!
Btw. Are you sure your source (MPEG-2) is Rec.601???

[kumi]

Yep, dgdecode tells me it's SMPTE 170M. I have quite a few DVDs with these coefficients, although the majority are Rec.709.

I'm really puzzled now. I had assumed the purpose of Colormatrix() was to preserve the original's color balance, as it passes through an encoder. But that's not at all what I'm seeing.

Here's a DVD that dgdecode says is SMPTE 170M:

http://img58.imageshack.us/img58/6976/rec601va9.th.png (http://img58.imageshack.us/img58/6976/rec601va9.png)

Since I'm going to re-encode it with HC, which uses Rec.709 coefficients, I add ColorMatrix(mode="Rec.601->Rec.709") to the script.

This is the .AVS and the final HC output (both are the same, like you predicted):

http://img240.imageshack.us/img240/6711/rec601torec709rn8.th.png (http://img240.imageshack.us/img240/6711/rec601torec709rn8.png) http://img460.imageshack.us/img460/9160/hcrec709lu0.th.png (http://img460.imageshack.us/img460/9160/hcrec709lu0.png)

The converted clip is clearly different from what's on the DVD... less saturated, I guess you could say.

So, is Colormatrix() restoring what the original master looked like, or is it introducing changes on it's own? Did the studio make a mistake when encoding, and that's what Colormatrix() is fixing?

Sincerely,
Confused in Ohio :p

[Sharro]

...colour bleeding and stair-stepping,
:confused:

HeadBangeR77 could you try decoding those videos where you see that with Xvid decoder force output to YV12 and tell me the result ?

All the best,

Sharro

[HeadBangeR77]

Yep, dgdecode tells me it's SMPTE 170M. I have quite a few DVDs with these coefficients, although the majority are Rec.709.
Ok, I see, it's rather atypical, and I've reacted too quickly. ;)

I'm really puzzled now. I had assumed the purpose of Colormatrix() was to preserve the original's color balance, as it passes through an encoder. But that's not at all what I'm seeing...
(...) The converted clip is clearly different from what's on the DVD... less saturated, I guess you could say.
Did you take a look at my screen captures? It's exactly the same as in your case. The colours are the same while watching the original MPEG-2 with MPC (and e.g. with PowerDVD - no screen caps because of hardware acceleration) and an encode without ColorMatrix (or a preview without it). When using the plugin I've got the reverse effect of what you're getting, but it's different than the source (either played or previewed with AVSP or VDub), so I'm totally puzzled.

:confused:

So, is Colormatrix() restoring what the original master looked like, or is it introducing changes on it's own? Did the studio make a mistake when encoding, and that's what Colormatrix() is fixing?
That's exactly what I would like to know too.

@ Sharro:
I was using ffdshow YV12 -> RGB32. Did you have a look at the screenshots btw? Since colour bleeding and stair-stepping, as a result of chroma sub-sampling, is normal for YV12, it disappears partially with YUY2 (that's what I use normally), but can only be eliminated with RGB. What I meant above was the fact - the brighter the red the more visible those artefacts are (as in JPEGs with chroma sub-sampling). Since I get much brighter red colours with ColorMatrix, the effect is more visible, but it isn't sth' caused by the plug-in; it's "natural".
If you asked for sth' else, than plz PM me. ;)

These screenshots (http://xasonline.info/headbanger/Colorspaces.rar) show the difference very well (as well as the VMR9 TV-scale bug). The name of each file tells everything about the render used and forced colour space).

[kumi]

When using the plugin I've got the reverse effect of what you're getting, but it's different than the source (either played or previewed with AVSP or VDub), so I'm totally puzzled.I think that's because you're doing "Rec.709->Rec.601", while I'm doing the opposite.

[HeadBangeR77]

I think that's because you're doing "Rec.709->Rec.601", while I'm doing the opposite.
Yeah, that's I think too. The problem is, this way or another, it's different from the decoded original.

[foxyshadis]

I'm confused about that "clamp" option,
what exactly does this option do and what purpose does it serve?
Or just put it in a easy way,should it be used when doing a DVD to XviD/X264 rip?

Thx!
Dan.

Clamp removes everything below 16 and above 240 from the luma (and 16/235 from the chroma), which are outside the gamut of the normal yuv-to-rgb conversion.

[DanielSun]

@foxyshadis

Thanks, though I'm still curious if this Clamp is a standard operation and if i do not perform this operation what would happen.

@kumi & HeadBangeR77 & others

I have a TS "colorbars" source which is suppose to be Rec709.
And i Played it with MPC,MPEG2 decoder is Gabest decoder(Reported "MPV Decoder" in MPC),and it is output YV12 to VMR9 renderer in my graph.
So i guess in this case the YUV->RGB convertion was done by VMR9. And I've read the whole thread, if I get the point right,VMR9's output color should be wrong(off color) because it assumes Rec601 when converting YUV->RGB.
But when i checked the snapshot of the output image,the colors are correct,or nearly correct.

Standard color bar should have a black level of RGB(161616) and i got (16 15 16);
Standard color bar should have a Red level of RGB(180 16 16) and i got (181 15 16)
Standard color bar should have a blue level of RGB(16 16 180) and i got (15 15 179)
Standard color bar should have a green level of RGB(16 180 180) and i have (16 175 14)<---this is a larger difference though but I still assumes it is right because I think if the colormatrix was unmatched the difference should be even larger?
Standard color bar should have a yellow level of RGB(180 180 16) and i got (180 175 15)<---still, this should be considered correct,right?
Standard color bar should have a cyan level of RGB(16 180 180) and i got (15 175 178)
Standard color bar should have a purple level of RGB(180 16 180) and i got (180 15 179)

So if this result can be considered correct, a problem rises.
I think there are 3 explanations for this:

1)MPV decoder have some functions like colormatrix(), it already corrected the YUV color beforce sending it to VMR9.

2) VMR9 uses Rec709 when converting YUV to RGB

3)The source was supposed to be Rec709,but it is indeed Rec601.<---this seems to be a desperate one :)

The question is which is true?Or none of them is true, then there must be some other explanations I missed.

THX!
Dan

[kumi]

@DanielSun:

I was following Wilbert's recommendation in the opening post of this thread to use VDubMod for previewing/screenshotting. What the MPV decoder and VMR9 renderer do with colors is a mystery to me... I just want to see what my standalone players will see.

[Wilbert]

I'm really puzzled now. I had assumed the purpose of Colormatrix() was to preserve the original's color balance, as it passes through an encoder. But that's not at all what I'm seeing.
Yes, that's true. Could you upload a small vob (say 10 frames), then i can look at it?

So, is Colormatrix() restoring what the original master looked like
Yes. Well, more exactly: is changes the clip in such a way that the decoder shows it (after YUV->RGB conversion) as what the original master looked like.

[kumi]

Thanks Wilbert, here's a VOB snippet from the DVD (Uzumaki R3 HK). DGDecode says it's SMTPE 170M. Same source as the screenshots I posted earlier:

http://hachirota.googlepages.com/VTS_01_1.VOB (4MB)


Yes. Well, more exactly: is changes the clip in such a way that the decoder shows it (after YUV->RGB conversion) as what the original master looked like.Ah! This leads me to ask: how can I best 'emulate' in AviSynth what I will see when I playback on a standalone device?

Do I add one of these to the end of the filter chain?

ConvertToRGB(matrix="Rec709") or
ConvertToRGB32(matrix="Rec709") or
SomethingElse() ?

[Jack Cox]

@Wilbert,of couse I did. In fact, the Japanese Anime DVDs still store data by rec.601.

That's not true. I have quite a few of them that are rec.709 and a few that are SMPTE 170 as well. Sure a large number of them may be rec.601, but to make such a blanket statement as if they all are is just patently false. I can provide pictures as proof to show this.

[DanielSun]

That's not true. I have quite a few of them that are rec.709 and a few that are SMPTE 170 as well. Sure a large number of them may be rec.601, but to make such a blanket statement as if they all are is just patently false. I can provide pictures as proof to show this.

Please do!

And is there some kind of principle to follow when the stream has no color coefficients flag since it isn't true to assume they are all Rec709?

[Jack Cox]

Please do!

And is there some kind of principle to follow when the stream has no color coefficients flag since it isn't true to assume they are all Rec709?

What I do is this. Load the straight vobs into Vdub. Then I load the vobs both without colormatrix and with colormatrix. If the colors match with colormatrix rather than without it's rec.709 otherwise its not. This works because I've tried it against those DVDs that are rec.601 and SMPTE 170M and if I use colormatrix on those it doesn't match the look of the vob that's loaded straight into Vdub while without it does. Here's a couple of examples to show this:

Anime DVD that is SMPTE 170M (showing the colorimetry info from mpeg2source) and that isn't the only one I have that is like this:

http://img169.imageshack.us/img169/4061/colorimetryjg2.jpg

Vob loaded directly into vdub:

http://img338.imageshack.us/img338/8799/directlyloadedaq0.jpg

Vob loaded into avisynth without colormatrix:

http://img136.imageshack.us/img136/2664/withoutcolormatrixyo2.jpg

Vob loaded into avisynth with colormatrix:

http://img147.imageshack.us/img147/853/withcolormatrixcn5.jpg

Anime DVD that shows as rec.709:

http://img299.imageshack.us/img299/9537/colorimetry2nj0.jpg

Vob loaded directly into vdub:

http://img85.imageshack.us/img85/8851/directlyloaded2tl1.jpg

Vob loaded through avisynth without colormatrix:

http://img180.imageshack.us/img180/2613/withoutcolormatrix2hx9.jpg

Vob loaded through avisynth with colormatrix:

http://img180.imageshack.us/img180/2369/withcolormatrix2wq7.jpg

So the first example demolishes the claim that only rec.601 coefficients is used on anime DVDs and also shows that if the stream is not using rec.709 coefficients then a wrong result will come from using colormatrix.

The second example is of the DVD that reports as using rec.709 coefficients. You can clearly tell that without using colormatrix that the colors are wrong (look at the reds) and with it they are correct which can only come from the fact that it really is using rec.709 coefficients. Otherwise, as the first example shows the colors would be wrong using colormatrix and correct when not using it.

[Didée]

What I do is this. Load the straight vobs into Vdub. Then I load the vobs both without colormatrix and with colormatrix. If the colors match with colormatrix rather than without it's rec.709 otherwise its not. This works because I've tried it against those DVDs that are rec.601 and SMPTE 170M and if I use colormatrix on those it doesn't match the look of the vob that's loaded straight into Vdub while without it does.

I think that your approach is flawed. By doing so, you get no certainty at all about what-is-right or what-is-wrong.
You are inherently assuming that the output is ultimately correct when loading the VOBs directly into Vdub (and are looking under wich circumstances Colormatrix matches Vdub's output). But this is not the case. Vdub has no magical way to determine the "correct" way to sample the output. The only means available to Vdub are the same that are available to Colormatrix: the colorimetry info contained in the stream. Not more, not less. And since the basic possibilities are always the same:

1) stream has colorimetry info, and it is correct
2) stream has colorimetry info, but it is wrong
3) stream doesn't have any colorimetry info

and since we never know which is the actual case (this is the problem we want to solve from the start), everything remains being guesswork.
For a methodological way to determine the right sampling routine, one would need to have some "fixed point" to hook in. Such a fixed point doeas not exist - if there was one, we wouldn't discuss all of this.

If the content you're dealing with is of type (3) or has a reasonable probability of being type (2), then the best chance prolly is compairing both sampling routines and judging which of both looks more real.

Certainty there is none.

[Jack Cox]

But I've tested this against cases that I know for a fact are rec.709, rec.601 and SMPTE 170M and my assumptions held up in all those cases. If it was rec.709 and I used colormatrix the colors matched, without it didn't. If it was for a fact rec.601 or SMPTE 170M they wouldn't match like in the example above if colormatrix was used. Sure there are chances it might be wrong, but as I said I've tested against many different streams where the colorimetry is known without a doubt and it all held up just like I said above so I'm pretty confident that my method is working.

[Wilbert]

@kumi,

I don't see any difference with that stream. I took a screenshot from the vob with VDubMod, and one from the following script (also using VDubMod):

Mpeg2Source("D:\Captures\ColorMatrix\VTS_01_1.d2v")
ColorMatrix(mode="Rec.601->Rec.709")
ConvertToRGB(matrix="rec709")
# frame 6


Could you tell me exactly what you did, and use the vob you uploaded above (and post some screenshots)?

[Didée]

But I've tested this against cases that I know for a fact are rec.709, rec.601 and SMPTE 170M and my assumptions held up in all those cases. If it was rec.709 and I used colormatrix the colors matched, without it didn't. If it was for a fact rec.601 or SMPTE 170M they wouldn't match like in the example above if colormatrix was used.

Yeah, sure. But you have only proved that, with a source of a *known* colorimetry, that you get the correct result when using Colormatrix in those cases where it *should* be used, and that you get a wrong result when using Colormatrix in those case were you *should not* use it. You have proved that Colormatrix is working correctly.

Of what help is this when there is no colorimetry info in the stream, or if you don't trust the info being correct?

... of no help at all, exactly.

[kumi]

Hi Wilbert,

I was using:
VDubMod 1.5.10.2
Avisynth 2.56

All screenshots taken in VDubMod:



#1 (same as #2, #5)
.VOB opened directly in VDubMod
http://hachirota.googlepages.com/vob.vdubmod.png



#2 (same as #1, #5)
MPEG2Source("G:\temp\VTS_01_1.d2v")
http://hachirota.googlepages.com/mpeg2source.png



#3 (unique)
MPEG2Source("G:\temp\VTS_01_1.d2v")
ColorMatrix("Rec.601->Rec.709", interlaced=true)
http://hachirota.googlepages.com/mpeg2source.rec601.to.rec709.png



#4 (unique)
MPEG2Source("G:\temp\VTS_01_1.d2v")
ConvertToRGB(matrix="rec709")
http://hachirota.googlepages.com/mpeg2source.converttorgb709.png



#5 (same as #1, #2)
MPEG2Source("G:\temp\VTS_01_1.d2v")
ColorMatrix("Rec.601->Rec.709", interlaced=true)
ConvertToRGB(matrix="rec709")
http://hachirota.googlepages.com/mpeg2source.rec601.to.rec709.convert.png



I was comparing #1 and #2 to #3, and there's clearly a difference. But, indeed, your script (#5) is identical to #1 & #2.

Do #4 and #5 accurately model what standalone players do with the video stream?

[Wilbert]

But, indeed, your script (#5) is identical to #1 & #2.
That's how it is supposed to be, so that's good.

About #3/#4 when opening the script

MPEG2Source("G:\temp\VTS_01_1.d2v")
ColorMatrix("Rec.601->Rec.709") # the interlaced flag is not important

in VDubMod, it is converted to RGB (upon display, but also if you save a frame as a picture). But it does so using Rec.601 coefficients (AviSynth can't pass that information to VDub/VDubMod or to any other encoder, and VDub/VDubMod uses Rec.601 in this case), while it should use Rec.709 coefficients in this case, because you applied ColorMatrix with that option.

In #5 you will let AviSynth do the proper conversion to RGB using the correct coefficients:

#5 (same as #1, #2)
MPEG2Source("G:\temp\VTS_01_1.d2v")
ColorMatrix("Rec.601->Rec.709", interlaced=true)
ConvertToRGB(matrix="rec709")

so that why #5 is the same as #1 and #2.

I hope it's a bit clear :)

[kumi]

Eureka :) Thanks for explaining.

Just one more silly question, and I'll get out of your hair:

Does script #4 represent what a player will do with a DVD with Rec.601/SMTPE 170M coefficients?

[Wilbert]

Does script #4 represent what a player will do with a DVD with Rec.601/SMTPE 170M coefficients?
No, in general, a software dvd player will use the coefficients specified in the stream itself (which is SMTPE 170M here). (I didn't investigate this, so i don't know if all popular dvd players are doing this correctly, but i assume most of them do.)

[kumi]

Ok then, I think I've finally seen the light :cool: Colormatrix() really is necessary for DVD-to-DVD encoding. Well, depending on the source and encoder coefficients of course.

Here's a Rec.601 DVD source:
MPEG2Source("C:\Rec.601.DVD.d2v").ConvertToRGB()http://hachirota.googlepages.com/Rec.601.DVD.png


Here's what HC does when fed a Rec.601 stream. It's borked!:
MPEG2Source("C:\HC.encoded.d2v").ConvertToRGB(matrix="rec709")http://hachirota.googlepages.com/Rec.601.fed.into.HC.encoder.png


And here's what HC does when fed the same stream corrected with Colormatrix(mode="Rec.601->Rec.709"). Looks just like the source:
MPEG2Source("C:\Rec.601.to.Rec.709.then.HC.encoded.d2v").ConvertToRGB(matrix="rec709")http://hachirota.googlepages.com/Rec.709.fed.into.HC.encoder.png


Wow.


@Wilbert: since I would like to avoid manually checking coefficients for each one of my DVDs, can I stack calls to ColorMatrix() to handle all possible 'conversions' to Rec.709?

MPEG2Source("C:\blah.d2v", info=3)
ColorMatrix(mode="FCC->Rec.709", hints=true)
ColorMatrix(mode="SMPTE 240M->Rec.709", hints=true)
ColorMatrix(mode="Rec.601->Rec.709", hints=true)

[Wilbert]

@Wilbert: since I would like to avoid manually checking coefficients for each one of my DVDs, can I stack calls to ColorMatrix() to handle all possible 'conversions' to Rec.709?
The easiest is to set hints=true and dest="Rec.709" (using ColorMatrix 2.1). That covers all the cases you listed.

[kumi]

Hi,

I tried that, but
MPEG2Source("G:\temp\rec.601.d2v", info=3)
ColorMatrix(dest=0, hints=true)
gives a "source and dest cannot be equal!" error.

dest="Rec.709" gives me a "named argument 'dest' had wrong type" error.

[Wilbert]

gives a "source and dest cannot be equal!" error.
Strange. It seems your source is detected as source=0, while it should be 3. Perhaps tritical can comment on this one.

[kumi]

Using the dest parameter with hints is problematic, but the mode parameter with hints corrects the coefficients as expected (and doesn't alter them if the mode target is equal to the hinted coefficients):

This converts a hinted Rec.601 source to Rec.709:
MPEG2Source("C:\rec.601.d2v", info=3)
ColorMatrix(mode="Rec.601->Rec.709", hints=true)

The same function call on a Rec.709 source seems to be a no-op:
MPEG2Source("C:\rec.709.d2v", info=3)
ColorMatrix(mode="Rec.601->Rec.709", hints=true)

[HeadBangeR77]

I've been following the discussion here to check where my problems may lie... If I get everything correctly, then:

1) If I want VDub /VDubMod /AVSP to preview my ITU-R BT.709 DVD using the right colours, then I should use a script like this one:

mpeg2source("I:\DVD\VTS_01_PGC_01_2.d2v", idct=7)
ConvertToRGB32(matrix="rec709")

because otherwise all the above applications will assume Rec.601, what will surely result in wrong colours coefficients, am I right?

2) Using the following scripts I truly get the same colours as with the above preview:

mpeg2source("I:\DVD\VTS_01_PGC_01_2.d2v", idct=7)
ColorMatrix (mode="Rec.709->Rec.601")
ConvertToRGB32(matrix="rec601")

or

mpeg2source("I:\DVD\VTS_01_PGC_01_2.d2v", idct=7, info=3)
ColorMatrix (mode="Rec.709->Rec.601",hints=true)
ConvertToRGB32(matrix="rec601")

I used to get different results from those previewed without ConvertToRGB32(matrix="rec709"), but I guess I was wrong (?).

3) Having read the last few pages once again, I still haven't got the faintest idea why MPC (built-in libmpeg2 decoding), MPC with libmpeg2 ffdshow decoding, Nero ShowTime and PowerDVD (5 & 6) display the colours as in the preview without the above conversion??? Anyone?

:confused:

Since my eyes are used to the colours I see while watching DVD, the results with ColorMatrix look a bit over-saturated to me (much brighter reds, stronger R channel, different greens and blues depending on the scene).

PS. Screenshots are on the previous page (http://forum.doom9.org/showthread.php?p=964856#post964856) - I've taken some new, if anyone is willing to take a look at them.

@ kumi:
Glad you've sorted the things out. :)

[tritical]

@kumi & Wilbert
The problem with dest vs mode is indeed a bug... it should be checking that neither hints nor d2v is being used before throwing the error about source==dest.

@All
I've read through all the latest posts, and as far as I can tell no one has discovered any true bugs have they? Only issues I'm aware of atm are the one above, and the fact that scaling=1/2 are redundant. Also, for everyone comparing colors, mpeg2source(,upconv=2) will output rgb24 using the colorimetry specified by the stream and following the progressive_frame flag.

[HanSolo00]

I've been reading and reading and I think I have things figured out. I'm having a debate with someone about encoding HD 1920x1080 Rec.709 MPEG-2 Transport Stream with x264.

As I understand it there is no difference at all between a SD 720x480 Rec.709 MPEG-2 stream and a HD 1920x1080 Rec.709 MPEG-2 stream from satellite/cable/blu-ray source; that they should both use a ColorMatrix(mode="Rec.709->Rec.601") for proper colors in the H.264 file (playback on a PC/RGB display, or HD monitor set to RGB colorspace, using either CoreAVC or FFDshow.)

Is my thinking correct? Shouldn't HD resolution Rec.709 MPEG-2 transport streams also be corrected to Rec.601 for MPEG-4 encoding? The argument I'm facing is that 'HD is supposed to be Rec.709, so you aren't encoding MPEG-4 properly if you are changing it to Rec.601'.

Edit: I didn't realize DGIndex is incorrectly reporting ITU-R BT.709 Colorimetry for MPEG-2 streams ripped from my SD-DVDs...

[HeadBangeR77]

Edit: I didn't realize DGIndex is incorrectly reporting ITU-R BT.709 Colorimetry for MPEG-2 streams ripped from my SD-DVDs...
Sorry, can't clear your doubts, as I'm pretty inexperienced with ColorMatrix myself. How did you find out that DGIndex was reporting your colorimetry wrongly? Did you compare some still frames or sth' like that?

Please, could anyone explain me, why am I getting different results using ColorMatrix than by MPEG-2 playback??? They are the same as using preview with ConvertToRGB32(matrix="rec709") or mpeg2source(..., upconv=2) , DGIndex reports the colorimetry as ITU-R BT.709, yet all software players and decoders I've tried display the colours differently (more on the previous page, screen grabs included). If someone happens to know the source, it's the 1st part of "Pirates of the Caribbean", NTSC.

many thanks in advance,
HDBR77

[Sharro]

Edit: I didn't realize DGIndex is incorrectly reporting ITU-R BT.709 Colorimetry for MPEG-2 streams ripped from my SD-DVDs...

Neither you realize neither is DGIndex reporting incorrectly, the only thing is if there is no colorimetry flag present it will assume BT.709.

I don't know about H264 but on XVID the problem is that the encoder expects to be feeded with RC.601 and this is the main reason to use ColorMatrix, I've found mpeg2 streams to be in Rec.601 (Star Wars Ep. I to III) pal .

Just my 5 cents.

All the best,

Sharro

[chainring]

Neither you realize neither is DGIndex reporting incorrectly, the only thing is if there is no colorimetry flag present it will assume BT.709.

I don't know about H264 but on XVID the problem is that the encoder expects to be feeded with RC.601 and this is the main reason to use ColorMatrix, I've found mpeg2 streams to be in Rec.601 (Star Wars Ep. I to III) pal .

Just my 5 cents.

All the best,

SharroOh, please say you're kidding about DGIndex not reporting colorimetry correctly....please.

If this is truly the case, then how do we determine it? FYI: I'm primarily messing with R1 DVD's.

[Sharro]

Ufff once and for all:

DGIndex is reporting COLORIMETRY CORRECTLY except when NO colorimetry flag is present in the stream.

Then DGindex will by default show Bt709.

All the best,

Sharro

[chainring]

Ok, that's easy to understand and I gathered that much from other posts. Is there any way to determine the colorimetry when there is NO flag in the stream? I'm assuming not...

[Sharro]

From ColorMatrix Readme.html:

How do you know which set of coefficients were used when encoding a MPEG-2 stream? Usually, the coefficient information is stored in the header of the MPEG-2 file (the "matrix_coefficients" field in the "sequence display extension"). Newer versions of GSpot will be able to read and display this information. Also, DGDecode v1.20+ (with Mpeg2source(info=1)) can be used to view it. If this extension field is not present in the header of the MPEG-2 file, the specs say we are supposed to assume the default of Rec.709

All the best,

Sharro

[chainring]

Cool, that clears it right up. I appreciate your patience and the information.

[HanSolo00]

Neither you realize neither is DGIndex reporting incorrectly, the only thing is if there is no colorimetry flag present it will assume BT.709.

I don't know about H264 but on XVID the problem is that the encoder expects to be feeded with RC.601 and this is the main reason to use ColorMatrix, I've found mpeg2 streams to be in Rec.601 (Star Wars Ep. I to III) pal .

Just my 5 cents.

All the best,

Sharro

Thank you for clarifying how DGIndex handles MPEG-2. I see now some DVDs report SMPTE 170M and others report ITU-R BT.709.

The question still remains for HD material, though. Passing the hints to AVIsynth ColorMatrix will tell it that the source HD transport stream is of course Rec.709, and as I understand it, ColorMatrix will convert that to Rec.601. for subsequent processing. Is this correct? If so, where does the Rec.601 dependency occur? Does x264 or the other H.264 encoders expect Rec.601, or is ColorMatrix even needed at all for Rec.709 MPEG-2 -> H.264 through AVIsynth?

I'll look through the other forums to see if there is any info as well.

[Keepitsimple]

going from rec.709 to rec.601 isnt lossless right? so every encode from hd-dvd has wrong colors if x264 needs rec.601 ..

[HanSolo00]

going from rec.709 to rec.601 isnt lossless right? so every encode from hd-dvd has wrong colors if x264 needs rec.601 ..
I just did a simple visual test without ColorMatrix, taking a frame from a MPEG-2 HD Rec.709 source, and the source frame looks identical in color (in MPC using MPV decoder filter) to the final x264-encoded H.264 frame (viewed using CoreAVC decoder in MPC). So, unless I'm doing something wrong, it would appear the source color is preserved through the whole x264 encoding/playback process without using ColorMatrix.

[Wilbert]

The question still remains for HD material, though. Passing the hints to AVIsynth ColorMatrix will tell it that the source HD transport stream is of course Rec.709, and as I understand it, ColorMatrix will convert that to Rec.601. for subsequent processing. Is this correct? If so, where does the Rec.601 dependency occur? Does x264 or the other H.264 encoders expect Rec.601
All MPEG-4 DEcoders expect Rec.601. That's the whole problem. If (1) the coefficients could be stored in the MPEG-4 stream (just as in any MPEG-2 stream) and (2) those coefficients are passed to the decoder then there would never be a problem.

I just did a simple visual test without ColorMatrix, taking a frame from a MPEG-2 HD Rec.709 source, and the source frame looks identical in color (in MPC using MPV decoder filter) to the final x264-encoded H.264 frame (viewed using CoreAVC decoder in MPC). So, unless I'm doing something wrong, it would appear the source color is preserved through the whole x264 encoding/playback process without using ColorMatrix.
Then you are doing something wrong. Could you upload such a small HD clip?

[HanSolo00]

Then you are doing something wrong. Could you upload such a small HD clip?
:thanks: for replying, I really appreciate it.

Here are some test files I'm playing with:

Sample Files (http://www.darkvault.org/doom9)

The sample clip is a ~5MB MPEG-2 .m2ts (from Blu-Ray) which because it is MPEG-2 HD should be Rec.709. The color in the frames I'm comparing look the same to my eyes, other than a slight difference in brightness on the H264 frame grabbed when using the 'VMR9' renderer instead of 'System Default' renderer in MPC.

When I use ColorMatrix(mode="Rec.709->Rec.601") there is a big difference in color; the image isn't nearly so dark red.

What am I doing wrong :confused:

[G_M_C]

I had a quick look at your sample AVS; Why are you using DirectShowSource ? Isnt it possible to ude DGIndex/DGMPGdec with MPEG2Source () ? When you use that, you can put in MPEG2Source (......, info=3) and colormatrix (......., info=true) wich imho should work better.

Or am i wrong here, and doesnt DGIndex work on those MPEG2 files ? (in wich case, ignore my posst ;) )

Anyway, regarding your earlier posting; Rec601 is expected by for instance XviD, and rec709 is expected by CCE. In the last case for example; When you feed rec601 to CCE you get a (much) darker image. You'll have to convert to the matrix that is required by the encoder you are going to use. Read in the forums/help-file and other places to find this out, or maybe ask about it. You'll only need to find it out once ;)

If your encoder accepts rec709, and your source is 709; Colormatrix shouldn't be needed at all, wich makes the whole affair a bit simpler :)

[HanSolo00]

I had a quick look at your sample AVS; Why are you using DirectShowSource ? Isnt it possible to ude DGIndex/DGMPGdec with MPEG2Source () ? When you use that, you can put in MPEG2Source (......, info=3) and colormatrix (......., info=true) wich imho should work better.

Or am i wrong here, and doesnt DGIndex work on those MPEG2 files ? (in wich case, ignore my posst ;) )
Well, the file isn't a regular Transport Stream (.ts), it's from a Blu-ray disc (.m2ts), and DGIndex didn't like it when I tried to open it. So, I let MeGUI decide how to open it, and it defaulted to DirectShowSource. Incidentally, I suspected something might be up with that, so I tried the same type of frame compares with a regular HD transport stream & DGIndex, and I got the same results--the colors in the source TS looked the same to me as the H264 frame when I left everything Rec.709.

Anyway, regarding your earlier posting; Rec601 is expected by for instance XviD, and rec709 is expected by CCE. In the last case for example; When you feed rec601 to CCE you get a (much) darker image. You'll have to convert to the matrix that is required by the encoder you are going to use. Read in the forums/help-file and other places to find this out, or maybe ask about it. You'll only need to find it out once ;)

If your encoder accepts rec709, and your source is 709; Colormatrix shouldn't be needed at all, wich makes the whole affair a bit simpler :)This is why I'm confused, I thought ColorMatrix is needed for Rec.709 MPEG-2->MPEG-4 encoding for proper color on playback but that isn't what I'm seeing. Probably Wilbert will know why. It's probably something dumb that I've overlooked.

[foxyshadis]

All MPEG-4 DEcoders expect Rec.601. That's the whole problem. If (1) the coefficients could be stored in the MPEG-4 stream (just as in any MPEG-2 stream) and (2) those coefficients are passed to the decoder then there would never be a problem.

There is, actually, and x264 actually exposes those options. xvid_encraw could as well. But no software player has a way to get that information from the bitstream to the renderer, since most windows players use VIDEOINFOHEADER[2] and BITMAPINFOHEADER, with no such field, and others use their own equivalents. Like range conversion, it seems hard to get anyone to care about it. =\

FFDshow could probably stand to properly decode AVC with the VUI flags set, though. I'll file an enhancement request, and hope someone might know how to get that info out of lavc.

[Wilbert]

FFDshow could probably stand to properly decode AVC with the VUI flags set, though. I'll file an enhancement request, and hope someone might know how to get that info out of lavc.
Keep me updated!

@HanSolo00, I will look at your sample. Btw, I have seen some MPEG-2 HD streams that are not Rec.709.

[HeadBangeR77]

DGIndex is reporting COLORIMETRY CORRECTLY except when NO colorimetry flag is present in the stream. Then DGindex will by default show Bt709.
Since I'm not getting any colorimetry info with G-Spot nor MediaInfo, AVInaptic isn't useful for MPEG-2 streams, and DGIndex shows BT.709, then I can assume there isn't any colorimetry information in the video stream I've written about above. Hence, as Didee mentioned once, it could be anything.

Could I assume then, that the colours displayed by all software DVD players/decoders I use are the correct ones? In such a case I should encode without Colormatrix, since it alters the colours differently from those seen by MPEG-2 playback. Or am I missing sth' obvious here? I'm already tired of all this. :/

Thanks in advance,
HDBR77

[Wilbert]

Since I'm not getting any colorimetry info with G-Spot nor MediaInfo, AVInaptic isn't useful for MPEG-2 streams, and DGIndex shows BT.709, then I can assume there isn't any colorimetry information in the video stream I've written about above. Hence, as Didee mentioned once, it could be anything.
Like Sharro said, and like i wrote in the readme file:

If this extension field is not present in the header of the MPEG-2 file, the specs say we are supposed to assume the default of Rec.709.
So in that case it could NOT by anything, but it should be Rec.709.

[HeadBangeR77]

Like Sharro said, and like i wrote in the readme file... So in that case it could NOT by anything, but it should be Rec.709.
Excuse me, Wilbert, but I've read the Readme-file and the last few pages more than once, so I really know, that your assumption is Rec.709, and why you've decided to choose this way. I wrote: "it could be anything" - maybe too strong use of modal verbs, I'm gonna try again then: "it might be anything, although it should be Rec.709".

Now plz, could sb' answer straight: May I assume in such a case, that the decoded MPEG-2 stream is properly decoded as to colorimetry by all the applications /decoders I've mentioned at least twice over the last two pages? If so, may I assume the colours from the original source are Rec.601 then, since I'm getting identical results with MPEG-4 sample encodes without ColorMatrix?

Thanks in advance, and I promise not to interfere in this thread again.

[kumi]

HeadBangeR77: I'm having a hard time understanding your problem. You want to know if various MPEG2 decoders correctly display colors on a clip with unspecified colorimetry?

If they follow the spec, and the source was indeed encoded with Rec.709, then the decoder output should be accurate.

If they follow the spec, and the source was not encoded with Rec.709, then the decoder output should be inaccurate.

As to your question of how to determine the coefficients used in an MPEG2 clip with unspecified colorimetry, my guess is that it's just impossible to tell. Someone correct me if I'm wrong.

[HeadBangeR77]

HeadBangeR77: I'm having a hard time understanding your problem. You want to know if various MPEG2 decoders correctly display colors on a clip with unspecified colorimetry?
Hi! Yes, exactly - I already know my sample encodes without Rec.709=>Rec.601 conversion look the same as the source, yet I've just come to conclusion today (it was yesterday actually ;)) the source itself doesn't contain any colorimetry info, or so it seems at least. Hence I can't be sure the decoded video is properly displayed as to colours, if I don't know what players/decoders (PowerDVD 5 & 6, MPC with internal libmpeg2 decoding, MPC with ffdshow libmpeg2 decoding) assume in such cases.

If they follow the spec, and the source was indeed encoded with Rec.709, then the decoder output should be accurate.
If they follow the spec, and the source was not encoded with Rec.709, then the decoder output should be inaccurate.
In other words, in case there is no colorimetry info present in the stream, they assume Rec.709, right? Or at least they should - mind they never obey ITU PARs, no matter what.

As to your question of how to determine the coefficients used in an MPEG2 clip with unspecified colorimetry, my guess is that it's just impossible to tell. Someone correct me if I'm wrong.
I was just trying to find out how the original should look like. Since there's whole lot of assumptions and uncertainties in the given case, I think I will just encode the film as it is, without ColorMatrix.

:thanks: anyway ;)

[kumi]

I was just trying to find out how the original should look like. Since there's whole lot of assumptions and uncertainties in the given case, I think I will just encode the film as it is, without ColorMatrix.That's probably the right choice. If your MPEG2 source is Rec.709, encoding to MPEG4 with and without colormatrix(mode="Rec.709->Rec.601") will look different. If your source is Rec.601, both encodes should look the same.

[foxyshadis]

If it's already Rec.601 and there's no hints/d2v to stop colormatrix, it'll happily convert it. Not to any particular standard now, since it just left all that behind, but you can stack ten of them to get some very rich color, or dull if you go the other way. (At which point even blind foxy here can notice the effect, finally.)

[Wilbert]

@HeadBangerR77,

Please upload a short sample source clip.

1) VOB - MPC (latest Celtic Druid's build), ffdshow (I can't recall the revision, but it was from December/January) libmpeg2 decoding, high quality YUV to RGB32 conversion. (...)
Hi! Yes, exactly - I already know my sample encodes without Rec.709=>Rec.601 conversion look the same as the source, yet I've just come to conclusion today (...)

I'm pretty sure this is false, and you are doing the comparison incorrectly. I think the problem is that you use ffdshow's "high quality YUV to RGB32 conversion". I'm pretty sure that this conversion uses Rec.601 coefficients, and you can't choose the Rec.709 coefficients. If this is true, then of course, you won't see any difference, because in BOTH cases (and both of them are wrong) Rec.601 coefficients are used for conversion to RGB.

[HeadBangeR77]

Hello, Wilbert!

A sample is still available here, in the "Holy War" ;) thread:
http://forum.doom9.org/showpost.php?p=947397&postcount=85

If you could figure sth' out from that crappy stream, I would be very much obliged. :)
The problem is all MPEG-2 decoders, with or without the mentioned conversion (MPC's internal decoding doesn't do any conversion AFAIK, and so PowerDVD), display the source as if it was Rec.601 (they look like my sample encodes w/o ColorMatrix, or preview in VDub /AVSP without Rec.709=>Rec.601), though it's Hollywood's blockbuster, so I would expect it to be Rec.709 (or at least my nose tells me so ;)).

thanks very much in advance,
HDBR77

[HanSolo00]

Just did another little test on an HD broadcast MPEG-2 1080i transport stream. DGindex reports Rec.709 (as one would expect with HD MPEG-2), and I used DGindex to framegrab instead of MPC, thinking perhaps MPC's MPEG-2 decoder was introducing something unexpected. Then I compressed the clip to H.264 (with x264), without using ColorMatrix. The output color matches the source color exactly (visually, anyhow.)

When I instead let ColorMatrix detect and use the (Rec.709) hints from the D2V, it of course adjusts the colors (Rec.709->Rec.601) and the resulting H.264 colors don't match the source frame (difference is quite easy to see, the adjusted reds are more of an orange than the original deep red in the original Rec.709 MPEG-2 frame.)

This would seem to tell me:
1) my process for comparison is flawed because I have overlooked something (perhaps both the MPEG-2 decoder and MPEG-4 decoder assume Rec.601 even though it is Rec.709), or
2) there is no need for ColorMatrix adjustment for Rec.709 MPEG-2 -> x264 MPEG-4, because without it, the decoded H.264 color already matches the source MPEG-2 color.

[HeadBangeR77]

(...)difference is quite easy to see, the adjusted reds are more of an orange than the original deep red in the original Rec.709 MPEG-2 frame.
I already thought I was the only one crazy here. :D
I've got exactly the same results - reds are too bright and more sort of orange; have a look at greens - they also change.

This would seem to tell me:
1) my process for comparison is flawed because I have overlooked something (perhaps both the MPEG-2 decoder and MPEG-4 decoder assume Rec.601 even though it is Rec.709)
This is exactly what I'm thinking about both in your and my case, though we encode with different codecs.

cheers,
HDBR77

EDIT:
@ Wilbert,
I've come to conclusion the other sample isn't suitable enough for the task. I'm just uploading another one, with much reds and greens, about 1 minute long. I will update this post, when I've uploaded it (Force Film for 2dv project works flawlessly).

The Sample (http://xasonline.info/headbanger/BlackPearl.m2v)

PS. Don't be surprised with the poor quality - it's been shrunk a long time ago - the original lies broken into two pieces, and I'm at fixing the poor back-up atm.

[Wilbert]

EDIT:
@ Wilbert,
I've come to conclusion the other sample isn't suitable enough for the task. I'm just uploading another one, with much reds and greens, about 1 minute long. I will update this post, when I've uploaded it (Force Film for 2dv project works flawlessly).
Could you tell me exactly (meaning decoder, player, script, etc...) what i should do with your clip to make the problem visible?

If i make a screenshot of avs (with ColorMatrix(mode="Rec.709->Rec.601")) and of DGIndex, the picture is exactly the same (as it should). If i make a screenshot with MPC (playing the m2v) it is different (as it should because you didn't correct anything).

[HanSolo00]

If i make a screenshot of avs (with ColorMatrix(mode="Rec.709->Rec.601")) and of DGIndex, the picture is exactly the same (as it should). If i make a screenshot with MPC (playing the m2v) it is different (as it should because you didn't correct anything).

I'm seeing the same (expected) behavior as Wilbert with the test clip.

[HeadBangeR77]

Hello,
The matter is we're obviously getting different results using the same software. Could you post the screen grabs you've mentioned? Plz save mine (beneath) to HDD and view at full-screen...

If i make a screenshot of avs (with ColorMatrix(mode="Rec.709->Rec.601")) and of DGIndex, the picture is exactly the same (as it should).
The problem is, I'm not getting the same picture in terms of colours with ColorMatrix(mode="Rec.709->Rec.601") avs preview (the same applies to sample encodes I've made using ColorMatrix):

1) Just ColorMatrix(mode="Rec.709->Rec.601") (AVSP 1.3.7, ColorMatrix v2.1)

http://www.hidebehind.com/thumbs3/E91CC480.png (http://www.hidebehind.com/E91CC480)

2) As above + hints enabled (looks exactly the same to my eyes)

http://www.hidebehind.com/thumbs3/19D0F8D2.png (http://www.hidebehind.com/19D0F8D2)

and DGIndex:
3) DGIndex 1.4.9 beta 14

http://www.hidebehind.com/thumbs3/E02D339E.png (http://www.hidebehind.com/E02D339E)

If i make a screenshot with MPC (playing the m2v) it is different (as it should because you didn't correct anything).
So you're saying MPC (I've got the same results with MPC and e.g. PowerDVD 5/6) isn't decoding the source properly in terms of colours? I don't understand what should I change in the m2v, since it's just a part cut out of the original VOB (?). I don't know how I could made myself clearer? If the above players fail with this source, I can also get wrong colours with other MPEG-2 sources - that's the matter.

4) MPC (internal libmpeg2 decoding), VOB/m2v ( both look the same, really):

http://www.hidebehind.com/thumbs3/6AE7CF37.png (http://www.hidebehind.com/6AE7CF37)

5) MPC, sample encode, ffdshow rev. 1006, ICL9, XviD lib:

http://www.hidebehind.com/thumbs3/D22CFE3C.png (http://www.hidebehind.com/D22CFE3C)

1 & 2 look different (to my eyes there's too much orange in the reds there) than 3-5 (the reds are deeper and seem more natural to my eyes). So to your eyes the first two ones look correctly (plz, forget about technical matters, and just have a look at them)?

cheers,
HDBR77

PS. AviSynth 2.5.7 final.

[Wilbert]

Regarding 1,2,3. Could you redo the screenshots in the following way:

a) open the scripts in 1,2 in VDub and: video -> snapshot source frame.

b) regarding 3: use latest DGIndex (i'm using 1.4.6). Open m2v: file -> save bmp.

My apologies if you have done it this way, but it's not clear from your post.

So you're saying MPC (I've got the same results with MPC and e.g. PowerDVD 5/6) isn't decoding the source properly in terms of colours?
That depends on who is doing the YCbCr -> RGB conversion in MPC. I don't think MPC does this conversion itself, but i might be wrong.

1 & 2 look different (to my eyes there's too much orange in the reds there) than 3-5 (the reds are deeper and seem more natural to my eyes). So to your eyes the first two ones look correctly (plz, forget about technical matters, and just have a look at them)?
I'm not saying which ones *look* correct, that's a different question.

My screenshots:

screenshot of avs with ColorMatrix(mode="Rec.709->Rec.601"):

http://img180.imageshack.us/img180/1963/blackpearlavsio2.th.png (http://img180.imageshack.us/my.php?image=blackpearlavsio2.png)

and of DGIndex:

http://img126.imageshack.us/img126/9489/blackpearldgindexvm1.th.png (http://img126.imageshack.us/my.php?image=blackpearldgindexvm1.png)

MPC:

http://img126.imageshack.us/img126/3695/blackpearlmpcjd4.th.jpg (http://img126.imageshack.us/my.php?image=blackpearlmpcjd4.jpg)

[Alain2]

If ffdshow is used by mpc for the video, by default its yv12 output is tv scaled, not PC scaled, contrary to all other output modes. Only way around I use is to disable in ffdshow all output colorspace but rgb32, and tick the high quality yv12->rgb convertion box. That way it properly scales the yv12 input. It is slightly more expensive on the cpu usage as it's software convertion but it's not very significant I found on my average PC. This is a known "bug" (or developper's choice).

I didn't read the thread completely, if this is not related to this post I apologize

[Wilbert]

If ffdshow is used by mpc for the video, by default its yv12 output is tv scaled, not PC scaled, contrary to all other output modes.
If you mean that it is converted to RGB [16,235] by default, then you are wrong. It depends on the driver of your card:

http://forum.doom9.org/showthread.php?t=106111

[HeadBangeR77]

Hi! I'll be home tomorrow afternoon, and I'll post the screen grabs here.

Regarding 1,2,3. Could you redo the screenshots in the following way:

a) open the scripts in 1,2 in VDub and: video -> snapshot source frame.
I can already tell you they look the same.

b) regarding 3: use latest DGIndex (i'm using 1.4.6). Open m2v: file -> save bmp.
I could use 1.4.8 (the latest stable) - the older ones I've deleted from my HDD (that's why I'm using 1.4.9 beta14, cause it seems stable enough).

That depends on who is doing the YCbCr -> RGB conversion in MPC. I don't think MPC does this conversion itself, but i might be wrong.
I've excluded the conversion - the VOB/m2v screen shot is pure source YV12 (look at the "nice" stair-stepping on the soldiers' outfit); while the encode is forced YUY2.

I'm not saying which ones *look* correct, that's a different question.
Right, yet I'm the kind of guy the eyes have a priority before all other technical matters. ;) that's why I've asked you, which one looked more natural to your eyes.

My screenshots:
screenshot of avs with ColorMatrix(mode="Rec.709->Rec.601"):

http://img180.imageshack.us/img180/1963/blackpearlavsio2.th.png (http://img180.imageshack.us/my.php?image=blackpearlavsio2.png)

and of DGIndex:

http://img126.imageshack.us/img126/9489/blackpearldgindexvm1.th.png (http://img126.imageshack.us/my.php?image=blackpearldgindexvm1.png)
Both look ok, yet more similar to my results without ColorMatrix, so I'm just wondering could it be some kind of e.g. graphic card drivers issue (?)

MPC:
http://img126.imageshack.us/img126/3695/blackpearlmpcjd4.th.jpg (http://img126.imageshack.us/my.php?image=blackpearlmpcjd4.jpg)
This one looks different because it's flawed with TV-scale bug (sorry, I've know the bastard for so many years I recognize it immediately), so the colours are dimmed and washed out, I've got no doubt... You've used VMR9 renderless in MPC, haven't you? I stick to VMR7 windowed, which works fine for me (PC-scale) - the same as overlay. VMR9 is too buggy because of our gracious Nvidia/ATI 2d drivers to be reliable enough for such a comparison (they're fixing it and then breaking it down again with mad irregularity).

thanks very much for your attention.

PS. I'm not using ffdshow for MPEG-2 decoding, as I've stated above, yet ffdshow libmpeg2 looks exactly the same as MPC's internal libmpeg2 decoding & Power DVD 5&6 & Nero ShowTime.

[Alain2]

If you mean that it is converted to RGB [16,235] by default, then you are wrong. It depends on the driver of your card:

http://forum.doom9.org/showthread.php?t=106111
Yes sorry that's what I meant, was a bit fast. And I think it's not possible to change this with my card driver (ati catalyst) ; I think it's the same for a lot of people (maybe nvidia as well) as this issue often comes back when I discuss on other boards. Also I still think it's ffdshow specific, using something else to read the same file does not convert to 16..235 (well last time I tried anyway, don't have anything else than ffdhow now)

[HeadBangeR77]

@ Alain2
I don't think it's ffdshow specific: I've got similar washed out & dimmed colours in MPC with its internal MPEG-2 decoding, or just using XviD 1.1.2 VfW decoding. It affects both VMR7 & 9 renderless. No problems here while using VMR7 windowed or Overlay. And yes, foxyshadis has mentioned more than once it's 2D drivers specific issue.

@ Wilbert
I was having hard time today trying to grab exactly the same frame in all applications, especially with DGIndex and Nero ShowTime, yet I've just managed it. Will upload the screen grabs soon.

1) Just ColorMatrix(mode="Rec.709->Rec.601") (VDub 1.7.1, ColorMatrix v2.1)
2) As above + hints enabled
3) DGIndex 1.4.8 preview

The above three up-sample chroma to RGB 24/32 by default - I've just discovered - there's no sign of colour bleeding or stair-stepping.

4) MPC (internal libmpeg2 decoding, YV12, no chroma up-sampling nor any other colour conversion)
5) Nero ShowTime (Nero Digital's internal splitter and decoder, default colour setting, YV12)

cheers,
HDBR77

Here we go:

1) http://www.hidebehind.com/thumbs3/605B2C09.png (http://www.hidebehind.com/605B2C09) 2) http://www.hidebehind.com/thumbs3/BC1D2A08.png (http://www.hidebehind.com/BC1D2A08)

3) http://www.hidebehind.com/thumbs3/2E05C2DB.png (http://www.hidebehind.com/2E05C2DB) 4) http://www.hidebehind.com/thumbs3/61DEE52D.png (http://www.hidebehind.com/61DEE52D) 5) http://www.hidebehind.com/thumbs3/4B89255C.png (http://www.hidebehind.com/4B89255C)

[HeadBangeR77]

1) http://www.hidebehind.com/thumbs3/6296135B.png (http://www.hidebehind.com/6296135B) 2) http://www.hidebehind.com/thumbs3/44702F4C.png (http://www.hidebehind.com/44702F4C)

3) http://www.hidebehind.com/thumbs3/3BEDF564.png (http://www.hidebehind.com/3BEDF564) 4) http://www.hidebehind.com/thumbs3/C0E28100.png (http://www.hidebehind.com/C0E28100) 5) http://www.hidebehind.com/thumbs3/124C296.png (http://www.hidebehind.com/124C296)

***
Here the orange reds look the worst imo:

1) http://www.hidebehind.com/thumbs3/99F38CB3.png (http://www.hidebehind.com/99F38CB3) 2) http://www.hidebehind.com/thumbs3/84BE031C.png (http://www.hidebehind.com/84BE031C)

3) http://www.hidebehind.com/thumbs3/5B7CCCE0.png (http://www.hidebehind.com/5B7CCCE0) 4) http://www.hidebehind.com/thumbs3/713A8BEA.png (http://www.hidebehind.com/713A8BEA) 5) http://www.hidebehind.com/thumbs3/C1451EE0.png (http://www.hidebehind.com/C1451EE0)


cheers,
HDBR77

[Wilbert]

Ok, first a possible misconception:

I've excluded the conversion - the VOB/m2v screen shot is pure source YV12 (look at the "nice" stair-stepping on the soldiers' outfit); while the encode is forced YUY2.
What ever you do, the clip is always converted to RGB upon display. If you enable forced YUY2 in ffdshow, then your system default YUY2 codec is converting it to RGB. (You can change that in your registry by setting "VIDC.YUY2"="huffyuv.dll" for example; see faq for more on this.)

1) Just ColorMatrix(mode="Rec.709->Rec.601") (VDub 1.7.1, ColorMatrix v2.1)
2) As above + hints enabled
3) DGIndex 1.4.8 preview
Ok, I also installed DGIndex 1.4.8: 1,2 is the same and 3 (saves as a bmp) is different (i guess the behaviour changed wrt to 1.4.6). I think it's a bug in DGIndex. I will inform neuron2 about it.

As for your pics 4 and 5, i think that both of them are wrong. I'm not sure who is doing the conversion to RGB here, but i think that Rec.601 is used.

Right, yet I'm the kind of guy the eyes have a priority before all other technical matters. that's why I've asked you, which one looked more natural to your eyes.
Don't get me wrong, since this is an important question. But if the colorimetry is wrong, it doesn't mean it is always wrong. You have to manually judge whether it is wrong in a particular case an act upon that. It's certainly wrong to assume it is always wrong.

[HeadBangeR77]

Thanks very much for the quick answer. :)

(...)
What ever you do, the clip is always converted to RGB upon display. If you enable forced YUY2 in ffdshow, then your system default YUY2 codec is converting it to RGB. (You can change that in your registry by setting "VIDC.YUY2"="huffyuv.dll" for example; see faq for more on this.)
I must admit I don't understand this entirely. Previewing with VDub didn't give me any artefacts typical for 4:2:0 colour compression, because it defaults in options to RGB24. I assume DGIndex does very similar or even exactly the same thing, so no colour bleeding nor stair-stepping.

Yet while decoding MPEG-2 (most of them are YV12 for compression's sake) or MPEG-4 ASP (Divx, XviD) I always get the mentioned artefacts, no matter what player and decoder I use. How could it be a clip is converted to RGB upon display and keeps artefacts typical for chroma sub-sampling (as in JPEGs)? The only thing I can do then is to use ffdshow and force either YUY2 output colour space or the already mentioned HQ YV12=>RGB conversion, again as output colour space. Only then the artefacts disappear (I made dozens of screen-shots once). Standard MPEG-2 decoding with either MPC or PowerDVD or Nero ShowTime also has stair-stepping. Where is the conversion then? :confused:


Ok, I also installed DGIndex 1.4.8: 1,2 is the same and 3 (saves as a bmp) is different (i guess the behaviour changed wrt to 1.4.6). I think it's a bug in DGIndex. I will inform neuron2 about it.
I've seen your post and backed you up. ;)

As for your pics 4 and 5, i think that both of them are wrong. I'm not sure who is doing the conversion to RGB here, but i think that Rec.601 is used.
I also think Rec.601 is used, yet the stream doesn't seem to have its own colorimetry info, so it's an assumption it should be Rec.709 (which is true in most of the cases).

Hence...
Don't get me wrong, since this is an important question. But if the colorimetry is wrong, it doesn't mean it is always wrong. You have to manually judge whether it is wrong in a particular case an act upon that. It's certainly wrong to assume it is always wrong.
I get it. After all that discussion, from which I've learnt a lot in the meantime, I think I'm gonna encode this one into two versions (with and without ColorMatrix). Most of the effects with CM are pleasant to my eyes, yet the orange reds look totally unrealistic to me.

Thank you very much for all the help.
cheers,
HDBR77

[Wilbert]

I must admit I don't understand this entirely. Previewing with VDub didn't give me any artefacts typical for 4:2:0 colour compression, because it defaults in options to RGB24. I assume DGIndex does very similar or even exactly the same thing, so no colour bleeding nor stair-stepping.

Yet while decoding MPEG-2 (most of them are YV12 for compression's sake) or MPEG-4 ASP (Divx, XviD) I always get the mentioned artefacts, no matter what player and decoder I use. How could it be a clip is converted to RGB upon display and keeps artefacts typical for chroma sub-sampling (as in JPEGs)? The only thing I can do then is to use ffdshow and force either YUY2 output colour space or the already mentioned HQ YV12=>RGB conversion, again as output colour space. Only then the artefacts disappear (I made dozens of screen-shots once).
It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.

[canuckerfan]

other than dgindex, what other method is there for determining a streams colorimetry?

[HeadBangeR77]

It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.
:thanks:

Now it's clear. :)

[Wilbert]

other than dgindex, what other method is there for determining a streams colorimetry?
GSpot (as mentioned in the documentation). I'm not aware of any other utilities which show the colorimetry.

[KillerZero]

Decoder doesn't assume anything. MPEG4 decoder just decodes MPEG4 to YV12. Conversion to RGB is done by graphic card, not by decoder. (except you force RGB24 output, if decoder supports it) So it is up to your graphic card and driver to select proper colorimetry. Decoder doesn't have anything to do with it. And at least Ati cards select correct colorimetry according to resolution. (Rec601 for SD, Rec709 for HD) I don't have nvidia card, so I can't test it but I think it will do it corectly too.

You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.

BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef":
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo

[HeadBangeR77]

You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.
I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab. Recently I've also compared MPC's, Nero ShowTime's and PowerDVD's still frames, and guess what, they all looked the same, no matter what application/decoder was used. It applies at least to MPEG-2, MPEG-4 ASP and x264 encodes.

BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef"...
Now this might be really interesting ... Why not to make a short samples with those parameters? ;)

cheers,
HDBR77

[HanSolo00]

I've just found some 'interesting' behaviour with a simple test on 4 different MPEG-2 clips. The problem with DGindex+ColorMatrix hints only seems to occur for me with HD MPEG-2; in all the other cases, the hints passed do as I expect with ColorMatrix. It does a Rec.709->Rec.601 on a Rec.709 Interlaced NTSC clip, but does not on a Rec.709 Progressive Film clip. On a SMPTE 170M Progressive Film clip, it also changes nothing. In those 3 cases, the DGindex shown frames match the output avs played back in MPC, with ColorMatrix(hints=true).

Where it does not match, is when you open a Rec.709 NTSC Interlaced Transport Stream. When you playback the TS in DGindex, and compare the frame colors to MPC playing back the same source frames, the colors match--but when you allow ColorMatrix to use DGindex hints, the colors are changed in the output. IMHO, this is improper--the HD Transport Stream, even though it is NTSC Video Type, should be left alone because HD is supposed to be Rec.709. When I let ColorMatrix change the colors to Rec.601, all the reds turn unnaturally orange, and this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'. So, the problem appears to be DGindex reporting hints to ColorMatrix that tells it to change the color on the Transport Streams, when it shouldn't.

In a nutshell: DGindex internally is leaving a HD Transport Stream alone, as Rec.709, as you can see when you play it in DGindex (which is correct.) But as soon as you pass hints 'NTSC' video type to ColorMatrix, it goes and does a Rec.709->Rec.601 because it isn't differentiating between SDTV NTSC video and HDTV NTSC video. This must be wrong, because if you open a SDTV NTSC clip into DGindex and play it, it internally changes the color to Rec.601.

I can't post more details or samples just yet as I must get some sleep--full work day tomorrow.

[KillerZero]

I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab.

Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709"). Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.

[HeadBangeR77]

Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709").
Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.

Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.
VMR can only add the TV-scale bug, if one is unlucky. I get it, gonna try with some QT trailers I've got. Could it be in any way related to the problem that HanSolo00 is having atm?

cheers,
HDBR77

[KillerZero]

Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.

When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid! I hope you didn't misunderstand me, that conversion to RGB in avisynth is good only if you make screenshots, you should leave it in YV12 for reencoding!


Could it be in any way related to the problem that HanSolo00 is having atm?

I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter... For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.

[HeadBangeR77]

When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid!
I've always been using fast recompress, was it Nandub ages ago, was it VDubMod or is it the latest VDub. Yet the application defaults to full processing mode when you open it, so I use it for previewing & taking screenshots (if necessary, e.g when asked by Wilbert, normally AVSP would suffice).

[Guest]

I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter... I suspect that is the case as well.

[HanSolo00]

I suspect that is the case as well.The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream. Of course it is easy to simply exclude ColorMatrix from HD encoding altogether, but that sort of defeats the whole purpose as I understand it of passing color hints and determining any color adjustment for the user automatically.

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)

For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.
This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything? It would make things a lot more simple and less confusing for the end user. And after all, I thought the whole point of passing hints in the first place was to allow DGindex+ColorMatrix to always get the color right irregardless of what the scripter needs to know.

[Guest]

The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream. DGIndex does not pass hints to anyone or anything. I will guess that you are meaning to say "DGDecode passes hints." Precision is important.

Second, DGDecode does not "tell" ColorMatrix to do anything. It simply reports the colorimetry detected in the stream. That may sound like a fine point to you, but it determines where a fix for your claimed bug should be located.

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.) DGDecode does not treat SD and HD differently, as there is nothing in the MPEG2 specification that requires it to do so. Any observed difference will be due to different stream specification of the colorimetry.

Furthermore, there is no hint specifying "NTSC video" as you alluded to in an earlier post. It simply does not exist. You wrote:

"this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'"

There is a hint that reports the progressive_frame flag, but I don't know if ColorMatrix uses it.

This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything? DGDecode reports the detected stream colorimetry via hints. That is all. If there is a problem, you need to focus on the downstream filter. If you can demonstrate that DGDecode is not correctly reporting the colorimetry, then you will have my attention.

[KillerZero]

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix. Hints tell colormatrix only what colorspace is source, not to what colorspace it should convert. Colormatrix changes colors to 601, so it is obvoius that it will seem wrong when it will be played with rec709 matrix. Good solution would be to change Colormatrix to default to rec709 when resolution is HD. But best would be to not use Colormatrix for HD at all, as you won't find HD in any other colorspace than Rec709, so it is never needed to convert it in any way.

[HanSolo00]

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix.No, I understand that just fine.
Good solution would be to change Colormatrix to default to rec709 when resolution is HD.This is the solution that makes the most sense to me since a lot of encoders simply trust that ColorMatrix(hints=true) will produce the right result with all MPEG-2 sources.

[Guest]

Good solution would be to change Colormatrix to default to rec709 when resolution is HD. That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.

If ColorMatrix is keying off the progressive hint, I'd like to know why. Wilbert should explain whether it uses it and why.

I do know that it is not uncommon for streams to set the progressive_frame flag incorrectly.

[Guest]

I just looked at the source code of ColorMatrix and it does not use the progressive hint. If you can point me to your stream that has a "problem" I will look at it and tell you exactly why the 709->601 conversion is being triggered (if in fact it is being triggered).

So, the ball is in your court to provide a sample stream.

[KillerZero]

That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.

What are you talking about? Yes you can have intelaced HD, but what it have to do with fact that HD always use Rec709 colors and when you play anything with HD resolution (even in PC) it will be played back with Rec709 matrix? Colorimetry and interlacing are two completly separate things.

[Guest]

There is nothing in the MPEG2 spec that says an HD stream must use 709. That is my point. The reference to interlacing was due to Han's claims.

The conversion is being triggered simply because the stream reports 709 and ColorMatrix by default does 709->601 conversion.

If in practice HD streams always use 709, then I suppose it might make sense to change the default mode of ColorMatrix. I don't care about that. I see a potential for just a different form of user confusion, though.

I got involved only because people started saying DGMPGDec is doing something wrong and needs a fix.

Carry on, I'm outta here.

[KillerZero]

Nothing in MPEG2, but in HD specs is Rec709 as only possible. Being it MPEG2, MPEG4, VC-1 or anything else, progressive or interlaced it must always use rec709.
That is what I'm talking about, it changes to Rec601, and this is the thing that causes wrong colors, because it is played as Rec709, like every HD video.

[Guest]

Nothing in MPEG2, but in HD specs is Rec709 as only possible. Being it MPEG2, MPEG4, VC-1 or anything else, progressive or interlaced it must always use rec709. There are still two systems in use for HDTV: 709 and SMPTE 240M. I agree that the latter is less common.

That is what I'm talking about, it changes to Rec601, and this is the thing that causes wrong colors, because it is played as Rec709, like every HD video. Well, it changed it because you asked it to. :) That is what ColorMatrix does, it converts color spaces.

[KillerZero]

Sorry, don't know exactly what spec says it, but every HD device assumes Rec709.

Yes, that is why I'm telling hansolo that he shouldn't use it. :)

[Wilbert]

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix.
I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

[Alain2]

Sorry to interrupt, but I thought that the colorspace used for the avs output should match the codec expectancy, and not related to some "resolution" specs ? I thought for instance that xvid decoders were expecting rec601 by default whatever the resolution (cf background information in colormatrix doc), same for x(h)264 decoders (no specific resolution, I am not encoding to any particular standard resolution), and CCE was expecting rec709 by default, am I completely wrong ?

[KillerZero]

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution. (You can test that it depends on resolution by using resize&aspect in ffdshow. When you resample it to 1280x720 it starts using Rec720 matrix. I've just tried it. I'm not sure what exact resolution is minimal, but for 1280x720 it works)

I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

It is not false, you can have examples which are in Rec601, but they still will be probably played as rec709. On PC they will definitely be played as Rec709. BTW I wonder where did you get that examples?

[Wilbert]

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution.
You are bringing up some interesting points. I will come back to this and will change the docs accordingly ...

I'm a bit confused. Let's talk about mpeg-2 and playback for example. Are you claiming that this colorimetry info in a mpeg-2 is never used upon display? Or does it depend on the player?

I thought that not all graphic cards support YV12, who is doing the YV12->RGB conversion in that case?

[KillerZero]

If we are talking about playing MPEG2 with ffdshow then it is not used. I know it, because TV broadcast in Rec709 and it plays like Rec601 unless I use resize to 1280x960 in ffdshow. (I have Radeon 9600XT)

If YV12 is not supported by card (do you know any card which doesn't? I don't) ffdshow switches to supported colorspace closest to YV12.

[HeadBangeR77]

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card.
That is indeed interesting - I used to think what Alain2 did. Radeon 9800XT on board here + X700 mobile, so we've got at least the same family of graphic cards to test with.

And it selects color matrix depending on resolution. (You can test that it depends on resolution by using resize&aspect in ffdshow. When you resample it to 1280x720 it starts using Rec720 matrix. I've just tried it. I'm not sure what exact resolution is minimal, but for 1280x720 it works)
I've been trying to reproduce this using MPC + ffdshow resizing (rev. 1006, ICL9), yet it doesn't seem to affect my encodes (XviD): VRM7 windowed, YV12 /YUY2 in ffdshow as output colour-spaces (yet it shouldn't matter, since the graphic card converts it to RGB). I've resized to 1280x0 (auto) and 1400x0 (auto).
Different drivers? Or perhaps it affects certain codecs (although it shouldn't) only? Could you bring the matter to the ffdshow thread - think the guys there might be interested and will have more knowledge and experience than I do to reproduce and track the problem.

cheers,
HDBR77

PS. I've just linked the last few posts in the ffdshow try-outs thread.

[KillerZero]

Try to use system default as output. I haven't tested VMR modes. And you have to compare paused video, not screnhots of course, because conversion is done by MPC for screenshots. Also, I have unchecked "let the application control video adjustments" in Catalyst control center video settings. And it is not problem, it should behave like this, as Rec601 is default for SD video and Rec709 for HD. I don't know if decoder can send colorimetry info to driver. If not, ffdshow would have to convert it.

[HeadBangeR77]

Try to use system default as output. I haven't tested VMR modes.
Well, if so, what OS are you running on? AFAIR VMR7 is system's default with WinXP.

And you have to compare paused video, not screnhots of course, because conversion is done by MPC for screenshots.
I remember - you don't have to remind me - that's what I did. ;)

Also, I have unchecked "let the application control video adjustments" in Catalyst control center video settings. And it is not problem, it should behave like this, as Rec601 is default for SD video and Rec709 for HD.
Well, it could be a potential problem, since whole bunch of people is using ffdshow's filters for real-time playback, and this includes the resizing for a better presentation /visualization, especially for all possible kinds of SD sources.
For instance: if I made the previously discussed encode with ColorMatrix Rec.709=>Rec.601 conversion, and I would upsize it by playback on my notebook to 1280xauto, then it would be happily converted to Rec.709, and I would get hell of over-saturation, most probably.

Btw. What ffdshow revision are you using?

[KillerZero]

I tried it and same thing in VMR7 windowed. And I tested it some more and it depends only on lines, so it has to be at least ????x720. This is rather bad, as reencodes with cropped blask bars will play wrong unless you add them back with ffdshow. I thought one of them seems wrong...
I'm using version from 2nd september 2006, I can't find revision number. (I use this older version because newer buids can't use HW deinterlacing, only weave and bob is allowed. At least few months ago it couldn't.)

[HeadBangeR77]

I tried it and same thing in VMR7 windowed. And I tested it some more and it depends only on lines, so it has to be at least ????x720 ...
That's what I was starting to suspect, since I was resizing a 16:9 widescreen (2.35/2.40:1) samples, so I never got to the lowest HD level in terms of vertical resolution.


I'm using version from 2nd september 2006, I can't find revision number. (I use this older version because newer buids can't use HW deinterlacing, only weave and bob is allowed. At least few months ago it couldn't.)
A new beta is just out at sourceforge.net. I've just uninstalled my "ancient" rev. 1006 from the 7th of March, so I'm gonna try to reproduce your issue using the official beta2.

[KillerZero]

I think it has nothing to do with ffdshow, I think that it depends only on graphic driver.

[Sharro]

I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

Not common, still my Star Wars Ep. I to III had all Rec.601 flag, which I believe it's a very "common" movie.

All the best,

Sharro

[Alain2]

@KillerZero
I don't understand.. Why bother putting colorimetry flags in the stream if nobody cares in the encoding or decoding process loop ? If it's resolution based only, do you know of a look-up table published somewhere to confirm this ? I find it hard to believe that it's standardized around the world

[KillerZero]

Sharro: where did you recorded it from?
Alain2: Decoder and decoder just takes raw data. Being it Rec601 or Rec709 encoding and decoding process is still the same. There is nothing to be changed and no reason to care which colorimetry it is. Colorimetry information is relevant only if you convert to RGB or back or if you do some color corrections. I don't know if it is possible to tell graphic card which colorimetry should be used?
What table? I don't know, it's just based on tests I've done. My card uses Rec601 for SD and Rec709 for HD.
It's possible that some HW players convert it, but I doubt it's widely used.
709 is standard for HDTV. It also requires slightly different RGB values, which probably all HDTV's use.

[Alain2]

Yes but the raw data are formatted to be decoded either rec601 or rec709 (or whatever) : your card renders differently at different resolution the same yv12 stream to the same rgb monitor, thus the raw data are supposed to be encoded taking into account the colorimetry convertion that will be applied when you watch it. So there is a reason to care about colorimetry I think, I am just not sure how now...

Also you refer only some specific standard SD / HD resolutions, but what about all the other non-standard resolutions ? I don't particularly pay attention to the resolution when I encode something, I choose whatever is the best compromise for resize aspect error/resolution/available bitrate as I don't plan to use hardware players..

[foxyshadis]

If you rely on your graphics card for colorometry, you might as well wish on a falling star. They can't even get luma levels right consistently, there's no way they'll ever make an effort to work with colorometry correctly. That's why I'm hoping ffdshow's hq rgb output will be able to take that into account someday. If you want the speed of YUV output you're just going to have to live with flaky rendering and making up-front corrections.

[KillerZero]

Alain2: I meant that there is no difference in encoding/decoding process. All can encoder do is to write given colorimetry info and decoder read it and give it to YV12/RGB convertor. That convertor is usually graphic card. Still noone answered my question if it is possible to tell card what colorimetry should be used.
It is dependent on number of lines, as long as it is 720 lines high or more, it uses Rec709.

They can't even get luma levels right consistently, there's no way they'll ever make an effort to work with colorometry correctly.
What do you mean by inconsistent luma? I really have no idea what should I imagine. And I think that current colorimetry behavior is quite correct.

If you want the speed of YUV output you're just going to have to live with flaky rendering and making up-front corrections.
Also, I don't understand what do you mean with that.
I don't know why should I use ffdshow's RGB conversion, if there is no difference from HW and it is much slower. +RGB output works correctly only to 960xsomething resolution. And as you say, ffdshow always use Rec601, so only way to play Rec709 is not using ffdshows RGB conversion.

[Leak]

What do you mean by inconsistent luma? I really have no idea what should I imagine. And I think that current colorimetry behavior is quite correct.
I guess she meant that whole "TV levels" vs. "PC levels" brouhaha...

[KillerZero]

What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.

[Leak]

What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
IIRC Overlay Mixer uses one and VMR7/9 uses the other, thus making both look different...

np: The Remote Viewer - Take Your Lights With You (Let Your Heart Draw A Line)

[KillerZero]

VMR7 also uses correct values, only VMR9 uses wrong colors.
edit: and VMR7 renderless is also wrong, so only overlay and VMR7 windowed is correct. But why?
Edit2: really strange, it seems that VMR9 selcts color mode randomly...
Edit3: I got it, VMR7 renderless and both VMR9 modes render colors correctly only with resolution < 720 lines. For 720p or higher, they really expect PC scale. Maybe bug in drivers? I'll try upgrade to newest catalyst.

[KillerZero]

It should be possible to set color matrix:

http://msdn2.microsoft.com/en-us/library/ms796493.aspx

[Alain2]

Alain2: I meant that there is no difference in encoding/decoding process. All can encoder do is to write given colorimetry info and decoder read it and give it to YV12/RGB convertor.
I am not sure of that.. I always use avisynth for encoding, and I really doubt that avisynth is keeping a colorimetry flag throughout the filters process, therefore to me the colorimetry flag is reset by the encoder used. That's why I said earlier that xvid/x264 were rec601 and CCE rec709, and that the source had to be dealt with accordingly... maybe avisynth devs can confirm / disapprove what I just said ?

Also, I don't understand what do you mean with that.
I don't know why should I use ffdshow's RGB conversion, if there is no difference from HW and it is much slower. +RGB output works correctly only to 960xsomething resolution.
What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.
Like Foxyshadis, I personnally disabled yv12 output in ffdshow and only enabled rgb32, with the yv12>rgb hq conversion option enabled. This is to get the full PC scale as I do want 0-255 on my lcd screen. Usual DVD software players / AvsP preview / vdub scale 16-235 over 0-255 (histogram("levels") indicate values in 16-235, whereas it is clearly displayed in 0-255 as black is true black), so I think it is what most people want on their computer... Only ffdshow yv12 output keep the output level to 16-235

[KillerZero]

For me, YV12 also results in 16 as black. There is no visible difference between RGB32 with HQ RGB conversion and YV12. What is your graphic card?
You definitely not using avisynth for encoding, only for decoding. And it is nothing contradicting to what I said - only what encoder can do is write colorimetry info to stream and all what decoder can do is to give colorimetry info to next filter if it's present in stream, but in encoding/decoding process itself is no slightest difference. It's only relevant for YV12<-->RGB conversion, so if we want it to be played properly ffdshow must be able to pass colorimetry info to graphic card. If not, default value is used, which is Rec601 for all resolutions below 720p.
I'm not sure if you understand - if you have raw YV12 data there is no way how to tell which colorimetry is it. If you have no colorimetry info in stream, all you can do is just guess what looks more correct to you.
Another question is if xvid writes colorimetry info to stream. Probably not, but at least MPEG2 playback could be correct.
X264 has option to set colorimetry info. use X264.exe --longhelp

[foxyshadis]

As I've said many times, it pretty much randomly changes based on your drivers. For a few driver versions it'll be "TV" levels, then it'll slide back to "PC" levels, fullrange conversion, sometimes only for some streams and not others. At least nvidia opened up a registry option that can be used to change the output levels, after being pestered, because some people actually use and prefer PC-levels, although I understand this stopped working or became unreliable last year. (I gave it up some time back.)

I'm surprised that anything changes for you when the size of the output reaches 720p. In my case, it's the same, with pretty recent cat, but an x1400 mobility. On the other hand I usually can't tell the difference between 601 and 709, so maybe it's just slipping by me.

I've been putting up with it for two years, once I figured out what caused it, filing occasional support requests, and the flip-flopping in the drivers and the steady stream of posts by other people with the same problem have just grated on me. So I'm a little more annoyed at them than I should be. That's the reason I suspect that instead of honoring any colorometry flag, they will just use one and ignore the stream. As in your case, they pick one flag for SD and one flag for HD - that's simply wrong, hardly any better than forcing one all the time.

[G_M_C]

Regarding the YUv PC/TV-scale; I've got a H264 clip wich comes out PC scale after opening throught AVCSource().

Currently I'm using a AVS-script like this:

AVCSource("bond.dga", deblocking=false).ConvertToYUY2()
Trim(xxxxx,xxxxx)
AssumeFPS(25,1,false)
Spline16Resize(720,426)
FFT3DGPU(...{bunch of options}...)
AddBorders(0,74,0,76)


Would you guys do the ...
1) ColorYUV("PC->TV") just before the ConvertToYUY2()
2) ColorYUV("PC->TV") just before the FFT3DGPU ?
3) Doesnt matter sh*t, there wont be a difference ;)

What would you guys do ?

PS: (G_M_C is trying hard to circumvent the "what's best" question ;) )

[KillerZero]

1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.
2) why are you converting it to YUY2? why don't you leave it in YV12?
3) Why fft3D? Denoising?
4) where can I get AVCsource plugin? Is it faster than DirectShowSource?
5) I don't know AVCSource and I cant google any relevant page, but if deblocking=false disables deblocking even if clip uses in-loop deblocking, this can lead to catastrophic results.

I think there won't be any significant difference, but maybe would be better put it after FFT3D, so it will work with more colors.

[G_M_C]

1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.

Did that, and thats how i know.

1)2) why are you converting it to YUY2? why don't you leave it in YV12?


Converting to MPEG2 using CCE (to be precise: Replace the crappy PQ of the video-track of one of my backups with a new and better one)

1)3) Why fft3D? Denoising ?

Yes, to help compression + it is needed (using low sigma-values, after resizing from HD to SD).

5) I don't know AVCSource and I cant google any relevant page, but if deblocking=false disables deblocking even if clip uses in-loop deblocking, this can lead to catastrophic results.

Read all about it on doom9's forum, only not here but here:
http://forum.doom9.org/showthread.php?t=122598

No catastrophic results known, and it is not relevant in this case.

In other words: I know what i'm doing, so above tips are known to me.

1)4)
I think there won't be any significant difference, but maybe would be better put it after FFT3D, so it will work with more colors.

Thx for this answer; But how do you think it works best on more colors ?

My hypothesis for option 1 was was because i do not know if luma getss "cut off" or otherwise broken when i use ConvertToYUY2() on PC-scale input.

If the conversion wont give those problems, than i wanted to use option 2 because any rounding-off errors or other noise (if any) that comes with the conversion gets corrected, and rest of the script can use the as much luma/chroma information i can give it (The FFT is needed anyway).

In the end i want to lose as less color/luma info as possible before giving it to CCE. In other words: The higher the quality the better
(=Didee-like encoding quality-standards ;) )

[KillerZero]

1) its strange, as it must look very dark in every player, that is why I'm asking.
ConverttoYUV2 just upsamples chroma, so it shouldn't cut off anything.
Nearly every filtering works best if it has highest bitdepth possible, i dont know why should be fft3D different.
Thx for link, but I still think that turning deblocking off is bad idea, though it may work on some streams. It's definitely not worth speed gain.

[G_M_C]

1) its strange, as it must look very dark in every player, that is why I'm asking.


Yes actually it does, thats when i discovered it (assumed that it would be TV scale on my first try). Dark tones are way to dark, and light tones are "overshined". The whole image looked like I turned up contrast to the max on my TV.

But thx for the help, i think i'll use option 1)

:)

[Alain2]

What is your graphic card?
X1600pro, using catalyst 06.8, media player classic output VRM9 renderless. Using the default / overlay renderer I do get yv12 displayed with the 0-255 scale, it's in VRM9 (that I want to use) that it is kept at 16-235 if ffdshow outputs yv12, but converted to 0-255 if ffdshow outputs rgb.
You definitely not using avisynth for encoding, only for decoding.
Yes ok, was tlaking fast. I use avisynth to pre-process my input (read by dgdecode for instance) with filters and send the resulting raw yv12 to the encoder (lagarith first, then x264).
And it is nothing contradicting to what I said - only what encoder can do is write colorimetry info to stream and all what decoder can do is to give colorimetry info to next filter if it's present in stream, but in encoding/decoding process itself is no slightest difference. It's only relevant for YV12<-->RGB conversion, so if we want it to be played properly ffdshow must be able to pass colorimetry info to graphic card.
Ok, I see your point, but still, my input is being processed by avisynth filters before being sent to the encoder, and I very much doubt that you would get a colorimetry info in the raw yv12 output of avisynth. Thus if you have a yv12 with no colorimetry sent to the encoder, ok you say it encodes it, and maybe add a colorimetry flag as well for the driver that will convert to rgb. That is this colorimetry flag I was thinking about: aren't xvid and x264 supposed to add by default rec601 flag whereas CCE is choosing rec709 be default ? In any case, you have to treat your yv12 stream according to this colorimetry flag of the encoder, meaning if it's not the same than your initial source, then a convertion as per colormatrix is necessary...

[KillerZero]

Strange, I have 9600XT and it uses 16-235 --> 0-255 RGB even with VMR9 renderles, if video isn't higher than 720 lines...
I don't know about XVID, but X264 leaves it undefined by default. I bet that xvid does the same, Rec601 is just default for SD video, so it is chosen by graphic driver if it's not specified.

[tritical]

I've made a new version that fixes the source==dest error when using d2v or hints, and that removes the 'scaling' parameter and replaces it with a boolean 'clamp' parameter (true will use limiter before and after, false wont). I read through the last 4 pages and I'm not sure whether anyone wanted the default for dest/mode to change to Rec.709 when the input has HD res? If so speak up, or if there are other changes wanted speak up also... otherwise I am just going to leave everything else as is.

[IanB]

...default for dest/mode to change to Rec.709 when the input has HD res?I think that might be a bad idea.

Having behaviour change depending on image dimensions is poor. Besides where do you set the threshold, H>576, W>720, H>=720, W>=1280, half way between, ....

If it is an issue that require fundamental thought then it probably should not have a default, i.e. the parameter must always be specified.

[wozio]

To clarify some things about yuv->rgb conversion whn using VMR9 on ATI.

This is really up to drivers how this color conversion is done. Decoder has nothing to tell here unless he outputs rgb data. Now ATI drivers uses two color matrixes depending on resolution of incoming image, if images has 720 lines or more then hd matrix is used, otherwise sd matrix. You can see comparision how it looks like here:

http://forum.doom9.org/showthread.php?p=988268#post988268

It looks very similar between ffdshow's yuv->rgb conversion and ati's vmr9 sd color matrix but difference to vmr9 hd matrix is bigger.

It would be great that decoders would pass color information to VMR9 using mentioned DXVA_ExtendedFormat but it is unknown how it is supported in drivers. As far as I see decoders have this information from stream.

At least from version 7.3 of drivers ATI started to extend all yuv inputs into PC scale.

I don't know how it looks like on nvidia cards.

[Dr.Khron]

Sorry to drag down the level of the discourse, but I've got a noobie question...

Ok, so I started inserting ColorMatrix into my AVS files... I'm working on some TV episode DVDs, so this is my syntax:
DGDecode_mpeg2source("D:\Ripping\S03E01.d2v", info=3)
ColorMatrix(hints=true, interlaced=true)

When I preview the file in AvsP, I see no difference at all when I add and remove the ColorMatrix line. From what I've gathered from reading this thread, this has to do with how I've got my FFDshow setup (I'm running a recent install of the CCCP). What can I do to change my FFDshow settings so that I can properly preview the changes that ColorMatrix makes to my AVS output?

Or should I just assume that fixes something, and use it for all of my .d2v content?

Thanks for any advice.

[Adub]

Maybe your original video was already rec.601, although it is doubtful. Also, depending on the size of your preview in AvsP, it may be hard to tell the difference. I usually can see the difference if I load the avs file into MPC and play it at fullscreen. Just look for parts of the video that should be black and compare them to the borders that are automatically inserted by MPC, if they are the same level of black, then it worked correctly, if not, you have some more work ahead of you.

[Wilbert]

Just look for parts of the video that should be black and compare them to the borders that are automatically inserted by MPC, if they are the same level of black, then it worked correctly, if not, you have some more work ahead of you.
ColorMatrix doesn't change the black level, so i'm not sure what you are referring to here. If the level of black is the same, it doesn't mean ColorMatrix did anything (like you said, if the source is Rec.601 for example).

[canuckerfan]

for special cases of deinterlacing, as in repal... should cm be used before with the interlaced paramatre set to true (this won't handle the odd progressive frame correctly) or use it after repal with it set to false (now that all frames are progressive)? I've tried both and they seem to work, even the hints seem to survive after repal.

[Cunhambebe]

I would like to thank the author for the new verion. Keep up the excellent job! :)

[Dr.Khron]

Update to my earlier issues:

Ok, so now I better understand how ColorMatrix works. The reason I wasn't seeing a difference is becuase, as Merlin7777 suggested, the source material was already in Rec.601; see the OutputDebugString below:

[3144] ColorMatrix: frame 426: detected colorimetry from d2v = 6 (Rec.601)
[3144] ColorMatrix: frame 426: returning src frame... no conversion required (d2v)


So, in this case, I have no need for ColorMatrix at all. :)


However, my research has brought up two new questions.

First, what does the the "interlaced" parameter do? According to the documentation, "if your video is YV12 and is interlaced you need to set this parameter to true."
In my experimentation, adding it and removing it made no difference.

Second, adding the "hints" parameter to my DGDecode line appears to screw up the de-interlacing, adding in artifacts.

DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v", info=3)
colormatrix(hints=true, debug=true)

[896] ColorMatrix: frame 0: detected hint = 6 (Rec.601)
[896] ColorMatrix: frame 0: returning src frame... no conversion required (hints)
http://img484.imageshack.us/img484/3057/89873172wa8.jpg


DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v")
ColorMatrix(debug=true)

[896] ColorMatrix: frame 0: using YV12 Rec.709->Rec.601 conversion (MMX).
http://img484.imageshack.us/img484/6397/38560236ie6.jpg

Why do the hints effect the de-interlacing?
Are the hints being passed to the wrong filter?


EDIT: To reiterate, adding or removing the "interlaced=true" parameter to either of the above srcripts DOES NOT change the output.

[canuckerfan]

yea, do hints survive such filters as repal?

[tritical]

All the interlaced parameter does is internally invoke Separatefields() before colormatrix and invoke weave() afterwards. The reason for doing this is that colormatrix has to get u/v values for every y value. In progressive yv12 luma lines 0/1 share chroma line 0, luma lines 2/3 share choma line 1, etc... However, in interlaced yv12 luma lines 0/2 share chroma line 0, luma lines 1/3 share chroma line 1, etc... So using interlaced=false on interlaced yv12 will result in some luma lines using chroma values from a different field. That will be fine as long as there isn't motion, but in moving areas it will be bad. That's why it is better to accidently use interlaced=true on progressive frames than to accidently use interlaced=false on interlaced frames.

Next question is is it better to use colormatrix before or after an interlaced->progressive conversion. Theoretically, if your conversion is perfect, it would be better to run colormatrix afterwards on the progressive frames. In practice, you probably couldn't tell the difference. I will say that in the case of ivtc it's probably better to run colormatrix afterwards if only for the fact there will be fewer frames (so less processing time will be required).

Now about hints. The hints from dgdecode are stored in the least significant bit of the first 64 pixels in the Y plane (or just the first 64 pixels for yuy2) of the image. Whether or not they will survive a specific filter or function depends entirely on whether or not that filter alters those 64 pixels. Most of the time you'd just have to try and see. If you set hints=true in colormatrix, and colormatrix doesn't detect any valid hints then it will throw an error. So if you don't get any error messages it should be fine.

@Dr.Khron
Could you show us the debug output from colormatrix in both cases (with/without hints). Also, if you are using colormatrix before ivtc and dgdecode is outputting yv12 then you must use interlaced=true or things will definitely get screwed up.

[Dr.Khron]

@Tritical:

Ok, I edited my previous message to include the debug output. Yes, I am using it before IVTC, but as I mentioned, adding or removing the "interlaced=true" parameter doesn't seem to effect the output.

Seems to me the best way to pass info to the ColorMatrix filter is to use the .D2V arguments... when I fooled around with that it never caused any issues, just the "hints=true" syntax.

[tritical]

What is the rest of your script? What happens if you don't use colormatrix? Could you post a small clip so that I can duplicate the behavior?

[foxyshadis]

One quick way of keeping the hints:
Mpeg2Source()
o=last
.... # do things
MergeHints(o)
ColorMatrix(hints=true)

Mergehints is part of... Decomb, I think? I don't think hints can totally survive a framerate conversion, since pieces of different frames (which may have different matrices) are merged; but accepting that such transitions are quite rare, a simple Mergehints(o.ChangeFPS(framerate)) should be sufficient.

[Dr.Khron]

What is the rest of your script?

Here ya go. Notice that it has no ColorMatrix, since this video doesn't need it.
#import Mpeg video and correct colors
DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v")

#De-interlace
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=1)

#Resize
LanczosResize(640,480) # Lanczos (Sharp)

#noise filter
Undot() # Minimal Noise

What happens if you don't use colormatrix?
The clip come out just fine.

Could you post a small clip so that I can duplicate the behavior?

You mean like a D2V file for a small piece? Wouldn't you need the entire VOB for that?

[Boulder]

You mean like a D2V file for a small piece? Wouldn't you need the entire VOB for that?He'll need a small VOB sample so he can try it out himself.

[canuckerfan]

upon frameserving (via mpc), the results WITHOUT colormatrix is favourable (at least in my eyes) to the one WITH colormatrix. if this clip were to be fed through CCE, would not using cm keep the reults favourable? or am I missing something?

oh and just in case...
ColorMatrix(mode="Rec.601->Rec.709",opt=0,hints=true,threads=0)

[Alain2]

Edit3: I got it, VMR7 renderless and both VMR9 modes render colors correctly only with resolution < 720 lines. For 720p or higher, they really expect PC scale. Maybe bug in drivers? I'll try upgrade to newest catalyst.
Ok I got it now, in vrm9 renderless I got the same...
To save some cpu time (for encoding ^^) I stopped outputting rgb32 but keep yv12 in ffdshow, and uses ffdshow resizer in bicubic mode to 1600 x 0, which gives me a nice output on my lcd, and do the convertion as you mentionned to pc levels (funny to see that ticking / unticking the resize in ffdshow changes the levels to TV/PC realtime). vertical dimension 720 is the hardlimit apparently (1280x718 keeps TV levels, 1280x720=PC levels). It apparently also changes the color decoding as well from my tests; it looks like <720 --> rec601, and >=720 --> rec709... What a mess !:eek:
(WinXP, MPC, VRM9 renderless, X1600pro with ATI catalyst 6.8, ffdshow Mar 22 2007)

[FredThompson]

You'll see similar problems with automatic imposition of chroma range limiting. IMNSHO, this is all ill-conceived idiot-proofing for analog TV output.

I've gone to Flash video for computer playback of anything with a computer-based component such as a pure white background or scanned images because the "helpful automatic conversions" you've mentioned really screw things up.

[kumi]

Tritical posted (http://forum.doom9.org/showthread.php?p=975906#post975906) here on the 26th of March about a new version that fixes the source==dest error. Is that available for download anywhere? The most recent Colormatrix .ZIP on his site is dated January of this year.

Edit: and it doesn't have the "source==dest" error fixed.

[woah!]

this might be a silly question, but should i use this with a HD-DVD AVC source? i know this is used for mpeg2 sources but how about VC1 AVC sources?

[MLS]

Alright I read this whole thread because to be honest this filter and its uses are very confusing; and the documentation and the people in this thread do not make it clear.

What is unclear here and further muddied from the last few pages is the all important question of When is this filter supposed to be used and how?

There are a few competing opinions here, also further confused by the 0-255/16-235 PC/TV issue.

One party claims it doesn't matter what the source colorimetry, or what you convert to, if the resolution is below 720 then the 601 coefficients will be used to display the picture, this chosen by the video card, if it is above, then the 709 coefficients will be used. This would imply no other possibilities exist for PC playback.

The other party says that the colorimetry must be converted based on what you are converting to. If it is MPEG-4, the decoders will use the 601 coefficients by default and thus a problem arises from 601 coefficients being used on what is supposed to be using 709 coefficients. If MPEG-2 is the destination format, then you want to match the colorimetry that the encoder will place in the stream. Resolution does not affect it in any way.

Am I correct in my summary?

If so, then the correct filter applications would be thus:

** If Party1 is correct:

- If destination resolution is < 720 AND source colorimetry is not Rec.601 THEN convert to Rec.601.

- If destination resolution is >= 720 AND source colorimetry is not Rec.709 THEN Convert to Rec.709.

- Else Leave it be?

** If Party2 is correct:

- If destination format is MPEG4 AND colorimetry is not 601 THEN Convert to Rec.601.

- If destination format is MPEG4 AND colorimetry is Rec.601 THEN Do nothing.

- If destination format is MPEG2, convert colorimetry based on what encoder will place in MPEG2 stream by default; if it places nothing (CCE), then use Rec.709 as per specs.

- If destination format is OTHER, ???.

Hope I'm not further confusing things, I'm attempting to make sense of the discussion in the last 20 pages.

/MLS

[Dr.Khron]

Well... Since I had problems with using the filter when it wasn't needed, this is what I do: I test each source with the Debug flag.

I add ColorMatrix using the D2V option, and add Debug=true.

Then I fire up DeBugView, and put a few frames through AvsP. The text in DeBugView tells you EXACTLY what the colors for the source material are, and wether or not you need to use the filter. If I don't need it, I remove it. Pretty simple.

[Wilbert]

@MLS,

If destination resolution is < 720
KillerZero, said the height mattered, not the width.

I used to think that Party2 is correct, and that's how it's described in the docs.

However, as KillerZero pointed out:

Yes, you are completely wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution.
It's a bit difficult to give correct guidelines, so i have to think about that for a while. The problem is that there might not be a good way to do this.

Consider the following example which shows the problem:

Suppose we encode to mpeg-2 with CCE and source is Rec.709. CCE writes Rec.709 is the header of the mpeg-2 stream (or more correctly, it leaves the colorimetry empty like you say). The problem is that since you are encoding to 720x480/576, Rec.601 is used by your graphics card to covert the decoded YV12 stream to RGB for display. This implies that it is displayed incorrectly. (Btw, i'm not sure that this also happens with software dvd-players which are not based on DirectShow.)

If want to avoid this we should encode "correcting for Rec.601". But in this case the encoding (with CCE) contradicts with the header of mpeg-2, which clearly says that Rec.709 should be used for decoding. I do not like doing this.

Perhaps others can share their mind about this ugly problem.

[Revgen]

this might be a silly question, but should i use this with a HD-DVD AVC source? i know this is used for mpeg2 sources but how about VC1 AVC sources?

All H.264/AVC and VC1 videos on HD-DVD's and Blu-Ray are BT.709 colorimetry.

[Revgen]

Alright I read this whole thread because to be honest this filter and its uses are very confusing; and the documentation and the people in this thread do not make it clear.

What is unclear here and further muddied from the last few pages is the all important question of When is this filter supposed to be used and how?

There are a few competing opinions here, also further confused by the 0-255/16-235 PC/TV issue.

One party claims it doesn't matter what the source colorimetry, or what you convert to, if the resolution is below 720 then the 601 coefficients will be used to display the picture, this chosen by the video card, if it is above, then the 709 coefficients will be used. This would imply no other possibilities exist for PC playback.

The other party says that the colorimetry must be converted based on what you are converting to. If it is MPEG-4, the decoders will use the 601 coefficients by default and thus a problem arises from 601 coefficients being used on what is supposed to be using 709 coefficients. If MPEG-2 is the destination format, then you want to match the colorimetry that the encoder will place in the stream. Resolution does not affect it in any way.

Am I correct in my summary?

If so, then the correct filter applications would be thus:

** If Party1 is correct:

- If destination resolution is < 720 AND source colorimetry is not Rec.601 THEN convert to Rec.601.

- If destination resolution is >= 720 AND source colorimetry is not Rec.709 THEN Convert to Rec.709.

- Else Leave it be?

** If Party2 is correct:

- If destination format is MPEG4 AND colorimetry is not 601 THEN Convert to Rec.601.

- If destination format is MPEG4 AND colorimetry is Rec.601 THEN Do nothing.

- If destination format is MPEG2, convert colorimetry based on what encoder will place in MPEG2 stream by default; if it places nothing (CCE), then use Rec.709 as per specs.

- If destination format is OTHER, ???.

Hope I'm not further confusing things, I'm attempting to make sense of the discussion in the last 20 pages.

/MLS

The whole 720p mess is with VMR 9 renderers. If you want to use a renderer similar to VMR9 without the BT.709 issues than you're better off using the Haali Video Renderer. You can choose the Colorimetry setting in the renderer which is something the VMR9 renderer won't allow a user to do.

Otherwise, you're better off sticking to old-fashioned overlay renderer.

[DeathWolf]

VMR9 should be avoided anyway. The large color inaccuracies it has in many of its conversions are, in my humble opinion, unacceptable.

[canuckerfan]

Tritical posted (http://forum.doom9.org/showthread.php?p=975906#post975906) here on the 26th of March about a new version that fixes the source==dest error. Is that available for download anywhere? The most recent Colormatrix .ZIP on his site is dated January of this year.

Edit: and it doesn't have the "source==dest" error fixed.
yes, I am curious about this as well. wondering if a version is floating around with this fix.

[kumi]

FYI I sent tritical a PM a few days ago about it, let's wait and see.

EDIT: Good news, Tritical said he'll put up the new version soon.

[kypec]

Good news, Tritical said he'll put up the new version soon.
Is it available yet?
More than 2 months have passed and there is still only v2.1 announced in the beginning of this thread which is dated 18th Jan 2007 :confused:

[vega22]

Always we are worried about the color in the video but we forgot the serious color problems that have ours displays. There is an enormous emptiness in the subject correction of display color, and we needed effective tools to solve it.

I have a probe to calibrate my LCD. Therefore, I know the real coordinates of points R-G-B in my display (all saturated).
My real gamut is much more wide that standard 601 and 709. Therefore, I have all the appropriate colors there, but my matrix expresses everything unfaithfully

Could be implemented in this filter the option to introduce your real display gamut to use it like corrector (real gamut display->standard color space conversion)?:eek:

[Wilbert]

Could be implemented in this filter the option to introduce your real display gamut to use it like corrector (real gamut display->standard color space conversion)
Just curious. Is this a wise idea to do? What if you buy a new display one day?

[vega22]

Just curious. Is this a wise idea to do? What if you buy a new display one day?

...The day when the store lets to me to prove with my probe all your displays before paying. Anyway, do not exist displays calibrated. Mine it´s a month old. 1300$...Very very good grayscale, noise and gamma...but...

[tritical]

Well, finally a new version: [link removed]. Changes:
- Changed the integer scaling parameter to a boolean parameter named clamp
(scaling 1/2 were redundant)
- Fixed source==dest error when using d2v or hints
- Fixed thrdmthd being switched internally (i.e. backwards versus the behaviors
described in the readme)

@Dr.Khron
I looked into the issue you reported back in April and it turns out that it is a problem with tfm and info=3 in dgdecode and not colormatrix.

[Guest]

I looked into the issue you reported back in April and it turns out that it is a problem with tfm and info=3 in dgdecode Is there something I need to fix in DGDecode?

[tritical]

Actually, it seems I spoke too soon and there isn't a bug in anything. What's happening is that tdeint() is detecting the hints from dgdecode() thinking they are from telecide(), and then decides not to deinterlace because of them. The solution is to set hints=false in tdeint.

DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v",info=3)
colormatrix(hints=true,interlaced=true)
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1,hints=false)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=1)

[kumi]

thank you for the new build!

With version 2.2 and DVD-Rebuilder, it's now possible to do automatic, "set it and forget it" colorimetry conversion with this script pasted into the Filter Editor:

LoadPlugin("X:\Path\To\ColorMatrix.dll")
P:ColorMatrix(dest=0, hints=true)
I:ColorMatrix(dest=0, hints=true, interlaced=true)

Of course you need to enable hinting with MPEG2SOURCE_OPTS=info=3 in your REBUILDER.INI file, and change the dest parameter if using an encoder that expects something other than Rec.709.

How cool is that?

[FredThompson]

2.1 does that. It was in the notes a few builds prior of DVD-RB Pro. It's a very nice method.

[kumi]

Actually that was impossible with 2.1: the "source==dest" error kept coming up.

[FredThompson]

You missed the "c:" macro which was added to DVD-RB Pro scripts recently:

c:ColorMatrix(hints=true, opt=0)

This will use ColorMatrix only if it is needed.

[cweb]

Well, finally a new version: ColorMatrix v2.2 (http://bengal.missouri.edu/~kes25c/ColorMatrixv22.zip).

hi!

I guess the title of this thread should be updated :)
thanks for your work!

[JarrettH]

what's new in 2.2? :p

[Boulder]

http://forum.doom9.org/showthread.php?p=1038118#post1038118 ?

[yesgrey]

tritical,
Could you tell me how to calculate the conversion matrix coefficients?
For example these:
" +0.7152, +0.0722, +0.2126, // Rec.709 (0)
-0.3850, +0.5000, -0.1150,
-0.4540, -0.0460, +0.5000, "

Where do you start from and which are the equations?

Thanks.

[Wilbert]

v1.10 contains a text file "coefficients.txt" where those coefficients are derived.

[yesgrey]

v1.10 contains a text file "coefficients.txt" where those coefficients are derived.

Can you tell me where can I get it?

Thanks.

[yesgrey]

I have found v1.5 and it has the file. I will look at it.

Thanks.

[Wilbert]

I'm not sure whether i changed it in newer version, so i attached it for you.

[yesgrey]

Wilbert,
thanks for the file. It seems to be identical to the one I found. It was very helpfull.

[uncertainty]

Could someone confirm my understanding of this thread when using source material of HDTV TS (mpeg2 720p or 1080i). I should NOT enable any colormatrix conversion of the BT.709 colorimetry?
I'm currently using the latest builds of megui and after reading this thread I have disabled any color correction for these type of source material.


If I'm mistaken let me know...

thanks

[Adub]

What kind of encoding is your destination going to be? AVC, ASP, MPEG2, etc?

From you saying MeGUI, I am assuming AVC or ASP, so I do believe that you should enable Colormatrix for your encodes. Especially if you are using DGindex's hints for the encoding process.

Edit: Use colormatrix according to the source colorimetry, which DGindex displays when you use the "Preview" selection in the file menu.

[uncertainty]

What kind of encoding is your destination going to be? AVC, ASP, MPEG2, etc?

From you saying MeGUI, I am assuming AVC or ASP, so I do believe that you should enable Colormatrix for your encodes. Especially if you are using DGindex's hints for the encoding process.

Edit: Use colormatrix according to the source colorimetry, which DGindex displays when you use the "Preview" selection in the file menu.


Megui with AVC atm and from what Hansolo and Headbanger and others have stated in this thread that using colormatrix for HD source material ( TS 720p , 1080i) will have adverse color effects on AVC output.

This entire thread needs a summary written for it because atm there is so much conflicting information its hard to make heads or tails out of it.

[Adub]

The best thing for you to do is to do a comparison. Use a program like AvsP to compare two scripts. One using colormatrix, the other one not using colormatrix. The best result should obviously be the one with the best colors.

[Wilbert]

This entire thread needs a summary written for it because atm there is so much conflicting information its hard to make heads or tails out of it.
Yes, i will do that one day :) To busy with other stuff atm.

[IanB]

@uncertainty,

Actually, stop and think about the chain of processing your project has taken so far and will take to your ultimate viewing experience.

Typically a camera photographed a scene.

The image was processed and stored as an MPEG2 stream (YUV colour space) which you now have. In the processing a RGB->YUV conversion will have been done, hopefully using a standard conversion and hopefully the correct colourmetry information was included in the stream.

To view a YUV colour space image on a RGB display device there has to be a YUV->RGB conversion. To get the correct original colours back you must use the correct conversion. If the correct colourmetry information was included in the MPEG2 stream, and the display conversion process can correctly act on that information, no problem.

If the colourmetry of the data encoded in the original stream is not as you want/need it to be, the ColorMatrix filter allows you to change the colourmetry of YUV data directly to suit.

If the display process conversion is not as you want/need it to be, again the ColorMatrix filter allows you to change the colourmetry of YUV data directly to suit.

So if the original stream has wrongly documented colourmetry, you can fix it.

If the original stream is correct but simply not as your encoding process needs, you can fix it.

If your Dvd player or display device or what ever uses the wrong conversion, you can fix it.

You need to take a holistic view of the entire process and be clear what conversion matrix was/will be used at each YUV/RGB conversion.

i.e.
RGB ->[601]-> YUV -> ... ->[601]-> RGB
RGB ->[709]-> YUV -> ... ->[709]-> RGB

RGB ->[709]-> YUV -> [ColorMatrix 709to601] -> ... ->[601]-> RGB
RGB ->[601]-> YUV -> [ColorMatrix 601to709] -> ... ->[709]-> RGB

[redfordxx]

Hi, I have question on following:

I have mpg video from digicam which is reported ITU-R BT.470-2 in DGIndex. Acc to manual it means not to apply colormatrix, right?
I encoded it to "x264.mkv" using MeGui.

Then I tested the color with script like:
o=MPEGSource...
c=DirectShow("x264.mkv")
#emhasize difference
mt_lutxy(o,c,"x y - 10 * 128 +")
Then I receive very orange video...the colors are different.

Where could be the problem?

Robert

[foxyshadis]

You must use chroma="process" (or u=2,v=2) with mt tools, or color will be completely meaningless trash.

You can also use levels to do the job.

Even once you have that, there's no guarantee that DirectShow will render colors correctly, or even that mpeg2source will if the stream has the wrong colorspace. Comparing to a film print is literally the only way you can ever be sure the colors are correct.

[redfordxx]

oooooooooooh, beginner's mistake...

mt_lutxy(o,c,"x y - 10 * 128 +",y=3,u=3,v=3)is OK

[Vesi]

When I rip dvd to xvid megui shows these kind of colormetry for defrint type of source, and i don't know i should keep enable the megui's colorcorection and when not, as megui's default is enable always

ITU-R BT.470
ITU-R BT.601
ITU-R BT.709
SMPTE 170 M
SMPTE 240 M

and it is hard for me to know, do i need colormatrix or not. can some one explain this when i need to use colormatrix and when not?
and if there is any other type of color that not named in the following list please add it.
And how i use this filter? I am doing xvids and x264 using megui
and should i replace this with the one i got with megui?

[foxyshadis]

Simple: If it's anything but 601 for SD or 709 for HD you should use it, make sure you always use it with source->dest arguments. The readme mentions BT.470 and 170M are the same as 601, so just refer back to it if you ever forget.

[Vesi]

Will be this Enough
DGDecode_mpeg2source(----info=3)
ColorMatrix(hints=true,interlaced=true).

if I get anything else from the one you mentioned,that colormatrix is not needed for. or I should do it in another way or add some param

[foxyshadis]

Yes, but specify your destination if it's HD (where 709 is preferred). Colormatrix doesn't try to detect HD and will always use 601 by default.

[Vesi]

make sure you always use it with source->dest arguments.

Could you explain this in simple words, coz I am still not familiar with advance language of encoding :).

And I am doing Xvid,x264 and divx.
I did xvid test with source color ITU-R BT.709 and enable colormatrix, i check the file with avsp and found the color close to source, when i remove the info=3 and colormatrix line from the script, then found it a bit off and dark.

The most important thing is for me now, with which type of color I need ColorCorection when I am doing Xvid,Divx and x264.

[tritical]

I updated ColorMatrix to v2.3 (http://bengal.missouri.edu/~kes25c/ColorMatrixv23.zip) based on ideas from josey_wells' BZColorspace filter in this thread: http://forum.doom9.org/showthread.php?t=133389.

Changes:
- Calculate conversion coefficients for PB/PR rows from luma coefficients
- Added inputFR and outputFR parameters allowing for YUV range expansion/contraction
- Changed the clamp parameter from bool to int to allow specifying only pre clipping
or only post clipping or both

The YV12 assembly routines aren't coded such that they can support the case where inputFR/outputFR aren't equal, and I don't have enough time atm to rewrite them or write new ones. So for now, if inputFR/outputFR aren't equal then the c routine gets used. Luckily, the c routine is pretty fast (it should even be slightly faster in this version than prior versions). I also made it so that dest/source can be set equal now as long as inputFR/outputFR are not equal (in which case you just get a range conversion). I set up the defaults for inputFR/outputFR/clamp such that v2.3 acts the same as v2.2 by default.

[EuropeanMan]

Why can't I use the 'clamp' function via CM 2.3? Any idea...since i'm getting an error "argument is wrong type"?

[tritical]

'clamp' was changed from bool to int in v2.3. clamp=3 in v2.3 is the same as clamp=true in v2.2. clamp=0 in v2.3 is the same as clamp=false in v2.2. If you enter it as an int value and still get an error please post your script.

[IanB]

@tritical,

That was a mean thing to do, changing the calling sequence to a well loved plugin. :(

You could define 2 templates for the function and add a small amount of code to the create function to allow old bool clamp to still work along with the new int clamp.

[tritical]

That is a good idea for maintaining backwards compatibility in filter syntax (something I generally pay little attention to), and one that had never occured to me. However, I don't think it is a major problem here since most of the encoder guis that generate scripts with colormatrix don't specify the clamp parameter. In fact, clamp was new to v2.2 (previously it was an integer called 'scaling').

[EuropeanMan]

@Tritical...appreciate your help. I seem sorta dumb for not reading about the change in bool type :)
clamp works for me now...

[hkazemi]

I've compiled a summary to hopefully consolidate the threads and address the confusion over colorspace and the usage of Colormatrix. It is available at http://forum.doom9.org/showthread.php?t=133982#post1090068

[canuckerfan]

if I'm working with a dvd source that i'm upscaling to 720p using x264. what colourspace should the material be set to?

[Adub]

Probably rec 709, but that is not 100%. Try it and if the colors look washed out, try another matrix. It is impossible to set it right 100% of the time, as streams can often be mislabeled as the wrong colorspace.

[Zanejin]

Let's say I have a YV12 Rec.709 [0, 255] source that will be filtered by AviSynth without color-space conversion and then encoded by x264. Am I correct to say that because there are no conversions to RGB, ColorMatrix is unnecessary? And do the majority of LCD monitors display RGB rather than YUV?

[foxyshadis]

Everything displays RGB. Monitors, projectors, scanners, etc, aside from black & white stuff. It's nearly impossible to engineer phosphors that range from one hue to another.

As long as you specify the colorspace in x264's encoding options (see --longhelp), you can keep the source's colorspace and let the decoder worry about it. I believe 709 fullscale is default for HD anyway, with newer video drivers, if you do the conversion on the video card. If doing it in software, you have to use a decoder that uses that information.

[tre31]

Ok I was directed here by neuron2 regarding 'no hints' colormatrix dgindex and HDTV. It seems HDTV and other HD sources in particular are not handled well by colormatrix at all, 'unknown' errors, 'unspecified video (2)', etc. I read in the dgindex thread that hdtv sources were assumed too be bt.709, if that is the case then why not let colormatrix also assume that and then allow 'hints=true' too function properly using bt.709.

Currently I just use Colormatrix() - whether that does anything or is a solution too this problem I don't really know - or just remove it entirely from the script, but the fact remains that dgindex and colormatrix do not handle HD sources.

Perhaps someone can enlighten me on the best way too handle all this.

[Guest]

Specifically, we are asking if the hints should be set according to the assumptions DGIndex makes for the Info dialog when the stream does not specify colorimetry, or whether the hints should state that the colorimetry is unspecified. The latter is done now. I wanted to get the opinion of the ColorMatrix users before making any change to the hints.

[Wilbert]

Specifically, we are asking if the hints should be set according to the assumptions DGIndex makes for the Info dialog when the stream does not specify colorimetry, or whether the hints should state that the colorimetry is unspecified. The latter is done now.
I prefer the former :) Because it's good and otherwise users can't use hints in an automatic way.

[Guest]

And so it shall be.

[IanB]

Consider :- If the stream does not specify the colorimetry then Mpeg2Source should NOT set the hints to pretend that it does.

If Mpeg2Source makes a guess and presents it as fact then filters like ColorMatrix cannot be programmed to handle the no colorimetry case, i.e. a default behaviour or a user specified default.

I think the gist of the above thoughts is ColorMatrix is not handling the no colorimetry case as they would like. If that is the case then ColorMatrix should be changed not Mpeg2Source.

If you really must do it this way then at least set an extra bit to say the colorimetry value is "Guessed" so future filters can better handle the decision process.

[~bT~]

does anybody have a working link pls for v2.3?

[buzzqw]

http://www.64k.it/andres/data/avisynth/ColorMatrixv23.zip

BHH

[~bT~]

^ :thanks:

[foxyshadis]

Consider :- If the stream does not specify the colorimetry then Mpeg2Source should NOT set the hints to pretend that it does.

If Mpeg2Source makes a guess and presents it as fact then filters like ColorMatrix cannot be programmed to handle the no colorimetry case, i.e. a default behaviour or a user specified default.

I think the gist of the above thoughts is ColorMatrix is not handling the no colorimetry case as they would like. If that is the case then ColorMatrix should be changed not Mpeg2Source.

If you really must do it this way then at least set an extra bit to say the colorimetry value is "Guessed" so future filters can better handle the decision process.

I'm not sure. If no colorimetry is present, you're pretty hosed, there's no way to find a colormatrix automatically. The spec defaults are the only rational choice unless you've somehow obtained inside information on the real flags, in which case a manual override is needed in the script anyway. So it makes no difference either way except to people stuck with an older dgindex; for that case maybe colormatrix should be updated with the same code.

[canuckerfan]

if an intermediate lossless encoder was used (let's say lagarith) before Xvid or CCE would this produce unexpected results?

[foxyshadis]

Only if you perform a color conversion during lossless encoding. Keep it in YV12 through the whole chain and it'll be just fine.

[kandrey89]

I just started using ColorMatrix and having RTFM I'm still confused in how to apply it to my video.

Video is MPEG 2 Stream from DVD, in d2v format after being Film Forced to get rid of interlaced frames.
Color is indicated as SMPTE 170M(same as 601).
I intend to downsize and encode with XviD.

I'm looking at samples of 601, 709, in both PC and REC(regular-TV?), all are different, the faces in some are more yellow and some are more dimmer/brighter.
Questions:
1. Is SMPTE 170M = Rec.601? or PC.601?
2. If my video is Rec.601, do I need to use colormatrix at all since manual says 601 is for XviD encodes.
3. Which format should I choose, PC (brighter), or Rec (dimmer)? (PC looks really nice on screen, but Rec is more of a standard? and used for TVs?)
4. What color space should I set the video to if I want the video to look good both on PC and on TV, is that possible?
5. Do I need to ConvertToRGB if I want to encode into XviD? (saw this earlier in this thread, got me all confused)

Note: Just realized that ColorMatrix doesn't convert to PC.xxx, it's the ConvertToRGB that does it.

[kandrey89]

Help anyone?

[Ranguvar]

Question: I'm importing a (mostly) telecined DVD through DGIndex. I think I heard that ColorMatrix needs to run even before the IVTC, so should I set interlaced=true? Or not, since it's only telecined?

I would rather not Force Film.

[~bT~]

^ yes, unless u applied force film.

[45tripp]

@kandrey89

2.no
5.no

[pitch.fr]

hi

thank you for this awesome script!

was wondering if you could possibly add "REC-601 EBU" and "REC-601 SMPTE-C" colorspaces ?

I've given real world examples here, where it would very useful :
http://forum.doom9.org/showthread.php?p=1157662#post1157662

TIA,

[yup]

Hi all!

Simple question:
my source analog capture encoded huffyuv, my MPEG-2 encoder is CCE, can I use
ColorMatrix(mode="Rec.601->Rec.709")
in my script, and if yes where, after loading video file or at last string. In CCE setting I use Luminance level 16-235.

With kind regards yup.

[helms]

After reading this http://forum.doom9.org/showthread.php?t=133982#post1090068 I'm still unsure whether I'm correct in using

ColorMatrix(mode="Rec.709->Rec.601", hints=true, interlaced=true)

when downscaling HD (interlaced) to SD resolutions and encoding h264 video.

Is what I'm doing correct?

[Alex_ander]

Simple question:
my source analog capture encoded huffyuv, my MPEG-2 encoder is CCE, can I use
ColorMatrix(mode="Rec.601->Rec.709")
in my script, and if yes where, after loading video file or at last string. In CCE setting I use Luminance level 16-235.


A simple answer would be: if your capture source is in SD format, then you don't need ColorMatrix(); in case you go from HD to SD, you need conversion in the 709 -> 601 direction. Then it's better to use ColorMatrix() in place where the video is progressive or field-separated (if anywhere), or with 'interlaced=true' setting somewhere in the beginning of the script.
CCE is neutral to matrix type (like other encoders, doesn't change it or 'expect something special' as was considered earlier) and is also known to not write matrix type to file header (that is the possible reason why some software players may show input/output difference using their defaults).
That's my conclusion after reading the long discussion here and in similar threads, earlier I used to apply 601 -> 709 conversion with CCE in most cases.

[Alex_ander]

After reading this http://forum.doom9.org/showthread.php?t=133982#post1090068 I'm still unsure whether I'm correct in using

ColorMatrix(mode="Rec.709->Rec.601", hints=true, interlaced=true)

when downscaling HD (interlaced) to SD resolutions and encoding h264 video.

Is what I'm doing correct?

I suspect h264 uses 709 matrix for any resolution, then you probably don't need ColorMatrix in this case.

[OvejaNegra]

HI. After reading all this i'm a little confused about colormatrix. So i will post some questions/doubts and please feel free to correct me:

1- A source (like DVD for example) can use different coefficients for the color. The encorders like XVID, DIVX or X264 (or are we talking about the decoders?) use Rec.601. So colormatrix reads the info from DGindex (using hints or the d2v project) and : Converts the source coef to rec601 (to match the encoders/decoders or IF the source is already rec 601 it stays untouched.

2- The data inside my x264 encoding is YV12 (i will go back here later).
3- When i open a VOB file with DGIndex it converts to RGB (only for the preview of course) AND correct the levels of chroma and luma because the maximum black and white (for example) is just 236 and 16 (that will give me gray and allmost white in a PC with out correction). So it "scales" the range to 255-0. That's why i see a nice picture in my DGindex preview.
4- When i open my favorite avs script in my VDUB the same happens in the preview. (and i see a nice picture).
5- My X264 encoder process the data from my script (it's YV12) and the levels pass untouched, only if i insert colormatrix (hints=true) it will make a correction if necesary (but only in the coeffients, not in the YC levels right?).

6- The encoders won't alter the coefficients of the video or correct anything.

7- In the decoding stage (THIS IS THE PART THAT CONFUSE A LOT OF PEOPLE I THINK).The decoder (like ffdshow) pass the data in YV12 to the video renderer (like VMR9) and the renderer send the data to the video card (something like that). NOW, in some part, someone should scale the levels again (because my PC monitor is 0-255). The renderer or the video card driver BUT sometimes for several reasons that does not happens. And i don't have my nice image (some people think they are not using colormatrix correctly but colormatrix has nothing to do with this).

8-My fresh and new compressed MKV+X264+AAC does not look as nice as in the previews.

What can i do? (Appart of course of having updated drivers, directx and all that stuff)

a) Change the renderer in MPC (VMR9 works bad for me but overlay mixer do the trick, but i lose the subtitles)
b) Cancel the YV12/YUY2 etc output in ffdshow, it will output converted RGB. Looks nice for me but i loose speed with high resolutions.
c) Enable the levels filter in FFDshow and set the input to 16-235 if i remember well and the output to 0-255. That will scale the range. I don't loose speed
and looks fine for me.


If we start talking about bigger resolutions and different matrix things can be more complicated. Enough for me.

9- Haali Renderer makes the corrections? (but i will loose the subtitles if i use it).

10 -Where should i put colormatrix (hints=true) in my script if:

a) I'm encoding a pure interlaced movie (of course i should put the interlaced=true).
b) I'm using forced film in a 100% film movie.
c) I'm using honor pulldown flags with anime/hybrid DVD and TIVTC and all that stuff.

Please fell free to correct me. Use the number of the question to avoid innecessary quotes (10a, 3, etc)

I'm trying to understand the concept but it's a little "complicado" (complicated, in spanish)

Thanks.

[Wilbert]

1- A source (like DVD for example) can use different coefficients for the color.
Yes.

The encorders like XVID, DIVX or X264 (or are we talking about the decoders?) use Rec.601.
If you request RGB from them, they will use Rec.601. Otherwise they will leave them unaltered.

So colormatrix reads the info from DGindex (using hints or the d2v project) and : Converts the source coef to rec601 (to match the encoders/decoders or IF the source is already rec 601 it stays untouched.
Yes.

2- The data inside my x264 encoding is YV12 (i will go back here later).
Yes.

3- When i open a VOB file with DGIndex it converts to RGB (only for the preview of course) AND correct the levels of chroma and luma because the maximum black and white (for example) is just 235 and 16 (that will give me gray and allmost white in a PC with out correction). So it "scales" the range to 255-0. That's why i see a nice picture in my DGindex preview.
Yes. (Btw it's 235, and not 236.)

4- When i open my favorite avs script in my VDUB the same happens in the preview. (and i see a nice picture).
Yes. Note that it assumes Rec601.

5- My X264 encoder process the data from my script (it's YV12) and the levels pass untouched, only if i insert colormatrix (hints=true) it will make a correction if necesary (but only in the coeffients, not in the YC levels right?).
Yes. Irc, it will clip the data if you set levels=false. (I'm too lazy to look it up right now ...)

6- The encoders won't alter the coefficients of the video or correct anything.
Usually they don't. (Some do if you feed them RGB.)

7- In the decoding stage (THIS IS THE PART THAT CONFUSE A LOT OF PEOPLE I THINK).The decoder (like ffdshow) pass the data in YV12 to the video renderer (like VMR9) and the renderer send the data to the video card (something like that).
Yes.

NOW, in some part, someone should scale the levels again (because my PC monitor is 0-255).
Yes, if your source is YCbCr [16,235].

The renderer or the video card driver BUT sometimes for several reasons that does not happens. And i don't have my nice image (some people think they are not using colormatrix correctly but colormatrix has nothing to do with this).
Yes. As you note below, VMR9 doesn't scale the levels back.

8-My fresh and new compressed MKV+X264+AAC does not look as nice as in the previews.

What can i do? (Appart of course of having updated drivers, directx and all that stuff)

a) Change the renderer in MPC (VMR9 works bad for me but overlay mixer do the trick, but i lose the subtitles)
Yes.

b) Cancel the YV12/YUY2 etc output in ffdshow, it will output converted RGB. Looks nice for me but i loose speed with high resolutions.
Yes.

c) Enable the levels filter in FFDshow and set the input to 16-235 if i remember well and the output to 0-255. That will scale the range. I don't loose speed and looks fine for me.[/QUOTE]
Yes. Are you sure about this? Because i suspect you will also loose speed here.


9- Haali Renderer makes the corrections? (but i will loose the subtitles if i use it).
Irc, you can adjust these settings in Haali renderer.


10 -Where should i put colormatrix (hints=true) in my script if:

a) I'm encoding a pure interlaced movie (of course i should put the interlaced=true).
b) I'm using forced film in a 100% film movie.
c) I'm using honor pulldown flags with anime/hybrid DVD and TIVTC and all that stuff.
This should be covered in this thread (probably a few pages back).

[OvejaNegra]

Wilbert: THANK YOU!!!
I have now a new PC with a nice Nvidia GF7300, i don't loose speed using the RBG conversion or the leves correction, but i need more testing with HD resolutions.

I have a a very old Celeron 1.2 GH with Ati RAGE PRO II. With the conversion to RGB my videos with 704 X 480 are allmost unplayable. But with the levels setting everything is fine. Maybe i will loose speed with higher resolutions (like 1280 X 720) but with standard DVD my celeron is ok.


Levels=false? i can't find that here: http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm#options ???

If i'm using the software player X, most of them use overlay mixer as the default renderer, and i set ffdshow to output RGB: The overlay mixer will overcorrect the levels or with let them untouched? (because it assumes that the correction is already done)? Usually i use MPC but sometimes i test other players.

The overlay mixer ALWAYS correct the levels fine OR it's using the video card for that (and some times will fail if the card is crap or the drivers have bugs). On the other hand, if the correction is done in the overlay mixer, it's software+cpu. Why i dont loose speed? Yes i know that even the most crappy onboard chip decodes YV12 / IYUV but what about the correction of the levels?

I'm just looking for the most safe+trustable+easy way of doing the levels correction (just for telling my friends, not for me). It seems to me that the levels setting in FFDSHOW is safer but since the decoded data is YV12 then the overlay mixer in CoreMedia player (for example) will overcorrect the levels and screw everything. Or it can detect (even with YV12) that the levels are already corrected? I think not.


So, in the end the safer combination is MPC + VMR9 (if you want SSA subtitles in anime) + levels correction or MPC + VMR9 (if you want SSA subtitles in anime) + RGB forced output (if your pc can handle it) or MPC + HAALI (and the ffdshow subtitles). Or don't do anything and leave the work to the Overlay Mixer (IF you can trust in that quartz.dll :) ).

And finally: How can i (by visual inspection) check if my correction is fine? Like comparing the final frame in my player with a preview of the same in VDUB mod (using AVS serving)?

Any advice of how the avs script should be? Or DirectShowSource () it's enough?

NO WAIT! i have one more question: If i open one AVI in VDUB using AviSource () or in Premiere (using of course the VCM codecs) the correction still happens or something may fail? I'm sure Vdub will make the corrections but Premiere, not so sure. I hear rumors about premiere messing with the YV12 colors.


Thank you for your attention.

[tom942]

I don´t really know if this info is useful, but I'm going to post it.

I was playing with Indiana Jones and the Kingdom of the Crystal Skull and The Sleeping Beauty 50th Anniversary (both DVD R2 PAL Spain) and in my case, they are the first DVD's that I found with the colorimetry flag setted and they are really, really new.

When I opened it with DGMPEGDec 1.4.5, I've seen that the Colorimetry field reported: ITU-R BT.470-2. When I saw this, I opened in version 1.5.3, and it reported the same info without asterisk so the stream was flagged, wasn´t it?.

I post this because when I read the threads and FAQ's always it is supposed or assumed that DVD works with 601, but it is not sure, am I wrong?.

If these two new DVD's are correctly flagged, then can we say that BT.601 is the correct color matrix for DVD's MPEG2?.

So when we feed the streams to CCE or HC it should also be set to 601 and not 709?.

I hope this thing helps, if not, just ignore it :).

Regards.

[frank]

BT.601 stands for all standard TV with tube (standard color space) an analog SCART interface.
CCE only encodes BT.601, so you have to use colormatrix in every case for 709 flagged input.

But if you own a modern player with upscaling and HDMI connected to a flat screen TV (only these can show the enhanced color space), then you can use 709 if you have such coder.

[Alex_ander]

CCE doesn't write colormetry data to file header (DGIndex will use * symbol for the assumed info for SD). It will produce the same YUV type, as on input, but the player will always use BT601 coefficients for RGB output, so yes, in case the source before encoding is BT709, you need ColorMatrix for turning it into BT601.

[manono]

When I opened it with DGMPEGDec 1.4.5, I've seen that the Colorimetry field reported: ITU-R BT.470-2. When I saw this, I opened in version 1.5.3, and it reported the same info without asterisk so the stream was flagged, wasn´t it?.

I post this because when I read the threads and FAQ's always it is supposed or assumed that DVD works with 601, but it is not sure, am I wrong?.
ITU-R BT.470-2 is exactly the same as ITU-R BT.601. There's nothing unusual about it and I see it from time to time.

[smok3]

my source is 0-255 RGB huffyuv avi, how should i use this filter for this encoders:
a. hcenc
b. x264
c. wmv
or should i just change the levels to 16-235? tnx.
(this is practical question)

[Adub]

What resolution are your target formats?

Are you going to be creating a DVD with this? Or is it going to be stored on a computer for personal use?

[tom942]

The idea of my initial post was just to give another two evidences that when DVD's MPEG2 is flagged, it reports BT.601. They also reports that are progressive, when they normally were wrongly flagged as interlaced, at least in PAL zone.

I just post it, because when I read the FAQ's about if a DVD uses BT.601 it is only assumed or supposed, but I don´t see a firm statement that says: it is sure that DVD's MPEG2 stream use BT.601 always when you are doing a DVD to DVD backup.

For instance, when I read the FAQ's it says that CCE doesn´t expect a concrete color matrix, but if I continue reading, then says that one people says that it expects 601 and others, 709. In the same FAQ, it says that HC expects 709, although confirmation is needed. Then, I don´t know what to do :).

As these two DVD's have been just released, I thought that it was a good idea to let you know this findings and I would like to know if it is good to "force" to use BT.601 when doing a DVD to DVD backup :).

Regards :)

[smok3]

Merlin7777:

yes, one export will be dvd, x264 will be for flash and one version will be HD, wmv will be web.

source is 1280x720, dvd will be anamorfic pal.

[tom942]

In summary:

If I use CCE, Basic or SP(2), to do a backup of a DVD, doing all the steps by hand or using DVD-RB (for instance), I should use BT.601 because it is ¿sure? that CCE expects as input this color matrix, shouldn´t I?

If I use HC, what color matrix should I use?, which one HC expects, 601 or 709?. I have read the FAQ, and it says 709, but it needs confirmation...

Any advice? :).

[Alex_ander]

There was a separate thread with some useful analysis:
http://forum.doom9.org/showthread.php?p=1193065#post1193065

As for what CCE expects, then according to its manual (SP), in some cases (when it needs conversion between YUV&RGB32) it uses BT601 coefficients. In case you feed YUY2 or any avi file that can be decompressed to YUY2, the manual doesn't mention any calculations of ColorMatrix' style.

[tom942]

@Alex_ander

I was re-reading the link (and some of the threads) that you gave me (this is the FAQ that I was talking about).

If I understood it right, when I'm doing a backup from DVD to DVD, using DGIndex, DVD-RB or other similar, there is no need to use ColorMatrix meanwhile I do not convert to RGB. I don´t talk of upconvert to HD or downconvert to SD.

CCE doesn´t expect a concrete color space. It doesn´t do internal color conversion while encoding.

The same applies to HC encoder, deesn´t it?

The doubt that I've got comes because in that link says HC expects 709, but reading Hanks's posts, he seems to say that HC doesn´t expect a concrete color space, is it right?

In the past I have used the line "Colormatrix (mode=rec.601->rec.709)" but if I undestand it right, I don´t need to use it anymore neither CCE nor HC, is it right?.

[Adub]

@smok3
You may get a kick out of this thread:
http://forum.doom9.org/showthread.php?t=133982&highlight=color+information+bt.601

However, here is what I believe is correct:

Use Rec.601 for HCenc. Be sure to set the flag correctly when you encode it with HCenc.

For the x264 flash, since it will be SD, I believe you also use Rec.601.
For the HD x264, use Rec.709.

For WMV, I have no idea. My best suggestion would be to try both and see which one looks better. This approach can be applied to all of the above encoding situations.


@tom942
Yes, it's sounding like you are right. There should be no need for colormatrix when going from DVD to DVD. The trick with CCE is that it wants YUY2 input, but that is about it. DVD-RB should handle this all correctly for you.

And if you look at HCenc's documentation, I believe that it likes Rec.601 for SD and Rec.709 for HD. Again, refer to the above link that I posted for more information.

[tom942]

Thank you Merlin7777 :).

I was reading that thread (that Alex_ander already point me before) and there was a point that confuse me:

What encoders expect BT.709?
HCenc, any other encoder that by default flags the output stream as BT.709
(verification would be appreciated)

But then, after re-reading nearly all threads, I found tests that Hank done with his encoder and I can undestand that it doesn´t expect anything. It takes what you give him.

http://forum.doom9.org/showthread.php?p=1061520#post1061520

As you said, I suppose that Hank is following the rule of 601 for SD and 709 for HD.

What I'm looking for is that I want do the correct steps with the apps. Later, if my DVD player do other things, it doesn´t mind me, because it wouldn´t be my fault.

Thank you for your time and answers :).

P.S.: This was the table I used to follow. I found it here some time ago:

Source_Colorimetry------------------Encoder-------------------Conversion_to_Use
Rec.709----------------------------CCE/HC/QuEnc-------------No Conversion or 'Rec.601 -> Rec.709 with hints=true'
Rec.601----------------------------CCE/HC/QuEnc-------------Rec.601->Rec.709 or 'Rec.601 -> Rec.709 with hints=true'
Rec.709----------------------------TMPGEnc------------------Rec.709 -> Rec.601 or 'Rec.709 -> Rec.601 with hints=true'
Rec.601----------------------------TMPGEnc------------------No Conversion or 'Rec.709 -> Rec.601 with hints=true'

As you can see, it was the opposite :).

[Adub]

Rec.709----------------------------CCE/HC/QuEnc-------------No Conversion or 'Rec.601 -> Rec.709 with hints=true'

That table seems screwed. Why would one use the 601->709 conversion on a source that is already 709? It makes absolutely no sense.

[tom942]

I don´t know.
It is a table that was in the forum before last year color matrix discussion. I found it when everybody assumed that DVD's MPEG2 was 709 due to the way that old versions of DGMPGDec report the absence of the colorimetry flag.

[smok3]

about luma range (and flash playback);

a. puting the whole 0-255 'RGB' range into yv12 -> x264 and then playing that back via flash seems wrong (the blacks are clipped? dunno...), doing the pc->tv conversion before will give more acceptable results (if little washed out)

about DVD;

b. i fed hcenc with squashed range (16-235) and again it seems a bit washed out (with mpui or vlc), but more black would look wrong again as it seems

:confused:

[fano]

I'm having some problem resing a 632*264 video to 1920*108p and using colormatrix to restore the right colors.
I see a little band on the right part of the image: it seems as a repetition of a part of image.

In this screenshot you can see clearly what is the problem:
http://img155.imageshack.us/img155/6725/garbagedresizehalfresax4.png

This the avisinth script that I'm using:


setMtmode(2)
ColorMatrix(mode="Rec.601->Rec.709")
ffdshow_setDAR(ffdshow_dar_x, ffdshow_dar_y)
MT("hqdn3d(2)", threads=4)
DisposeAxis(1920, 1080, ffdshow_dar_x, ffdshow_dar_y)
MT("Spline16Resize(da_w, last.height)", threads=4)
MT("Spline16Resize(last.width, da_h)", threads=4, splitvertical=true)


If I delete the colormatrix line or pospone it after resize the colored line disappear... but Colormatix after resize has not effect, right?

There is a known solution for this or maybe is a bug?

Thanks for your help,
fanoI

[tritical]

There's a bug in the mmx/sse2 routines causing it not to process the last (width&15) for sse2 and (width&7) for mmx worth of pixels for non mod 16 and non mod 8 widths respectively (you end up with whatever values happen to be at that those memory locations in the destination frame). A temporary fix is to set opt=0 to force the C routines. I'll put up a fixed version later tonight, it just needs one line changed.

[fano]

I've tried to add opt=0 and now works right!

Thanks for your help,
fanoI

[tritical]

I put up v2.4 on my website. Only change was fixing this little problem.

[fano]

Ok I'll try it tonight :)

[vucloutr]

hi, got a problem with colormatrix (using the latest 2.4).

LoadPlugin("..\DGDecode.dll")
DGDecode_MPEG2Source("file.d2v")

ColorMatrix(d2v="file.d2v")
Source is a MPEG2 HDTV .ts and I used DGIndex 1.5.3 for indexing.
With this script, I get an error message "ColorMatrix: d2v and filter frame counts do not match!"
Without the .d2v param and with info=3&hints=true i get strange colors in some frames.
normal.png (2.3 MB) (http://a.imagehost.org/view/0910/normal)
strange.png (2.1 MB) (http://a.imagehost.org/view/0561/strange)

any help is appreciated :)

[tritical]

If you turn on debug output what source colorimetry does it detect for the good frames and the bad frames? That d2v error about frame count mismatch will only trigger if multiple colorimetrys are present. Could you post a sample?

[vucloutr]

debugview log says: 00000173 14.75968838 [1248] ColorMatrix:1784: frame 86432: detected hint = 1 (Rec.709)
00000174 14.75977802 [1248] ColorMatrix:2908: frame 86432: using YV12 Rec.709->Rec.601 conversion (SSE2).
00000175 15.04918671 [1248] ColorMatrix:1784: frame 86433: detected hint = 4 (FCC)
00000176 15.04928112 [1248] ColorMatrix:2908: frame 86433: using YV12 FCC->Rec.601 conversion (SSE2).
first is the "normal" frame and second is the "strange" one.

here's a sample (.7z ~45MB) (http://www.megaupload.com/?d=37043OPD) (P4S5VV0RD: fw48czlqw94bgt g-f45tw-3.6mw.56w-v3mn)

[tritical]

There were two bugs causing problems. First was that the d2v parsing was never updated for v16 DGIndex project files. This didn't effect colorimetry detection in v16 d2vs, but frame count detection was incorrect (only a problem if multiple colorimetrys were present). Second, there was a bug in the mmx/sse2 routines used for FCC<->Rec.601 conversions that caused incorrect U plane values. Both problems are fixed in v2.5 on my website.

[vucloutr]

thanks!

edit: whoops ^^

[canuckerfan]

if a conversion from 601 to 709 has been done. can it be reversed by just calling colormatrix again and changing the destination to 601? I realize it would just be best to go back and not do the conversion in the first place.

[Wilbert]

if a conversion from 601 to 709 has been done. can it be reversed by just calling colormatrix again and changing the destination to 601? I realize it would just be best to go back and not do the conversion in the first place.
Sure. Use mode="Rec.709->Rec.601".

[leeperry]

http://thumbnails14.imagebam.com/5155/6cd6d751549075.gif (http://www.imagebam.com/image/6cd6d751549075)

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

http://thumbnails9.imagebam.com/5155/7e837451549079.gif (http://www.imagebam.com/image/7e837451549079)

why would it change the levels :confused:

[Keiyakusha]

Hi. I'd like to ask something about colormatrix...

Here (http://img230.imageshack.us/img230/3301/infoor.png) is info from DGIndex about my DVD.
Here (http://img156.imageshack.us/img156/7328/29471546.png) is a screenshot, taken in VirtualDub using avisynth script with only one line in it: Mpeg2source("VTS_01_1.d2v")
Here (http://img156.imageshack.us/img156/667/kkkkkkkk.png) is a screenshot of the same frame, but taken with following script: Mpeg2source("VTS_01_1.d2v",info=3).Colormatrix(hints=true,interlaced=true)
It looks like screenshots are the same, but here (http://img83.imageshack.us/img83/1112/13520879.png) is what I see after overlaying them using "difference" and boosting levels.

I expected to see no difference at all or to see much more difference... So all is fine here, this is how it should be? Am I doing something wrong?

[Keiyakusha]

After reading many nice posts by manono in this (http://forum.doom9.org/showthread.php?t=134684) thread, I think maybe the difference on my screens appears because of clamping some levels after applying colormatrix. Indeed such things shouldn't be done 'behind the back'.

[leeperry]

indeed, RTFM helped me a lot too :D

ColorMatrix(mode="Rec.601->Rec.709",clamp=0,opt=0)

[leeperry]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn

[Keiyakusha]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn

Thanks :goodpost:

[Wilbert]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn
Please, include the source. Thanks.

[XhmikosR]

So you need the ICL project files? Because that's the only thing that's different and that I changed the File Info to distinguish it from the normal build.
Anyway, here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca5d770fd2dc6da976) is the package with the source included.

[JoeH]

Thanks for your great tool. I use it all the time.

I was wondering if it would be feasible to prepare a 64-bit version. I have been looking at squid_80's 64 bit version of AVISynth and related 64-bit plugins that he has prepared, and he has everything I use in AVISynth ready in 64-bit except ColorMatrix.

I have no idea what that would imply, but if it is something feasible it would be great! Thanks again.

[leeperry]

hi tritical, I was wondering if you had any idea about this: http://forum.doom9.org/showpost.php?p=1341393&postcount=1751

problem of chroma alignment possibly? any idea how to get the same exact output as ffdshow please?

:thanks:

[yesgrey]

any idea how to get the same exact output as ffdshow please?
When you use t3dlut, the conversion between BT.601 and BT.709 coefficients is performed like this:
1) up-sample chroma from 4:2:0 or 4:2:2 to 4:4:4
2) convert BT.601 -> BT.709
3) sub-sample chroma from 4:4:4 to 4:2:0 or 4:2:2
I'm not sure about Colormatrix, but I think it will work similarly...
When you use ffdshow it's a different thing, because you are not converting YV12->YV12 or YUY2->YUY2, you are converting YV12->RGB32, and in this kind of conversion, you don't need to downsample the chroma at the end.

Summing up, you only could be able to get the same output as ffdshow if you use it like ffdshow. With t3dlut, you should set it for YV12->RGB32, and not for YV12->YV12 as you are performing in your examples. With Colormatrix, that's not possible, because it only performs conversions between YV12/YUY2->YV12/YUY2.

[leeperry]

ok, but we had the same problem when I wanted to get the same output from your LUT as I was getting from the PS script...and at some point, we did! you told me there was some hiccup in the LUT code and made a bugfix :o

I'll try to fix the 601>709 LUT conversion .ini file, and hopefully I'll have more details about what's "broken" to give to tritical.

[yesgrey]

hopefully I'll have more details about what's "broken" to give to tritical.
I don't think there's anything that tritical could "fix".
From what I understand, the difference between Colormatrix and t3dlut is that the later let's the user define which chroma placement to consider, while the former always assume it internally.
I believe the problem is due to the last step of chroma sub-sampling, so I don't think it could be fixed, because there is nothing to fix...;)

[leeperry]

well, maybe he could allow to choose the chroma alignment? :o

[yesgrey]

well, maybe he could allow to choose the chroma alignment? :o
First, try with t3dlut chroma alignment options. If it doesn't solve the problem, adding the chroma alignment to Colormatrix will not help also...

[leeperry]

First, try with t3dlut chroma alignment options. If it doesn't solve the problem, adding the chroma alignment to Colormatrix will not help also...
I've just tried all the possible settings in t3dlut/yv12toyuy2 and yuy2toyv12...what works the best is t3dlut(cplaceU=1) + yv12toyuy2(itype=0):

http://thumbnails23.imagebam.com/6152/1e2c9361511788.gif (http://www.imagebam.com/image/1e2c9361511788)

but if you compare to these, ffdshow still looks slightly better IMHO: http://forum.doom9.org/showpost.php?p=1341393&postcount=1751

still would be pretty cool if tritical could allow to change the chroma placement in ColorMatrix() http://forum-images.hardware.fr/images/perso/otakonleboss.gif

[tritical]

To match ffdshow you probably need to set itypeU=1 in t3dlut. Since by default t3dlut uses cubic interpolation for 4:2:2->4:4:4, which utilizes 4 pixels, so the end points of the kernel will still be spanning those color blocks. Anyways, I think basing what looks best on that one image is not a good idea. It contains big blocks of color with hard transitions and mpeg1 chroma placement... so of course duplication and mpeg1 chroma placement assumption in t3dlut/yv12toyuy2 will look best on it. However, I could easily generate an image where that combination will look much worse than cubic interpolation with mpeg2 chroma placement assumed. Anyways, with respect to colormatrix there is nothing to change in regards to chroma alignment since it does not upsample. It converts directly YUV->YUV, to get the UV values for computing the new Y samples it uses nearest neighbor. That is, in YV12 each set of 4 luma pixels ((x,y)(x+1,y)(x,y+1)(x+1,y+1)) uses the U and V pixels at (x>>1,y>>1) in the U and V plane respectively.

[leeperry]

ok, thanks for the feedback tritical...if you say that this doesn't matter(even on a wide projection screen), I wholeheartly believe you http://forum.slysoft.com/images/smilies/agreed.gif

[Shinji-kun]

I encoded an MPEG-2 file to MPEG-4 AVC (x264). Would colormatrix be necessary in this situation. The brightness does seem a little off.

[[DB-FR] Nikko]

You answer is here in the first message of this topic ^^:

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders, with the result that DivX/XviD clips or mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors (which looks like a small difference in brightness ).

[henryho_hk]

If I put "info=3" in mpeg2source() and "hints=true" in colormatrix(), do I need to specify "interlaced=true" in colormatrix() too?

[SilaSurfer]

If you are dealing with interlaced source I think yes.

[henryho_hk]

Oh, I thought the interlace information is put in the hints by "info=3". Thanks for the clarification. (But.... why isn't it?)

One further question about "clamp" and "outputFR". I am encoding AVI from DVDs for viewing on PC monitor (TFT LCD), using madVR (32bit) and VMR9 renderless (64bit XP). Should I specify both "clamp=0" and "outputFR=true" ?

[Wilbert]

Oh, I thought the interlace information is put in the hints by "info=3". Thanks for the clarification. (But.... why isn't it?)
Indeed it's not. It's not, because it's not made that way :) Using the interlaced flag from DGDecode/mpeg2source is not reliable way to determine whether the stream is trully interlaced.

From the documentation:
hints:

DGDecode v1.20 or newer can output colorimetry hints in the video stream which ColorMatrix can read in order to automatically determine the source coefficients.

[Boulder]

But doesn't the source being encoded as interlaced force the use of interlaced=true even if the stream is actually progressive?

[Wilbert]

But doesn't the source being encoded as interlaced force the use of interlaced=true even if the stream is actually progressive?
Do you mean 'force' as in forced by using hints? Then no. No interlaced information is passed by hints.

[Boulder]

I meant "force" as in "force the user to set interlaced=true in CM" since the chroma information has been encoded as interlaced anyway.

[leeperry]

Hi tritical,

Thanks for the great ColorMatrix(), I use it for upscaled SD through madVR :)

I was wondering, is there a way you could implement 16bit? like the hack recently added to SmoothAdjust() that I also use: http://forum.doom9.org/showpost.php?p=1504207&postcount=210

I run Avisynth 2.6 if that matters.

:thanks: for considering it!

[szabi]

Hi

I am using megui, it creates this line to aviscript, when my source is :
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDecode.dll")
DGDecode_mpeg2source("C:\wedding\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)
My question what does "threads=0" mean?

Bye
szabi

[leeperry]

what does threads=0 mean?
it's all explained in the manual.

[steptoe]

Sets the number of threads Colormatrix will use for processing. Can be any value greater than 0 and, for YUY2, less than the frame height, for YV12, less than the frame height divided by 2. If set to 0, ColorMatrix will automatically detect the number of available processors and set threads equal to that value

So if you have a dual core processor, with threads=0 then it will use both cores to process the source, with quad core it will use all 4 cores to process the source and so on


I personally set it by hand then you know it really is using all CPU cores, so threads=4 would be the value set on my quad core

[szabi]

Thnx, for the explaination.
It helped me. :)

bye
szabi

[mandarinka]

Hi tritical,

Thanks for the great ColorMatrix(), I use it for upscaled SD through madVR :)

I was wondering, is there a way you could implement 16bit? like the hack recently added to SmoothAdjust() that I also use: http://forum.doom9.org/showpost.php?p=1504207&postcount=210

I run Avisynth 2.6 if that matters.

:thanks: for considering it!

For encoding where absolute speed isn't critical beyond some basic level, what would suffice would be some script for the most needed conversions between rec709 and rec601.
But of course, somebody who 1) knows what to do 2) can write such a function would be needed...

EDIT:

Actualy I missed this initialy, but since version 1.9, Dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) includes functions to convert between rgb and yv12, which can be coupled to perform a 16bit (stacked format) conversion between any of FCC, ITU-R BT.601, ITU-R BT.709 and SMPTE 240M.

[TalasNetrag]

The download link is dead.

[StainlessS]

Yep all links to it seem dead.

http://www.mediafire.com/download/69xnjjxannnqo8b/ColorMatrixv25.zip

EDIT: Includes source.

[kedautinh12]

I see v2.6 of colormatrix add Rec.2020 support.
https://github.com/sorayuki/ColorMatrix/release

[StainlessS]

kedautinh12, Your link is 404 (you missed the last 's' off the end ie should be 'releases')

https://github.com/sorayuki/ColorMatrix/releases

[Selur]

Anyone got a link to a 64bit ColorMatrix 2.6 build?

[StainlessS]

Selur, Grouchy Avisynth stuff:- https://forum.doom9.org/showthread.php?t=173259

[Selur]

Thanks :)