Article 6KDVW Compensating for non-square pixels

Compensating for non-square pixels

by
KISSAndStable
from LinuxQuestions.org on (#6KDVW)
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

Code:xdpyinfo | grep resolution
resolution: 384x386 dots per inchOn 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:

Code:echo "384/386" | bc -l
0.99481865284974093264We 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.

Code:display -resize 99.48%x100% [our image](99.48% == 0.9948)

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

Code:magick [our image] -resize 99.48%x100% - | display -resize 3800x1920 -Code:magick [our image] -resize 99.48%x100% - | display -resize 300% -
External Content
Source RSS or Atom Feed
Feed Location https://feeds.feedburner.com/linuxquestions/latest
Feed Title LinuxQuestions.org
Feed Link https://www.linuxquestions.org/questions/
Reply 0 comments