I bet a hand crafted png can be smaller still, we used png for video games back in the day and there were some heavy tweaking bringing them down to close to nothing (removing all metadata, reducing the number of colors, …).
Maybe they were bigger than 1kb, gotta dig up some examples…
The maximum color quantization you can do on this image without huge information errors is something like:
1x yellow-brown for stars / streamers / shorts / socks
1x brown for tree base (though it might be better to remove the base to save a color)
1x red for baubles / hat / sweater / shoes
1x green for tree
1x blue for hair (potentially you could merge the tree color if you want to really push it)
1x skin tone for skin
1x pink for mouth
1x black for lines
1x light yellow for background
Which is 9 total colors. This would also require living with aliased text ( c r u n c h y ), since it would be data-expensive to add extra shades of gray. At that point you’re no longer making a low-quality copy of the original - you’d basically be making a pixel art version of it since you can’t afford any colors for anti-aliasing and gradients.
Here’s an example PNG with 9 unique colors and some pretty simple patterns without huge information density: https://files.catbox.moe/bj0acl.png
Even that’s 1,847 bytes! (i.e., basically 2KB)
Edit: I made a big (in hindsight, obvious) mistake by forgetting I can literally just change the bit depth of the image when saving, so the example I’ve provided is actually very inefficient by comparison. Valmond has set me straight.
Finally somewhere my knowledge of anime can improve the world! The character is Yotsuba and her hair is green, not blue, so one color for both the tree and her hair is absolutely fine!
Did you use some specific soft to compress the png & get rid of the meta data? Because if you don’t then it will be way bigger.
Also, you could anti alias the text with colours, that’s how it’s done on screens toaday, you just don’t see it from afar. And lastly, you could reduce the colorspace even more by reusing similarish colors.
I dug up some examples, I don’t have the talent needed to remake that, nor the executables for it but this is what people could compress back in the day:
699 bytes:
923 bytes:
1.4kb:
The same but smaller so 770 bytes:
and some eye candy:
2.3kb:
2.1kb:
10kb !
So yeah, hard to push that original under 1kb I guess, but who knows ^^ !
Shit, you’re absolutely right, I missed an (in hindsight very obvious) optimization - bit depth. It’s been so long since I’ve actually needed to worry about it that I forgot that the setting existed! What makes it even worse is that I did already play with quantizing the colors dwon to a more limited space, I just never baked that in as the bit depth haha.
To be honest I’m not sure if the metadata actually matters much or not (I’ve never had to ultra-optimize like this before), but I just ran it through a PNG size optimizer and let it figure it out haha.
It’s quite challenging to keep the text legible within a 1KB limit. Here I manually removed a few details that more-or-less weren’t visible post-compression anyway, then cut the color palette a little. You have to use such a low resolution with such high compression that almost everything gets amputated to keep the text kinda-readable (and even AVIF and JPEG XL (which are usually better than WebP) struggled, at least in my editor): https://files.catbox.moe/eyp2w7.webp
Valmond’s implicit suggestion of not just quantizing as a pre-processing step (which is what I foolishly did), but actually reducing the saved bit depth of the image might give you something that looks much better overall than what any of the WebP versions we’ve been playing with here do - if you put in more effort!
Here’s an example of a not-fully-optimized implementation that gets down to ~2.5KB as a PNG, or ~2KB as a lossless WebP (i.e., the two images are identical in quality):
With some judicious manual optimization (which I haven’t done here), it’s plausible you could get this down to 1KB with better overall fidelity than the lossy WebP versions we’ve been playing with. Not 100% sure, as optimizing images for file sizes this small is not really my wheelhouse!
My main concern with this approach is that you’re bottlenecked by resolution - large areas of plain color have a hard limit on their compression with PNG, but lossy compression can go wild with stuff like that.
Responding to Valmond’s comment got me thinking about doing some more pre-processing to assist the compression, so here are three more 1KB versions which I think are slightly improved:
since the 1kb example was actually 1.1kb I re-made it while also improving the quality ten-fold
(check it out - it really is 1kb!)
I bet a hand crafted png can be smaller still, we used png for video games back in the day and there were some heavy tweaking bringing them down to close to nothing (removing all metadata, reducing the number of colors, …).
Maybe they were bigger than 1kb, gotta dig up some examples…
The maximum color quantization you can do on this image without huge information errors is something like:
Which is 9 total colors. This would also require living with aliased text ( c r u n c h y ), since it would be data-expensive to add extra shades of gray. At that point you’re no longer making a low-quality copy of the original - you’d basically be making a pixel art version of it since you can’t afford any colors for anti-aliasing and gradients.
Here’s an example PNG with 9 unique colors and some pretty simple patterns without huge information density: https://files.catbox.moe/bj0acl.png
Even that’s 1,847 bytes! (i.e., basically 2KB)
Edit: I made a big (in hindsight, obvious) mistake by forgetting I can literally just change the bit depth of the image when saving, so the example I’ve provided is actually very inefficient by comparison. Valmond has set me straight.
Finally somewhere my knowledge of anime can improve the world! The character is Yotsuba and her hair is green, not blue, so one color for both the tree and her hair is absolutely fine!
Nice!
Did you use some specific soft to compress the png & get rid of the meta data? Because if you don’t then it will be way bigger.
Also, you could anti alias the text with colours, that’s how it’s done on screens toaday, you just don’t see it from afar. And lastly, you could reduce the colorspace even more by reusing similarish colors.
I dug up some examples, I don’t have the talent needed to remake that, nor the executables for it but this is what people could compress back in the day:
699 bytes:
923 bytes:
1.4kb:
The same but smaller so 770 bytes:
and some eye candy:
2.3kb:
2.1kb:
10kb !
So yeah, hard to push that original under 1kb I guess, but who knows ^^ !
Merry Christmas !
Shit, you’re absolutely right, I missed an (in hindsight very obvious) optimization - bit depth. It’s been so long since I’ve actually needed to worry about it that I forgot that the setting existed! What makes it even worse is that I did already play with quantizing the colors dwon to a more limited space, I just never baked that in as the bit depth haha.
To be honest I’m not sure if the metadata actually matters much or not (I’ve never had to ultra-optimize like this before), but I just ran it through a PNG size optimizer and let it figure it out haha.
awesome! but no text :(
It’s quite challenging to keep the text legible within a 1KB limit. Here I manually removed a few details that more-or-less weren’t visible post-compression anyway, then cut the color palette a little. You have to use such a low resolution with such high compression that almost everything gets amputated to keep the text kinda-readable (and even AVIF and JPEG XL (which are usually better than WebP) struggled, at least in my editor): https://files.catbox.moe/eyp2w7.webp
If you can live with 2KB, you don’t have to amputate nearly as much: https://files.catbox.moe/g5htfo.webp
In both cases I manually reconstructed the top of the star, but that’s a bit “extra” lol.
And just for comparison, no text and 10KB at “full” res: https://files.catbox.moe/9bkn21.webp
The same thing but half res (more optimal at this file size): https://files.catbox.moe/cac65u.webp
Valmond’s implicit suggestion of not just quantizing as a pre-processing step (which is what I foolishly did), but actually reducing the saved bit depth of the image might give you something that looks much better overall than what any of the WebP versions we’ve been playing with here do - if you put in more effort!
Here’s an example of a not-fully-optimized implementation that gets down to ~2.5KB as a PNG, or ~2KB as a lossless WebP (i.e., the two images are identical in quality):
With some judicious manual optimization (which I haven’t done here), it’s plausible you could get this down to 1KB with better overall fidelity than the lossy WebP versions we’ve been playing with. Not 100% sure, as optimizing images for file sizes this small is not really my wheelhouse!
My main concern with this approach is that you’re bottlenecked by resolution - large areas of plain color have a hard limit on their compression with PNG, but lossy compression can go wild with stuff like that.
A competitor approaches!
new image, 988 bytes, with text, 125x180 pixels (more quality then your 92x128 1kb)
https://files.catbox.moe/eqbk4e.webp
This is indeed way better!
Tysm
Spending too long editing 1KB images is the true meaning of Christmas
Responding to Valmond’s comment got me thinking about doing some more pre-processing to assist the compression, so here are three more 1KB versions which I think are slightly improved:
i truly love how beautiful this community is sometimes <3
That’s the improvement.
True. Reading sucks. This isn’t school.
❌
would need a high-quality version of the one with text to start with
☝️🤓
fuck, uhhh here’s a less then 1kb one, it counts, right? right?