News for hackers. Stuff that matters.
Re:A Pixel Is Not a Little Square (1995) [pdf] by gumby on Sunday November 16, 2014 @01:20PM (#8614926)
> Stopped reading at "A pixel is a point sample." > ...yes, many times, it's a square.

While "appeal to authority" is generally a bad way to end a discussion, I will start by pointing out that this is Alvy Ray Smith writing, and he was writing in 1995. So while you could end up disagreeing with him (though I hope you wouldn't), you might consider why he was writing. Your comment shows that this paper is just as applicable today.

(since you stopped on page two you never saw the several examples of why this matters in the article, including one on scanning and one on pre-rendering geometric computation).

Those graphics cards you refer to reflect Smith's influence on their design.You have sub pixel rendering today because pixels aren't squares. This was computationally prohibitive in 1995.

The TL;DR of this brief paper is "IO is really really hard, and though accepting shortcuts and defaults only kinda works and here's why." You benefit from a lot of work done in the last 20 years to improve the quality of the libraries and hardware available to you, but still, "photo-realistic" graphics aren't.

By the way, rendered pixels weren't squares in those days (they were not-always-circular dots on a screen which itself wasn't flat) and they aren't on today's flat LCDs (you can think of them as rectangular, though the color elements do not present uniformly though the area) and they sure as hell aren't on any device with lenses or mirrors (including projectors and headsets)

Re:A Pixel Is Not a Little Square (1995) [pdf] by gaze on Sunday November 16, 2014 @01:55PM (#8615034)
I think everyone in signal processing writes the same rant against zero-order-hold at some point. The Xiph people did (http://xiph.org/video/) and so has this guy.
Re:A Pixel Is Not a Little Square (1995) [pdf] by Stratoscope on Sunday November 16, 2014 @04:07PM (#8615431)
A couple of things in your interesting comment were a bit confusing to me. Since you obviously know your stuff, it may be just a difference in terminology that thew me off. So let me add a couple of notes that hopefully may help clarify for others.

> You have sub pixel rendering today because pixels aren't squares.

Another way to put this is that color LCD panels don't have pixels at all. The only thing they have is red, green, and blue "subpixels" that each have a 1:3 aspect ratio. So you could take any three of those subpixels in a row and call them a "pixel".

Operating systems were traditionally written without any knowledge of these individual subpixels, and addressed the display on a whole-pixel basis. It's up to the display hardware to figure out how to map colors onto the physical device.

But if you know you're rendering on an LCD with the 1:3 subpixels, and you know the order of those subpixels (usually RGB, sometimes BGR), then you can give each "pixel" a color that lights up the individual subpixels as you want.

As an aside, in CSS you can think of a color value like "rgb(10,20,30)" as addressing the individual subpixels, assigning 10, 20, and 30 to the red, green, and blue subpixels. You just don't know how those physical subpixels are laid out on the display, so you can't really do subpixel rendering in CSS.

But if the OS knows what order the subpixels are in, it can take advantage of that. Even though the display hardware/firmware presents an abstraction of "pixels", the OS still provides individual R, G and B values for each "pixel" - thus addressing in a roundabout way the individual subpixels.

That's what makes subpixel rendering possible on displays that don't directly expose the individual subpixels.

> rendered pixels weren't squares in those days (they were not-always-circular dots on a screen which itself wasn't flat)

The circular dots on a CRT aren't pixels and aren't directly related to pixels at all. Assuming a traditional non-Trinitron CRT, you have three electron guns for R, G, and B. The beams from these guns go through a shadow mask with little holes in it, and then the beams hit phosphor dots on the screen. The shadow mask allows each beam to light up only the phosphor dots for that color.

As the electron beams sweep across the CRT, each horizontal sweep corresponds to a row of pixels, and the three beams are modulated brighter or dimmer for each individual pixel. But there's no relationship between the size and location of these "pixels" and the actual shadow mask holes or phosphor dots on the screen. CRT displays could run in multiple resolutions but obviously the phosphor dots couldn't move to line up with the pixel locations for each resolution.

Trinitron displays were are a bit different, using phosphor stripes instead of dots and an aperture grille (tiny vertical wires under tension) instead of a shadow mask with holes in it, but the principle was the same: The phosphor stripes didn't correspond at all to pixel locations.

Re:A Pixel Is Not a Little Square (1995) [pdf] by davrosthedalek on Sunday November 16, 2014 @01:45PM (#8614998)
I realize that sub-pixel rendering is a misleading term, there are two concepts: a) Making use of fact that a physical pixel is a composite of multiple, disjunct areas of single-colored elements. b) Rendering objects with higher-than-pixel-density resolution, for example lines which appear thinner than a pixel.

/Both/ relies on the fact that a pixel has an area, i.e. it is not a point, which is the point I was trying to make.

A pixel on LCDs is indeed square most of the time, the subpixel elements are not. CRTs, of course, different story.

All the "problems" he describes actually arise from the misconception that a pixel is a /point/ sample. It is an area sample, and if you treat it as such, the rest follows.