图好快｜常见问题，批量在线压缩50-5000张图片，图片压缩，图片加速API，图片加速
问：图好快是做什么的？
1, 图好快专门为用户提供各种批量图片压缩服务（包括JPG，JPEG，PNG和GIF）。
2, 图好快提供整站图片全自动压缩服务，能对客户网站上所有的图片进行自动压缩及优化。
问：图好快能解决南北通问题吗？
能，整站图片自动压缩服务能解决南北通问题。
问：图好快能解决国内外访问速度吗？
能，整站图片自动压缩服务能解决国外访问的速度问题。
问：为什么要试用图好快？
网站或App不应该在需要一张小图的地方去调用很大的图片。合理得压缩图片能让您的网站和App打开更快。
问：PNG图片也能压缩吗？
1, 图好快压缩的PNG图片能保留原来的Alpha通道。即透明的原图，压缩出来的图片也是透明的。
2, 有的网站编辑在截屏取图时会把文件保存为PNG格式，这样文件会很大。图好快对这类图片优化效果尤其显著。
问：GIF图片也能压缩吗？
使用我们的缩略图规则，减小图片的宽高也会使GIF文件相应变小。
问：整站全自动压缩图片的功能需要用户上传图片吗？
图好快会全自动处理。详情可咨询QQ或微信客服。
问：网站图片全自动压缩部署起来方便吗？
答：很方便。用户只要修改一下图片的地址就可以了。图好快可提供技术支持，详情可咨询QQ或微信客服。一例奇怪的doc文件中图片压缩的问题
为什么我们压缩图片后的文档，大小没有明显减小？我因为修改制作一个简报，发现了一个相当隐秘的问题，并且搞懂了它！
简报的初稿是老秦做的。他大概是用插入-图片的方法，在写好的doc文档中插入了几张照片。照片的像素很高，每张照片都大约占用5M以上的空间，他又不懂得图片压缩——因此，到我手里时，吓了我一跳——这个doc文档的大小已经超过了55M。
于是，我修改了部分文字，又用QQ截图的方法，增加了一些图片素材进去，然后选择压缩图片——文档中的所有图片——打印
&分辨率200dpi，然后我查看文件大小，现在在增加了不少图片的情况下，文件大小是33M。然后另存为PDF文件，pdf文档的大小为18M。
怎么文件还是偏大？尽管心中还是隐隐有些奇怪，但我还是以为事情就到此搞定了。
然后我需要在网页发布这个简报。
因为简报中的照片是已经选出来的，我难得再次到海量的原片中去寻找了，于是直接右键点击图片，选择“另存为图片”，呃……（因为我用的是WPS2012，有这个功能，在word中是没有这个功能的）。
怪事发生了，有部分图片默认的格式是jpg，但还有些图片默认的格式是png！开始我没主意，重选格式为jpg就是了，但是几次以后，我觉得不对了！&同样的doc文档中的图片，怎么会有两种不同的格式呢？
这是第一个问题。
还有一张图片，另存后才发现其大小居然还是源文件的大小，我不是选择了“文档中的所有图片”，都压缩了的吗？&将这张图片单独再压缩一次，整个文档的大小就变成了27M！
根据我将pdf文件导出为图片格式的经验，导出的png图片比导出的jpg图片要大很多倍。以这次的简报文档为例，全照片的页导出的png图片大约要2M，而jpg文件仅仅240k左右，大小相差9倍左右！
我突然想到，难道在doc文档中存储的图片仍然是有格式差异的？如果存储的都是png图片，怎么压缩也不会小，反之，如果是存储的jpg图片，文件就应该小下去了！通过对比pdf文档导出的两种格式，一共14页的简报，导出的jpg图片大小是3.03M，而png图片大小达到了13.8M！
于是，继续试验，我用&wps中的“另存为图片”功能将所有png图片另存为jpg图片，然后重新导入doc文档中，替换掉原来的png图片，保存，现在文档的大小，从之前的27M，变成3.03M了！——简直是超级大瘦身啊！
为了将问题弄得更明白，我决定继续试验！
我用一张的分辨率的照片，图片大小为295KB。一个文档用jpg格式直接插入doc文档中，另一个文档用截屏的方式截屏粘贴到doc文档中，两个doc文档的大小会有什么不同呢？结果吓我一跳！下面给出截图：
由两个doc文档属性的截图可以看到，尽管两个文档显示的图片和效果几乎完全相同，但直接插入jpg图片的文档只有307KB，而通过QQ截屏功能截取原图同等大小的屏幕显示图，然后粘贴到doc文档中的方式，其doc文档竟然达到了1.7MB！将两个文档中的图片另存为，一个默认jpg格式，一个默认png格式！
现在我来将两个文档中的图片进行压缩后比较。点击文档中的图片，在图片工具栏选择压缩图片，同样选择“打印
分辨率200dpi”，然后确定，如下图：
现在，会发生什么情况呢？比较两个doc文档的属性……
插入jpg图片的文档体积从305KB变成了170KB，说明确实被压缩了。可是截屏图片插入的doc文档，大小完全没有变化！说明压缩操作无效！
我彻底无语了……
当别人的文档因为插入了图片而体积过大时，我常常建议他们用QQ截屏的方式来缩小文件体积。但是，从今天的发现来看，这样的做法，表面上是缩小了体积，但是因为doc文件内部图片格式的关系，实际上截屏粘贴的图片，在压缩图片时几乎是无效的！这就是困惑了我许久的”压缩图片“命令效果很差的根本原因！而插入的jpg图片，表面上可能很大，但一经压缩，文件体积迅速减小，反而没有问题了。
哈哈，终于弄懂了……下一步……我做PPT的时候，最喜欢用截屏的方式获取图片了。这些PPT中的图片，是不是有着同样的问题呢？
看来啊，我做的PPT的体积，其实完全可以进一步缩小呢！
谨以此文，牢记此教训，下次做文件，所有图片正规插入，然后压缩图片减小体积！
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。JavaScript 图片压缩问题？
&del&本人尝试使用 canvas 2d 来重绘图片并且给服务器返回dataurl但是 iOS（移动端） 的 Safari 对于 canvas 2d 绘制图片 超过2M 会直接中断。并且返回 data:; 空 base64 URL 信息。&/del&好了， 问题已经解决了。 不用作答了。 谢谢各位方法本人已经自答
按投票排序
用户本地的图片体积都很大，尺寸不变的绘制的确会失败。如果要保证尺寸不变的上传，一般就直接FileReader读取文件然后塞到formdata中，不压缩上传文件，还想前端压缩，估计只能尝试把大图分解成多个瓦片来逐个绘制然后逐个上传，后端再拼接实现了。如果能接受修改绘制尺寸，那就好办多了，把大图绘制到一个等比的小canvas上，然后读取这个小canvas的base64上传。另外，上传base64字符串其实不是一个很好的方案，base64的体积很大，这里贴一下twitter的图片上传逻辑：// 压缩前的代码
convertCanvasToBlob:function(e){var t,i,s,n,r,a,o,c;for(n="image/jpeg",t=e.toDataURL(n),i=window.atob(t.split(",")[1]),r=new window.ArrayBuffer(i.length),a=new window.Uint8Array(r),s=0;s&i.length;s++)a[s]=i.charCodeAt(s);return o=window.WebKitBlobBuilder||window.MozBlobBuilder,o?(c=new o,c.append(r),c.getBlob(n)):new window.Blob([r],{type:n})}
function convertCanvasToBlob(canvas) {
var format = "image/jpeg";
var base64 = canvas.toDataURL(format);
var code = window.atob(base64.split(",")[1]);
var aBuffer = new window.ArrayBuffer(code.length);
var uBuffer = new window.Uint8Array(aBuffer);
for(var i = 0; i & code.length; i++){
uBuffer[i] = code.charCodeAt(i);
var Builder = window.WebKitBlobBuilder || window.MozBlobBuilder;
if(Builder){
var builder = new Builder;
builder.append(buffer);
return builder.getBlob(format);
return new window.Blob([ buffer ], {type: format});
这是它触屏版上传前的图片压缩逻辑之一，就是在前端把base64转成二级制数据，这个数据体积相比base64小很多，还可以塞到formdata中提交，不过不支持android 2及以下，ios 5.1及以下版本的浏览器。我猜你的业务可能也是想实现类似这样的图片上传功能，分析twitter的源码可能会对你有一些帮助====【补刀】====评论中，提问者
找到了一个开源的实现
这个已经实现了瓦片绘制、最终结果转Blob，考虑全面，应该可以拿来直接用了
好了， 问题已经解决了， 大家不用回答了， 谢谢由于 IOS 的限制， 所以思路是将 图片分解成 若干块， 一块一块来进行绘制。最后拼在一张画布上， 则不会出现不能绘制的情况。其次， 在绘制的过程中， 每次绘制一块，绘制大小也不能超过2M否则～ ， canvas 一样会被挂起。 故：国外的项目大家可以参考一下： 注： 如果 IOS 上传图片依然是 2M 以上的大小， 那么绘制时候要调试最大宽度限制， 一般是2000px 的宽度 （2000px 最大图片宽度 的分辨率你还想怎么样。。。）可看源码
使用js版本的zlib ，取出canvas的imagedata像素数据 ，用zlib对其压缩，将结果传给服务器。
没想到还能这么玩
题主，这个功能我刚做过，用的是图片转base64data。坑巨多，一点都不好。之所以超过2M就中断，是因为tomcat（其它容器不知道）的POST请求最大传输数据默认限制为2M，有一个参数maxPostSize可以修改这个限制。
已有帐号？
无法登录？
社交帐号登录关于JPG格式图像的品质压缩疑问如何查看JPG图像的品质.如果把质量本身不高的JPG图像转成最佳,这样文件大小变大了,质量会发生怎样的变化?如果重复另存相同的质量,比如品质8另存两次,会不会形成二次压缩导致图像标准质量越来越差?
1、查看图像品质,可以用一些比较高级的看图软件,比如ACDSee、XnView,在其中显示文件属性,就会有“质量”（或类似的词）一项,就显示图片质量.2、果把质量本身不高的JPG图像转成最佳,只会增加图片大小,图像质量不会增加,反而会略微下降.因为每次保存,都会压缩,只不过压缩程度不同.3、品质8另存两次,会导致质量越来越差.同上,每次保存,都会压缩.如果还需要修改,建议保存tif或psd格式.额外,每次图像编辑软件打开jpg文件,无论它的初始质量是多少,软件都默认这是原始文件,在保存时,会在这次的基础上压缩,而不是在最初的原始文件基础上压缩.
问题二追问：那是不是另存反而增加了大小，就说明另存的质量超过了原有质量，是多余的举措，应当另存成大小一样的品质才能最大效益（质量和大小都最佳）的保存原有文件？
并不是文件越大，质量越好。
第二次保存时，会把第一次压缩造成的“杂色”当做文件的一部分，保存所有细节。
增加的文件大小，来源于 不需要的杂色，而不是提高了图片质量。
如果原始文件是jpg，只保存一次，建议保存为10左右即可，不需要保存到12.
因为肉眼无法区分10、12的区别（Photoshop中，图像质量从0到12）
道理上，另存成大小一样的品质才能最大效益。
但实际很少有人刻意在乎这个
需要编辑的保存为psd或tif，不需要编辑的，保存为质量为10的jpg
以你的例子那么万一要二次保存应当保存多少品质为好？
一句话，你非要保存成jpg的话，
如果还需要下次编辑，保存最高质量
不需要下次编辑，保存高质量，10左右
当然，特殊用途，比如预览图、网上图片等，中等质量甚至低质量均可
如果要质量最大化，保存时就选最高质量就是12吧，那样不是会增大文件大小吗？你说的不需要的杂色具体是什么意思，能浅白一点解释嘛？
如果要质量最大化，保存时就选最高质量就是12，会增加文件大小。
如果保存的质量很低，图像就会出现彩色的点，就是杂色，你找一找图，保存成质量很低的图，就看到了。
。那问题的关键是选择了12会增加了多余的文件大小，这个大小是从哪里加上去的，质量高不是杂色更少不是应该大小不变吗？而你又说10跟12肉眼分别不了，，那又何必保存为最高？
这个大小，是图像细节加上去的。软件把原本的杂色也当做细节，仔细保存了
肉眼不可分辨，但软件可以分辨啊，
为您推荐：
扫描下载二维码}