REC-png.html
PNG (Portable Network Graphics) Specification
Version 1.0
W3C Recommendation 01-October-1996
Previous page
Next page
Table of contents
To allow new chunk types to be added to PNG, it is necessary to
establish rules about the ordering requirements for all chunk types.
Otherwise a PNG editing program cannot know what to do when it
encounters an unknown chunk.
We define a "PNG editor" as a program that modifies a PNG file and
wishes to preserve as much as possible of the ancillary information in
the file. Two examples of PNG editors are a program that adds or modifies
text chunks, and a program that adds a suggested palette to a truecolor
PNG file. Ordinary image editors are not PNG editors in this
sense, because they usually discard all unrecognized information while
reading in an image. (Note: we strongly encourage programs handling PNG
files to preserve ancillary information whenever possible.)
As an example of possible problems, consider a hypothetical new
ancillary chunk type that is safe-to-copy and is required to appear
after PLTE if PLTE is present. If our program to
add a suggested PLTE does not recognize this new
chunk, it may insert PLTE in the wrong place, namely after
the new chunk. We could prevent such problems by requiring PNG
editors to discard all unknown chunks, but that is a very unattractive
solution. Instead, PNG requires ancillary chunks not to have ordering
restrictions like this.
To prevent this type of problem while allowing for future extension,
we put some constraints on both the behavior of PNG editors and the
allowed ordering requirements for chunks.
The rules for PNG editors are:
-
When copying an unknown unsafe-to-copy ancillary chunk, a PNG editor
must not move the chunk relative to any critical chunk. It can relocate
the chunk freely relative to other ancillary chunks that occur between
the same pair of critical chunks. (This is well defined since the
editor must not add, delete, modify, or reorder critical chunks if it is
preserving unknown unsafe-to-copy chunks.)
-
When copying an unknown safe-to-copy ancillary chunk, a PNG editor must
not move the chunk from before IDAT to after IDAT or
vice versa. (This is well defined because IDAT is always
present.) Any other reordering is permitted.
-
When copying a known ancillary chunk type, an editor need
only honor the specific chunk ordering rules that exist for that chunk
type. However, it can always choose to apply the above general rules
instead.
-
PNG editors must give up on encountering an unknown critical chunk
type, because there is no way to be certain that a valid file will
result from modifying a file containing such a chunk. (Note that
simply discarding the chunk is not good enough, because it might
have unknown implications for the interpretation of other chunks.)
These rules are expressed in terms of copying chunks from an input
file to an output file, but they apply in the obvious way if a PNG
file is modified in place.
See also
Chunk naming conventions.
The ordering rules for an ancillary chunk type cannot be any stricter
than this:
- Unsafe-to-copy chunks can have ordering requirements relative to
critical chunks.
- Safe-to-copy chunks can have ordering requirements relative to
IDAT.
The actual ordering rules for any particular ancillary chunk type may
be weaker. See for example the ordering rules for the standard
ancillary chunk types
(Summary of standard chunks).
Decoders must not assume more about the positioning of any
ancillary chunk than is specified by the chunk ordering rules.
In particular, it is never valid to assume that a specific ancillary
chunk type occurs with any particular positioning relative to other
ancillary chunks. (For example, it is unsafe to assume that your
private ancillary chunk occurs immediately before IEND.
Even if your application always writes it there, a PNG editor might
have inserted some other ancillary chunk after it. But you can
safely assume that your chunk will remain somewhere between
IDAT and IEND.)
Critical chunks can have arbitrary ordering requirements, because PNG
editors are required to give up if they encounter unknown critical
chunks. For example, IHDR has the special ordering rule that
it must always appear first. A PNG editor, or indeed any PNG-writing
program, must know and follow the ordering rules for any critical
chunk type that it can emit.
Previous page
Next page
Table of contents