一般PNG图片压缩的Java实现

      由于对资源或网速的要求,在手机游戏或一般的网页游戏中,希望能对图片进最大可能的压缩,以节省资源。最近公司做的项目也有对这方面的需求,于是我在网上逛了半天,希望能发现现成版的Java方法可以使用(用程序来压缩而不借助于工具,要不然2万多张的图片你想累死人?虽然PS有批量功能,它却无法按原来的路径存放);失望的是,好像没发现什么能直接使用代码,哪怕是提个解决方案也很少。既然网上找不到合适的,那就自己动手,丰衣足食。

      关于PNG图片的格式我在此就不多说,图片压缩方面的理论知识我也不在这多此一举,网上资料一大堆。开门见山,我们的目标是怎样用Java把PNG图片尽最大可能的压缩;当然,不能看出明显的失真。

      一:BufferedImage类

      在Java中,关于图片处理我们自然而然的想到了BufferedImage类,深入了解它,你会发现其实Java已经帮我们做好了图片压缩了,只是压缩完的图片和我们的需求有一点点偏差.......先看看BufferedImage最常用的构造方法:

 public BufferedImage(int width,int height,int imageType);

      构造一个类型为预定义图像类型之一的 BufferedImage,其中imageType有以下几种:

BufferedImage.TYPE_INT_RGB:8 位 RGB 颜色分量,不带alpha通道。

BufferedImage.TYPE_INT_ARGB:8 位 RGBA 颜色分量,带alpha通道。

BufferedImage.TYPE_INT_ARGB_PRE:8 位 RGBA 颜色分量,已预乘以 alpha。

BufferedImage.TYPE_INT_BGR:8 位 RGB 颜色分量Windows 或 Solaris 风格的图像,不带alpha通道。

BufferedImage.TYPE_3BYTE_BGR:8位GBA颜色分量,用3字节存储Blue、Green和Red三种颜色,不存在alpha。

BufferedImage.TYPE_4BYTE_ABGR:8位RGBA颜色分量,用3字节存储Blue、Green和Red三种颜色以及1字节alpha。

BufferedImage.TYPE_4BYTE_ABGR_PRE:具有用3字节存储的Blue、Green和Red三种颜色以及1字节alpha。

BufferedImage.TYPE_USHORT_565_RGB:具有5-6-5RGB颜色分量(5位Red、6位Green、5位Blue)的图像,不带alpha。

BufferedImage.TYPE_USHORT_555_RGB:具有5-5-5RGB颜色分量(5位Red、5位Green、5位Blue)的图像,不带alpha。

BufferedImage.TYPE_BYTE_GRAY:表示无符号byte灰度级图像(无索引)。

BufferedImage.TYPE_USHORT_GRAY:表示一个无符号short 灰度级图像(无索引)。

BufferedImage.TYPE_BYTE_BINARY:表示一个不透明的以字节打包的 1、2 或 4 位图像。

BufferedImage.TYPE_BYTE_INDEXED:表示带索引的字节图像。  

      其实imageType就是对应着Java内不同格式的压缩方法,编号分别为1-13;下面我们将一张原图用下面的几句代码分别调用不同的参数生成图片看看:

      原图如下,PNG格式,大小24.0KB:

原图(24.0KB)

     压缩后的图片:

TYPE_INT_RGB(9.21KB)  TYPE_INT_ARGB(11.4KB)  TYPE_INT_ARGB_PRE(11.4KB)  TYPE_INT_BGR(9.21KB)  TYPE_3BYTE_BGR(9.21KB)  TYPE_4BYTE_ABGR(11.4KB)  TYPE_4BYTE_ABGR_PRE(11.4KB)   TYPE_USHORT_565_RGB(5.72KB)   TYPE_USHORT_555_RGB(4.74KB)  TYPE_BYTE_GRAY(3.24KB)  TYPE_USHORT_GRAY(6.62KB)  TYPE_BYTE_BINARY(0.38KB)  TYPE_BYTE_INDEXED(3.50KB)

      从图片看到,黑白照片最小,不过这不是我们想要,排除;最后一张TYPE_BYTE_INDEXED类型的(其实就是PNG8)是彩色,也不大,但是失真太厉害了,排除;剩下的透明的那几个大小都一样,排除;对比剩下背景不透明的那几张,TYPE_USHORT_555_RGB就是我们要的压缩类型了。

       二:555格式的位图

    555格式其实是16位位图中的一种。16位位图最多有65536种颜色。每个色素用16位(2个字节)表示。这种格式叫作高彩色,或叫增强型16位色,或64K色。16位中,最低的5位表示蓝色分量,中间的5位表示绿色分量,高的5位表示红色分量,一共占用了15位,最高的一位保留,设为0。在555格式下,红、绿、蓝的掩码分别是:0x7C00、0x03E0、0x001F(在BufferedImage源码中也有定义)。

      三:进一步处理

      从图片效果可以看出,555格式非常接近真彩色了,而图像数据又比真彩图像小的多,非常满足我们的要求。但是我们需要背景是透明的,而用TYPE_USHORT_555_RGB生成的图片背景却是不透明的,自然而然的我们想到了把不透明的背景替换成透明的不就行了。 

   其中的isBackPixel(rgb)用于判断当前像素是否为背景像素:

   经转化后的图片如下:

   背景像素替换后(5.28KB)

   转化后稍微大了一点,这个可以接受;要命的是带了一个黑色边框。为什么呢?原因很简单,原图中边框部分的像素是介于透明和不透明之间的,而经过555格式压缩后所有像素都变成了布尔透明,也就是说所有的像素要么是透明的要么就是不透明的。

   最容易想到的方法就是把边框的像素换成原图边框的像素,关键在于怎么判断当前像素是否为图片的边框像素,这个算法可能得花费你一定的时间,下面只是我想到的一种实现:

   其中的cutedImage=cutImageAuto(sourceImage);是对原图进行裁剪,代码如下:

   改善后得到的图片:

   改善转化方法后的图片(6.34KB)

   实际上,这种方法只适用于图片颜色分明(边框颜色分明,背景颜色唯一),黑色像素不多的图片。一些比较特殊的图片就得特殊处理了,如以下图片:

   蜂(压缩前) 召唤门(压缩前)         压缩后      蜂(压缩后)   召唤门(压缩后)    

   原因是黑色不透明像素也是图片实体的一部分,这样就把它替换成白色透明的了。可以把代码改一下,但是图片的大小会增加不少,就是把程序认为是背景颜色的像素替换成原图片的像素;将compressImage()方法中的第33、43、61行改成 pixel[i]=sourcePixel[i]; 即可。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章