正在加载......
类别:扩展学习  时间: 2008-01-04 11:56:01; 浏览: 21621; 评论: 1  
Tags : GIF JPEG PNG

哪种图像格式最好?
作者:Jonathan Snook 译:htmlor

在网站开发过程中,用什么图像格式你可能不会考虑太多。不过,明智的选择会为你自己(或公司)节省一大笔带宽开支。当今主流的web图像压缩格式有3种:GIF、JPEG和PNG。它们采用不同的图像信息压缩技术,各有利弊。

GIF
注:Graphics Interchange Format,图形交换格式。
GIF是无损压缩,即在压缩过程中图像没有质量损失。未压缩的图像信息以线性方式存储。(下载时)每行象素从左到右依次读取。交错式GIF图像(htmlor注:fireworks导出GIF时有交错式图像可选)用不同的顺序存储图像行。(下载时)先读取第4、8、12、16、20行,然后是第2、6、10、14、18行,…… 以此类推,直到读取完整个图像。以这种方式下载时,网速较慢的用户能把过程看得清清楚楚。(htmlor注:查看这个页面可以看到上述下载效果。)

GIF的压缩方式是把文件中重复的色块消除,然后把(这些色块的)位置信息存在一个表里(也叫hash表)。(因此)图像中相同色块越多,压缩率就越高。如背景图、包含文字的图像和被图样填充的图像等。

GIF的一大显著优势就是能制作动画图像。你肯定在网上见过铺天盖地的GIF动画(尤其是90年代的全盛时期)。根本上讲,一个GIF动画就是一串含有时间信息的GIF静态图像。不过GIF动画有个问题:即便帧数不多,字节数也会变得很大。(举例来说)如果1帧GIF有15kb,那么20帧将超过100kb(对于web图像显然是太大了)。在这个GIF大行其道的时代,如果要做动画,还是用flash好些。

GIF的另一优势是透明度。你可以选择颜色表里的某一种颜色作为透明色。这样的话,原本这种颜色出现的地方(会变得透明)可以看到下层的HTML背景。

(有利自然有弊)GIF格式的最大不足,就是它对256色之外的颜色无能为力。如果一幅含有成千上万种色彩的照片用GIF格式压缩,将会变得惨不忍睹。

JPEG
注:Joint Photographic Experts Group,联合图像专家小组。文件扩展名通常简化为JPG。

JPEG是有损压缩,即在压缩过程中图像质量会有损失。其压缩过程首先把图像从RGB转换为YUV,用亮度、色调和饱和度储存每个象素的信息。然后减少色调和饱和度的信息数量,这种差别不容易被肉眼察觉到。在图像字节数递减时(比如在photoshop里移动质量控制滑块),你会看到在色块上产生模糊的斑点,尤其是边缘附近。总的来说,JPEG格式最适用于色彩丰富的图像。(因为)把含有渐变色彩的图像或者照片压缩成低质量,损失并不显眼(却能大幅减少字节数)。而包含文字或者有大块实心背景色的图像的压缩,更适合交给GIF和PNG格式去做。

PNG
注:Portable Network Graphics,便携式网络图形。

PNG在现有的多种图像格式中算是晚辈,却来势汹汹,大有后来居上之势。它在某些方面与GIF类似,却在其他方面更胜一筹。与GIF同为无损压缩,PNG还支持24位色(GIF只支持8位色),同时支持alpha透明(GIF只支持单色透明)。PNG使用多种压缩过滤器减小图像字节数,它能针对每行使用不同的过滤器从而实现高压缩率。alpha透明是PNG最令人心动的一大特点。不过可惜,ie现在还不能完全支持(尽管通过一些小手段可以实现)。

如果你不需要alpha透明或者256色已经够用,可以使用8位色PNG。平均来说,在同等图像质量的条件下,8位色PNG的字节数要比GIF小。在处理相同色块很多的图像时,PNG和GIF非常相似,都能出色的完成任务。如果你还想储存比256色更丰富的色彩,就用24位色PNG吧。只是别忘了测试一下24位色PNG和JPEG哪个实际效果更好。

(人家的优点它都有,缺点自然也少不了)PNG的缺点跟GIF相同:对于照片的优化,不如JPEG好。

谁是老大?
没有哪种图像格式独领风骚、老少咸宜。所以,该用哪个用哪个、该怎么压缩怎么压缩,不拘泥于一种格式,就是最好的方案。

也许您对下面的文章感兴趣:
  1. [2015-01-18 23:58:49] Mac查看gif文件
类别:随便说说  时间: 2007-12-29 19:11:14; 浏览: 50866; 评论: 0  
Tags : 生命 珍惜

    2007年12月23日,公司一位女同事因患胃癌医治无效而与世长辞,英年30岁。公司由CEO和副总裁带头捐款以慰问家属。

    2007年12月29日,在喜悦村看见奶瓶发帖,为其同学而默哀。

    IT行业很累的,尤其互联网方向的。而且对这种事亡羊补牢的事也不到位。比如事后捐款,那事前去哪了?小恩小惠并不能左右人心,跟何况很多地方还没有小恩小惠。

    现实是如此的残酷,我们更多的是以自我安慰的激昂心态努力做好现在的事情,为了明天而奋斗!

    新年来了,祝大家新年快乐!身体健康!

    另:刚得到消息baidu CFO 王湛生在休假时因意外去世,默哀!尽管不是我很担心的健康问题。

也许您对下面的文章感兴趣:
类别:MySQL学习  时间: 2007-12-26 19:28:40; 浏览: 53393; 评论: 1  
Tags : mysql

    昨天在处理mysql数据的时候提示:Got error 127 from table handler。症状为:取出前面的数据没问题,但是在遇到一条游问题的数据时显示“Got error 127 from table handler”。

   上网查询资料如下:

以下是引用片段:
1:Got error 127 from table handler
2:MySQL : GOT error 127 from table handler
3:表被破坏
4:手册对repair table的说明
5:手册对check table的说明

    比较有参考价值的回复如下:

以下是引用片段:
1 E_ERROR fatal run-time errors  
2 E_WARNING run-time warnings (non fatal errors)  
4 E_PARSE compile-time parse errors  
8 E_NOTICE  run-time notices (less serious than warnings)   
16 E_CORE_ERROR fatal errors that occur during PHP's initial startup PHP 4 only
32 E_CORE_WARNING warnings (non fatal errors) that occur during PHP's initial startup  PHP 4 only
64 E_COMPILE_ERROR fatal compile-time errors PHP 4 only

error 127就是同时存在2,4,8,16,32,64的错误
主要的是16和64,原因分析:可能是你装php的时候有问题,建议重装

    看得资料一般是说使用“REPAIR TABLE `tablename`”去修复表,看了手册的说明后操作如下:

以下是代码片段:
mysql> check table mytable;
+-------------------+-------+----------+----------------------------------------------------+
| Table             | Op    | Msg_type | Msg_text                                           |
+-------------------+-------+----------+----------------------------------------------------+
| mydb.mytable | check | error    | got error: 5 when reading datafile at record: 1291 |
| mydb.mytable | check | error    | Corrupt                                            |
+-------------------+-------+----------+----------------------------------------------------+
2 rows in set (3.09 sec)

    check的结果与测试得到的差错点一致,为第1291条数据开始便有问题了!然而在这个时候尝试取出数据时失败了:

以下是代码片段:
mysql> select * from `mytable` limit 1291, 1;
ERROR 1016: Can't open file: 'mytable.MYD'. (errno: 145)

    真是无语啊........骑虎难下,继续操作,希望还有救:

以下是代码片段:
mysql> repair table mytable;
+-------------------+--------+----------+----------------------------------------+
| Table             | Op     | Msg_type | Msg_text                               |
+-------------------+--------+----------+----------------------------------------+
| mydb.mytable | repair | warning  | Number of rows changed from 30030 to 0 |
| mydb.mytable | repair | status   | OK                                     |
+-------------------+--------+----------+----------------------------------------+
2 rows in set (3.10 sec)

    疯了!30030条数据全没了!幸好还有备用的数据库,把数据文件和索引文件直接copy了过来,修改文件的权限后,数据能正常取出了。

    为什么会这样呢?原因不详,只能吸取教训:
    1:修复表时最好先锁定表。
    2:最好是在把mysql shut down后再修复表。

    谁能告诉我这是怎么回事?非常感谢!

也许您对下面的文章感兴趣:
类别:Linux/Unix  时间: 2007-12-21 19:31:50; 浏览: 95092; 评论: 1  
类别:随便说说  时间: 2007-12-20 12:22:58; 浏览: 32744; 评论: 0  
类别:随便说说  时间: 2007-12-19 19:30:51; 浏览: 22755; 评论: 0  
类别:C/C++学习  时间: 2007-12-05 19:57:35; 浏览: 59603; 评论: 2  
Tags : C C++ Linux
类别:C/C++学习  时间: 2007-12-04 17:58:27; 浏览: 65133; 评论: 1  
类别:PHP心得  时间: 2007-11-06 11:02:43; 浏览: 59776; 评论: 1  
类别:C/C++学习  时间: 2007-10-31 19:18:56; 浏览: 36870; 评论: 0  
[198][10/20][|<][6][7][8][9][10][11][12][13][14][15][>|] | 回页首
© 2004 - 2019 芽雨快跑 - 本页面所有内容,未经芽雨许可,欢迎转载,请注明出处

京ICP备09017802号