Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct size and YUV order for jpeg decoding #16179

Merged
merged 11 commits into from
Oct 9, 2022

Conversation

unknownbrackets
Copy link
Collaborator

@unknownbrackets unknownbrackets commented Oct 8, 2022

Fixes #9931, it turns out the stride is part of the sceJpegCreateMJpeg() function call, which should keep #9760 working (does for another play view.) See tests in hrydgard/pspautotests#229 which validate this functionality.

I think this may help #16157 as some logs indicated it uses sceJpeg (and sceJpeg was not logging read/write in the debugger.) It would make more sense than a download to VRAM using the wrong stride.

This also corrects the swizzle for sceJpegCsc, which I'm hoping will help #9457 as well.

Other changes:

  • Most of these functions should reschedule (I believe they run on the ME), and now do. Timing is rough.
  • Error codes are much better, although not perfect for invalid data.
  • Grayscale JPEGs now work consistently (before, they did not decode), although the PSP seems to fail to decode grayscale so maybe they shouldn't (note: incorrectly allowing grayscale decode currently causes test failures.)
  • Pointers are validated, fixing what would've previously crashed with bad parameters.
  • Debugger knows about reads and writes now.
  • Stride for colorspace conversion behaves more correctly (although sceJpegMJpegCsc has some weird behavior, causing test failures.)

Notably, the jpeg decoding and colorspace conversions are not bit accurate to the PSP, so the colors are still slightly off. Didn't really touch the RGBA/YCbCr conversion. Currently our JPEG decoder goes to RGB, and then we go back to YCbCr, which adds error.

There's some weird behavior with sceJpegMJpegCsc(), which is no less broken than before. Changing Cb or Cr values doesn't affect the pixels I'd expect, I think it might be upside-down and swizzled or something. sceJpegDecodeMJpegYCbCr() is probably using a similarly wrong order. Since they match, it shouldn't cause real problems, but it's not currently accurate.

-[Unknown]

Seems to be reused even after Delete, strangely.
This also fixes a crash on invalid output pointer.
Previously, it was assumed that the stride was the nearest power of two,
but it's actually the Create width.
For non-mjpeg, the height and width are halved, and more sampling modes
are supported.  This also checks for invalid pointers and notifies the
debugger.

The exact YCbCr->RGBA conversion is not accurate, but it writes in the
correct places now.  MJpeg is still a bit off.
@hrydgard
Copy link
Owner

hrydgard commented Oct 8, 2022

Very cool! I'll look through it tomorrow.

Verified this is what's output from a PSP's DecodeMJpegYCbCr, and games
directly use its output in MJpegCsc - so change to match.

This makes the colors in Gods Eater Burst character portraits look better.
@unknownbrackets
Copy link
Collaborator Author

I went ahead and changed MJpegCsc to match what I'm roughly getting. I get some garbage in my tests, but visually it has to be this way. My tests do show it uses different coefficients, though, so I kept the loop separate.

Slightly worried this may impact #8521, but I think it was just getting messed up colors before?

For me, this improves the character image (on save data) from Gods Eater Burst.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
HLE/Kernel Kernel, memory manager, other HLE issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sceJpeg uses wrong width/stride
2 participants