View Full Version : Losing colors with xvid?
chilledinsanity
7th November 2006, 22:02
I just noticed that in some footage I've been working on, I'm seeing some minor color loss between the original uncompressed footage, and the final xvid clip. At first I thought it was because I was using fast compression in virtualdub, but it happens in full processing mode too. I hosted some screenshot comparisons, but you probably won't be able to tell the difference between them unless you look at them one after the other. Here's a link:
original snapshot (http://img464.imageshack.us/img464/1426/originalge4.png)
xvid snapshot (http://img170.imageshack.us/img170/8486/xvidrn9.png)
ColorMatrix version (http://img473.imageshack.us/img473/4498/colormatrixxz7.png)
Overall, the xvid version looks a little darker, and loses some of the reds that are present in the original shot (the brickwork off to the left is where I noticed the most difference). As for my Xvid settings, for this shot, I did a single-pass, no quantization settings checked, used chroma motion, Motion precision 6, VHQ mode off, and minimum I and P frame quantizers set to 1.
Is there some sort of setting I'm using that causes this, or is this an unavoidable aspect of xvid?
unskinnyboy
8th November 2006, 02:31
Search the forum for 'ColorMatrix'.
chilledinsanity
8th November 2006, 06:06
I looked into that, but I'm not sure this is what I need. I tried using it and it only gave me an error message, saying input to the filter had to be YUV. My source material is an uncompressed RGB AVI file which I captured, not MPEG-2 DVD material. Is this still the filter I need, or do I need something different?
plane
8th November 2006, 14:06
I looked into that, but I'm not sure this is what I need. I tried using it and it only gave me an error message, saying input to the filter had to be YUV. My source material is an uncompressed RGB AVI file which I captured, not MPEG-2 DVD material. Is this still the filter I need, or do I need something different?
You aren't alone, I got the same red color problem with xvid too(Kopei's previous old build and lastest build). With the same final output size at any bitrate, X264 and Divx6 seems don't have this issue.
My sources are all deinterlaced real-life contents in Huffyuv RGB format. I used MeGUI to encode X264 and VDMod to encode both Xvid/Divx.
chilledinsanity
8th November 2006, 17:29
Well damn, I'd hate to jump ship on Xvid over this. I've been using VirtualDubMod too in order to encode. Do you know if there are any builds of Xvid where this doesn't happen?
Terranigma
8th November 2006, 18:03
I looked into that, but I'm not sure this is what I need. I tried using it and it only gave me an error message, saying input to the filter had to be YUV.
converttoyv12()
Wilbert
8th November 2006, 22:53
As his source is uncompressed RGB AVI, using ColorMatrix won't correct anything. Sorry, i don't know what the problem is.
Didée
8th November 2006, 23:37
OMG! What an unacceptable result of Xvid this is - looks like two completely different videos! :D
a) See if "chroma optimizer" is enabled in the zone tab. If so, disable it. (Should only affect dark areas anyway, but you never know)
b) Try a recent 1.2 build of Xvid. Some time ago, there was a fix for Intra DC coefficients, which could have an effect on the colors, too. (IIRC the fix was aplied to 1.2 branch only, not to 1.1 ... not sure of that, though.)
c) Try ConvertToYV12().ColorMatrix(). Trying will not harm. (@Wilbert - sure it can not "correct" anything in this case, but perhaps it *looks* better) :)
Keep in mind that it's generally impossible to reproduce the colors of a (native) RGB source to 100% in YUV colorspace. The conversion RGB->YUV will always cause some slight changes in chroma data.
chilledinsanity
9th November 2006, 00:47
Well, the newer version of Xvid did the exact same thing. I tried ColorMatrix and it seems to have overcorrected the problem (editing original post to include shot). I then tried using just the ConvertToYV12 then ran the Xvid copy through virtualdub using Full processing mode. While it's still a little off (just a touch darker mainly), the color quality is really damn close, so that should work as a solution. Thanks for the help.
Blue_MiSfit
9th November 2006, 14:45
If you add ConvertToYV12() to your script, then enable 'fast recompress' in virtualdub - otherwise you get converted to RGB and back to YV12 AGAIN. Yuck.
The difference you are seeing is likely the unavoidable side effect of a color space conversion. You loose a lot of chroma data with YV12 (4:2:0) vs "4:4:4" RGB (not really an accurate comparison, but it illustrates the idea).
CruNcher
11th November 2006, 02:20
hmm just useing yv12->rgb32 high quality (especialy for smoother red lines) in the decoder (ffdshow) and adjusting gama values to PC Scale (when rendering on VMR9) should also give a similiar result without jumping @ encoding in the colorspaces as Blue_Misfit correctly detected as being not good @ all, but still this is lossy compression so what is gone is definetly gone and won't ever come back 100% like it was before and YV12 means you sacrifice color information, if you don't want todo that you could use a lossy codec that works in RGB32 like for example Loco (in lossy mode) or some Intermidiate Codec like Canopus HQ this would be better suited if you wan't to represent the color information correctly as how it was in the source (on Computer Displays).
vBulletin® v3.8.11, Copyright ©2000-2018, vBulletin Solutions Inc.