CALL for DISCUSSION: cOMp/cOMP/coMp/coMP: compression wrapper chunks

John Bowler <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAP7U39_boUyobq4wj4kcwc41=e33dpWOdEcE9SCg+rhnzaDsZQ@mail.gmail.com>
This call for discussion follows the format approved by Glenn.  A lot
of the following document is boilerplate; therefore I have extracted
the definition part here.  This is the addition to the "extensions"
document, verbatim, excluding references.

  3.7. Compressed chunks

   Four chunk types  are defined with chunk types (see ISO-PNG[2],
   "5.4 Chunk naming conventions"):

   coMp  [99  111   77  112] private, safe to copy compressed chunk
   coMP [99  111   77   80] private, unsafe to copy compressed chunk
   cOMp [99   79   77  112] public, safe to copy compressed chunk
   cOMP [99   79   77   80] public, unsafe to copy compressed chunk

   The data of each chunk contains another chunk of the corresponding
   chunk type as described in ISO-PNG "5.3 Chunk layout" except that
   the original "Chunk Data" is compressed as described below and the
   CRC is omitted.

   Thus the chunks have the following layout, following the description
   given in section 5.3 and using cOMp as an example:

      length [4 bytes, length of the cOMp data]
      cOMp [4 bytes, 99, 79, 77, 112]
         original chunk length
         original chunk type
         compressed original chunk data
     crc

   The compressed original data shall have the format:

       | compression method byte | compressed data |

   Where the compression method byte is as defined in ISO-PNG
   "11.2.2 IHDR Image header" and therefore has the value 0 and the
   compressed data is Zlib compressed data as defined in RFC-1950[4]

   The "property bits" (as defined in ISO-PNG 5.4) of the chunk type shall
   match the property bits of the original chunk type, thus only ancillary
   chunks may be compressed.  A decoder shall discard a compressed
   chunk where the property bits do not match.

   Except for sPLT ancillary chunks defined in ISO-PNG shall not be
   compressed.  Specifically the following ancillary chunks shall not be
   compressed:

      cHRM gAMA iCCP sBIT sRGB bKGD hIST
      tRNS pHYs tIME iTXt tEXt zTXt

   If a decoder encounters a compressed version of one of the above
   chunks it is permitted either to ignore the error or to discard the chunk.

   3.7.1 Decoder recommendations [informative]

   A PNG decoder may use a streaming decompressor which simply
   expands compressed chunks to the original format without attention
   to any part of ISO-PNG except the basic chunk layout described in
   section 4.7 "PNG datastream".  (I.e. without regard to the ordering
   requirements in section 5.)  Such a decompressor must skip
   compressed chunks which do not meet the property bit requirement.

   3.7.2 Encoder recommendations [informative]

   A system may use a streaming compressor to produce compressed
   chunks however the compressor must obey the restrictions on which
   ancillary chunks can be compressed.

  A compressor is permitted to compress chunks even if that increases
  the size of the stream.  To avoid this it is recommended that compressors
  either try a trial compress of small chunks or avoid compressing chunks
  below a certain size.  The compressed chunk format, using deflate, can
  never reduce a size of a chunk with chunk length below 19.

================== END ADDITION ==========================

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

                    PNG Proposed cOMp/cOMP/coMp/coMP chunks, draft 20170129

File: png-proposed-comp-chunks-20170129.txt

Status of this Memo

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

   Comments on this document can be sent to the PNG specification
   maintainers at [email protected] [1].

   Distribution of this memo is unlimited.

   Initial proposals were in the png-mng-misc mailing list, starting
   December 31, 2016.

   At present, the latest version of this document is available on the
   World Wide Web in the archives of the png-mng-mailing list [1].

Notices

   Copyright © 2017 John Bowler

   Permission is granted to copy and distribute this document for any
   purpose and without charge, provided that the copyright notice and this
   notice are preserved, and that any substantive changes or deletions
   from the original are clearly marked.

Abstract

   This document describes a group of chunk types that have been
   proposed for use in various PNG (Portable Network Graphics) [2]. It has
   not yet been approved for registration
   by the PNG developers, and therefore is experimental and its format is
   subject to change. The proposed chunks types are coMp, coMP, cOMp
   and cOMP.

PNG compressed chunk proposal

   It is proposed to add the following section to the document "Extensions
   to the PNG 1.2 Specification, Version 1.4.0"[3]

=================== BEGIN ADDITION =======================
  3.7. Compressed chunks

   Four chunk types  are defined with chunk types (see ISO-PNG[2],
   "5.4 Chunk naming conventions"):

   coMp  [99  111   77  112] private, safe to copy compressed chunk
   coMP [99  111   77   80] private, unsafe to copy compressed chunk
   cOMp [99   79   77  112] public, safe to copy compressed chunk
   cOMP [99   79   77   80] public, unsafe to copy compressed chunk

   The data of each chunk contains another chunk of the corresponding
   chunk type as described in ISO-PNG "5.3 Chunk layout" except that
   the original "Chunk Data" is compressed as described below and the
   CRC is omitted.

   Thus the chunks have the following layout, following the description
   given in section 5.3 and using cOMp as an example:

      length [4 bytes, length of the cOMp data]
      cOMp [4 bytes, 99, 79, 77, 112]
         original chunk length
         original chunk type
         compressed original chunk data
     crc

   The compressed original data shall have the format:

       | compression method byte | compressed data |

   Where the compression method byte is as defined in ISO-PNG
   "11.2.2 IHDR Image header" and therefore has the value 0 and the
   compressed data is Zlib compressed data as defined in RFC-1950[4]

   The "property bits" (as defined in ISO-PNG 5.4) of the chunk type shall
   match the property bits of the original chunk type, thus only ancillary
   chunks may be compressed.  A decoder shall discard a compressed
   chunk where the property bits do not match.

   Except for sPLT ancillary chunks defined in ISO-PNG shall not be
   compressed.  Specifically the following ancillary chunks shall not be
   compressed:

      cHRM gAMA iCCP sBIT sRGB bKGD hIST
      tRNS pHYs tIME iTXt tEXt zTXt

   If a decoder encounters a compressed version of one of the above
   chunks it is permitted either to ignore the error or to discard the chunk.

   3.7.1 Decoder recommendations [informative]

   A PNG decoder may use a streaming decompressor which simply
   expands compressed chunks to the original format without attention
   to any part of ISO-PNG except the basic chunk layout described in
   section 4.7 "PNG datastream".  (I.e. without regard to the ordering
   requirements in section 5.)  Such a decompressor must skip
   compressed chunks which do not meet the property bit requirement.

   3.7.2 Encoder recommendations [informative]

   A system may use a streaming compressor to produce compressed
   chunks however the compressor must obey the restrictions on which
   ancillary chunks can be compressed.

  A compressor is permitted to compress chunks even if that increases
  the size of the stream.  To avoid this it is recommended that compressors
  either try a trial compress of small chunks or avoid compressing chunks
  below a certain size.  The compressed chunk format, using deflate, can
  never reduce a size of a chunk with chunk length below 19.

================== END ADDITION ==========================

Contributors

  Contributors to discussion on the png-mng-misc list

     * John Bowler
     * Glenn Randers-Pherson
     * [others: TBD]

  Editor

     * John Bowler, [email protected]

   End of PNG Proposed cOMp/cOMP/coMp/coMP chunks.
   Expires 28 February 2017.

References

   1. mailto:[email protected]
   2. https://www.iso.org/obp/ui/#iso:std:iso:12234:-3:ed-1:v1:en [normative]
       or: http://www.libpng.org/pub/png/spec/iso/ [freely available copy, not
       normative].
   3. http://www.libpng.org/pub/png/spec/register/
   4. https://www.ietf.org/rfc/rfc1950.txt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.