Accurate(ish) CRT TV simulation theory

[blargg]

Pixel aspect ratio (the squareness of each individual pixel)
Picture aspect ratio (the squareness of the entire screen as a whole)

What i am trying to do here is get both correct on a computer monitor. And that's exactly what my calculation does.

Get pixel aspect ratio correct and the other will also be correct, as far as it can given the shape of the display. You can't have both on a widescreen LCD for example; either you have stretching or black borders.

[tetsuo55]

- we start with the 256x224 image
- Double the height by repeating each pixel 256x448
- Pad the height by adding 19 black pixels above and below 256x486 (At this point we have reached the accurate height) [...]
- Stretch 256 to 704
- 704 needs to be padded too by adding 8 black pixels to both left and right.
- The resulting 720x486 image has the pixels correctly stored. However we still need to convert them to the correct frame/picture aspect ratio
- To do this we scale horizontally by 10/11
- 720 > 654 6/11
- Now crop to 640, equally on each side "7 3/11"
- The resulting 640x486 image is square for both the content and the monitor

You scaled horizontally by 704/256*10/11 = 2.5 and vertically by 2, for 2.5:2 = 1.25:1. The correct aspect is around 1.141:1. Same error as before. Forget about the frame; focus only on the ratio of horizontal to vertical scaling.

Where is that 1.141:1 coming from? i am unable to find any reference to it in anywhere

Pixel aspect ratio (the squareness of each individual pixel)
Picture aspect ratio (the squareness of the entire screen as a whole)

What i am trying to do here is get both correct on a computer monitor. And that's exactly what my calculation does.

Get pixel aspect ratio correct and the other will also be correct, as far as it can given the shape of the display. You can't have both on a widescreen LCD for example; either you have stretching or black borders.

My calculation are already correct according to the information i can find, please explain in more detail what you think is going wrong?

PS my monitor and TV now almost look exactly the same other than the fact that my tv has massive overscan

[Verdauga Greeneyes]

Where is that 1.141:1 coming from? i am unable to find any reference to it in anywhere

I think he means the 54/47 thing, although that would be 1.149:1..

[FirebrandX]

Where is that 1.141:1 coming from? i am unable to find any reference to it in anywhere

I think he means the 54/47 thing, although that would be 1.149:1..

And I maintain that the 54/47 is patently false for proper SNES apsect ratio correction. All tests I have done point to the intended aspect ratio of 4:3 (1097/940) for NTSC display of SNES graphics. There are several SNES games that render circles and triangles, and in both cases, they only become the correct geometric shape when you apply a 4:3 aspect ratio.

[tetsuo55]

Ofcourse its wrong

NTSC pixel aspect ratio = 10:11
NTSC picture aspect ratio = 4:3

The biggest mistake we're all making is that these aspect ratios have nothing to do with the RGB image that the emulator is outputting.

We keep completely ignoring what the DAC (RF modulator) does to the image. My Calculation takes that all into account and produces a perfect image

[blargg]

Where is that 1.141:1 coming from? i am unable to find any reference to it in anywhere

I think it's one we measured a while back. A calculated version is on nesdev, 1.148936. A simple way to be sure you've got it correct is to draw a square and be sure it appears square. Using the calculated ratio of 1.148936:1, a 195x224 box should appear square on a SNES.

Get pixel aspect ratio correct and the other will also be correct, as far as it can given the shape of the display. You can't have both on a widescreen LCD for example; either you have stretching or black borders.

My calculation are already correct according to the information i can find, please explain in more detail what you think is going wrong?

My point was that the two are connected; you can't adjust one without affecting the other, and a given screen either allows both to be correct, or forces you to choose between black borders or stretched pixels.

I maintain that the 54/47 is patently false for proper SNES apsect ratio correction. All tests I have done point to the intended aspect ratio of 4:3 (1097/940) for NTSC display of SNES graphics. There are several SNES games that render circles and triangles, and in both cases, they only become the correct geometric shape when you apply a 4:3 aspect ratio.

Pixel or screen aspect ratio? If you mean screen aspect ratio, sure, since expanding the active SNES display area of 256x224 to 299x224 (299/224 is approx 4/3) gives a pixel aspect ratio of about 1.168:1, which is fairly close to 1.148936:1. It's not exactly correct because the SNES displays slight black borders around the active pixel area, which must be taken into account as part of the image that's fit within the TV's area.

[Verdauga Greeneyes]

And I maintain that the 54/47 is patently false for proper SNES apsect ratio correction. All tests I have done point to the intended aspect ratio of 4:3 (1097/940) for NTSC display of SNES graphics. There are several SNES games that render circles and triangles, and in both cases, they only become the correct geometric shape when you apply a 4:3 aspect ratio.

Sure the developers probably intended a geometrically perfect triangle, but the sprite artists probably assumed the SNES would output to a 4:3 ratio. As our calculations show it didn't, but the difference is small enough that they probably either didn't care or notice.

[blargg]

The biggest mistake we're all making is that these aspect ratios have nothing to do with the RGB image that the emulator is outputting.

I don't follow. Emulator's output is a 2D array of pixels. We know how wide and tall they must appear on screen, so we display them like that. What else is there? Or are you talking about the phosphor patterns you see with a magnifying glass (and which differ from TV to TV)?

We keep completely ignoring what the DAC (RF modulator) does to the image. My Calculation takes that all into account and produces a perfect image

That's covered by the pixel aspect ratio. You've got the TV's electron beam scanning horizontally from left to right at a fixed speed, and the video encoder in the SNES spending some amount of time displaying each pixel. Combine the two and you end up with a physical width on screen for each pixel. Make a ratio of that with the physical spacing between scanlines on the tube and you have the pixel aspect ratio. Given the NTSC standard and SNES pixel rate, this ratio has been calculated to 54/47. That is, the physical width of a SNES pixel on an NTSC TV is is about 14.89% more than the spacing between scanlines.

[_willow_]

The frame aspect on those monitors is not 4:3, it's 5:4. Correct calculation:

1280/5 = 256
1024/4 = 256

The myth that 1280x1024 is a 4:3 resolution has its roots in CRT monitor days when this resolution was more popular than 1280x960 for some reason, despite the fact that the latter was the correct one to use for a 4:3 frame aspect. 1280x1024 stretched to fit a 4:3 aspect CRT results in a distorted image because it's a 5:4 resolution in a 4:3 frame. I don't know who started it, but they should be shot immediately.

I did measurements on 19" monitor myself

width 37.5 centimeters, 1280 pixels
height 30 centimeters, 1024 pixels

1280/37.5 = 34,13333333
1024/30 = 34,13333333

That monitor have perfect 5:4 ratio and perfect 1:1 pixel ratio. And obviously me is the victim of so called 4:3 myth. . Still there is a chance some custom monitor, notebook or other portable device do not have 1:1 pixel ratio.

Forget about the frame; focus only on the ratio of horizontal to vertical scaling

Emulator's output is a 2D array of pixels. We know how wide and tall they must appear on screen, so we display them like that. What else is there?

That's covered by the pixel aspect ratio. You've got the TV's electron beam scanning horizontally from left to right at a fixed speed, and the video encoder in the SNES spending some amount of time displaying each pixel. Combine the two and you end up with a physical width on screen for each pixel. Make a ratio of that with the physical spacing between scanlines on the tube and you have the pixel aspect ratio. Given the NTSC standard and SNES pixel rate, this ratio has been calculated to 54/47. That is, the physical width of a SNES pixel on an NTSC TV is is about 14.89% more than the spacing between scanlines.

Second it. We should take only visible TV image in to account, do the SNES pixel rate correction to the rendered image, do the hardware pixel ratio correction (if required) and let the real monitor have the black frame bars depending on its aspect ratio.

[tetsuo55]

Had to really crunch my brain to figure out that one.

The calculation over at nesdev contains a CRITICAL error.

The exact pixelclock and scanline time length is used to calculate the aspect ratio. Thats good, but that also means that you cannot cheat and leave out the sync lines and such.

the total frame has 525 lines for NTSC

Width was accurately calculated at 282.7 samples.

However height was wrong, its not 243 for progessive its 262,5(explaining the black line) its easier to use the full frame

525 = 3, to calculate the 4 = 700, scaling that back to progessive we get 350

350/282 = 1.24...

EDIT:

The math im using here is applied only to the visable part of the video signal. The math from nesdev has to be applied to the entire image including all non-image lines. This means that my calculation can be applied to any device regardless of its original output frequency

[blargg]

The calculation over at nesdev contains a CRITICAL error.

The exact pixelclock and scanline time length is used to calculate the aspect ratio. Thats good, but that also means that you cannot cheat and leave out the sync lines and such.

We just need to know the number of visible scanlines on the screen, which is 243. Horizontally, we need to know how long a scanline lasts (~52.66 us) and how long a SNES pixel lasts (~5.369318 MHz pixel clock = ~0.186 us per pixel). Divide the scanline time by pixel duration (52.66 us per scanline/0.186 us per pixel = ~283 pixels per scanline). We now have the number of SNES pixels across the TV and down (283x243). If they were square, we'd have 243*4/3=324 across. We only have 283, so pixels are wider than tall by 324/283 = ~1.14488. If all this were calculated with full precision as on the Nesdev page, we'd end up with the exact same value.

However height was wrong, its not 243 for progessive its 262,5(explaining the black line) its easier to use the full frame

The vblank lines have no importance. They aren't part of those displayed.

Let the insanity continue...

[Gil_Hamilton]

Verdauga: The 1280*1024 resolution originated before PC games started driving graphics hardware design. The modern gamer-driven hardware design cycle didn't really start until fairly recently, and 1280*1024 is an OLD standard.

By old, I mean it was an established standard on Windows 3.1 machines, back when most gaming graphics were rendered on the CPU and 3D accelerators were new and exciting. And the Voodoo 2, released in 1998, couldn't render more than 800*600. Not exactly pushing resolution boundaries there.

Ofcourse its wrong

NTSC pixel aspect ratio = 10:11
NTSC picture aspect ratio = 4:3

The biggest mistake we're all making is that these aspect ratios have nothing to do with the RGB image that the emulator is outputting.

We keep completely ignoring what the DAC (RF modulator) does to the image. My Calculation takes that all into account and produces a perfect image

Okay, I'm not gonna let this one lie anymore.

THERE IS NO SUCH THING AS AN NTSC PIXEL.

You assume repeatedly that DVD-Video and NTSC are the same thing, which is a fundamental fallacy.


NTSC does not HAVE a horizontal resolution, because it's an analog format. The maximum horizontal resolution is determined by the hardware, and varies on a DEVICE-TO-DEVICE BASIS. In some cases, it is less than HALF your assumed spec. The MINIMUM horizontal resolution, of course, is 1.
Fortunately, since it's analog, if you push past what the hardware can do, it "smears" rather than just cutting out. It's the only thing that keeps most TVs working with DVD players and game machines that have "high-res" 640*480 output.

I'm somewhat amused that you recognize this per-device variability for scanline bleeding, but no other purpose.


BUT IT GETS BETTER!
NTSC's nature as a backwards-compatible update to the prior monochrome format creates TWO SETS of numbers. The image itself is transmitted in the luma signal, and a chroma signal works as a color overlay. Luma by itself is useful(and results in a black-and-white image), chroma by itself is not.
And while luma is a (relatively) high-bandwidth signal, chroma is embarrassingly limited.




Also, the DAC and the RF modulator are separate devices. My SNES RF modulator has never been used, but my SNES still outputs analog video signals.


Is all this being nitpicky?
Not for your stated goal of accurate CRT TV emulation.

And like I said, you're never going to achieve an accurate reproduction of a CRT TV due to brightness and color range issues.
Very few LCDs have an even backlight. And all but the very best LCDs have APPALLING color range.


You're also using sample rate as a synonym for resolution in your current first post, when it's a different concept. Certainly bandwidth defines your maximum resolution, but it's not equivalent to resolution.

[tetsuo55]

The calculation over at nesdev contains a CRITICAL error.

The exact pixelclock and scanline time length is used to calculate the aspect ratio. Thats good, but that also means that you cannot cheat and leave out the sync lines and such.

We just need to know the number of visible scanlines on the screen, which is 243.

No thats false.

You have 2 options.

1.Calculate the visable scanlines by hand
2.Calculate ALL scanlines with the mhz

How can you ignore the non-image scanline when calculating the exact timings?

snip

Good points, all correct as you have probably read in my source links.

My explentation must not be very clear, thanks to your feedback i can clear some things up.


My TV simulation can be compared to a "DVR unit recording the image as a video to the harddisk"
Using the most accurate standards for analogue to digital videocapturing calculations

[Gil_Hamilton]

My TV simulation can be compared to a "DVR unit recording the image as a video to the harddisk"
Using the most accurate standards for analogue to digital videocapturing calculations

So you're reinventing the NTSC filter, and not doing a good job of it?

[blargg]

We just need to know the number of visible scanlines on the screen, which is 243.

No thats false.
You have 2 options.
1.Calculate the visable scanlines by hand
2.Calculate ALL scanlines with the mhz
How can you ignore the non-image scanline when calculating the exact timings?

Because the exact timings of non-visible things don't matter. Scanlines are a digital thing; one scanline of the SNES always corresponds with one scanline on the TV. Timing doesn't come into play at all; it's only relevant within an individual scanline.

Maybe the cause of this disagreement can be found by having you describe how you think an NTSC television converts a video signal into an image. Perhaps we're just using different terms or something.

[_willow_]

blargg

+1

The exact DAC timings have no connection with CRT electronic impulses. With DAC timings you just know what is going on, but you can't explain how powerful the impulse is.

In ruler we trust.

[tetsuo55]

We just need to know the number of visible scanlines on the screen, which is 243.

No thats false.
You have 2 options.
1.Calculate the visable scanlines by hand
2.Calculate ALL scanlines with the mhz
How can you ignore the non-image scanline when calculating the exact timings?

Because the exact timings of non-visible things don't matter. Scanlines are a digital thing; one scanline of the SNES always corresponds with one scanline on the TV. Timing doesn't come into play at all; it's only relevant within an individual scanline.

Maybe the cause of this disagreement can be found by having you describe how you think an NTSC television converts a video signal into an image. Perhaps we're just using different terms or something.

Source: http://zone.ni.com/devzone/cda/tut/p/id/4750

The snes has to add VSYNC and HSYNC information to the signal.
the full frame is image data+vsync+hsync.

When you want to calculate image size based on the clockrates you have to include this data because thats what the snes is doing too.

The width might be xxx pixels wide but that includes hsync data which takes up several pixels

Vsynch takes a lot of scanlines (40 for a max scanline image)

PS.

I completely rewrote the first post again. Hopefully its a lot clearer in explaining what i'm trying to do exactly.

[creaothceann]

xxx pixels wide

...

[tetsuo55]

xxx pixels wide

...

In reference to this calculation

http://nesdev.parodius.com/bbs/viewtopi ... 4815#24815

Active scanline is 52+59/90 µs (ITU-R BT.470-6). NES' pixel clock is precisely 6/4*Fsc = 7,5*63/88 MHz, giving 282.7 pixels, or 282 full pixels horizontally.

[_willow_]

But how can you calculate aspect ratio?

Width is just time units and how you are going to express SIZE for TIME?

[tetsuo55]

But how can you calculate aspect ratio?

Width is just time units and how you are going to express SIZE for TIME?

You can calculate it by stripping the HSYNC and VSYNC data, what is left is the image as it would be displayed on a 4:3 screen.

Its the exact same calculation as is done on nesdev but the input numbers are slightly different. I cannot calulcate this because i do not know how long the hsync and vsync signals take.

The system in the first post completely evades this problem.

[Tallgeese]

...I thought it was universally understood by now that tetsuo is insane? Why do you people keep entertaining his topics?

[_willow_]

--->8-- Example ---->8------
-Stretch the width from 256 to 702
-Pad the width to 720 by adding 9 black lines at the left and the right of the image.
--->8-- Example ---->8------

No no, by that logic borders units and image time units become different timing units but they are the same. Black borders is an empty part of the whole image. And they are not neither lines nor rows nor columns, they are timing units within line. Borders are in place because CRT degrading the image quality near the borders so they leaved just blank.

[tetsuo55]

...I thought it was universally understood by now that tetsuo is insane? Why do you people keep entertaining his topics?

Not really i just question things other don't dare to touch

--->8-- Example ---->8------
-Stretch the width from 256 to 702
-Pad the width to 720 by adding 9 black lines at the left and the right of the image.
--->8-- Example ---->8------

No no, by that logic borders units and image time units become different timing units but they are the same. Black borders is an empty part of the whole image. And they are not neither lines nor rows nor columns, they are timing units within line. Borders are in place because CRT degrading the image quality near the borders so they leaved just blank.

i know why they are there, but because the DVD standard is based on them we need them to get the correct aspect ratio when resizing to 1:1 pixels.

I guess you could probably find a way around them but you'd have to adjust the cropping after resize too.

[_willow_]

Somewhat close. We need to scale the whole line including the left and right borders. SNES black borders must be different and this counts on the aspect ratio too. Looks like left & right borders is the part of the whole image and should be rendered on the endpoint device as well.