PNG file format

 

PNG file structure analysis (I: Understand the PNG file storage format)

 

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, we can only use images in PNG format), even though images can be added to our applications? Many highlights, however, the support for PNG images alone limits the possibility of further improvement (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 improve the flexibility of developers in processing images. However, in the days when midp2 has not been fully popularized, we need. 0 implementation of this type of method is still whimsical, so in order 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 avoid some software processing PNG files as text files. The remaining parts of the file are composed of more than three PNG data blocks (chunks) 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, which is a standard data block, and the other is ancillary chunks ), this is an optional data block. Important data blocks define four standard data blocks, each of which must be included in a PNG file. PNG read/write software must also support these data blocks. Although the PNG file specification does not require the PNG codecs to encode and decode optional data blocks, the specification advocates the support of optional data blocks.

The following table lists the types of data blocks in PNG. We use a dark background to Distinguish important data blocks.

Data blocks in PNG file format
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, If we store the four data blocks in the PNG file we use in the above sequence, they only appear once.

Data Block Structure

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

Name	Bytes	Description
Length)	4 bytes	Specifies the length of the data field in a 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)	4 bytes	Store the cyclic verification code used to check whether the token has an error

The value in the CRC (cyclic redundancy check) field is calculated for the data in the chunk type code field and chunk data field. CRC detailed algorithms are defined in ISO 3309 and ITU-T v.42, and their values are calculated based on the following CRC codes:

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 important data block.

Ihdr

File header data block ihdr (header chunk): it includes basic information about the image data stored in the PNG file, and needs to be used as the first data block to appear in the PNG data stream, in addition, a PNG data stream only has 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 of all, let's 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, important PNG data blocks have special requirements:
  Ihdr
• File size: the MIDP supports PNG images of any size. However, if an image is too large, it cannot be read because the memory is exhausted.
• 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 information is ignored and treated as opaque colors.
• 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 same Code can be used for extracting PNG image data and jar files. (In fact, this is the reason why j2's support for PNG images is very good :))
• 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 the following 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

You can take an exam for a large amount of other information.Http://www.w3.org/TR/REC-png.html

Plte

The palette data block plte (palette chunk) includes color transformation data related to the indexed color image, which is only related to the indexed color image, it must be placed before the image data chunk.

Plte data blocks are the palette information that defines the image. plte can include 1 ~ 256 palette information, each of which 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, this will cause the PNG image to be 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 actual data and can include 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 indicates that a PNG file or data stream has ended and must be placed at the end of the file.

Assuming that we carefully observe the PNG file, we will find that the end of the file should always look like this:

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

It is not difficult to clarify that because of the definition of the data block structure, the length of the iend data block is always 0 (00 00 00, unless manually added? Information), 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. To make it easier for you to watch, we can enlarge the image:

Use ultraedit32 to open the file, for example:
00000000 ~ 00000007:

We can see that 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 cannot exceed 16, of course, assuming that the number of colors cannot exceed 8, use 03 to indicate that it is more appropriate)
• 03 color type, index image
• 00 PNG spec specifies that the total value here is 0 (non-0 values are 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 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 includes 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 detailed 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. Because PNG specifies that all other auxiliary data blocks except important data blocks are optional, with this standard, we can reduce the size of PNG files by deleting all the auxiliary data blocks. (Of course, it should be noted that the PNG format can store layer and text information in the image. Once these auxiliary data blocks are deleted, the image will lose its editability .)

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

In fact, we can complete some interesting things by changing the color value of the color palette, such as the flow of clouds/water waves, and the fade-in and fade-out of images. Here, provide a link for you to see, maybe more directly:Http://blog.csdn.net/flyingghost/archive/2005/01/13/251110.aspxI wrote this article, which is inspired by this article.

As mentioned above, idat data blocks are generated using the lz77 compression algorithm because the mobile phone processor's capabilities are limited. Therefore, we assume that we still use the lz77 compression algorithm when generating idat data blocks, the efficiency will be greatly reduced. Therefore, we can only use the non-compressed lz77 Algorithm for efficiency purposes. This article does not intend to go into details about the implementation of lz77 algorithm, if you are interested in the Java implementation of the lz77 algorithm, you can refer to the following two websites:

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

PNG file structure analysis (below: generate a PNG file on the mobile phone)

(Read)

We have learned about the PNG storage format above. Therefore, to generate a PNG image, you only need to write the file according to the above data block.

(Because the ihdr and plte structures are very easy, Here we only focus on the idat generation method, and the ihdr and plte data content follow the above data content)

This is indeed the problem. We know that for most graphic files, we can map the actual image content into a two-dimensional color array. For the above PNG files, because it uses a 16-color palette (actually 13 colors), The ing of images can be as follows:

(Comparison of color palette)

12	11	10	9	8	7	6	5
11	10	9	8	7	6	5	4
10	9	8	7	6	5	4	3
9	8	7	6	5	4	3	2
8	7	6	5	4	3	2	1
7	6	5	4	3	2	1	0
6	5	4	3	2	1	0	0
5	4	3	2	1	0	0	0

In the PNG spec, it is pointed out that, if the PNG file is not stored by the scanner, the data is stored by line (scanline). to distinguish the first line, PNG requires that 0 be added before each row to indicate differentiation. Therefore, the above image ing should be as follows:

0	12	11	10	9	8	7	6	5
0	11	10	9	8	7	6	5	4
0	10	9	8	7	6	5	4	3
0	9	8	7	6	5	4	3	2
0	8	7	6	5	4	3	2	1
0	7	6	5	4	3	2	1	0
0	6	5	4	3	2	1	0	0
0	5	4	3	2	1	0	0	0

In addition, it should be noted that because PNG stores images in order to save space, each row is stored in bit instead of the bytes we think ), if you have not forgotten it, the color depth in our ihdr data block indicates this. Therefore, to make up the idat required by PNG, we need to change the data to the following:

0	203	169	135	101
0	186	152	118	84
0	169	135	101	67
0	152	118	84	50
0	135	101	67	33
0	118	84	50	16
0	101	67	33	0
0	84	50	16	0

Finally, we can compress the data with lz77 to obtain the correct idat content.

However, this is not so simple. Because we are studying PNG on the mobile phone, we assume that lz77 compression needs to be completed on the mobile phone, and the time consumed is imaginable. Therefore, we have to try again to reduce the time consumed during compression.

Fortunately, lz77 also provides a non-compression method (strange ?), Therefore, we only need to simply write data in a non-compressed manner, so that even if the space is wasted, the time is returned!

Well, let's take a look at how to compress lz77 blocks without compression:

Bytes	Meaning
0 ~ 2	Compressed information, fixed to 0x78, 0xda, 0x1
3 ~ 6	The Len and nlen information of the compressed block.
Compressed Data
Last 4 bytes	Adler32 Information

When Len is the index data length, it occupies two bytes. For our image, the first scan line contains five bytes (such as 0,203,169,135,101 of the first row ), therefore, the Len value is 5 (byte/row) x 8 (ROW) = 40 (byte), the generated byte is 28 00 (the low byte is in front of), and nlen is the complement of Len, that is, nlen = Len ^ 0 xFFFF, so nlen is D7 ff, adler32 information is 24 A7 0b A4 (for details about the algorithm, see the source program). Therefore, in this order, we generate an idat data block. Finally, we can write the ihdr, plte, idat, and iend data blocks into the file to get the PNG file,

(The selected part is the generated "COMPRESSED" data)

Now, we can convert the array to a PNG Image in the fastest time.

 

Exam materials:

PNG file format White Paper:Http://www.w3.org/TR/REC-png.html
A few Chinese PNG format descriptions:Http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm
RFC-1950 (zlib compressed data format specification ):Ftp://ds.internic.net/rfc/rfc1950.txt
The RFC-1950 (deflate compressed data format specification ):Ftp://ds.internic.net/rfc/rfc1951.txt
JAVA Implementation of lz77 algorithm:Http://jazzlib.sourceforge.net/
JAVA Implementation of the lz77 algorithm, including the j2_version:Http://www.jcraft.com/jzlib/index.html

PNG file format