XRGB-mini Framemeister

[blizzz]

Anyway! I've got a bit of a weird problem with RGB colour. It seems like the problem is actually a greeny blue hue over the entire image. I tried messing with the RGB settings, but it only made the whites extremely red, or made everything even more dull. I don't have a reliable way of capturing it, but another good example was the grass outside Peach's castle in SM64. On my BVM, it's green, the sand is orange, and the walls are grey. On the Mini, the grass is highliter neon green, the sand is blueish, and the walls are red.

Here's how the grass in SM64 looks for me: https://blz.la/rgb/img/2014/framemeister_29.jpg

Not sure what's happening on your device.

[pyrotek85]

http://www.amazon.com/dp/B003VJ9RP6

Thanks, I may give that a try if the picture ever starts to act up. But generally it's pretty good IMO, but I don't have quite as sharp an eye for the really fine details either.

[austin532]

480i/p will look much better and the transitions will be instantaneous without losing the signal unlike the Mini.

480p - yes.
480i - no. While the new Sonys have a great deinterlacer, the picture is considerably softer compared to running it through the Mini.

Are you sure about that? Ok maybe 480i doesn't necessarily look better but it doesn't look worse compared to the Mini IMO. You have to turn off everything to get a clear image even the misleading Display Speed Preference option that heavily softens the image.

[Jademalo]

Anyway! I've got a bit of a weird problem with RGB colour. It seems like the problem is actually a greeny blue hue over the entire image. I tried messing with the RGB settings, but it only made the whites extremely red, or made everything even more dull. I don't have a reliable way of capturing it, but another good example was the grass outside Peach's castle in SM64. On my BVM, it's green, the sand is orange, and the walls are grey. On the Mini, the grass is highliter neon green, the sand is blueish, and the walls are red.

Here's how the grass in SM64 looks for me: https://blz.la/rgb/img/2014/framemeister_29.jpg

Not sure what's happening on your device.

Any chance of your settings for both colour and scaling? Your pixels look really nice and sharp.
Also to clarify, this isn't a capture issue, the direct feed to my monitor is exactly the same.

So to start, here's an image of what my grass looks like in the same place. You can also see the Bob-omb's stache is extremely grey.
http://i.imgur.com/r5SZzz6.png
And here's a section of the grass taken and averaged in Photoshop. Yours is on the left, mine is on the right.
http://i.imgur.com/DQmst34.png

Here's also an image of the very start of the game, you can see how neon the grass looks especially here. The texture has been almost completely destroyed.
http://i.imgur.com/eDErXur.png
Here's another image of the start, but one I took a couple of days ago. For some reason the colours are different again, lol.
http://i.imgur.com/KLf8qFN.png

Thanks!

[Fudoh]

Are you sure about that? Ok maybe 480i doesn't necessarily look better but it doesn't look worse compared to the Mini IMO.

Yes, it's a night and day difference in sharpness. Edges and pixels with 480i on the Mini look as sharp as they do with 480p content. On the TVs I've seen, even those managing to do a perfect 480p image, 480i is always blurred.

[blizzz]

Jademalo, I went back to the source file of my Super Mario 64 capture and took a screenshot of the garden area.
Correct processing: https://dl.dropboxusercontent.com/u/345 ... 64_709.png
Incorrectly decoded as Rec.601: https://dl.dropboxusercontent.com/u/345 ... 64_601.png

The second one looks very close to your picture. This is a common error that shows up all the time. If you record the Framemeister with the PEXHDCAP card in AmarecTV and you take a screenshot there, it will turn out like this. Also if you record it as a video and open it in VirtualDub it will incorrectly use the color matrix for SD content. It should look correct in the preview and on your TV though. Make sure that the HDMI input on your TV is set to Rec.709 for 720p/1080p sources, though this is the standard and should be what your TV uses by default. Color enhancements can also screw up the greens on TVs.

As for my settings, I had most settings on the default values. H_SCALER is set to 5 to make it as sharp as possible, the color stuff is mostly untouched. A/D level is also at the default value.

[Jademalo]

Jademalo, I went back to the source file of my Super Mario 64 capture and took a screenshot of the garden area.
Correct processing: https://dl.dropboxusercontent.com/u/345 ... 64_709.png
Incorrectly decoded as Rec.601: https://dl.dropboxusercontent.com/u/345 ... 64_601.png

The second one looks very close to your picture. This is a common error that shows up all the time. If you record the Framemeister with the PEXHDCAP card in AmarecTV and you take a screenshot there, it will turn out like this. Also if you record it as a video and open it in VirtualDub it will incorrectly use the color matrix for SD content. It should look correct in the preview and on your TV though. Make sure that the HDMI input on your TV is set to Rec.709 for 720p/1080p sources, though this is the standard and should be what your TV uses by default. Color enhancements can also screw up the greens on TVs.

As for my settings, I had most settings on the default values. H_SCALER is set to 5 to make it as sharp as possible, the color stuff is mostly untouched. A/D level is also at the default value.

Oh my god, that looks to be exactly the issue I'm having! :O
I'm capturing with an Avermedia Extremecap U3, and the issue happens in both Amarec and OBS.
The monitor I'm using is a Benq RL2450HT, with the HDMI of the Mini split and plugged directly into both it and the Extremecap. Interestingly that has the same colour issues as the rec.601 which was what was confusing me so much. I was getting the same image on that as I was on the feed through Amarec.

Thanks a ton, this means I might have a base to actually go on now to fix it!
Have you got any idea how to force OBS and Amarec to use Rec.709?

Thanks! =]

EDIT: Just read your site, damn there is some good information on there!
Also another quick question, does the Mini output Limited range RGB or full range?

[FBX]

H_SCALER is set to 5 to make it as sharp as possible

Zooming tests I did show that 5 adds a miniscule amount of ringing. A value of 4 is the sharpest non-ringing setting you can get.

[Jademalo]

Hmm... Yeah, I have no idea. This is getting confusing.

The new OBS has an option to use 601 or 709 colour. As it turns out, I have been capturing 709 this whole time and it's not just my imagination. This is an issue related, but really weird.

Using Component on 709, I get a perfect image
Using RGB on 709, I get a greeny image.
Using Component on 601, I get an image IDENTICAL to RGB on 709
Using RGB on 601, I get an INSANELY green image.

Just from looking, it's almost as if rgb is getting a double helping of 601, even though I don't think it works that way, lol. What really gets me is that component on 601 and rgb on 709 are entirely identical, and I mean entirely. RGB on 601 practically doubles the issue, and makes the greens flat out insane.

I have an idea though. Fudoh, have you got any idea which firmware that isn't the most recent has the fewest weird bugs? I think I might be going through them and seeing if it's a firmware bug, because honestly I can't get away with how similar component 601 and rgb 709 are.

[Fudoh]

1.07A was pretty much fine. You're just losing the zoom function.

It's an interesting issue. When you compare component and RGB, what do you use ? The same source, one time with a transcoder ? Or different sources ?

Remember that rec.601/709 is usually a decoder question and the matrices are used to decode YCbCr to RGB, so they're only appliciable when YCbCr is used. If you run your signal in RGB444 instead, there's no choice available.

So, if you want to rule out the display decoding and have a seperate look at the Mini's input processing, make sure to use RGB output.

[Jademalo]

I've tried all different combinations. Component out of the wii, the transcoder from that component, a scart cable out of the Wii, bypassing the rest of my setup for all of the above, the works. The issue as I've said is also present in all RGB consoles, the component and transcoder is nice because I can flick between the two at ease to compare.
I've also got the Mini set to RGB output, and have done the entire time. (Also you say rgb444, i thought the mini was 4:2:2?)

The other interesting thing about this is as i said, the issue is visible not just on my capture hardware, but also on my monitor.
I think with the combination of all that it's definitely not a colour decoding issue, but something the mini is doing. It's like the mini is applying 601 then sending it in RGB, so the true capture is already messed up.

I'll try 1.07A now, and I'll get back to you. If this fixes it, then that will be interesting, lol.



Hm, that's interesting. Standby mode seemed to not exist with v1.11 for me. It works fine now.

Spoiler

Aaand holy shit it's a firmware bug. Lemme mess around with the settings some more to confirm it, but god damn it looks so, SO much better
EDIT: Yeah, the colours are way, way closer to eachother now. This is what I was expecting!
I guess the thing to question now is why on earth are the colours on v1.11 RGB broken?

EDIT2: Wait, that might have been a premature celebration. Now it's gone weird again. I have no idea what I've done.
Yeah this is super weird. On default settings they both look the same, but when I fix component to look correct (As in, identical to my BVM and an emulator) it's impossible to get RGB to look the same. It looks like it's got some form of processing that's applying 601 to the rgb feed for some reason. This is causing most of the colours to go severely out of whack when the settings are properly dialed in to not look washed out.

I think the reason it looked good initially was because it being washed out disguised the issue with the greens, but when I lowered the brightness it became mega visible again.

The more I look at it, the more I'm positive that's what it's doing. I've reconfigured component and it's absolutely perfect. The greens are vibrant, but not harsh. Whites are bright and not dull. Colours pop. (On another note, man my new cable is an improvement, so much less noise)
I'm gonna try a much older firmware, see if that does anything.

EDIT3: Tried the first firmware available, same issue. It's almost like RGB is in permanent anime mode or something. I don't know what to do or think, since Component is absolutely perfect. RGB is definitely getting processed colour wise before the output. The more I look, the more apparent it is.

I'm at a loss now. I've also tried some different monitors and my other TV, and they all show the neon green. I also figured I would try the normal inputs on the TV just to be sure, and the colours are as I expect them. What on earth is the mini doing...

EDIT4: Yeah, I'm done. I'm at a loss as of what to do. The only thing I can think is to try DVI output, but I don't have a cable long enough and my monitors are wired in in such a way it would be a nightmare to take them over to try it.

It definitely seems like the Mini is applying Rec. 601 to all RGB inputs, which is making greens turn neon and messing with reds. I can get an absolutely perfect image with Component that has the greens a bit darker and the image overall looking a lot better. If I apply Rec. 601 to that in virtualdub or something, I get an image almost identical to the RGB output.
It's an issue that exists in every single version of the firmware as far as I've tested.

This is extremely disappointing in all honesty, but it explains a heck of a lot. I was wondering why Yoshi was such a vibrant shade of green in YI a few weeks ago, but I put it down to a capture card issue. Super Mario 64 looked weird, and so did Banjo Kazooie. Since Sunshine and my Wii in general looked fine, I figured it was just my eyes playing tricks on me. It definitely isn't though, the Mini is messing with RGB colours substantially.

The only thing I can think to try now is getting an RGB to YPbPr transcoder and doing these same tests again. I have a feeling that it will make my N64 and SNES look perfect. Ironic, considering the amount of people saying the Component imput is bad, lol.
Any suggestions for a cheap one of those Fudoh?

Ah well, thanks for all the help guys. I do have one more question though - Does anyone have a Wii/GC scart cable and sunshine, and if you do would you be willing to give me a hand for a test?
Thanks again, man I feel pretty deflated now.


EDIT5: Out of curiosity, what exactly is rec 601/709?
From what I've been able to figure out and according to some stuff I read, it's a set of standards of getting Luma from RGB. However, you say it's YCbCr to RGB? I'm a bit confused by that.
Also, if SD devices were all designed to use 601, and by that im assuming things like a SNES and N64 were, why is it that a 601 decoded image looks so obviously wrong from them? Is it to do with how LCD and CRT display the colour?

If that's the case and if I have this right, is the Mini decoding the lumiance from the RGB input with 601, but for some reason indicating over HDMI that it's infact encoded with 709, so when a device tries to decode the lumiance it's thinking the image is already in 709 and fine, when it should actually be reading that as 601 and reencoding the lumiance to 709 thereby fixing the colour?

EDIT6: No wait, that has to be wrong. Or else setting it to 601 would fix it rather than making it worse. I need to get my head around this, argh. Also I see that it's a YCbCr encoding now, I found another site that made that make more sense.

So RGB is an absolute colour thing that uses 0-255 intensity of Red Green and Blue to determine exact colour and lumiance. This works based on how our eyes work.
YCbCr is a method of encoding RGB into Lumiance and two cromiance signals, which allows for chroma subsampling to reduce bandwidth.
There are two main methods of encoding, Rec. 601 and Rec. 709. Correctly decoded, these images should look the same. The issues arise when one is decoded with the other.
An image encoded with 709 but displayed/decoded with 601 causes the greens to go really bright. Most HD devices etc use 709 to decode so this isn't an issue, but sometimes some software can use the wrong algorithm.
To correct this, the YCbCr signal needs to be decoded correctly.
YPbPr, the analogue variant, uses the same constants as Rec. 709.

My issue with the mini is strange, since for some reason (As far as I can tell,) I'm getting an RGB444 feed that has a weird encoding issue.
For some reason, the Mini is encoding the RGB input with 709, then decoding it with 601 to achieve RGB444. This results in the broken colours.
For the YPbPr input however, it is correctly decoding it with 709 into RGB444, resulting in correct colours. (Or maybe not, I'm not sure if I've ever had it output RGB from a YPbPr source)

My capture card seems to encode all inputs into YUV 709. I'm assuming this is so it can subsample to 4:2:2 so it can actually achieve the recording at 1080p60 without failing miserably.
Because of this, my recordings need to be decoded into RGB. If I decode them with 709 then everything is correct in terms of what is sent to the capture card. However if I decode them with 601, then this causes the same issue for the YPbPr mini feed. In addition, it also makes the already broken RGB feed even more broken. However, if this is correctly set to 709, everything is fine.

So for some reason, the Mini is doing a random, failure of an encode and decode for some reason (Possibly for chroma subsampling?) before sending the RGB444 signal.
I think.

If this is the case, is it something I need to get on to Mimcomsoft about? I mean, it's a pretty severe bug in the firmware if that's the case. Hmm, I wonder if using the YUV output can solve this rather than forcing RGB.



EDIT7: Oh my god it worked.
If the HDMI output is set to Auto and the Mini booted after the console so that the HDMI output is actually YUV, the RGB colour is correct, and encoded with 709. Considering every single guide everywhere was how to get the Mini to stay in RGB mode I assumed it would be better, but I think that is where the bug is! (And I assume that's where my premature celebration came from since after installing the firmware it output YUV)

It seems for whatever reason, the RGB input to the Mini is being encoded with 709, then decoded with 601 before being sent over RGB444 HDMI.
The YPbPr input to the Mini doesn't have this problem, as far as I can tell the Mini doesn't seem to like RGB444 HDMI output from a component source.

However, if the Mini is set to YCbCr, then RGB is being encoded with 709 before being sent, and YPbPr isn't being reencoded at all so they're both fine.


Moral of the story - RGB output is flawed on the Mini for RGB sources, don't use it or your colours are wrong!

EDIT8: Some images -

http://i.imgur.com/mqlSlVY.png - RGB Input, RGB Output (The broken one)
http://i.imgur.com/ZPRLITY.png - RGB Input, YUV Output (The fixed one!)
http://i.imgur.com/IyJu3hH.png - YPbPr Input, YUV Output

Those images are a bit bad since Amarec seems to decode them in 601 when using image capture (Lol, for an added layer of poop) but the preview and OBS and my monitor are all perfect. Also they're doubly bad since they're uncalibrated, I just sat down and got both RGB and Component to be extremely close, and almost identical to my BVM.

Honest to god, this is what I was expecting from the Mini. I'm so pleased it got there in the end =]
(Though that bug does need to be reported)

[CkRtech]

Although I generally don't have a complaint about lag on the framemeister, I finally got around to getting my Saturn dusted off and hooked up to it. Seems like X-Men vs Street Fighter in PICTURE mode is noticeably behind. Granted, this is the only way I have played it (via the xrgb). I was also using the 3D controller at the time, but man...

I compensated after a couple of battles but was a bit disappointed that I had to.

[Xan]

Moral of the story - RGB output is flawed on the Mini for RGB sources, don't use it or your colours are wrong!

And nobody realized this until now? I guess that flaw is just a result of that Marvell chip being engineered for BD players...

Still the YCbCr output is chroma subsampled so it's not perfect (unless only dealing with recordings), maybe this should be reported to Micomsoft?

[blizzz]

Now that I think about it, this issue sounds a lot like the one Shining had a while ago: http://shmups.system11.org/viewtopic.ph ... 0#p1087120

He also had oversaturated greens when using RGB output, while YCbCr was fine. I'm not sure what to make out of this.

[Fudoh]

Thanks for playing this through!

I might add that it's even a little more complicated than this. I can assure you that it's possible to get the same bug with component input. You'll quite easily run into it when you use a game that you can easily switch from to 240p to 480i to 480p.

And if you like to continue to look into it (which I hope you'll do), try 480p output mode as well.

Remember that rec.601 (input and outputwise) is used for 240p, 480i and 480p, while .709 is used for 720p, 1080i and 1080p. In other words, 480p output from the Mini should behave completely different than 720p and 1080p.

[12345]

Thanks for playing this through!

I might add that it's even a little more complicated than this. I can assure you that it's possible to get the same bug with component input. You'll quite easily run into it when you use a game that you can easily switch from to 240p to 480i to 480p.

And if you like to continue to look into it (which I hope you'll do), try 480p output mode as well.

Remember that rec.601 (input and outputwise) is used for 240p, 480i and 480p, while .709 is used for 720p, 1080i and 1080p. In other words, 480p output from the Mini should behave completely different than 720p and 1080p.

Yes, I've already realized this with component inputs since quite some time so I'm sticking to AUTO. I see no point in conversion anyway for this input since it's YcBCR natively anyway.

[Jademalo]

Thanks for playing this through!

I might add that it's even a little more complicated than this. I can assure you that it's possible to get the same bug with component input. You'll quite easily run into it when you use a game that you can easily switch from to 240p to 480i to 480p.

And if you like to continue to look into it (which I hope you'll do), try 480p output mode as well.

Remember that rec.601 (input and outputwise) is used for 240p, 480i and 480p, while .709 is used for 720p, 1080i and 1080p. In other words, 480p output from the Mini should behave completely different than 720p and 1080p.

I'll give everything another look later, I'll also try to capture some properly calibrated images rather than the terrible ones in my other post. I should be able to get the issue to show itsself on the 240p test suite if that's the case, since it's easy to flick that between different modes and it's conveniently on the Wii!

Also just to get this straight - is there any difference between YPbPr anf YCbCr except for the name? Are SD signals encoded with 601 and HD 709 the same as YCbCr over HDMI?
I think I've understood it now which should help with getting consistent results, but the Wikipedia page for YPbPr only states rec.709 as being used. Also my Transcoder states that it uses these colour profiles - Color: 480i/480p per SMPTE 170M, 720p/1080i per SMPTE 274M. Is 170M 601 and 274M 709?

Now that I think about it, this issue sounds a lot like the one Shining had a while ago: http://shmups.system11.org/viewtopic.ph ... 0#p1087120

He also had oversaturated greens when using RGB output, while YCbCr was fine. I'm not sure what to make out of this.

Yeah, that's exactly the issue I've seen. I don't have super mario world to do a direct comparison though, or I would.
Actually, I wonder if I can get something similar using Virtual Console...

Moral of the story - RGB output is flawed on the Mini for RGB sources, don't use it or your colours are wrong!

And nobody realized this until now? I guess that flaw is just a result of that Marvell chip being engineered for BD players...

Still the YCbCr output is chroma subsampled so it's not perfect (unless only dealing with recordings), maybe this should be reported to Micomsoft?

Thankfully the YCbCr output is fine for my needs since I'm mainly recording, but it definitely does seem like a weird one. I'd report it myself, but 私は日本語を話しカント.

[Gered]

Just wanted to quickly add my experiences with some weird colour differences. The SMW "green shrub" test that Shining used in his post has been helpful to me too in noticing little differences in colour, so I'll use that here as well.

Apologies in advance for the photo quality, all I have to work with are crummy phone and tablet cameras and I'm definitely no photographer!

• HDMI @ 1080p RGB output (Mini powered on before SNES)

• HDMI @ 1080p YCBCR output (Mini powered on after SNES)

• DVI @ 1080p

• DVI @ 1280x1024

The DVI output at 1280x1024 gives me the best colour. And I really don't understand why! The method to get the Mini to output as YCBCR by powering it on after the console helped a little bit (sorry, kind of hard to tell in the photo) but not nearly as much as in the last DVI photo. 1600x1200 output also looks good colour-wise, but I don't use it as it looks slightly more blurred compared to 1280x1024 on my TV. Also, any of the DVI modes shown in the list above 1600x1200 show correct colour. All of the modes below (1280x768, 1360x768, 1680x1050, etc etc) show the same kind of incorrect colour seen in the 1080p photos above. Only difference I notice is basically that the 4:3 output modes show correct colour while the 16:9 modes don't. I can't imagine why that would make any difference, but it is basically what I'm seeing!

Thankfully DVI output at 1280x1024 actually looks quite nice on my TV, but definitely not as sharp an image as it would be at 1080p output. Would love to know what the heck is going on.

[Fudoh]

Also just to get this straight - is there any difference between YPbPr anf YCbCr except for the name? Are SD signals encoded with 601 and HD 709 the same as YCbCr over HDMI?

YPbPr carries full color resolution. The standard itself does not tell anything about chroma subsampling. With a digitally compressed source (like DVD or BD) the color gets upsampled. With analogue encoders (as present in most consoles) you can usually assume that the color channels are simply transcoded from the original RGB colors, so they have full resolution.

Also rec. 601 and 709 only apply to digital signals (that's why your transcoder states the SMPTE norms instead). Of course most (if not all) analogue HD signals are derived from digital processors or encoders, so you can assume that 709 specs are still in place. I would also assume that the older rec. 601 conversion was based on the old analogue SMPTE specs, so nothing to worry about.

If a processor applies different protocols for encoding analogue SD/ED and HD signals is a different question. But I think it's safe to assume that nobody of use deals with analogue 720p on the Mini's inputs.

[Unseen]

Also just to get this straight - is there any difference between YPbPr anf YCbCr except for the name?

In theory, YCbCr is the digital representation of a video signal and YPbPr is an analog signal, but in practice both seem to be used more or less interchangably.

[RGB32E]

Just wanted to quickly add my experiences with some weird colour differences. The SMW "green shrub" test that Shining used in his post has been helpful to me too in noticing little differences in colour, so I'll use that here as well.

Apologies in advance for the photo quality, all I have to work with are crummy phone and tablet cameras and I'm definitely no photographer!

• HDMI @ 1080p RGB output (Mini powered on before SNES)

Would love to know what the heck is going on.

Seems like it's either a display issue or a firmware issue. I'm still using v1.10 IIRC, and as mentioned earlier in the thread I get good color on my TV:

[FBX]

The only strange behavior on my mini is I can only get RGB output if the input source is RGB. On D-Terminal, S-video, and composite video, the full status always shows YCbCr 8-bit or 12-bit if I turn auto deep color on. Anyone else have their mini doing this?

[Gered]

I'm on v1.11, though I guess based on Jademalo's efforts testing using different firmware versions with his issue that I'll probably see similar results. Will try on a different display and see how that goes.

[blizzz]

I also did the Super Mario World Shrub Test™ again and had a look at the garden in Super Mario 64. I'm still using FW v1.08. Also for anyone who wants to test this stuff, you can set the Mini to RGB by pushing the RGB button on the remote. When I set my TV to standby and power it on again it switches to YCbCr, this takes only 3 seconds. I've set my TV to full range for RGB and limited range for YCbCr.

Both in RGB and YCbCr mode I can clearly see the second shade of green. RGB has slightly more neon colors, though. In Super Mario 64 the grass has a bit more contrast in YCbCr mode. The bright spots are a bit more pronounced.



The difference isn't huge (on my TV), but it does look nicer in YCbCr mode. It really sucks that there is no option to force YCbCr output on the Mini. Especially with games that have resolution changes you are forced to use RGB output. What makes it even weirder is that the colors in RGB output are fine in DVI mode, but you can't select 720p there.

[FBX]

It really sucks that there is no option to force YCbCr output on the Mini.

The only way to really force it is by turning the console on first before the mini. It will then default to YCbCr without polling the display. I'm betting res-swapping games will cause it to revert though.

[blizzz]

Yes, swapping games or a resolution change will revert it back to RGB output. :/

[Jademalo]

The only strange behavior on my mini is I can only get RGB output if the input source is RGB. On D-Terminal, S-video, and composite video, the full status always shows YCbCr 8-bit or 12-bit if I turn auto deep color on. Anyone else have their mini doing this?

Mine is the same.

Seems like it's either a display issue or a firmware issue. I'm still using v1.10 IIRC, and as mentioned earlier in the thread I get good color on my TV:

Hmm, that's interesting. I'd almost argue though that the tv may be helping the colours in that image to look right. The shrub looks exceedingly bright conpared to other peoples, even though you are getting a bit more contrast. It's also visible on Yoshi and the title, the greens are very bright.
Can you try that on YCbCr output to compare? I'm extremely curious.

Also for anyone who wants to test this stuff, you can set the Mini to RGB by pushing the RGB button on the remote.

Doesn't that change the input, not the output?



Also thanks Fudoh and Unseen, I think I've got it now!

I'm going to try and put together a post detailing everything I've found with various captures etc, but it might have to wait a couple of days. 4 days+ trying to fix the colour issue has left me substantially behind on a few jobs I need to do, lol.
I'll keep as many variables out of the pictures as possible, and try as many modes as I can. I've got a DVI to HDMI converter somewhere around, so I'll try and find that to get some DVI comparisons as well. Am I right un understanding that DVI is pure RGB444?

[blizzz]

Also for anyone who wants to test this stuff, you can set the Mini to RGB by pushing the RGB button on the remote.

Doesn't that change the input, not the output?

It changes the output to RGB mode (and ofc also switches the input). It's the same as starting the console after the Framemeister.

[TheShadowRunner]

It changes the output to RGB mode (and ofc also switches the input). It's the same as starting the console after the Framemeister.

The RGB button on the remote is just to switch input, it's no meant to switch from YCbCr to RGB (even if it does), that's just a side effect ^^;

[blizzz]

Yes, I know, but what I wanted to say was: If you want to switch between RGB and YCbCr output to test a scene you can just push the RGB button for RGB output and restart your TV for YCbCr output.