20 ms·
The smallest 256x256 single-color PNG file, and where you've seen it (2015)
- moron4hire 4y agoEven better would be no image for the water tiles and set the background color of the container element.
- Lammy 4y agoThat might end up looking weird with a dark-mode extension like Dark Reader.
- atli-a 4y agoCouldn't they just use css background-image property to load just one?
- cyral 4y agoYeah 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).
- rplnt 4y ago> Yeah I wonder why that isn't used It's extra handling in the client, request and traffic is still there. Saving few bytes for extra complexity is probably not worth it.
- Tabular-Iceberg 4y agoI 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.
- moron4hire 4y agoBy the time that will be a concern, mapping apps will have been rewritten in JavaScript++ 5 times over.
- leephillips 4y agoIt’s been a concern for several years already. You can visit several planets and their satellites with Google Maps, at least.
- tppiotrowski 4y agoOne 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-elevation-data/#decode-data https://docs.mapbox.com/data/tilesets/guides/access-elevatio...
- danielheath 4y agoI’d suggest jpeg; lossy compression over the full precision data will get you to your target bit rate trivially.
- geenew 4y agoPeople get funny about accuracy in maps. Being able to specify accuracy, even a limited accuracy, is worth a lot. Saving bytes by reducing specified accuracy is in a lot of use-cases better than saving bytes by fuzzing data.
- cmckn 4y agoI take your point; but I don’t think features on an in-browser map are ever small enough for compression artifacts to ruin the integrity of the map.
- danielheath 4y agoYou can compute the maximum error when you encode, which tells you how much precision you can still claim to have
- actionfromafar 4y agoHow? I thought it was up to the JPEG decoder how to actually decode the image into pixels. (Not that JPEG couldn't be workable in practice if some care was put into a solution.)
- LeoPanthera 4y agoThis 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 4y agozopflipng takes the 1189 byte file to 103 bytes for me.
- softgrow 4y agoConvert to svg maybe? For OpenStreetMap 136 bytes <svg xmlns="http://www.w3.org/2000/svg http://www.w3.org/2000/svg" width="256" height="256" viewBox="0 0 256 256"><path d="M0 0h256v256H0z" fill="#aad3df"/></svg>
- lostgame 4y agoBut 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.
- easrng 4y agoYes, it's everywhere.
- RKearney 4y agoYes https://caniuse.com/?search=svg https://caniuse.com/?search=svg
- zinekeller 4y agoWhile yes, you could use SVG today, for performance reasons (not obviously for water, but more complicated stuff like an actual city) raster files are both more efficient in terms of computation time and more consistent in rendering with the only disadvantage of file size tradeoffs. Not quite a concern for computers and dedicated navi systems (in fact Google Earth and the Google Maps apps for iOS and Android* uses vectors, probably not SVG though), but other embedded systems don't really have the luxury of including a proper 3D or even 2D-accelerated drawing (there's a basic chip for raster rendering and relatively fast path drawing but city maps usually contains many geometric paths that overwhelm the graphics processor). * If you know Android Go (not Android Auto), the Maps there are raster due to hardware constraints.
- im3w1l 4y agoThe 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>
- jameshart 4y agoWas 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 4y agoThis 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.
- boomlinde 4y agoI would have guessed that they use quadtrees for this, splitting each non-leaf node into quadrants of more detailed maps as you zoom in.
- incanus77 4y agoIt's a quadtree of sorts, but is typically done via map projection (web mercator) math so that each tile is replaced by four tiles at the next highest (more zoomed-in) zoom level. Number of tiles to cover the world at zoom z = 4^z
- michaelt 4y agoBefore Google Maps came out, online maps all looked like this: https://web.archive.org/web/20060428160705/http://www.multimap.com/map/browse.cgi?client=public&ukwidth=289&ukheight=301&scale=%0D%0A2000000&lang=&overviewmap=GB_over&db=&g.x=211&g.y=242 https://web.archive.org/web/20060428160705/http://www.multim... and this: https://web.archive.org/web/20050528023529/http://maps.yahoo.com/py/maps.py?addr=LGA 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)
- deleted 4y ago[deleted]
- adam_arthur 4y agoSeems 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 4y agoI 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).
- cmeacham98 4y ago> It seems like a Herculean effort to attempt to get browser support for such a thing https://caniuse.com/datauri https://caniuse.com/datauri
- silisili 4y agoData URIs have much more widespread utility than what is being discussed, I think.
- Retr0id 4y agofwiw, JPEG-XL manages to encode the whole image in only 22 bytes.
- eslaught 4y agoPeople can and have written image decoders for custom formats in Javascript [1]. This seems like the same thing but for a very domain-specific use case. Worth it? Not sure. But possible? Definitely. [1]: https://bellard.org/bpg/ https://bellard.org/bpg/
- Retr0id 4y agoWith some dirty hacks, I got it down to 83 bytes: https://cdn.discordapp.com/attachments/286612533757083648/966916647875137576/foo.png 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==
- thrdbndndn 4y agoSo what are the tricks
- Retr0id 4y agoThe first trick is simply "cut the end of the file off". This saves the adler32 checksum on the end of the zlib stream, the crc32 on the end of the IDAT chunk, and the entire IEND chunk. This works because modern browsers have support for progressively rendering images that are still being downloaded - as a result, truncation is also handled gracefully. However, this alone results in rendering errors - the last few rows of pixels end up missing, like this: https://cdn.discordapp.com/attachments/286612533757083648/966914183214014594/foo.png https://cdn.discordapp.com/attachments/286612533757083648/96... I don't know the precise reason for this, but I believe the parsing state machine ends up stalling too soon, so I threw some extra zeroes into the IDAT data to "flush" the state machine - but not enough to increase the file size.
- vmception 4y 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
- aidenn0 4y agogzip 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 4y agoWeb 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/966929643464704060/art.jxl https://cdn.discordapp.com/attachments/286612533757083648/96... base64 data uri version: data:image/jxl;base64,/wp/QCQIBgEALABLOEmIDIPCakgSBg==
- eru 4y agoMost browser do support gzip though. Sort-of transparently on the connection level. So instead of optimizing the size of your file directly, you could optimize the size of what's actually send over the connection. I wonder if that would give you a slightly different png or bmp or so?
- willis936 4y agoI 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 4y agoThat 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.
- willis936 4y agoThis already handled afaict. When I zoom in on apple maps on a stalled data connection I can see the sharp edges of the low resolution vector data until the higher resolution data is downloaded. SVG is convenient but isn't necessary.
- WesolyKubeczek 4y agoOn apple maps the app or on the web? Although I suspect that canvas + some homegrown vector engine it is.
- willis936 4y agoThe app. I'm not sure how the web interface behaves.
- jillesvangurp 4y agoA 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.
- 4y ago
- blenderdt 4y agoThe 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.
- 3OCSzk 4y agoHow did you find out only around 1.8% are viewed?
- blenderdt 4y agoFrom a OSM wiki page. Most of the world is ocean and not a lot of people zoom in on those parts.
- carstenhag 4y agoBut it only applies to 100% water/forest/etc tiles, which when zoomed out only applies to oceans.
- meerita 4y agoTakes more time to request it to the server and loading it in the browser than downloading the resource :)
- schappim 4y agoAnyone else sometimes find it hard to upvote? [1] [1] https://files.littlebird.com.au/Shared-Image-2022-04-22-17-52-37.png https://files.littlebird.com.au/Shared-Image-2022-04-22-17-5...
- validuser 4y agoWhy use an image at all when css background-color exists?
- dingdingdang 4y agoThis is the comment I just ctrl-f'd for: exactly?!
- creativenolo 4y agoAs the article mentions, the browser requests an image and to respond with anything different would take as many bytes if not more.
- rekoil 4y 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; }