[HN Gopher] When square pixels aren't square
___________________________________________________________________
When square pixels aren't square
Author : PaulHoule
Score : 98 points
Date : 2025-12-31 13:44 UTC (9 hours ago)
(HTM) web link (alexwlchan.net)
(TXT) w3m dump (alexwlchan.net)
| drmpeg wrote:
| > Videos with non-square pixels are pretty rare...
|
| Before HD, almost all video was non-square pixels. DVD is
| 720x480. SD channels on cable TV systems are 528x480.
| m132 wrote:
| >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.
| drmpeg wrote:
| Here's some captures from my Comcast system here in Silicon
| Valley.
|
| https://www.w6rz.net/528x480.ts
|
| https://www.w6rz.net/528x480sp.ts
| m132 wrote:
| Cool!
|
| Doing my part and sending you some samples of UPC cable
| from the Czech Republic :)
|
| 720x576i 16:9: https://0x0.st/P-QU.ts
|
| 720x576i 4:3: https://0x0.st/P-Q0.ts
|
| That one weird 544x576i channel I found:
| https://0x0.st/P-QG.ts
|
| I also have a few decrypted samples from the Hot Bird 13E,
| public DVB-T and T2 transmitters and Vectra DVB-C from
| Poland, but for that I'd have to dig through my backups.
| ErroneousBosh wrote:
| My DVCAM equipment definitely outputs 720x576i, although
| whether that's supposed to render to 768x576, or 1024x576 for
| 16:9 stuff.
|
| It still looks surprisingly good, considering.
| ranger_danger wrote:
| 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?
| binaryturtle wrote:
| A square pixel has a 1:1 aspect ratio (width is the same as
| the height). Any other rectangular pixel with widths
| different than their heights would be considered "non-
| square".
|
| F.ex. in case of a "4:3 720x480" frame... a quick test:
| 720/4=180 and 480/3=160... 180 vs. 160... different
| results... which means the pixels for this frame are not
| square, just rectangular. Alternatively 720/480 vs. 4/3 works
| too, of course.
| ranger_danger wrote:
| Again I think you're talking about pixel _aspect ratios_
| instead, and not physically non-square pixels, which would
| be display-dependent. OP only said "square pixels" but
| then only talked about aspect ratios, hence my confusion.
| formerly_proven wrote:
| Dots on a crt are not pixels. Their shape depends on the
| shadow mask.
| dahart wrote:
| OP quoted "non-square pixels" from the article, which is
| talking about pixel aspect ratios, i.e., width vs height.
| The implicit alternative to square in this context is
| rectangular, we're not talking about circular or other
| non-rectangular shapes. Whenever the display aspect ratio
| is different than the storage or format aspect ratio,
| that means the pixels have to be non-square. For example,
| if a DVD image is stored at 720x480 and displayed at 4:3,
| the pixel aspect ratio would have to be 8:9 to make it
| work out: (720x8)/(480x9)==4/3. I believe with NTSC, DVDs
| drop a few pixels off the sides and use 704x480 and a
| pixel aspect ratio of 10:11.
| badc0ffee wrote:
| I'm not 100% sure I understand your question, but in order to
| display a DVD correctly, you need to either display the
| pixels stored in the video stream wider than they are tall
| (for widescreen), or narrower than they are tall (for 4:3).
| Displaying those pixels 1:1 on a display with square pixels
| would never be correct for DVD video.
| leguminous wrote:
| CRTs didn't have pixels at all. They had shadow masks (or
| aperture grilles) and phosphors, which could be a triad of
| rectangles, lines spanning basically the entire screen
| height, or dots. They did not line up with the signal, so it
| doesn't make sense to call them pixels.
| kmeisthax wrote:
| CRTs do not have pixels. At all. The shapes you might see on
| the screen if you look really closely at it are solely
| different bands of color phosphors. CRTs are capable of
| drawing arbitrary beam shapes on them in one color[0]; but
| you need regularly spaced filters and phosphor patterns in
| order to get multiple colors. If these """pixels""" were
| bigger, you'd see a perfectly normal red part of the image,
| next to a perfectly normal green part of the image, next to a
| perfectly normal blue part of the image.
|
| What a CRT _actually draws_ , though, are lines. Analog
| television is a machine that chops up a 2D plane into a stack
| of lines, which are captured, broadcasted, and drawn to the
| screen with varying intensity. _Digital_ television - and,
| for that matter, any sort of computer display - absolutely
| does need that line to be divided into timesteps, which
| become our pixels. But when that gets displayed back on a
| CRT, the "pixels" stop mattering.
|
| In the domain of analog television, the only property of the
| video that's actually structural to the signal are the
| vertical and horizontal blanking frequencies - how many
| frames and lines are sent per second. The display's shape is
| implicit[1], you just have to send 480 lines, and then those
| lines get stretched to fit the width[2] of the screen. A
| digital signal being converted to analog can be anything
| horizontally. A 400x480 and a 720x480 picture will both be
| 4:3 when you display it on a 4:3 CRT.
|
| Pixel aspect ratio (PAR) is how the digital world accounts
| for the gap between pixels and lines. The more pixels you
| send per line, the thinner the pixels get. If you send
| exactly as many horizontal pixels as the line count times the
| display's aspect ratio, you get square pixels. For a 4:[3]
| monitor, that's 640 pixels, or 640x480. Note that that's
| neither the DVD nor the SD cable standard - so both had non-
| square pixels.
|
| Note that there _is_ a limit to how many dots you can send.
| But this is a _maximum_ - a limitation of the quality of the
| analog electronics and the amount of bandwidth available to
| the system. DVD and SD cable are different sizes from each
| other, but they both will display just fine even on an
| incredibly low-TVL[4] blurry mess of a 60s CRT.
|
| [0] There were some specialty tubes that could do
| "penetrative color", i.e. increasing the amplitude of the
| electron gun beyond a certain voltage value would change to a
| different color. This did not catch on.
|
| [1] As well as how many lines get discarded during vertical
| blanking, how big the overscan is, etc.
|
| [2] Nothing physical would stop you from making a CRT that
| scans the other way, but AFAIK no such thing exists. Even
| arcade cabinets with portrait (tate) monitors were still
| scanning by the long side of the display.
|
| [3] There's a standard for analog video transmission from
| 16:9 security cameras that have 1:1 pixel aspect ratio - i.e.
| more pixels per line. It's called 960H, because it sends...
| 960 horizontal pixels per line.
|
| https://videos.cctvcamerapros.com/surveillance-
| systems/what-...
|
| [4] Television lines - i.e. how many horizontal lines can the
| CRT display correctly? Yes, this terminology is VERY
| CONFUSING and I don't like it. Also, it's measured
| differently from horizontal pixels.
| ranger_danger wrote:
| Yes I know all of that, but I think it still doesn't answer
| my question.
|
| I know you are arguing semantics and I hoped people would
| see past the "pixels aren't pixels" debate and focus on
| what I was actually asking, which is how physical
| dot/pixel/phosphor/mask/whatever patterns have anything to
| do with frame sizes of a digital video format, and I still
| assert that they don't, inherently... short of some other
| explanation I am not aware of.
|
| All I was trying to say was that I thought OP was
| conflating _physical_ "pixel" geometry with _aspect
| ratios_. Perhaps my question was _too_ simple and people
| were taking it to mean more than I did, or thought I was
| misunderstanding something else.
| ssl-3 wrote:
| > which is how physical dot/pixel/phosphor/mask/whatever
| patterns have anything to do with frame sizes of a
| digital video format,
|
| In that context, the answer is: They don't really have
| any relationship at all.
|
| Plenty of TVs of the past (from any continent) also had
| no physical dots/pixels/patterns at all. These were
| monochrome, aka black and white. :)
|
| They had an inflexible number of lines that could be
| displayed per field, but there was no inherent
| delineation within each line as to what a pixel meant. It
| was just a very analog electron beam that energized a
| consistently-coated phosphorescent screen with a
| continuously-variable intensity as it scanned across for
| each raster line.
|
| Pixels didn't really happen until digital sources also
| happened. A video game system (like an Atari or NES, say)
| definitely seeks to deliver pixels at its video output,
| and so does a digital format like DVD.
|
| But the TV doesn't know the difference. It doesn't know
| that it's displaying something that represents pixels
| instead of a closed-circuit feed from a completely-analog
| pixel-free tube-based camera.
|
| The "non-square pixel" part is just a practical
| description: When we have a digital framebuffer (as we do
| with a DVD player), that framebuffer has defined
| horizontal and vertical boundaries -- and a grid of
| pixels within those boundaries -- because that's just how
| digital things be.
|
| When we smoosh the pixels of a DVD player's 720x480
| framebuffer into an analog display with an aspect ratio
| of 4x3, we wind up with a _combined_ system, _with
| pixels_ , and those pixels aren't square.
|
| ---
|
| And that's perfectly OK, though it does lead to
| weirdness.
|
| For example: To produce a display of a perfect square
| that is 100 lines high using a 4x3 NTSC DVD is actually
| impossible. It'd have to be 100 pixels high and 112.5
| pixels wide, which we can't accomplish since the format
| doesn't have that kind of precision. It's impossible with
| an LCD, and it's impossible with an analog set from 1955
| just the same.
|
| It's a DVD limitation, not a display limit. There's no
| great trick to producing a perfect square with analog
| gear, where pixels aren't a thing -- but we can't get
| there with the DVD's non-square pixels.
|
| That weirdness doesn't have anything at all to do with
| how the display is constructed, though: Again, the TV has
| no concept of what a pixel even is (and a shadow mask
| doesn't necessarily exist at all).
| cynix wrote:
| I think how one interprets the usage of "square pixels"
| here is highly dependent on what that person is most
| familiar with. When I saw the title, even without reading
| the article, I immediately knew it's talking about PAR,
| since I'm already familiar with video encoding standards.
| It didn't even occur to me that it could be talking about
| the shape of physical elements on various display
| technologies.
| pwg wrote:
| It comes about from digitizing analog video signals. The
| early standards for sampling (digitizing) analog video
| signals resulted in the digital pixel horizontal sample size
| (often) being wider than the line spacing of the displayed
| analog video. With the result that digitized video of analog
| signals usually has a "pixel size" (analog video has no
| concept of discrete horizontal pixels) that is wider than it
| is tall.
| binaryturtle wrote:
| 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.
| ndiddy wrote:
| It may also be due to legacy reasons. Japan was a pioneer in
| adopting HD TV years before the rest of the world, but early
| HD cameras and video formats like HDCAM and HDV only recorded
| 1080i at 1440x1080. If their whole video processing chain is
| set up for 1440x1080, they'd likely have to replace a lot of
| equipment to switch over to full 1920x1080i.
| badc0ffee wrote:
| 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.
| GrantMoyer wrote:
| Even with modern digital codecs and streaming, there's usually
| chroma subsampling[1], so the color channels may have non-
| square "pixels" even if overall pixels are nominally square. I
| most often see 4:2:0 subsampling, which still has square
| pixels, but at half resolution in each dimension. However 4:2:2
| is also fairly common, and it has half resolution in only one
| dimension, so the pixels are 2:1. You'd have trouble getting a
| video decoding library to mess this up though.
|
| [1]: https://en.wikipedia.org/wiki/Chroma_subsampling
| dehrmann wrote:
| DVD also supports 352x480. These pixels are _very_ non square.
|
| Why would you want this? VHS. NTSC has 480-ish visible
| scanlines, but VHS only has bandwidth for 350 pixels.
| sbondaryev wrote:
| This reminded me of retina screenshots on mac -- selecting a
| 100x100 area can produce a 200x200 file. Different cause but same
| idea - the stored pixels don't always match what you see on
| screen.
| m132 wrote:
| 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...
| sublinear wrote:
| I might be misunderstanding what you're saying, but I'm
| pretty sure print and web were already more popular than
| anything Apple did. The need to be aware of output size and
| scale pixels was not at all uncommon by the time retina
| displays came out.
|
| From what I recall only Microsoft had problems with this, and
| specifically on Windows. You might be right about software
| that was exclusive to desktop Windows. I don't remember
| having scaling issues even on other Microsoft products such
| as Windows Mobile.
| m132 wrote:
| Print was always density-independent. This didn't translate
| into high-density displays, however. The web, at least how
| I remember it, for the longest time was "best viewed in
| Internet Explorer at 800x600", and later 1024x768, until
| vector-based Flash came along :)
|
| If my memory serves, it was Apple that popularized high
| pixel density in displays with the iPhone 4. They weren't
| the first to use such a display [1], but certainly the ones
| to start a chain reaction that resulted in phones adopting
| crazy resolutions all the way up to 4K.
|
| It's the desktop software that mostly had problems scaling.
| I'm not sure about Windows Mobile. Windows Phone and UWP
| have adopted an Android-like model.
|
| [1]:
| https://en.wikipedia.org/wiki/Retina_display#Competitors
| 8n4vidtmkvmk wrote:
| Why does the PPI matter at all? Thought we only cared about
| the scaling factor. So 2 in this 100 to 200 scenario. It's
| not like I'm trying to display a true to life gummy bear on
| my monitor, we just want sharp images.
| m132 wrote:
| These days, as most take 1x scaling factor for 96 PPI (or
| 72 if you're Apple), yes, but at the very beginning, there
| was no such reference. 100x100 without the density could
| have meant 10x10 or 100x100 inches.
|
| Some software, most notably image editors and word
| processors, still try to match the zoom of 100% with the
| physical size of a printout.
| shmerl wrote:
| I think resolution always refers to physical resolution of
| the display. But rendering can be using scaling to make
| things appear to the user in whatever real size regardless of
| the underlying resolution.
| m132 wrote:
| That really depends on the context. Open your browser's
| Developer Tools and you'll see logical sizes everywhere.
| Android, which in my opinion has the best scaling model,
| and where the PPI wildly varies from device to device,
| nearly always operates on logical sizes. Windows, GNOME,
| and KDE on the other hand tend to give you measurements in
| physical pixels. macOS is a mix and match; Preview and
| QuickTime tell you the physical resolutions, Interface
| Builder and display preferences will only show logical
| dimensions.
| alberth wrote:
| Am I missing the obvious, but it seems like the author is messing
| with the aspect ratio.
| ranger_danger wrote:
| 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.
| 8n4vidtmkvmk wrote:
| Because if that pixel takes up 2 vertical pixels when
| displayed in your web browser... That takes up more space and
| causes layout shift.
|
| I thought i understood the article just fine but these
| comments are confusing.
| avianlyric wrote:
| No the author is highlighting the fact that the aspect ratio a
| video is stored in doesn't always match the aspect ratio a
| video is displayed in. So simply calculating the aspect ratio
| based on the number of horizontal and vertical pixels gives you
| the storage ratio, but doesn't always result in the correct
| display ratio.
| a012 wrote:
| I'm no expert but this sounds like a digital version of the
| anamorphic lens/system, doesn't it?
| shrinks99 wrote:
| 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.
| pixelesque wrote:
| 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.
| fasterik wrote:
| Obligatory "A Pixel Is Not A Little Square"
|
| https://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf
| groundzeros2015 wrote:
| Yep, daily reminder that pixels are discrete point samples.
| Dylan16807 wrote:
| If you're rendering a videogame without antialiasing, they
| are.
|
| If you used a camera or a GUI to generate your pixels, they
| are not point samples.
| drob518 wrote:
| Proving that everything is more complicated than you first think
| it is when you lift up a corner of the rug.
| Demiurge wrote:
| My first thought was that pixels are never square. Squares are an
| artifact of nearest sampling to another grid. I suppose pixel art
| assumes knowledge of this final grid, but most media doesn't?
|
| Furthermore, the referencing of a raster can assume any shape or
| form. It makes some sense some signals are optimized for hardware
| restrictions.
|
| Another interesting example are anamorphic lenses used in cinema.
| laidoffamazon wrote:
| I'm reminded of how 720p Plasma TVs had input resolutions of
| 1024x768 - the pixels themselves were rectangular
___________________________________________________________________
(page generated 2025-12-31 23:00 UTC)