Version 7.2

Version 7.2

This release represents the best part of 1 year's continuous work to improve the performance and features of Kakadu on numerous fronts, while working with customers to ensure remove residual flaws in some of the most demanding applications.  A lot of work has been invested in integrating some of the most exciting new features in IS15444-2/AMD3 (this is a very large amendment to Part-2 of the JPEG2000 suite of standards, that focusses on augmenting the capabilities of the JPX file format). With this release, JPIP video is also finally a reality. The specific features of this release may be organized under the following categories:
 
    1) Multi-threaded core sub-system improvements
       -- Introduced a new job queue design at the heart of the core
          multi-threaded sub-system that involves an absolute minimum of
          bus locking operations to enqueue and dequeue processing jobs.
          Bus locking operations are a fundamental measurement of the cost
          of synchronizing access to shared resources by multiple physical
          processors.  The average combined number of bus locking
          instructions (a.k.a. atomic instructions) required to both enqueue
          and dequeue a processing job in Kakadu's distributed multi-threading
          sub-system is less than 2 -- for reference, acquisition and release
          of a critical section lock (just once) requires at least 2 bus
          locking operations, but typically many more when the number of
          CPU's becomes large.
    2) New features for JPX files
       -- Added comprehensive support for what we call "JPX containers"
          (a.ka. Compositing Layer Extensions boxes), as well as
          aggregated codestreams (a.k.a. Multiple Codestream boxes).
          These are new features introduced by IS15444-2/AMD3 to support
          efficient representation and remote access to files with a very
          large number of compositing layers and/or codestreams.  The new
          `jpx_source' and `jpx_target' implementations also correctly
          generate and interpret metadata embedded within JPX
          containers, which is by no means simple but can be used in
          very powerful ways.
       -- As a result, Kakadu and its demo applications now support
          multiple JPX presentation threads (or tracks), each with their
          own animation stream.  You can effectively build metadata that
          references whole presentation tracks or portions of them in an
          efficient way.
       -- These new features also mean that Kakadu can very efficiently
          encapsulate video (including live video -- i.e. where the sequence
          length is unknown a priori or unbounded) within a JPX file and
          access it in a random or streaming fashion via JPIP.  Prior to
          these innovations, all codestreams and their header boxes needed to
          live at the top level of a JPX file so that a massive number of
          placeholder boxes (each ~28 bytes) might need to be sent to a
          remote client as minimal representation for the codestreams
          preceding one that might be of interest.
       -- These innovations make JPX files an excellent choice for embedding
          video, especially where auxiliary navigation or annotation metadata
          is to be embedded as well, or for advanced applications such
          as hyperspectral video using multi-component transforms for
          both efficient compression and to enable a diversity of
          presentation modes (via presentation threads).
       -- Greatly enhanced the JPX metadata and animation management and
          discovery features offered by Kakadu.  This has been done largely
          in response to the new features implied by JPX containers.  You
          can now: count tracks; count frames in a track; count temporal
          duration of tracks or parts of tracks; and search for composited
          frames that match number list descriptions, searching fowards or
          backwards.  These features are very efficient and are designed to
          work with content that may contain millions of frames and numerous
          presentation tracks.  They are also designed to work with content
          that is remotely located, so that it may be only partially
          available in a local cache.
       -- Extended Kakadu's JPX file writing capabilities, so that the
          writing of metadata and imagery can be interleaved at will.
          Metadata and imagery can be added on the fly and written
          incrementally to the file.  Moreover, all of this is done in such
          a way as to avoid polluting the top-level of the file with a large
          number of boxes that would interfere with efficient random access
          and interactive JPIP browsing.
    3) JPIP support for video and animation as well as the new JPX features
       -- Extended the `kdu_serve' interface and `kdu_servex' implementations
          to correctly serve JPX files that use JPX containers (Compositing
          Layer Extensions boxes) and Multiple Codestream boxes.
       -- Augmented `kdu_region_animator' with the ability to calculate and
          issue its own window-of-interest requests to a `kdu_client'
          interface and to analyze the current status of those requests,
          providing a simple yet comprehensive interface to applications
          that are interested in JPIP video/animation services.  The
          `kdu_region_animator' object provides all the state information and
          machinery to manage the timing and request/response management
          for JPIOP video and other more ellaborate animations, including
          complex composted animations (defined by a remote JPX file) and/or
          metadata-driven animations (defined by metadata selected by the
          application or user).
       -- To support JPIP video/animation, the `kdu_client' interface has
          been augmented slightly to keep track of the status of posted
          windows of interest and to allow so-called "timed requests" to
          be posted.  The `kdu_client' interface simplifies the process of
          determining when and how timed requests should be issued during
          an interactive video/animation, so as to maximize the responsiveness
          of the experience.  The interface is defined in such a way as to
          tolerate drift between the clock domains used by the application
          and the internal `kdu_client' machinery.
    4) Improvements in rate control and codestream generation efficiency
       -- Extended the core `kdu_compressed_target' class to support the
          writing of structured codestream elements to a cache, as opposed
          to sequentially writing a codestream in the conventional manner.
          This is part of a long standing plan to realize fully integrated
          live encoding, rendering and JPIP services, all brokered by a
          real-time compressed data cache.  The newly defined "structured
          cache" targets may choose to write the elements that arrive
          (main header, tile headers and precincts) to a database, or to an
          in-memory cache.  They may choose to later serialize the
          elements into a conventional linear JPEG2000 codestream, or they
          may choose to offer the cached elements to a decompression/rendering
          engine, using Kakadu's well established cached compressed data
          source interface.
       -- At present, the most important benefit that can be derived from
          structured cache compressed data targets is that incremental
          codestream flushing is much more flexible and efficientt for such
          targets than it is for linear codestream targets.  For a
          structured cache target, incremental flushing does not require
          the lower resolution components of the image to have very small
          precincts.  As a result, huge untiled images can be compressed
          and incrementally flushed to a structured cache target, regardless
          of how many resolution levels are defined, so long as you define
          moodest precinct sizes (e.g., `Cprecincts={128,128}').
       -- Considerable effort has been invested in reducing the number of
          simulation passes required by Kakadu's rate-control machinery,
          since these simulation passes are inherently single-threaded so
          that they can become a bottleneck on machines with many CPU cores.
          The enhancements include better prediction of the distortion-length
          slope thresholds that are likely to be most suitable, a new
          algorithm to synthesize specifications for quality layers that
          do not have hard bit-rate/comressed size constraints, and a number
          of other measures.  As a result of these measures, the total number
          of simulation passes required by a typical compression
          application has been reduced by perhaps 5 or even 10 fold.
       -- To support the enforcing of new High Frame Rate (HFR) Digital
          Cinema profile specifications, the `Creslengths' attribute has
          been augmented with a `Cagglengths' attribute that can be used
          to define collections of image components whose aggregate
          compressed sizes should conform to constraints offered by
          `Creslengths'.  The mechanism is very flexible.
    5) Enhancements to the demo apps
       -- Upgraded the "kdu_merge" demo app to support generation of JPX
          files with containers (Compositing Layer Extensions boxes).  This
          has been done largely for testing purposes, but it allows some
          very interesting configurations to be synthesized using
          command-line options.
       -- Upgraded "kdu_show" (Windows and MAC versions) to support
          editing, interpretation and navigation for metadata embedded
          within JPX containers.  The "kdu_show" applications now also
          support the playback of multiple presentation tracks where
          defined by JPX containers and the synthesizing of metadata-driven
          animations that take advantage of all the features of JPX
          containers.  For example, holding the shift key down while
          double-clicking on a metadata entry that is embedded within
          a JPX container will synthesize a metadata-driven animation that
          plays out all the associated content from the container, taking
          repetitions of the container into account.  These capabilities are
          all realized using the underlying powerful API's, for which the
          "kdu_show" application is a demonstration platform.
       -- Upgraded the "kdu_v_compress" demo application to support writing
          of video directly to a JPX file, along with metadata, taking
          advantage of JPX containers.  This demo app now supports four
          compressed video formats: MJ2, JPX, JPB (broadcast streams) and
          MJC (raw) video streams.  It is the best platform on which to
          build live video compression applications.  If you want to use
          Part-2 codestream features for your video or embed rich
          auxiliary metadata, or facilitate interactive access via JPIP,
          JPX is by far the best choice, except that there is not currently
          any support for audio in the JPX file format.
       -- Upgraded the "kdu_v_expand" and "kdu_vex_fast" demo apps to support
          JPX input files, processing the first codestream in each animation
          frame -- of course JPX animations can be much more complex than
          regular video, potentially involving many different codestreams,
          composited in interesting ways, but these upgrades at least allow
          "kdu_v_expand" and "kdu_vex_fast" to decompress video content
          written to a JPX file by "kdu_v_compress".
       -- Upgraded "kdu_server" to support JPX files with JPX containers.
          Also substantially reduced the number of file handles and
          synchronization objects required by "kdu_server" when serving
          sources that contain a large number of embedded codestreams (such
          as video, animations, or highly complex compositions).
       -- All compression demo apps ("kdu_compress", "kdu_v_compress" and
          "kdu_buffered_compress") now accept a "-tolerance" parameter that
          may be used to regulate the accuracy of the rate control process,
          trading accuracy against the number of simulation passes required
          to achieve a target bit-rate.  Moreover, the default tolerance is
          automatically set to +/-1% relative to 99% of the target bit-rate
          and this is done uniformly.
       -- "kdu_compress" now offers the possibility of using a
          structured cache compressed data target. As noted above, these
          are much better when incremental flushing of massive untiled
          compressed images is required.  Currently, the structured cache
          target is a "null" target that discards all of its data and is
          instantiated whenever there is no supplied output file.  However,
          this is only for testing purposes.  Application developers can
          readily extend the `kdu_compressed_target' interface to provide
          much more interesting structured cache targets.  In future releases
          of Kakadu, some such derived target objects will be supplied
          ready-built.
       -- "kdu_compress" and "kdu_expand" now work to preserve ICC profiles
          between TIFF and JP2/JPX files.  The Kakadu API's have supported
          this for many years, but the feature was now demonstrated in these
          demo apps, but many people have asked for this.
    6) Bug fixes
       -- This release incorporates quite a few bug fixes, most of which
          are quite subtle or difficult to excite.  Details of bug fixes
          are available in the usual "Updates.txt" file that ships with
          licensed distributions.
       -- One important feature of Kakadu is that it is very widely licensed;
          most of the bugs that have been found recently have been discovered
          by licensees, using Kakadu in particularly challenging ways.
       -- A number of the corrected bugs address race conditions in the
          `kdu_cache' object that had lain undiscovered for many years.
       -- Other significant bugs were discovered and fixed in the encode-time
          ROI compression logic, one of the high precision data conversion
          paths in `kdu_stripe_compressor', the hyperdoc-generated Java
          bindings for at least one API function, and the underlying
          communication machinery used by Kakadu's client/server components.
Go Top