Apologies for not watching the full video before asking- but is the chroma shift unrelated to the minor chroma bug that older versions of GCVideo had?Konsolkongen wrote:I agree. His video is great
Unfortunately the chroma shift on the Wii games is still there, and still looks really bad. But I didn’t expect this mod to be able to fix this anyway. Still a huge improvement for sure
WiiDual / GCVideo discussion
-
bobrocks95
- Posts: 3472
- Joined: Mon Apr 30, 2012 2:27 am
- Location: Kentucky
Re: WiiDual / GCVideo discussion
PS1 Disc-Based Game ID BIOS patch for MemCard Pro and SD2PSX automatic VMC switching.
Re: WiiDual / GCVideo discussion
as discussed with Bob and Dan already, the problem is that the chroma shift is actually MORE obvious than it is on the stock output. This might be related to the chroma upsampling is handled, but the result is quite obvious. In the videos you can see green outlines on the yellow question mark boxes in mario. And you can see a lot of chroma problems around Mario's hat.
Also here's a comparion between the WiiDual and the stock output (left half is the WiiDual, right half is stock) - heavily enlarged of course, but you get the idea.
This said, of course this should just be a software problem. After all tapping the signal digitally shouldn't bear worse results than the analogue stock output.
Also here's a comparion between the WiiDual and the stock output (left half is the WiiDual, right half is stock) - heavily enlarged of course, but you get the idea.
This said, of course this should just be a software problem. After all tapping the signal digitally shouldn't bear worse results than the analogue stock output.
Re: WiiDual / GCVideo discussion
Bob used OBS for recording, but OBS' video capture defaults to the NV12 format with the Datapath VisionRGB.
So the conversion path went something like this:
RGB > YCbCr 4:2:2 (co-sited) > RGB > YCbCr 4:2:0 (centered) > RGB > YCbCr 4:2:0 (centered, interpreted as co-sited) > RGB > YCbCr 4:2:0 (co-sited, interpreted as centered?) > RGB
So the conversion path went something like this:
RGB > YCbCr 4:2:2 (co-sited) > RGB > YCbCr 4:2:0 (centered) > RGB > YCbCr 4:2:0 (centered, interpreted as co-sited) > RGB > YCbCr 4:2:0 (co-sited, interpreted as centered?) > RGB
Re: WiiDual / GCVideo discussion
But Dan did the same capture straight 4:4:4 into his capture card and the chroma shift is identically present on that very shot - the color balance was just massively better than on Bob's snapshots.
Re: WiiDual / GCVideo discussion
This is from Dan's snapshot:
Re: WiiDual / GCVideo discussion
This is what Bob showed me out of the Vision window.
Looks fine to me.
Looks fine to me.
Re: WiiDual / GCVideo discussion
No, it shows the exact same problem. Here's a close up. You can basically see that on the stock Wii the 4:2:2 chroma is interpolated to the right side, while the chroma interpolation is centered on the WiiDUAL (it's basically a shifted one pixel to the left compared to the stock output). You can see the green outline on the right edge of the yellow color bar, where the same bar on the stock output is cleaner (disregard Bob's shitty capture quality).
Please understand, I'm not argueing for and against anything here. It's a mere observation and having seen dozens of video processors doing good and bad chroma interpolation over the past 15 years, the chroma problems present right here are just quite obvious.
Please understand, I'm not argueing for and against anything here. It's a mere observation and having seen dozens of video processors doing good and bad chroma interpolation over the past 15 years, the chroma problems present right here are just quite obvious.
Re: WiiDual / GCVideo discussion
I won't call you crazy as I thought the same thing before, until I did my GCVideo simulations.
Re: WiiDual / GCVideo discussion
Here are my preliminary results with direct analog capture of a RVL-CPU-01 in SD and ED using the Datapath VisionRGB-E1.
It's almost as good as the GameCube in SD.
It's almost as good as the GameCube in SD.
-
andykara2003
- Posts: 1338
- Joined: Sat Apr 27, 2013 3:26 pm
Re: WiiDual / GCVideo discussion
Is this something that could be sorted by a firmware update?
Re: WiiDual / GCVideo discussion
While I definitely believe you, I can’t find where (in the review video) they state this or come to this conclusion. And even if it was stated there, doesn’t all this controversy over capture & upscaling methods nullify that conclusion anyway?Fudoh wrote:as discussed with Bob and Dan already, the problem is that the chroma shift is actually MORE obvious than it is on the stock output.
To clarify, you mean it’s a GCvideo software-correctable problem, right?Fudoh wrote: This said, of course this should just be a software problem. After all tapping the signal digitally shouldn't bear worse results than the analogue stock output.
The 240p Test Suite’s color bleed test is the obvious thing people should be screen capturing for comparisons, not 3D graphics (like the Mario title screen) or potentially prerended, antialiased text (like the above Wii remote instructions text).
Last edited by awe444 on Sat Oct 13, 2018 9:56 am, edited 1 time in total.
Re: WiiDual / GCVideo discussion
this was all after the review video had been put online. I don't yet own a WiiDual modded unit.I can’t find where (in the review video) they state this or come to this conclusion
-
Konsolkongen
- Posts: 2315
- Joined: Fri May 16, 2008 8:28 pm
- Location: Denmark
Re: WiiDual / GCVideo discussion
Would it be possible to add user adjustable red and blue shift in the Wii Dual firmware?
Back when I used the Lumagen VisionPro HDP I could control the position of both colors separately, and I noticed that the correct position varied on a game by game basis. What looked correct in one game would look totally wrong in another.
This is the single worst thing about the Wii's output in my opinion. It looks terrible, and if it could be fixed, or at least improved that would be awesome. Not to belittle the results of the Wii Dual at all, the added sharpness obviously is a huge improvement over a stock output
Back when I used the Lumagen VisionPro HDP I could control the position of both colors separately, and I noticed that the correct position varied on a game by game basis. What looked correct in one game would look totally wrong in another.
This is the single worst thing about the Wii's output in my opinion. It looks terrible, and if it could be fixed, or at least improved that would be awesome. Not to belittle the results of the Wii Dual at all, the added sharpness obviously is a huge improvement over a stock output
Re: WiiDual / GCVideo discussion
yes, but then again - as you can see - it doesn't neccessarily look that bad on a test pattern, while it can be really annoying when you can see it all the time throughout a game.The 240p Test Suite’s color bleed test is the obvious thing people should be screen capturing for comparisons, not 3D graphics (like the Mario title screen) or potentially prerended, antialiased text (like the above Wii remote instructions text).
@Extrems:
exactly. Same result as Bob's capture told us already. So, in essence - this is the same we've been seeing on the CGVideo recently, right ? The Chroma interpolation algorithm simply differs between the original stock output and the mod, right ? I didn't follow the CGVideo discussion close enough to recall what had been changed in the end (with the recent FW update), but this was adressing the issue, right ?
Re: WiiDual / GCVideo discussion
The stock output doesn't have interpolation. The issue with GCVideo was a different one.
Re: WiiDual / GCVideo discussion
GCVideo 2.4b fixed Cb being ahead of the rest. Unseen said he would make chroma interpolation optional in 2.5 which should make it look the same as stock.
Re: WiiDual / GCVideo discussion
Ideally we'd have native YCbCr 4:2:2 over HDMI for true lossless video, but alas...
Maybe the conversion matrix settings could be misused to that gain in my setup.
Maybe the conversion matrix settings could be misused to that gain in my setup.
-
- Posts: 208
- Joined: Thu Sep 27, 2018 1:04 am
Re: WiiDual / GCVideo discussion
Thing being, sending YCbCr 4:2:2 is an official part of the HDMI specification, so any technical reason why the GCVideo doesn't do this?Extrems wrote:Ideally we'd have native YCbCr 4:2:2 over HDMI for true lossless video, but alas...
Maybe the conversion matrix settings could be misused to that gain in my setup.
https://en.wikipedia.org/wiki/HDMI
Re: WiiDual / GCVideo discussion
But then you depend on the receiving device doing the YCbCr to RGB conversion which could cause even more issues.
Re: WiiDual / GCVideo discussion
Unseen insists on reading the EDID to know that it is supported, and it would complicate the on-screen display.energizerfellow wrote:Thing being, sending YCbCr 4:2:2 is an official part of the HDMI specification, so any technical reason why the GCVideo doesn't do this?
Re: WiiDual / GCVideo discussion
Two main reasons actually:energizerfellow wrote:Thing being, sending YCbCr 4:2:2 is an official part of the HDMI specification, so any technical reason why the GCVideo doesn't do this?
- Anything except 8 bit RGB is an optional part of the spec, not every device supports it. If you use it on a device that does not support it, you will probably get a messed up image with just red and green
- The scanliner and OSD assume that they can manipulate individual pixels which isn't true for 4:2:2. For the OSD this can probably be workedd around because the font is pixel-doubled horizontally anyway, but the scanliner can select the scanline strength based on Y and must apply that strength to both Y and the color components to avoid color shifts.
Per-channel (input or output?) horizontal shifts would obviously be nice, but I believe variable-tap shift registers are expensive on this FPGA and the synthesis tool claims that in my "2.5 WIP" branch 99% of the slices of the FPGA are in use.
(huh, for some reason I thought 4:2:2 on HDMI would pack the four high-order bits of Y and C into TMDS channel 0, but it actually stuffs the low-order bits there... that simplifies things, maybe it still is featible as a "if anything breaks after turning on, you're on your own" option because I don't have enough space for an EDID parser anymore)
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: WiiDual / GCVideo discussion
Hasn't the chroma thing been fixed in the latest version 2.4b? Citrus even uploaded a video that shows you how to update the dual unit:
https://www.youtube.com/watch?v=RSG9kC6o0G0
Anyway here are zoomed up shots from my setup with HDMI (I don't have GCVideo 2.4b):
Here's a comparison of Xenoblade Chronicles Title Screen running on my setup (WiiDual 480p HDMI Upscaled to 1080p):
And here is the same Title Screen running on Dolphin Emulator with HD Packs (spoilers, it's never gonna look like that real hardware):
https://www.youtube.com/watch?v=RSG9kC6o0G0
Honestly if people didn't point out I wouldn't even know this was a thing, you literally have to take a shot of your TV and zoom up alot on specific colored word scheme to notice it. And from what I understand, the chroma issue does not affect YPbPr from what I remember reading from one of citrus' posts?Konsolkongen wrote:Unfortunately the chroma shift on the Wii games is still there, and still looks really bad.
Anyway here are zoomed up shots from my setup with HDMI (I don't have GCVideo 2.4b):
Here's a comparison of Xenoblade Chronicles Title Screen running on my setup (WiiDual 480p HDMI Upscaled to 1080p):
And here is the same Title Screen running on Dolphin Emulator with HD Packs (spoilers, it's never gonna look like that real hardware):
Re: WiiDual / GCVideo discussion
This is a different issue.Lawfer wrote:Hasn't the chroma thing been fixed in the latest version 2.4b?
Re: WiiDual / GCVideo discussion
But the chroma shift issue has been fixed, no? (which is what the post I was replying to mentioned).Extrems wrote:This is a different issue.Lawfer wrote:Hasn't the chroma thing been fixed in the latest version 2.4b?
Though there seem to be yet another chroma-related issue, an issue related to "chroma interpolation"?
Re: WiiDual / GCVideo discussion
This is a different chroma shift issue.
Re: WiiDual / GCVideo discussion
I see, so if you could explain please, how does the remaining chroma shift issue differ from the one that has been fixed in version 2.4b?Extrems wrote:This is a different chroma shift issue.
Re: WiiDual / GCVideo discussion
For doing comparisons “by eye”, I fully agree, in-game visuals are what really matter. Conversely, if a test pattern reveals flaws in the signal but the gameplay looks fine by eye, it shouldn’t matter.Fudoh wrote:yes, but then again - as you can see - it doesn't neccessarily look that bad on a test pattern, while it can be really annoying when you can see it all the time throughout a game.The 240p Test Suite’s color bleed test is the obvious thing people should be screen capturing for comparisons, not 3D graphics (like the Mario title screen) or potentially prerended, antialiased text (like the above Wii remote instructions text).
Color bleed test however can tell us objectively, in bit values, if we actually alternate between full black and full red/green/blue as the pattern is meant to be conveyed. The other nice thing is it ensures we’re not looking at post processing scaling effects since those would equally affect the white part of the pattern.
-
- Posts: 208
- Joined: Thu Sep 27, 2018 1:04 am
Re: WiiDual / GCVideo discussion
Would it also be possible to use HDMI's Auxiliary Video information (AVI) InfoFrame ancillary data to flag RGB vs YCbCr to enhance compatibility when reading the full EDID isn't possible? Only some ancient DVI PC monitors should have issues with this from what I'm finding.Unseen wrote:Two main reasons actually:energizerfellow wrote:Thing being, sending YCbCr 4:2:2 is an official part of the HDMI specification, so any technical reason why the GCVideo doesn't do this?My current plan is to build a test firmware that can capture and hexdump a single video line of the Cube/Wii raw digital data stream to allow actual analysis instead of just guessing based on processed output. I'm not sure if I can actually manage to implement that soon-ish because I first need to clean out some other things before I can even set up the development Cube again.
- Anything except 8 bit RGB is an optional part of the spec, not every device supports it. If you use it on a device that does not support it, you will probably get a messed up image with just red and green
- The scanliner and OSD assume that they can manipulate individual pixels which isn't true for 4:2:2. For the OSD this can probably be workedd around because the font is pixel-doubled horizontally anyway, but the scanliner can select the scanline strength based on Y and must apply that strength to both Y and the color components to avoid color shifts.
Per-channel (input or output?) horizontal shifts would obviously be nice, but I believe variable-tap shift registers are expensive on this FPGA and the synthesis tool claims that in my "2.5 WIP" branch 99% of the slices of the FPGA are in use.
(huh, for some reason I thought 4:2:2 on HDMI would pack the four high-order bits of Y and C into TMDS channel 0, but it actually stuffs the low-order bits there... that simplifies things, maybe it still is featible as a "if anything breaks after turning on, you're on your own" option because I don't have enough space for an EDID parser anymore)
Re: WiiDual / GCVideo discussion
When enhanced DVI mode in GCVideo is turned on, it already transmits infoframes that specify RGB color space, the appropriate quantization range according to the current settings and the selected aspect ratio. For any kind of YUV output that would obviously have to be switched(*) to an infoframe that specifies YUV instead.energizerfellow wrote:Would it also be possible to use HDMI's Auxiliary Video information (AVI) InfoFrame ancillary data to flag RGB vs YUV to enhance compatibility when reading the full EDID isn't possible? Only some ancient DVI displays should have issues with this from what I'm finding.
(*) It's just a ROM with a set of pre-generated infoframes covering all combinations because there used to be not that many...
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: WiiDual / GCVideo discussion
WiiDual-installation-video by citrus3000psi: https://www.youtube.com/watch?v=gNqjkZr9dYM