Posted: 3/13/2012 1:38 AM
Post subject: PSXjin: Color reproduction error?
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
FFIX has a number of situations where it seamlessly switches between a standard backdrop and a cutscene. This is such a situation; two adjacent frames, one backdrop, one cutscene, both pulled out of psxjin in lossless RGB and presented to you as lossless x264 RGB: http://www.mediafire.com/?m55c8mujfthk1tw The colors are not the same. I don't know much about psx emulation, but textures for the 3d engine can be stored in a variety of RGB formats, where as the FMVs are stored in some special mdec format that was decompressed in hardware, and are YUV based. It's possible that the devs of FFIX got it wrong, but it seems likely that they got it right: I would expect that the colors in these two frames should match. But they don't. This leads me to suspect the psxjin mdec decoder? For your viewing pleasure, also as PNGs: Edit: Apparently not the first time this sort of thing has been examined? http://smf.mameworld.info/?p=12
Posted: 3/13/2012 1:45 AM
Quote
Lex
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Yeah, that's a pretty major color difference that would be noticeable in an in-game switch between the still background and the FMV. It seems like just a mismatch in color conversion standard. Does that FMV format specify a color conversion standard to use? If so, is psxjin reading and interpreting that properly?
Posted: 3/13/2012 2:08 AM
(Edited: 3/14/2012 3:27 PM)
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I'm pretty sure this is what PSXjin actually does: Two different options (compile time) float or fixed, and two different output paths (run time) 15 or 24 bit (because the PSX backbuffer can be 15 bit or 24 bit) floating point: R1 = 1.40200 * Cr G1 = -.3437 * Cb -.7143 * Cr B1 = 1.77200 * Cb fixed point: R1 = 1.4013671875 * Cr G1 = -0.3427734375 * Cb -0.7138671875 * Cr B1 = 1.771484375 * Cb 15 bit: R = (clip(Y + R1 + 128))>>3 G = (clip(Y + G1 + 128))>>3 B = (clip(Y + B1 + 128))>>3 24 bit: R = clip(Y + R1 + 128) G = clip(Y + G1 + 128) B = clip(Y + B1 + 128) According to wikipedia, http://en.wikipedia.org/wiki/YUV this is neither rec601 nor rec709, but that in it self doesn't mean it's wrong. Disregard, that page is for limited range. The only goal of course is to produce exactly what the real MDEC hardware does; standards be damned. Edit: FFmpeg's MDEC decoder is here: http://ffmpeg.org/doxygen/trunk/mdec_8c-source.html It doesn't handle yuv->rgb internally, instead passing the YUV directly out of the decoder for swscale to handle. It marks PIX_FMT_YUVJ420P, which is labeling the YUV as compliant to the JFIF standard. Assuming all of that is correct, that would be full range rec601 ("PC.601" in avisynth lingo). The JFIF standard http://www.jpeg.org/public/jfif.pdf is exactly what psxjin does, but somehow that's wrong...
Posted: 3/13/2012 5:19 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I got out my ps2 and my FFIX cds and started the game while observing it on my TV (wish I still had the capture card setup...) There's an FMV->backdrop seamless transition very early in the game, right when you meet Vivi. It's about 5 minutes into the FFIX tas on the workbench, and doesn't take much longer to get there unassisted. When viewing it on real hardware, I saw no noticeable color shift at the transition point, but the psxjin dump has a shift there. (top: FMV, bottom: backdrop) (comparison video in lossless x264 rgb) http://www.mediafire.com/?ucfdc1pueca2u6a
Posted: 3/15/2012 3:33 AM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Well, here's a capture off my PS2, compared to psxjin. http://www.mediafire.com/?e1dbdcmsz38y33r [25MiB] I'm aware that this captured video has many... technical shortcomings. I was about ready to burst a few blood vessels just getting the capture to work at all. I think it's good enough to show the one thing that it needs to show: there is no colorshift when the FMV ends and texture backdrop begins. jpsxdec appears to use the same conversion coefficients that psxjin does, pc601, which doesn't look right. other things i've tried that don't look right include pc709 and an alternate matrix (labeled as "wrong") that's in the jpsxdec source code.
Posted: 3/15/2012 5:21 PM
Quote
zeromus
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
http://forum.fobby.net/index.php?t=msg&th=701 study the latest mednafen and perhaps attempt to discover its coefficients. this is the most cutting edge psx emulator right now, even if it isnt completely stable yet. you should also check out pcsx-reloaded. ill wager this kind of stuff is too detailed for anyone to care about in psxjin, which is a turd. if you can present a better table and vouch for it, then itd be easy to check in.
Posted: 3/15/2012 6:13 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I took a quick look at both mednafen and pcsx-reloaded. Both use slightly tweaked JFIF coefficients, not quite the same but not nearly the magnitude of difference we'd be looking for. I decided to capture output from pcsx-reloaded and... it looks like the coefficients are not the problem. The colors in pcsx-reloaded are rather different than the ones in psxjin, and the pcsx-reloaded colors look much closer to the originals. But, those coefficients are almost the same ones as psxjin uses! (And the miniscule difference between them is not big enough for this). So there must be some other mdec error causing incorrect colors, perhaps something in the IDCT? Whatever it is, it's out of my league, and I doubt anyone else will be interested in fixing it. Meh. Edit: Note that the slight decrease of redness going from FMV->backdrop (especially visable in the pcsx-reloaded capture at the top left corner) is also visible in my analog cap from a PS2. So I think pcsx-reloaded probably has it mostly or completely right.
Posted: 3/15/2012 9:58 PM
Quote
zeromus
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
i suspect psxjin is wholly wrong and archaic. it's almost entirely using lewpy's software renderer which was cutting edge circa year 2000. digging up bugs in it is like looking for a termite in an anthill. however you are still doing yourself a favor by digging in this deep, as the knowledge will assist mednafen and psxhawk (should it ever arrive); but youre not doing yourself a favor if youre wasting wishes for something of this magnitude to get revised in psxjin.
Posted: 3/16/2012 1:59 AM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
zeromus wrote:
but youre not doing yourself a favor if youre wasting wishes for something of this magnitude to get revised in psxjin.
No wishes have been wasted. Just wanted to figure out what went wrong, and if it was a quick fix, to fix it. For anyone who happens to read this in the future, here's the executive summary: PSXjin MDEC decoding is wrong. It's probably not a 2 minute fix. The best solution would be to start from scratch with one of the more thouroughly investigated MDEC decoders: MAME psx core, mednafen psx core, PCSX-reloaded. jPSXdec is also a good source of information (although it doesn't actually implement exactly what we're looking for here).