Portable Network Graphics Frames Format Proposal Version 0.960810

Ninth draft

File

draft-pnf-0.960810.txt

Status of this Memo

This document is an informal draft of the PNG development group.

It is a proposal, and the format is subject to change.

Comments on this document can be sent to the PNG specification maintainers at

png-info@uunet.uu.net or at png-list@dworkin.wustl.edu.

Distribution of this memo is unlimited.

At present, the latest version of this document is available on the World Wide Web from

ftp://swrinde.nde.swri.edu/pub/png-group/documents/mpng/.

Changes from eighth draft (draft-pnf-960727)

Abstract

This document presents the [proposed] the format of a PNF (Portable Network graphics Frames) stream. PNF is a multiple-image format that can contain simple animations (slide shows) comprised of PNG single-image streams. It can also incorporate PND (Portable Network Delta) and composite frames, which are defined herein, and PNP (Portable Network Photo) images, once a definition for PNP is developed.

A PND stream defines an image in terms of an original PNG, PNP, or PND image and the differences from that image. This can provide a much more compact way of representing subsequent images than using a complete PNG or PNP stream for each.

A composite frame stream defines a single image whose subimages can be PNG, PND, or PNP single-image streams. A composite frame can be independent, or, if it contains PND streams, it can depend upon the information in the previous composite frame. The composite frame format provides a mechanism for using a subimage as a "sprite" that can be moved from one location to another in subsequent dependent composite frames.

The PNF and PND formats use the same chunk structure that is defined in the PNG specification, and share other features of the PNG format.

Table of Contents

1. Introduction

This [proposed] specification defines the format of the PNF (Portable Network graphics Frames) stream. It also defines the format of the PND (Portable Network graphics Delta) stream and the format of a single-image, composite frame stream. PND and the composite image stream can be components of a PNF stream.

Note: This [proposed] specification depends on the PNG Portable Network Graphics) and PNP (Portable Network Photograph) specifications. PNP is under discussion by pnp-list@dworkin.wustl.edu. The PNG specification is available at the PNG home page,

http://quest.jpl.nasa.gov/PNG/
A PNF stream describes a sequence of single images, each of which can be composed of one or more PNG, PNP, PND (PNG-Delta, defined herein), or composite images.

PNF is pronounced "Ping-frames."

When the PNF stream is a standalone file, use the PNG 8-byte header with "PNF" instead of "PNG" in bytes 2-4, and ".pnf" as the file suffix.

PNF does not accommodate sound or complex sequencing information, nor does it accommodate playing a stream backwards. Those are left to be described in the MPNG specification, which is yet to be defined, and is being discussed in the mpng-list@dworkin.wustl.edu mailing list.

Chunk structure (length, name, CRC) and the chunk-naming system are identical to those defined in the PNG specification. As in PNG, all integers that require more than one byte will be in network byte order.

A PNF stream consists of a FHDR chunk, followed by one or more image definitions, followed by the FEND chunk. The first image can be a PNG stream (IHDR, PNG chunks, IEND), a PNP stream PHDR, PNP chunks, PEND), or an "initial" composite frame (CHDR, composite frame chunks, CEND). Subsequent images can be any of these, or a PND stream (PHDR, PND chunks, PEND), or a "dependent" composite frame. Each chunk of the PNF stream or of any image definition is an independent entity, i.e., no chunk is enclosed in the data segment of another chunk.

2. Top-level PNF chunks

2.1. Critical PNF chunks

2.1.1. FHDR PNF stream header

4 bytes: max_frame_width  (unsigned integer,
         default 2^31-1)

4 bytes: max_frame_height (unsigned integer,
         default 2^31-1)

4 bytes: max_number_of_frames (unsigned integer,
         default 2^31-1)  There are not more than
         max_number_of_frames in this PNF stream.

4 bytes: max_chunk_length (unsigned integer,
         default 2^31-1)  No chunk in this stream,
         including in any included PNGs or PNPs, has
         a data field exceeding this length.

4 bytes: ticks_per_second  (unsigned integer, default 1)

4 bytes: frame_duration (unsigned integer, default 1) in
         ticks.  The time between the beginning of
         displaying one frame until the beginning of
         displaying the next.

4 bytes: total_duration (unsigned integer, default 2^31-1
         in ticks.  Maximum total duration of the entire
         stream.  The sum of the individual frame_durations
         must not exceed this value (under actual playback
         conditions the display is likely to take longer).

4 bytes: default_gamma (unsigned integer, default 100000).
         The value of gamma, times 100000, to be assumed
         for any images or subimages in the stream that do
         not supply their own value of gamma.  This default
         gamma value also applies to the background color
         or application-supplied background image, if the
         gamma value for the background is unknown, and is
         the gamma value to be assumed when using the gPLT
         chunk.

1 byte:  max_bit_depth (unsigned integer, default 16)

1 byte:  background_source (unsigned integer, default 0)
         0: use the supplied background color
         1: read the current display contents or application
            specified background if possible, but if not
            possible, then use supplied background color
         2: background is not required.

2 bytes: red_background (unsigned integer, default 0)

2 bytes: green_background (unsigned integer, default 0)

2 bytes: blue_background (unsigned integer, default 0)

1 byte:  ok_to_discard (unsigned integer, default 0)
         0: image data must be retained 
         1: image data may be discarded after processing
            each frame.  This is a promise that this PNF
            stream contains no PNDs or dependent composite
            frames)
Any of the FHDR data fields can be set equal to zero, meaning that the value assumes the default value. Encoders are strongly encouraged not to use zeros, especially for the max_frame_width and max_frame_height fields, though, if the information is available when the encoder is writing the FHDR chunk.

The FHDR chunk may be omitted, provided that the first chunk in the stream is IHDR or PHDR. In this event, decoders must assume the default values for all of the FHDR data, except that max_frame_width and max_frame_height values are defined by the width and height fields in the first IHDR or PHDR chunk.

2.1.2. FEND End of PNF stream

The FEND chunk's data length is zero. It signifies the end of a PNF stream.

2.1.3. IHDR, PNG chunks, IEND

A PNG (Portable Network Graphics) stream.

See the PNG specification for the format of the PNG chunks.

Any chunks between IHDR and IEND are written and decoded according to the PNG specification. The image width and height must not exceed max_frame_width and max_frame_height from the FHDR chunk.

2.1.4. DHDR, PND chunks, DEND

A PND (PNG-Delta) stream.

See Chapter 3, The PND Format, below, for the format of the PND stream. Any chunks between DHDR and DEND are written and decoded according to the PND format. The image width and height must not exceed max_frame_width and max_frame_height from the FHDR chunk.

2.1.5. PHDR, PNP chunks, PEND

A PNP (Portable Network Photo) stream.

See the PNP specification [not yet written] for the format of the PHDR chunk.

[It is assumed that the PNP stream will begin with a PHDR chunk and end with a PEND chunk, and it is assumed that the first two fields of PHDR will be unsigned 4-byte integers giving the image width and height. It is also assumed that the PNP image data will be contained in a sequence of PDAT chunks.]

The image width and height must not exceed max_frame_width and max_frame_height from the FHDR chunk.

Any chunks between PHDR and PEND are written and decoded according to the PNP specification. Until PNP is defined, it is acceptable for viewers to display an empty width by height frame when a PNP stream is encountered. Such viewers should, when encountering a PHDR chunk, simply skip chunks until a PEND chunk is found.

2.1.6. CHDR composite frame chunks, CEND

A composite frame stream. See Chapter 4, The composite frame, below, for the format of the composite frame stream.

2.1.7. SEEK Seek point

A seek point.
n bytes: previous (number of bytes since the
         previous SEEK chunk) If previous == 0,
         then the number of bytes is unspecified.

n bytes: next (number of bytes to the next SEEK
         chunk) If next == 0, then the number of
         bytes is unspecified.

n is the length of the SEEK chunk, divided by two.
         n must be either 4 or 8.
The SEEK chunk is only allowed at positions in the PNF stream where a restart is possible, and no information appearing prior to the SEEK chunk (other than the information in the FHDR chunk) is required to display the remainder of the stream properly. In addition to providing a mechanism for skipping frames or backspacing over frames, this provides a means of dealing with a corrupted datastream. The viewer would abandon processing and simply look for the next SEEK chunk before resuming. Note that looking for a PNG IHDR or PNP PHDR would not be sufficient because the PNG or PNP stream might be a subimage a of a composite frame rather than a complete frame description.

When n is eight, 32-bit machines will have to interpret "previous" as a set of two integers, the first representing the number of complete 4G blocks and the second (the last four bytes of "previous") as the remainder, and will have to treat "next" similarly.

"Previous" and "next" are measured from the first length byte of one SEEK chunk to the first length byte of another SEEK chunk.

Applications are allowed to forget everything preceding the SEEK chunk, except for data appearing in the FHDR chunk, so new instances of any needed chunks are required. The first frame following the SEEK chunk must not be defined by a PND stream or a "dependent" composite frame.

Multiple instances of the SEEK chunk are permitted.

2.2. Ancillary PNF chunks

2.2.1. dISC Ok to discard

The dISC chunk temporarily overrides the "ok_to_discard" field in the FHDR chunk, when "ok_to_discard" is zero. The dISC chunk's data length is zero. The presence of the chunk signifies that decoders may discard the subsequent PNG, PND, PNP, or composite frames after processing, and can rest assured that no PND or dependent composite frames will follow. The effect of the dISC chunk remains until a SEEK chunk is encountered. When the dISC chunk is not in effect, then decoders must keep the image data for possible use in a subsequent PND or dependent composite frame, if the "ok_to_discard" FHDR field is zero. It is not possible to override "ok_to_discard" when "ok_to_discard" is not zero.

Multiple instances of the dISC chunk are permitted.

2.2.2. dURa Duration

Duration of display.
4 bytes: duration (unsigned integer), in ticks, using
         the tick length determined from ticks_per_second
         defined in the FHDR chunk.
Overrides the value of duration given in the FHDR chunk. The value of "duration" will remain in effect until another "dURa" chunk is encountered or until a "SEEK" chunk is encountered, when the duration reverts to the value from FHDR. Multiple instances of the dURa chunk are permitted, but no more than one dURa chunk is permitted between any two critical chunks. The dURa chunk takes effect immediately; if a dURa is encountered after an image has been displayed, the next image can be started after the specified number of ticks have elapsed since the previous image was started.

2.2.3. tEXt, zTXt Text chunks

Same as PNG.

3. The PND format

A PND stream describes a single image, by giving the changes from a previous PNG (Portable Network Graphics), PNP (Portable Network Photo), or another PND image. While it is possible for a PND stream to be stored in a standalone file (where the original image is available in another standalone file), a PND stream will normally be found as a component of a PNF stream or a MPNG (Multiple Portable Network Graphics, yet to be defined) stream.

If the PND stream is a standalone file (not usually the case), use the PNG 8-byte header with "PND" instead of "PNG" in bytes 2-4, and use ".pnd" as the file suffix.

PND is pronounced "Ping-delta."

The decoder must have available an original (decoded) image from which the original chunk data is known. How the original image is made available to the decoder is up to the implementation. It could be in a separate file or it could be provided earlier in a PNF datastream. The original image can be the result of decoding a PNG, a PNP, or another PND stream. If alpha or transparency is present, then the decoder must also have available the original background against which the original image was displayed, if transparency or alpha are to be composited against the background.

The decoder must not have modified the pixel data in the original image by applying output transformations such as gAMA or cHRM, or by compositing the image against a background. Instead, the decoder must make available to the PND decoder the unmodified pixel data along with the values for the gAMA, cHRM, and any other recognized chunks from the original image datastream.

A PND stream consists of a DHDR and DEND enclosing other optional chunks (if there are no other chunks, the decoder simply copies the original image).

Chunk structure (length, name, CRC) and the chunk-naming system are identical to those defined in the PNG specification. Definitions of compression_type, filter_type, and interlace_type are also the same as defined in the PNG specification.

3.1. PND critical chunks

3.1.1. DHDR PND stream header

4 bytes: width
   Must match original image if IDAT or PDAT is not present.
   When IDAT or PDAT is present, the original pixel data is
   discarded entirely and replaced by a new image with
   dimensions width x height.

4 bytes: height
  Must match original image if IDAT or PDAT is not present

1 byte: bit_depth
  Must match bit_depth of original image if IDAT or PDAT is
  not present.

1 byte: color_type
  Must match original image if IDAT or PDAT is not present.

       0, 2, 3, 4, 6: same as PNG
       8: PNP grayscale image
      10: PNP color image
      12: PNP grayscale image with alpha
      14: PNP color image with alpha
[or whatever PNP developers decide]

1 byte: compression_type
  Same as PNG 

     [We might want to add a compression_type
     that uses deflate with the previous image
     data as a preset dictionary]

  Need not match original image.

1 byte: filter_type
  Same as PNG
  Need not match original image.

1 byte: interlace_type
  Same as PNG
  Need not match original image.

1 byte: delta_type
  0: subtraction, by bytes, modulo 256.

1 byte: copy-safe
  0: This stream contains no changes that would render
     unknown chunks unsafe-to-copy.  All chunks will be
     copied from the previous image unless they are
     mentioned in a NOCO chunk.
  1: This stream contains changes that would render
     unknown chunks unsafe-to-copy.  Such chunks will not
     be copied from the previous image unless they are
     mentioned in a COPY chunk.

3.1.2. DEND End of PND stream

End of PND stream. This chunk has a zero data length.

3.1.3. IDAT PNG image header

New image data in PNG format. Just as in PNG, multiple, consecutive IDAT chunks are allowed, whose contents, when concatenated, form a zlib datastream containing PNG pixel data. IDAT is not allowed if PDAT or DDAT is present.

3.1.4. PDAT PNP image data

New image data in PNP format, yet to be defined.

Until the PNP PDAT chunk is defined, it is acceptable for a PND decoder to skip this chunk.

Multiple, consecutive PDAT chunks are allowed, whose contents, when concatenated, form a PNP image description. PDAT is not allowed if IDAT or DDAT is present.

3.1.5. DDAT Pixel deltas

Deltas from an original image known to the decoder. DDAT is not allowed if IDAT or PDAT is present.

If DDAT is present, then the image width and height, color_type, and bit_depth must match those of the original image, and the original image must have been derived from a PNG stream or from a sequence of PND streams that depend upon a PNG stream, but not from a PNP stream.

Similarly to the PNG IDAT chunk, there can be multiple, consecutive DDAT chunks whose contents are concatenated to make up a zlib datastream that, when decompressed, contains a filtered and perhaps interlaced set of delta pixel samples. The actual pixel values are calculated using the method defined in the delta_type field of the FHDR chunk.

When delta_type is 0, an encoder calculates the bytes in the DDAT chunk by subtracting the new image bytes from the original image bytes, modulo 256. When decoding the DDAT chunk, the new image bytes are obtained by adding the delta bytes to the original image bytes, modulo 256. This is similar in operation to the PNG SUB filter.

When color_type is 3, the deltas are differences between index values (by bytes), not between color samples.

3.1.6. COPY Chunks to be copied

Chunks to be copied
4 bytes: chunkname_1
etc.
4 bytes: chunkname_n
COPY provides a list of chunknames that are to be copied (values inherited) from the original image, regardless of the copy-safe rules, and regardless of whether the chunk is recognized or not. The number of names is determined from the chunk length, divided by 4.

There can be multiple instances of the COPY chunk. A COPY chunk appearing before IDAT can be used to copy any incoming chunks. A COPY chunk appearing after IDAT can only be used to copy chunks appearing after IDAT in the original image.

The COPY chunk does not specify the placement of chunks within the resulting PNG stream; it merely marks them for copying. The decoder can place them in any order, relative to their order in the original image, that obeys the chunk-ordering rules for copy-safe chunks given in the PNG specification.

The COPY chunk data itself is inherited (unless "COPY" appears in a NOCO chunk), so a COPY chunk need only appear in the first of a sequence of PND streams, if there are no changes.

If a chunkname appears in a COPY chunk and also appears in a NOCO chunk, the last instance takes precedence. If the last instance appears after the IDAT, PDAT, or DDAT chunk, it will only affect chunks appearing after IDAT, PDAT, or DDAT chunk.

Applications that reconstruct a PNG or PNF stream from a PND stream and an original PNG, PNF, or PND stream should not write the COPY chunk to the resulting PNG or PNF stream, because the COPY chunk would not be recognized by a PNG or PNF decoder.

It is not an error for a chunkname to appear in the copy list, when that chunk does not appear in the original image.

3.1.7. NOCO Chunks not to be copied

Chunks not to be copied
4 bytes: chunkname_1
etc.
4 bytes: chunkname_n
NOCO provides a list of chunknames that are not to be copied (values not to be inherited) from the original image, regardless of the copy-safe rules, and regardless of whether the chunk is recognized or not. The number of names is determined from the chunk length, divided by 4.

There can be multiple instances of the NOCO chunk. When a NOCO chunk appears before IDAT, all instances of the named chunks will be marked for deletion. A NOCO chunk appearing after IDAT can only be used to delete chunks appearing after IDAT in the original image.

If a chunkname appears in a COPY chunk and also appears in a NOCO chunk, the last instance takes precedence. If the last instance appears after the IDAT, PDAT, or DDAT chunk, it will only affect chunks appearing after IDAT, PDAT, or DDAT chunk.

It is not an error for a chunkname to appear in the NOCO list, when that chunk does not appear in the original image.

Applications that reconstruct a PNG or PNF stream from a PND stream and an original PNG, PNF, or PND stream should not write the NOCO chunk to the resulting PNG or PNF stream.

The NOCO chunk data itself is inherited (unless "NOCO" appears in a NOCO chunk), so a NOCO chunk need only appear in the first of a sequence of PND streams, if there are no changes.

3.2. PND ancillary chunks

3.2.1. fADE fade in or out

This chunk can be used to "fade" an image in or out against the background, without having to transmit new alpha values.
   1 byte: (unsigned integer) fade_type
         0: fade out
         1: fade in
         2: fade in but don't change fully transparent
            pixels
   2 bytes: (unsigned integer) alpha_delta
When "fade_type" is 0, the value of alpha_delta is subtracted from the alpha sample of every pixel in the original image, but the result is not allowed to fall below zero.

When "fade_type" is 1, the value of alpha_delta is added to the alpha sample of every pixel in the original image, but the result is not allowed to exceed the maximum alpha value for the image's bit depth.

When "fade_type" is 2, the value of alpha_delta is added to the alpha sample of any pixel in the original image that has a non-zero value, and the result is not allowed to exceed the maximum alpha value for the image's bit depth.

If color_type is 3, then the value of alpha_delta is added to or subtracted from the alpha values that were defined by the tRNS chunk data in the original image, and the resulting values become the tRNS data exported to any subsequent image. The maximum alpha value for this color_type is 255, regardless of the bit depth.

If color_type is 0 or 2, the fADE chunk is ignored.

If DDAT, IDAT, or PDAT is also present, the fade operation is performed after decoding and applying the DDAT/IDAT/PDAT chunk data.

3.3. Other PND chunks

Any PNG or PNP chunk can appear in a PND stream, and are handled as described in the governing specification. When only one instance of the chunk is permitted in a PNG or PNP stream, the chunk data replaces the chunk data from the original file. When multiple instances are permitted, the chunk is treated as an additional instance. When the format depends on the color_type, the appropriate format must be used.

A gAMA, cHRM, or similar chunk existing in the original image would not affect the pixel data inherited by this PND stream because they are not used in decoding the pixel data. Applications are responsible for ensuring that the pixel values that are inherited from the previous image have not been transformed in any way after decompressing and unfiltering them.

When processing the oFFs and pHYS chunks, the viewer is responsible for providing the correct background if alpha or transparency is present; when the image size or location changes, the background will not be the same background against which the original image was composited.

When processing the tRNS chunk, if color_type is 3 and PLTE is not supplied, then the number of allowable entries is determined from the number of PLTE entries in the original image.

4. The composite frame

A composite frame is a single image, made up of the background (defined by the FHDR chunk) and zero or more subimages, each defined by a PNG, PNP, or PND stream. The LOCA chunk can be used to specify the placement of each subimage within the composite frame.

A composite frame can be an "initial" frame or a "dependent" frame. If it is "dependent" then it requires information inherited from the previous frame, such as the global palette (gPLT) and any PNG, PNP, or PND subimages that are to be redisplayed or that are to serve as the basis for a PND subimage. PNF viewers that process composite frames must be prepared to "remember" any number of such subimages from the immediately previous composite frame.

PNF viewers are expected to recognize and process the PNG pHYs and oFFs chunks encountered in subimages, even though these are ancillary chunks. When the pHYs chunk appears with unit_specifier=0, then that subimage should be scaled to to obtain the desired aspect ratio by scaling the image height and leaving the image width fixed.

4.1. Critical composite frame chunks

4.1.1. CHDR Composite frame header

Beginning of a composite frame.
4 bytes: composite_frame_width  (unsigned integer)
         (must match that of the previous frame if
         frame_type = 1, and must not exceed
         max_frame_width in the FHDR chunk)

4 bytes: composite_frame_height  (unsigned integer)
         (must match that of the previous frame if
         frame_type = 1, and must not exceed
         max_frame_height in the FHDR chunk)

4 bytes: x_dimension (unsigned integer), default 0,
         corresponding to composite_frame_width, in
         micrometers.  If non-zero, this value is to be
         used when processing pHYs and oFFs chunks
         found in subimages, even if the actual frame
         dimensions are otherwise available.

4 bytes: y_dimension (unsigned integer), default 0,
         corresponding to composite_frame_height.

1 byte:  frame_type
         0: Initial frame
         1: Dependent frame

4.1.2. CEND End of composite frame

End of composite frame. This chunk has a zero data length.

4.1.3. LOCA Subimage location

Location for the following subimage.

The LOCA chunk gives the position, measured downward and to the right of the upper left corner of the frame, where the following subimage is to be located.

The chunk's contents are:

4 bytes: Image position, X axis (signed integer)
4 bytes: Image position, Y axis (signed integer)
Negative values are permitted, and denote displacement in the opposite directions. LOCA can specify an image placement that is partially or wholly outside the frame boundaries. In such cases, the resulting subimage must be clipped to fit within the frame, or not displayed at all if it falls entirely outside the frame.

If the subimage contains an oFFs chunk, the subimage's offset is computed with respect to the position defined by the LOCA chunk (convert the oFFs distances to pixel units, and add them to the image position defined by LOCA).

After processing one subimage, the offset values revert to (0,0) until another LOCA chunk is encountered.

4.1.4. IHDR, PNG chunks, IEND

The image width and height are allowed to exceed those given in the CHDR chunk; if so, the image must be clipped to fit them.

4.1.5. DHDR, PND chunks, DEND

The image width and height are allowed to exceed those given in the CHDR chunk; if so, the image must be clipped to fit them.

4.1.6. PHDR, PNP chunks, PEND

The image width and height are allowed to exceed those given in the CHDR chunk; if so, the image must be clipped to fit them.

4.1.7. SODE Subimage source and destination

1 byte: source
        0: none (subimage will be completely defined
           in this frame by a PNG or PNP stream)
        1: subimage defined in previous frame
        2: subimage previously defined in this frame

1 byte: destination
        0: discard immediately after displaying subimage
        1: keep (make available for use by next PNF)
        2: discard after completion of this PNF

2 bytes: source ID (unsigned integer)
        when source=0: omitted
        when source=1: subimage identified by
           "destination ID" in the previous frame
        when source=2: subimage identified by
           "destination ID" earlier in this frame

2 bytes: destination ID (unsigned integer)
        when destination=0: omitted
        when destination=1: the "source ID" by which
            this subimage can be identified later in
            this frame or in the following frame
        when destination=2: the "source ID" by which
            this subimage can be identified later in
            this frame.
        Can be the same as the destination ID of a
            previous subimage, if the previous subimage
            will no longer be required.
If a SODE chunk is not followed by a subimage description (IHDR, DHDR, or PHDR), i.e. a CEND chunk or another SODE chunk is encountered prior to encountering any IHDR, DHDR, or PHDR chunk, then the subimage from the previous frame with the specified source ID is given the specified destination ID and is retained for possible use in the following frame, but is not displayed in the present frame.

If a subimage header chunk (IHDR or PHDR) is not preceded by a SODE chunk (i.e. no SODE chunk was encountered after the preceding CHDR, IEND, PEND, or DEND chunk), the chunk will be treated as if it had been preceded by a SODE chunk with source=0, destination=0, source ID and destination ID omitted.

The DHDR chunk introducing a PND stream must be preceded by a SODE chunk with a valid source ID.

4.2. Ancillary composite frame chunks

4.2.1. gPLT Global Palette

This chunk may be used to suggest a reduced global palette to be used when the display device is not capable of displaying the full range of colors present in the images. If present, it provides a recommended set of colors, with alpha and frequency information, that may be used to construct a reduced palette to which the truecolor image may be quantized.

The format of this chunk is identical to that of the [proposed] sPLT PNG chunk. The chunk's contents are a zero-byte-terminated text string that names the palette, followed by a series of palette entries, each a ten-byte series, containing five unsigned integers:

    name:      n bytes (ASCII text)
    null byte  1 byte  (terminator)

    red:       2 bytes (0 = black, 65535 = red)
    green:     2 bytes (0 = black, 65535 = green)
    blue:      2 bytes (0 = black, 65535 = blue)
    alpha:     2 bytes (0 = fully transparent,
                        65535 = fully opaque)
    frequency: 2 bytes (relative frequency of occurrence)
    ...

There can be any number of entries; a decoder determines the number of entries from the remaining chunk length after the null-terminated "name" string. This length not divisible by ten is an error. Entries must appear in decreasing order of "frequency".

The "name" (e.g. "rgba512 8-8-4-2 color cube", "rgb256 winter scenery", "rgb242 6-6-6 color cube plus 26 gray levels", "Windows white background", "50-color rgb palette for use with early versions of Mosaic") identifies the palette, which may permit applications or people to choose the appropriate one when more than one suggested palette appears in a PNF stream. The "name" string must consist only of printable ASCII characters and may not have leading or trailing blanks, but may have single embedded blanks. There must be at least one and no more than 79 characters in the name. Names are case-sensitive. Decoders should filter out any nonprintable characters, especially the ESC character, in the "name" string before displaying it, to avoid possible security hazards.

The red, green, and blue values are not premultiplied by alpha, nor are they precomposited against any background. A decoder can build a palette by compositing those palette entries against any background color or set of background colors that it chooses.

Each frequency entry is proportional to the approximate fraction of pixels in the images that are closest to that palette entry, without regard to any compositing against a background palette. The exact scale factor is chosen by the encoder, but should be chosen so that the range of individual values reasonably fills the range 0 to 65535. It is acceptable to artificially inflate the "frequency" values for "important" colors such as those in a company logo or in the facial features of a portrait. Zero is a valid value for frequency.

The palette uses 16 bits (2 bytes) per value regardless of the image bit depth specification. Decoders wishing to construct 8-bit palettes can accomplish this by scaling down the RGB entries to 8 bits, as described under "bit depth rescaling" in the PNG specification.

If the file gamma value for a subimage is different from the default gamma value from the FHDR chunk, decoders will need to gamma-correct the image samples before quantizing them to the gPLT palette.

Multiple gPLT chunks, with different names, are allowed within a composite frame description. If present, they must appear prior to any IHDR, DHDR, or PHDR chunk in the composite frame. The gPLT chunk may appear for any color type. When a subimage contains a PLTE or sPLT suggested palette, the gPLT data takes precedence.

4.2.2. oFFs Composite frame offset

Same as PNG, offsets the entire composite frame. If a subimage also contains an oFFs chunk, the values from both oFFs chunks are added together with the LOCA value to form a total offset for the subimage.

Only one oFFs chunk is allowed within a composite frame description, and, if present, it must appear prior to any IHDR, DHDR, or PHDR chunk in the composite frame.

4.2.3. tEXt, zTXt Text chunks

Same as PNG.

5. Security Considerations

Security considerations are addressed in the basic PNG specification.

The gPLT chunk contains a "name" field that might be printed or displayed as text by some applications. As with the tEXt chunk, any non-printable characters in the gPLT "name" field, especially the ESC character, should not be displayed directly.

No known additional security concerns are raised by this format.

Detection of corrupted file transfers can be improved even beyond that available in PNG by using the FHDR max_chunk_size field to determine whether any chunk length (except for that of FHDR itself, which has a known length that can be checked) is unreasonably large.

6. Appendix: Examples

6.1. Example 1: simple movie

\211 P N F \r \n ^z \n  # PNF signature
FHDR 720 468     # width and height
     20 65536  # 20 frames, max chunk length = 65kbytes
     30  3 60  # 10 frames per second, duration 60 ticks
     77000  8  # default gamma is 0.77, max_bit_depth 8
     2 0 0 0 0 # Background not required, not OK discard
tEXtTitle\0Sample Movie

SEEK 0 n1
IHDR 720 468 ...
IDAT ...
IEND

DHDR 720 468 ...# A PNG-delta frame
DDAT ...
DEND

DHDR 720 468 ...# Another PNG-delta frame
DDAT ...
DEND

SEEK n1 n2      # Ok to restart here because a
IHDR 720 468    # complete PNG frame follows
IDAT ...
IEND

DHDR 720 468 ...# another PNG-delta frame
DDAT ...
DEND

SEEK n2 0
FEND            # end of PNF stream

6.2. Example 2: single composite frame

Here's an example single-composite-frame PNF, which takes a grayscale image and draws it side-by-side with a false-color version of the same image:
\211 P N F \r \n ^z \n # PNF signature
FHDR 1024 512 1 8192 # width, height, nframes, maxchunklen
     0 0 0    # tick length, frame duration unspecified
     0        # default gamma value is 100000 (gamma=1.0)
     16       # depth 16
     1 64 64 192  # sky blue background
     1        # ok to discard
CHDR 1024 512 0 0 0  # Initial composite frame, 1024 x 512
LOCA 6 6             # Location of first subimage
SODE 0 2 1           # New object 1, keep for later use
IHDR 500 500 16 0 .. # A graylevel image (note, no PNG
gAMA 50000           #    signature here)
IDAT ...
IEND                 # End of subimage

SODE 2 0 1           # Reload object 1, discard afterwards
LOCA 518 6           # Location for second subimage.  Note
                     #    that SODE-LOCA order doesn't matter.
DHDR 500 500 16 0 .. # Png-delta, inherits gAMA and IDAT
                     #    from object 1
tEXtComment\0The faLS chunk is described in ftp://swrinde....
faLS ...             # Apply pseudocolor to previous subimage
                     # No DDAT or IDAT; pixels don't change
DEND                 # End of subimage

LOCA 900 400         # Overlay near lower right-hand corner
IHDR 101 101 2 3 ... # SODE can be omitted when the subimage
                     #    doesn't depend on another and
                     #    nothing depends on it.
gAMA 50000           # We need a new gAMA, though, because
PLTE ...             #    there's no "source ID" for object.
tRNS ...             # It's transparent (maybe a logo)
IDAT ...             # Note that the color type can differ
IDAT ...             #    from that of the other objects.
IEND                 # End of subimage

CEND                 # End of composite frame
FEND                 # End of PNF stream

6.3. Example 3: movie with sprites

Here's another movie, illustrating the use of PND streams as sprites
\211 P N F \r \n ^z \n  # PNF signature
FHDR 512 512 ... # Start of PNF stream
CHDR ...         # First frame
LOCA 0 0         # Location for object 1
SODE 0 1 1       # define object 1  and export to next frame
PHDR 512 512 ... # it's a full-display PNP image
gAMA 50000
PDAT ...
PEND
LOCA 300 200     # Location for object 2
SODE 0 1 2       # define object 2 and export to next frame
IHDR 32 32 ...   # It's a small PNG
gAMA 50000
IDAT ...
IEND
CEND             # end of frame

CHDR ...         # Next frame (repeat this CHDR-CEND
                 #   sequence with different locations to
                 #   move the objects around)
LOCA 0 0         # New location for object 1 is still 0,0
SODE 1 1 1 1     # Retrieve object 1 from previous frame,
                 #    export to next
DHDR             # A completely empty DHDR-DEND just
                 #    redisplays the object
DEND             #    at the new location
LOCA 310 205     # New location for object 2
SODE 1 1 2 2     # Retrieve object 2 from previous frame,
                 #    export it to the next
DHDR             # Another empty DHDR-DEND
DEND
LOCA 400 500     # Location for another copy of object 2
SODE 2 1 2 3     # Reuse object 2 from this frame,
                 #    export it as object 3
DHDR             # Another DHDR-DEND
tRNS ...         # Make it semitransparent
DEND
CEND             # End of frame

CHDR ...         # Another frame
etc.
CEND 
etc.             # More frames
FEND             # End of PNF stream

6.4. Example 4: "Fading in" a transparent image

The opaque parts of this image will "fade in" gradually. This technique won't work with color_type 4 or 6 images that have partially transparent pixels. You must use a series of PND streams with DDAT chunks, instead, that add the desired amount to each individual alpha sample but make no changes to the color component samples. You can, however, "fade out" such images with the fADE chunk.
\211 P N F \r \n ^z \n # PNF signature
FHDR 64 64 16  # width, height, nframes
     8192      #  maxchunklen
     30 6 140  # tick length, frame and total duration
     50000     # default gamma
     8         # max bit depth 8
     0         # use application supplied background
   192 192 192 # "browser gray" default background
     0         # not ok to discard
IHDR ...    # PNG header
PLTE ...
tRNS ...    # Entries are zero for the transparent color
            # and 16 for the nontransparent ones.  They
            # will be barely visible)
IDAT ...
IEND
dURa 
DHDR ...
fADE 2 16   # Add 16 to alpha for all nontransparent
DEND        # colors
DHDR ...    # Repeat
fADE 2 16
DEND
etc.        # Repeat DHDR-fADE-DEND 13 more times.  The
            # opaque colors will end up with alpha=255
            # and the transparent ones will still be 0.
dURa 60     # Hold the last frame for at least 60 ticks
            # (2 sec).  Applications might show it longer,
            # or they might ignore dURa; it's ancillary.
FEND        # end of PNF

7. Credits

Contributors' names are presented in alphabetical order:

Author's Address

Glenn Randers-Pehrson
U.S. Army Research Laboratory
ATTN: AMSRL-WT-TD
Aberdeen Proving Ground, MD 21005-5066

Phone: (410) 278-6554

EMail: glennrp@arl.mil or randeg@alumni.rpi.edu

End of PNF Specification
Expires 10 February 1997