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

71–80 of 81 posts

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

#71

Post by gsliepen »

jacobolus wrote: post #59
bjourne wrote: post #26

A pixel is a picture element. An element of a picture. Hence the name... It turns out that thinking of them as little boxes arranged in rectangular grids is very useful. Because that is how computers deal with them. Not as point samples. The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magni…

> Because [little squares] is how computers deal with them. Not as point samples This is not accurate. Computers generally represent raster images as arrays of numbers (where each entry in the array is called a “pixel”). There are no literal little squares involved. Some code (much of it mediocre) conceives of those arrays of numbers as representing little squares. Other code does not. > vectors-as-numbers is much mo…

As a physicist myself, I find I think of vectors more often as a set of independent magnitudes for each of the coordinate system axes, than of a single magnitude with a direction. That's because in most cases, the physics just works independently in each axis. So it makes a lot of sense to treat vectors as sets of numbers.

Most calculations physicists do are the same as pure mathematicians would do. So we use for example in-product and cross-product operators to operate on vectors, without caring for the exact coordinate system used. Only when we have to come up with a final answer to a question like "what angle does the ball hit the ground and with what velocity?" will we convert our vectors into a magnitude and direction.

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

#72

Post by bjourne »

dahart wrote: post #62
bjourne wrote: post #26

A pixel is a picture element. An element of a picture. Hence the name... It turns out that thinking of them as little boxes arranged in rectangular grids is very useful. Because that is how computers deal with them. Not as point samples. The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magni…

> When I teach graphics programming, I will continue to tell students that pixels are like little boxes. There’s certainly a sweet spot, where too much theoretical background takes away from learning graphics, and too little could leave students unprepared, or worse, uninterested. It’s certainly good & fun to go through at least a little sampling theory. You might also be interested to know the guy who wrote this pap…

> I’d be cautious drawing that line. I realize you were talking in part about grid arrangements. But computers treat samples however we teach them to. It’s uncommon and unlikely you’re writing a lot of code that truly handles pixels as finite square geometry rather than a point sample.

I thought about it and came up with a counter-example. subpixel rendering in general and ClearType in particular. The algorithm works by considering the exact arrangement of RGB squares (rectangles actually) to improve the appearance of rendered text. Theoretically subpixel rendering could increase the horizontal resolution threefold which were very useful for DPI-starved screens. Font hinting were also used to fit the text into the confines of the limited pixel grid.

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

#73

Post by nonanonymous »

mort96 wrote: post #68
msla wrote: post #34

Earlier quoted context omitted.

> The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magnitudes is wrong. I break every mathematical object down into three things: 1. The intuition. Why do we have this concept to begin with? What underlying idea are we trying to capture? 2. The definition. These are the axioms. 3. The implem…

There's also the case that there's a bunch of vectors you _can't_ represent as tuples of numbers. A vector with orientation but a magnitude of 0 is a completely valid vector afaik, and you could do things with it like normalizing it to get a unit vector of the same orientation, and it's not representable as a tuple. The tuple model is extremely useful, but incomplete.

Vectors with different orientation but the same magnitude are the same vector (the zero vector.) Observe that if you add a zero magnitude vector and a unit vector, the result is just the same unit vector. It follows that the normalization scheme you described can't be a function on vectors (since you can "normalize" two equal vectors but get two different results.)

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

#74

Post by dahart »

bjourne wrote: post #72
dahart wrote: post #62

Earlier quoted context omitted.

> When I teach graphics programming, I will continue to tell students that pixels are like little boxes. There’s certainly a sweet spot, where too much theoretical background takes away from learning graphics, and too little could leave students unprepared, or worse, uninterested. It’s certainly good & fun to go through at least a little sampling theory. You might also be interested to know the guy who wrote this pap…

> I’d be cautious drawing that line. I realize you were talking in part about grid arrangements. But computers treat samples however we teach them to. It’s uncommon and unlikely you’re writing a lot of code that truly handles pixels as finite square geometry rather than a point sample. I thought about it and came up with a counter-example. subpixel rendering in general and ClearType in particular. The algorithm works…

> I thought about it and came up with a counter-example. subpixel rendering in general and ClearType in particular. The algorithm works by considering the exact arrangement of RGB squares (rectangles actually) to improve the appearance of rendered text.

I mostly agree, and see my other top-level comment where I called out LCD panels as having physically square pixels.

It’s a good thought, and it is correct that ClearType is considering the sub pixel arrangement of LCD elements. But also remember the arrangement of pixels isn’t Alvy’s main point, he was mainly trying to convey how to think about the shape of samples (pixels).

Even with ClearType you don’t necessarily want to integrate the sub-sub-samples of an LCD sub-pixel with a box (square) filter.

For sub-pixel rendering in general, box filtering is definitely not the best answer. Though yes, lots of people do it and get away with it all the time when sampling quality is not a high priority. Games are a good example, even as they’re improving. Treating pixels as square when sub-sampling causes ringing artifacts that can never be cured by adding more samples. This is actually a really fun thing to do with a class of graphics students because it’s kind of surprising the first time you really get it. For some nasty antialiasing problems only high quality kernels like a Gaussian will integrate sub-samples without artifacts.

Note I’m not talking about LCD sub-pixels there, just normal supersampling. The Wikipedia article on ClearType calls that “grayscale antialiasing” to distinguish it from LCD red-green-blue subpixels. But IMO that’s a bad name since grayscale antialiasing is still referring to filtering color images.

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

#75

Post by taejo »

mort96 wrote: post #68
msla wrote: post #34

Earlier quoted context omitted.

> The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magnitudes is wrong. I break every mathematical object down into three things: 1. The intuition. Why do we have this concept to begin with? What underlying idea are we trying to capture? 2. The definition. These are the axioms. 3. The implem…

There's also the case that there's a bunch of vectors you _can't_ represent as tuples of numbers. A vector with orientation but a magnitude of 0 is a completely valid vector afaik, and you could do things with it like normalizing it to get a unit vector of the same orientation, and it's not representable as a tuple. The tuple model is extremely useful, but incomplete.

> A vector with orientation but a magnitude of 0 is a completely valid vector afaik

Not by the mathematicians' definition. Maybe somewhere in physics such objects are useful, but if you formalized them you'd get something other than a vector space.

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

#76

Post by BubRoss »

jacobolus wrote: post #67
BubRoss wrote: post #65

Earlier quoted context omitted.

No, diameter means the width of the filter in pixels. Each side would extend 1.1 pixels for a 2.2 diameter filter. If you compare filters at the same width, gauss will be softer, which is why you can lower the diameter.

A Gaussian filter has infinite support, and is characterized by its variance (or standard deviation). https://en.wikipedia.org/wiki/Gaussian_filter A ‘Gaussian’ which extends 1.1 units is a non-standard and not clearly defined thing. Are you picking some fraction of 1.1 as the standard deviation and truncating after? (Often Gaussian filters are truncated after 3 standard deviations, or similar.) Are you multiplying b…

When I say 2.2 pixels as the diameter, I mean roughly that a pixel will be made up of all the samples 1.1 pixels or closer to the center of the pixel and they will be weighted by a gauss curve. How that gauss curve is actually used is not formal or strictly defined, but is usually a curve that goes out to about 3 standard deviation a baked into a LUT and normalized.

A curve that uses more standard deviations would have to be wider in pixels to look similar.

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

#77

Post by perrygeo »

> [title repeats 3 times]

> rid the world of the misconception that a pixel is a little geometric square.

> The little square model is simply incorrect. It harms.

> I show why it is wrong in general.

Why the bluster?

He makes a decent case for this point in the domain of graphics processing; what he calls "correct image (sprite) computing".

But the narrow focus on computer graphics undermines these broad generalizations. There are many other domains that can be represented in pixel-based data models. Climate, terrain, population and land cover mapping are just a few domains where the use of a pixel as a "little geometric square" is a perfectly viable approach.

Ultimately, if the message is "think about how your data model maps to reality" - I agree. But why the hyperbole? Why shit on an entire model because it doesn't fit for your very specific use case?

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

#78

Post by jacobolus »

gsliepen wrote: post #71
jacobolus wrote: post #59

Earlier quoted context omitted.

> Because [little squares] is how computers deal with them. Not as point samples This is not accurate. Computers generally represent raster images as arrays of numbers (where each entry in the array is called a “pixel”). There are no literal little squares involved. Some code (much of it mediocre) conceives of those arrays of numbers as representing little squares. Other code does not. > vectors-as-numbers is much mo…

As a physicist myself, I find I think of vectors more often as a set of independent magnitudes for each of the coordinate system axes, than of a single magnitude with a direction. That's because in most cases, the physics just works independently in each axis. So it makes a lot of sense to treat vectors as sets of numbers. Most calculations physicists do are the same as pure mathematicians would do. So we use for exa…

> I find I think of vectors more often as a set of independent magnitudes for each of the coordinate system axes

Interesting. This is what Hestenes calls the “coordinate virus”, http://geocalc.clas.asu.edu/pdf/MathViruses.pdf ; very often any specific coordinate system is not inherent but is some arbitrary addition to the space made for convenience in some particular calculation. It is in my opinion a mistake to think of the coordinates as primary.

> operate on vectors, without caring for the exact coordinate system used

This is the opposite of the previous statement.

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

#79

Post by jacobolus »

BubRoss wrote: post #76
jacobolus wrote: post #67

Earlier quoted context omitted.

A Gaussian filter has infinite support, and is characterized by its variance (or standard deviation). https://en.wikipedia.org/wiki/Gaussian_filter A ‘Gaussian’ which extends 1.1 units is a non-standard and not clearly defined thing. Are you picking some fraction of 1.1 as the standard deviation and truncating after? (Often Gaussian filters are truncated after 3 standard deviations, or similar.) Are you multiplying b…

When I say 2.2 pixels as the diameter, I mean roughly that a pixel will be made up of all the samples 1.1 pixels or closer to the center of the pixel and they will be weighted by a gauss curve. How that gauss curve is actually used is not formal or strictly defined, but is usually a curve that goes out to about 3 standard deviation a baked into a LUT and normalized. A curve that uses more standard deviations would ha…

Do you have some code for what you specifically are talking about? Or a formal description?

You have been saying here “this kernel is better than all of the alternatives” but it’s hard to evaluate that kind of claim without knowing precisely what you mean.

“not formal or strictly defined” is not super encouraging.

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

#80

Post by BubRoss »

jacobolus wrote: post #79
BubRoss wrote: post #76

Earlier quoted context omitted.

When I say 2.2 pixels as the diameter, I mean roughly that a pixel will be made up of all the samples 1.1 pixels or closer to the center of the pixel and they will be weighted by a gauss curve. How that gauss curve is actually used is not formal or strictly defined, but is usually a curve that goes out to about 3 standard deviation a baked into a LUT and normalized. A curve that uses more standard deviations would ha…

Do you have some code for what you specifically are talking about? Or a formal description? You have been saying here “this kernel is better than all of the alternatives” but it’s hard to evaluate that kind of claim without knowing precisely what you mean. “not formal or strictly defined” is not super encouraging.

I never said it was better than all alternatives, I said my experience is that it is difficult to beat in a general case.

Bake a gauss curve out to three standard deviations into a LUT and normalize it. You can look at what PBRT does.

Keep in mind that I was replying to someone confused by all the choice of filters and was giving him a very solid starting point. This isn't some grandiose claim of scientific exploration, it's experience.

Post reply on HN