XRGB-mini Framemeister

[FBX]

Possibly why mine is perfectly stable on that is I currently ONLY have one source plugged in, and that's the JP-21 RGB adapter. I guess I should expect this issue to start cropping up when I get my D-Terminal cable in the mail from Solaris.

No that's independent of number of source(s) plugged. Try the procedure above to reproduce 100% of the time (check what it outputs in Special > Full Status > Page 2).

Will do. I'll report back the results. BTW, I'm also using 1080p output when most everyone else is using 720p, so don't know if that matters either.

[12345]

It's always sharper to have the Framemeister send a 1080p signal to a 1080p display.

I cannot confirm that. On my set the 1080p setting on the mini seems to introduce more false contouring than the 720p mode, no matter what I set V-/H-settings to.

[FBX]

Okay, just tested it 5 times with the console turned on before the mini is turned on, and then 5 times after the mini is turned on. Here are the results:

It ONLY defaulted to YCbCr when I turned the Genesis on before turning on the mini. It correctly went to my full RGB setting all 5 times I turned the mini on first before turning the Genesis on.

[FBX]

It's always sharper to have the Framemeister send a 1080p signal to a 1080p display.

I cannot confirm that. On my set the 1080p setting on the mini seems to introduce more false contouring than the 720p mode, no matter what I set V-/H-settings to.

False contouring? Not sure what that is, but on my Sony display, 1080p is very clearly sharper. Using 720p causes the display to upscale the image at the slight cost of sharpness, and of course I'm talking about 240p gaming in this regard. I don't know about interlace results.

[12345]

It's always sharper to have the Framemeister send a 1080p signal to a 1080p display.

I cannot confirm that. On my set the 1080p setting on the mini seems to introduce more false contouring than the 720p mode, no matter what I set V-/H-settings to.

False contouring? Not sure what that is, but on my Sony display, 1080p is very clearly sharper. Using 720p causes the display to upscale the image at the slight cost of sharpness, and of course I'm talking about 240p gaming in this regard. I don't know about interlace results.

I'm talking about progressive sources in general. What I mean by false contouring is that the mini seems to introduce additional detail arround (diagonal) edges which isn't supposed to be there on the real outpout. It's e.g. like an additional grey line of pixels added next to the original black line of pixels shown by the hardware.

[FBX]

Okay so after more experiments with the power on of my display, mini, and console, I think I've worked out what's going on with the YCbCR versus full RGB:

It seems the mini uses YCbCr as a default failsafe when it cannot poll the TV. So for example, if you turn on the mini before the TV, it will default to YCbCr. However, turning on a console will cause the mini to re-poll the TV, and it will switch to full RGB when the console image appears on the screen if your TV is on when that happens. Conversely, if you turn the console on before the mini, it will again default to YCbCr because it skips polling the TV when detecting a console signal on boot-up.

So to sum up, always make sure your mini is on before you turn a console on. Once the midi is ready, it will correctly switch to full RGB when the console is turned on (provided your TV is on when this happens). If you want to be extra-certain of this, boot your TV first, then the mini, then the console (giving each system time to fully reach ready status).

Edit: I was further able to prove the polling theory by first having the console on and then the mini (which causes the auto failsafe to kick in). Then with the mini and TV still on, I turned off the console. If my theory was correct, turning the console back on would cause the mini to re-poll the TV for full RGB, and that's exactly what happened.

[FBX]

I'm talking about progressive sources in general. What I mean by false contouring is that the mini seems to introduce additional detail arround (diagonal) edges which isn't supposed to be there on the real outpout. It's e.g. like an additional grey line of pixels added next to the original black line of pixels shown by the hardware.

That's not happening on my end. The pixels are perfectly crisp with no artifacts. The only thing I've seen introduce what you are describing is the mini's "Sharpness" setting, which people have figured out this is never to be changed from zero for that reason.

[12345]

I'm talking about progressive sources in general. What I mean by false contouring is that the mini seems to introduce additional detail arround (diagonal) edges which isn't supposed to be there on the real outpout. It's e.g. like an additional grey line of pixels added next to the original black line of pixels shown by the hardware.

That's not happening on my end. The pixels are perfectly crisp with no artifacts. The only thing I've seen introduce what you are describing is the mini's "Sharpness" setting, which people have figured out this is never to be changed from zero for that reason.

Actually sharpness set to 1 is needed in the first place because otherwise all pixels are shifted to the side.

[FBX]

I'm talking about progressive sources in general. What I mean by false contouring is that the mini seems to introduce additional detail arround (diagonal) edges which isn't supposed to be there on the real outpout. It's e.g. like an additional grey line of pixels added next to the original black line of pixels shown by the hardware.

That's not happening on my end. The pixels are perfectly crisp with no artifacts. The only thing I've seen introduce what you are describing is the mini's "Sharpness" setting, which people have figured out this is never to be changed from zero for that reason.

Actually sharpness set to 1 is needed in the first place because otherwise all pixels are shifted to the side.

That's your problem right there then. I don't know what's causing your shifting issue, but using Sharpness 1 is DEFINITELY causing your false contouring issue. I was able to spot this myself when I tested it on the SNES. I then looked up a couple guides on the Internet, and the resounding opinion is to leave it as zero because of that.

[12345]

Sometimes opinions and FAQs on the internet are outdated as well.
I did a quick comparison with the Mini set to Sharpness 0 on the first image and 1 on the second.
Game: SF2
H/V-Scaler: 5/6

Spoiler

[FBX]

There's gotta be something else going on there because mine doesn't do that, and neither does it do that for the "opinions" you suggested were wrong on the Internet.

I'd need to know the details of your setup:

TV model
Input method from your console to the mini (as well as where you got your cable)
Format of your console (US, Europe, Japan)
Model of your console (which revision)
All the settings of your Framemeister in 1080p mode

Edit: here's a snap I took off the screen of my display. It doesn't show just how clear it looks entirely, but you get the idea:

[Thomago]

Regarding 12345's "opinion"-post.

Wether the sharpness option gives okay results depends on wether the source material is unsharp (as 12345's SF2 source is), or not.

For comparison, here's what SHARPNESS = 1 does to a rather crisp source (Illusion of Gaia from a 1-CHIP-SNES):

[12345]

@FBX
I'm talking about the junkerhq-FAQ for example which is not up to date, but many people still take it over the newer information posted recently in this thread. Furthermore I see opinions from different reviews being copy-pasted from users and other reviewers without personal evidence.
Anyway your shot does indeed look very good. Given you use different settings than most people do you use any furhter processing methods? Could you do a comparison shot with sharpness set to 1?

I got this phenomenon on all my inputs, both SCART and D-terminal so it can't have anything to do with that. I use a panasonic VT30 Plasma on Professional, calibrated with all additional processing off. With your preferences in mind the shots were taken in 1080p in advance.

Edit: @Thomago
What difference should I be looking for on your comparison shot?
How can the "issue" be persistent on all my inputs then? I doubt they're all bad since they look alright when hooked to a CRT.

[Thomago]

What difference should I be looking for on your comparison shot?
How can the "issue" be persistent on all my inputs then? I doubt they're all bad since they look alright when hooked to a CRT.

The artifacts around the eyes.
Also I was only referring to your SF2 screens - I don't know about any persistant, input-overarching issues that don't happen to be visible on CRTs.

[TheShadowRunner]

Okay so after more experiments with the power on of my display, mini, and console, I think I've worked out what's going on with the YCbCR versus full RGB:

It seems the mini uses YCbCr as a default failsafe when it cannot poll the TV. So for example, if you turn on the mini before the TV, it will default to YCbCr. However, turning on a console will cause the mini to re-poll the TV, and it will switch to full RGB when the console image appears on the screen if your TV is on when that happens. Conversely, if you turn the console on before the mini, it will again default to YCbCr because it skips polling the TV when detecting a console signal on boot-up.

So to sum up, always make sure your mini is on before you turn a console on. Once the midi is ready, it will correctly switch to full RGB when the console is turned on (provided your TV is on when this happens). If you want to be extra-certain of this, boot your TV first, then the mini, then the console (giving each system time to fully reach ready status).

Edit: I was further able to prove the polling theory by first having the console on and then the mini (which causes the auto failsafe to kick in). Then with the mini and TV still on, I turned off the console. If my theory was correct, turning the console back on would cause the mini to re-poll the TV for full RGB, and that's exactly what happened.

Very interesting theory! thanks for your time testing this.
There's still a mystery going on, or maybe it's just another bug..
If you boot TV first, then Mini and then console, you get RGB, so far so good.
However if you change input on the TV to anything else, like another HDMI input and then come back to the Mini input (triggering a new handshake), it WILL change to YCbCr, although neither the Mini nor the console were turned off at any point during the procedure..

[Jademalo]

So I take it you are having your monitor not do any scaling then? This would mean the 720p source would appear with large black boarders on the top and bottom. If you are having it scale the image, then this goes back to what I was saying about the 15% loss of sharpness. It's always sharper to have the Framemeister send a 1080p signal to a 1080p display.

Anyway, the H_Scale and V_Scale control the sharpness in those directions (that's the effect anyway). When you turn Auto_Scaler off, you then can manually set the sharpness with those H and V scalers. This is how I found that H_Scale 5 is slightly sharper than the default 6.

My monitor is doing zero scaling and is displaying a pixel accurate image. There are large black bars, but I don't care, the main use for the mini is recording anyway. I've got my BVM for playing. For recording, it's pointless doing 1080p since it uses more cpu and a TON more disk space. 720p is perfect in that regard.

Also hmm... I think I need to test something quickly. I'd love to know the technical thing that those settings do, especially considering how pants 480i sources look with game mode set.
EDIT: Well that was disappointing, H5 V7 did absolutely nothing for my chroma shift issue and barely changed the sharpness. Also for whatever reason unlike you guys, sharpness 1 dramatically increases the quality and sharpness of my image on the SNES.

Also for reference purposes here is an album of the feed from my mini, with extra settings being changed from default in each one. http://imgur.com/a/0d58z

EDIT2: Damnit, the plot thickens. Plugging the snes directly into the Mini makes the chroma shift WAY worse, but having it through my Crosspoint improves it somewhat. What on earth is causing this. I'm beginning to think it's the SNES output, but through my BVM it is absolutely sharp as a razor.
EDIT3: I'm lying, it's the snes output. After magnifying it on the BVM, I'm getting this chroma shift on that too. Damn. I'll have to ask phil. I wonder why it isnt visible on my monitor.

Well that at least solves that issue, lol. Guess it's not the mini or the capture card at least.

[12345]

@Thomago/FBX
Are you guys sure you have the sharpness setting OF YOUR TV set to 0 and every additional processing turned off? To me it seems like the cause for the shift got to be the mini itself.

@FBX
I tried the zoom settings you posted on the previous page but all it does is making the picture even smaller, far samller than the fullscreen shot you made. Are you sure your TV isn't stretching the picture although it's set to Fullpixel?
Btw.: Is your YcBCR/RGB method also valid for component sources? Because my output would always stay on YcBCR with that input....

[Thomago]

Hehe, I don't even use a TV but a PC monitor - there's absolutely no signal alteration from that side.

[12345]

Hehe, I don't even use a TV but a PC monitor - there's absolutely no signal alteration from that side.

Those monitors have corresponding options as well...

[FBX]

@Thomago/FBX
Are you guys sure you have the sharpness setting OF YOUR TV set to 0 and every additional processing turned off? To me it seems like the cause for the shift got to be the mini itself.

@FBX
I tried the zoom settings you posted on the previous page but all it does is making the picture even smaller, far samller than the fullscreen shot you made. Are you sure your TV isn't stretching the picture although it's set to Fullpixel?
Btw.: Is your YcBCR/RGB method also valid for component sources? Because my output would always stay on YcBCR with that input....

The sharpness is turned all the way off on my TV, because like the mini, it's sharpness introduces fake contours.

My picture taken of my TV is using the 5x zoom settings. 4x zoom will in fact appear much smaller, but that's the only way to have perfectly scaled pixels without using 5x mode. The math works like this:

4x224 = 896 (this means the remaining 184 res of a 1080p display will be black borders).

5x224 = 1120 (this means 4 rows of graphics on the top and bottom will be cut off on a 1080p display)

The point to using 5x or 4x is to have perfect vertical scaling, which makes scrolling on the vertical axis perfectly smooth. The only other way to get smooth scrolling is to output at 720p at a default image size like "Standard" and have the 1080p display upscale the image.

As for the component issue, I'm afraid I won't be able to test that until I get my D-Terminal in the mail. It may be another week before it arrives from customs. The Polling theory works 100% when I test it with the RGB input however.

[FBX]

Okay so after more experiments with the power on of my display, mini, and console, I think I've worked out what's going on with the YCbCR versus full RGB:

It seems the mini uses YCbCr as a default failsafe when it cannot poll the TV. So for example, if you turn on the mini before the TV, it will default to YCbCr. However, turning on a console will cause the mini to re-poll the TV, and it will switch to full RGB when the console image appears on the screen if your TV is on when that happens. Conversely, if you turn the console on before the mini, it will again default to YCbCr because it skips polling the TV when detecting a console signal on boot-up.

So to sum up, always make sure your mini is on before you turn a console on. Once the midi is ready, it will correctly switch to full RGB when the console is turned on (provided your TV is on when this happens). If you want to be extra-certain of this, boot your TV first, then the mini, then the console (giving each system time to fully reach ready status).

Edit: I was further able to prove the polling theory by first having the console on and then the mini (which causes the auto failsafe to kick in). Then with the mini and TV still on, I turned off the console. If my theory was correct, turning the console back on would cause the mini to re-poll the TV for full RGB, and that's exactly what happened.

Very interesting theory! thanks for your time testing this.
There's still a mystery going on, or maybe it's just another bug..
If you boot TV first, then Mini and then console, you get RGB, so far so good.
However if you change input on the TV to anything else, like another HDMI input and then come back to the Mini input (triggering a new handshake), it WILL change to YCbCr, although neither the Mini nor the console were turned off at any point during the procedure..

The likely explanation for that is again the failsafe kicking in when losing the TV's signal. When you turn back to the correct input on the TV, the mini is checking the console input first, which causes it to skip polling the TV and drop into failsafe mode. What you'd have to do is turn the console off, then back on again to force the mini to poll the TV. Obviously you don't want to do that if you have a game going, so the trick is to avoid changing the TV away from communicating with the mini.

I'll try this on my end to confirm.

[Thomago]

Those monitors have corresponding options as well...

Well, my monitor indeed merely has a Sharpness control, and it's set to "neutral" (neither sharpening nor softening, as per factory default - what I wrote hinted at the fact that PC monitors, in contrast to TVs, usually have neutral, non-alterating factory settings). So everything you see on my screenshots is the Mini's doing.

[FBX]

I'll try this on my end to confirm.

Okay so my Sony TV does not cause a loss of signal to the mini when I switch to a different HDMI input. It stays on full RGB and the mini doesn't require a new handshake when I turn back to it on the TV. So the theory here is different models/brands of TVs may or may not keep HDMI communication active on all connections when switching inputs.


EDIT: To confirm the above, I just tried turning the TV completely off, and this DID drop the mini into failsafe mode. When I turned the TV back on, the mini was now in YCbCr. This fully explains the polling and HDMI communication with the TV, as well as how some brands of TV completely turn off HDMI communication when switching inputs.

EDIT 2: Also I just realized you could reset the mini by merely yanking the RGB cable (or whichever cable you're using). This will force the mini to re-poll the TV, and you don't have to turn your console off.

[TheShadowRunner]

Okay so my Sony TV does not cause a loss of signal to the mini. It stays on full RGB even when I switch the TV to a different input, and the mini doesn't require a new handshake when I turn back to it on the TV. So the theory here is different models/brands of TVs may or may not keep HDMI communication active on all connections when switching inputs.

Thanks for verifying, it's good to know. Sony 40Z5500 from Q4 2009 here (a rather old model now )

Edit:

EDIT: To confirm the above, I just tried turning the TV completely off, and this DID drop the mini into failsafe mode. When I turned the TV back on, the mini was now in YCbCr. This fully explains the polling and HDMI communication with the TV, as well as how some brands of TV completely turn off HDMI communication when switching inputs.

Roger that, one less mystery on the Mini yaye!
I still view this failsafe behavior as a quite strange design choice. Why would it default to YCbCr versus RGB heh xD

[FBX]

Just edited my post above. You should be able to yank the input cable on your mini to force it to re-poll the TV if you happen to switch away from it.

[FBX]

Why would it default to YCbCr versus RGB heh xD

Because YCbCr is viewable on ANY display, whereas full RGB would only be supported by some displays. Hence it is a failsafe measure and not actually a bug.

[TheShadowRunner]

Because YCbCr is viewable on ANY display, whereas full RGB would only be supported by some displays. Hence it is a failsafe measure and not actually a bug.

Ah hmm I thought it was the other way round.

To ensure baseline compatibility between different HDMI sources and displays (as well as backward compatibility with the electrically compatible DVI standard) all HDMI devices must implement the sRGB color space at 8 bits per component. Ability to use the YCbCr color space and higher color depths ("deep color") is optional.

[12345]

@FBX
I tried your zoom settings but I still haven't got any improvement on 1080p. 720p with sharpness on 1 still looks a lot more accurate. Is there anything else I could try?
Furthermore I tried your YcBCR-(swap)-method but it doesn't seem to work on Component sources.

Btw. I came across another weird thing: When setting the mini to DVI it seems to have different Gamma/Blacklevel settings, even with the same values. Can anybody confirm that?

[Thomago]

Btw. I came across another weird thing: When setting the mini to DVI it seems to have different Gamma/Blacklevel settings, even with the same values. Can anybody confirm that?

Yep, here. I think that's because in DVI mode the Mini always outputs RGB.

[12345]

Btw. I came across another weird thing: When setting the mini to DVI it seems to have different Gamma/Blacklevel settings, even with the same values. Can anybody confirm that?

Yep, here. I think that's because in DVI mode the Mini always outputs RGB.

I'm not sure, my mini is still on YcBCR when set to DVI. The output seems to be different nevertheless, because when I try rising BLACK (even up to 50) in the mini's settings some pixel areas which would've been turned off/completely dark on HDMI are still partially lit. This effect is very well visible on a Plasma.