changes_from_vm5_2.txt

JPEG2000实现的源码

                         CHANGES IN VM6.0 FROM VM5.2
	                =============================

_____________________________________________________________________________
                          Framework and Philosophy
_____________________________________________________________________________

* There have been some changes to the framework of the VM to support
  the rich flexibility offered by the JPEG2000 standard; most significantly,
  to support the ability to change almost all possible coding parameters
  on a tile and even a component basis.

* The VM6.0 decompressor is implemented so as to decompress all possible
  compliant codestreams, rather than just those created by the VM6.0
  compressor; in other words, it is a full reference implementation
  rather than just a test-bed -- this is actually a key to
  discovering problems with the text of the standard (something
  one would expect of a "verification" model) as testified by the
  list of problems discovered in this way in the accompanying file,
  "PROBLEMS_IN_CD.TXT".

* The VM6.0 compressor is implemented so as to be able to generate
  almost all, if not all possible legal variations of coding parameters
  so as to thoroughly exercise compliant decompressors.  The emphasis
  here is on coding parameters.  It deliberately stays away from
  producing all possible codestream organizations or from producing
  any pointer markers.  Instead it is capable of producing sufficiently
  annotated codestreams to allow a separate utility "j2g_fiddle" to
  fiddle with the codestream organization, introduce pointer markers,
  farm packet heads off to PPT/PPM markers, etc.  To do this, you should
  supply `-Bresync' (and for packet head manipulation also `-Beph')
  command-line switches to the VM6 compressor.  For an explanation of
  the EPH markers generated by `-Beph' see the "PROBLEMS_IN_CD.TXT" file.

* The interface functions which manage exchange of marker information
  between the "stream_in" and "stream_out" objects and the compression
  and decompression objects have been radically changed.  The compression
  and decompression objects now push and pull so-called "pre-marker
  elements" according to a set of well-defined conventions.  New pre-
  marker elements may be defined and used at will without informing the
  "stream_out" or "stream_in" objects.  Whenever the stream objects do
  not know how to assemble the elements into existing codestream
  marker definitions, it uses a generic marker packing mechanism which
  allows for arbitrary call sequences (unlike the original
  `push_global_header_val' and `pull_global_header_val' calls) and is
  much more efficient than using CME markers directly; moreover, the
  mechanism fully supports the global header -> tile-header -> component
  overriding paradigms established in PART-1 and farms most of the work
  of constructing efficient marker combinations subject to these rules
  off to the stream objects, which can handle most cases in a generic
  manner.  Users of these functions should annotate the file, "SYNTAX.TXT"
  to maintain a textual record of the underlying interpretation of the
  marker elements which they declare and use to facilitate implementation
  of appropriate translators in the stream objects.  The stream objects
  report the number of non-compliant markers which are generated in a
  codestream; there should be none when using only PART-1 features.

* The VM6 decompressor makes every effort to minimize the amount of
  the codestream which must be buffered, either in the "stream_in"
  object or by the "decoder" object.  In this way, the effect of
  different packet partitions, packet progression sequences, tile
  sequences and tile-partitioning should be reflected in the
  report generated using the `-mem' argument.

* There had been a few violations of the principle established in VM3A
  that no object should examine the internal state of another object
  directly (i.e. without going through a function).  These created
  a lot of headaches in introducing the new flexible features, which
  is why we had the rule in the first place.  These violations have
  been resolved in the correct manner.

_____________________________________________________________________________
                                  Features
_____________________________________________________________________________

* The VM6.0 decompressor should decode any compliant PART-1 JPEG2000
  codestream at all, barring bugs and subject to the specific choices
  made in dealing with problems in the JPEG2000 CD, as described in the
  accompanying file, "PROBLEMS_IN_CD.TXT".

* The VM6.0 compressor should be able to generate almost any legal
  combination of PART-1 coding parameters across tiles and image
  components for testing purposes.  It applies optimal rate control,
  with or without visual effects (frequency weighting and -Cvis masking
  compensation) in conjunction with all possible coding parameters;
  Various codestream rearrangements can be introduced using the separate 
  program, "j2g_fiddle", whose implementation is expected to be enhanced over
  time to cover testing of error resilience, insertion of packed packet 
  header markers (the decompressor accepts PPT/PPM, but the compressor will 
  not generate them itself; they need to be added separately), pointer 
  markers and so forth.  Using these tools you can produce some really wild 
  bit-streams and certainly some really useless bit-streams.

* The above comments extend beyond PART-1 features to most features
  currently envisaged for PART-2, with the caveat that these features
  necessarily involve the generation of non-standard marker codes until
  codestream syntax has been defined for them.

* The choice concerning whether Wavelet transform are implemented using
  lifting or convolution is now independent of quantities signalled in
  the codestream.  Both the compressor and decompressor accept a
  `-Fconv' argument to force convolution implementation rather than
  the default lifting implementation (used to be the other way around).

_____________________________________________________________________________
                          New Elements From Maui
_____________________________________________________________________________

The following new elements, accepted in Maui, have been implemented.

* Elimination of byte stuffing for error resilience and substitution with
  simpler, more efficient bit-stuffing only in packet heads and raw
  bit-stream segments generated in lazy mode.

* Full implementation of the canvas coordinate system across all elements
  of the system, including all PART-2 aspects of the canvas coordinate
  system (i.e. including frames (cells in the WD) and frame/block anchor
  points).

* Packet partitions with arbitrary power-of-2 packet partition dimensions
  in every resolution level of every tile-component.

* All packet progression sequences described in the CD, including
  layer, resolution, component and spatially oriented progressions and
  progression changes at arbitrary points.

* Restrictions on entropy coder block dimensions have been changed to allow 
  both height and width to vary from 4 to 1024, but the product of height 
  and width still must be less than or equal 4096.

* Subband processing as well as trained codewords have been removed for TCQ. 
  This leaves the block processing mode for TCQ and the scan order through 
  each block follows that for the entropy coder.  The last three entropy 
  coder bit-plane passes are included together in the same packet for each 
  block to improve progressive performance.  Finally, TCQ step sizes are 
  stored in the bit-stream as double that actually used by TCQ (to allow 
  almost immediate approximate SQ decoding) and the initial states for each 
  trellis are fixed to zero.

* Point-wise extended visual masking has been added.  The implementation for 
  visual masking has also been moved to the transform object.  Thus, usage 
  for this option is now controlled with the `-Xmask' encoder command line 
  argument.

* A palette-based program has been added in the VM sub-directory 
  palette_option.  See the README in that directory for more details 
  concerning this new option.

_____________________________________________________________________________
                           Resurrected Elements
_____________________________________________________________________________

The following elements have been resurrected from VM3A in anticipation of the
needs of PART-2, having been broken by syntax implementations.

* Arbitrary user-defined kernels are supported in each direction, at
  each resolution level, in each component and each tile.  User-defined
  kernels are loaded and signalled exclusively through lifting steps, but
  may optionally be implemented using convolution (the option may be
  independently requested at the compressor or decompressor).

_____________________________________________________________________________
                     Changes in Command-Line Signalling
_____________________________________________________________________________

The command-line signalling methods have changed substantially to support
the numerous other changes in the software mentioned above.  As always,
the usage statements contain a rich description of just about everything
you should need to know, but we point out a few things here to get you
started:

-- Most command-line arguments take an optional form in which the
   argument string has a suffix of the form +<tnum>, i.e. a zero
   based tile index, preceded by a `+' sign, which restricts the
   argument's scope to the relevant tile.  Thus, "-Flev 3" specifies
   3 decomposition levels for all tiles, while "-Flev+1 3" specifies
   the use of 3 levels only for the second tile (remember that tile
   indices are zero-based).  Default or global specifications are
   overridden only in the specified tiles.  This is mainly for use
   in creating and testing weird codestreams.  You can tell which
   arguments take this tile-specific form by looking at the usage
   statements: something like "-Flev[+<tnum>]" means that the argument
   string takes the optional suffix.

-- Objects in the system no longer process "argc" and "argv"
   directly.  Instead, the routine tasks which were performed in
   each object before (plus many new tasks) are absorbed into
   the new command-line processing object, "cmdl".  As with other
   objects, the internal state of this object must never be
   directly examined or manipulated from outside the "cmdl"
   object's own implementation.
   
-- Minor modifications to the syntax of -Fweights and -Fsteps files.  See
   the modified discussion at the beginning of the std_forward_info.c file
   for details.

-- Some of the most commonly used arguments have moved around a little.
   Here are a few important examples:
   * "-lev"
     -> use "-Flev"
   * "-prof sp"
     -> "-Clayers" by itself gives you generic scalable mode  (~50 layers) now
   * "-rate" during decompression
     -> use one of "-parse" or "-trunc" depending upon what you want to do
        (avoids accidental misuse).