Original: an image compression format that can be quickly displayed, FH

An image compression algorithm that can be quickly displayed.
Author: HouSisong@GMail.com 2005.10.08

(: Refer to another open-source FRG image file format)

Tag: image format, texture compression, image compression algorithm, quick display, and quick Blend

Some popular video cards now support some texture compression methods, so that the video memory can multiply to accommodate more texture data (the benefit is self-evident); for example, s3tc (dxtc) fxt1, 3dc, etc. This paper proposes a software-only compression technology;

This is a method that supports fast display (or decompression) of pure software.Support 32bit argb(With 8-bit Alpha Channel) high fidelity compression solution (the application can quickly copy or blend to the display buffer without decompression ). The image format is based on the JPEG, 3dc, s3tc (dxtc), fxt1, and other compression solutions, especially the inspiration of cloud wind's article "high quality and high decoding speed and high-color image compression;

Basic Solution:Divide an image into 8x8 blocks. Find 16 or the following colors (called partial color palette) that can accurately describe these 64 pixels on an 8x8 block ); for each pixel of the original 64 pixels, only one 4-bit index value is saved to point to the nearest partial color palette. The obtained partial color palette is stored in a public color palette, the 8x8 block stores an index to the public palette, so that the image compression ratio can be easily calculated; original size: 64*32 bit; Compressed size: 64 * 4bit + 32bit + (0 ~ 16) * 32bit;
The compression ratio is: (2.56 ~ 7.11): 1; (in actual use, it is often possible to obtain an almost lossless compression ratio. Of course, you can also use other compression algorithms such as zip to further compress the image data; if the obtained data is further compressed using the Huffman or RLE Algorithm, a higher compression ratio can be obtained. At the same time, the process of loading data files from the hard disk to display will be faster in most cases ;)

Optimize the color palette: Since each partition has an index pointing to the public palette, it is easy to share some of the same palette during compression. For example: you can calculate the partial palette of adjacent blocks and then share the palette. Alternatively, you can share some of the palette. You can also find out whether the public palette is equivalent after the partition is computed... there are also some other algorithms that optimize the color palette (I think it should be better to create a global algorithm); (of course, these will not affect the image format and its display function );

Optimized display speed:To further optimize the display speed, add a block description (32bit) to the block compression data of 8x8, and define the description constant: default Value 0x0, completely transparent 0x2, completely opaque 0x4, single color 0x8, pixels completely transparent or completely opaque 0x10; to know whether a block has a certain attribute, you only need to test the corresponding bit field. For example, whether the block is a single color = (0! = (Block description & 0x8 ));

 Lossless compression:In the process of compressing 64 colors to 16 colors, the color loss of some blocks is too serious in some cases. In this case, you can consider adding a lossless compression scheme; add an information constant to the description of the block: lossless compression of 0x20, indicating no compression, 8x7 color data to the color palette, And the last 8 color data to the index data;

Supported regions of interest: This compression scheme supports selecting regions of interest during compression, that is, different regions adopt different compression rates;

Support constant time access for a single pixel; (Pixel Random Access supported)

 Limitations:The compression ratio is moderate and local rewriting is not supported (unless the size of the partial palette is fixed, but the compression is relatively small ); for images with smooth colors and strong changes in the local area, the compression ratio is relatively low (or the image can be compressed but the quality loss is relatively large );
 
Let's take a look.Compression Effect:

Effect after 0 compression of the source image (4.62: 1)

Effect after compression of source image 1 (with alpha channel) (4.7: 1)
 
A demo of compression and conversion (updated in 2007.06.29 ):

Http://download.csdn.net/source/202028

The file format used in the demo (*. FH ):
//// File Header ////
File Type: 'fof' 2 byte
File version '06' 2 byte two characters
The file format is '0a' 2 byte (the demo supports '0b' compression, that is, the color palette data and block data are compressed and saved using zlib, respectively. The compressed data format is as follows: after the color palette data is compressed, the length is 4 Bytes Integer + the color palette compressed data + the index data is compressed, and the length is 4 Bytes Integer + the index compressed data)
Start pixel offset DX 4 byte INTEGER (usually 0)
Start pixel offset DY 4 byte INTEGER (usually 0)
Actual pixel width 4 byte integer
Actual pixel height 4 byte integer
Global color palette length table_length 4 byte integer
The width of the compressed block data is an integer of pixelsnodewidth 4 byte.
Length of the compressed block pixelsnode_length 4 byte INTEGER (note here: pixelsnode_length = pixelsnodewidth * _ pixelsnodeheight)
/// Data zone '0a' format ////
Global palette 32bitargb array tabledata table_length * 4 byte
Compressed block array pixelsdata pixelsnode_length * (4 + 4 + 8*8*4/8) byte
 
(Description of the internal data format of a single compressed block pixelsnode:
Block description 0 nodetype 2 byte integer
Reserved block description 1 2 byte INTEGER (not used currently)
Index tableindex 4 byte integer of the global palette
Colorindexs 8*8 * 4bit = 32 byte (in the order from top to bottom, each row is encoded from left to right; for two index data in one byte, the pixels corresponding to the low position of 4 bits are in front)
)