>Before HD, almost all video was non-square pixels

Correct. This came from the ITU-R BT.601 standard, one of the first digital video standards authors of which chose to define digital video as a sampled analog signal. Analog video never had a concept of pixels and operated on lines instead. The rate at which you could sample it could be arbitrary, and affected only the horizontal resolution. The rate chosen by BT.601 was 13.5 MHz, which resulted in a 10/11 pixel aspect ratio for 4:3 NTSC video and 59/54 for 4:3 PAL.

>SD channels on cable TV systems are 528x480

I'm not actually sure about America, but here in Europe most digital cable and satellite SDTV is delivered as 720x576i 4:2:0 MPEG-2 Part 2. There are some outliers that use 544x576i, however.

Displaying content from a DVD on a panel with square pixels (LCD, plasma, etc.) required stretching or omitting some pixels. For widescreen content you'd need to stretch that 720x480 to 848x480, and for 4:3 content you'd need to stretch it to 720x540, or shrink it to 640x480, depending on the resolution of the panel.

CRTs of course had no fixed horizontal resolution.

Edit: I just realized I forgot about PAL DVDs which were 720x576. But the same principle applies.

Just look at Japanese television… most channels get broadcast at 1440x1080i for 16:9 content instead the full 1920x1080i (to save bandwidth for other things, I assume), so it's still very common with HD too.

I'm confused... what does DVD, SD or any arbitrary frame size have to do with the shape of pixels themselves? Is that not only relevant to the display itself and not the file format/container/codec?

My understanding is that televisions would mostly have square/rectangular pixels, while computer monitors often had circular pixels.

Or are you perhaps referring to pixel aspect ratios instead?

It is.

Some modern films are still filmed with anamorphic lenses because the director / DP like that, and so we in the VFX industry have to deal with plate footage that way, and so have to deal with non-square pixels in the software handling the images (to de-squash the image, even though the digital camera sensor pixels that recorded the image from the lens were square) in order to display correctly (i.e. so that round circular things still look round, and are not squashed).

Even to the degree that full CG element renders (i.e. rendered to EXR with a pathtracing renderer) should really use anisotropic pixel filter widths to look correct.

Yes, and when working with footage shot with anamorphic lenses one will have to render the footage as non-square pixels, mapped to the square pixels of our screens, to view it at its intended aspect ratio. This process is done either at the beginning (conforming the footage before sending to editorial / VFX) or end (conforming to square pixels as a final step) of the post-production workflow depending on the show.

Yes I think they are conflating square pixels with square pixel aspect ratios.

If a video file only stores a singular color value for each pixel, why does it care what shape the pixel is in when it's displayed? It would be filled in with the single color value regardless.

This is indeed similar in the effects, but completely different in the cause to the phenomenon referenced in the article (device pixel ratio vs pixel aspect ratio).

What you're referring to stems from an assumption made a long time ago by Microsoft, later adopted as a de facto standard by most computer software. The assumption was that the pixel density of every display, unless otherwise specified, was 96 pixels per inch [1].

The value stuck and started being taken for granted, while the pixel density of displays started growing much beyond that—a move mostly popularized by Apple's Retina. A solution was needed to allow new software to take advantage of the increased detail provided by high-density displays while still accommodating legacy software written exclusively for 96 PPI. This resulted in the decoupling of "logical" pixels from "physical" pixels, with the logical resolution being most commonly defined as "what the resolution of the display would be given its physical size and a PPI of 96" [2], and the physical resolution representing the real amount of pixels. The 100x100 and 200x200 values in your example are respectively the logical and physical resolutions of your screenshot.

Different software vendors refer to these "logical" pixels differently, but the most names you're going to encounter are points (Apple), density-independent pixels ("DPs", Google), and device-independent pixels ("DIPs", Microsoft). The value of 96, while the most common, is also not a standard per se. Android uses 160 PPI as its base, Apple has for a long time used 72.

[1]: https://learn.microsoft.com/en-us/archive/blogs/fontblog/whe...

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/devi...