ColorMatrix v2.3

[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

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

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 .

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

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?