ColorMatrix v2.3

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