ColorMatrix v2.3

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

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

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]

Originally Posted by canuckerfan

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]

Originally Posted by canuckerfan

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

Originally Posted by unskinnyboy

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.

Originally Posted by Wilbert

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.ph...894#post879894

[unskinnyboy]

Originally Posted by G_M_C

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