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

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

#61

Post by Tabular-Iceberg » Fri, Apr 22, 2022, 7:09 AM UTC

moron4hire wrote: post #2

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

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.

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

#62

Post by WesolyKubeczek » Fri, Apr 22, 2022, 7:11 AM UTC

willis936 wrote: post #57

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?

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.

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

#63

Post by willis936 » Fri, Apr 22, 2022, 7:16 AM UTC

WesolyKubeczek wrote: post #62

willis936 wrote: post #57

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?

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.

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

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

#64

Post by 3OCSzk » Fri, Apr 22, 2022, 7:42 AM UTC

blenderdt wrote: post #59

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.

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

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

#65

Post by jillesvangurp » Fri, Apr 22, 2022, 7:51 AM UTC

willis936 wrote: post #57

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?

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.

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

#66

Post by somishere » Fri, Apr 22, 2022, 7:52 AM UTC

tppiotrowski wrote: post #3

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…

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

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

#67

Post by schappim » Fri, Apr 22, 2022, 7:53 AM UTC

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

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

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

#68

Post by blenderdt » Fri, Apr 22, 2022, 8:06 AM UTC

3OCSzk wrote: post #64

blenderdt wrote: post #59

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.

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

From a OSM wiki page. Most of the world is ocean and not a lot of people zoom in on those parts.

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

#69

Post by carstenhag » Fri, Apr 22, 2022, 8:11 AM UTC

blenderdt wrote: post #59

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.

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

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

#70

Post by doomlaser » Fri, Apr 22, 2022, 8:47 AM UTC

Retr0id wrote: post #30

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…

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