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

11–20 of 31 posts

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

#11

Post by roflmaostc »

Mathematically speaking the paper is correct.

I think it actually depends what you define as "pixel". Sure, the pixel on your screen emits light on a tiny square into space. And sure, a sensor pixel measures the intensity on a tiny square.

But let's say I calculate something like:

  # samples from 0, 0.1, ..., 1 
  x = range(0, 1, 11)
  # evaluate the sin function at each point
  y = sin.(x)
Then each pixel (or entry in the array) is not a tiny square. It represents the value of sin at this specific location. A real pixelated detector would have integrated sin from `y[u] = int_{u}^{u + 0.1} sin(x) dx` which is entirely different from the point wise evaluation before.

So for me that's the main difference to understand.

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

#12

Post by jansan »

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. 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 counter example: 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?

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

#13

Post by gitroom »

i think i've argued with friends over this exact thing - like, once you zoom in, does it even matter what shape the pixel is or is it just about how we use it? you think treating pixels as points or little squares actually changes decisions when making art or code

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

#14

Post by jvanderbot »

jansan wrote: post #12
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. 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…

I really think it would be defined by the set of pixels not of that color that border that color, but maybe I'm thinking about this wrong.

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

#15

Post by jvanderbot »

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?

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

#16

Post by mordae »

There's pixels and pixels.

Screen pixels are (nowadays) usually three vertical rectangles that occupy a square spot on the grid that forms the screen. This is sometimes exploited for sub-pixel font smoothing purposes.

Digital photography pixels are reconstructed from sensors that perceive cone of incoming light of certain frequency band, arranged in a Bayer grid.

Rendered 3D scene pixels are point samples unless they approximate cones via sampling neighborhood of the pixel center.

In any case, Nyquist will tear your head off and spit into your neck hole as soon as you come close to any kind of pixel. Square or point.

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

#17

Post by GuB-42 »

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…

Things becomes less clear when you take supersampling into account. Samples may be taken in a quincunx pattern for instance.

But these samples are usually called fragments, not pixels. They turn into little square pixels later in the pipeline, so yeah, I guess that pixels really are little squares, or maybe little rectangles.

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

#18

Post by codeflo »

badmintonbaseba wrote: post #9
p0w3n3d wrote: post #6

Earlier quoted context omitted.

I think you're wrong. According to my knowledge the pixels on CRT were rectangular and were throwing their color on neighbouring pixels. Graphics created for CRT were shown nicely on those screens, had much better visuals than displayed on LCD/LED and were antialiases by default (i.e. by the display technology)

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.

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

#19

Post by thaumasiotes »

jvanderbot wrote: post #14
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…

I really think it would be defined by the set of pixels not of that color that border that color, but maybe I'm thinking about this wrong.

If your model of the pixels is that they're point samples, they have no edges and there's no way to know what they do or don't border. They're near other pixels, but there could be anything in between.

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

#20

Post by Someone »

jansan wrote: post #12
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. 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 you have samples at grid positions. Target then is to find a shape that covers the part of ℝ² that satisfies a discriminator function (e.g. “red component at least 0.8, green and blue components at most 0.1) decently well, balancing the simplicity of the shape (in terms of number of control points or something like that) with the quality of the cover.

Post reply on HN