WiiDual / GCVideo discussion

[citrus3000psi]

How do you compensate for the half-pixel chroma shift caused by that?

I delayed the chroma in the encoder before it gets to the 422-444. Sounds like you'd need to compensate for the shift in the encoder when pixel averaging is on.

[Unseen]

How do you compensate for the half-pixel chroma shift caused by that?

I delayed the chroma in the encoder before it gets to the 422-444. Sounds like you'd need to compensate for the shift in the encoder when pixel averaging is on.

That answer doesn't make any sense to me. Using zero-order hold instead of bilinear interpolation in the 422-444 conversion results in a half-pixel shift (relative to luma) which you can't fix by delaying anything because delays can only result in full-pixel shifts.

[vol.2]

I'm currently waiting on my wiidual kit. What's the easiest way to update the firmware?

There's only way one that I seen citrus mention and it's not easy...

https://twitter.com/citrus3000psi/statu ... 7699394560

Ok. Thanks for that, I never thought of checking twitter as I don't use it much. I wonder if there is a way to do it before I install the kit?

[Extrems]

That answer doesn't make any sense to me. Using zero-order hold instead of bilinear interpolation in the 422-444 conversion results in a half-pixel shift (relative to luma) which you can't fix by delaying anything because delays can only result in full-pixel shifts.

It was added at my request for a future project and analog YPbPr.

[fernan1234]

Just to confirm, it is advised now for WiiDual users to flash citrus3000psi's 2.4c.1, or is Unseen's 2.4d doing the same but better, or still wait for 2.5?

I'm asking since Unseen's last post makes it sound as if the fix implemented in 2.4c.1 is not correct.

[Lawfer]

Just to confirm, it is advised now for WiiDual users to flash citrus3000psi's 2.4c.1, or is Unseen's 2.4d doing the same but better, or still wait for 2.5?

I'm asking since Unseen's last post makes it sound as if the fix implemented in 2.4c.1 is not correct.

I mean that depends on how "easy" it is for you to flash the firmware? If you know what you are doing, have soldering experience and are confident in flashing it real quick without messing it up you can go ahead and flash it right now I guess? However, if you have no soldering experience and you are not really too confident in what you are doing then it is better to update the firmware as little as possible, in that case it would be advised to wait for 2.5 or later.

I mean citrus himself gives you this disclaimer:

I cannot be found responsible for damage done to consoles or yourself. If you are the least bit uncomfortable doing the upgrade, please seek help.

[Extrems]

I'm asking since Unseen's last post makes it sound as if the fix implemented in 2.4c.1 is not correct.

It's unrelated to the fix.

[citrus3000psi]

Here are screenshots. There seems to be in issue with vanilla 2.4d on the Wii? As the color are inverted? See screenshot below.

Spoiler

Odd Image screenshot of 2.4c.1 with pixel average on

Spoiler

Odd Image screenshot of 2.4c.1 with pixel average off (Yes Luma is not aligned, its 1 pixel to the right)

Spoiler

Even Image screenshot of 2.4c.1 with pixel average on

Spoiler

Even Image screenshot of 2.4c.1 with pixel average off (Luma looks correct)

Spoiler

[Lawfer]

Odd Image screenshot of 2.4c.1 with pixel average on

Spoiler

Odd Image screenshot of 2.4c.1 with pixel average off (Yes Luma is not aligned, its 1 pixel to the right)

Spoiler

Just so you know, these are both the same screenshots (with pixel average on).

[Extrems]

You somehow managed to implement average off incorrectly, it's shifted left.

[citrus3000psi]

Just so you know, these are both the same screenshots (with pixel average on).

Thanks Fixed

You somehow managed to implement average off incorrectly, it's shifted left.

It makes sense what unseen is saying, not sure how to fix this....

[Lawfer]

You somehow managed to implement average off incorrectly, it's shifted left.

That answer doesn't make any sense to me. Using zero-order hold instead of bilinear interpolation in the 422-444 conversion results in a half-pixel shift (relative to luma) which you can't fix by delaying anything because delays can only result in full-pixel shifts.

It was added at my request for a future project and analog YPbPr.

Would you please be kind enough to explain what the introduction of "pixel average on" and "pixel average off" does and what improvements it is supposed to bring in? Does it affect (Analog) RGB or only YPbPr?

With the "pixel average off" being shifted left/right, I notice that the circle looks more "pixelized" or "aliased", see the circled part in red on the lower left part of the screen:

Spoiler

The screenshot with "pixel average on" on the other hand, looks to not have this problem in comparison.

[Unseen]

Would you please be kind enough to explain what the introduction of "pixel average on" and "pixel average off" does and what improvements it is supposed to bring in?

"pixel average on" is basically what GCVideo has always done, it calculates the missing color values for every second pixel by averaging the color of the left and right pixel - it's a very common method for interpolating 4:2:2 video to 4:4:4. "pixel average off" in citrus' build probably takes the color of one pixel and applies it either to the left or right one. This can make smooth color transitions look more pixelated, especially for colors that are at the extreme ends of the YCbCr color range (e.g. fully saturated red or blue). extrems probably wants it for GBI, because there he's dealing with non-smooth graphics in the first place and disabling color interpolation can preserve the edges of zoomed pixels.

Does it affect (Analog) RGB or only YPbPr?

It should affect everything, because the Gamecube outputs YCbCr 4:2:2 and everything else is derived from that.

With the "pixel average off" being shifted left/right, I notice that the circle looks more "pixelized" or "aliased", see the circled part in red on the lower left part of the screen:

If you take two identical screenshots with pixel averaging on and off and flip between them, you'll probably notice that the colors move slightly between them, especially in the areas that appear pixelated. That's because the Gamecube sends the brightness for every pixel, but the color only for every second pixel to save RAM and bandwidth. If you then take that color and apply it either to the left or right brightness-only-pixel, you conceptually "smear" the color towards this direction. With pixel averaging on, the "smearing" happens equally in both directions, so the position of the color channels compared to the brightness channel stays the same.

[fernan1234]

I mean that depends on how "easy" it is for you to flash the firmware? If you know what you are doing, have soldering experience and are confident in flashing it real quick without messing it up you can go ahead and flash it right now I guess? However, if you have no soldering experience and you are not really too confident in what you are doing then it is better to update the firmware as little as possible, in that case it would be advised to wait for 2.5 or later.

Thanks. I'm a mere user with no ability to do the upgrade myself, so I have to send it out to the modder who did the installation again, at additional cost after paying for the kit and installation. I'd wager a good chunk of users, if not most, are on the same boat.

From the current discussion it sounds like it's more prudent to wait for the video gurus here to sort things out.

[citrus3000psi]

You somehow managed to implement average off incorrectly, it's shifted left.

That answer doesn't make any sense to me. Using zero-order hold instead of bilinear interpolation in the 422-444 conversion results in a half-pixel shift (relative to luma) which you can't fix by delaying anything because delays can only result in full-pixel shifts.

It was added at my request for a future project and analog YPbPr.

Would you please be kind enough to explain what the introduction of "pixel average on" and "pixel average off" does and what improvements it is supposed to bring in? Does it affect (Analog) RGB or only YPbPr?

With the "pixel average off" being shifted left/right, I notice that the circle looks more "pixelized" or "aliased", see the circled part in red on the lower left part of the screen:

Spoiler

The screenshot with "pixel average on" on the other hand, looks to not have this problem in comparison.

The gamecube outputs 422 Luma Chroma information. This is converted to 444, to make up for the missing chroma you either can average or duplicate. Duplication will look better on hard/rough pixel content like GBI.


Those Pixel Average off images are incorrect. They should more look like this. Ignore the OSD, only look at the background content. This is with the chroma shifted right 1 pixel.

Odd Image

Spoiler

Even Image

Spoiler

[Extrems]

"pixel average on" is basically what GCVideo has always done, it calculates the missing color values for every second pixel by averaging the color of the left and right pixel - it's a very common method for interpolating 4:2:2 video to 4:4:4. "pixel average off" in citrus' build probably takes the color of one pixel and applies it either to the left or right one. This can make smooth color transitions look more pixelated, especially for colors that are at the extreme ends of the YCbCr color range (e.g. fully saturated red or blue). extrems probably wants it for GBI, because there he's dealing with non-smooth graphics in the first place and disabling color interpolation can preserve the edges of zoomed pixels.

I found that a zero-order hold give better results for analog YPbPr with consumer equipment.

[Lawfer]

I mean that depends on how "easy" it is for you to flash the firmware? If you know what you are doing, have soldering experience and are confident in flashing it real quick without messing it up you can go ahead and flash it right now I guess? However, if you have no soldering experience and you are not really too confident in what you are doing then it is better to update the firmware as little as possible, in that case it would be advised to wait for 2.5 or later.

Thanks. I'm a mere user with no ability to do the upgrade myself, so I have to send it out to the modder who did the installation again, at additional cost after paying for the kit and installation. I'd wager a good chunk of users, if not most, are on the same boat.

From the current discussion it sounds like it's more prudent to wait for the video gurus here to sort things out.

Yeah I am in the same boat as well, I am on GCVideo 2.4b right now, meaning digital audio is a no-go as it has an issue where digital audio (through HDMI) sound muffled and echoes like if it was coming from a tunnel or something (this is an issue that was fixed by 2.4c) thankfully analog audio does not have this issue, and now 2.4d fixed the "incorrect chroma mixing for Cr-first lines" issue as well. So yeah, if you are going to pay money for shipments and for the modding service, it would be better to wait (in my opinion) and have it done once.

The gamecube outputs 422 Luma Chroma information. This is converted to 444, to make up for the missing chroma you either can average or duplicate. Duplication will look better on hard/rough pixel content like GBI.


Those Pixel Average off images are incorrect. They should more look like this. Ignore the OSD, only look at the background content. This is with the chroma shifted right 1 pixel.

Odd Image

Spoiler

Even Image

Spoiler

I see thank you for the information, interesting, I was aware that both the GameCube and Wii uses 422 internally as Fudoh explained to me, so I am using the Wii set to Analog RGB in the GCVideo menu + OSSC 1.6 + Extron DSC 301 HD, both the OSSC and Extron uses 4:4:4 chroma and I set the Extron to output in 1920x1080 4:4:4, by any chance might you know if this might somehow "rectify" the issue?

[citrus3000psi]

I'm currently waiting on my wiidual kit. What's the easiest way to update the firmware?

Where are you getting it from?

I'm currently waiting on my wiidual kit. What's the easiest way to update the firmware?

There's only way one that I seen citrus mention and it's not easy...

https://twitter.com/citrus3000psi/statu ... 7699394560

The update is actually pretty easy. I will update anyone's Wii for free. As long as they:

Take apart the Wii and ship me only the motherboard.
Pack the item appropriately, so I can reuse your packing materials.
Include a return shipping label, that I just need to tape on.

[Lawfer]

The update is actually pretty easy.

Oh yeah, though by "not easy" I meant from an average joe end-user perspective, not from an expert modder perspective. Average joe's expect to be able to update the firmware easily like they would update their PS4 firmware, or at most insert an SD Card with the firmware inside and click "update firmware" like on an OSSC or Mega Sg for example, with the GCDual or WiiDual updating the firmware is little more complicated than that.

I will update anyone's Wii for free. As long as they:

Take apart the Wii and ship me only the motherboard.
Pack the item appropriately, so I can reuse your packing materials.
Include a return shipping label, that I just need to tape on.

Oh that would be pretty helpful for alot of us who don't feel too confident in updating the firmware ourselves, thank you very much for for letting us know.

[fernan1234]

That's a nice offer, though it seems that by far the worst part involved in the upgrade process is the disassembly and reassembly of the console.

[Lawfer]

That's a nice offer, though it seems that by far the worst part involved in the upgrade process is the disassembly and reassembly of the console.

Yeah, I recently bought a brand new SCPH-3900x PAL PS2, upon trying it out I found that the clock battery was dead (the time wouldn't work and the sphere wouldn't swirl around on the dashboard), I looked on youtube to see how you can replace the battery and holy hell you literally have to take the whole thing apart just to get to the battery:

https://www.youtube.com/watch?v=yFjZ-aVaYzM

Thankfully for the Wii, Nintendo made it so much easier to replace it by just having you unscrew one screw on the side of the Wii (the side where the fan is).

[vol.2]

I'm currently waiting on my wiidual kit. What's the easiest way to update the firmware?

Where are you getting it from?

I'm currently waiting on my wiidual kit. What's the easiest way to update the firmware?

There's only way one that I seen citrus mention and it's not easy...

https://twitter.com/citrus3000psi/statu ... 7699394560

The update is actually pretty easy. I will update anyone's Wii for free. As long as they:

Take apart the Wii and ship me only the motherboard.
Pack the item appropriately, so I can reuse your packing materials.
Include a return shipping label, that I just need to tape on.

VGP. although I suppose you would've been more local? For some reason I thought you were also in the UK. After Seeing your Twitter page, I realize your US.

I can certainly do the procedure myself, but I guess I'll have to order the programmer.

Is your offer only good for ones you sold directly?

[citrus3000psi]

Here is 2.4c.2 for users with WiiDual 1.1
http://dansprojects.com/firmware/WiiDual1.1_2.4c.2.zip

And also 2.4c.2 for WiiDual 1.0 (The 1.0 is not printed on the PCB, just says WiiDual)
http://dansprojects.com/firmware/WiiDual1.0_2.4c.2.zip

This fixes the shift that extrems mentioned earlier.

[fernan1234]

Here is 2.4c.2 for users with WiiDual 1.1

http://dansprojects.com/firmware/WiiDual1.1_2.4c.2.zip

This fixes the shift that extremes mentioned earlier.

Thanks for this release. I think I'll try to get this flashed and call my WD done for good. After this there aren't really any issues left unresolved, right?

Also, am I getting it correctly that pixel average off would be more suited for sprite-based graphics (like GB/C/A games on GBI), while pixel average on would be better for 3D/Wii/GC games?

[Extrems]

It's for analog YPbPr and a future project based on GBIHF.

[fernan1234]

It's for analog YPbPr and a future project based on GBIHF.

OK, so just to clarity, for analog RGB and other content it will be better to leave it on, while setting it off for analog YPbPr and your future project?

[Extrems]

If you get YPbPr into an OSSC, you'll probably want to leave it on.

[fernan1234]

If you get YPbPr into an OSSC, you'll probably want to leave it on.

Thanks. I mainly feed RGBS into a BVM. I guess it won't hurt to see how off looks on different stuff anyway.

[Drunk_Caterpillar]

After this there aren't really any issues left unresolved, right?

This is what I've been wondering. What's even left to implement with Firmware v2.5? Sounds like the FPGA is pretty stretched by this point anyway, no?

[Extrems]

You can read the GBI manual for a taste of remaining issues condensed in one-ish place.