Live data from Hacker News

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

mjt.me.uk

21–30 of 104 posts

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

#21
post #15
post #14

Earlier quoted context omitted.

>>> len(' '.encode('zip')) 122 Gzipping doesn't save much.

brotli helps: $ echo ' ' | brotli -9 - | wc -c 93

Couldn't resist trying to go further. We can use an implicit viewBox.

  $ echo '' | brotli -9 - | wc -c
  83
r="1000" hits brotlis built-in dictionary, but if you target zlib then r="2566" is better.

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

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

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

#23
post #8
post #5

Convert to svg maybe? For OpenStreetMap 136 bytes http://www.w3.org/2000/svg " width="256" height="256" viewBox="0 0 256 256">

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)

Depending on how you're loading the svg in the page the xmlns attribute may not be needed as well.

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

#24

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

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

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

#26
post #21
post #15

Earlier quoted context omitted.

brotli helps: $ echo ' ' | brotli -9 - | wc -c 93

Couldn't resist trying to go further. We can use an implicit viewBox. $ echo ' ' | brotli -9 - | wc -c 83 r="1000" hits brotlis built-in dictionary, but if you target zlib then r="2566" is better.

Can you use a short closing tag "" or implicit closure?

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

#27

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

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

#28

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.

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.

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

#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  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==
Post reply on HN