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

41–50 of 104 posts

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

#41

Post by silisili »

cmeacham98 wrote: post #39
silisili wrote: post #37

Earlier quoted context omitted.

I mean, you could. Not a browser author or map maker but thinking it out loud. This would be a 'rectangle color' specific. Probably 24 bytes to represent height, width, color? It seems like a Herculean effort to attempt to get browser support for such a thing, for a phenomenally rare use case. It would need to be an image format probably and not a browser implementation, since they're usually arranged around other im…

> It seems like a Herculean effort to attempt to get browser support for such a thing https://caniuse.com/datauri

Data URIs have much more widespread utility than what is being discussed, I think.

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

#42

Post by Andrew_nenakhov »

vmception wrote: post #34
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…

> Although technically invalid, it still renders fine in Firefox, Chrome, and Safari. When I learned HTML the syntax was sooo particular. Now (our pretty much since then) anything goes and I love it Natural evolution of protocols

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.

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

#43

Post by zinekeller »

lostgame wrote: post #6
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">

But the PNG provided was 103 bytes :3 Also - pardon my ignorance, this may be a dumb question, is SVG universally supported in browsers these days? I’m not big up on image standards.

While yes, you could use SVG today, for performance reasons (not obviously for water, but more complicated stuff like an actual city) raster files are both more efficient in terms of computation time and more consistent in rendering with the only disadvantage of file size tradeoffs. Not quite a concern for computers and dedicated navi systems (in fact Google Earth and the Google Maps apps for iOS and Android* uses vectors, probably not SVG though), but other embedded systems don't really have the luxury of including a proper 3D or even 2D-accelerated drawing (there's a basic chip for raster rendering and relatively fast path drawing but city maps usually contains many geometric paths that overwhelm the graphics processor).

* If you know Android Go (not Android Auto), the Maps there are raster due to hardware constraints.

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

#44

Post by Retr0id »

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…

JPEG-XL has a lossless mode, and supports custom bit depths and channel counts.

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

#45

Post by Retr0id »

silisili wrote: post #37
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 mean, you could. Not a browser author or map maker but thinking it out loud. This would be a 'rectangle color' specific. Probably 24 bytes to represent height, width, color? It seems like a Herculean effort to attempt to get browser support for such a thing, for a phenomenally rare use case. It would need to be an image format probably and not a browser implementation, since they're usually arranged around other im…

fwiw, JPEG-XL manages to encode the whole image in only 22 bytes.

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

#46

Post by cmckn »

geenew wrote: post #17
danielheath wrote: post #16

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

I take your point; but I don’t think features on an in-browser map are ever small enough for compression artifacts to ruin the integrity of the map.

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

#47

Post by sophiebits »

Andrew_nenakhov wrote: post #42
vmception wrote: post #34

Earlier quoted context omitted.

> Although technically invalid, it still renders fine in Firefox, Chrome, and Safari. When I learned HTML the syntax was sooo particular. Now (our pretty much since then) anything goes and I love it Natural evolution of protocols

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.

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

#48

Post by boondaburrah »

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.

parsing was never so much the problem as what was rendered afterwards being different.

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

#49

Post by boomlinde »

th0ma5 wrote: post #28
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.

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.

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

#50

Post by eslaught »

silisili wrote: post #37
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 mean, you could. Not a browser author or map maker but thinking it out loud. This would be a 'rectangle color' specific. Probably 24 bytes to represent height, width, color? It seems like a Herculean effort to attempt to get browser support for such a thing, for a phenomenally rare use case. It would need to be an image format probably and not a browser implementation, since they're usually arranged around other im…

People can and have written image decoders for custom formats in Javascript [1]. This seems like the same thing but for a very domain-specific use case.

Worth it? Not sure. But possible? Definitely.

[1]: https://bellard.org/bpg/

Post reply on HN