PNG format Analysis

Preface

We all know that during the development of the mobile phone application program for j2's, we can use images in PNG format (even on some mobile phones ).
Only images in PNG format can be used. Although images can be used to add many highlights to our application, only images in PNG format are supported, which further limits our potential.
(In fact, it should be said that the processing capability on the mobile phone platform is limited ).

In midp2 or APIs provided by some vendors (such as Nokia), drawpixels/getpixels methods are provided, which further improves developers' processing.
The flexibility of the image, however, is not fully popularized in midp2 today, we need
The implementation of such methods in. 0 is still whimsical. Therefore, to achieve more advanced applications, we must fully tap the potential of PNG.

PNG file structure

For a PNG file, the file header is always described by fixed Bytes:

Decimal number	137 80 78 71 13 10 26 10
Hexadecimal number	89 50 4E 47 0d 0a 1A 0a

The first byte 0x89 is out of the ASCII character range to prevent some software from processing PNG files as text files. The remaining parts of the file are composed of 3 or more PNG data blocks.
(Chunk) is composed in a specific order. Therefore, a standard PNG file structure should be as follows:

PNG file flag

PNG data block

......

PNG data block

PNG data block (chunk)

PNG defines two types of data blocks. One is critical
Chunk). This is a standard data block, and the other is called an auxiliary data block (ancillary

Chunks). This is an optional data block. Key data blocks define four standard data blocks. Each PNG file must contain them. PNG read/write software must also support these data blocks. Although
The PNG file specification does not require the PNG encoding/Decoding of optional data blocks. However, the specification advocates that optional data blocks are supported.

The following table lists the types of data blocks in PNG. The key data blocks are distinguished by the dark background.

PNG file format data Block
Data Block symbol	Data Block name	Multiple Data blocks	Optional	Location restrictions
Ihdr	File header data block	No	No	First
CHRM	Base color and white point data block	No	Yes	Before plte and idat
Gama	Image gamma data block	No	Yes	Before plte and idat
Sbit	Sample valid BIT data block	No	Yes	Before plte and idat
Plte	Color Palette data block	No	Yes	Before idat
Bkgd	Background color data block	No	Yes	Before idat after plte
Hist	Image histogram data block	No	Yes	Before idat after plte
TRNS	Transparent data block	No	Yes	Before idat after plte
Offs	(Private Public Data blocks)	No	Yes	Before idat
Phys	Physical pixel size data block	No	Yes	Before idat
Scal	(Private Public Data blocks)	No	Yes	Before idat
Idat	Image Data Block	Yes	No	Continuous with other idat
Time	Last modification time data block of the image	No	Yes	Unlimited
Text	Text Information Data Block	Yes	Yes	Unlimited
Ztxt	Compressing text data blocks	Yes	Yes	Unlimited
Frac	(Private Public Data blocks)	Yes	Yes	Unlimited
Gifg	(Private Public Data blocks)	Yes	Yes	Unlimited
Gift	(Private Public Data blocks)	Yes	Yes	Unlimited
Gifx	(Private Public Data blocks)	Yes	Yes	Unlimited
Iend	Image end data	No	No	Last data block

For the sake of simplicity, we assume that in the PNG file we use, the four data blocks are stored in the above Order, and only appear once.

Data Block Structure

In a PNG file, each data block consists of four parts:

Name	Bytes	Description
Length)	4 bytes	The length of the data field in the specified data block. The length cannot exceed (231 -1) bytes
Chunk type code (data block type code)	4 bytes	The data block type code consists of ASCII letters (A-Z and A-Z)
Chunk data (data block data)	Variable Length	Store data specified by chunk type code
CRC (Cyclic Redundancy detection)	4 bytes	The storage is used to check whether there are error cyclic verification codes.

The value in the CRC (cyclic redundancy check) field is for the chunk type code field and chunk
The data in the data field is calculated. The specific CRC algorithm is defined in ISO
In 3309 and ITU-T v.42, the value is calculated according to the following CRC code generated polynomial:

X32
+ X26
+ X23
+ X22
+ X16
+ X12
+ X11
+ X10
+ X8
+ X7
+ X5
+ X4
+ X2
+ X + 1

Next, let's take a look at the structure of each key data block in sequence.

Ihdr

File header data block ihdr (Header
Chunk): it contains the basic information of the image data stored in the PNG file, and must appear as the first data block in the PNG data stream, and a PNG data stream can only have one file header data
Block.

The file header data block consists of 13 bytes. Its format is shown in the following table.

Domain Name	Bytes	Description
Width	4 bytes	Image Width, in pixels
Height	4 bytes	Image Height, in pixels
Bit depth	1 byte	Image depth: Indexed color images: 1, 2, 4, or 8 Grayscale Images: 1, 2, 4, 8, or 16 True Color Image: 8 or 16
Colortype	1 byte	Color type: 0: grayscale image, 1, 2, 4, 8, or 16 2: true color image, 8 or 16 3: indexing color images, 1, 2, 4, or 8 4: grayscale image with alpha channel data, 8 or 16 6: true color image with alpha channel data, 8 or 16
Compression Method	1 byte	Compression Method (lz77 derived algorithm)
Filter Method	1 byte	Filter Method
Interencryption Method	1 byte	How to scan through multiple rows: 0: Non-interlace Scan 1: adam7 (7 times of interlace scan developed by Adam M. Costello)

Because we are studying PNG on the mobile phone, first let's take a look at the requirements of midp1.0 for the PNG images used:

• In midp1.0, we can only use PNG images of version 1.0. In addition, PNG key data blocks have special requirements:
  Ihdr
• File Size: MIDP supports PNG images of any size. However, if an image is too large, it cannot be read due to memory depletion.
• Color type: All color types are supported, although the display of these colors depends on the display capability of the actual device. At the same time, MIDP also supports Alpha channels. However, all alpha-channel messages
  Will be ignored and treated as an opaque color.
• Color Depth: All colors are supported.
• Compression Method: only the compression method 0 (deflate compression mode) is supported, which is the same as the compression method of jar files. Therefore, the decompression of PNG image data and JAR file can be the same.
  . (In fact, this is the reason why corner stone supports PNG images :))
• Filter Method: although only method 0 is defined in the PNG White Paper, all five methods are supported!
• Line-based scan: although the MIDP supports the 0 and 1 methods, the MIDP does not actually use the line-based scan method for display when line-based scan is used.
• Plte Chunk: supported
• Idat Chunk: The image information must be filtered in five ways: 0 (none, sub, up,
  Average, paeth)
• Iend Chunk: When the iend data block is found, this PNG image is regarded as a valid PNG image.
• Optional data blocks: MIDP supports the following secondary data blocks. However, this is not required.
  

  Bkgd CHRM Gama hist ICCP itxt phys
  Sbit splt sRGB text time tRNS ztxt

For more information, see http://www.w3.org/TR/REC-png.html

Plte

The palette data block plte (palette chunk) contains an index color image (indexed-color)
The color conversion data, which is only related to indexed color images and must be placed in image data blocks.
Data chunk.

Plte data blocks are the palette information that defines the image. plte can contain 1 ~ There are 256 palette information. Each palette information consists of three Bytes:

Color	Bytes	Meaning
Red	1 byte	0 = Black, 255 = red
Green	1 byte	0 = Black, 255 = green
Blue	1 byte	0 = Black, 255 = blue

Therefore, the length of the color palette should be a multiple of 3. Otherwise, this will be an invalid color palette.

For indexed images, the color palette information is required. The color index of the palette starts from 0, followed by 1, 2 ......, The number of colors in the color palette cannot exceed the number of colors specified in the color depth (when the color depth is 4
The number of colors in the color palette cannot exceed 2 ^ 4 = 16). Otherwise, the PNG image is invalid.

Real-color images and true-color images with alpha channel data can also have color palette data blocks, so that the non-real-color display program can use it to quantify image data and display the image.

Idat

Image Data Block idat (image data
Chunk): It stores the actual data and can contain multiple consecutive sequential image data blocks in the data stream.

Idat stores the real data information of the image. Therefore, if we can understand the idat structure, we can easily generate PNG images.

Iend

Image Trailer
Chunk): it is used to mark the PNG file or the data stream has ended, and must be placed at the end of the file.

If we carefully observe the PNG file, we will find that the last 12 characters of the file should always look like this:

00 00 00 00 49 45 4E 44 AE 42 60 82

It is hard to understand that due to the definition of the data block structure, the iend data block length is always 0 (00 00
00, unless information is manually added), the data ID is always iend (49
45 4E 44), so the CRC code is always AE 42 60 82.

Instance research PNG

The following is an image generated by fireworks. The image size is 8x8,
Is
For your convenience, we will enlarge the image:

Use ultraedit32 to open the file as follows:
00000000 ~ 00000007:

As you can see, the selected first 8 bytes are the identification of the PNG file.

The next part is the ihdr data block:

00000008 ~ 00000020:

• 00 00 00 0d indicates that the length of the ihdr header is 13
• 49 48 44 52 ihdr logo
• 00 00 00 08 image width, 8 pixels
• 00 00 00 08 Image Height, 8 pixels
• 04
  Color depth, 2 ^ 4 = 16, that is, this is a 16-color image (it is also possible that the number of colors does not exceed 16, of course, if the number of colors does not exceed 8, it is more appropriate to use 03)
• 03 color type, index image
• 00 PNG
  Spec specifies that the total value here is 0 (the non-0 value is reserved for better compression methods in the future), indicating the compression method (lz77 derived algorithm)
• 00 same as above
• 00 non-interlace Scan
• 36 21 A3 B8 CRC verification

00000021 ~ 0000002f:

Optional data block sbit, color sampling rate, RGB all 256 (2 ^ 8 = 256)

00000030 ~ 00000062:

Here is the color palette Information

• 00 00 00 27 indicates that the color palette is 39 bytes long and has 13 colors.
• 50 4C 54 45 plte ID
• FF 00 color 0
• FF ed 00 color 1
• ...... ......
• 09 00 B2 last color, 12
• 5f F5 BB dd CRC verification

00000063 ~ 000000c5:

This part contains three data blocks of the Phys and text types. Because it is not very important, it is not described in detail.

201700c0 ~ 000000f8:

The selected part is the idat data block.

• 00 00 00 27 Data Length: 39 bytes
• 49 44 41 54 idat ID
• 78 9C ...... The compressed data. lz77 derives the compression method.
• Da 12 06 A5 CRC verification

The compressed data section in idat will be described in detail later.

000000f9 ~ 00000104:

Iend data blocks. As mentioned above

00 00 00 00 49 45 4E 44 AE 42 60 82

So far, we have been able to identify each data block from a PNG file. As PNG stipulates that all other auxiliary data blocks except key data blocks are optional, with this standard, we
You can delete all auxiliary data blocks to reduce the size of the PNG file. (Of course, it should be noted that, in PNG format, information such as layers and text in the image can be stored. Once these auxiliary data blocks are deleted,
The image will not be editable .)

The PNG file after the auxiliary data block is deleted. The current file size is 147 bytes, and the original file size is 261 bytes. After the file size is reduced, the image is not affected.
.

In fact, we can do some interesting things by changing the color value of the color palette, such as achieving the flow effect of clouds/water waves and the fade-in and fade-out effect of images.
Here, give a link for everyone to see maybe more direct: http://blog.csdn.net/flyingghost/archive/2005/01/13/251110.aspx
,
I wrote this article, which is inspired by this article.

As mentioned above, idat data blocks are generated using the lz77 compression algorithm. Due to the limitations of mobile phone processors, If we generate the number of idat
The lz77 compression algorithm is still used for data blocks, which will greatly reduce the efficiency. Therefore, for efficiency, only the lz77 Algorithm without compression can be used. This article does not describe the implementation of the lz77 algorithm, for example
If you are interested in the Java implementation of the lz77 algorithm, you can refer to the following two sites:

• Http://jazzlib.sourceforge.net/
• Http://www.jcraft.com/jzlib/index.html

References:

PNG file format White Paper: http://www.w3.org/TR/REC-png.html

The few Chinese PNG format description: http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm

RFC-1950 (zlib compressed data format specification): ftp://ds.internic.net/rfc/rfc1950.txt

RFC-1950 (deflate compressed data format specification): ftp://ds.internic.net/rfc/rfc1951.txt

JAVA Implementation of lz77 algorithm: http://jazzlib.sourceforge.net/

Lz77 algorithm Java implementation, including the j2-version: http://www.jcraft.com/jzlib/index.html

 

Address: http://www.ismyway.com/png/png-struct1.htm