it's midnight and I'm writing a pngbomb generator, what is my life
the png spec is excellent bedtime reading
https://github.com/liclac/pngbomb
only the finest overengineered png bombs on my timeline
I got the 10.000x10.000px sample image down from 147kb to 12kb, but unfortunately the 100.000x100.000 one now takes 13h to generate (up from 10min), because zlib is rather confused at the notion that somebody would want to compress 1.16GB of zeroes
lol nvm get rid of some unnecessary copying and it goes from 13h to 25s
unfortunately, it only saved 46b :( https://github.com/liclac/pngbomb/commit/f0fc2f2a42784557727e44be2f1b86844759a6fa
@embr i liked the bigger on the inside part.
@Ucak same, i'm very proud of it
@embr what's a png bomb?
@lyliawisteria it's in the readme, a small .png (or other image) file, that's crafted to decompress into taking up a humongous amount of RAM when opened
@embr i think i've heard of jpeg and pdf bombs.. i've probably encountered a couple
@embr Pure evil. I like it.
KDE's thumbnailer choked on it at least. Firefox seemed to be mostly fine for me.
@nilsding I love pngbombs for things like this, you get fun results out of the macOS finder and windows explorer too, or if you find a web service that doesn't check bounds properly
I wanna make a much bigger one, but I first need to optimise the compression a bunch more, else they become really unwieldy
I'm now reading the deflate spec because I'm getting annoyed at how there has to be a more efficient way to store a load of zeroes if you can just make some assumptions