Broadcast video still too bright using Colormatrix?

[snowden]

I've been using avisynth to compress videos (recorded from an aerial broadcast via Win-TV) using the following script (this is a template for all videos I want to compress):

LoadPlugin("S:\VIDEO_EDIT\COMPRESSION_PACK\dgmpgdec-148\DGDecode.dll")
LoadPlugin("S:\VIDEO_EDIT\COMPRESSION_PACK\filters\decomb.dll")
LoadPlugin("S:\VIDEO_EDIT\COMPRESSION_PACK\filters\UnDot.dll")
LoadPlugin("S:\VIDEO_EDIT\COMPRESSION_PACK\filters\ColorMatrix.dll")
mpeg2source("__vid__")
FieldDeinterlace()
crop(14,42,692,486)
LanczosResize(656,432)
ColorMatrix("Rec.709->Rec.601",true)
Undot()

, but it doesn't seem to matter where I put ColorMatrix; the video always seems hardly any darker when I use colormatrix, and the video, when compressed, seems too bright, like somebody turned up the brightness. I still don't understand where and when I should place the ColorMatrix() command (within the script), or what the different functions mean (as in hints=false and so on).

My main question is shoud I be using Colormatrix as above, or do I even need some of the other filters above (like Undot() ), and are they in the right order? :(

[Video Dude]

Put ColorMatrix directly after mpeg2source. Set the interlaced flag if needed. But you might have an entirely different problem that ColorMatrix is not intended to solve. What is the format you are encoding to (XviD, MPEG-2) and what program are you using to encode?

You could get much better results if you replaced FieldDeinterlace with TDeint or Yadif.

[snowden]

I knew i'd forget something.

I'm compressing to XviD (using the latest binary release) using VirtualDub 1.17 or VirtualDubMod b2542.

About deinterlacing - I didn't seem to have much look with other Deinterlacers like TomsMoComp and so on. But I will try those you mentioned, thanx. Also, I just downloaded DGIndex 1.4.9 final, so I'm looking forward to trying it. :)

Perhaps you are right about the problem I am having; maybe i don't even need colormatrix - perhaps I am supposed to be just using Levels() or something? :|

[IanB]

ColorMatrix doesn't change the brightness very much and then really only in the predominantly blue areas. The greyscale parts of the image are not changed at all.

Check the brightness control of your decoder/player first. Compare other peoples encodes to yours. Make sure that your encode is truely overbright before you correct it with Levels or other.

Use Histogram to check the distribution of Luma values.

[R3Z]

ColorMatrix doesn't change the brightness very much and then really only in the predominantly blue areas. The greyscale parts of the image are not changed at all.

Check the brightness control of your decoder/player first. Compare other peoples encodes to yours. Make sure that your encode is truely overbright before you correct it with Levels or other.

Use Histogram to check the distribution of Luma values.

Calibrate your monitor too !

[snowden]

I can't check other peoples encodes, because it is from an analog broadcast source - and I'm the only one who taped it.

I have the latest nVidia drivers installed. The monitor is lcd, so there should be no problem with it - it adjusts itself nicely. And I even used auto adjust on it, so there is no problem with it.

I don't know much about Luma values - what should I be looking out for? The Xvid decoder has a brightness control, but I don't think I'm going to like decreasing it - I shouldn't have to do that anyway...

Btw, when I play the uncompressed MPEG-2 file in Media Player Classic, there is a TV->PC levels changer in the filters options. This seems to darken the video nicely. It also makes the ugly sheen disappear that appears to show around the whole of the 4:3 image, even though the broadcast is 14:9 (think this is about the AR of the active image).

Finally, in DGIndex, there is the option for changing colorimetry for TV or PC. I always have PC selected. I always think that if I have PC selected, it means that the output will be suitable for compression on a PC. But the output colorimetry of this says ITU...701. Am I doing this incorrectly? Should I have selected TV to reflect what the source signal is, or am I supposed to select it for what the destination format should be?

Thanx for the help so far... :)

[foxyshadis]

That's an output conversion problem, and various driver sets from all the major graphics developers have that problem. One way to fix it is to force HQ RGB output from ffdshow, or you can use its levels() filter to achieve the same in YUV.

If you add a converttorgb() at the end of the script, you should see it looking normal when you load it into an editor. (Though most, like virtualdub, should do it this way anyway.) You can encode with ColorYUV(levels="TV->PC") to force the behavior without needing to tweak the output, but since it's actually a driver/decoder issue, any change in the playback chain can cause overdark/overbright problems.

[DarkT]

I always use Tweak to handle colors /brightness/darkness... Dunno if this applies to your case though - but just htough to mention it since I haven't seen anyone else mention it...

"and the video, when compressed, seems too bright,"

Also, before compression, when you check things by frame - atleast when I did, the "overlay" doesn' get applied to the picture, but when you play a movie, the overlay gets applied... So you might have a tweaked "overlay" setting which you need to reset...

[snowden]

I'm actually using the overlay mixer in Media Player Classic.

I did have a look at Tweak() but I can't tell the corresponding values to convert from TV->PC contrast and brightness. In fact, the Levels() help page in the avisynth docs mentions this might be better to use. Also, Tweak seems to be the only function that supports YV12 -I don't want to go backwards with color conversions. I don't think ColorYUV() would support YV12, would it?

foxyshadis, you say to use converttorgb() at the end, but as I just learned, using fast compression mode in virtualdub was meant to be the way to compress. I have been using full processing mode in VD forever, and never knew it output the video in rgb. what a waste! (As it defeats the purpose of encoding to YV12 which avisynth outputs anyway.)
Funny thing is, the video always seemed too 'bright' after encoding the video this way also...

Now that you mention it, I have seen a strange thing happen with the overlay on MPC. Every now and then, when I click on something else on the dekstop while mpc is playing a movie, the video changes into a solid bluey color. The only way to fix this is to pause the movie and then continue, or reopen the movie. So I think (and hope!) that this brightness issue is caused by the nvidia driver (v93.71). In case anyone is wondering, I have an nVidia Geforce 7300LE. :)

[foxyshadis]

converttorgb was just for testing, to see if it'd come out right. And ColorYUV does support YV12.

It'll still look too bright when you encode from rgb like that, because when vdub converts back to yuv for the codec it'll end up feeding the encoder essentially the same thing you were before. It always uses luma range reduction. The flip side is that when you do the range expansion in yuv, the preview in vdub will now look incorrect. (Unless you use Converttorgb(matrix="pc.709").)

Some people have said that 90-series nvidia drivers have a registry key you can set to determine their luma range properties, so you don't have to change the encoding, but as I don't have one I don't remember what it is.

[snowden]

ColorYUV(levels="TV->PC") seems to be working very nicely when I play it thru MPC.
Does it matter where I place ColorYUV(levels="TV->PC") in the avisynth script? Will putting it at the end of the script have any detrimental effects on other filters (such as Fluxsmooth etc)?

[foxyshadis]

Not as long as your thresholds are over 1 or 2. In fact, by adding it early, you can slightly reduce the inevitable banding.