GIF Conversion Info (gIFg, gIFx)
- Status: officially registered (PNG Extensions)
- Location: anywhere
- Multiple: yes
Since PNG originated as an intended replacement for GIF, one requirement for
the new format was to be able to store all possible GIF information in one
form or another. Part of that requirement is addressed by chunks we've
already described. Within GIF's Logical Screen Descriptor (the global
header that immediately follows the GIF signature bytes), the Pixel Aspect
Ratio, Color Resolution, and Background Color Index fields map to pHYs, sBIT,
and bKGD, respectively. Note that Background Color Index only applies if
there is a Global Color Table, however. Within the Image Descriptor, the
Image Left Position and Image Top Position fields map to oFFs. And within
the Graphic Control Extension, the Transparent Color Index maps to tRNS.
This is summarized in Table 11-8.
|
Table 11-8.
Correspondence Between GIF Fields and Standard PNG Chunks
|
| GIF Block |
GIF Variable Name |
PNG Chunk
|
| Logical Screen Descriptor |
Pixel Aspect Ratio |
pHYs |
| Color Resolution |
sBIT |
| Background Color Index |
bKGD |
| Image Descriptor |
Image Left Position |
oFFs |
| Image Top Position |
oFFs |
| Graphic Control Extension |
Transparent Color Index |
tRNS |
The remainder of the requirement that PNG be able to store all GIF information
is addressed by two of PNG's three GIF extension chunks. Both correspond
directly to GIF89a extensions: the Graphic Control Extension (gIFg) and the
Application Extension (gIFx). The third chunk, gIFt, turns out to be an
unintended special case; it is discussed separately later.
GIF's Graphic Control Extension is most commonly used to indicate
transparency, for which it corresponds most closely to PNG's tRNS
chunk. But it is also used in multi-image GIFs to provide timing and
compositing information. Although this is more properly the realm of
MNG, PNG's multi-image cousin (which I'll discuss in Chapter 12, "Multiple-Image Network Graphics", PNG
also supports the conversion of a multi-image GIF into several
single-image PNGs. The gIFg chunk is used to encode the
nontransparency information in the GIF extension block so that
lossless conversion back to an animated GIF is possible.
The gIFg chunk, shown in Table 11-9, contains only three fields.
| Field |
Length and Valid Range
|
| Disposal method |
1 byte (0-3) |
| User input |
1 byte (0, 1) |
| Delay time |
2 bytes (0-65,535) |
The interpretation and value of each field are identical to those in part 23
of the GIF89a Specification, with the exception that the 2-byte delay time
is stored in big-endian order (most significant byte first) in gIFg, whereas
GIF integers are stored in little-endian format. PNG decoders may treat the
delay time (measured in hundredths of a second) as the maximum amount of time
to display the image before going on to the next one, if any, but it is likely
that most decoders will ignore the chunk entirely.
GIF's Application Extension is simply a way for an application to include its
own information in the image; it corresponds exactly to a private chunk in a
PNG image. The format is given in Table 11-10.
| Field |
Length and Valid Range
|
| Application identifier |
8 bytes (printable ASCII characters) |
| Authentication code |
3 bytes |
| Application data |
n bytes |
The contents of gIFx are a direct transcription of the GIF data, with the sole
exception that any GIF sub-blocks are deblocked into a flat stream.
|
PNG Options and Extensions 
