Why use an image at all when css background-color exists?
The smallest 256x256 single-color PNG file, and where you've seen it (2015)
81–90 of 104 posts
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#82Earlier quoted context omitted.
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.
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.)
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#83I 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?
A single ocean tile on mapbox is 39 bytes:
1a25 7802 0a05 7761 7465 7228 8020 1217
1803 2213 0980 69e0 7f1a dfa8 0100 00bf
bf01 e0a8 0100 0f
layers {
name: "water"
features {
type: POLYGON
geometry: 9
geometry: 13440
geometry: 16352
geometry: 26
geometry: 21599
geometry: 0
geometry: 0
geometry: 24511
geometry: 21600
geometry: 0
geometry: 15
}
extent: 4096
version: 2
}
And produces this geometry before reprojecting to the tile coordinates:
Layer name: water
Geometry: Polygon
Feature Count: 1
Extent: (0.000000, 0.000000) - (4096.000000, 4096.000000)
Layer SRS WKT:
(unknown)
mvt_id: Integer64 (0.0)
OGRFeature(water):0
POLYGON ((0 0,0 4096,4096 4096,4096 0,0 0))
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#84Earlier 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.)
Decoding JPEG doesn't leave much room for interpretation and the images should essentially always be decoded the same. For encoding, it's a different story, as there are steps to downsample the image data (chrominance data is often, but not necessarily, sampled at a lower rate than luminance data), there can be a different cutoff point for which of the DCT coefficients to discard (usually related to the "compression" or "quality" setting for the compressor). All JPEG decoders should reproduce the same image from a given JFIF file, but I'd be surprised if different encoders produced the exact same JFIF file from a given source image.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#85Earlier quoted context omitted.
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?
Those are both sgml (as opposed to xml) things. Neither validates.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#86Why use an image at all when css background-color exists?
This is the comment I just ctrl-f'd for: exactly?!
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#87Why use an image at all when css background-color exists?
As the article mentions, the browser requests an image and to respond with anything different would take as many bytes if not more.
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#88With 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…
JXL without container has a very short header, which is nice.
WebP is 38 bytes, and is already supported by browsers.
00000000 52 49 46 46 24 00 00 00 57 45 42 50 56 50 38 4c |RIFF$...WEBPVP8L|
00000010 18 00 00 00 2f ff c0 3f 00 07 50 e8 d6 16 ba ff |..../???..P??.??|
00000020 01 00 45 fa ff 9f 22 fa 9f fa df 7f |..E??."?.??.|
data:image/webp;base64,UklGRiQAAABXRUJQVlA4TBgAAAAv/8A/AAdQ6NYWuv8BAEX6/58i+p/6338=
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#89Earlier 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.
You can also drop the new line character by using echo -n, which gives 82 bytes :)
Re: The smallest 256x256 single-color PNG file, and where you've seen it (2015)
#90> Instead of serving a 256x256px image, you can serve a 1px image and tell the browser to scale it up. Of course, if you have to put width= "256px" height= "256px" into your HTML that adds 30 bytes to your HTML!
CSS is a thing as well, could just use CSS to force all tiles to the same size, regardless of the image data in them. Something like:
.map img {
width: 256px;
height: 256px;
}