It is currently Sun Dec 17, 2017 1:23 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
 Post subject:
PostPosted: Mon Feb 20, 2006 6:51 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
When you post these huge PNGs, it's best to convert them to 256 colors without dithering.


I didn't want to introduce any artifacts that could affect comparison. Obviously if I wanted small images, I'd use JPEG.

Quote:
Which leads to another obvious way to detect the emulator image: it is much smaller because it has less noise.


I guess we'll need to add in some hard-to-compress noise for a Turing Test-style comparison. But comparing image sizes is one example of using tools to detect differences, which goes beyond the visual test.

The main point of the two images was that the NTSC filter is now nearly the same as video capture.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2006 8:09 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 330
Jagasian wrote:
NTSC artifacting is a necessity for perfecting the accuracy of NES emulation to the point where it could pass a "Turing-test" like experiment with a real NES.
A "Turing test"? Now there's a toy if there ever was one. Also, you'll never pass a Turing test unless you can get your TV-out card to output a non-interlaced signal.
Quietust wrote:
That, and the off-center horizontal blanking.
The off-center blanking is how the PPU operates. It's 15 overscan pixels to the left and 11 to the right. The emulated picture does not reflect that because of Blargg's 7/8 instead of 40/47 ratio.
Blargg wrote:
since my field merging reduces the luma-chroma crosstalk (as tepples said before, this is a 3D comb filter, to some extent).
If you're only merging fields, it's a 2D comb filter. A 3D filter would require you to merge fields as well as lines.
Blargg wrote:
That's the definitive sign, my video capture's likely notch filter blending some of the previous scanline's chroma signal.
It's probably not a notch filter, but a two-line comb filter which does that.

What I'm more surprised at is that both in the emulated and the video-captured pictures, there are still some slight diagonal stripes visible in the solid blue.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2006 8:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
Jagasian wrote:
NTSC artifacting is a necessity for perfecting the accuracy of NES emulation to the point where it could pass a "Turing-test" like experiment with a real NES.
A "Turing test"? Now there's a toy if there ever was one. Also, you'll never pass a Turing test unless you can get your TV-out card to output a non-interlaced signal.

Unless your computer's TV-in card is considered part of the NES cabling for purposes of the test.

NewRisingSun wrote:
Quietust wrote:
That, and the off-center horizontal blanking.
The off-center blanking is how the PPU operates. It's 15 overscan pixels to the left and 11 to the right.

That's odd, as it would seem to make some horizontal-mirrored games even more off-balance (23 to the left and 11 to the right). Now we know why Super Mario Bros. 3 shoved its attribute artifacts to the right side.

NewRisingSun wrote:
The emulated picture does not reflect that because of Blargg's 7/8 instead of 40/47 ratio.

Using DirectX to scale with your video card's hardware linear interpolation could help hide this.

NewRisingSun wrote:
Blargg wrote:
since my field merging reduces the luma-chroma crosstalk (as tepples said before, this is a 3D comb filter, to some extent).

If you're only merging fields, it's a 2D comb filter. A 3D filter would require you to merge fields as well as lines.

So-called Wolfenstein 3D didn't have any action in the up-and-down dimension.

NewRisingSun wrote:
It's probably not a notch filter, but a two-line comb filter which does that.

A comb filter with zeroes above Fs/6 is the same thing as a notch filter, as it has only one relevant zero.

NewRisingSun wrote:
What I'm more surprised at is that both in the emulated and the video-captured pictures, there are still some slight diagonal stripes visible in the solid blue.

Imperfect chroma-luma separation is probably the culprit. I've seen those stripes when playing NES through a black-and-white TV.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 4:28 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 330
tepples wrote:
Imperfect chroma-luma separation is probably the culprit.
But that shouldn't happen in solid areas.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 8:24 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
tepples wrote:
Imperfect chroma-luma separation is probably the culprit.
But that shouldn't happen in solid areas.

Ideally. But in the real world, we have real filters, which are real imperfect.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 9:27 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 330
tepples wrote:
NewRisingSun wrote:
tepples wrote:
Imperfect chroma-luma separation is probably the culprit.
But that shouldn't happen in solid areas.
Ideally.
No, not ideally, realistically. The original code doesn't produce them, and neither do my TV and TV card.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 1:57 pm 
Offline

Joined: Wed Feb 09, 2005 9:31 am
Posts: 418
blargg,

Can you fix the mentioned bugs and post links to two new screenshots? I am eager to see if your emulator can make screenshots that can fool the expert eyes around here that weren't fooled by the first pair of screenshots. An observable equivalence test has to start somewhere and screenshots seem to be a good objective way to measure. Once an emulator can pass the screenshot test, then we can debate about what constitutes a better test. A set of screenshot pairs could be very convincing that this is more important than other types of pixel filters.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 1:03 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I've got the colors very close to what my video capture gives (thanks to some flesh/sky hue warping code from NewRisingSun), but I'm not going to be adding a chroma line delay or low-level noise right now. I think PAL might require this, so if I ever get around to making a PAL filter, this would naturally become available to the NTSC code. I've rewritten the code yet again to build the tables in a clean way and adjust them so you can output to 16-bit RGB pixels without any diagonal stripes in solid color areas, caused by rounding errors getting amplified when truncating to 5 bits per color component.

My main goal is to make it fast and usable in an emulator. Going the last mile to make it indistinguishable from video capture is too labor-intensive given the payoff. If I'm going to do something labor-intensive, writing more test ROMs would be more worthwhile. Like NewRisingSun said, the main value of any of this NTSC decoding is for systems that require it to even get the basic pixel colors correct, like the Apple II.

I've played it now full-screen 640x480 and it's pretty darn close to a TV, but still has a slightly off look (kind of like how digitized NTSC video looks). On a side note, someone's used the code for Atari 800 NTSC and I wrote a SNES version over the past couple of days, probably to appear in bsnes over the weekend. I was bored so I made another GIF animation of even and odd fields using the latest code.

Image


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 24, 2006 1:23 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 330
Quote:
adding a chroma line delay or low-level noise right now. I think PAL might require this
Not if you're going for a "Simple PAL" decoder. Since we're not dealing with terrestial reception problems, you won't need the delay line even for PAL.

Have you already replaced the Gaussian with the Bessel filter? That might be the one factor still significant in achieving a perfect TV look.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 24, 2006 2:31 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
The Atari 800 modifications someone made to an earlier version I posted here included PAL line delay which was necessary for some demos to look right (it cleverly used even scanlines for chroma information and odd for luma, allowing many more colors than the system has. Good to know though; the table-based algorithm wouldn't like that as much.

Quote:
Have you already replaced the Gaussian with the Bessel filter? That might be the one factor still significant in achieving a perfect TV look.


Nope. I'm kind of sore about that too, since I attempted a "by-the-book" decoder by generating the NES video waveform at 42 MHz and filtering that down. I never could get the damn luma and chroma filters to work well; the chroma kept getting the blips at the edges of large luma changes, as you'd expect since an amplitude step is made up of many harmonics. Until I can get that working, I probably won't mess with the filter. And like I said, I'm sore on this issue so I'm not really interested in discussing solutions at the moment (even if you have one that works heh).

I did make one important improvement to your gaussian kernel, though: ensure that the sums of every fourth point (at each of the four phases) total 0.5, otherwise it will favor one of the Y+I, Y+Q, Y-I, or Y-Q components. I wrote a simple normalization after the kernel is generated that just finds the sums and then scales every fourth sample for each phase by the appropriate ammount. Your gaussian approaches this ideal as it gets wider, but for really small sizes it's off (in my table I'm using a gaussian of width 13, so each side is 6 points). Also, I found that I could vary the width (via the factor inside the call to exp()) and reduce the "echoes" around text, at the expenst of adding slightly more color fringe.

I remember what the problem was, I read that the luma spectral components interleve with the chroma components, so you need a comb filter to separate them properly. I'm not at all up on comb filters was overwhelmed by things I didn't understand.


Top
 Profile  
 
PostPosted: Sat Sep 19, 2015 1:25 pm 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
Bumping this OLD thread because I have a question about this particular filter's method for some sliders. In my PAL filter implementation, I'm getting somewhat close to composite output I see from my tuner, and I made notch simulator that reduces moire on solid colors, but I'm stuck with implementing the sharpness slider. I fail to understand how it decides what to reduce, and what colors it uses and how. It's not some blending, in Blargg's NTSC filter blending is more like the resolution slider.

Image

And this is how close the Blargg's filter gets to my tuner:

Image


Top
 Profile  
 
PostPosted: Sat Sep 19, 2015 1:38 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
As I remember, my sharpness is just 2D (scanline) edge enhancement. In its more basic form, you exaggerate differences between pixels, but correct before/after to keep the absolute level the same. So 10, 10, 90, 90 becomes 10, 0, 100, 90 if you're enhancing, and 10, 20, 80, 90 if you're softening.


Top
 Profile  
 
PostPosted: Sat Sep 19, 2015 2:03 pm 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
So you're also detecting edges somehow? Is that within RGB? What's the principle? Or it's just for any changing color?


Top
 Profile  
 
PostPosted: Sat Sep 19, 2015 4:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
The principle is convolution. Convolving a picture with, say, [1, 6, 1]/8 will soften edges, and convolving it with [-1, 10, -1]/8 will sharpen them. The first means you take 1/8 times the pixel to the left, 6/8 times the pixel to the middle, and 1/8 times the pixel to the right, and add them.


Top
 Profile  
 
PostPosted: Mon Sep 21, 2015 10:48 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 106
Location: RU
Thank you guys, added sharpness that looks quite right (except for a few too bright pixels):
http://savepic.su/6222236.png

What I really need now is how fringing works. It creates rainbow effect when luma level suddenly changes, and color depends on how far from colorburst it is, but what are the colors and what are the lengths for them? I compared Blargg's filter to my tuner, and even though the color is not the same, the idea is still quite clear.

Even if exact values aren't known, I at least would like to know what setup is there in Blargg's filter.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 5 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