为什么微信android图片质量会比iphone的差?
2015-06-09 11:22
567 查看
摘自网络,出处未知。
为什么微信android图片质量会比iphone的差?
我们团队最初也纠结过这个问题,费了半天劲、绕了好大圈,直到最后才发现,原来这是谷歌犯得一个“小”错误,而且一直错到了今天。
谷歌的错就在于:libjpeg。
libjpeg是广泛使用的开源JPEG图像库(参考 libjpeg ),安卓也依赖libjpeg来压缩图片。通过查看源码,我们会发现安卓并不是直接封装的libjpeg,而是基于了另一个叫Skia的开源项目(Skia
Graphics Engine)来作为的图像处理引擎。Skia是谷歌自己维护着的一个大而全的引擎,各种图像处理功能均在其中予以实现,并且广泛的应用于谷歌自己和其它公司的产品中(如:Chrome、Firefox、Android等)。Skia对libjpeg进行了良好的封装,基于这个引擎可以很方便为操作系统、浏览器等开发图像处理功能。
libjpeg在压缩图像时,有一个参数叫optimize_coding,关于这个参数,libjpeg.doc有如下解释:
这段话大概的意思就是如果设置optimize_coding为TRUE,将会使得压缩图像过程中基于图像数据计算哈弗曼表(关于图片压缩中的哈弗曼表,请自行查阅相关资料),由于这个计算会显著消耗空间和时间,默认值被设置为FALSE。
这段解释乍看起来没有任何问题,libjpeg的代码也经受了十多年的考验,健壮而高效。但很多人忽略了这一点,那就是,这段解释是十多年前写的,对于当时的计算设备来说,空间和时间的消耗可能是显著的,但到今天,这似乎不应再是问题,相反,我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。
谷歌的Skia项目工程师们最终没有设置这个参数,optimize_coding在Skia中默认的等于了FALSE,这就意味着更差的图片质量和更大的图片文件,而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么,这个参数的影响究竟会有多大呢?
经我们实测,使用相同的原始图片,分别设置optimize_coding=TRUE和FALSE进行压缩,想达到接近的图片质量(用Photoshop放大到像素级逐块对比),FALSE时的图片大小大约是TRUE时的5-10倍。换句话说,如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片,FALSE的品质将大大逊色于TRUE的(虽然品质很难量化,但我们不妨说成是差5-10倍)。
我们又对Android和iOS进行了对比(均使用标准的JPEG压缩方法),两个系统都没有提供设置optimize_coding的接口(通过阅读源码,我们已经知道Android是FALSE,iOS不详),当压缩相同的原始图片时,结果也是一样,iOS完胜。想要品质接近,文件大小就会差出5-10倍,而如果要压缩出相同大小的文件,Android的压缩品质简直就是惨不忍睹。
结果说明,苹果很清楚optimize_coding参数和哈弗曼表的意义,这里需要特别指出,苹果使用的哈弗曼表算法与libjpeg(及我们后来自行采用的libjpeg-turbo)不同,像素级可以看出区别,苹果似乎基于libjpeg又进行了进一步的优化,压缩出来的图片细节上更柔和、更平滑。
以上试验,我们尝试过多个原图、多种压缩比例,试验结果均类似,如有兴趣,您不妨也自行进行尝试。
最终我们决定,不再使用安卓系统原生的JPEG压缩方法,而是基于libjpeg-turbo自行编译了一版native的安卓库,专门用来压缩图片,这样在我们的产品中,就做到了仅仅用1/5的图片大小,就能让用户得到不逊色甚至更优的图片品质,对于我们团队来说,费了半天劲、绕了好大圈是非常值得的。(使用libjpeg-turbo还有性能上的好处,这里就不再赘述了)
为什么微信android图片质量会比iphone的差?
我们团队最初也纠结过这个问题,费了半天劲、绕了好大圈,直到最后才发现,原来这是谷歌犯得一个“小”错误,而且一直错到了今天。
谷歌的错就在于:libjpeg。
libjpeg是广泛使用的开源JPEG图像库(参考 libjpeg ),安卓也依赖libjpeg来压缩图片。通过查看源码,我们会发现安卓并不是直接封装的libjpeg,而是基于了另一个叫Skia的开源项目(Skia
Graphics Engine)来作为的图像处理引擎。Skia是谷歌自己维护着的一个大而全的引擎,各种图像处理功能均在其中予以实现,并且广泛的应用于谷歌自己和其它公司的产品中(如:Chrome、Firefox、Android等)。Skia对libjpeg进行了良好的封装,基于这个引擎可以很方便为操作系统、浏览器等开发图像处理功能。
libjpeg在压缩图像时,有一个参数叫optimize_coding,关于这个参数,libjpeg.doc有如下解释:
这段话大概的意思就是如果设置optimize_coding为TRUE,将会使得压缩图像过程中基于图像数据计算哈弗曼表(关于图片压缩中的哈弗曼表,请自行查阅相关资料),由于这个计算会显著消耗空间和时间,默认值被设置为FALSE。
这段解释乍看起来没有任何问题,libjpeg的代码也经受了十多年的考验,健壮而高效。但很多人忽略了这一点,那就是,这段解释是十多年前写的,对于当时的计算设备来说,空间和时间的消耗可能是显著的,但到今天,这似乎不应再是问题,相反,我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。
谷歌的Skia项目工程师们最终没有设置这个参数,optimize_coding在Skia中默认的等于了FALSE,这就意味着更差的图片质量和更大的图片文件,而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么,这个参数的影响究竟会有多大呢?
经我们实测,使用相同的原始图片,分别设置optimize_coding=TRUE和FALSE进行压缩,想达到接近的图片质量(用Photoshop放大到像素级逐块对比),FALSE时的图片大小大约是TRUE时的5-10倍。换句话说,如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片,FALSE的品质将大大逊色于TRUE的(虽然品质很难量化,但我们不妨说成是差5-10倍)。
我们又对Android和iOS进行了对比(均使用标准的JPEG压缩方法),两个系统都没有提供设置optimize_coding的接口(通过阅读源码,我们已经知道Android是FALSE,iOS不详),当压缩相同的原始图片时,结果也是一样,iOS完胜。想要品质接近,文件大小就会差出5-10倍,而如果要压缩出相同大小的文件,Android的压缩品质简直就是惨不忍睹。
结果说明,苹果很清楚optimize_coding参数和哈弗曼表的意义,这里需要特别指出,苹果使用的哈弗曼表算法与libjpeg(及我们后来自行采用的libjpeg-turbo)不同,像素级可以看出区别,苹果似乎基于libjpeg又进行了进一步的优化,压缩出来的图片细节上更柔和、更平滑。
以上试验,我们尝试过多个原图、多种压缩比例,试验结果均类似,如有兴趣,您不妨也自行进行尝试。
最终我们决定,不再使用安卓系统原生的JPEG压缩方法,而是基于libjpeg-turbo自行编译了一版native的安卓库,专门用来压缩图片,这样在我们的产品中,就做到了仅仅用1/5的图片大小,就能让用户得到不逊色甚至更优的图片品质,对于我们团队来说,费了半天劲、绕了好大圈是非常值得的。(使用libjpeg-turbo还有性能上的好处,这里就不再赘述了)
相关文章推荐
- 源码阅读 5 微信6.0底部效果
- js对微信的相关操作
- 微信JS接口汇总及使用详解(转)
- 微信支付样例
- chorme模拟微信浏览器
- Flask+SAE快速打造微信公众帐号
- C#微信开发小白成长教程二(新手接入指南,附视频)
- 如何设置微信订阅号的微信号以及申请微信认证
- 6.9学习内容 设置相机参数,android古怪的bug,仿微信可点击的点赞文字
- 安卓版微信自带浏览器和IE6浏览器ajax请求abort错误处理
- 微信支付后台需要做的事情 ,以及遇到的一些问题
- [031] 微信公众帐号开发教程第7篇-文本消息中换行符的使用
- [030] 微信公众帐号开发教程第6篇-文本消息的内容长度限制揭秘
- [029] 微信公众帐号开发教程第5篇-各种消息的接收与响应
- [028] 微信公众帐号开发教程第4篇-消息及消息处理工具的封装
- [027] 微信公众帐号开发教程第3篇-开发模式启用及接口配置
- [026] 微信公众帐号开发教程第2篇-微信公众帐号的类型(普通和会议)
- [025] 微信公众帐号开发教程第1篇-引言
- [024] 欢迎大家关注我的微信公众帐号小q机器人(xiaoqrobot)
- 微信公众平台