shmups.system11.org

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?

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.

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

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.

This is from Dan's snapshot:

This is what Bob showed me out of the Vision window.



Looks fine to me.

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.

I won't call you crazy as I thought the same thing before, until I did my GCVideo simulations.

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.

Is this something that could be sorted by a firmware update?

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?


To clarify, you mean it’s a GCvideo software-correctable problem, right?

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).

this was all after the review video had been put online. I don't yet own a WiiDual modded unit.

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

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.

@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 ?

The stock output doesn't have interpolation. The issue with GCVideo was a different one.

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.

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.

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?

https://en.wikipedia.org/wiki/HDMI

But then you depend on the receiving device doing the YCbCr to RGB conversion which could cause even more issues.

Unseen insists on reading the EDID to know that it is supported, and it would complicate the on-screen display.

Two main reasons actually:

• 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.

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.

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)

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




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?

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):

This is a different issue.

But the chroma shift issue has been fixed, no? (which is what the post I was replying to mentioned).

Though there seem to be yet another chroma-related issue, an issue related to "chroma interpolation"?

This is a different chroma shift issue.

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?

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.

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.

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.

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.

(*) It's just a ROM with a set of pre-generated infoframes covering all combinations because there used to be not that many...

WiiDual-installation-video by citrus3000psi: https://www.youtube.com/watch?v=gNqjkZr9dYM