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

71–80 of 104 posts

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

#71

Post by stefs »

adam_arthur wrote: post #29

Seems 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

i thought so too, but is it actually the case? it's a bit more js code but if pack all your js files there's one less http header. then it's cached. for the image you got the initial size + header (roughly 500 bytes), then it's cached all the same. so, if the additional js gz'd is smaller than 100 bytes of png + gz(400 bytes for the header) it might pay off.

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

#72

Post by berkes »

sophiebits wrote: post #47
Andrew_nenakhov wrote: post #42

Earlier quoted context omitted.

No. It goes only because there are very few browser engines, who mostly can align their behaviour with each other. Protocols with miltiple implementations are way more strict, because you can't feasibly test your quirky approach on every implementation, and the chance they will all be as forgiving is slim.

HTML parsing is well-specced these days.

The parsing is easy. And done in many, many libraries outside of the browsers. (And no, parsing with regex is still not possible, zalgo)

The problem is not parsing of HTML, its the DOM events, CSS application, javascript apis and above all the combination thereof which must be rendered all exactly the same, what makes it hard.

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

#73

Post by rplnt »

cyral wrote: post #24
moron4hire wrote: post #2

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

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

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

#74

Post by moron4hire »

Tabular-Iceberg wrote: post #61
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.

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

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

#75

Post by yread »

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…

Still super bloated compared to the tiniest GIF:

47 49 46 38 39 61 01 00 01 00

00 ff 00 2c 00 00 00 00 01 00

01 00 00 02 00 3b

http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...

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

#76

Post by kuschku »

jancsika wrote: post #52
softgrow wrote: 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">

Every editor adds their own xml namespace to SVG. Inkscape’s being probably the most famous one.

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

#77

Post by tecleandor »

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 are, but it maight be CPU heavy depending on your platform, acceleration and the numbers of layers/information you have on the screen.

Android application OsmAnd is notoriously slow because of this: https://github.com/osmandapp/OsmAnd/discussions/11961

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

#78

Post by michaelt »

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 than Google Maps - the older maps being modelled on printed paper maps)

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

#79

Post by naoqj »

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

I thought that it had existed for decades, but I had confused it for jp2. https://en.wikipedia.org/wiki/JPEG_2000

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

#80

Post by daxterspeed »

yread wrote: post #75
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…

Still super bloated compared to the tiniest GIF: 47 49 46 38 39 61 01 00 01 00 00 ff 00 2c 00 00 00 00 01 00 01 00 00 02 00 3b http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...

If we permit the fairly recent QOI format[0] we can produce a 1x1 transparent pixel in just 23 bytes (14 byte header, 1 byte for QOI_OP_INDEX, 8 byte end marker):

  71 6f 69 66 00 00 00 01 00 00 00 01 04 00 | 14 byte header
  00                                        | QOI_OP_INDEX 
  00 00 00 00 00 00 00 01                   | end marker
Similarly the 103 byte png in the article would be [EDIT] This is incorrect, see below

  71 6f 69 66 00 00 01 00 00 00 01 00 04 00 | 14 byte header
  fe b7 d0 d0                               | QOI_OP_RGB, RGB color, 
  fd fd fd fd c6                            | QOI_OP_RUN for 62+62+62+62+7
  00 00 00 00 00 00 00 01                   | end marker
[0]: https://qoiformat.org/qoi-specification.pdf

[EDIT] I realized that we actually run into one of QOI's drawbacks if we were to encode the 103 byte png in the article, as we actually need to repeat the pixel 65535 times, so we'd have floor(65535/62)=1057 QOI_OP_RUN bytes followed by another QOI_OP_RUN to repeat the last pixel. Here it's pretty clear that the QOI spec missed out on special handling of repeated QOI_OP_RUN operators, as long repetitions could have been handled in far fewer bytes.

Post reply on HN