[solved] GSdx recordings are off-color
Pseudonym has fixed the problem. Latest SVN GSdx should do fine, now!


After taking a look at GSdx's source code and making a small change, I've gotten the plugin to correctly record --
so the colors come out as they should. woot! Biggrin

For anybody who wants the specifics...
In the file GSCapture.cpp, I switched the order of lines 81-92 and lines 94-105 (so the structures for RGB32 get pushed first). Works nicely for me.


I've been experimenting with recording from pcsx2... and it wasn't until I was looking at Final Fantasy X that I noticed that the colors in videos recorded from GSdx seem off-hue. Have a look.

First image: pcsx2/GSdx screencap using PrintScreen key (this is what the video frame should look like.)

Second image: frame from GSdx recording, grabbed with VirtualDub

Also, I've tried...
  • recording using ZeroGS -- the colors in ZeroGS's recordings actually look fine! (but I'd prefer to use GSdx right now.)
  • taking screencaps in GSdx (F8 key) -- the resulting BMP files look fine.
  • recording in Windows 7 (same machine/dual-boot) using the same settings in pcsx2 --- colors are still not right in GSdx recordings.
  • recording on another machine (a older laptop) -- still has the same color problem in GSdx recordings.
  • recording using another video codec besides 'Uncompressed', namely 'ffdshow' -- still has the color problem.
  • recording another game with GSdx... MGS3's opening cutscene -- has the color problem (though considering its color palette, it's kind of easy to overlook Biggrin )
  • recording using pcsx2 0.9.6 (with its respective version of GSdx) -- has the color problem.

my configuration...
PCSX2: latest public beta (
OS: Windows XP SP2
CPU: AMD Athlon 64 X2 5000
Graphics: PNY Verto GeForce 210
RAM: 2 gigs

... So, any ideas? Or can anyone else try seeing if you're also having this problem?

Attached Files Thumbnail(s)

Sponsored links

the second has colours like this cause of the settings you have put in the drivers for video colours (how strong to be or something like that) or in the program you use to play the file. give a look at that and try to disable any enchasements
OS: Win 7 Ultimate x64 sp1, MoBo: Asus P5QD Turbo, CPU: Q6600 @ 3,0Ghz, RAM: Trancend 2x2gb 6-6-6-18 800 MHz, GPU: HD 4850 1gb.
Pcsx2: Always Latest
i currently do not use the video/color enhancement features on my graphics cards (RGB gamma, PureVideo).
also, since that frame was exported straight out of of VirtualDub, i don't think the video driver would have any involvement in that process.
Yeah I've noticed this too. Hope someone would take a look at it and possibly fix it, although gabest is away and he is the one who knows the most about these functions of the plugin
[Image: newsig.jpg]
GSDx probably does its own RGB->YUV and doesn't do it to spec, but I'm not inclined to investigate.
(07-11-2010, 08:58 PM)pseudonym Wrote: GSDx probably does its own RGB->YUV and doesn't do it to spec, but I'm not inclined to investigate.

Indeed, the videos that come out of GSdx seem to be encoded using the YUY2 colorspace... whereas ZeroGS outputs its recordings in RGB32... Blink
Read the update on my first post at the top.
Er... does that make the colour space correct for all codecs?
(07-16-2010, 06:52 PM)pseudonym Wrote: Er... does that make the colour space correct for all codecs?

Not all codecs (like Huffyuv, which seems to prefer YUY2).

But for codecs that can take RGB, yes... they'll take it. (I've tried ffdshow and Lagarith. Both work fine.)

My assumption is that the order the structs are pushed determines the priority/preference of one colorspace over the other.....
Well using the codec's own RGB support probably is a good thing, but this is just a workaround. Changing the conversion to match the appropriate standard (finding out what that is is the hard part, the code is very simple) is still necessary.

That said, isn't directshow meant to do conversion of formats automagically? Maybe it's not being used correctly.

Users browsing this thread: 1 Guest(s)