Convert to svg maybe? For OpenStreetMap 136 bytes http://www.w3.org/2000/svg " width="256" height="256" viewBox="0 0 256 256">
An inline svg in the parent page would trim it down to 87 bytes and replace code, so even less than 87 in practice.
The smallest 256x256 single-color PNG file, and where you've seen it (2015)
51–60 of 104 posts
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#52Convert to svg maybe? For OpenStreetMap 136 bytes http://www.w3.org/2000/svg " width="256" height="256" viewBox="0 0 256 256">
No post body was provided.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#53One 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…
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 BufferedIm…
Data from sources like GMTED2010 or SRTM15+ is often float32 or even float64: whether it needs to be is another question, but float16 often isn't sufficient in terms of magnitude accuracy (IEEE), and as you mention you often need negative values as well, which for the whole ocean surface of the earth, more than double the range.
To me (working in the VFX industry with EXR being the predominant HDR format), it's interesting that something that compresses a lot better than TIFF (i.e. EXR) hasn't won over in the GIS space, but I believe that's mostly momentum as well as the fact EXR doesn't natively support 64-bit float, but then neither does TIFF really (it's an extension), and the same could be done with EXR (extend the formats it supports).
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#54Earlier quoted context omitted.
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.
I would have guessed that they use quadtrees for this, splitting each non-leaf node into quadrants of more detailed maps as you zoom in.
It'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
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#55Earlier quoted context omitted.
I’d suggest jpeg; lossy compression over the full precision data will get you to your target bit rate trivially.
People 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.
You can compute the maximum error when you encode, which tells you how much precision you can still claim to have
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#56Convert to svg maybe? For OpenStreetMap 136 bytes http://www.w3.org/2000/svg " width="256" height="256" viewBox="0 0 256 256">
An inline svg in the parent page would trim it down to 87 bytes and replace code, so even less than 87 in practice.
That looks like a very low entropy series of bytes to me.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#57I 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?
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#58gzip 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.
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==
Most 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?
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#59The 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.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#60Takes more time to request it to the server and loading it in the browser than downloading the resource :)