WingNews logo WingNews
top | item 31115857

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

482 points| karulont | 3 years ago |mjt.me.uk

101 comments

order

Retr0id|3 years ago

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                                          |��.|
Although technically invalid, it still renders fine in Firefox, Chrome, and Safari.

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==

doomlaser|3 years ago

Hadn't heard of JPEG XL until you mentioned it. The format looks really cool! Support for lossless and lossy compression, animation, and tons of other new features

https://en.wikipedia.org/wiki/JPEG_XL

Preliminary support in Firefox and Chromium nightly/testing builds already. I share your hope that we can start to use it in the next couple years. Looking at you, Safari ;)

dchest|3 years ago

JXL without container has a very short header, which is nice.

WebP is 38 bytes, and is already supported by browsers.

  00000000  52 49 46 46 24 00 00 00  57 45 42 50 56 50 38 4c  |RIFF$...WEBPVP8L|
  00000010  18 00 00 00 2f ff c0 3f  00 07 50 e8 d6 16 ba ff  |..../???..P??.??|
  00000020  01 00 45 fa ff 9f 22 fa  9f fa df 7f              |..E??."?.??.|


  data:image/webp;base64,UklGRiQAAABXRUJQVlA4TBgAAAAv/8A/AAdQ6NYWuv8BAEX6/58i+p/6338=
Maybe can be made smaller, I just used cwebp -z 9.

vmception|3 years ago

> Although technically invalid, it still renders fine in Firefox, Chrome, and Safari.

When I learned HTML the syntax was sooo particular.

Now (our pretty much since then) anything goes and I love it

Natural evolution of protocols

thrdbndndn|3 years ago

So what are the tricks

tppiotrowski|3 years ago

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...

geokon|3 years ago

Not my area of expertise, but in my limited experience DEM tiles are usually GeoTIFF. This can be 16bit greyscale. The catch is that these are actually signed... Elevation doesn't start at 0meters bc you have locations below sea level and you need to handle those corner cases somehow

What's funny is that you can parse a GeoTIFF as a .tiff most of the time but not always. I had fun debugging that :). Java's BufferedImage understandably doesn't directly support negative pixel values haha

tristanc|3 years ago

The PNG format already allows grayscale 16bits / channel images. I regularly use this when rendering out depth maps from blender and ffmpeg seems to handle reading from these PNGs just fine (detecting the gray16 pixel format).

However I don’t know of any DEM tile apis that provide these sorts of PNGs but it sounds like a fun project!

Edit: I found this StackExchange post which shows how to generate 16-bit PNGs with gdal https://gis.stackexchange.com/questions/246934/translating-g...

somishere|3 years ago

Not exactly the same, but I did some work a while back retrofitting 8bit pngs as DEMs with non-linear elevation profiles (in the days when Mapbox only supported 8bit dem uploads). This allowed for fine detail in the range I was most interested in and coarser detail elsewhere. I was also working below sea level, so the standard models weren't suitable. I used gdal and node for the encode to PNG (from high res geotiffs) and then leant on mapbox expressions for the custom decode on the front end. Looked cool and file size was reasonable. Tho I'm certain much cooler things are now possible with 16 bit encode and the new terrain API.

Edit: a link to a mapbox-gl-js discussion on the use of custom dems/encodings (after which anything is possible): https://github.com/mapbox/mapbox-gl-js/issues/10775

twelvechairs|3 years ago

If file size is your worry and accuracy not, maybe use a lossy format for tiles like JPG or JP2 rather than PNG?

Worth noting DEMs are moving away from tiled formats recently. Mainly to COG (Cloud Optimised Geotiff) which isn't the most efficient but is a simple tweak to a file format already broadly adopted. There's a few others out there aiming for efficency at scale too - ESRI has CRF and MRF for instance, but nothing has become industry standard other than COG yet.

danielheath|3 years ago

I’d suggest jpeg; lossy compression over the full precision data will get you to your target bit rate trivially.

Retr0id|3 years ago

JPEG-XL has a lossless mode, and supports custom bit depths and channel counts.

rekoil|3 years ago

> 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;
  }

jameshart|3 years ago

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.

th0ma5|3 years ago

This is a very old term used to try to describe the Google Maps interface to people who never used an octree multidirectional scrolling and zooming image collection.

michaelt|3 years ago

Before Google Maps came out, online maps all looked like this: https://web.archive.org/web/20060428160705/http://www.multim... and this: https://web.archive.org/web/20050528023529/http://maps.yahoo...

View the map a single tile at a time, no dragging the map, no moving by less than a tile, no zooming with the mousewheel, every move and zoom a full pageload.

(You'll also notice the older maps are much higher contrast than Google Maps - the older maps being modelled on printed paper maps)

willis936|3 years ago

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?

WesolyKubeczek|3 years ago

That time when browsers rendered SVG funny if at all was not very long ago.

There’s another challenge: you need to provide more and more data as you zoom in, wonder how that should work with vector stuff.

jillesvangurp|3 years ago

A lot of rendering is vector based these days and uses webgl to do it but there are still a lot of tile servers using images as well. This article is from 2015. Vector maps were less common then and webgl was a lot less mature.

For example maplibre is a great option for rendering vector based openstreet maps from e.g. maptiler or mapbox. They can tilt the maps, render buildings in 3D, have step less zooming, etc.

jleedev|3 years ago

A single ocean tile on mapbox is 39 bytes:

  1a25 7802 0a05 7761 7465 7228 8020 1217
  1803 2213 0980 69e0 7f1a dfa8 0100 00bf
  bf01 e0a8 0100 0f
Decodes to this protobuf:

  layers {                                                                                                                                                                                         
    name: "water"                                                                                                                                                                                  
    features {
      type: POLYGON
      geometry: 9
      geometry: 13440
      geometry: 16352
      geometry: 26
      geometry: 21599
      geometry: 0
      geometry: 0
      geometry: 24511
      geometry: 21600
      geometry: 0
      geometry: 15
    }
    extent: 4096
    version: 2
  }
Geometry interpretation is here: https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4...

And produces this geometry before reprojecting to the tile coordinates:

  Layer name: water
  Geometry: Polygon
  Feature Count: 1
  Extent: (0.000000, 0.000000) - (4096.000000, 4096.000000)
  Layer SRS WKT:
  (unknown)
  mvt_id: Integer64 (0.0)
  OGRFeature(water):0
    POLYGON ((0 0,0 4096,4096 4096,4096 0,0 0))
But of course, this doesn't specify a color, just "the ocean is a rectangle".

chipsa|3 years ago

Some of the newer map tile formats are vectors instead of raster. But technology hasn't quite caught up with that yet. And some things are still better are rasters (like overlaying satellite/aerial imagery).

adam_arthur|3 years ago

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

silisili|3 years ago

I mean, you could. Not a browser author or map maker but thinking it out loud.

This would be a 'rectangle color' specific. Probably 24 bytes to represent height, width, color? It seems like a Herculean effort to attempt to get browser support for such a thing, for a phenomenally rare use case. It would need to be an image format probably and not a browser implementation, since they're usually arranged around other images. And all for saving some 60 bytes per square.

To be clear I'm not saying it's a bad idea - I'm all for it. It just seems like a pretty edge use case(large blobs of single color images such as oceans in cartoon maps).

stefs|3 years ago

i thought so too, but is it actually the case? it's a bit more js code but if pack all your js files there's one less http header. then it's cached. for the image you got the initial size + header (roughly 500 bytes), then it's cached all the same. so, if the additional js gz'd is smaller than 100 bytes of png + gz(400 bytes for the header) it might pay off.

blenderdt|3 years ago

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.

carstenhag|3 years ago

But it only applies to 100% water/forest/etc tiles, which when zoomed out only applies to oceans.

3OCSzk|3 years ago

How did you find out only around 1.8% are viewed?

moron4hire|3 years ago

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

cyral|3 years ago

Yeah I wonder why that isn't used... I can even remove the src from the image and add "background-color: #aad3de" and it looks exactly the same. I'd imagine it's also slightly faster and less memory intensive to render a static background color than to copy the data from an image.

I'm actually surprised they even use DOM nodes for this. Last I checked Google Maps uses a totally custom WebGL based renderer (since it supports 3D and such).

Tabular-Iceberg|3 years ago

I think they don’t want the tile server API have to think about what planet it’s on and where said planet has its oceans. So every tile has to have a valid image associated with it.

Lammy|3 years ago

That might end up looking weird with a dark-mode extension like Dark Reader.

LeoPanthera|3 years ago

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.

edflsafoiewq|3 years ago

zopflipng takes the 1189 byte file to 103 bytes for me.

softgrow|3 years ago

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>

im3w1l|3 years ago

The png is only 103 bytes though. Btw your svg can be decreased by changing viewBox to 0 0 1 1, and also by changing the path to a circle (implicitly positioned at 0, 0)

  <svg xmlns="http://www.w3.org/2000/svg" width="256" height="256" viewBox="0 0 1 1"><circle r="2" fill="#aad3df"/></svg>

lostgame|3 years ago

But the PNG provided was 103 bytes :3

Also - pardon my ignorance, this may be a dumb question, is SVG universally supported in browsers these days? I’m not big up on image standards.

softgrow|3 years ago

An inline svg in the parent page would trim it down to 87 bytes and replace <img> code, so even less than 87 in practice.

<svg width="256" height="256"><rect width="100%" height="100%" fill="#aad3df" /></svg>

jancsika|3 years ago

<svg xmlns="dear user agent, if you happen to run into a problem resolving ambiguities with any of the following tags, please use the namespace for Scalable Vector Graphics and not, say, one of the zero other contexts that xml ninjas will no doubt create over the next two decades of what I can only surmise will be a glorious outpouring of richness and complexity. I mean, we went to the trouble of creating a dang URL for the thing, so it's the least you could do. That is, aside from doing nothing, in which case Hixie will probably write a parser to just handle it. Best wishes, W3C. P.S. Cannot wait to see all the Javascript-driven SVG content that users will upload to social media. Look out, animated gif-- your days are numbered!"><path d="animateYourSVGArcFlagsFTW" /></svg>

validuser|3 years ago

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

creativenolo|3 years ago

As the article mentions, the browser requests an image and to respond with anything different would take as many bytes if not more.

dingdingdang|3 years ago

This is the comment I just ctrl-f'd for: exactly?!

aidenn0|3 years ago

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.

Retr0id|3 years ago

Web browsers do not support pbm, last time I checked. On the other hand, the JPEG-XL rollout is well underway (e.g. Chrome supports it behind a feature flag).

The image is only 22 bytes as a jxl:

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

base64 data uri version:

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

meerita|3 years ago

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