0

I have a plan to add images to a chat I've created, but the problem is that I have a small amount of bandwidth to use and I don't want to overstay my welcome, so does this form of file compression seem legitimate and safe? If you open developer tools on any common broswer, you can see how many bytes come in and out of the local compressor, and the elapsed time.

Each result differs on each computer when using the same image, and it uses "image/webp" format when Chrome is available because it uses less space than any other format. GIFs loose their animation and PNGs lose their transparency.

Is there anything I am missing? It combines HTML5's canvas.toDataURL() compression and LZW compression together to deliver maximum results. It works in Chrome and IE10, and I haven't been able to test it on any other browsers. My goal isn't to make it compatible with every browser, but instead to deliver a convenient form of compression.

dylanweber
  • 580
  • 7
  • 19
  • 1
    *Which* form of file compression? Please include everything in the question which is required to answer the question. – user229044 May 22 '13 at 17:56

2 Answers2

3

It combines HTML5's canvas.toDataURL() compression

That's not "compression", it's "encoding", and it's a bad idea. You're not compressing anything, converting the image to a base64-encoded data URI will decompress the image, as you can fit a lot fewer bytes in base64 than you can in actual 256 bit binary encoding. LZW Compressing the resulting text will have negligible benefit.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • base64 encoding adds about 33% overhead. Source: http://php.net/manual/en/function.base64-encode.php – Halcyon May 22 '13 at 17:59
  • Then if I were to convert the data URI's data to a binary string and then use LZW compression, would that make you happy? – dylanweber May 22 '13 at 18:07
  • 1
    No, you shouldn't be applying *any* LZW compression. The format itself is compressed, the browser will do it for you. You're trying to compress already compressed data, which doesn't work. – user229044 May 22 '13 at 18:08
  • I do admit to being a little stupid, but if you read developer.mozilla.org: If the requested type is image/jpeg or image/webp, then the second argument, if it is between 0.0 and 1.0, is treated as indicating image quality; if the second argument is anything else, the default value for image quality is used. Other arguments are ignored. – dylanweber May 22 '13 at 18:09
  • the canvas toDataURL USED to spit out only uncompressed png, which takes a lot of space; jpg will reduce it a lot more than the 33% overhead of b64 encoding... – dandavis May 22 '13 at 18:35
  • The image is *already* a jpeg. Base64 encoding it makes the same data 33% bigger. I'm not talking about conversion between formats; within the *same* format, conversion to Base64 and LZW compression is *not compression*. – user229044 May 22 '13 at 18:38
1

You can put your image in another host. There is plenty of free picture's hosting service out there.

Your bandwidth will be safe, no data transmission require. But it depend of what you need to do with theses pictures ...

0x1gene
  • 3,349
  • 4
  • 29
  • 48