home *** CD-ROM | disk | FTP | other *** search
/ Compressed Image File Formats / CompressedImageFileFormatsJohnMiano.iso / pc / Specs / jng-0.91-19990202-pdg.txt < prev    next >
Encoding:
Text File  |  1999-02-09  |  22.1 KB  |  501 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.             JNG (JPEG Network Graphics) Format Version 0.91
  7.  
  8.    Status of this Memo
  9.  
  10.       This document is an informal draft of the PNG development group.
  11.  
  12.       It is a proposal, and the format is subject to change.
  13.  
  14.       Comments on this document can be sent to the PNG specification
  15.       maintainers at one of the following addresses:
  16.  
  17.           * mpng-list@ccrc.wustl.edu
  18.  
  19.           * png-group@w3.org
  20.  
  21.           * png-info@uunet.uu.net
  22.  
  23.       Distribution of this memo is unlimited.
  24.  
  25.       At present, the latest version of this document is available on
  26.       the World Wide Web from
  27.  
  28.          ftp://swrinde.nde.swri.edu/pub/mng/documents/.
  29.  
  30.       In the case of any discrepancy between this extract and the full
  31.       MNG specification, the full MNG specification shall take
  32.       precedence.
  33.  
  34. Changes from fifty-fifth MNG draft (mng-0.9-19981231)
  35.  
  36.        * Revised the JDAT specification with regard to 12-bit and
  37.          progressive JPEG, and rearranged some paragraphs in a better
  38.          order.
  39.  
  40. Abstract
  41.  
  42.    This document presents the format of a JNG (JPEG Network Graphics)
  43.    datastream.  JNG is a lossy single-image member of the PNG (Portable
  44.    Network Graphics) format family.  It encapsulates a JPEG datastream
  45.    in PNG-style chunks, along with an optional alpha channel and
  46.    ancillary chunks that carry color-space information and comments.
  47.    While JNG is primarily intended as a subformat of the MNG (Multiple-
  48.    image Network Graphics) format, standalone JNG files are also
  49.    possible.
  50.  
  51. 1. The JPEG Network Graphics (JNG) Format
  52.  
  53.    JNG (JPEG Network Graphics) is the lossy sub-format for MNG objects.
  54.  
  55.    Note: This specification depends on the PNG Portable Network Graphics
  56.    specification [PNG].  The PNG specification is available at the PNG
  57.    home page,
  58.  
  59.       http://www.cdrom.com/pub/png/
  60.  
  61.    A JNG datastream consists of a header chunk (JHDR), JDAT chunks that
  62.    contain a complete JPEG datastream, and optionally, IDAT chunks that
  63.    contain a PNG-encoded grayscale image that is to be used as an alpha
  64.    mask.  Such a mask must have the same dimensions as the image itself.
  65.    The JDAT and IDAT chunks can be interleaved.  Some of the PNG
  66.    ancillary chunks are also recognized in JNG datastreams.
  67.  
  68.    While JNG is primarily intended for use as a sub-format within MNG, a
  69.    single-image JNG datastream can be written in a standalone file.  If
  70.    so, the first eight bytes of a JNG datastream are
  71.  
  72.       139 80 78 74 13 10 26 10
  73.  
  74.    (decimal) which is similar to the PNG signature with "\213 J N G"
  75.    instead of "\211 P N G" in bytes 0-3.
  76.  
  77.    JNG is pronounced "Jing."
  78.  
  79.    1.1. JNG critical chunks
  80.  
  81.       This section specifies the critical chunks that are defined in the
  82.       JNG format.
  83.  
  84.       1.1.1. JHDR JNG header
  85.  
  86.          The format of the JHDR chunk introduces a JNG datastream.  It
  87.          contains:
  88.  
  89.             Width:      4 bytes (unsigned integer, range 0..65535).
  90.             Height:     4 bytes (unsigned integer, range 0..65535).
  91.             Color type: 1 byte
  92.                           8: Gray (Y).
  93.                          10: Color (YCbCr).
  94.                          12: Gray-alpha (Y-alpha).
  95.                          14: Color-alpha (YCbCr-alpha).
  96.  
  97.             JDAT sample
  98.               depth:    1 byte
  99.                           8: 8-bit samples and quantization tables.
  100.                          12: 12-bit samples and quantization
  101.                              tables.
  102.                          20: 8-bit image followed by a 12-bit
  103.                              image.
  104.  
  105.             JDAT compression
  106.               method:   1 byte
  107.                           8: ISO-10918-1 Huffman-coded baseline JPEG.
  108.  
  109.             JDAT interlace
  110.               method:   1 byte.
  111.                           0: Sequential JPEG, single scan.
  112.                           8: Progressive JPEG.
  113.  
  114.             IDAT sample
  115.               depth:    1 byte.
  116.                           0, 1, 2, 4, 8, or 16.
  117.  
  118.             IDAT compression
  119.               method:   1 byte.
  120.                           0: Zlib DEFLATE.
  121.  
  122.             IDAT filter
  123.               method:   1 byte.
  124.                           0: Adaptive (see PNG spec).
  125.  
  126.             IDAT interlace
  127.               method:   1 byte.
  128.                           0: Not interlaced.
  129.  
  130.          The width, height, JDAT_sample_depth, JDAT_compression_method,
  131.          and JDAT_interlace_method fields are redundant because
  132.          equivalent information is also embedded in the JDAT datastream.
  133.          They appear in the JHDR chunk for convenience.  Their values
  134.          must be identical to their equivalents embedded in the JDAT
  135.          chunk.  We use four bytes in the width and height fields for
  136.          similarity to MNG and PNG, and to leave room for future
  137.          expansion, even though two bytes would have been sufficient.
  138.  
  139.          When the color_type is 8 or 10 (no alpha channel), the last
  140.          four bytes, which describe the IDAT data, must be set to zero.
  141.          The IDAT_sample_depth must be nonzero when the alpha channel is
  142.          present.
  143.  
  144.       1.1.2. JDAT JNG image data
  145.  
  146.          A JNG datastream must contain one or more JDAT chunks, whose
  147.          data, when concatenated, forms a complete JNG JPEG datastream.
  148.          JNG decoders are required to read all baseline JNG JPEG and
  149.          eight-bit progressive JNG JPEG datastreams.  Twelve-bit
  150.          capability is not required.
  151.  
  152.          JDAT chunks are like PNG IDAT chunks in that there may be
  153.          multiple JDAT chunks, the data from which are concatenated to
  154.          form a single datastream that can be sent to the decompressor.
  155.          No chunks are permitted among the sequence of JDAT chunks,
  156.          except for interleaved IDAT chunks.  The ordering requirements
  157.          of other ancillary chunks are the same with respect to JDAT as
  158.          they are in PNG with respect to the IDAT chunk.
  159.  
  160.          A JNG JPEG is a baseline, extended-sequential, or progressive
  161.          JPEG as defined by JPEG Part 1 [ISO/IEC-10918-1].  JNG uses
  162.          only JFIF-compatible [JFIF] component interpretations, and
  163.          imposes a few additional restrictions that reflect limitations
  164.          of many existing JPEG implementations.  In particular, only
  165.          Huffman entropy coding is permitted.
  166.  
  167.          Actually, a JNG may contain two separate JNG JPEG datastreams
  168.          (one eight-bit and one twelve-bit), each contained in a series
  169.          of JDAT chunks, and separated by a JSEP chunk (see the JSEP
  170.          chunk specification below, Paragraph 5.1.4).  Decoders that are
  171.          unable to handle twelve-bit datastreams are allowed to display
  172.          the eight-bit datastream instead, if one is present.
  173.  
  174.          The core of the JNG JPEG definition is baseline JNG JPEG, which
  175.          is JPEG Part 1's definition of baseline JPEG further restricted
  176.          by JFIF restrictions and JNG-specific restrictions.  JPEG,
  177.          which is also defined in JPEG Part 1 and has JNG-specific
  178.          restrictions.
  179.  
  180.              * Baseline JNG JPEG restrictions
  181.  
  182.                A baseline JPEG according to JPEG Part 1 is DCT-based
  183.                (lossy) sequential JPEG, using 8-bit sample precision and
  184.                Huffman entropy coding, with the following further
  185.                restrictions:
  186.  
  187.                    * Quantization table precision must be 8 bits for
  188.                      baseline JPEG.
  189.  
  190.                    * Huffman code tables can have table numbers 0 and 1
  191.                      only.
  192.  
  193.                The SOF marker type for baseline JPEG is SOF0.
  194.  
  195.                JDAT datastreams must always follow "interchange JPEG"
  196.                rules: all necessary quantization and Huffman tables must
  197.                be included in the datastream; no tables can be omitted.
  198.  
  199.              * JFIF-compatible restrictions
  200.  
  201.                The image data is always stored left-to-right, top-to-
  202.                bottom.
  203.  
  204.                The encoded data shall have one of the two color space
  205.                interpretations allowed by the JFIF specification:
  206.  
  207.                    * Grayscale: a single component representing
  208.                      luminance, ranging from 0 for black to 255 for
  209.                      white (or 0 to 4095 when dealing with twelve-bit
  210.                      data).  This component shall have JPEG component
  211.                      identifier 1.
  212.  
  213.                    * YCbCr: three components representing luminance,
  214.                      chroma blue, and chroma red, in that order.  The
  215.                      components shall be assigned JPEG component
  216.                      identifiers 1, 2, 3 respectively.  YCbCr is defined
  217.                      as a linear transformation from RGB color space:
  218.  
  219.                         Y = Luma_red*R + Luma_green*G + Luma_blue*B
  220.                         Cb = (B - Y) / (2 - 2*Luma_blue) + Half_scale
  221.                         Cr = (R - Y) / (2 - 2*Luma_red)  + Half_scale
  222.  
  223.                      By convention, the luminance coefficients are
  224.                      always those defined by CCIR Recommendation 601-1:
  225.  
  226.                         Luma_red   = 0.299
  227.                         Luma_green = 0.587
  228.                         Luma_blue  = 0.114
  229.  
  230.                      The constant Half_scale is 128 when dealing with
  231.                      eight-bit data, 2048 for twelve-bit data.  With
  232.                      these equations, Y, Cb, and Cr all have the same
  233.                      range as R, G, and B: 0 to 255 for eight-bit data,
  234.                      0 to 4095 for twelve-bit data.
  235.  
  236.                      The JFIF convention for YCbCr differs from typical
  237.                      digital television practice in that no
  238.                      headroom/footroom is reserved: the coefficient
  239.                      values range over the full available 8 or 12 bits.
  240.  
  241.                      Intercomponent sample alignment shall be such that
  242.                      the first (upper leftmost) samples of each
  243.                      component share a common upper left corner
  244.                      position.  This again differs from common digital
  245.                      TV practice, in which the first samples share a
  246.                      common center position.  The JFIF convention is
  247.                      simpler to visualize: subsampled chroma samples
  248.                      always cover an integral number of luminance sample
  249.                      positions, whereas with co-centered alignment,
  250.                      chroma samples only partially overlap some
  251.                      luminance samples.
  252.  
  253.              * Additional JNG restrictions
  254.  
  255.                JNG imposes three additional restrictions not found in
  256.                the text of either JPEG Part 1 or the JFIF specification:
  257.  
  258.                    * The sampling factors for YCbCr images must be one
  259.                      of these sets:
  260.  
  261.                          * 1h1v,1h1v,1h1v (also called 4:4:4 or 1x1
  262.                            sampling)
  263.  
  264.                          * 2h1v,1h1v,1h1v (also called 4:2:2 or 2x1
  265.                            sampling)
  266.  
  267.                          * 2h2v,1h1v,1h1v (also called 4:2:0 or 2x2
  268.                            sampling)
  269.  
  270.                          * 1h2v,1h1v,1h1v (also called 1x2 sampling)
  271.  
  272.                      In other words, the chroma components may be
  273.                      downsampled 2:1 or 1:2 horizontally or vertically
  274.                      relative to luminance, or they may be left full
  275.                      size.  These four sampling ratios are the only ones
  276.                      supported by a wide spectrum of implementations
  277.                      (1x2 is relatively uncommon, and is usually the
  278.                      result of a lossless rotation of a 2x1 sampling).
  279.  
  280.                      For grayscale images, the sampling factors are
  281.                      irrelevant according to a strict reading of JPEG
  282.                      Part 1.  Hence decoder authors should accept any
  283.                      sampling factors for grayscale.  However, we
  284.                      recommend that encoders always emit sampling
  285.                      factors 1h1v for grayscale, since some decoders
  286.                      have been observed to malfunction when presented
  287.                      with other sampling factors.
  288.  
  289.                    * There must be only one scan in an image: that is,
  290.                      YCbCr images must be fully interleaved.  There is
  291.                      little advantage to be gained by encoding a
  292.                      baseline image in multiple scans, and many baseline
  293.                      decoders do not support multiple scans at all.
  294.  
  295.                    * The DNL (Define Number of Lines) marker is
  296.                      prohibited.  The image height must always be
  297.                      specified accurately in the SOFn marker and in the
  298.                      JHDR chunk.
  299.  
  300.              * Recommended progressive JPEG subset
  301.  
  302.                For JNG progressive JPEG datastreams, the JPEG process is
  303.                progressive Huffman coding (SOF marker type SOF2) rather
  304.                than baseline (SOF0).  All JNG-compliant decoders must
  305.                support full progression, including both spectral-
  306.                selection and successive-approximation modes, with any
  307.                sequence of scan progression parameters allowed by the
  308.                JPEG Part 1 standard.
  309.  
  310.                Otherwise, all the restrictions listed above apply,
  311.                except these:
  312.  
  313.                    * Multiple-scan support is obviously required for
  314.                      progressive JPEG.
  315.  
  316.                    * Huffman table numbers up to 3 (the full JPEG limit)
  317.                      may be used, since the baseline two-table limit is
  318.                      unlikely to be needed by any decoder that can
  319.                      handle progressive JPEG.
  320.  
  321.                We require full progression support since relatively
  322.                little code savings can be achieved by subsetting the
  323.                JPEG progression features.  In particular, successive
  324.                approximation offers significant gains in the visual
  325.                quality of early scans.  Omitting successive-
  326.                approximation support from a decoder does not save nearly
  327.                enough code to justify restricting JNG progressive
  328.                encoders to spectral selection only.
  329.  
  330.                No particular progressive scan sequence is specified or
  331.                recommended by this specification.  Not enough experience
  332.                has been gained with progressive JPEG to warrant making
  333.                such a recommendation.  To allow for future
  334.                experimentation with scan sequences, decoders are
  335.                expected to handle any JPEG-legal sequence.  Again, the
  336.                code savings that might be had by making restrictive
  337.                assumptions are too small to justify a limitation.
  338.  
  339.                When the JSEP chunk is present, both images must be
  340.                progressive if one of them is progressive.
  341.  
  342.              * Recommended 12-bit JPEG subset
  343.  
  344.                JNG JPEGs may optionally use 12-bit sample precision as
  345.                defined in JPEG Part 1.
  346.  
  347.                For a sequential image, the SOF marker type must be SOF1
  348.                (extended sequential) not SOF0, and the baseline
  349.                restriction of two Huffman tables is removed.  Also, the
  350.                encoder may use either 8-bit or 16-bit quantization
  351.                tables.  All other JNG baseline restrictions still apply.
  352.                It is recommended that JNG encoders not use extended-
  353.                sequential mode except to encode 12-bit data.
  354.  
  355.                For a progressive image, the only difference between 8-
  356.                bit and 12-bit modes is that the sample precision is 12
  357.                bits and the encoder may use either 8-bit or 16-bit
  358.                quantization tables.  All other JNG restrictions still
  359.                apply.
  360.  
  361.       1.1.3. IDAT JNG alpha data
  362.  
  363.          This chunk is exactly like the IDAT chunk in a PNG grayscale
  364.          image, except that it is interpreted as an alpha mask to be
  365.          applied to the image data from the JDAT chunks.  The alpha
  366.          channel, if present, can have sample depths 1, 2, 4, 8, or 16.
  367.          The IDAT chunks can be interleaved with the JDAT chunks (see
  368.          Recommendations for Encoders:  JNG interleaving below).  No
  369.          other chunk type can appear among the sequence of IDAT and JDAT
  370.          chunks.  No other chunk type can appear between the sequences
  371.          of IDAT and JDAT chunks when they are not interleaved.  The
  372.          samples in the IDAT must be presented in noninterlaced order,
  373.          left to right, top to bottom.  As in PNG, zero means fully
  374.          transparent and 2^IDAT_sample_depth-1 means fully opaque.
  375.  
  376.          The IDAT chunks must precede the JSEP chunk, if the JSEP chunk
  377.          is present.  Minimal viewers that ignore the twelve-bit JDAT
  378.          chunks must read the IDAT chunks and apply the alpha samples to
  379.          the eight-bit image that is contained in the JDAT chunks that
  380.          precede the JSEP chunk.  Viewers that skip the eight-bit JDAT
  381.          chunks must read the IDAT chunks that precede the JSEP chunk
  382.          and apply the alpha samples to the twelve-bit image that is
  383.          contained in the JDAT chunks that follow the JSEP chunk.
  384.  
  385.          The JNG IEND chunk is identical to its counterpart in PNG.  Its
  386.          data length is zero, and it serves to mark the end of the JNG
  387.          datastream.
  388.  
  389.       1.1.4. JSEP 8-bit/12-bit image separator
  390.  
  391.          The JSEP chunk is empty.
  392.  
  393.          A JSEP chunk must appear between the JDAT chunks of an eight-
  394.          bit datastream and those of a twelve-bit datastream, when
  395.          JDAT_sample_depth=20 in the JHDR chunk.  The eight-bit
  396.          datastream must appear first.  Both images must have the same
  397.          width, height, color type, compression method, and interlace
  398.          type.  Viewers can choose to display one or the other image,
  399.          but not both.
  400.  
  401.    1.2. JNG ancillary chunks
  402.  
  403.       Some PNG ancillary chunks can also appear in JNG datastreams, and
  404.       are used for the same purposes as described in the PNG
  405.       specification:
  406.  
  407.       If the bKGD chunk is present, it must be written as if it were
  408.       written for a PNG datastream with sample_depth=8.  It has one 2-
  409.       byte entry for grayscale JNGs and three 2-byte entries for color
  410.       JNGs.  The first (most significant) byte of each entry must be 0.
  411.  
  412.       The following chunks have exactly the same meaning and have the
  413.       same format as given in the PNG specification: cHRM, gAMA, iCCP,
  414.       sRGB, pHYs, oFFs, [iTXt,] tEXt, tIME, and zTXt.
  415.  
  416.       The PNG PLTE, hIST, pCAL, sBIT, and tRNS chunks are not defined in
  417.       JNG.
  418.  
  419.       When cHRM, gAMA, iCCP, or sRGB are present, they provide
  420.       information about the color space of the decoded JDAT image, and
  421.       they have no effect on the decoded alpha samples from the IDAT
  422.       chunks.  Any viewer that processes the gAMA chunk must also
  423.       recognize and process the sRGB chunk.  It can treat it as if it
  424.       were a gAMA chunk containing the value .45455 and it can ignore
  425.       its "intent" field.
  426.  
  427.       The chunk copying and ordering rules for JNG are the same as those
  428.       in PNG, except for the fact that JDAT and IDAT chunks can be
  429.       interleaved.
  430.  
  431. 2. Recommendations for Encoders
  432.  
  433.    The following recommendations do not form a part of the
  434.    specification.
  435.  
  436.    2.1. Interleaving JDAT and IDAT chunks
  437.  
  438.       When a JNG datastream contains an alpha channel, and the file is
  439.       intended for transmission over a network, it is useful to
  440.       interleave the IDAT and JDAT chunks.  In the case of sequential
  441.       JPEG, the interleaving should be arranged so that the alpha data
  442.       arrives more or less in sync with the color data for the
  443.       scanlines.  In the case of progressive JPEG, the alpha data should
  444.       be interleaved with the first JPEG pass, so that all of the alpha
  445.       data has arrived before beginning the second JPEG pass.
  446.  
  447. 3. Credits
  448.  
  449.    Editor
  450.  
  451.           * Glenn Randers-Pehrson randeg @ alumni.rpi.edu
  452.  
  453.    Contributors
  454.  
  455.       Contributors' names are presented in alphabetical order:
  456.  
  457.           * Gerard Juyn, gjuyn @ xs4all.nl
  458.           * Tom Lane, tgl @ sss.pgh.pa.us
  459.           * Glenn Randers-Pehrson, randeg @ alumni.rpi.edu
  460.           * Nancy M. Randers-Pehrson, randeg @ alumni.rpi.edu
  461.           * Greg Roelofs, newt @ pobox.com
  462.  
  463.    Document source
  464.  
  465.       This document was built from the file mng-master-19990202 on
  466.       02 February 1999.
  467.  
  468.    Copyright Notice
  469.  
  470.       Copyright (c) 1998, 1999 by:  Glenn Randers-Pehrson
  471.  
  472.       This specification is being provided by the copyright holder under
  473.       the following license.  By obtaining, using and/or copying this
  474.       specification, you agree that you have read, understood, and will
  475.       comply with the following terms and conditions:
  476.  
  477.       Permission to use, copy, and distribute this specification for any
  478.       purpose and without fee or royalty is hereby granted, provided
  479.       that the full text of this NOTICE appears on ALL copies of the
  480.       specification or portions thereof, including modifications, that
  481.       you make.
  482.  
  483.       THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDER MAKES
  484.       NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED.  BY WAY OF
  485.       EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO
  486.       REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
  487.       ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL
  488.       NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR
  489.       OTHER RIGHTS.  COPYRIGHT HOLDER WILL BEAR NO LIABILITY FOR ANY USE
  490.       OF THIS SPECIFICATION.
  491.  
  492.       The name and trademarks of copyright holder may NOT be used in
  493.       advertising or publicity pertaining to the specification without
  494.       specific, written prior permission.  Title to copyright in this
  495.       specification and any associated documentation will at all times
  496.       remain with copyright holder.
  497.  
  498. End of JNG Specification.
  499.  
  500.  
  501.