Page 2 of 7

Re: PAL color palette emulation

Posted: Tue May 12, 2015 3:17 pm
by tepples
Some imported TVs worked around Telefunken's delay line patent by decoding sorta-NTSC-style, just inverting the V carrier's phase from line to line. These rely on the eye to do the chroma subsampling.

Re: PAL color palette emulation

Posted: Wed May 13, 2015 7:36 am
by feos
doesn't do any vertical chroma subsampling
I'm sorry, but the video he posted does have a ton of subsampling, just not with gray, white or black.

I can tweak the option in any way, I just need some insight on what it should not do. If it's even known.

Re: PAL color palette emulation

Posted: Wed May 13, 2015 7:55 am
by lidnariq
feos wrote:I'm sorry, but the video he posted does have a ton of subsampling, just not with gray, white or black.
"Not doing subsampling against grey" means it's not doing subsampling at all. It can't be conditional: televisions from before the 1980s were too simple for such logic.

In any case, please point out what you see that makes you think it's selective. As near as I can tell, the capture card is doing something weird with how it calculates the phase of the colorburst, producing the weirdly different colors from scanline to scanline. (My best guess is that it's using a 1 scanline delay line instead of 64µs to calculate U/V phase ... or vice versa.)

Re: PAL color palette emulation

Posted: Wed May 13, 2015 8:01 am
by feos
In any case, please point out what you see that makes you think it's selective.
Pictures like this:
download/file.php?id=1950&mode=view

I just thought, since black, white and gray are 0 chroma, merging them wasn't intended. However, there's now more evidence that it should be done in 100% cases, right?

Re: PAL color palette emulation

Posted: Wed May 13, 2015 8:14 am
by lidnariq
feos wrote:However, there's now more evidence that [chroma subsampling] should be done in 100% cases, right?
Yes. It'll just produce out-of-gamut values when subsampling through pixels of white or black. (When you transform YUV with {Y=0, U=nonzero, V=nonzero} to RGB, you get some negative values for the result.)

Re: PAL color palette emulation

Posted: Wed May 13, 2015 8:51 am
by feos
Well, we're sliding down to what happens on devices, while my goal it simulating the effect. For maximum speed, I use lookup tables whenever I can, and for chroma presence in a color (by index) too. And then, by original chroma presence, I determine if I should blend or not. If I determine it on fly doing the conversion to RGB from YUV, fps will drop to 20- because of fractions.

Probably there lies a problem with too heavy blending clearly visible in some games if I blend RGB 50/50. If done at runtime only with U and V, maybe it'd look more accurate.

Re: PAL color palette emulation

Posted: Wed May 13, 2015 9:17 am
by lidnariq
That could explain your problems... luma is not supposed to be subsampled at all.

Re: PAL color palette emulation

Posted: Wed May 13, 2015 9:31 am
by feos
It's not that simple. There's palettetranslate array in fceux, that contains values as for what RGB color to use per color index. I parse it all, convert to YUV, calculate subcarrier mask, apply it for where U or V are not zero, convert the results (16 variants per color) to RGB, and then at runtime decide what to pick by an index that comes from the main buffer (XBuf), figure out that moire phase should be used, and immediately pick the needed color. Can go up to 600fps on my old machine.

THEN, I precalculate an array of bools that tell me what color has chroma in it, and at runtime look that up too, and if there was no chroma in a color per initial conversion, I don't blend it.

Possible options: blend only if both have chroma, blend if at least on has chroma, blend always, blend never.

But as I said, blending by RGB values might be wrong compared to blending by YUV. Sadly, I can't make a lookup for that too, too many options. Or can I?

Re: PAL color palette emulation

Posted: Tue Jun 02, 2015 6:41 am
by HardWareMan
I would like to add to this topic a little bit of technical information. As you already know, PPU has no any palette, it generate NTSC or PAL signal natively. It is possible because of the fundamentals of coding those color systems. PPU generate 12 different subcarrier phases for color range (color number from x1 to xC). All next info will refer to the following picture (NES palette ROM) and PAL PPU (basically clone):
Image
I would like to remind you that video DAC is resistor chain. It can generate only 11 voltage levels (include 0V), so luma variants are very limited. You can search this research in this forum, I don't remember what that thread was.

Code: Select all

LEVEL :  SYNC : BURST : LUMA0 : LUMA1 : LUMA2 : LUMA3 :
 VCC  :       :       :       :       :       :       :
 L10  :       :       :       :       :       :       :
 L09  :       :       :       :       :   H   :   H   :
 L08  :       :       :       :       :   |   :   L   :
 L07  :       :       :       :   H   :   |   :       :
 L06  :       :       :   H   :   |   :   |   :       :
 L05  :       :       :   |   :   |   :   L   :       :
 L04  :       :   H   :   |   :   |   :       :       :
 L03  : - H - : - | - : - | - : - L - : - - - : - - - : < BLACK LEVEL
 L02  :   |   :   |   :   L   :       :       :       :
 L01  :   |   :   L   :       :       :       :       :
 GND  :   L   :       :       :       :       :       :
As you can see, there is only 6 types of signal. Each type has High and Low level. All except SYNC can oscillate between those levels. L10 connected to emphasise logic and don't will discussed here. So, I've look at oscilloscope and what I was discovered.
Image
This is one screen capture. Legend:
Channel 1 (yellow) is composite signal.
Channel 2 (cyan) is -(B-Y) signal form PAL decoder, based on TDA3510.
Channel 3 (magenta) is -(R-Y) signal from PAL decoder.
So, each color row (for each luma) starts with H level (index x0), goes through 12 hues by oscillating between H and L (indexes x1 - xC) and ends with L level (index xD). 0x row has L level lower than black level, so you notice it on the screen (for example in Super Robin Hood game from Codemasters).

Important thing: oscillating between two levels creates new luma value, which is always average for H and L levels. It noticeable with notch subcarrier filter turned on or on the eye from a distance from TV. Since, subcarrier always has duty cycle 50% average level is (H+L)/2. This level will used for RGB calculating.

I has made many measurement of absolute levels by scope and got this preliminary results:

Code: Select all

0: R-Y     +0.25V +0.04V -0.17V -0.29V -0.37V -0.35V -0.19V -0.18V +0.09V +0.21V +0.36V +0.38V   amplitude -0.35V ... +0.38V  delta 0.73
0: B-Y     -0.52V -0.65V -0.59V -0.40V -0.05V +0.22V +0.55V +0.60V +0.65V +0.54V +0.22V -0.07V   amplitude -0.59V ... +0.65V  delta 1.24

1: R-Y     +0.48V +0.25V -0.07V -0.34V -0.53V -0.57V -0.43V -0.26V +0.13V +0.32V +0.55V +0.59V   amplitude -0.57V ... +0.59V  delta 1.16
1: B-Y     -0.61V -0.93V -0.98V -0.76V -0.30V +0.11V +0.70V +0.92V +0.98V +0.82V +0.32V -0.13V   amplitude -0.93V ... +0.98V  delta 1.91

2: R-Y     +0.56V +0.27V -0.07V -0.37V -0.60V -0.65V -0.50V -0.13V +0.32V +0.53V +0.67V +0.62V   amplitude -0.65V ... +0.67V  delta 1.32
2: B-Y     -0.68V -1.04V -1.10V -0.87V -0.34V +0.14V +0.80V +1.15V +1.05V +0.77V +0.14V -0.39V   amplitude -1.10V ... +1.15V  delta 2.25

3: R-Y     +0.27V +0.15V -0.03V -0.18V -0.29V -0.31V -0.23V -0.07V +0.16V +0.25V +0.32V +0.31V   amplitude -0.31V ... +0.32V  delta 0.63
3: B-Y     -0.34V -0.50V -0.53V -0.41V -0.15V +0.09V +0.41V +0.57V +0.52V +0.38V +0.07V -0.19V   amplitude -0.53V ... +0.57V  delta 1.10

    LEVE L  :  SYNC : BURST : LUMA0 : LUMA1 : LUMA2 : LUMA3 :
 VCC  ????? :       :       :       :       :       :       :
 L10  ????? :       :       :       :       :       :       : FULL CLAMP
 L09  1.20V :       :       :       :       :   H   :   H   : 100% 100%
 L08  0.87V :       :       :       :       :   |   :   L   :  72%  88%
 L07  0.84V :       :       :       :   H   :   |   :       :  70%  85%
 L06  0.54V :       :       :   H   :   |   :   |   :       :  45%  55%
 L05  0.48V :       :       :   |   :   |   :   L   :       :  40%  48%
 L04  0.41V :       :   H   :   |   :   |   :       :       :  34%  41%
 L03  0.22V : - H - : - | - : - | - : - L - : - - - : - - - :  18%   0% < BLACK LEVEL
 L02  0.16V :   |   :   |   :   L   :       :       :       :  13%
 L01  0.15V :   |   :   L   :       :       :       :       :  12%
 GND  0.00V :   L   :       :       :       :       :       :   0%
In order to facilitate the perception of the data I have built a graph:
Image
Very noticeable that fact what luma0 very similar to luma3 and luma1 very similar to luma2. If I eliminate some possible measurement errors I've got this kind of graph:
Image
So, it's a sine shaped signal. that is true: 12 phase is 30 degrees vectors. And also very noticeable that fact what R-Y shifted by 90 degrees to the B-Y. This is normal for PAL when you make linear shift subcarrier phase by 30 degrees.

In the end I able to measure phase of each color but I don't see meaning in it. You can synthesize any of R-Y/B-Y and luma levels, scale them (R-Y/B-Y scaling is saturation control and luma scaling is contrast control) and mix them up to result RGB values, with the simple addition and subtraction, as is done by electronics devices.

Discuss.

Re: PAL color palette emulation

Posted: Tue Jun 02, 2015 8:33 am
by tepples
So you're simultaneously measuring the NES and the TDA3510. In order to eliminate the TDA3510's behavior from the equation, it might be best to take phase measurements directly on the composite signal. Particularly, I'd like to see phase of the composite signal during color burst and each color for odd and even scanlines. That way an emulator can choose to implement either Telefunken decoding (mixing chroma with that from a 64 us delayed signal) or the most common workaround for Telefunken's patent (taking into account the signaling in the burst and otherwise decoding each line independently, which is more subject to Hanover bars).

Re: PAL color palette emulation

Posted: Tue Jun 02, 2015 9:32 am
by HardWareMan
tepples wrote:So you're simultaneously measuring the NES and the TDA3510. In order to eliminate the TDA3510's behavior from the equation, it might be best to take phase measurements directly on the composite signal. Particularly, I'd like to see phase of the composite signal during color burst and each color for odd and even scanlines. That way an emulator can choose to implement either Telefunken decoding (mixing chroma with that from a 64 us delayed signal) or the most common workaround for Telefunken's patent (taking into account the signaling in the burst and otherwise decoding each line independently, which is more subject to Hanover bars).
In TDA3510 case there is merging. It's very noticeable at neighbor scanlines with different color. Unlike NTSC, PAL subcarrier multiple to scanlines. That why PAL PPU has "dot crawl" but they don't crawl and stay steady. Full period is 6 scanlines:
Image
So, there is 6 different phases of subcarrier relative to sync. Of course this doesn't matter to color decoding. Here 6 scanlines in a row:
Image

Re: PAL color palette emulation

Posted: Sun Jun 14, 2015 1:39 am
by feos
Since it's related here, as my intent is to emulate it, I'll answer to this here:
lidnariq wrote:Anyway, the bit where "black" and "white" appear to not suffer from chroma subsampling happens because the subsampling only happens on the U and V components, and out of gamut colors are clipped back into gamut.

Say you had a screen full of alternating scanlines of
- black (Y=U=V=0) and
- yellowish (Y=0.5, U=-0.5, V=0)

Chroma subsampling would turn those into:
- black (Y=0, U=-0.25, V=0)
- greyish-yellow (Y=0.5, Y=-.25, V=0)

Then when you convert those to RGB values to drive the (conceptual) electron beams with, you'd get
- black (R=0, G=0.098, B=-0.483) which is probably clamped to (R=0, G=0.098, B=0) (#001B00)
- greyish-yellow (R=0.5, G=.598, B=0.017) (#809804)

And I'm skipping gamma correction, because that's a pain. But it doesn't affect U and V values, just Y and the colorspace transformation.


I understand that you're trying to figure out how to do something equivalent given RGB input and lookup tables, and to first-order approximation is seems like white and black are just not affected, but I'm just not all that certain that you can do this accurately without converting back to YUV.
Exactly. Now we have a proof that it even happens to white.

Here's a 2-color cloud the way the game renders it.
Image

Here's a super detailed shot of it on TV:
http://i.imgur.com/HJHv6TM.jpg

Watch how red comes into play between white and blue (creating gray)!

Re: PAL color palette emulation

Posted: Sun Jun 14, 2015 6:31 am
by tepples
feos wrote:Here's a super detailed shot of it on TV
403 Forbidden

Re: PAL color palette emulation

Posted: Sun Jun 14, 2015 10:30 am
by feos
Fixed.

Re: PAL color palette emulation

Posted: Thu Jul 23, 2015 10:27 am
by r57shell
Trying to make RGB->CVBS->CRT->RGB filter, to simulate CRT linked by composite video.

ATM made some SVideo part...
https://gist.github.com/realmonster/23a ... d50e859f09

Stucked on low-pass filters.
Can't figure out how to simulate low-pass filters
1) there are many of them, what exactly to choose? Ofc I need some of those that is comming in analog TV (CRT)
2) even if I have schematics, actually I don't need schematics or characteristics itself. For example for many filters there is bode diagram, step-response analysis, phase shift etc... But I need V-in - > V-out function. I saw for example V-out(s)/V-in(s) = f(...) where ... is capacitors, resistors.
For example for simple RC-circuit there is formulae V-out(s)/V-in(s) = 1/(1+jwRC). For me it looks like right side is constant for appropriate RC and w. When it comes to changing w, all messed up.

Best that I found was formulae from Wikipedia y = x*a + (1-a)*y[i-1]
but it's not enough for me too... I want non-discrete function, to be able integrate. This one is based on samples. Maybe I just don't understand something.

Also, from question that I need to solve... when TV decoding UV from composite signal...
1) does it decode UV straight from N (composite signal), or does it decode UV from N-Low_pass(N,3.5MHz), or maybe from High_pass(N,3.5MHz). (frequency is just some random chosen because I don't remember exact value)
2) Any analog low-pass filter introduces delay in signal, so does it synced after? (UV with Y)

I don't have CRT nor NES, so I can mistake everywhere :)