satan

注： 原文地址是 http://yuiblog.com/blog/2008/11/14/imageopt-3/

这篇文章是一些你可以用来减小你的图片文件大小的普通工具。 想法是让你可以把你的设计师刚创建好的图片拿过来， 不用花费精力， 甚至都不用看， 就可以把他们整小， 并且跟原来一样。

这个过程的好消息是：
无损的 – 你去除了字节， 所以你的一些信息丢失了， 不过不是像素信息， 你的结果图片也看起来跟源图片一样， 没有质量的损失。
使用免费的工具 – 所有的我们提到的工具都是免费的， 开源的， 都可以再windows和unix 上使用
自动化的 – 因为这些都是命令行工具， 所以他们都很容易编成自动化脚本； 一个自动化的例子就是 smush.it 工具.

第一步：压缩PNG
PNG 把图片的信息存贮在所谓的”块“里面， 不是所有的块都是在显示图片的时候必须的。 事实上， 大部分都不是， 你可以使用类似 pngcrush 这样的工具安全的把所有不需要的块移除掉. 例：

> pngcrush -rem alla -brute -reduce src.png dest.png

我们来看看这个命令的选项：

• src.png 是源图片， dest.png 是目标图片
• -rem all 意思是删除透明块之外所有的块
• -reduce 试图减少调色板中的颜色假如可能的话
• -brute 试图使用默认10种之外的100 多种不同的方法优化图片。 这是很慢，的过程， 并且不会有大的改进。但是你只是在”线下做这个过程， 能赢得文件大小，一两秒甚至更多都不重要了。在一些性能敏感的场景把这个选项移除

用这个命令跑Alexa上排名前十的网站上的PNG突破， 我们平均减小16.05%的文件大小。这意味着你很简单的就给你的PNG图片减肥了， 节省了带宽和磁盘空间， 也改进了加载时间， 而不用牺牲图片质量， 甚至都不用更改任何一行程序代码。

PNGcrush 是这类优化的唯一的工具. 别的你可以看看的工具有：

• pngrewrite
• OptiPNG
• PNGOut

现在我们有很好的PNG 解决方案了， 我们来看看我们是不是能对别的图片类型做一样的事情。

第二步： 移除JPG 元数据

JPEG 文件保护的元数据有：

• 评论
• 程序（比如photoshop）的元数据
• EXIF信息比如相机信息， 照像时间， 甚至真实图片的缩略图或者音频

这些元数据都不是显示图片必须的， 是可以安全的删除而不损失图片质量。 在前面的讨论中说道， JPEG 是有损格式， 这就意味着你的每次保存都会有质量丢失。 但是幸运的是一些操作不是有损的， 操作比如删除图片的一部分， 旋转， 和拷贝个人爱好元数据。一个允许你做这些的工具叫做 jpegtran.

这个命令是拷贝一个原图片， 优化并不把任何元数据拷贝到新的图片备份：

> jpegtran -copy none -optimize src.jpg dest.jpg

注意这依赖于你用的版本， 可能你需要用到这样结尾的语法：
src.jpg> dest.jpg

这个 -optimize 选项让jpegtran 优化哈夫曼树并改进压缩。

在Alexa 前10 的站点跑这个命令平均节省11.85%.

使用jpegtran的 -progressive 选项， 你可以进一步优化你的图片大小。它让jpeg 图片在浏览器中渐进式的加载。从第低质量版本的图片逐步改进到所有信息都到达。

元信息剔除的重要提示： 只是对你自己的图片做。 因为当jpegtran 删除所有元信息的时候， 它也会把图片中的版权信息删除。

第三步： GIF 转为 PNG

最好的优化GIF图片的方法是什么？ 把它转换成PNG . 挺起来很搞笑， 不过这是真的。 大部分时间你会从PNG得到比较小的文件大小和相同质量并且浏览器支持， 跟之前的文章里我们讨论的一样。注意到PNG 并不总是比较小的， 但是大部分时间是的， 所以还是值得检查转换的， 在两个文件中挑一个比较小的。

为了可以自动化转换你的图片， 你可以使用 ImageMagick的转换：

> convert image.gif image.png

假如你想强制使用PNG8 的话可以用：
> convert image.gif PNG8:image.png

这个可能不是必须的， 因为GIF 很有可能被转换成PNG8 ， ImageMagick 会根据颜色数来挑选合适的文件格式。

当你把图片从GIF 转换为PNG ， 别忘记用第一步的工具缩小一下PNG 结果。

假如前10 的网站把所有他们的GIF 转为PNG （排查那些不产生更小的文件大小的）， 平均可以有20.4% 的文件大小缩减。 唯一的不方便就是要你写一个查找替换脚本，把所有的GIF 引用替换成新的PNG 版本。

优化GIF 动画
现在所有的GIF, PNG 图片都压缩了， JPEG也是， 还剩下什么呢？GIF动画。 你可以用的一个工具是GIFsicle . 因为动画是由帧组成的， 并且图片的一些部分在帧改变的时候不会变化， GIFsicle 不会携带重复的像素信息。 这样用：
> gifsicle -O2 src.gif > dest.gif

压缩它
就跟我们在开始说的一样， 这四步最赞的地方是他们不会导致图片质量损失， 所以你不用工具比较优化前后。 它们都是命令行的工具， 所以它们很容易自动化。 所以在用ftp 上传文件到服务器之前， 你不会丢失任何信息， 你只是赢了。

你可以尝试 smush.it工具，看一下你可能节省多少。

注： 原文地址http://yuiblog.com/blog/2008/12/05/imageopt-4/

在前面的文章中， 渐进式的JPEG 只是简单的提到作为图片优化的一个可用选项。这篇文章从10,000 张图片的的优化实验来深挖这个选项。

基线JPEG  vs 渐进式JPEGS

基线是指”普通的”JPEG, 所有的图片程序都是 默认用这个类型的JPEG 保存的。浏览从顶到底的方式加载图片信息。

加载一个基线JPEG， 点击放大

逐渐加载的JPEG 是另外的一种JPEG， 就跟名字说的一样， 他们是被逐渐展现的。首先你看到这个图片的低分辨率的版本。然后更多图片的信息从网络上过来了， 图片的质量逐步的改善。

加载一个渐进JPEG ， 点击放大

从可用性的角度来看， 渐进通常是好的， 因为事情正常进展中用户得到了反馈. 假如你的网络连接很慢， 逐步加载你的优先选择， 因为你不用等到整个图片都回来的时候你就知道这个东西是不是你想要的了。 如果不是， 你就可以离开这个网页或者点击回退按钮， 而不用等待高清的图片。

我听到的一个反对坚强渐进式JPEG的理由是它太学院派了，它的使用导致的渐进式渲染会使人很郁闷，不是愤怒的话。我没有这方面的用户研究， 如果你听到过有这方面的实验 请评论一下。

从日志和书上看到关于渐进式JPEG和基线JPEG 的文件大小的讨论都是互相矛盾的。 在这个无休止的更小文件和无损的优化下， 这是一个试图回答这个问题的实验。

实验

Yahoo提供的很多免费API中有一个图片搜索的API。我用它来搜索匹配很多的查询， 比如“厨房”, “小狗”, “猴子”,”婴儿”,”鲜花”,”落日”……总共12个。我下载了所有的图片， 刨去4xx, 5xx的错误的和不是JPEG的（有一些站点会把PNG甚至BMP的图片重命名为.jpg）。清理完后剩下10360张图片， 有各种尺寸和质量的， 最好的是， 都是从现在网络弄到的只是图片。

有了源文件， 我用下面的命令跑了两次jpegtran，

> jpegtran -copy none -optimize source.jpg result.jpg

和

> jpegtran -copy none -progressive source.jpg result.jpg

第一个方法会优化基线JPEG 图片的哈弗曼表（前面文章讨论的）。后面一个命令会把源文件变成渐进式的。

我们来看看结果文件的大小事怎么样的。

结果

在这个实验中中等大小的JPEG 是52.07kb ， 可能不是最有用的统计。 重要的是用jpegtran无损的优化图片，对于基线JPEG 平均节省 9.04%(中等大小变为47.36kb), 对于渐进式jpeg 节省11.45%(中等大小变成46.45%)。

看起来渐进式JPEG平均比较小。不过这只是平均， 不是绝对的。 事实上多于15%（10360 张图片中的1611张）渐进式图片比较大。 想要预测一个图片什么时候压缩成渐进式的比较小（或者自动完成），从图片尺寸和文件大小上看图片的表现的想法可能会很有帮助。

看这个关系， 我把所有的结果都打点在了一个图表上了：

Y轴是 “渐进式- 基线”的大小， 所以负数是基线比较小

X 轴是图片的原始大小

这个图表看到结果在什么地方都有， 但是看起来有个趋势- 图片越大， 渐进式JPEG 节省的就越多。

放大到比较小的图片的区域渐进式图片就没有那么有效了， 让我们只考虑图片大小在30 K以下的吧。 然后用Excel 的趋势线的功能， 我们画出了一条线

总结

上面的图表能带回家的信心是：

当你的JPEG图片小于10k的时候， 保存为基线图片比较合适（预计75 % 的几率会比较小）

大于10K的图片用渐进式图片会有比较大的压缩（94%的机会）

如果你的目标是挤掉每一个字节， 最好的是基线和渐进式都试一下， 选比较小的。

别的选择是所有小于10k 的图片用基线， 比的图片用渐进式的。或者只是用基线作为缩略图， 渐进式做为所有别的。

ie 和渐进式图片

“哦， 不是又是IE吧“， 可能是你正在想的， 不过事实上没有那么坏。 只是IE 不会渐进式的渲染JPEG。 只是在整个图片都加载完的时候才显示图片。 所以基线JPEG（从上到下的过程） 比渐进式JPEG 更加 渐进式。

关于ImageMagick

ImageMagick 是一个命令行的图片工具， 你也可以用来优化文件。 不像大部分的图片软件， ImageMagick 是用 优化的基线JPEG 保存图片的（跟在jpegtran 中用了 -optimize 一样）。

ImageMagick 也可以去除元数据和写渐进式JPEG，因此我重复的用ImageMagick 替换 jpegtran 做上面的实验。命令是这样的：

>convert -strip source.jpg result.jpg // baseline JPG
>convert -strip -interlace Plane source.jpg result.jpg // progressive JPEG

从ImageMagick 实验得到的结果：

基线对比渐进式的趋势曲线是一样的： 大于10k的图片用渐进的编码方式有更好的优化。

整体压缩比较好： 基线的平均优化比试10.85%(jpegtran 节省9.04%), 渐进式节省 13.25%(jpegtran 是11.45%).

图片质量有损。 ImageMagick 用的不是完全无损的操作。 随便一个图片用肉眼看不出任何的区别， 但是用图片比较工具能看出一些像素的信息被修改了。

这个实验最后一组统计要看的是写JPEG 的图片。这是jpegtran 和 ImageMagick 优化大于10K 以上的图片在我的电脑上的表现(Windows XP, 2GHz dual CPU, 500Mb RAM).从最快到最慢

1. jpegtran baseline (11  张图片每秒),
2. jpegtran progressive (9 张图片每秒),
3. ImageMagick baseline (7 张图片每秒),
4. ImageMagick progressive (5.5 张图片每秒)

译注： 感谢米随随 翻译的这个系列的文章和提供的链接， 我就顺便把前面的这几篇文章翻译一下， 也练练手。
这篇文章的原文地址是：
http://yuiblog.com/blog/2008/11/04/imageopt-2/

下面是译文：

这是系列文章的第二部分，你可以看别的部分：
图片优化第一部分： 图片的重要性
图片优化第三部分： 减小文件大小四部曲
图片优化第四部分： 渐进式JPEG， 性感么？

这个图片优化的第二部分讲的是文件格式以及如何选择正确的。 我们会简单的讨论一下流行的GIF 和 JPEG格式，然后转向备受关注的巨星 ，PNG， 希望可以纠正对它的一些误解。

GIF
GIF 是调色板(也叫做索引)类型的图片。它有一个256 索引色的调色板， 图片的每一个像素对应一个颜色索引。这个格式已经不是专利了， 你可以不用因为创建GIF图片 冒着要去监狱的危险了。（更多GIF格式的历史点这里）

GIF 不是一个有损的格式， 这就以为着当你修改图片，保存的时候你不会丢失质量。

GIF也支持动画的，导致在黑暗的web 1.0 时代，出现大量的闪烁的”新”图片，旋转的 @ 符号， 小鸟下降（注：原文是birds droping）……和别的烦人的东西。 在文明很多的web2.0 时代， 在等待ajax结果返回来更新也慢的时候， 我们还是有很多的“loading……”, 不过也有很多好的东西人们喜欢放到社交网络的资料里去的， 不管怎么样， 你需要的话， 动画是支持的。

GIF 也支持布尔类型的透明。一个像素要么是全透明，要么是完全不透明。

JPEG

JPEG 没有跟GIF 一样的256 色的限制， 它可以保护上百万的颜色，也有很好的压缩。 这让它很适合图片， 事实上， 大部分的照相机都是用JPEG 格式存储照片的。 它是有损的格式， 这就意味着你的每次编辑都会丢失图片质量， 所以你最好用别的格式存储当你准备做多次的编辑的时候。 然而， 一些操作是无损的， 比如切掉图片的一部分， 旋转图片或者修改元信息， 比如图片中的评论信息。

JPEG 不支持透明。

PNG

PNG 不是有损的， 它有几种类型， 为实用的目的， 我们可以认为PNG 有以下两种类型:
1. PNG8 和
2. 真色彩的PNG

跟GIF一样， PNG8 是调色板的图片格式， 8 的意思是8 比特 或者 28, or 256 个颜色实体。 名词 “PN8″, “调色板PNG” 和”索引PGN” 表示相同的意思。

跟GIF 比， PNG8 怎么样呢？

优点：
通常生成的文件比较小一点
支持alpha(多样的)透明

缺点：
不支持动画

第二种类型的PNG 是真彩色的PNG, 跟JPEG 一样， 拥有百万的颜色。你也可以说是PNG24 或者PNG32。

那真彩色的PNG跟JPEG 比怎么样呢？ 优点是它不是有损的，支持alpha 透明， 但是缺点是文件更大。 这个让真彩色的PNG 做为有多次编辑的JPEG 的理想媒介， 很很适用很在意每个像素而不在意文件大小的情况， 比如帮助文档的快照或者打印资料。

ie 和PNG 透明

我们说两个类型的PNG 都支持alpha 透明，但是你应该注意的有一些浏览器的古怪行为影响着这两个类型。

在ie(6或者以下)，PNG8 的图片半透明的像素都显示为完全透明的。这个不是很理想， 但还是很有用的， 并且GIF你也会得到相同的行为。因此用PNG8，在最坏的情形（ie7以下）下，你也是得到和gif 一样的体验， 但是在别的浏览器（Firefox, Safari, Opera） 下你能得到更好的体验。 下面是一个展示这个的例子， 注意ie6 下灯周围的半透明是怎么消失的：

对于真彩色的PNG，形式就没有那么好了。 所有的半透明像素在ie7一下都变成了灰色：

ie7 引进了对PNG8 和真彩色的PNG的alpha 透明的默认支持。对于早期的ie版本， 你需要使用CSS 和 AlphaImageLoader 滤镜来修正真彩色PNG 的透明问题， 在接下来的文章中我们会做更细节的讨论。

“我们说的是： 给PNG 一个机会”

因为它比较小的文件大小，对早期ie不用特殊的css滤镜就可以良好的降级， PNG8是比较推崇的PNG 类型，， 但是有一些场合适合真彩色的PNG:

当PNG8的256色不够用的时候， 你可能需要真彩色的PNG
这是你应该避免的情况。 假如你有成千上万的颜色， 那你就可以考虑有更好的压缩的JPEG了。 另外， 假如颜色就在1000 左右， 你就可以试图把图片转为PNG8 ，看是否可以接受。 经常的， 人类的眼睛不够敏感的去区分200 和 1000色。 当然的， 这要看图片了，经常你可以安全的移除1000颜色， 但经常的移除了2个颜色也会不可接受。 有上面的情况， 你就可以试一下真彩色PNG和JPEG， 看质量和文件大小哪个更合适。
当图片大部分都是半透明的时候 假如只有图片的一小部分是半透明的， 比如圆角， 降级到类似GIF的PNG8 经常是可以的。 但是假如图片大部分是透明的， （比如视频缩略图的PLAY 按钮）， 你可能别无选择的使用AlphaImageLoader 。

最后， 我们来总结一下这个章节讨论的亮点：
JPEG 是照片的格式.
GIF 是动画的格式.
PNG8 是所有别的东西的格式- 图标， 按钮， 背景， 图标……你能想到的。