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

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

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.

> 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

Still super bloated compared to the tiniest GIF:

47 49 46 38 39 61 01 00 01 00

00 ff 00 2c 00 00 00 00 01 00

01 00 00 02 00 3b

http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...

So what are the tricks

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

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

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

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.

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

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

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.

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)

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.

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.

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

Some are, but it maight be CPU heavy depending on your platform, acceleration and the numbers of layers/information you have on the screen.

Android application OsmAnd is notoriously slow because of this: https://github.com/osmandapp/OsmAnd/discussions/11961

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

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

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.

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

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

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

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.

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

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

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>

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.

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>

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

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

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

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