[feature request] fixing vwii video issues
Reual4412 opened this issue · 12 comments
What we know is that there seems to be a color space issue.
https://gbatemp.net/threads/fixing-vwii-mode.573265/post-9391136
(he says it's his display. But, I suspect that's the output from the cable, as it's even repeatable on my monitor. )
What the issue is specifically is the cable is giving a rec 709 over hdmi, on vwii mode, which is HD color space. Not the correct 609 color space, which is for SD. Which given that the wiiu (in wiiu mode) doesn't properly send RGB range in the first place. (yet somehow does in vwii) It's unlikely Nintendo properly implemented that in the first place.
The second issue, seems to be what's causing the color bleed.
https://gbatemp.net/threads/fixing-vwii-mode.573265/post-9512768
The OG wii does a RGB color space (internally) and then does a conversion to YcBCr, which according to the user, is 4:2:2.
Basically, Nintendo's DMCU? (I'm not sure if that's the exact cause, but considering that it's responsible for VI in vwii.)
instead of doing the correct 4:2:2 format. It's doing YCrCb 4:4:4. this creates the color bleed and other issues. (Or rather, making them far worse. as the original Wii already had light color bleed.)
Regardless if this is possible to fix or not. Thanks, honestly. It's already amazing to be finally done with the overcropping issue.
Thanks for mentioning this, I completely missed those posts while skimming over the "Fixing vWii Mode" thread.
Regarding the first issue:
Color Matrix Transformation is disabled in vWii mode, which might confirm the suspicion in the original thread:
On vWii I believe the issue is that the game is rendering SD 601 colours, but vWii is neglecting to convert them to HD 709 colours before outputting them as 709 colours over HDMI.
Not too sure about the second issue though, the pixel encoding format is set to YCbCr 4:2:2 while in vWii mode.
Not too sure about the second issue though, the pixel encoding format is set to YCbCr 4:2:2 while in vWii mode.
Interesting, unless the view port fix fixed the colorbleed issue. (that or it's just purely caused by that color space issue, or something else entirely. One step at a time I suppose)
Also awesome to hear I was able to help somewhat.
The chroma bleed issue is unfortunately not fixed by evwii for now (it would be amazing if it could be fixed). I have tested both Wind Waker (via Nintendont) and Skyward Sword at 1080p and 480p via HDMI as well as 480p via component while using evwii 0.2. The issue is most clearly visible in skyward sword when looking at the white outline/glow around the goddess statue in the intro - the glow on the right side of the statue is clearly non-white due to the bleeding. For Wind Waker I set evwii to 640x480 to try and reduce scaling artifacts, but bleed could still be seen on Link's right side during the playable intro segments. It honestly looks like a 1-2 pixel horizontal chroma/luma offset (though how that sort of bug is even possible I can't imagine). I can post uncompressed screen captures if that would be helpful.
For future reference here are comparison captures, both were taken with the following fixes applied to try and get as raw a framebuffer capture as possible:
- 480p fix
- Deflicker Filter disabled (extended)
- Video width: Framebuffer
All captures are fully uncompressed (rgb24) taken with a Magewell capture card and saved to a PNG with ffmpeg.
First capture is from the Wii and was captured unscaled with an OSSC connected with component cables using optimal timings.
Second capture is from the Wii U in vWii mode outputting 480p with evwii set to 720x480 and was captured directly via HDMI.
For dramatic effect here's the zoom in (scaled nearest neighbor):
Wii:
Wii U (evwii):
Hopefully this helps!
According to NoobletCheese, the chroma bug seems to be coming from the a misalingment of the CbCr channels, and that it could be solved by outputting RGB instead of YCbCr.
Could a toggle for RGB/YCbCr be added to evWii?
Original post: https://gbatemp.net/threads/fixing-vwii-mode.573265/post-9758960
I used Nintendont to force different video modes, and I can confirm this behavior:
Just a reminder, the chroma is usually slightly shifted to the left and it is yellowish.
- Running PAL games on PAL WiiU would not cause bleeding to the red
- Running NTSC games on PAL WiiU would cause bleeding with the red-shifted to the right
The red shift would stay in the HBC and SM, so there would be no more yellowish bleed.
(Shift to yellowish does reset after the reboot)
- The thing that I had a 100% chance to reset the red bleed is setting
TV Typeto60Hz (480i)and then changing back toEDTV/HDTV (480p)
Most of the time, only changing to60Hz (480i)would be enough to fix it.
When booting the game, staying at 50Hz is the goal:
- Forcing NTSC, MPAL, or 60Hz on PAL game also results in the red bleed
- Forcing the NTSC game in 50Hz mode would not cause the red bleed
BUT YOU MUST NOT USE Gamecube IPL, and @GaryOderNichts knows why.
The__VIInitreasons
I think I already said about this a bit on the linked threads when testing the evwii first version output, but the chroma shift seems to vary between a very ugly one and a fine-ish one according to how the software sets the video output and the VI (and if it reinitializes it or not too?). I imagine this is a bug in Nintendo's implementation on the Wii U as of course doesn't happen on GameCube and Wii.
If you output on 1:1 without crop and look carefully, when there's more chroma shift, the most horizontal pixels of the vWii output are green on each side. It also always crops one pixel on the game image right side when there's more chroma shift. There are some images that show that below (all with evwii for the Wii U).
Wii U (most chroma shift):
Wii U (less chroma shift):
Wii (2006 unit):
### 300% zoom
Wii U (most chroma shift):
Wii U (less chroma shift):
Wii (2006 unit):
I think this would require a rewrite of the DMCU firmware to fix. And I don't believe anyone knows in enough real great detail how the DMCU firmware works exactly to be able to rewrite it to fix all of this.
I think this would require a rewrite of the DMCU firmware to fix. And I don't believe anyone knows in enough real great detail how the DMCU firmware works exactly to be able to rewrite it to fix all of this.
I have the DMCU firmware mostly reverse engineered and partially reimplemented. Unfortunately that doesn't automatically help with fixing the chroma shift issues.
There's a lot more testing required to figure out what exactly causes it.
Hopefully this is something that can be solved in the near future, seeing as DMCU is mostly reverse engineered. Nintendo really dropped the ball with the Wii U.
Is latency also something that people have reproduced/tested? I've noticed it, although I haven't tested it, and its been reported as about 20ms, which is pretty high. I'm using a European Wii U, if that makes a difference.
If the chroma shift is fixed it would make the wii u almost perfect for most wii games. I would LOVE to see a fix for the issue in the future.