Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Pixel Is Not a Little Square (1995) [pdf]

alvyray.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: A Pixel Is Not a Little Square (1995) [pdf]

#21

Post by [deleted] »

Someone wrote: post #20
jansan wrote: post #12

Earlier quoted context omitted.

> I don't think it has anything to do with display technologies though. Imagine this: there is a computer that is dedicated to image processing. It has no display, no CRT, no LCD, nothing. The computer is running a service that is resizing images from 100x100 pixels to 200x200 pixels. Would the programmer of this server be better off thinking in terms of samples or rectangular subdivisions of a display? How about a c…

> As part of a vectorization engine you need to trace the outline of all pixels of the same color in a bitmap. What other choice to you have than to think of pixels as squares with four sides? I think that’s a bad example. For vector tracing, you want the ability to trace using lines and curves at any angle, not alongside the pixel boundaries, so you want to see the image as a function from ℝ² to RGB space for which…

[deleted]

Re: A Pixel Is Not a Little Square (1995) [pdf]

#22

Post by codeflo »

justin_ wrote: post #10
codeflo wrote: post #4

This classic article is wrong, BTW, there's no nicer way to put it. It applies the wrong theory. It was already wrong in 1995 when monitors where CRTs, and it's way wrong in 2025 in the LCD/OLED era where pixels are truly discrete. Audio samples are point samples (usually). This is nice, because there's a whole theory on how to upsample point samples without loss of information. But more importantly, this theory work…

> Audio samples are point samples (usually). This is nice, because there's a whole theory on how to upsample point samples without loss of information. This signal processing applies to images as well. Resampling is used very often for upscaling, for example. Here's an example: https://en.wikipedia.org/wiki/Lanczos_resampling > It was already wrong in 1995 when monitors where CRTs, and it's way wrong in 2025 in the L…

> I don't think it has anything to do with display technologies though.

I think your two examples nicely illustrate that it's all about the display technology.

> The computer is running a service that is resizing images from 100x100 pixels to 200x200 pixels. Would the programmer of this server be better off thinking in terms of samples or rectangular subdivisions of a display?

That entirely depends on how the resizing is done. Usually people choose nearest neighbor in scenarios like that to be faithful to the original 100x100 display, and to keep the images sharp. This treats the pixels as squares, which means the programmer should do so as well.

> Alvy Ray Smith, the author of this paper, was coming from the background of developing Renderman for Pixar.

That's meaningful context. I'm sure that in 1995, Pixar movies were exposed onto analog film before being shown in theatres. I'm almost certain this process didn't preserve sharp pixels, so "pixels aren't squares" was perhaps literally true for this technology.

Re: A Pixel Is Not a Little Square (1995) [pdf]

#23

Post by GrantMoyer »

People get caught up on display technology, but how pixels are displayed on a screen is irrelevant. From a typical viewing distance and with imperfect human lenses, a point impulse and a little square are barely distingishable. The important part is that thinking about pixels as little squares instead of points makes all the math you do with them harder for no benefit.

Consider the Direct3D rasterization rules[1], which offset each sample point by 0.5 on each axis to sample "at the pixel center". Why are the "pixel centers" even at half-integer coordinates in the first place? Because if thinking of pixels as little squares, it's tempting to align the "corners" with integer coordinates like graph paper. If instead the specifiers had thought of pixels as lattice of sample points, it would have been natural to align the sample points with integer coordinates. "Little square" pixels resulted in an unneeded complication to sampling, an extra translation by a fractional distance, so now every use of the API for pixel perfect rendering must apply the inverse transform.

[1]: https://learn.microsoft.com/en-us/windows/win32/direct3d11/d...

Re: A Pixel Is Not a Little Square (1995) [pdf]

#24

Post by justin_ »

codeflo wrote: post #22
justin_ wrote: post #10

Earlier quoted context omitted.

> Audio samples are point samples (usually). This is nice, because there's a whole theory on how to upsample point samples without loss of information. This signal processing applies to images as well. Resampling is used very often for upscaling, for example. Here's an example: https://en.wikipedia.org/wiki/Lanczos_resampling > It was already wrong in 1995 when monitors where CRTs, and it's way wrong in 2025 in the L…

> I don't think it has anything to do with display technologies though. I think your two examples nicely illustrate that it's all about the display technology. > The computer is running a service that is resizing images from 100x100 pixels to 200x200 pixels. Would the programmer of this server be better off thinking in terms of samples or rectangular subdivisions of a display? That entirely depends on how the resizin…

> Usually people choose nearest neighbor in scenarios like that to be faithful to the original

Perhaps I should have chosen a higher resolution. AIUI, in many modern systems, such as your OS, it’s usually bilinear or Lanczos resampling.

You say that the resize should be faithful to the “100x100 display”, but we don’t know whether it was used from such a display, or coming from a camera, or generated by software.

> I'm almost certain this process didn't preserve sharp pixels

Sure, but modern image processing pipelines work the same way. They are working to capture the original signal, with a hopeful representation of the continuous signal, not just a grid of squares.

I suppose this is different for a “pixel art” situation, where resampling has to be explicitly set to nearest neighbor. Even so, images like that have problems in modern video codecs, which model samples of a continuous signal.

And yes, I am aware that the “pixel” in “pixel art” means a little square :). The terminology being overloaded is what makes these discussions so confusing.

Re: A Pixel Is Not a Little Square (1995) [pdf]

#25

Post by codeflo »

jvanderbot wrote: post #15
codeflo wrote: post #4

This classic article is wrong, BTW, there's no nicer way to put it. It applies the wrong theory. It was already wrong in 1995 when monitors where CRTs, and it's way wrong in 2025 in the LCD/OLED era where pixels are truly discrete. Audio samples are point samples (usually). This is nice, because there's a whole theory on how to upsample point samples without loss of information. But more importantly, this theory work…

A pixel is a box that changes color to match the point sample it represents. What's the issue?

To quote my post that you reply to, it's

> a bad approximation that can only result in unnecessarily blurry images

Re: A Pixel Is Not a Little Square (1995) [pdf]

#26

Post by leguminous »

GrantMoyer wrote: post #23

People get caught up on display technology, but how pixels are displayed on a screen is irrelevant. From a typical viewing distance and with imperfect human lenses, a point impulse and a little square are barely distingishable. The important part is that thinking about pixels as little squares instead of points makes all the math you do with them harder for no benefit. Consider the Direct3D rasterization rules[1], wh…

The half pixel offset makes sense, though. If you have two textures, you want the edges to align, not the centers of the pixels.

See, for example: https://bartwronski.com/2021/02/15/bilinear-down-upsampling-...

Implementations of resizing based on aligning pixel centers resulted in slight shifts, which caused a lot of trouble.

Re: A Pixel Is Not a Little Square (1995) [pdf]

#28

Post by p0w3n3d »

codeflo wrote: post #18
badmintonbaseba wrote: post #9

Earlier quoted context omitted.

Pixels displayed on CRT displays are not squares, but they are not infinitely small dots either. They are much less well-defined blobs, that even overlap with each other. There is also the complication of composite video signals, where you can't treat pixels as linearly independent components.

Good PC monitors (especially in 1995) displayed pixels as almost perfect discrete squares. It was home consoles on televisions where people get the idea from that all CRTs were blurry.

Let me guess: when game creators were thinking about result visuals were they considering that everyone would have this good pc monitor with exact square pixel, or were they taking into account possible distortions that would occur on average CRT?

Also: people playing retro nowadays use shaders to emulate CRT https://youtube.com/shorts/W_ZI3w9CYnI

Re: A Pixel Is Not a Little Square (1995) [pdf]

#29

Post by codeflo »

p0w3n3d wrote: post #28
codeflo wrote: post #18

Earlier quoted context omitted.

Good PC monitors (especially in 1995) displayed pixels as almost perfect discrete squares. It was home consoles on televisions where people get the idea from that all CRTs were blurry.

Let me guess: when game creators were thinking about result visuals were they considering that everyone would have this good pc monitor with exact square pixel, or were they taking into account possible distortions that would occur on average CRT? Also: people playing retro nowadays use shaders to emulate CRT https://youtube.com/shorts/W_ZI3w9CYnI

As I said,

>> It was home consoles on televisions where people get the idea from that all CRTs were blurry.

The video you linked shows a PS1 game, which proves my point. It's possible you're too young to remember the big difference between a CRT TV and a CRT monitor. Monitors really did show discrete pixels (which was important for tiny text in applications to be readable), while TVs were blurry messes.

Re: A Pixel Is Not a Little Square (1995) [pdf]

#30

Post by IAmBroom »

ChrisMarshallNY wrote: post #8
captainmuon wrote: post #5

Except pixels are little squares. Sure, if you look under a microscope, they have funny shapes, but they are always laid out in a rectangular grid. I've never seen any system where the logical pixels are staggered like a hex grid, for example. No matter how the actual light emitters are arranged, the abstraction offered to the programmer is a rectangular grid. If you light up pixels in a row, you get a line - a long…

I don't remember the manufacturer (may have been Fuji[0]), but someone made a camera sensor that was laid out around a 45-degree angle. [0] https://en.wikipedia.org/wiki/Super_CCD

There's also a hex-pattern camera sensor out there. It claimed to have better resolution without increased chip-printing cost (N pixels/area produced better effective visual resolution), but never took off.
Post reply on HN