JPEG 2000， 正式名称为 "ISO 15444" ，同样是由JPEG 组织负责制定。自1997年三月开始筹划，但这几年间，在算法选取问题上耽误了不少时间，人们普遍预计要到2000年十二月 JPEG2000才能制定完成!，但在今年 3 月的东京的一个会议上，可能是由于数字照相机厂商们施加压力，规定基本编码系统的最终协议草案提前出台，终于不用改名为 JPEG2001 了。标准既然已经定了，那么相对的应用软件就很快就出来了。现在是 8 月，我已经找到几套这样的软件了，在介绍它们之前，我们先看看 JPEG2000 的原理、优点、应用。
JPEG2000的原理：
JPEG 2000 与传统 JPEG 最大的不同，在于它放弃了 JPEG 所采用的以离散馀弦转换(Discrete Cosine Transform) 为主的区块编码方式，而改采以小波转换(Wavelet transform) 为主的多解析编码方式。小波转换的主要目的是要将影像的频率成分抽取出来。
JPEG2000的优点：
1、JPEG2000 作为JPEG升级版，高压缩（低比特速率）是其目标，其压缩率比 JPEG 高约 30% 左右。
2、JPEG2000 同时支持有损和无损压缩，而 JPEG 只能支持有损压缩。无损压缩对保存一些重要十分有用。
3、JPEG2000 能实现渐进传输，这是JPEG2000的一个极其重要的特征。也就是我们对 GIF 格式影像常说的“渐现”特性。它先传输图像的轮廓，然后逐步传输数据，不断提高图像质量，让图象由朦胧到清晰显示，而不必是像现在的 JPEG 一样，由上到下慢慢显示。
4、JPEG2000 支持所谓的“感兴趣区域”特性，你可以任意指定影像上你感兴趣区域的压缩质量，还可以选择指定的部份先解压缩。这样我们就可以很方便的突出重点了。
JPEG2000的应用：
JPEG 2000的应用领域可概略分成两部分，一为传统JPEG的市场，像印表机，扫描器，数位相机等，一为新兴应用领域，像网路传 无线通讯，医疗影像等。目前对 JPEG 2000 热情最大的当然就是那些数字照相机厂商。JPEG 2000 和 JPEG 相比优势明显，且向下兼容，因此取代传统的JPEG格式指日可待。
理论说完，下面我们再来联系实际，看看 JPEG 2000 到底有没有上面说的那么好。下面我首先说说我们这次所使用的软件：
1、Image Power JPEG 2000 Codec BETA Preview v 0008
由于 JPEG 2000 标准刚制定不久，所以这个是我找到的第一个 JPEG2000 编码、解码软件。它在 DOS 下运行，生成的文件扩展名是 JP2 ，感觉上比较“正统”。它只支持 BMP 文件转换成 JP2 文件，解压缩的时候，也只能把文件还原成 BMP 文件才可以用其它看图软件观看，相当麻烦。
2、LuraWave SmartCompress Freeware for Windows
JPEG2000 确定了全新的编码演算法后，LuraTech 是起跑最快的技术应用厂商之一，他们所主导的 LuraWave (LWF) 及 LuraDocument (LDF) 格式，已经迈入了成熟的应用阶段。而且 LuraTech 已经和开发 ACDSee 的 ACD Systems 公司签订协定，在使用率最高的图形管理软体 ACDSee 30 上，提供 JPEG2000 LWF 格式的外挂插件，这样只要我们安置了这个插件就可以观看和制作 LWF 格式的文件了（如下图）。这个是目前比较完整的一个 JPEG 2000 软件，无论是在查看还是压缩制作方面它都提供了相应的处理软件，不仅如此，LuraTech 还推出了一系列让 PHOTO SHOP 、IE 等常用影像、网络软件支持 LWF 格式的插件。另外使用 LuraWave SmartCompress 还可以为影像加上密码，不知道密码打开的影像非常朦胧，是一个非常实用的功能（如下图）。有如此完整的一系列应用软件打天下，相信 LWF 会成功的。
3、Elecard Wavelet Image Compressor
和前面的 LuraTech 比，它的速度是算比较慢的了，其推出的软件不功能不强，而且只有一个 IE 下的用 JAVA 来显示图象的插件，这个软件生成的文件其扩展名是 WLT，其图象质量比 LuraWave SmartCompress 要差一些，所以这次我没把拿来测试。
4、DjVu
它和 LuraTech 相比，插件也比较齐全，但无奈提供的软件体积都比较大，而且在易用性方面也有所不及，所以我也没把拿来测试。
在大家开始比较之前我想先说说一些注意的地方，由于大家的浏览器在没补丁的情况下是不能显示 JPEG 2000 格式影像文件的，所以，我只好把它们保存成压缩质量是 90 的普通 JPEG 格式，虽然这样对 JPEG2000 有点不公平，但也只能好这样了。首先要测试的是在高压缩率（低比特速率）下的的影像质量。下面这幅个人物图 （宽：270 高：329）用 JPEG 最好质量（100） 压缩后文件大小 81215kb ，保存成 WINDOWS BMP 真彩16位格式的话，文件大小是 267202kb。
标准 JPEG 压缩 JPEG 2000 压缩 LuraWave 压缩
3352kb 压缩质量 6%
3408kb 压缩率 80
3328KB 压缩率 80
从上图大家不难看出在压缩率相等的情况下， JPEG 2000 的影像质量明显优于 JPEG 。用 JPEG 处理的那幅图里面的人物基本可以说是被方格“毁容”了，这也是 JPEG 最大的缺点，也就是我们说的马赛克现象非常严重。而用 JPEG 2000 处理的那幅图就基本看不到有马赛克，而且人物的脸部轮廓也比较清晰的表现了出来。LWF 压缩在脸部清晰度方面我认为又比 JPEG2000 好一点。我们再来看看 JPEG 图上面的那几个字母 >最近给服务器搞的头疼，一遇到问题就要很长时间才能解决，尤其是编码问题，转移服务器最怕的就是这个问题了，而且由于我们是每一届都是不同的人管理服务器，工作交接不可能那么的到位，所以很多时候还是要靠自己。前面一直也没有很好的办法解决。今天又遇到一个问题，一个网站显示不正常，看了下他给我的代码，107M，我的妈呀，这个不是要了哥我的命嘛！细细看了下，这个写网站的人还比较厚道，有一个commonphp，修改了下，不行，崩溃了。初步怀疑是代码写的时候是utf-8的，只是改下meta好像不行（我也不确定，因为以前也遇到过类似的情况），无奈了，只有到网上去搜一搜，发现原来是可以的。而且很简单的修改。
打开apache配置文件，找到AddDefaultCharset GB2312这一行（也可能是AddDefaultCharset utf-8）给注释掉，然后加上一句AddDefaultCharset off，其实就是关掉默认使用的字符集，这样apache就可以根据网页中的meta信息来选择使用字符集。很好用的方法，修改完后service >
>
正向代理要求客户端自己设置代理服务器的地址。客户的每次请求都将直接发送到该代理服务器，并由代理服务器来请求目标资源。比如处于防火墙内的局域网机器要访问Internet，或者要访问一些被屏蔽掉的国外网站，就需要使用正向代理服务器。
反向代理则被设置在服务器端，因而客户端无需进行任何设置。反向代理是指用代理服务器来接收Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从内部服务器上得到的结果返回给客户端。这种情况下，代理服务器对外就表现为一个真实的服务器。各大网站通常分区域设置了多个代理服务器，所以在不同的地方同一个域名可能得到不同的IP地址，因为这些IP地址实际上是代理服务器的IP地址。
>
如图所示，正向代理服务器和客户端主机处于同一个逻辑网络中。该逻辑网络可以是一个本地LAN，也可以是一个更大的网络。反向代理服务器和真正的Web服务器也位于同一个逻辑网络中，这通常由提供网站的公司来配置和管理。
透明代理只能设置在网关上。用户访问Internet的数据报必然都经过网关，如果在网关上设置代理，则该代理对用户来说显然是透明的。透明代理可以看作正向代理的一种特殊情况。
代理服务器通常还提供缓存目标资源的功能，这样用户下次访问同一资源时速度将很快。优秀的开源软件squid，varnish都是提供了缓存能力的代理服务器软件，其中squid支持所有代理方式，而varnish仅能用作反向代理。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）