The smallest 256x256 single-color PNG file, and where you've seen it (2015)

With some dirty hacks, I got it down to 83 bytes:

https://cdn.discordapp.com/attachments/286612533757083648/96...

  00  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
  10  00 00 01 00 00 00 01 00  01 03 00 00 00 66 bc 3a  |.............f�:|
  20  25 00 00 00 03 50 4c 54  45 b5 d0 d0 63 04 16 ea  |%....PLTE���c..�|
  30  00 00 00 1b 49 44 41 54  68 81 ec c1 01 0d 00 00  |....IDATh.��....|
  40  00 c2 a0 f7 4f 6d 0f 07  14 00 00 00 00 00 00 00  |. �Om..........|
  50  c0 b9 01                                          |��.|

Edit: 87 -> 83 bytes

Edit2: Maybe in a couple of years time, we can use JPEG-XL instead (only 22 bytes, without any hacks!):

  data:image/jxl;base64,/wp/QCQIBgEALABLOEmIDIPCakgSBg==

One thing I've wondered about are size savings for DEM tiles. Typically elevation values are encoded in RGB values giving a resolution down to fractions of an inch [1]. This seems like overkill. With an elevation range from 0 - 8848 meters (Mt everest), you can use just 2 bytes and get an accuracy down to .2 meters. That seems plenty for many uses. Does anybody know if there's a PNG16 format where you can reduce the file size by only using 2 bytes per pixel, instead of the typical 3-byte RGB or 4-byte RGBA?

[1] https://docs.mapbox.com/data/tilesets/guides/access-elevatio...

> Instead of serving a 256x256px image, you can serve a 1px image and tell the browser to scale it up. Of course, if you have to put width= "256px" height= "256px" into your HTML that adds 30 bytes to your HTML!

CSS is a thing as well, could just use CSS to force all tiles to the same size, regardless of the image data in them. Something like:

  .map img {
    width: 256px;
    height: 256px;
  }

Was new to me, but it seems "slippy map" is open-streetmap's terminology for a generic zoomable-pannable web map view, here used to refer to any such UI - whether backed by OSM or google or bing or whoever's map data.

Feels like a weird word choice to me, when 'map' was right there, but who are we to judge.

I love image formats and data packing, but was disappointed that the reveal was that maps use raster tiles. The map data is vector, why not render it as such?

Seems a lot more performant to generate single color images programatically rather than sending it over the wire?

Assuming this level of optimization is actually warranted

The difference between the OSM and Google tile is 75 bytes. So if they serve one million tiles OSM saved 75MB.

OSM needs 54TB for all tiles but only around 1.8% are viewed. So you need at least 1TB of cache.

I am curious if this micro optimalization really makes a difference.

Even better would be no image for the water tiles and set the background color of the container element.

This is one example where "zopfli" or other optimized zlib compressors don't help, the input data is too simple.

"oxipng" (my current preferred png optimizer) bring a plain 256x256 image created with imagemagick down to 179 bytes, as long as you tell it to strip all metadata objects.

Interlacing doesn't make any difference, it's the same size with it on or off.

Convert to svg maybe?

For OpenStreetMap 136 bytes

<svg xmlns="http://www.w3.org/2000/svg" width="256" height="256" viewBox="0 0 256 256"><path d="M0 0h256v256H0z" fill="#aad3df"/></svg>

Why use an image at all when css background-color exists?

gzip compressed (binary) pbm is only 56 bytes; 32 bytes for zstd compressed data. PBMs have a very simple header and no footer, so the file is almost entirely all zeroes.

Takes more time to request it to the server and loading it in the browser than downloading the resource :)

Anyone else sometimes find it hard to upvote? [1]

[1] https://files.littlebird.com.au/Shared-Image-2022-04-22-17-5...