Compensating for non-square pixels
 

COMPENSATING FOR NON-SQUARE PIXELS

Computer programs make the assumption that the pixels on a screen are exactly square: that the width and the height of each pixel take up the same space on the screen. On real screens, that's not always true.

Of course, whether that matters is up to you. The following is an outline of A) how an X server can tell you whether your pixels are square; and B) how to tell at least some programs to compensate if they're not.

HOW AN X SERVER CAN TELL YOU WHETHER YOUR PIXELS ARE SQUARE

On this (imaginary) screen, 384 'dots' (pixels) fill one inch of *width*, but it takes 386 pixels to fill one inch of *height*.

This means that the pixels on our imaginary screen are not square. Our pixels are a little wide, compared to their height. It takes fewer of our pixels to make a width, more of them to make a height.

DO YOU CARE?

Our imaginary pixels are about 0.5 percent wider than they are high. Their widths take up slightly more screen area than their heights.

In our imaginary example, a program that draws a square of 384x384 pixels will display a figure that fills 1 inch of the *width* of our imaginary screen, but 0.9948 inch of its height.

Does that matter? Does it matter on your screen for figures 10 times that size? Only your own eyes can tell you.

A MISTAKE I MADE, BUT THE CORRECTION STILL WORKS IN IMAGEMAGICK

If the X server tells you that you have non-square pixels, you have non-square pixels.

Previously I thought that you can tell gtk3 (and gtk4) programs, as well as QT5 programs, to compensate for non-square pixels, but I was probably wrong.

There's a difference between "display ratio" and "pixel ratio" that I had not previously taken into account.

I now think that gtk3, gtk4, and QT5 programs only adjust display ration (they adjust width and height simultaneously, by the same amount).

That means that they will not compensate for pixel ratio (which is the ratio of width/height in pixels, and thus requires width and height to be capable of being adjusted independently).

However, ImageMagick can still compensate for non-square pixels, in the manner I describe here.

By the way, non-square pixels that have the opposite problem than our too-wide pixels -- non-square pixels that are not wide enough -- have a similar treatment that will not be outlined here.

In our example, by our previously derived xdpyinfo ("resolution: 384x386 dots per inch") our pixels are too wide by 386/384.

The inverse of 386/384 is 384/386, which gives us our correction factor.

If programs apply this correction factor to widths, while not touching heights, we compensate for our too-wide pixels.

So:

We need to pare down our widths by 0.99481865284974093264. That's too long a number! It turns out that a correction factor of 0.9948 is more than accurate enough for (say) a real-world 3840x2160 pixel screen.

Here's how we instruct ImageMagick to display images with the width correction.

(99.48% == 0.9948)

We can also make images bigger or smaller that carry over the correction without additional calculation. For instance:

They don't matter whether they're slightly off or not. Can you watch NTSC, PAL, or SECAM television programs or is your attention drawn to the mess on the screen? I bet you can, unless you make a conscious effort to detach yourself from the program and watch the tv picture instead.

NTSC is low resolution (525p) 60Hz interlaced (= 30Hz screen refresh) and each alternate pass is tinted red or blue by any signal ghosting going on. TV signal ghosting is like audio echo. The eyes & ears mush it all together, and you can see the game/whatever, because your eyes filter it out.

PAL is 625p @50 HZ interlaced and it learned from NTSC. So each alternate line it tinted red. then blue and the eyes much that together.

SECAM learned from both systems, and does 819p and is probably the best of the lot. But it too, relies on video distortions being fudged by the human eye. The human eye does the job quite nicely.

By comparison with transmitted signals monitors are more precise. I strongly suggest you stop obsessing about pixel shape. The only place a pixel shape has any effect will be a tiny percentage of distortion on colour changes. And your eyes lie to you about much bigger things than that. Enjoy the pictures on your monitor, relax, and don't obsess about unimportant details.

Typically, with all monitors, the pixels are square. And, increasingly, the colors are (or can easily be) calibrated.

However, if you are producing video, intended (say ...) to be watched on some sort of "portable video player device" – as I actually do with museum kiosks – you do need to be aware of how "lesser, cheaper" equipment might still work. And, you very much need to look at your final intended result on the actual device(s). Likewise if you are making audio for cheap MP3 players – yes, they're still out there.