ColorMatrix v2.3

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

DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v")
ColorMatrix(debug=true)

[896] ColorMatrix: frame 0: using YV12 Rec.709->Rec.601 conversion (MMX).

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]

Originally Posted by Dr.Khron

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]

Originally Posted by KillerZero

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 !
(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 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]

Originally Posted by 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?

All H.264/AVC and VC1 videos on HD-DVD's and Blu-Ray are BT.709 colorimetry.