![]() Data is more uniformly distributed in the 8-in-7 images, since the ASCII images never set the high bit on any of the bytes, so only really use half of the possible values for each pixel (the dark ones). The 8bit images are red because they only store data in the red channel. The visual representation tells you some interesting things about the code. Here are some of the square image encodings of the jQuery library: It's not practical to view the wide and tall images, since they are several thousand pixels in a single dimension. I calculate MD5 sums of the data returned to check that it's exactly as expected.Īs further bit depth and compressed encodings are used, the image dimensions shrink. The file bake.php creates all of the test images, while unpack.htm checks that you can decode them correctly using Canvas. For various input files, create output images with a combination of shape, bit depth and encoding. I hacked together a quick image generator using PHP and GD. Because of the way internal PNG compression works, some kinds of data will just compress better than others. With all of these changes, the issue isn't information density, but final output size. Since JavaScript & CSS both tend to only use 7-bit ASCII, can we compress things down either further? With 7 bits of data per character, we could pretty easily fit 8 characters into 7 bytes, by just spreading out the bytes: 11111112 22222233 33333444 44445555 55566666 66777777 78888888 I seemed to remember something about image dimensions mattering for PNG size, so try wide, tall and square images and checking for differences seems like a good idea. This would avoid needing the PLTE (palette) block at the start of the image.Īlex used a very tall image, one pixel wide. While Alex was using a fairly straight forward PNG-8 encoding, I wondered what would happen if I tried to put more bytes per pixel - storing 3 bytes per pixel in a PNG-24 or even 4 bytes per pixel in a PNG-32. If this technique is going to be any good, it needs to beat GZipped content for size. This means that we can use GZip compression to serve compressed text (CSS & JavaScript) anyway. ![]() The main way in which the real world differs from the contest is that we care about how many bytes go over the wire, not how many are stored on disk. So I wondered - can this technique be used to make regular web sites faster for very slow connections? The Variables The idea is pretty simple - since the contest limits the size of the final files, you can include more code by putting text inside PNGs and taking advantage of the PNG's internal compression. Updated : There are now some additional results.Īlex Le used a really interesting technique (originally proposed by Jacob Seidelin) for pushing the limits of the 10k Apart Contest - storing JavaScript and CSS in PNG files. 37 PNGStore - Embedding compressed CSS & JavaScript in PNGs ![]()
0 Comments
Leave a Reply. |