# Why are pixels square?

Pixels in screens are square, but I'm not sure why.

Both pixelated images look pretty bad - but I'm not sure there's any advantage of squares over hexagons here.

Hexagons also divide up into 3 colours nicely:

So what's the advantage of squares in an LCD / CRT display?

• Please clarify about the context. Are you referring to displays, image formats or prints? And even then, this question might be too broad. – Daniel B Dec 30 '15 at 17:21
• Pixels are dimensionless logical units and are not ever square in actuality, as @DanielB suggests, every rasterizer handles them differently. Google images of "screen pixels" for example. – Yorik Dec 30 '15 at 17:22
• This question should perhaps be migrated to User Experience or Electrical Engineering. – curiousdannii Jan 1 '16 at 9:32
• I don't get it. Why is this upvoted at all, and why hasn't it been migrated to a mechanical engineering forum? – Carl Witthoft Jan 2 '16 at 16:56

### Pixels in screens are square, but I'm not sure why.

They aren't (necessarily) square.

Some would argue that they are never square ("A pixel is a point sample. It exists only at a point.").

### So what's the advantage of squares in an LCD / CRT display?

• Other arrangements (such as triangles, hexagons or other space filling polygons) are more computationally expensive.

• Every image format is based on pixels (whatever shape they are) arranged in a rectangular array.

• If we were to choose some other shape or layout a lot of software would have to be re-written.

• All the factories currently manufacturing displays with a rectangular pixel layout would have to be retooled for some other layout.

### Practicalities of Using a Hexagonal Coordinate System

There are generally four major considerations that must be pondered upon when using a hexagonal coordinate system:

• Image Conversion – Hardware capable of capturing images from the real world directly onto a hexagonal lattice is highly specialist, and so not generally available for use. Therefore, efficient means of converting a standard square-latticed image into a hexagonal one is required before any processing can be performed.
• Addressing and Storage – Any manipulations performed on images must be able to index and access individual pixels (in this case hexagons rather than squares), and any image in hexagonal form should be storable in hexagonal form (otherwise image conversion would have to be performed every time the image was accessed). Moreover, an indexing system that is simple to follow and makes the arithmetic of certain functions simpler would be very valuable.
• Image Processing Operations – In order to make effective use of the hexagonal coordinate system, operations must be designed or be converted that are geared to exploit the strengths of the system, and particularly the strengths of the addressing system used for indexing and storage.
• Image Display – As with actually obtaining the image in the first place, display devices in general do not use hexagonal lattices. Therefore the converted image must be returned to a form that can be sent on to an output device (whether a monitor, a printer or some other entity) with the resultant display appearing in natural proportions and scale. The exact nature of this conversion is dependent on the indexing method used. This could be a simple reversion of the original conversion process, or be a more considerable convolution.

### Issues with Hexagonal Coordinate Systems

There are some problems with hexagonal coordinate systems however. One issue is that people are very used to the traditional square lattice.

Reasoning in hexes can seem unnatural and therefore a little difficult. While it could be argued that people can become used to it if they have to, it is still the case that they will be naturally inclined towards reasoning with the traditional Cartesian coordinate system by default, with hexagonal systems merely a secondary choice.

The lack of input devices that map onto hexagonal lattices, and the lack of output devices that display as such is also an obstacle:

• The necessity of converting from squares to hexagons and back again detracts from the usefulness of operating on hexagonal lattices.

• As such lattices are denser than equivalent square lattices of the same apparent size, unless images are fed in at a deliberately higher resolution than is to be operated on, converted images shall have to extrapolate some pixel locations (which is generally less desirable than having all pixels provided directly from a source).

• The conversion back to square lattices would collapse some pixel locations into one another, which results in loss of apparent detail (which could result in a lower quality image than the one that was originally fed in).

If one seeks to use hexagonal coordinate systems in their own vision work, then they should first determine whether these problems are outweighed by the inherent advantages of operating with hexagons.

### Has any other shape or layout been tried?

The XO-1 display provides one color for each pixel. The colors align along diagonals that run from upper-right to lower left To reduce the color artifacts caused by this pixel geometry, the color component of the image is blurred by the display controller as the image is sent to the screen.

Comparison of the XO-1 display (left) with a typical liquid crystal display (LCD). The images show 1×1 mm of each screen. A typical LCD addresses groups of 3 locations as pixels. The OLPC XO LCD addresses each location as a separate pixel:

Source OLPC XO

Other displays (especially OLEDs) employ different layouts - such as PenTile:

The layout consists of a quincunx comprising two red subpixels, two green subpixels, and one central blue subpixel in each unit cell.

It was inspired by biomimicry of the human retina which has nearly equal numbers of L and M type cone cells, but significantly fewer S cones. As the S cones are primarily responsible for perceiving blue colors, which do not appreciably affect the perception of luminance, reducing the number of blue subpixels with respect to the red and green subpixels in a display does not reduce the image quality.

This layout is specifically designed to work with and be dependent upon subpixel rendering that uses only one and a quarter subpixel per pixel, on average, to render an image. That is, that any given input pixel is mapped to either a red-centered logical pixel, or a green-centered logical pixel.

Source PenTile matrix family

### Simple Definition of pixel

Any one of the very small dots that together form the picture on a television screen, computer monitor, etc.

### Pixel

In digital imaging, a pixel, pel, or picture element is a physical point in a raster image, or the smallest addressable element in an all points addressable display device; so it is the smallest controllable element of a picture represented on the screen.

...

A pixel does not need to be rendered as a small square. This image shows alternative ways of reconstructing an image from a set of pixel values, using dots, lines, or smooth filtering.

Source Pixel

### Pixel aspect ratio

Most digital imaging systems display an image as a grid of tiny, square pixels. However, some imaging systems, especially those that must be compatible with standard-definition television motion pictures, display an image as a grid of rectangular pixels, in which the pixel width and height are different. Pixel Aspect Ratio describes this difference.

Source Pixel aspect ratio

### A Pixel is Not A Little Square!

A pixel is a point sample. It exists only at a point.

For a color picture, a pixel might actually contain three samples, one for each primary color contributing to the picture at the sampling point. We can still think of this as a point sample of a color. But we cannot think of a pixel as a square or anything other than a point.

There are cases where the contributions to a pixel can be modeled, in a low order way, by a little square, but not ever the pixel itself.

Source A Pixel is Not A Little Square! (Microsoft Technical Memo 6 Alvy Ray Smith, July 17, 1995)

• Citation needed on the "more computationally expensive" point. Ideally link to a research paper considering a hexagonal tessellation for instance and a computational analysis. It kind of sounds like you're just naming some plausible-sounding explanations. – djechlin Jan 5 '16 at 0:39
• Also we rewrite a lot of software all the time as part of improving things. I'm not sure your point. – djechlin Jan 5 '16 at 0:41
• @djechlin Currently all video/image specs are based on a rectangular array of pixels. Display of any video or image would require conversion from a rectangular (cartesian) coordinate system to a hexagonal coordinate system. The calculations for drawing lines on a rectangular coordinate system are simpler than drawing on a hexagonal coordinate system (this is basic math). Need I explain further? – DavidPostill Jan 5 '16 at 9:09
• @djechlin Answer updated and a citation included – DavidPostill Jan 5 '16 at 10:51
• + 1 for your Microsoft Tech Memo Source. Awesome answer in general. – shock_gone_wild Jan 5 '16 at 16:39

I would like to offer an alternative to David Postill's well thought out answer. In his answer, he approached the question of pixels being square, just as the title suggested. However, he made a very insightful comment in his answer:

Some would argue that they are never square ("A pixel is a point sample. It exists only at a point.").

This position can actually spawn off a whole different answer. Instead of focusing on why each pixel is a square (or not), it can focus on why we tend to organize these point-samplings into rectangular grids. It actually wasn't always that way!

To make this argument, we're going to play back and forth between treating an image as abstract data (such as a grid of points), and the implementation thereof in hardware. Sometimes one view is more meaningful than the other.

To start, let's go quite far back. Traditional film photography had no "grid" at all, which is one reason why the pictures always looked so crisp compared to modern digital ones. Instead, it had a "grain" which was a random distribution of crystals on the film. It was roughly uniform, but it was not a nice rectilinear array. The organization of these grains arose from the production process of the film, using chemical properties. As a result, film really didn't have a "direction" to it. It was just a 2d spattering of information.

Fast forward to the TV, specifically the old scanning CRTs. CRTs needed something different from photos: they needed to be able to represent their content as data. In particular, it needed to be data that could stream, in analog, over a wire (typically as a continuously changing set of voltages). The photo was 2d, but we needed to turn it into a 1d structure so that it could just vary in one dimention (time). The solution was to slice the image up by lines (not pixels!). The image was encoded line by line. Each line was an analog stream of data, not a digital sampling, but the lines were separated from each other. Thus, the data was discrete in the vertical direction, but continuous in the horizontal direction.

TVs had to render this data using physical phosphors, and a color TV required a grid to divide them into pixels. Each TV could do this differently in the horizontal direction, offering more pixels or fewer pixels, but they had to have the same number of lines. In theory, they could have offset every other row of pixels, exactly as you suggest. However, in practice this wasn't needed. In fact, they went even further. It was quickly realized that the human eye handled movement in a way that let them actually only send half the image every frame! On one frame, they'd send the odd numbered lines, and on the next frame ,they'd send the even numbered lines, and stitch them together.

Since that time, digitizing these interlaced images has been a bit of a trick. If I had a 480 line image, I actually only have half the data in each frame due to interlacing. The result of this is very visible when you try to see something move fast across the screen: each line is temporally shifted 1 frame from the other, creating horizontal streaks in fast moving things. I mention this because it's rather amusing: your suggestion offsets every other row in the grid by half a pixel to the right, while interlacing shifts every other row in the grid by half in time!

Frankly, it is easier to make these nice rectangular grids for things. With no technical reason to do any better than that, it stuck. Then we hit the computer era. Computers needed to generate these video signals, but they had no analog capabilities to write out an analog line. The solution was natural, the data was split into pixels. Now the data was discrete in both vertical and horizontal. All that was left was to pick how to make the grid.

Making a rectangular grid was extremely natural. First off, every TV out there was already doing it! Second, the math for drawing lines on a rectangular grid is much simpler than drawing them on a hexagonal one. You might say "but you can draw smooth lines in 3 directions on a hexagonal grid, but only 2 in the rectangular one." However, rectangular grids made it easy to draw horizontal and vertical lines. Hexagonal grids can only be made to draw one or the other. In that era, not many people were using hexagonal shapes for any of their non-computing efforts (rectangular paper, rectangular doors, rectangular houses...). The ability to make smooth horizontal and vertical lines far outstripped the value of making smooth full color imagery... especially given that the first displays were monochrome and it would be a long time before smoothness of imagery played a major part in thinking.

From there, you have a very strong precedent for a rectangular grid. The graphics hardware supported what the software was doing (rectangular grids), and the software targeted the hardware (rectangular grids). In theory some hardware might have tried to make a hexagonal grid, but the software just didn't reward it, and nobody wanted to pay for twice as much hardware!

This fast forwards us to today. We still want nice smooth horizontal and vertical lines, but with high end retina displays, that's getting easier and easier. However, developers are still trained to think in terms of the old rectangular grid. We are seeing some new APIs support "logical coordinates" and doing anti-aliasing to make it seem like there's a full continuous 2d space to play with rather than a grid of rigid 2d pixels, but its slow. Eventually, we might see hexagonal grids.

We actually do see them, just not with screens. In print, it is very common to use a hexagonal grid. The human eye accepts the hexagonal grid much faster than it accepts a rectangular grid. It has to do with the way lines "alias" in the different systems. Hexagonal grids alias in a less harsh way, which the eye is more comfortable with (if a hex grid needs to go one row up or down, they get to do it smoothly over a diagonal transition. Rectangular grids have to skip, creating a very clear discontinuity)

• Great for explaining how TV came in to being: an analog stream. This standard stood for 70 years and adding color was done in a way that kept compatibility with B/W, try accomplishing that these days! How many video formats are there now? – user488805 Dec 31 '15 at 20:11
• """TVs had to render this data using physical phosphors, with a grid to divide them into pixels.""" - was this true of Black & White TV? My understanding was that discrete "physical phosphors" (which still never corresponded to any pixel-like item in the data stream) came with color TV, and that monochrome CRTs simply have a continuous coating of phosphor-stuff. – Random832 Jan 1 '16 at 6:14
• I like the history, but I disagree regarding the transition to modern devices. Although the legacy appears rectilinear, a TV is actually analog in the horizontal direction until you look at the color phosphor on the TV. It is actually hexagonal! I suggest that the real reason we have rectilinear is VLSI layout is easier as rectilinear rather than hexagonally packed. – user3533030 Jan 6 '16 at 5:59
• In a black and white TV, why wouldn't you just smear phosphors over the surface and let the electron stream be stronger/weaker and make them glow more/less in a completely analog way? In short, why have (horizontal) pixels at all? Once you have color, things get trickier; but even then, the color signal is not defined in a per-pixel manner if I remember correctly. As for horizontal samples, the number of samples required to reconstitute a signal from uniform intensity samples is a function of the frequency bandwidth, and half-"sample" offsets do not improve this. – Yakk Jan 6 '16 at 19:12
• @Yakk Most black and white CRTs were built exactly like that - early BW TV CRTs were derived from Radar/Oscilloscope CRTs which are often controlled in analogue X/Y or polar fashion with no raster. The TVs still used line by line scanning because that corresponds with how the signal is encoded, but no pixels on the lines. Some specialty displays (mostly for aircraft cockpits) even used phosphors that changed color depending on how strongly they were hit with an electron beam (that kind of display is called a penetron). – rackandboneman Jan 7 '16 at 9:21

Two reasons:

• A rectangular shape versus circular, triangluar, or more-than-4-sided has the advantage that it can be placed next to other rectangles with the minimum of "wasted space". This ensures that the full area of the pixel contributes to the image. Other shapes can exist that "fit together", but they would probably more complex to manufacture than simple squares or rectangles, yet not introduce any additional advantages.

• A general purpose pixelated display - one that might be used to display any type of information needs to have pixels that don't favor certain types of shapes. So pixels should be square instead of longer or wider in one direction, and not sheared or rotated in any way.

• If pixels are taller than wider, the minimum thickness of a horizontal line will be wider than the minimum thickness of a vertical line, making horizontal and vertical lines look different, for the same number of pixels.

• If pixels are rotated, then only angled lines that match the angle of rotation will look smooth, any other lines will look jagged. Most operating systems and productivity software relies on straight lines so that would be a lot of fringing or jagged egdes.

• Sheared pixels (rhombuses) would be the worst of both worlds - neither diagonals or horizontal/verticals would be smooth.

If you are not interested in a general purpose display, but one geared towards a specific purpose, then you can be more flexible. An extreme example is the 7-segment LED, if all you need to do is display a number, 7 non-square pixels arranged in such fashion is all you need. Or 15-segment LEDs that allow letters.

• Hmm, I'm not sure the cost argument works for hexagons (I could be wrong). – Tim Dec 30 '15 at 19:59
• @Tim - You should some research on the subject. If there was an technical advantage to hexagons a display manufacture would use them, the fact they are not used, indicates they don't hold any sort of advantage from a cost or performance advantage. – Ramhound Dec 30 '15 at 20:06
• @Ramhound yes, got it. I need to research more - well this question is my research. I'm asking for reasons why not hexagons - not why squares (and a link to some cost comparison would be nice - idk if anyone has ever made one) – Tim Dec 30 '15 at 20:14
• "they would probably more complex to manufacture than simple squares or rectangles" -- citation needed. "yet not introduce any additional advantages" -- citation needed. – Raphael Dec 31 '15 at 11:39
• @Raphael Well, you don't really need a citation for that - on a CRT, the "pixels" were not squares or rectangles. They had great colour distribution, and required fewer sub-pixel rendering "tricks". When LCDs came around, they simply couldn't compare - the technology was extremely pro-rectangle, so the more traditional layout was more or less impossible. Of course, modern "LCDs" are not necessarily actually LCDs - you're not going to find any "liquid crystals" in an OLED, for example. Finally, hexagons (or old school CRTs, it's similar) would work nice for pictures and movies, but not for UIs. – Luaan Jan 1 '16 at 1:51

# Pixels are not necessarily square!

In the past pixels have rectangular shapes. That's why in any professional image/video editor like Photoshop, Premiere, Sony Vegas... you see the pixel aspect ratio option. Only modern TV and PC monitor standards have square pixels.

Famous examples:

• PAL Analog TV/DVD: 720x576 which is obviously not 16:9 or 4:3 but 5:4. However when setting the correct pixel aspect ratio it'll produce the correct unstretched output image

• NTSC Analog TV/DVD: 720x480 which is 3:2. After setting the aspect ratio it'll become 16:9 or 4:3 like PAL above. The lower vertical resolution also explains why NTSC DVDs look a lot less crisp than PAL

• VCD: PAL 352x288, NTSC 352x240. Both use 4:3 screen aspect ratio
• SVCD: 480x480, and unsurprisingly it doesn't produce a square output
• DV: 1440x1080 16:9 full HD resolution
• CGA: 320x200 and 640x200 in 4:3 (yes, older computer screens do have rectangular pixels)
• EGA supports 640x350 for 4:3 screens in addition to 320x200 and 640x200

Adobe Premiere Pro - Working with aspect ratios

• This answer could be improved by explaining a little more about aspect ratio (as opposed to just a link). It is not clear, by itself, why a particular screen resolution can't have square pixels. – Jon Bentley Dec 31 '15 at 17:15
• I don't understand the link between the square pixels and the resolution. – A.L Jan 2 '16 at 16:32
• @A.L as I already stated above. 720:576 is 5:4 and if pixels are square, it'll result in a 5:4 aspect ratio. However if pixels aspect ratio is set to a value different from 1 it'll produce a different aspect ratio. But where did I say about resolution here? I just said aspect ratio – phuclv Jan 2 '16 at 16:38
• @A.L: This answer proves that not all pixels in screens (or file) are square: some are rectangular. – slebetman Jan 4 '16 at 3:10
• Atari 8-bit computers had some graphics modes with a resolution of 80x192, resulting in very non-square, dash-shaped pixels. – DaveP Apr 6 '17 at 8:35

The answer is: they should be hexagonal, because hexagonal tiling provides optimal optical quality, so it will be the future.
But I think there are two main reasons why are they still square:

• It is easier to represent bitmap image data on a square grid as an 2d array (both for the hardware simplicity and for human being)
• It happened historically so it will be so for some time because of the reason #1.

Update

This topic is a thriller. Almost 10k views. People want to master the pixel :) Funny how someone finds a relation of the question with screen resolution or "quadracy" of a quad.
For me it is: which building block, square or hexagon gives better optical results?

First, we need a simple tiling, but which covers a custom area better and it is indeed hexagon tiling. Which can be easily understood from simple tests. A strong test would be so called "ring" test. For simplicity here I make trinary color: 0 - background, 1 - gray and 2 - black.

Staring with a dot, we'll try to expand the ring, keeping it looking continuous like this:

For sure I will also want to draw horizontal/vertical lines, for many tasks, like UI and print design, or a platformer game. Let's call it "Bar Test":

With this test I can choose the line style which just looks better in real conditions. With vertical lines it is even simpler. For a specific task display everything can be made hard-coded, so to draw a line with a function, we just repeat its segment in horizontal direction. The thing is, both square and hexagonal pixel approach works, but if you try same test with square tiling, you'll notice the difference quickly. With very high DPI it is not so noticable, but why try making more DPI instead of trying more effective approach? I don't see much sence.

For RGB colors, this will probably need more complex structures. Actually, I would like to have a grayscale device, as on the images above. It would be cool also to have fast pixel response to make animations.

Just for fun I made up simple hexagonal structure, where the pixels can be RGB. Of course I don't know how could this look on a real device, but looks cool even so.

An informal explanation-illustration which could
help to describe the situation:

• I partially disagree with both parts of 1 because a) 3dmdesign.com/development/hexmap-coordinates-the-easy-way (although sure it might be a little harder to set up, but there is no difficulty in mapping coordinates to them) and b) Since when were the details of computers designed with humans in mind. – Tim Jan 1 '16 at 21:53
• @Tim Details of computer are not, but the human self tends to treat information in "rectangular" way, and that in turn leads to strange designs. There are a lot of examples, like this robonaut So why make a robot look like a human? From ergonomical point of view this robot should be more like an octopus, but people are people. – Mikhail V Jan 1 '16 at 23:01
• @MikhailV making a robot like a human, allows it to use things made for humans. Otherwise everything has to be special made for the robot. – Thorbjørn Ravn Andersen Jan 2 '16 at 18:42
• @ThorbjørnRavnAndersen Yeah, like a t-shirt and sun glasses :) – Mikhail V Jan 4 '16 at 5:48
• Wouldn't triangles be superior to hexagons as they can do everything hexagons can and more? – Raynet Jan 4 '16 at 10:25

Some of the answers already touch this... I think that non-rectangular array in terms of data storage would create almost unimaginable complexity and would be extremely error prone. I've had lots of experience with modeling physical systems where the grid is not rectangular (staggered grids - data points at half-edges and so on). Indexing is a nightmare.

First, there's the problem of how to define the boundary. Images are usually rectangular (again, this is a matter of history - if our screens were hexagonal, things would be a bit easier). So, not even the image boundary is a straight line. Do you put the same number of pixels in each row? Do you alternate even/odd? And... is the lower left pixel to the left to the one above it, or to the right? You immediately get almost 10 different standards, and programmers have to remember each time how it goes (even row-major and column-major difference or top-down/bottom-up indexing difference is causing errors sometimes). This brings along the immense problem of conversion landscape/portrait (natural transformation, which is trivial on rectangular grid, but requires interpolation and is almost necessarily a lossy procedure on a hex or different grid). This is even a problem for rectangular pixels (aspect ratio != 1).

Then there's the natural instinct people have with rectangular layout. You have matrices in math, which have the same layout. Similarly, a cartesian coordinate frame is pretty much the easiest to use and understand in most general cases. Getting the index of a pixel at (x,y) is just x+width*y (not the other way around - legacy of scanline indexing). If width is a multiple of 2, you don't even need multiplication. Working with non-right angles makes a lot of complications that stem from vector algebra, when basis vectors are not orthogonal: rotations are no longer simple cos/sin superpositions. Translation becomes weird. This brings a long a lot of computational complexity (would be a few times more expensive to compute), and code complexity (I remember coding the Bresenham's algorithm once, and I really wouldn't like to try doing it in hex).

Interpolation and antialiasing in general has a lot of algorithms that depend on the square grid. Bilinear interpolation, for instance. All fourier-based processing methods are tied to the rectangular grid as well (FFT is very useful in image processing)... well, unless you do some expensive and lossy transformations first.

That all shows that data in the memory and file formats should be stored as rectangular grid. How you display it depends on the display device/printer, but that should be the problem of the driver. The data is supposed to be device-independent and shouldn't assume what hardware you have. As shown in the posts above, there are many advantages to using nonrectangular pixels, due to human eye physiology and other more technological factors - just keep the data on the square grid, or you'll have a horde of neurotic programmers to answer for :)

Despite all this, I actually played with a thought of having a circular pixel arrangement for integration in watch faces (making hands straight lines). When I started imagining how difficult would that make drawing anything as simple as a straight line that doesn't go through the center, I came to a lot of the conclusions I mention above.

• "This brings along the immense problem of conversion landscape/portrait" <...> "This is even a problem for rectangular pixels" - Oxymoron? I personally don't have habit rotating my monitor so why would rotate 90* image. – Mikhail V Jan 5 '16 at 6:03
• There are a lot of vertical screens out there (arrival/departure screens at some train stations, various advertisement panels and so on) which you can see are actually just regular screens rotated 90 degrees. Observe: img.worsethanfailure.com/images/200710/error'd/… – orion Jan 5 '16 at 8:03
• This is called "improper use of the equipment". By the way, line drawing algorithm for arbitrary points on hex grid could probably be solved without hassle. I never did it, so I try to divinate, it could turn out it will be even more elegant than for square grid. – Mikhail V Jan 5 '16 at 8:18
• Another example are phones are tablets, which rotate the image all the time dynamically. Both data (file formats) and screens need to have logically square pixels for that (no matter what the hardware does to actually display that). The line drawing algorithm is problematic in definition: Bresenham ensures the line is precisely one pixel thick either horizontally or vertically (depending on the slope). The half-width offsets of every other line in hex grid make it ambiguous what "one pixel thick" means. Sure, it can be done, but you'd first need to define and derive the algorithm anew. – orion Jan 5 '16 at 8:34
• "needs to have square pixels" Here lies the problem. Display device should never be produced with this in mind, that someone would want to rotate it. It is just a misconcept which also leads to software misconcepts and redundant abstraction layers. As for calculations: in computer vision particularly, many effective solutions are by nature tri-directional, if you will do this kind of things, polar coordinates help a lot. – Mikhail V Jan 5 '16 at 8:44

Square pixels were "the logical thing to do," says their inventor, Russel Kirsch:

“Of course, the logical thing was not the only possibility … but we used squares. It was something very foolish that everyone in the world has been suffering from ever since.”

http://www.wired.com/2010/06/smoothing-square-pixels/

This question is more about arrangement than the actual shape of a pixel.

The problem with hexagonal arrangements is that translating an hexagonal site into a cartesian coordinates and vice versa is not trivial.

Either you work with a primitive Bravais lattice index

https://en.wikipedia.org/wiki/Bravais_lattice

or you work with a rectangular conventional cell and add several internal "basis vectors". (You need two basis vectors for the smallest rectangular lattice and about 16 for the smallest square lattice).

In the first case there is an angle transformation involved and in the second each pixel need `x, y` and a base index `j` to be specified.

So at the end it, "square" pixels must be a byproduct of our Cartesian culture.

By the way, it would be very cool to have that technology but it is very incompatible with the current paradigm. In fact biologic systems, prefer hexagons when producing lattices for visual systems. Think of fly's eyes. Human retina also follows something closer to hexagonal (than square).

See here http://www.kybervision.com/resources/Blog/HumanRetinaMosaic.png and back to the point of displays http://www.kybervision.com/Blog/files/AppleRetinaDisplay.html

I have no doubts that an hexagonal lattice is more appropriate for visualization. But you can think of it in this way, each time engineers want to improve a display they face the following dilemma, 1) switch to hexagonal, change the paradigm, rewrite trillons of lines of code and hardware 2) make "squares" smallers, add memory, increase two number for display dimensions measure in pixels. Option 2) is always cheaper.

Finally a word from the inventor of the square pixel http://www.wired.com/2010/06/smoothing-square-pixels

Russell Kirsch, inventor of the square pixel, goes back to the drawing board. In the 1950s, he was part of a team that developed the square pixel. '"Squares was the logical thing to do," Kirsch says. "Of course, the logical thing was not the only possibility but we used squares. It was something very foolish that everyone in the world has been suffering from ever since.' Now retired and living in Portland, Oregon, Kirsch recently set out to make amends. Inspired by the mosaic builders of antiquity who constructed scenes of stunning detail with bits of tile, Kirsch has written a program that turns the chunky, clunky squares of a digital image into a smoother picture made of variably shaped pixels.'

• I'd say this: 3dmdesign.com/development/hexmap-coordinates-the-easy-way is fairly trivial? – Tim Jan 2 '16 at 20:24
• Yes, (good point) but that coordinate system is still not cartesian. For example, The surface "hexmap" region of "3x3" is not 9 (not even approximately). It is not a matter of angle, it is a matter of metric, an hexagonal lattice is not a rectagular (or square) lattice rotated. – alfC Jan 2 '16 at 20:29
• Fair point - but Cartesian isn't required is it? – Tim Jan 2 '16 at 20:29
• As I said, not in principle, I think it is more of a paradigm problem. (Culture biases technology and technology is sticky, technology is difficult change in isolation). – alfC Jan 2 '16 at 20:37
• I would not agree that it is a big change of paradigms. For purely digital case, it fairly simple adresation change. Practically you need a same discrete set, so that "blit" function knows where to write the data. As for image data from rectangular sources, yes there are problems. And to create a font for hex display will be even simpler than on a square (less headache with slopes). – Mikhail V Jan 4 '16 at 17:56

To appreciate why a rectilinear pixel has value, you need to understand the fabrication process of sensors and displays. Both are based upon silicon layout. Both are derived from the origins of VLSI.

For you to implement a non-rectilinear sensor pixel, you need to be prepared to:

1. Layout the light sensitive elements in a non-rectilinear way (e.g. hex-packed circles).
2. Layout the wires that collect the charge (e.g. CMOS / CCD) in a non-rectilinear way
3. Scale this layout to >> 1M x 1M to meet market demands
4. Match (or interpolate) the information to a rectilinear display

For you to implement a non-rectilinear display pixel, you need all the same things.

Many people have tried to make foveal cameras and displays (high-res in the middle where our eyes are best, low-res on the periphery). The result is always something that is more costly and less capable than a rectilinear sensor.

The reality of commercial efficiency is that you can dream of non-rectilinear sensors / displays, but it is not cost effective or scalable at this time.

• A conventional square-aspect pixel sensor would turn into one with rectangular pixels if used behind an anamorphic lens. Just as the bokeh becomes ellipical. – JDługosz Jan 6 '16 at 23:34

While they may not physically be square. They are abstractly represented as square, and when shown on displays with lowered resolutions they are seen as squares. Mostly due to laziness, and less processing. Scaling different shapes like hexagons takes more processing, as you cross fraction of pixels. While a Square is just multiplying each side by the constant. Also trying to plot a hex grid you can't just just do an easy X, Y location.

• You plot +x 100% to get the full row. Then the next row is offset by +50% and moved down by 75%. The third row is offset from the second by -50% (or 0% from the first row). While this is more complicated, I'd argue it's still easy - and a Hex coordinate system exists, as opposed to the standard cartesian - slope the Y by 30° 3dmdesign.com/development/hexmap-coordinates-the-easy-way. – Tim Dec 31 '15 at 17:14

There are two ways to answer this question:

1. In hardware, pixels are not necessarily physically square, but may be whatever shape or arrangement the manufacturer of a display device thought appropriate. In reality, they are often not square.
2. In software, pixels are considered "square" in that they are assumed to represent an area that is the same width and height. This does not mean that when rendered, for example if enlarged, they have to be drawn as squares, but they must represent the data for an area of the image that has square proportions, otherwise the image will appear stretched one way or another. This is purely by convention.

In both cases, pixels are not required to be square, but are like that purely by convention. Case in point: early widescreen displays used the same number of pixels - both in hardware and software - as non-widescreen displays, but the pixels were conceptually rectangular (the horizontal size was greater than the vertical size) rather than conceptually square as is the standard. Nevertheless, using pixel shapes that do not approximate a square is non-standard and likely to cause massive compatibility problems, at least in everyday usage.

Pixels are treated as square by convention.

From a bystander's POV, I'd have to say it's because the screen you typically watch this on anyway is rectangular. A common aspect ratio is 1920 by 1080. Past a certain length such as 720 allows for "high definition" to be recognized. This could very well be more difficult to achieve with circular or hexagonal pixels.

• Well circular doesn't tessellate, but I don't see why you can't just shrink the hexagons. See the image I made of the car - just fit more of them in? – Tim Jan 1 '16 at 17:18
• And those aspect ratios are well rectangular because the shape pixels are laid out in... A grid. – Tim Jan 2 '16 at 14:08
• @Tim, tessellation may not be that important from a "user" point of view once you give up cartesian or regular indexing. The retina is not tessellated (perfectly) and that could be even optimal (for example to avoid moiré en.wikipedia.org/wiki/Moir%C3%A9_pattern or light diffraction artifacts). – alfC Jan 5 '16 at 2:05

## protected by bwDracoJan 6 '16 at 22:48

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).