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

31–40 of 104 posts

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

#31

Post by twelvechairs »

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…

If file size is your worry and accuracy not, maybe use a lossy format for tiles like JPG or JP2 rather than PNG?

Worth noting DEMs are moving away from tiled formats recently. Mainly to COG (Cloud Optimised Geotiff) which isn't the most efficient but is a simple tweak to a file format already broadly adopted. There's a few others out there aiming for efficency at scale too - ESRI has CRF and MRF for instance, but nothing has become industry standard other than COG yet.

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

#32

Post by thrdbndndn »

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…

So what are the tricks

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

#33

Post by Retr0id »

thrdbndndn wrote: post #32
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…

So what are the tricks

The first trick is simply "cut the end of the file off". This saves the adler32 checksum on the end of the zlib stream, the crc32 on the end of the IDAT chunk, and the entire IEND chunk.

This works because modern browsers have support for progressively rendering images that are still being downloaded - as a result, truncation is also handled gracefully.

However, this alone results in rendering errors - the last few rows of pixels end up missing, like this:

https://cdn.discordapp.com/attachments/286612533757083648/96...

I don't know the precise reason for this, but I believe the parsing state machine ends up stalling too soon, so I threw some extra zeroes into the IDAT data to "flush" the state machine - but not enough to increase the file size.

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

#34

Post by vmception »

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

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

#36

Post by [deleted] »

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…

[deleted]

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

#37

Post by silisili »

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 images. And all for saving some 60 bytes per square.

To be clear I'm not saying it's a bad idea - I'm all for it. It just seems like a pretty edge use case(large blobs of single color images such as oceans in cartoon maps).

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

#38

Post by atli-a »

Lammy wrote: post #7
moron4hire wrote: post #2

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

That might end up looking weird with a dark-mode extension like Dark Reader.

Couldn't they just use css background-image property to load just one?

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

#39

Post by cmeacham98 »

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…

> It seems like a Herculean effort to attempt to get browser support for such a thing

https://caniuse.com/datauri

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

#40

Post by Retr0id »

aidenn0 wrote: post #35

gzip compressed (binary) pbm is only 56 bytes; 32 bytes for zstd compressed data. PBMs have a very simple header and no footer, so the file is almost entirely all zeroes.

Web browsers do not support pbm, last time I checked. On the other hand, the JPEG-XL rollout is well underway (e.g. Chrome supports it behind a feature flag).

The image is only 22 bytes as a jxl:

https://cdn.discordapp.com/attachments/286612533757083648/96...

base64 data uri version:

  data:image/jxl;base64,/wp/QCQIBgEALABLOEmIDIPCakgSBg==
Post reply on HN