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.
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)
I guess that flaw is just a result 
