|
|
Curious if anyone has insight regarding palette output, as processed through the Sony CXA2025AS US decoder matrix, whether it can be implemented as an option with all the various shader and video filter possibilities currently available for MAME (?)
Vice...
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/video/render2x2ntsc.c
...and puNES...
https://github.com/punesemu/puNES/blob/master/src/video/filters/ntsc.c
...as well as Nestopia (Undead)...
https://github.com/rdanbrook/nestopia/blob/master/source/nes_ntsc/demo.c
...has an option for it.
It is also applied to (forks of) the Gens/Genesis emulator as well as a part of the TwoMBit-Core featuring SMS emulation for OpenEmu.
When selected as a palette option, the color hues are spectacular, nailing the way respective console and computer systems appear when displayed on many highly utilized and popular computer monitors and televisions.
For those interested, the conversion formula (RGB --> YIQ) for this particular decoder matrix is as follows:
Code:
R = Y + 1,630 * I + 0,317 * Q
G = Y - 0,378 * I - 0,466 * Q
B = Y - 1,089 * I + 1,677 * Q
Spec sheet/details are attached.
|
|
|
|
Re: Sony CXA2025AS US
[Re: Trebor]
#353036 - 04/15/16 11:59 PM
|
|
|
EDIT: Nevermind. Now that I'm not on my laptop out in the sun I see that this is pretty bad on a calibrated monitor. But I'm still surprised at how far off the YIQ->RGB formulas are from the standard ones you see everywherw (like wikipedia).
It's interesting how far off these are from the formulas on the YIQ wikipedia page.
If you want to try out this effect now (it might be wrong if we need to do some kind of gamma correction first) you can do the following:
(1)Get the RGB->YIQ matrix from wikipedia.
(2)Get the YIQ->RGB matrix from your post
To get the full RGB->YIQ->RGB you multiply the matrices together in the correct order (YIQ->RGB)*(RGB->YIQ) and use the result in the color convolution section of the hlsl shader. Either the BGFX version or D3D will work. But you'll need to edit the hlsl.json to allow negative slider values.
For example, if I type the matrices into wolframalpha mostly correctly and copy paste the result, the result is:
(1.33737 | -0.025411 | -0.311956
0.17323 | 0.446306 | 0.380464
-0.005481 | 0.031327 | 0.974154)
So
Red from Red = 1.34
Red from Green = -0.025
Red from Blue = -0.0312
Green from Red = 0.173
Green from Green = 0.45
Green from Blue = 0.38
Blue from Red = -0.005
Blue from Green = 0.031
Blue from Blue = 0.97
This would correspond to correctly converted YIQ but then converted back to RGB with your coefficients (barring typos). It does seem to make, for example, the nes output closer to my old crt PVM. The sky is much closer in smb1 anyway. But you might need to play with the gamma settings. And lower saturation if you haven't already. It was set at 150% by default in the bgfx hlsl chain!
> Curious if anyone has insight regarding palette output, as processed through the Sony
> CXA2025AS US decoder matrix, whether it can be implemented as an option with all the
> various shader and video filter possibilities currently available for MAME (?)
>
> Vice...
> https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/video/render2x2ntsc.c
>
> ...and puNES...
> https://github.com/punesemu/puNES/blob/master/src/video/filters/nes_ntsc.c
>
> ...as well as Nestopia (Undead)...
> https://github.com/rdanbrook/nestopia/blob/master/source/nes_ntsc/demo.c
> ...has an option for it.
>
> It is also applied to (forks of) the Gens/Genesis emulator as well as a part of the
> TwoMBit-Core featuring SMS emulation for OpenEmu.
>
> When selected as a palette option, the color hues are spectacular, nailing the way
> respective console and computer systems appear when displayed on many highly utilized
> and popular computer monitors and televisions.
>
> For those interested, the conversion formula (RGB --> YIQ) for this particular
> decoder matrix is as follows:
> R = Y + 1,630 * I + 0,317 * Q
> G = Y - 0,378 * I - 0,466 * Q
> B = Y - 1,089 * I + 1,677 * Q
> Spec sheet/details are attached.
Edited by SoltanGris42 (04/16/16 06:28 AM)
|
|
|
|
Re: Sony CXA2025AS US
[Re: SoltanGris42]
#353052 - 04/16/16 01:18 PM
|
|
|
> EDIT: Nevermind. Now that I'm not on my laptop out in the sun I see that this is
> pretty bad on a calibrated monitor. But I'm still surprised at how far off the
> YIQ->RGB formulas are from the standard ones you see everywherw (like wikipedia).
>
> It's interesting how far off these are from the formulas on the YIQ wikipedia page.
>
> If you want to try out this effect now (it might be wrong if we need to do some kind
> of gamma correction first) you can do the following:
>
> (1)Get the RGB->YIQ matrix from wikipedia.
> (2)Get the YIQ->RGB matrix from your post
>
> To get the full RGB->YIQ->RGB you multiply the matrices together in the correct order
> (YIQ->RGB)*(RGB->YIQ) and use the result in the color convolution section of the hlsl
> shader. Either the BGFX version or D3D will work. But you'll need to edit the
> hlsl.json to allow negative slider values.
>
> For example, if I type the matrices into wolframalpha mostly correctly and copy paste
> the result, the result is:
>
> (1.33737 | -0.025411 | -0.311956
> 0.17323 | 0.446306 | 0.380464
> -0.005481 | 0.031327 | 0.974154)
>
> So
>
> Red from Red = 1.34
> Red from Green = -0.025
> Red from Blue = -0.0312
> Green from Red = 0.173
> Green from Green = 0.45
> Green from Blue = 0.38
> Blue from Red = -0.005
> Blue from Green = 0.031
> Blue from Blue = 0.97
>
>
> This would correspond to correctly converted YIQ but then converted back to RGB with
> your coefficients (barring typos). It does seem to make, for example, the nes output
> closer to my old crt PVM. The sky is much closer in smb1 anyway. But you might need
> to play with the gamma settings. And lower saturation if you haven't already. It was
> set at 150% by default in the bgfx hlsl chain!
Thanks for all the above, including the effort, it is appreciated. The Sony CXA2025AS US decode matrix is definitely something many NTSC(/US) users experience(d).
Absolutely, off the bat, the sky in SMB1 is one of the first noteworthy items, appearing as a 'true blue', rather than the current default of a very 'purple' colored sky.
Having an option, perhaps a command line switch (I.E. -matrix ntscsony) or some other way to have a preset display default, with the correctly converted and assigned attributes, would go a long way in MAME emulating the hue/color output as witnesses under many systems for a considerable portion of the population.
Hopefully, somewhere down the road we'll see it implemented "officially". Thanks, again 
|
|
|
| AWJ |
|
|
|
|
|
|
|
Reged: 03/08/05
|
|
Posts: 936
|
|
Loc: Ottawa, Ontario
|
|
|
|
Send PM
|
|
|
Re: Sony CXA2025AS US
[Re: Trebor]
#353057 - 04/16/16 03:49 PM
|
|
|
NES emulation has been held back for years by people misremembering what SMB1 looks like on real hardware 
https://www.youtube.com/watch?v=FynvXHZ3DZE
(It's a TV commercial for SMB2J, but SMB1 and SMB2J use exactly the same palette)
Yes, the sky really is purple in SMB1. SMB2US is the one with the pure blue sky.
|
|
|
|
Re: Sony CXA2025AS US
[Re: AWJ]
#353059 - 04/16/16 04:43 PM
|
|
|
> NES emulation has been held back for years by people misremembering what SMB1 looks
> like on real hardware
>
> https://www.youtube.com/watch?v=FynvXHZ3DZE
>
> (It's a TV commercial for SMB2J, but SMB1 and SMB2J use exactly the same palette)
>
> Yes, the sky really is purple in SMB1. SMB2US is the one with the pure blue sky.
How the color for that particular palette value is interrupted, through the Sony CXA2025AS US decode matrix, is blue though. This is not from memory, but with actual results under various CRTs.
From the Sony CXA2025AS US decode matrix you receive blue skies under SMB1 - proven when applied accordingly; no (faulty) memories required
P.S. We could try (other) TV commercials too though:
https://www.youtube.com/watch?v=sSgTB-tKrNk
|
|
|
|
Re: Sony CXA2025AS US
[Re: AWJ]
#353061 - 04/16/16 06:25 PM
|
|
|
Yes I only remember it ever being purple. What about tint control? NTSC TVs have to be tint-corrected. Could it be just a matter of people's TVs not being tint-correct? What does a SMPTE test pattern look like with these 'blue sky' TVs?
|
|
|
|
Re: Sony CXA2025AS US
[Re: anikom15]
#353067 - 04/16/16 07:56 PM
|
|
|
> Yes I only remember it ever being purple.
Someone may have not ever seen a blue sky with real hardware for SMB1 if never utilizing: (1) NTSC CRT (2) from the U.S. (3) incorporating the Sony CXA2025AS US decode matrix.
Nonetheless, it is common and popular enough that it has been provide as a palette option for the aforementioned emulators in the OP and others.
It is a known and able to be calculated (a converted) palette interpretation for both consoles and computers. It is not just taking into consideration any person(s) limited memory or experience, but actual fact.
Of course there are those who do recall experiencing or/and currently experience the same with their current hardware setups as well.
Certainly not implying it should be the default palette interpretation; however, considering how far MAME has progressed in providing various possibilities regarding how the end users experiences and views systems being emulated, there is hope this popular decode matrix may make its way into baseline as an option someday.
As a side note, see the below site for a comparison of the purple/blue difference (among other hues) for the C64; since the difference in palette decoding is not just NES specific
http://hitmen.c02.at/temp/palstuff/
|
|
|
|
Re: Sony CXA2025AS US
[Re: Trebor]
#353072 - 04/16/16 08:58 PM
|
|
|
What are these highly popular TV models with these blue skys? When was the CXA2025AS first integrated into TVs? Why is this decoder so special, as opposed to other ICs? Is it because the matrix is different? Every decoder will have a different matrix. It's why NTSC stands for 'Never the Same Color' but you are supposed to use the tint and phase control to get the correct colors (that's why they are there), and I've never seen a TV that couldn't be corrected. The only objective criterion I have seen for how an NTSC television is supposed to look is the NTSC standard itself. To support this standard I can name dozens of consumer-grade television sets that can be tuned (by the consumer) to look pretty damn close to the standard.
MAME already let's you adjust the colors, so if you want shitty colors you can do that now, and keep the save file for personal use, or put it up on your GitHub if you want to help others achieve shitty colors, too, but I don't think it should be an official option since it doesn't seem to be founded on any reality, but is rather a 'this looks kind of like how I remember it so it must be correct' conjecture.
The alternative is to emulate every NTSC IC in MAME, along with the options to control the service parameters like a real TV. This would probably be better served as a separate television emulator.
Edited by anikom15 (04/16/16 09:01 PM)
|
|
|
|
Re: Sony CXA2025AS US
[Re: anikom15]
#353080 - 04/16/16 11:44 PM
|
|
|
> What are these highly popular TV models with these blue skys? When was the CXA2025AS
> first integrated into TVs? Why is this decoder so special, as opposed to other ICs?
> Is it because the matrix is different? Every decoder will have a different matrix.
> It's why NTSC stands for 'Never the Same Color' but you are supposed to use the tint
> and phase control to get the correct colors (that's why they are there), and I've
> never seen a TV that couldn't be corrected. The only objective criterion I have seen
> for how an NTSC television is supposed to look is the NTSC standard itself. To
> support this standard I can name dozens of consumer-grade television sets that can be
> tuned (by the consumer) to look pretty damn close to the standard.
>
> MAME already let's you adjust the colors, so if you want shitty colors you can do
> that now, and keep the save file for personal use, or put it up on your GitHub if you
> want to help others achieve shitty colors, too, but I don't think it should be an
> official option since it doesn't seem to be founded on any reality, but is rather a
> 'this looks kind of like how I remember it so it must be correct' conjecture.
>
> The alternative is to emulate every NTSC IC in MAME, along with the options to
> control the service parameters like a real TV. This would probably be better served
> as a separate television emulator.
Yikes...Wow...Didn't intend for this to get so twisted or bent out of shape. As linked earlier, with the proper calculated formula applied for that Sony matrix, objectively, the setting without tint manipulation, provides a blue sky in SMB1.
It is not a matter of "this looks kind of like how I remember it so it must be correct", but rather what is technical correct and sound when utilizing the 'Sony CXA2025AS US' decode matrix.
Which again, was brought up as perhaps being a possible -option- under MAME for consoles and computers. It is not claiming anything else is inaccurate or incorrect, or the Sony_CXA2025AS US is the only right choice for NTSC US users, while everything else is wrong.
Good grief...dropping this branch now. Beating a dead horse here while spinning my wheels...lol.
|
|
|
|
Re: Sony CXA2025AS US
[Re: Trebor]
#353084 - 04/17/16 01:50 AM
|
|
|
I'm out of town until tomorrow evening and I don't know if I'll have time then.
But it's easy-peasey to write a shader that can (gamma correctly) encode/decode YIQ with whatever matrix you want and provides tint/color controls as well. I could have it let you chose between pre-defined decode matrices and/or let you provide your own.
I can post a modified version of the hlsl.json along with the the new bgfx shaders/effect json files/source here if you want. I can also provide a simpler shader chain that applies only the color corrections without all the other stuff from the hlsl chain.
Are there other matrices besides the standard matrix and the Sony IC that are worth pre-defining? I'll take a look around the interwebs and see.
Of course, I'm not a MAMEDEV (or any dev) so don't expect MAME to adopt it.
> > What are these highly popular TV models with these blue skys? When was the
> CXA2025AS
> > first integrated into TVs? Why is this decoder so special, as opposed to other ICs?
> > Is it because the matrix is different? Every decoder will have a different matrix.
> > It's why NTSC stands for 'Never the Same Color' but you are supposed to use the
> tint
> > and phase control to get the correct colors (that's why they are there), and I've
> > never seen a TV that couldn't be corrected. The only objective criterion I have
> seen
> > for how an NTSC television is supposed to look is the NTSC standard itself. To
> > support this standard I can name dozens of consumer-grade television sets that can
> be
> > tuned (by the consumer) to look pretty damn close to the standard.
> >
> > MAME already let's you adjust the colors, so if you want shitty colors you can do
> > that now, and keep the save file for personal use, or put it up on your GitHub if
> you
> > want to help others achieve shitty colors, too, but I don't think it should be an
> > official option since it doesn't seem to be founded on any reality, but is rather a
> > 'this looks kind of like how I remember it so it must be correct' conjecture.
> >
> > The alternative is to emulate every NTSC IC in MAME, along with the options to
> > control the service parameters like a real TV. This would probably be better served
> > as a separate television emulator.
>
> Yikes...Wow...Didn't intend for this to get so twisted or bent out of shape. As
> linked earlier, with the proper calculated formula applied for that Sony matrix,
> objectively, the setting without tint manipulation, provides a blue sky in SMB1.
>
> It is not a matter of "this looks kind of like how I remember it so it must be
> correct", but rather what is technical correct and sound when utilizing the 'Sony
> CXA2025AS US' decode matrix.
>
> Which again, was brought up as perhaps being a possible -option- under MAME for
> consoles and computers. It is not claiming anything else is inaccurate or incorrect,
> or the Sony_CXA2025AS US is the only right choice for NTSC US users, while everything
> else is wrong.
>
> Good grief...dropping this branch now. Beating a dead horse here while spinning my
> wheels...lol.
|
|
|
|
Re: Sony CXA2025AS US
[Re: Trebor]
#353085 - 04/17/16 02:43 AM
|
|
|
What evidence do you have that it is 'technical correct and sound'? The only information I could find is that this is one IC which happens to have a different matrix from the standard (which is nothing special) and that it so happens that applying the default parameters of it gives the 'blue sky' you seem to prefer for Super Mario Bros.
But the IC itself is configurable, so we can assume that the TV manufacturers would all have their own settings for their particular TVs. So there needs to be some kind of evidence that the 'blue sky' phenomenon is one due to some quirk with certain highly popular TVs, which produces a blue sky regardless of how it's adjusted. I don't think this TV actually exists. I rather like to think that people are either (a) misremembering the sky's color (b) basing it off of unreliable sources like photographs, box shots, &c. (c) did not bother to set their TV tint correctly, which is rather common esp. since the tint could change dramatically just from changing the channel!
There is a difference between something like this, where there is no real data, and perhaps some arcade system that was shipped with a certain type of monitor that had incorrect stretching or cropping or something (this is all hypothetical) that would either be hugely obvious or clearly documented. The truth is, we can't even rely on televisions from the era, because TVs age, and the TV will look rather different now than it did when it was bought, simply due to age. MAME provides a palette based on a standard that was followed close enough so as to be reliable, and it's one that can be pointed to and say 'That's the NTSC standard! That's what NTSC decoders are based on!' and MAME provides all the parameters we need to adjust the colors for individual users' preferences. That's perfect, because we are essentially allowing each user to tune the color to whatever they want, without any bias towards one particular model of TV or another. Because if we are going to throw in this IC's matrix, then what is to stop us from throwing in dozens of others'?
This all comes from a frustration with shitty palettes in FCEUX, a 'yellow boost' feature added to Nestopia which was completely unfounded, and the fact that MAME and Nestopia still have slightly different palettes.
|
|
|
|
Re: Sony CXA2025AS US
[Re: SoltanGris42]
#353104 - 04/17/16 01:11 PM
|
|
|
> I'm out of town until tomorrow evening and I don't know if I'll have time then.
>
> But it's easy-peasey to write a shader that can (gamma correctly) encode/decode YIQ
> with whatever matrix you want and provides tint/color controls as well. I could have
> it let you chose between pre-defined decode matrices and/or let you provide your own.
>
> I can post a modified version of the hlsl.json along with the the new bgfx
> shaders/effect json files/source here if you want. I can also provide a simpler
> shader chain that applies only the color corrections without all the other stuff from
> the hlsl chain.
>
> Are there other matrices besides the standard matrix and the Sony IC that are worth
> pre-defining? I'll take a look around the interwebs and see.
>
> Of course, I'm not a MAMEDEV (or any dev) so don't expect MAME to adopt it.
Very cool and thank you. It is appreciated. It was a passing thought and wondered of the possibilities under MAME, especially considering other highly regarded emulators, such as Vice and Nestopia - which for several years contain video tweaking options including tint/hue control, saturation, brightness, contrast, etc., yet offer up the Sony CXA2025AS US decode matrix as an alternative relatively recently.
No other additional decode matrix for NTSC - either 'NTSC' or the 'NTSC Sony US' one appear to be present at this time that I am aware of; at the very least, none of which that has received the attention and consideration of "Sony CXA2025AS US".
Perhaps it is significant enough to warrant such an inclusion to MAMEDev, especially when understanding to simulate something similar under MAME, per your other excellent reply earlier, is evidently more than just a hue or saturation control adjustment.
The 'base' hues are indeed considerably different, the sky in SMB1 being one of the most obvious examples; additionally, contrasting color differences in the ground and pillars in Rygar, and skin tones in Double Dragon, are among a plethora of other noticeable hue base changes between 'NTSC' and 'NTSC Sony US'.
All adjustments cannot be aligned properly with the aforementioned typical consumer adjustment controls [Hence, the need for inclusion of this alternate decode matrix ]. One area may be tweaked, but it will throw off another due to these 'base' differences.
Regardless of the outcome, thank you again for your time and consideration.
|
|
|
|
|
Hi again,
Sorry for the delay. Super busy at work. I'm attaching a zip file with a shader called "yiqcolor" that just encodes an RGB color as YIQ using the standard matrix, applies tint/saturation adjustment, and then takes it back to RGB.
It has presets for the wikipedia YIQ->RGB formula as well as coefficients for the FCC standard, the Sony US matrix you posted, a different Sony YUV matrix, and a custom one that you can define in the shader. Probably most formulas you could find online are just a phase shift away from the standard, but that's fine.
The ZIP file contains a "bgfx" folder that you can merge with the bgfx folder in MAME 0.172. Then you can try out the effect with either the included "hlsl_yiq_tweak" or "yiqcolor" bgfx shader chains.
NOTE: It will stop working with 0173 since MooglyGuy has made a lot of changes to bgfx since 0172.
The shader chain, "hlsl_yiq_tweak", is just the standard hlsl shader chain with the color effect replaced with this and different defaults.
The shader chain, "yiqcolor", is just the color effects and nothing else.
I also included the shader source, as simple as it is.
-greg
> Curious if anyone has insight regarding palette output, as processed through the Sony
> CXA2025AS US decoder matrix, whether it can be implemented as an option with all the
> various shader and video filter possibilities currently available for MAME (?)
>
> Vice...
> https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/video/render2x2ntsc.c
>
> ...and puNES...
> https://github.com/punesemu/puNES/blob/master/src/video/filters/ntsc.c
>
> ...as well as Nestopia (Undead)...
> https://github.com/rdanbrook/nestopia/blob/master/source/nes_ntsc/demo.c
> ...has an option for it.
>
> It is also applied to (forks of) the Gens/Genesis emulator as well as a part of the
> TwoMBit-Core featuring SMS emulation for OpenEmu.
>
> When selected as a palette option, the color hues are spectacular, nailing the way
> respective console and computer systems appear when displayed on many highly utilized
> and popular computer monitors and televisions.
>
> For those interested, the conversion formula (RGB --> YIQ) for this particular
> decoder matrix is as follows:
> R = Y + 1,630 * I + 0,317 * Q
> G = Y - 0,378 * I - 0,466 * Q
> B = Y - 1,089 * I + 1,677 * Q
> Spec sheet/details are attached.
Edited by SoltanGris42 (04/19/16 09:08 AM)
|
|
|
|
Re: Sony CXA2025AS US
[Re: SoltanGris42]
#353203 - 04/19/16 01:03 PM
|
|
|
> Hi again,
>
> Sorry for the delay. Super busy at work. I'm attaching a zip file with a shader
> called "yiqcolor" that just encodes an RGB color as YIQ using the standard matrix,
> applies tint/saturation adjustment, and then takes it back to RGB.
>
> It has presets for the wikipedia YIQ->RGB formula as well as coefficients for the FCC
> standard, the Sony US matrix you posted, a different Sony YUV matrix, and a custom
> one that you can define in the shader. Probably most formulas you could find online
> are just a phase shift away from the standard, but that's fine.
>
> The ZIP file contains a "bgfx" folder that you can merge with the bgfx folder in MAME
> 0.172. Then you can try out the effect with either the included "hlsl_yiq_tweak" or
> "yiqcolor" bgfx shader chains.
>
> NOTE: It will stop working with 0173 since MooglyGuy has made a lot of changes to
> bgfx since 0172.
>
> The shader chain, "hlsl_yiq_tweak", is just the standard hlsl shader chain with the
> color effect replaced with this and different defaults.
>
> The shader chain, "yiqcolor", is just the color effects and nothing else.
>
> I also included the shader source, as simple as it is.
>
> -greg
>
Excellent; the stab at it is once again appreciated...Thank you, Greg!
|
|
|
|
Index 
Threaded 
Sony CXA2025AS US
Reply
[Re: 
