Live data from Hacker News

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

alvyray.com

51–60 of 81 posts

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

#51
post #14

Earlier quoted context omitted.

Reeeaallly? I haven't made the images, but my intuition is telling me that text will be noticeably blurry compared with a box filter. I basically agree with your points regarding compositing in a linear space, except that I suspect that thin black-on-white lines will come out looking thin and spindly.

It sounds like you are talking about text that doesn't move. If you want a general filter that can give a result without visible aliasing while sacrificing as little sharpness as possible, a 2.2 gauss filter is very hard to beat and I have spent a lot of time trying. Box filters can be sharper, lancoz filters can be better for scaling down a final image, etc. but they will alias in a general sense. You might not see…

A Gaussian kernel will reduce ringing artifacts, but is much blurrier than alternative resampling kernels. https://www.imagemagick.org/Usage/filter/nicolas/

Does “diameter” here mean “twice the standard deviation”?

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

#52

Earlier quoted context omitted.

It's possible this research has been done, but if so I haven't seen it yet. Basically the reason I feel confident asserting it is that I'm talking very specifically about the stimulus produced by modern displays. I know there's some work by Avi Naiman on CRT displays from the very early 90's[0]. There might be some other work done on low-resolution LCD's, but even aside from resolution it's only modern, high quality…

There is research about perception of physically printed lines, done by e.g. print photography companies decades ago. There is plenty of formal signal processing analysis of the aliasing artifacts at different angles created by grids of pixels. The ImageMagick folks did a bunch of experimentation about resampling filters as used in arbitrary transformations of existing raster images. https://www.imagemagick.org/Usage…

So based on this research, what reconstruction filter and gamma curve should I use to render text so it looks good over a range of fonts? :)

Or, perhaps a better posed question. What research-informed model will accurately predict the results of a user study that presents various renderings of antialiased lines on a modern LCD monitor and asks subjects to choose "which line is thicker" types of queries?

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

#53

Pixel and voxel are not commensurable. A pixel is a display hardware concept. A voxel is more comparable to a texel. https://en.wikipedia.org/wiki/Texel_(graphics) Texels and Voxels can be square/cubic, such as in video game applications where it is accepted and exploited as a fundamental esthetic: worlds are textured with tiled mosaics which reveal their square unit when approached closely, and ditto for worlds made…

Both the word “pixel” and the word “voxel” are commonly used in both of these different senses. I believe the word “voxel” was created to be explicitly a 3D analog of a 2D “pixel”.

For example, you can also have “pixel art”, drawings made up of little squares, which only loosely have to do with pixels as samples for a raster image or physical camera detector elements or physical display elements. https://en.wikipedia.org/wiki/Pixel_art

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

#54

Earlier quoted context omitted.

There is research about perception of physically printed lines, done by e.g. print photography companies decades ago. There is plenty of formal signal processing analysis of the aliasing artifacts at different angles created by grids of pixels. The ImageMagick folks did a bunch of experimentation about resampling filters as used in arbitrary transformations of existing raster images. https://www.imagemagick.org/Usage…

So based on this research, what reconstruction filter and gamma curve should I use to render text so it looks good over a range of fonts? :) Or, perhaps a better posed question. What research-informed model will accurately predict the results of a user study that presents various renderings of antialiased lines on a modern LCD monitor and asks subjects to choose "which line is thicker" types of queries?

Also does the font have variable weight? Are you adjusting it in any other way before rendering? What context were the fonts designed for – did the font designers evaluate their appearance using any specific displays / rendering engines?

> asks subjects to choose "which line is thicker" types of queries

I think you could develop a model for “which line is thicker” given a specific target display without inordinately much trouble; you might have to tweak some parameters for matching particular displays. The harder question is “which line is the right thickness”, especially if you don’t have any correct answers to reference.

We also don’t just care about apparent line thickness but also spatial resolution, aliasing artifacts, ...

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

#56
post #30

This piece is a classic and a must-read for graphics people, but do remember that this was written before LCD displays. Today’s pixels actually are little squares to a much greater degree than CRTs in 1995. That doesn’t change the theory or truth in Alvy Ray’s paper, but it does mean that the perfect reconstruction isn’t the same now that it was then.

Heck, if you've written color film recorder software, they're not even particularly square

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

#57
post #36
post #32

Earlier quoted context omitted.

Were all the filters being compared with the same width? At the same width it will be softer, at a smaller pixel radius is where you can compare aliasing with the same visual sharpness as something like catmull-rom.

There were a variety of widths, it was one axis of the study. But I don’t remember the details, it is certainly possible you’re talking about something we didn’t test. Personally, at first I couldn’t even see the differences they were discussing. Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocke…

> Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocked how good they were at it, and how not that good I was. :)

IMO the best place to learn to see these distinctions is in careful photo printing (of the type where you spend >30m per image, and where “printing” here is being used in an old-school sense of “all of the manual steps to take a raw image from the camera and turn it into printed output”).

Spend a few months doing that for a few hours per week and your ability to see artifacts, textural details, fine differences in amount of edge contrast, etc. will shoot up. (Obviously the folks who spend 30 years on this are even better.)

Studying signal processing, optics, psychophysics, etc. is also useful for understanding what you are noticing, but it isn’t seeing practice.

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

#58
post #38
post #36

Earlier quoted context omitted.

There were a variety of widths, it was one axis of the study. But I don’t remember the details, it is certainly possible you’re talking about something we didn’t test. Personally, at first I couldn’t even see the differences they were discussing. Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocke…

My experience has likewise been that film DP’s have extremely impressive visual acuity, memory for color, etc. Talented artists often have developed whole sets of skills that the rest of us are unaware are even skills. In the same way a programmer might have thought about cache line false sharing as it affects memory hierarchy throughput, visual art often hides lots of expertise you cannot directly perceive, even as…

If you want to see really careful observation skills, try dye-transfer printers like http://ctein.com/

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

#59
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 more useful when calculating with them

This is super myopic / parochial.

Mathematicians think of “vectors” as elements of an abstract vector space (i.e. anything with well-defined concepts of scalar multiplication and vector addition over some field). This is useful to them because there are many powerful theorems which work in general for any arbitrary vector space, or sometimes for any vector space over the complex number field, or sometimes for any finite-dimensional vector space, or ....

Physicists think of vectors as directed magnitudes, generally some kind of measurable physical quantity in Euclidean 3-space (or Minkowski space). This is useful because many kinds of combinations and relations of directed magnitudes can be computed can be made without reference to any specific coordinate system.

One possible representation of physicists’ vectors (or certain types of mathematicians’ vectors) is an array of numbers.

But an array of numbers by itself is a completely different type of object than a vector. There are no specific well-defined operations on a generic array of numbers; or rather, depending on what it represents there are a wide variety of operations that might be meaningful or reasonable.

There are many kinds of “calculations” which are completely abstract where thinking of vectors as arrays of numbers is unbelievably obscurantist and counterproductive. Proofs and derivations involving coordinates are almost always extremely cumbersome.

There are even many types of concrete calculations on vectors-represented-as-arrays-of-numbers where the most effective algorithm is to first convert to a different representation.

Post reply on HN