Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mjt.me.uk

Post reply on HN
Print view View original

91–100 of 104 posts

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

#91

Post by tyingq »

michaelt wrote: post #78
jameshart wrote: post #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.

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…

>every move and zoom a full pageload

That seems expected, since XMLHttpRequest wasn't really broadly standard until 2003/4 or so. Mapquest and other incumbents didn't move fast enough to use it.

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

#92

Post by billpg »

willis936 wrote: post #56
softgrow wrote: post #51

Earlier quoted context omitted.

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.

That string gzips to 82 bytes. I thought it would be a lot smaller.

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

#93

Post by chipsa »

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?

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

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

#94

Post by michaelt »

tyingq wrote: post #91
michaelt wrote: post #78

Earlier quoted context omitted.

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…

>every move and zoom a full pageload That seems expected, since XMLHttpRequest wasn't really broadly standard until 2003/4 or so. Mapquest and other incumbents didn't move fast enough to use it.

But you could use Javascript to replace one image with another - or to move elements around the page in response to the mouse.

(Back in those days common usage was limited to trivial things like making buttons change colour on mouseover)

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

#95

Post by tyingq »

michaelt wrote: post #94
tyingq wrote: post #91

Earlier quoted context omitted.

>every move and zoom a full pageload That seems expected, since XMLHttpRequest wasn't really broadly standard until 2003/4 or so. Mapquest and other incumbents didn't move fast enough to use it.

But you could use Javascript to replace one image with another - or to move elements around the page in response to the mouse. (Back in those days common usage was limited to trivial things like making buttons change colour on mouseover)

I don't know that would be enough to deal with panning and zooming a tile based map, at least not without some severe hackery.

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

#96

Post by capitainenemo »

doomlaser wrote: post #70
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 ;)

Still sad about the demise of JNG all these years later. There was even a "light" version of the spec to address the complexity issues, and someone in bug #18574 had even made a reference library which took up less space than the default Mozilla libpng, and maintained their own browser branch. It was maintained for a few years but abandoned when it was clear Mozilla was all in on APNG.

But, yeah, we had all those things in something that was actually in major browsers, 22 years ago.

https://bugzilla.mozilla.org/show_bug.cgi?id=18574

http://mngzilla.sourceforge.net/

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

#97

Post by leephillips »

moron4hire wrote: post #74
Tabular-Iceberg wrote: post #61

Earlier quoted context omitted.

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.

By the time that will be a concern, mapping apps will have been rewritten in JavaScript++ 5 times over.

It’s been a concern for several years already. You can visit several planets and their satellites with Google Maps, at least.

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

#98

Post by pornel »

actionfromafar wrote: post #82
danielheath wrote: post #55

Earlier quoted context omitted.

You can compute the maximum error when you encode, which tells you how much precision you can still claim to have

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

For grayscale data there's very little ambiguity, since chroma and colorspace conversions aren't involved. Basically just rounding in DCT, for which you can make reasonable assumptions.

Moreover the JPEG XT spec (not to be confused with JPEG XL or the ton of other X-somethings JPEG made) has specified precisely how to decode the classic JPEG format, and has blessed libjpeg-turbo as the reference implementation.

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

#99

Post by jameshart »

michaelt wrote: post #78
jameshart wrote: post #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.

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…

Such maps presumably still had the issue of ocean tiles.

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

#100

Post by WesolyKubeczek »

willis936 wrote: post #63
WesolyKubeczek wrote: post #62

Earlier quoted context omitted.

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.

On apple maps the app or on the web? Although I suspect that canvas + some homegrown vector engine it is.
Post reply on HN