ftp://swrinde.nde.swri.edu/pub/mng/documents/.
This document is a specification by the PNG development group.
It has been approved by a vote of the group, and future technical changes will require formal approval by a vote of the group. It is the intent of the group to maintain backward compatibility if possible. We will, however, correct any technical deficiencies discovered in the course of developing "beta" implementations.
Comments on this document can be sent to the PNG specification maintainers at one of the following addresses:
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/mng/documents/.
In the case of any discrepancy between this extract and the full MNG specification, the full MNG specification shall take precedence.
This document presents the format of a JNG (JPEG Network Graphics) datastream. JNG is a lossy single-image member of the PNG (Portable Network Graphics) format family. It encapsulates a JPEG datastream in PNG-style chunks, along with an optional alpha channel and ancillary chunks that carry color-space information and comments. While JNG is primarily intended as a subformat of the MNG (Multiple-image Network Graphics) format, standalone JNG files are also possible.
JNG (JPEG Network Graphics) is the lossy sub-format for MNG objects.
MNG-LC and MNG-VLC applications can choose to support JNG or not. Those that do not can check bit 4 (JNG is present/absent) of the MHDR simplicity profile to decide whether they can process the datastream.
Note: This specification depends on the PNG Portable Network Graphics specification [PNG]. The PNG specification is available at the PNG home page,
http://www.cdrom.com/pub/png/
A JNG datastream consists of a header chunk (JHDR), JDAT chunks that contain a complete JPEG datastream, optional IDAT chunks that contain a PNG-encoded grayscale image that is to be used as an alpha mask, and an IEND chunk. The alpha mask, if present, must have the same dimensions as the image itself. The JDAT and IDAT chunks can be interleaved. Some of the PNG ancillary chunks are also recognized in JNG datastreams.
While JNG is primarily intended for use as a sub-format within MNG, a single-image JNG datastream can be written in a standalone file. If so, the first eight bytes of a JNG datastream are
139 80 78 74 13 10 26 10
(decimal) which is similar to the PNG signature with "\213 J N G" instead of "\211 P N G" in bytes 0-3.
JNG is pronounced "Jing."
This section specifies the critical chunks that are defined in the JNG format.
The format of the JHDR chunk introduces a JNG datastream. It contains:
Width: 4 bytes (unsigned integer, range 0..65535).
Height: 4 bytes (unsigned integer, range 0..65535).
Color type: 1 byte
8: Gray (Y).
10: Color (YCbCr).
12: Gray-alpha (Y-alpha).
14: Color-alpha (YCbCr-alpha).
Image sample
depth: 1 byte
8: 8-bit samples and quantization tables.
12: 12-bit samples and quantization
tables.
20: 8-bit image followed by a 12-bit
image.
Image compression
method: 1 byte
8: ISO-10918-1 Huffman-coded baseline JPEG.
Image interlace
method: 1 byte.
0: Sequential JPEG, single scan.
8: Progressive JPEG.
Alpha sample
depth: 1 byte.
0, 1, 2, 4, 8, or 16.
Alpha compression
method: 1 byte.
0: PNG grayscale IDAT format.
Alpha filter
method: 1 byte.
0: Adaptive (see PNG spec).
Alpha interlace
method: 1 byte.
0: Not interlaced.
The width, height, image_sample_depth, image_compression_method, and image_interlace_method fields are redundant because equivalent information is also embedded in the JDAT datastream. They appear in the JHDR chunk for convenience. Their values must be identical to their equivalents embedded in the JDAT chunk. We use four bytes in the width and height fields for similarity to MNG and PNG, and to leave room for future expansion, even though two bytes would have been sufficient.
When the color_type is 8 or 10 (no alpha channel), the
last four bytes, which describe the IDAT data, must be set to
zero. The alpha_sample_depth must be nonzero when the alpha
channel is present.
A JNG datastream must contain one or more JDAT chunks, whose data, when concatenated, forms a complete JNG JPEG datastream. JNG decoders are required to read all baseline JNG JPEG and eight-bit progressive JNG JPEG datastreams. Twelve-bit capability is not required.
JDAT chunks are like PNG IDAT chunks in that there may be multiple JDAT chunks, the data from which are concatenated to form a single datastream that can be sent to the decompressor. No chunks are permitted among the sequence of JDAT chunks, except for interleaved IDAT chunks. The ordering requirements of other ancillary chunks are the same with respect to JDAT as they are in PNG with respect to the IDAT chunk.
A JNG JPEG is a baseline, extended-sequential, or progressive JPEG as defined by JPEG Part 1 [ISO/IEC-10918-1]. JNG uses only JFIF-compatible [JFIF] component interpretations, and imposes a few additional restrictions that reflect limitations of many existing JPEG implementations. In particular, only Huffman entropy coding is permitted.
Actually, a JNG may contain two separate JNG JPEG datastreams (one eight-bit and one twelve-bit), each contained in a series of JDAT chunks, and separated by a JSEP chunk (see the JSEP chunk specification below, Paragraph 1.1.5). Decoders that are unable to handle twelve-bit datastreams are allowed to display the eight-bit datastream instead, if one is present.
The core of the JNG JPEG definition is baseline JNG JPEG, which is JPEG Part 1's definition of baseline JPEG further restricted by JFIF restrictions and JNG-specific restrictions. JPEG, which is also defined in JPEG Part 1 and has JNG-specific restrictions.
A baseline JPEG according to JPEG Part 1 is DCT-based (lossy) sequential JPEG, using 8-bit sample precision and Huffman entropy coding, with the following further restrictions:
The SOF marker type for baseline JPEG is SOF0.
JDAT datastreams must always follow "interchange JPEG" rules: all necessary quantization and Huffman tables must be included in the datastream; no tables can be omitted.
The image data is always stored left-to-right, top-to-bottom.
The encoded data shall have one of the two color space interpretations allowed by the JFIF specification:
Y = Luma_red*R + Luma_green*G + Luma_blue*B Cb = (B - Y) / (2 - 2*Luma_blue) + Half_scale Cr = (R - Y) / (2 - 2*Luma_red) + Half_scale
By convention, the luminance coefficients are always those defined by CCIR Recommendation 601-1:
Luma_red = 0.299 Luma_green = 0.587 Luma_blue = 0.114
The constant Half_scale is 128 when dealing with eight-bit data, 2048 for twelve-bit data. With these equations, Y, Cb, and Cr all have the same range as R, G, and B: 0 to 255 for eight-bit data, 0 to 4095 for twelve-bit data.
The JFIF convention for YCbCr differs from typical digital television practice in that no headroom/footroom is reserved: the coefficient values range over the full available 8 or 12 bits.
Intercomponent sample alignment shall be such that the first (upper leftmost) samples of each component share a common upper left corner position. This again differs from common digital TV practice, in which the first samples share a common center position. The JFIF convention is simpler to visualize: subsampled chroma samples always cover an integral number of luminance sample positions, whereas with co-centered alignment, chroma samples only partially overlap some luminance samples.
JNG imposes three additional restrictions not found in the text of either JPEG Part 1 or the JFIF specification:
In other words, the chroma components may be downsampled 2:1 or 1:2 horizontally or vertically relative to luminance, or they may be left full size. These four sampling ratios are the only ones supported by a wide spectrum of implementations (1x2 is relatively uncommon, and is usually the result of a lossless rotation of a 2x1 sampling).
For grayscale images, the sampling factors are irrelevant according to a strict reading of JPEG Part 1. Hence decoder authors should accept any sampling factors for grayscale. However, we recommend that encoders always emit sampling factors 1h1v for grayscale, since some decoders have been observed to malfunction when presented with other sampling factors.
For JNG progressive JPEG datastreams, the JPEG process is progressive Huffman coding (SOF marker type SOF2) rather than baseline (SOF0). All JNG-compliant decoders must support full progression, including both spectral-selection and successive-approximation modes, with any sequence of scan progression parameters allowed by the JPEG Part 1 standard.
Otherwise, all the restrictions listed above apply, except these:
We require full progression support since relatively little code savings can be achieved by subsetting the JPEG progression features. In particular, successive approximation offers significant gains in the visual quality of early scans. Omitting successive-approximation support from a decoder does not save nearly enough code to justify restricting JNG progressive encoders to spectral selection only.
No particular progressive scan sequence is specified or recommended by this specification. Not enough experience has been gained with progressive JPEG to warrant making such a recommendation. To allow for future experimentation with scan sequences, decoders are expected to handle any JPEG-legal sequence. Again, the code savings that might be had by making restrictive assumptions are too small to justify a limitation.
When the JSEP chunk is present, both images must be progressive if one of them is progressive.
JNG JPEGs may optionally use 12-bit sample precision as defined in JPEG Part 1.
For a sequential image, the SOF marker type must be SOF1 (extended sequential) not SOF0, and the baseline restriction of two Huffman tables is removed. Also, the encoder may use either 8-bit or 16-bit quantization tables. All other JNG baseline restrictions still apply. It is recommended that JNG encoders not use extended-sequential mode except to encode 12-bit data.
For a progressive image, the only difference between 8-bit and 12-bit modes is that the sample precision is 12 bits and the encoder may use either 8-bit or 16-bit quantization tables. All other JNG restrictions still apply.
This chunk is exactly like the IDAT chunk in a PNG grayscale
image, except that it is interpreted as an alpha mask to be applied to
the image data from the JDAT chunks,
when alpha_compression_method=0. The alpha channel, if
present, can have sample depths 1, 2, 4, 8, or 16. The IDAT
chunks can be interleaved with the JDAT chunks
(see Recommendations for Encoders:
JNG interleaving below).
No other chunk
type can appear among the sequence of IDAT and JDAT
chunks. No other chunk type can appear between the sequences of
IDAT and JDAT chunks when they are not interleaved.
The samples in the IDAT must be presented in noninterlaced order, left
to right, top to bottom. As in PNG, zero means fully transparent and
2^alpha_sample_depth-1 means fully opaque.
The IDAT chunks must precede the JSEP chunk, if the JSEP chunk is present. Minimal viewers that ignore the twelve-bit JDAT chunks must read the IDAT chunks and apply the alpha samples to the eight-bit image that is contained in the JDAT chunks that precede the JSEP chunk. Viewers that skip the eight-bit JDAT chunks must decode the IDAT chunks that precede the JSEP chunk and apply the alpha samples to the twelve-bit image that is contained in the JDAT chunks that follow the JSEP chunk.
The JNG IEND chunk is identical to its counterpart in PNG. Its data length is zero, and it serves to mark the end of the JNG datastream.
The JSEP chunk is empty.
A JSEP chunk must appear between the JDAT
chunks of an eight-bit datastream and those of a twelve-bit datastream, when
image_sample_depth=20 in the JHDR chunk. The eight-bit
datastream must appear first. Both images must have the same width,
height, color type, compression method, and interlace type. Viewers can
choose to display one or the other image, but not both.
Some PNG ancillary chunks can also appear in JNG datastreams, and are used for the same purposes as described in the PNG specification [PNG] and the Extensions to the PNG Specification document [PNG-EXT].
If the bKGD chunk is present, it must be written as if it were written for a PNG datastream with sample_depth=8. It has one 2-byte entry for grayscale JNGs and three 2-byte entries for color JNGs. The first (most significant) byte of each entry must be 0.
The following chunks have exactly the same meaning and have the same syntax as given in the PNG specification: cHRM, gAMA, iCCP, sRGB, pHYs, oFFs, sCAL, iTXt, tEXt, tIME, and zTXt.
The PNG PLTE, hIST, pCAL, sBIT, sPLT, tRNS, fRAc, and gIF* chunks are not defined in JNG.
When cHRM, gAMA, iCCP, or sRGB are present, they provide information about the color space of the decoded JDAT image, and they have no effect on the decoded alpha samples from the IDAT chunks. Any viewer that processes the gAMA chunk must also recognize and process the sRGB chunk. It can treat it as if it were a gAMA chunk containing the value .45455 and it can ignore its "intent" field.
The chunk copying and ordering rules for JNG are the same as those in PNG, except for the fact that JDAT and IDAT chunks can be interleaved.
The following recommendations do not form a part of the specification.
When a JNG datastream contains an alpha channel, and the file is intended for transmission over a network, it is useful to interleave the IDAT and JDAT chunks. In the case of sequential JPEG, the interleaving should be arranged so that the alpha data arrives more or less in sync with the color data for the scanlines. In the case of progressive JPEG, the alpha data should be interleaved with the first JPEG pass, so that all of the alpha data has arrived before beginning the second JPEG pass.
This (incomplete as of version 0.96) section does not form a part of the specification. It provides the rationale behind some of the design decisions in MNG.
It has been suggested that the JNG alpha data should optionally be transmitted as a grayscale JPEG. Why not?
We will be running some tests with a proposed JDAA chunk to evaluate this suggestion. But we are reluctant to add new critical chunks to the JNG specification now.
Released 28 February 2000. Minor editorial changes only.
Released 18 July 1999.
JDAT_sample_depth" to
"image_sample_depth" and
"IDAT_sample_depth" to
"alpha_sample_depth", etc.
Initial public release, approved by the PNG Development Group on 11 May 1999.
See also Pennebaker, William B., and Joan L. Mitchell, "JPEG : Still Image Data Compression Standard" Van Nostrand Reinhold, ISBN:0442012721, September 1992
See also the PNG-1.2 draft:
Randers-Pehrson, G., et. al., "PNG (Portable Network Graphics
Format) Version 1.2", which is available at
ftp://swrinde.nde.swri.edu/pub/png/documents/.
Security considerations are addressed in the PNG specification.
No known additional security concerns are raised by this format.
Contributors' names are presented in alphabetical order:
This document was built from the file mng-master-20000228 on 28 February 2000.
Copyright (C) 1998, 1999, 2000 by: Glenn Randers-Pehrson
This specification is being provided by the copyright holder under the following license. By obtaining, using and/or copying this specification, you agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and distribute this specification for any purpose and without fee or royalty is hereby granted, provided that the full text of this NOTICE appears on ALL copies of the specification or portions thereof, including modifications, that you make.
THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDER MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDER WILL BEAR NO LIABILITY FOR ANY USE OF THIS SPECIFICATION.
The name and trademarks of copyright holder may NOT be used in advertising or publicity pertaining to the specification without specific, written prior permission. Title to copyright in this specification and any associated documentation will at all times remain with copyright holder.