It is currently Sun Oct 22, 2017 7:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Mon Sep 21, 2015 11:17 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
Beyond what's written in the wiki page, how best to explain it to you depends on what concepts you already understand. Are you familiar with the concepts of YUV color space and quadrature amplitude modulation (QAM)?


Top
 Profile  
 
PostPosted: Mon Sep 21, 2015 11:35 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
Sure, this is how I did moire.
https://sourceforge.net/p/fceultra/code ... t.cpp#l634
https://sourceforge.net/p/fceultra/code ... t.cpp#l469

I know that fringing occurs because notch filter can't properly recognize luma from chroma (if tweaked wrong), which are not very separated in the signal. But not what color depends on what position and what luma change. And wether it depends on luma going up or down.


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 1:40 pm 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
tepples wrote:
Beyond what's written in the wiki page, how best to explain it to you depends on what concepts you already understand. Are you familiar with the concepts of YUV color space and quadrature amplitude modulation (QAM)?

Now as Bisqwit has told me the principle behind fringing, I understand it a bit better, but still have questions. On that page it's said that NES generates 8 samples per pixel, and decoder expects 12. Does it mean decoder fetches 4 more samples to generate every pixel, and so it gets a few samples from the following pixel, mixing their colors because of that? Then it would make sense how rainbow colors depend on position on screen and on colors it appears between. But then, how does that concern luma level change, if at all?


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 1:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
feos wrote:
On that page it's said that NES generates 8 samples per pixel, and decoder expects 12. Does it mean decoder fetches 4 more samples to generate every pixel, and so it gets a few samples from the following pixel, mixing their colors because of that?
Bisqwit's write up is an approximation that is closer to right than to wrong.

A real NTSC decoder does not use a 12-sample "boxcar" bandpass filter. Either it uses explicit demodulation followed by a lowpass filter, or it uses a bandpass filter that's much longer than 12 samples)

Quote:
How does that concern luma level change, if at all?
Luma is decoded by re-modulating the U & V components and subtracting those from the received composite video. (Since composite = luma + chroma, theoretically composite - chroma = luma)


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 1:58 pm 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
Which of those filters is notch? I've heard it's not applied to S-Video signal, so we can see full subcarrier there, and there's also fringing too. Note that fringing/rainbow effect was my initial question a page earlier.

Image


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 2:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
The end result of demodulating chroma, filtering it, remodulating it, and subtracting that from luma produces an effective notch filter on the luma signal.


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 2:06 pm 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
My point is, notch/lowpass is probably not a reason to fringing like on the picture above.


Top
 Profile  
 
PostPosted: Tue Sep 29, 2015 2:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
Hmm, I think that looks like an overly exaggerated luma-into-chroma chrosstalk... ?

Three NTSC NES pixels = two NTSC color periods, so an area has to be at least NTSC NES pixels wide before it even theoretically could reach steady-state.

And, uh, six PAL NES pixels = five PAL color periods, so an area probably has to be at least six PAL NES pixels wide to reach steady state.


Top
 Profile  
 
PostPosted: Wed Sep 30, 2015 9:46 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
Right, I tweaked the tuner so that the colors are the most visible. Inability to reach steady state doesn't look like a reason either, because there's no need for the color to appear only shortly to generate rainbow. It occurs on borders of huge solid blocks of black/white/gray too. Color depends on horizontal position of the border, but I'm not a ROM hacker to showcase that too.

Image


Top
 Profile  
 
PostPosted: Wed Sep 30, 2015 10:22 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
IF you're doing composite demodulation (and not s-video), that's correct. The exact horizontal position of the transition will produce color artifacts.

(The receiver cannot know where the pixel edges are, so it's hard to distinguish between a true chroma signal and some other random sharp edge. That said, later televisions started using more and more sophisticated algorithms to separate luma from chroma. Later than the NES, anyway.)


Top
 Profile  
 
PostPosted: Sat Oct 03, 2015 4:11 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
lidnariq wrote:
feos wrote:
On that page it's said that NES generates 8 samples per pixel, and decoder expects 12. Does it mean decoder fetches 4 more samples to generate every pixel, and so it gets a few samples from the following pixel, mixing their colors because of that?
Bisqwit's write up is an approximation that is closer to right than to wrong.

A real NTSC decoder does not use a 12-sample "boxcar" bandpass filter. Either it uses explicit demodulation followed by a lowpass filter, or it uses a bandpass filter that's much longer than 12 samples)

Let's abstract from filtering for a moment. While generating those 8 samples per pixel, does NES resume generating the following 4 during the next pixel, or it just cuts the previous signal period and starts the next one?

Like, does a triplet of solid color pixels look like that

Code:
|00 01 02 03 04 05         |         03 04 05 06 07 08|                  06 07 08|
|                  06 07 08|00 01 02                  |00 01 02 03 04 05         |


or like that

Code:
|00 01 02 03 04 05         |00 01 02 03 04 05         |00 01 02 03 04 05         |
|                  06 07 08|                  06 07 08|                  06 07 08|


Judging by tuner screenshots, it's the former, with each pixel getting the average value between the 2 levels depending on their presence. Used SVideo output to get rid of notch. Maybe the numbers need an amendment considering PAL standard for that particular picture, but the question I'm asking will generally work for both.

Image


Top
 Profile  
 
PostPosted: Sat Oct 03, 2015 11:10 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
feos wrote:
While generating those 8 samples per pixel, does NES resume generating the following 4 during the next pixel, or it just cuts the previous signal period and starts the next one?
[...]
Maybe the numbers need an amendment considering PAL standard for that particular picture, but the question I'm asking will generally work for both.
Yes, both the 2C02 and 2C07 do not restart phase on a pixel border. The 2C02 generates 8 samples; the 2C07 generates 10. The chroma modulation frequency for both video standards corresponds to 12 samples.


Top
 Profile  
 
PostPosted: Sun Oct 04, 2015 11:13 pm 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
feos wrote:
Like, does a triplet of solid color pixels look like that

Code:
|00 01 02 03 04 05         |         03 04 05 06 07 08|                  06 07 08|
|                  06 07 08|00 01 02                  |00 01 02 03 04 05         |


Since color subcarrier generator works independently to video generator, the solid color area will be like above. But as the size and position of each pixel is not a multiple of the color subcarrier then be the duty cycle distortion of the color subcarrier at the boundaries of two different colors.
Code:
|00 01 02 03 04 05         |00 01 02 03               |
|                  06 07 08|            04 05 06 07 08|

Hint: to study the effect of the position of a pixel on a fringing make a ROM, which will gradually be shifted pixel by pixel black and white border with maximum difference (between colors 0x0D and 0x30). Moreover, in three different versions: black-white, white-black, black-white-black. You can do it without using sprites: just use to solid B&W symbols and 8 symbols with different vertical variants of B&W pixels, using last ones on edge in name table. And joypad control for changing pixel edge position.


Top
 Profile  
 
PostPosted: Sun Oct 04, 2015 11:34 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
Correct.

Tepples wrote a test (tvpassfail) that specifically abuses this beat pattern to make the color disappear. It works by taking three colors at phases offset by 4 columns (e.g. shades $11, $15, and $19) and making a simple repeating pattern out of it (over 9 total tiles for a 24x24 pixel repeat).

When the phase restarts every pixel, the result has frequency content only at multiples of 1/2 of the pixel rate, i.e. 2.7MHz, 5.4MHz, 8.1MHz, and 10.7MHz, so there's no decoded chroma signal.


Top
 Profile  
 
PostPosted: Thu Oct 08, 2015 10:06 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
I finally emulated the correct subcarrier view using all the formulas, but I still have one huge suspicion: that next color is guessed by the decoder only at the first subcarrier peek. This is hard to determine on tuner screenshots due to blending, but it looks like the only reason to have saw-like edges. It also happens on NTSC, but there full vertical subcarrier cycle is 3 pixels, while it's 6 on PAL, so the former case looks more aggressive.

Image

Image

At first I thought that filtering edges only partially was the reason, but it really looks like it's not just that.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: tepples and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group