Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Post by Dwedit »

Wiki has this illustration: https://www.nesdev.org/wiki/File:Nes_nt ... anline.gif

Image

In this illustration, there are ragged edges on all vertical lines, regardless of whether they are color or monochrome. This is from using a 12-step square wave pattern.
But this is wrong. Monochrome vertical lines do not have ragged edges.


Here is a screenshot of a Mega Man 1 capture (From Arcus on Twitch)
megaman_1_gutsman.jpg
Enlarge the image and look closely at the three energy bars. The bar for the weapon energy and boss's life have a periodic ragged edge pattern that repeats every 3 bars. The life energy does not have a ragged edge.
Also the metal girder tiles do not have a ragged edge.

Another screenshot:
megaman_1_bombman_stage.jpg
The sky color against the black outline of the ladder has ragged edges. The white rungs of the ladder against the black outline do not have ragged edges.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
rainwarrior
Posts: 8733
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Post by rainwarrior »

I think that depends on the decoder.

For example, take a look at the capture image in my NTSC pattern torture test demonstration. There we can clearly see the colour artifacts affecting monochrome material.

However I do find on my LCD TV, those artifacts tend to be suppressed for white against black like that, at least if there is enough space between them.

I don't know how it decodes differently, but it does seem that some have a way of filtering that improves the monochrome case.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Post by lidnariq »

Just checked on my CRT SDTV with a copy of SMB3 - the chroma artifacts are definitely visible on the black and white tiles at the bottom of the title screen, although much more subdued than in Bisqwit's emulator.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Post by NewRisingSun »

There are two artifacts occurring at the same time in the vicinity of vertical lines: cross-luma, and cross-color.

Cross-luma artifacts occur because chroma information is incorrectly decoded as luma. Accordingly, they only occur during colorful vertical lines, not white or gray ones. Vertical lines will look "ragged":
| |-> / |
| |-> / |
| |-> / |
| |-> / |
NES video is more prone to exhibiting cross-luma artifacts than broadcast video: The NES PPU generates the luma and chroma components of the video waveform in the same circuit. This means that chroma cannot be properly filtered as the NTSC standard calls for. Without this filtering, chroma components exist in frequency bands in which they should not exist, and therefore, the TV's composite decoder decodes them as luma. White vertical lines on the other hand never look "ragged" because they lack chroma information that could be mis-decoded as luma.

Cross-color artifacts occur because luma information is incorrectly decoded as chroma. Since every part of the picture necessarily has a luma component, cross-luma artifacts will occur on any sharp transition from bright to dark or vice-versa. Because the PPU's scanline length is such that the end of a scanline does not coincide with a full color subcarrier cycle but with one third of it, at a given horizontal position within the scanline, the color produced by cross-color artifacts changes from scanline to scanline but repeats every three scanlines:
| -> |
| -> |
| -> |
| -> |
| -> |
| -> |
Broadcast NTSC's scanline length is such that the end of a scanline coincides with half a color subcarrier cycle, resulting in a two- rather than a three-scanline cross-color artifact repetition pattern.

Because cross-color artifacts are a greater problem in broadcast NTSC than cross-luma artifacts, composite decoders invest a greater effort in reducing cross-color artifacts than cross-luma artifacts. One way of reducing cross-color artifacts is to average the chroma information across several scanlines, and therefore across phases of the color subcarrier cycle, which results in retaining the intended chroma information while cancelling out the cross-color artifacts if the picture content across the several scanlines is sufficiently similar. This method is awkwardly referred-to in the literature as a "comb filter". I say "awkwardly" because the name comes from the frequency plot of a signal being mixed with a delayed version of itself looking like a comb. Yet this property is entirely irrelevant to the intuitive understanding of what is actually done, why it is done and why and when it works as intended.

If your TV or capture card has a well-working "comb filter", it will reduce or even remove cross-color artifacts, resulting in perfectly white-looking vertical lines. It could also be that a TV's chroma decoder is attuned to the scanline length of broadcast NTSC, and will perform not at all or poorly with the non-standard scanline length of NES video.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Issue with NTSC video wiki illustration - Monochrome edges should not be ragged

Post by psycopathicteen »

TVs that use digital NTSC composite decoders, does anyone know how many multiplications per second those things do? If they're using a Hamming-Sinc filter with a cutoff at 3.13 Mhz and a stop band frequency at 3.58 Mhz, I calculated the FIR filter will be 24 NES pixels long. If the chip is processing the composite video at 14.32 Mhz, then the FIR filter will be 64 pixels long, and since FIR filters are symetrical that would take 32 multiplications per pixel at 14.32 Mhz, which would result in 458.18 million multiplications per second.
Post Reply