ColorMatrix v2.3

[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(?).