ColorMatrix v2.3

[charleski]

I only came across this yesterday after looking at the output of AutoGK and it gave me a bit of a shock.

I have a question, though. What about encodes from PAL DVB material? After scratching around a bit on the web, I get the feeling that these should already be using 601 coefficients. Is that right?

[Didée]

Probably not - check the colorimetry info. For most of the material I capture from DVB-S, DGindex is reporting BT.709 ...

/*hands over smelling salts*

[charleski]

Ah yes, you're right. d2V's made from remuxed mpegs were coming up as Colorimetry: Unspecified Video (2) in DGDecode, but I looked at an original capture and it's 709.

Aargh!

[Wilbert]

New version, v1.10. See first post for download and changelog.

[actionman133]

Hey, I have a question about the use of ColorMatrix. It seems like a simple one, but having searched through about 75% of this thread (and the others that link here too, it's all too big to read everything), I still don't have an answer.

I have a DVD source that DGDecode reveals to be stored using SMPTE 170M (6 in the d2v file). According to your table about the various colorimetrics, it's the same as ITU-R BT.601 (which I assume is the technical name for Rec.601).

My question is, do I need to run ColorMatrix on this clip (or for any clip where the original coefficients are the same as rec.601)? Logic says no, but I did a Subtract (Original.ColorMatrix (d2v = "blah.d2v", mmx = false), Original) and there are some discrepencies. Granted they are minor but I am video purist, and if ColorMatrix is throwing it off a little, I'd rather save the CPU cycles for better playback. :cool:

Thanks, and apologies if this has been answered before. Perhaps a FAQ is in order where ALL the information is. :)

[Wilbert]

Depends on your end format. But if you are encoding to DivX/XviD you don't need to run Colormatrix in your case.

Try the following script to spot any difference:

Original = Mpeg2Source(...).Limiter()
Subtract(Original.ColorMatrix (d2v = "blah.d2v", mmx = false), Original)

Your dvd can have luma values outside [16,235], which will be clipped by ColorMatrix. That's one of the differences you should see in your original script.

If you still see a difference, please upload a small part (20 frames) of that vob.

[actionman133]

Yes, it was for DivX at the end. And Limiter removed those little errors, so the difference was just your filter's clamping. So it's all good.

Thanks Wilbert. :)

[tritical]

I've made a test version of colormatrix that is able to do all colorimetry type conversions (not just BT.709->BT.601 and BT.601->BT.709) with exact coefficients. It also has 3 options for value capping and coefficient scaling:

0.) cap input/output to [16,235(240)] range, and scale conversion coefficients (219/255,224/255)
1.) cap input/output to [0,255] range, and scale coefficients to (219/255, 224/255)
2.) cap input/output to [0,255] range, and don't scale coefficients (255/255)

The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont :).

[colinb]

I'll shortly be using HC to encode some DV (camcorder) footage. I'll be feeding the DV AVI file to HC via an avisynth script.

Do I need to use colormatrix() in my avisynth script?

It's PAL DV if that is significant.

[TheBashar]

Just a quick note. I saw in the docs that you (Wilbert) had never come across a mixed colorimetry source. I've been transferring some of my TV DVD collections to x264 and I've found some of the season 1 SG-1 DVDs have mixed colorimetry. Thanks for the hints option!

[colinb]

I'll shortly be using HC to encode some DV (camcorder) footage. I'll be feeding the DV AVI file to HC via an avisynth script.

Do I need to use colormatrix() in my avisynth script?

It's PAL DV if that is significant.

Well, I tried loading both the original DV AVI file and HC encoded m2v files into VirtualDub side by side and they appeared identical - this was without a call to colormatrix.

This surprised me because after a bit of searching I found that DV is supposed to be Rec.601 while HC expects its input to be Rec.709, so I would have thought that a conversion rec601->rec709 would be required before feeding HC.

So I then tried passing the original DV AVI file through a colormatrix 601 to 709 conversion and displayed this in VirtualDub alongside the original DV file (without colormatrix conversion). They looked almost identical too. Neither looked darker than the other. I did notice that on frames with intense red/orange these areas seemed slight darker or perhaps just more saturated on the 601->709 converted footage. This was the first time I have tried colormatrix and I was expecting to see a slightly more noticeable difference.

Anyway it looks like for PAL DV at least I don't need to use colormatrix - but I'm not sure why.

[Wilbert]

Just a quick note. I saw in the docs that you (Wilbert) had never come across a mixed colorimetry source. I've been transferring some of my TV DVD collections to x264 and I've found some of the season 1 SG-1 DVDs have mixed colorimetry. Thanks for the hints option!
Great! Could you upload a small vob which has this mixed colorimetry info?

This surprised me because after a bit of searching I found that DV is supposed to be Rec.601 while HC expects its input to be Rec.709, so I would have thought that a conversion rec601->rec709 would be required before feeding HC.
Sounds right (and yes, the difference is small). Could you upload a small part of that dv (10 frames)?

[EpheMeroN]

I have HD content that I am encoding to DVD using CCE 2.70, and was looking into using ColorMatrix on my sources.

DGIndex reports back a Colorimetry = ITU-R BT. 701 (1)

CCE also, by default, assumes ITU-R BT. 701 (1) coefficients correct? So, is there any reason to still use ColorMatrix? Or do I have it all wrong?

[Wilbert]

CCE also, by default, assumes ITU-R BT. 701 (1) coefficients correct? So, is there any reason to still use ColorMatrix? Or do I have it all wrong?
No, you are correct.

[actionman133]

I've made a test version of colormatrix that is able to do all colorimetry type conversions (not just BT.709->BT.601 and BT.601->BT.709) with exact coefficients. It also has 3 options for value capping and coefficient scaling:

0.) cap input/output to [16,235(240)] range, and scale conversion coefficients (219/255,224/255)
1.) cap input/output to [0,255] range, and scale coefficients to (219/255, 224/255)
2.) cap input/output to [0,255] range, and don't scale coefficients (255/255)

The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont :).

If you created a more comprehensive and precise filter (not to say Wilbert did a bad job, it's a great filter!), I would definitely use it. I am a precision control freak, so those extra options would be much appreciated. :D

[EpheMeroN]

No, you are correct.
Good to know!

...but do you know if HD broadcasts use a range of 0-255 or 16-235?

[jsquare]

I have an old Samurai movie in B/W, when encoded with Xvid it looks a bit too bright and washed out, DGIndex is reporting the colorimetry as "ITU-R BT.470-2" and the frame type seems hybrid(it changes from Interlace to Progressive constantly). By adding ColorMatrix() to the script my encode looks acceptable, but I have a couple of questions:

Is the default command ColorMatrix() all I need or should I include some other settings?

Should I add ColorMatrix() to all my future encodes?

[Boulder]

Does ColorMatrix even affect BW stuff?

[jsquare]

Does ColorMatrix even affect BW stuff?
Probably not, but it seems to "clamp" Luma/Chroma to CCIR-601 values as stated on the docs.

[Boulder]

That's a job for Limiter()..I'm sure using it is faster than using ColorMatrix with B/W stuff.

[Oline 61]

I don't quite understand this. If I have a DVD that uses BT.709 according to DGIndex, do I need to use Colormatrix? If so, what settings?

[Wilbert]

What is your final format? What is your encoder?

As an example: If you are encoding to mpeg-4 (which uses BT.601), you will need the conversion.

[Oline 61]

I am just going AVISynth to MeGUI/x264 CLI. Another thing I just noticed is that when I preview the VOB in DGIndex it says BT.709, but after it finishes creating a d2v project file it says SMPTE 170M. So what would be the proper settings for me to use?

[Wilbert]

I am just going AVISynth to MeGUI/x264 CLI. Another thing I just noticed is that when I preview the VOB in DGIndex it says BT.709, but after it finishes creating a d2v project file it says SMPTE 170M. So what would be the proper settings for me to use?
If true, this would be a bug in DGIndex (since SMPTE 170M = BT.601, and SMPTE 240M = BT.709). Could you check this with the latest DGIndex?

[Oline 61]

Using latest DGIndex version:
The first picture is the windows after completely saving the d2v project.
http://img467.imageshack.us/img467/5964/untitled20tb.jpg
The second picture is a screenshot while running a preview.
http://img382.imageshack.us/img382/9803/untitled8br.jpg

[Oline 61]

Is there a definitive way to tell which of these colorimetries is correct?
BTW, when I try to use ColorMatrix(d2v="VTS_01_1.d2v")
it tells me that multiple colorimetry types were detected in the d2v file.

[Wilbert]

BTW, when I try to use ColorMatrix(d2v="VTS_01_1.d2v")
it tells me that multiple colorimetry types were detected in the d2v file.
Yes, neuron2 hinted at this possibility. You need to find out, by scrolling through the video, when the colorimetry changes. I guess the main movie is BT.709, but after the credits some black frames are SMPTE 170M? Please confirm.

If that's indeed the case, i would apply ColorMatrix to the whole movie (it doesn't do anything when a frame is black, since it corrects chroma).

[Oline 61]

Looks like your right. If I play it starting near the end it changes to 170M right before reaching the end of the file. Thanks for helping, I will use ColorMatrix()

[Boulder]

Another option is to enable hints output in MPEG2Source and set ColorMatrix accordingly.

[15081947]

After going through this entire thread I am trying to tabularise the colormatrix usage for Divx/Xvid conversion.

Anything -> Divx/Xvid
------------------------
Source Colorimetry--------ColorMatrix
ITU-R BT.470-----------------No
ITU-R BT.601-----------------No
ITU-R BT.709-----------------Yes
SMPTE 170 M-----------------No
SMPTE 240 M-----------------Yes

Please feel free to correct it.

Thanks

[Wilbert]

Please feel free to correct it.
It's correct.

[Ginsonic]

Hi Wilbert and Tritical,

Thank You for Your great ColorMatrix-Plugin !

@Tritical:
The current version is always doing the equivalent of option 0. Would anyone be interested in this? If so I'll finish it up (mmx/sse2 conversions aren't finished), if not then I wont
I would be very interested in such a version, it would be great, if You could release it.

[EpheMeroN]

I have an XviD file that was converted from an HDTS .ts file, but ColorMatrix was not used in the script.

Will adding ColorMatrix back in a script to do XviD to DVD correct the colors?

[Wilbert]

Depends. What are the coefficients of your original transport stream?

[EpheMeroN]

Depends. What are the coefficients of your original transport stream?
ITU-R BT. 701 (1)

[Wilbert]

... ITU-R BT. 709 i presume :)

In that case you don't need to correct it (the errors cancel each other out), provided you feed YUV to the mpeg-2 encoder (CCE, QuEnc or HC).

[EpheMeroN]

... ITU-R BT. 709 i presume :)

In that case you don't need to correct it (the errors cancel each other out), provided you feed YUV to the mpeg-2 encoder (CCE, QuEnc or HC).
Is YUV YUY2/YV12 colorspaces?

...and yes, you presumed correctly. :)

[Wilbert]

Is YUV YUY2/YV12 colorspaces?
Yes, it is.

[FredThompson]

How about adding the option to set clamping to either the default of CCIR-601 or simple overflow protection?

[Boulder]

Wilbert,

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.

See this one for more info: http://forum.doom9.org/showthread.php?p=788356#post788356

[tritical]

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.
The hint information is stored in the least significant bit of each of the first 64 bytes of the image. For YV12 that means the first 64 luma pixels (Y plane). However, in YUY2 it would be the first 32 luma pixels + 16/16 U/V pixels since YUY2 is a packed format (YUYV). Therefore, doing a YV12->YUY2 or YUY2->YV12 colorspace conversion will make the hints unreadable in the new colorspace. This could be avoided if hints were always stored in the first 64 luma pixels (not just the first 64 pixels), but not sure if its really worth the trouble. Also, any operation that could modify the values of the first 64 pixels could destroy the hints... so resizing, denoising, color correction, trimming that removes the top line or pixels off the left, etc... should all be avoided. Though if you really need to do this there is a filter in TIVTC called MergeHints() that can maintain these types of hints across such filtering and color space conversions by transferring the hint information from a saved clip to a new clip.

I would be very interested in such a version, it would be great, if You could release it. I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.

[Wilbert]

there seems to be a problem when using hints and either resizing or doing a colorspace conversion, the hints are lost.
That's normal. It's the same story with Decimate and Telecide and why neuron2 advices you to place the two next to each other.

I don't know precisely how it works, so i hope tritical will reply. But hints are added at the start of the stream. Sometimes filters will destroy those hints and sometimes not. I recall tritical made once a filter for this purpose, which can store those hints and pass them to a filter which comes later in the filter chain. I can't find that filter though.

edit: too late :)

[Boulder]

OK, I'll have to refrain from resizing before ColorMatrix.

I've learnt two new things today, not bad ;)

[Wilbert]

tritical, can i ask something stupid :)
The hint information is stored in the least significant bit of each of the first 64 bytes of the image.
(1) what does least significant bit means (i mean why not the first bit)? (2) so there should be one pixel visible (if you don't use the hints) which is actually garbage?

[foxyshadis]

LSB also means least important and least noticeable, ie, changing it only changes the pixel value +-1, below the noise threshold of most videos, whereas changing the first, the most significant, means +-128. Little more noticeable. :p Since it only changes a few pixels' values by 0 or 1, it should never have a noticeable effect on filters or output.

[Wilbert]

LSB also means least important and least noticeable, ie, changing it only changes the pixel value +-1
How does ColorMatrix know which pixel is altered and by how much? I guess i need to read the code again tonight :)

[foxyshadis]

Hinting just overwrites whatever was in the last bit of the first 64 bytes (pixels) of the plane. Then filters read only those last bits, ignoring the rest. They don't really care what was there before, or whether it was modified.

[FredThompson]

Ah, come on, Wilbert, gimme a nod, ok? I can whine if it will help :P

[Ginsonic]

I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.
Thanks a lot Tritical !

[jackiehcs]

If I use "TMPsource" instead of "mpeg2source" by importing d2v to tmpgenc, is it correct to use "ColorMatrix(d2v="xxx.d2v")" to correct the color difference?