ColorMatrix v2.3

[yesgrey]

v1.10 contains a text file "coefficients.txt" where those coefficients are derived.

Can you tell me where can I get it?

Thanks.

[yesgrey]

I have found v1.5 and it has the file. I will look at it.

Thanks.

[Wilbert]

I'm not sure whether i changed it in newer version, so i attached it for you.

[yesgrey]

Wilbert,
thanks for the file. It seems to be identical to the one I found. It was very helpfull.

[uncertainty]

Could someone confirm my understanding of this thread when using source material of HDTV TS (mpeg2 720p or 1080i). I should NOT enable any colormatrix conversion of the BT.709 colorimetry?
I'm currently using the latest builds of megui and after reading this thread I have disabled any color correction for these type of source material.


If I'm mistaken let me know...

thanks

[Adub]

What kind of encoding is your destination going to be? AVC, ASP, MPEG2, etc?

From you saying MeGUI, I am assuming AVC or ASP, so I do believe that you should enable Colormatrix for your encodes. Especially if you are using DGindex's hints for the encoding process.

Edit: Use colormatrix according to the source colorimetry, which DGindex displays when you use the "Preview" selection in the file menu.

[uncertainty]

What kind of encoding is your destination going to be? AVC, ASP, MPEG2, etc?

From you saying MeGUI, I am assuming AVC or ASP, so I do believe that you should enable Colormatrix for your encodes. Especially if you are using DGindex's hints for the encoding process.

Edit: Use colormatrix according to the source colorimetry, which DGindex displays when you use the "Preview" selection in the file menu.


Megui with AVC atm and from what Hansolo and Headbanger and others have stated in this thread that using colormatrix for HD source material ( TS 720p , 1080i) will have adverse color effects on AVC output.

This entire thread needs a summary written for it because atm there is so much conflicting information its hard to make heads or tails out of it.

[Adub]

The best thing for you to do is to do a comparison. Use a program like AvsP to compare two scripts. One using colormatrix, the other one not using colormatrix. The best result should obviously be the one with the best colors.

[Wilbert]

This entire thread needs a summary written for it because atm there is so much conflicting information its hard to make heads or tails out of it.
Yes, i will do that one day :) To busy with other stuff atm.

[IanB]

@uncertainty,

Actually, stop and think about the chain of processing your project has taken so far and will take to your ultimate viewing experience.

Typically a camera photographed a scene.

The image was processed and stored as an MPEG2 stream (YUV colour space) which you now have. In the processing a RGB->YUV conversion will have been done, hopefully using a standard conversion and hopefully the correct colourmetry information was included in the stream.

To view a YUV colour space image on a RGB display device there has to be a YUV->RGB conversion. To get the correct original colours back you must use the correct conversion. If the correct colourmetry information was included in the MPEG2 stream, and the display conversion process can correctly act on that information, no problem.

If the colourmetry of the data encoded in the original stream is not as you want/need it to be, the ColorMatrix filter allows you to change the colourmetry of YUV data directly to suit.

If the display process conversion is not as you want/need it to be, again the ColorMatrix filter allows you to change the colourmetry of YUV data directly to suit.

So if the original stream has wrongly documented colourmetry, you can fix it.

If the original stream is correct but simply not as your encoding process needs, you can fix it.

If your Dvd player or display device or what ever uses the wrong conversion, you can fix it.

You need to take a holistic view of the entire process and be clear what conversion matrix was/will be used at each YUV/RGB conversion.

i.e.
RGB ->[601]-> YUV -> ... ->[601]-> RGB
RGB ->[709]-> YUV -> ... ->[709]-> RGB

RGB ->[709]-> YUV -> [ColorMatrix 709to601] -> ... ->[601]-> RGB
RGB ->[601]-> YUV -> [ColorMatrix 601to709] -> ... ->[709]-> RGB

[redfordxx]

Hi, I have question on following:

I have mpg video from digicam which is reported ITU-R BT.470-2 in DGIndex. Acc to manual it means not to apply colormatrix, right?
I encoded it to "x264.mkv" using MeGui.

Then I tested the color with script like:
o=MPEGSource...
c=DirectShow("x264.mkv")
#emhasize difference
mt_lutxy(o,c,"x y - 10 * 128 +")
Then I receive very orange video...the colors are different.

Where could be the problem?

Robert

[foxyshadis]

You must use chroma="process" (or u=2,v=2) with mt tools, or color will be completely meaningless trash.

You can also use levels to do the job.

Even once you have that, there's no guarantee that DirectShow will render colors correctly, or even that mpeg2source will if the stream has the wrong colorspace. Comparing to a film print is literally the only way you can ever be sure the colors are correct.

[redfordxx]

oooooooooooh, beginner's mistake...

mt_lutxy(o,c,"x y - 10 * 128 +",y=3,u=3,v=3)is OK

[Vesi]

When I rip dvd to xvid megui shows these kind of colormetry for defrint type of source, and i don't know i should keep enable the megui's colorcorection and when not, as megui's default is enable always

ITU-R BT.470
ITU-R BT.601
ITU-R BT.709
SMPTE 170 M
SMPTE 240 M

and it is hard for me to know, do i need colormatrix or not. can some one explain this when i need to use colormatrix and when not?
and if there is any other type of color that not named in the following list please add it.
And how i use this filter? I am doing xvids and x264 using megui
and should i replace this with the one i got with megui?

[foxyshadis]

Simple: If it's anything but 601 for SD or 709 for HD you should use it, make sure you always use it with source->dest arguments. The readme mentions BT.470 and 170M are the same as 601, so just refer back to it if you ever forget.

[Vesi]

Will be this Enough
DGDecode_mpeg2source(----info=3)
ColorMatrix(hints=true,interlaced=true).

if I get anything else from the one you mentioned,that colormatrix is not needed for. or I should do it in another way or add some param

[foxyshadis]

Yes, but specify your destination if it's HD (where 709 is preferred). Colormatrix doesn't try to detect HD and will always use 601 by default.

[Vesi]

make sure you always use it with source->dest arguments.

Could you explain this in simple words, coz I am still not familiar with advance language of encoding :).

And I am doing Xvid,x264 and divx.
I did xvid test with source color ITU-R BT.709 and enable colormatrix, i check the file with avsp and found the color close to source, when i remove the info=3 and colormatrix line from the script, then found it a bit off and dark.

The most important thing is for me now, with which type of color I need ColorCorection when I am doing Xvid,Divx and x264.

[tritical]

I updated ColorMatrix to v2.3 (http://bengal.missouri.edu/~kes25c/ColorMatrixv23.zip) based on ideas from josey_wells' BZColorspace filter in this thread: http://forum.doom9.org/showthread.php?t=133389.

Changes:
- Calculate conversion coefficients for PB/PR rows from luma coefficients
- Added inputFR and outputFR parameters allowing for YUV range expansion/contraction
- Changed the clamp parameter from bool to int to allow specifying only pre clipping
or only post clipping or both

The YV12 assembly routines aren't coded such that they can support the case where inputFR/outputFR aren't equal, and I don't have enough time atm to rewrite them or write new ones. So for now, if inputFR/outputFR aren't equal then the c routine gets used. Luckily, the c routine is pretty fast (it should even be slightly faster in this version than prior versions). I also made it so that dest/source can be set equal now as long as inputFR/outputFR are not equal (in which case you just get a range conversion). I set up the defaults for inputFR/outputFR/clamp such that v2.3 acts the same as v2.2 by default.

[EuropeanMan]

Why can't I use the 'clamp' function via CM 2.3? Any idea...since i'm getting an error "argument is wrong type"?

[tritical]

'clamp' was changed from bool to int in v2.3. clamp=3 in v2.3 is the same as clamp=true in v2.2. clamp=0 in v2.3 is the same as clamp=false in v2.2. If you enter it as an int value and still get an error please post your script.

[IanB]

@tritical,

That was a mean thing to do, changing the calling sequence to a well loved plugin. :(

You could define 2 templates for the function and add a small amount of code to the create function to allow old bool clamp to still work along with the new int clamp.

[tritical]

That is a good idea for maintaining backwards compatibility in filter syntax (something I generally pay little attention to), and one that had never occured to me. However, I don't think it is a major problem here since most of the encoder guis that generate scripts with colormatrix don't specify the clamp parameter. In fact, clamp was new to v2.2 (previously it was an integer called 'scaling').

[EuropeanMan]

@Tritical...appreciate your help. I seem sorta dumb for not reading about the change in bool type :)
clamp works for me now...

[hkazemi]

I've compiled a summary to hopefully consolidate the threads and address the confusion over colorspace and the usage of Colormatrix. It is available at http://forum.doom9.org/showthread.php?t=133982#post1090068

[canuckerfan]

if I'm working with a dvd source that i'm upscaling to 720p using x264. what colourspace should the material be set to?

[Adub]

Probably rec 709, but that is not 100%. Try it and if the colors look washed out, try another matrix. It is impossible to set it right 100% of the time, as streams can often be mislabeled as the wrong colorspace.

[Zanejin]

Let's say I have a YV12 Rec.709 [0, 255] source that will be filtered by AviSynth without color-space conversion and then encoded by x264. Am I correct to say that because there are no conversions to RGB, ColorMatrix is unnecessary? And do the majority of LCD monitors display RGB rather than YUV?

[foxyshadis]

Everything displays RGB. Monitors, projectors, scanners, etc, aside from black & white stuff. It's nearly impossible to engineer phosphors that range from one hue to another.

As long as you specify the colorspace in x264's encoding options (see --longhelp), you can keep the source's colorspace and let the decoder worry about it. I believe 709 fullscale is default for HD anyway, with newer video drivers, if you do the conversion on the video card. If doing it in software, you have to use a decoder that uses that information.

[tre31]

Ok I was directed here by neuron2 regarding 'no hints' colormatrix dgindex and HDTV. It seems HDTV and other HD sources in particular are not handled well by colormatrix at all, 'unknown' errors, 'unspecified video (2)', etc. I read in the dgindex thread that hdtv sources were assumed too be bt.709, if that is the case then why not let colormatrix also assume that and then allow 'hints=true' too function properly using bt.709.

Currently I just use Colormatrix() - whether that does anything or is a solution too this problem I don't really know - or just remove it entirely from the script, but the fact remains that dgindex and colormatrix do not handle HD sources.

Perhaps someone can enlighten me on the best way too handle all this.

[Guest]

Specifically, we are asking if the hints should be set according to the assumptions DGIndex makes for the Info dialog when the stream does not specify colorimetry, or whether the hints should state that the colorimetry is unspecified. The latter is done now. I wanted to get the opinion of the ColorMatrix users before making any change to the hints.

[Wilbert]

Specifically, we are asking if the hints should be set according to the assumptions DGIndex makes for the Info dialog when the stream does not specify colorimetry, or whether the hints should state that the colorimetry is unspecified. The latter is done now.
I prefer the former :) Because it's good and otherwise users can't use hints in an automatic way.

[Guest]

And so it shall be.

[IanB]

Consider :- If the stream does not specify the colorimetry then Mpeg2Source should NOT set the hints to pretend that it does.

If Mpeg2Source makes a guess and presents it as fact then filters like ColorMatrix cannot be programmed to handle the no colorimetry case, i.e. a default behaviour or a user specified default.

I think the gist of the above thoughts is ColorMatrix is not handling the no colorimetry case as they would like. If that is the case then ColorMatrix should be changed not Mpeg2Source.

If you really must do it this way then at least set an extra bit to say the colorimetry value is "Guessed" so future filters can better handle the decision process.

[~bT~]

does anybody have a working link pls for v2.3?

[buzzqw]

http://www.64k.it/andres/data/avisynth/ColorMatrixv23.zip

BHH

[~bT~]

^ :thanks:

[foxyshadis]

Consider :- If the stream does not specify the colorimetry then Mpeg2Source should NOT set the hints to pretend that it does.

If Mpeg2Source makes a guess and presents it as fact then filters like ColorMatrix cannot be programmed to handle the no colorimetry case, i.e. a default behaviour or a user specified default.

I think the gist of the above thoughts is ColorMatrix is not handling the no colorimetry case as they would like. If that is the case then ColorMatrix should be changed not Mpeg2Source.

If you really must do it this way then at least set an extra bit to say the colorimetry value is "Guessed" so future filters can better handle the decision process.

I'm not sure. If no colorimetry is present, you're pretty hosed, there's no way to find a colormatrix automatically. The spec defaults are the only rational choice unless you've somehow obtained inside information on the real flags, in which case a manual override is needed in the script anyway. So it makes no difference either way except to people stuck with an older dgindex; for that case maybe colormatrix should be updated with the same code.

[canuckerfan]

if an intermediate lossless encoder was used (let's say lagarith) before Xvid or CCE would this produce unexpected results?

[foxyshadis]

Only if you perform a color conversion during lossless encoding. Keep it in YV12 through the whole chain and it'll be just fine.

[kandrey89]

I just started using ColorMatrix and having RTFM I'm still confused in how to apply it to my video.

Video is MPEG 2 Stream from DVD, in d2v format after being Film Forced to get rid of interlaced frames.
Color is indicated as SMPTE 170M(same as 601).
I intend to downsize and encode with XviD.

I'm looking at samples of 601, 709, in both PC and REC(regular-TV?), all are different, the faces in some are more yellow and some are more dimmer/brighter.
Questions:
1. Is SMPTE 170M = Rec.601? or PC.601?
2. If my video is Rec.601, do I need to use colormatrix at all since manual says 601 is for XviD encodes.
3. Which format should I choose, PC (brighter), or Rec (dimmer)? (PC looks really nice on screen, but Rec is more of a standard? and used for TVs?)
4. What color space should I set the video to if I want the video to look good both on PC and on TV, is that possible?
5. Do I need to ConvertToRGB if I want to encode into XviD? (saw this earlier in this thread, got me all confused)

Note: Just realized that ColorMatrix doesn't convert to PC.xxx, it's the ConvertToRGB that does it.

[kandrey89]

Help anyone?

[Ranguvar]

Question: I'm importing a (mostly) telecined DVD through DGIndex. I think I heard that ColorMatrix needs to run even before the IVTC, so should I set interlaced=true? Or not, since it's only telecined?

I would rather not Force Film.

[~bT~]

^ yes, unless u applied force film.

[45tripp]

@kandrey89

2.no
5.no

[pitch.fr]

hi

thank you for this awesome script!

was wondering if you could possibly add "REC-601 EBU" and "REC-601 SMPTE-C" colorspaces ?

I've given real world examples here, where it would very useful :
http://forum.doom9.org/showthread.php?p=1157662#post1157662

TIA,

[yup]

Hi all!

Simple question:
my source analog capture encoded huffyuv, my MPEG-2 encoder is CCE, can I use
ColorMatrix(mode="Rec.601->Rec.709")
in my script, and if yes where, after loading video file or at last string. In CCE setting I use Luminance level 16-235.

With kind regards yup.

[helms]

After reading this http://forum.doom9.org/showthread.php?t=133982#post1090068 I'm still unsure whether I'm correct in using

ColorMatrix(mode="Rec.709->Rec.601", hints=true, interlaced=true)

when downscaling HD (interlaced) to SD resolutions and encoding h264 video.

Is what I'm doing correct?

[Alex_ander]

Simple question:
my source analog capture encoded huffyuv, my MPEG-2 encoder is CCE, can I use
ColorMatrix(mode="Rec.601->Rec.709")
in my script, and if yes where, after loading video file or at last string. In CCE setting I use Luminance level 16-235.


A simple answer would be: if your capture source is in SD format, then you don't need ColorMatrix(); in case you go from HD to SD, you need conversion in the 709 -> 601 direction. Then it's better to use ColorMatrix() in place where the video is progressive or field-separated (if anywhere), or with 'interlaced=true' setting somewhere in the beginning of the script.
CCE is neutral to matrix type (like other encoders, doesn't change it or 'expect something special' as was considered earlier) and is also known to not write matrix type to file header (that is the possible reason why some software players may show input/output difference using their defaults).
That's my conclusion after reading the long discussion here and in similar threads, earlier I used to apply 601 -> 709 conversion with CCE in most cases.

[Alex_ander]

After reading this http://forum.doom9.org/showthread.php?t=133982#post1090068 I'm still unsure whether I'm correct in using

ColorMatrix(mode="Rec.709->Rec.601", hints=true, interlaced=true)

when downscaling HD (interlaced) to SD resolutions and encoding h264 video.

Is what I'm doing correct?

I suspect h264 uses 709 matrix for any resolution, then you probably don't need ColorMatrix in this case.