Version 8.0.4

Version 8.0.4

In addition to bug fixes, version 8.0.4 adds the following features to version 8.0.3:
  1. Low-latency compression is dramatically improved.
    • Background: For quite a long time, Kakadu has been able to perform low-latency compression with a constant-bit-rate communication channel, avoiding underflow and overflow while flushing the codestream in discrete "flush-sets" that are individually rate controlled and can be very small, with end-to-end latencies as low as a few tens of lines from an image or video frame. These capabilities are enabled by the `Scbr' parameter attribute; they can be used to simulate the behaviour of a hardware implementation with guaranteed end-to-end latency constraints; but they can also be used to actually perform low-latency compression in software, admittedly with some extra latency due to the uncertainties introduced by process and thread scheduling in the operating system. The most significant enhancements to low latency in this release are as follows:
    • New capability: The Cplex-EST complexity constraint generation procedure, that is so valuable in ensuring guaranteed high encoding throughput with the HTJ2K block coding algorithm, has been extended to properly handle the `Scbr' low-latency constant-bit-rate flushing model. When used with small flush-sets, for low latency, even the high memory form of Cplex-EST does not use much memory, and constrained-complexity HTJ2K encoding (with at most 2 HT-Sets generated per code-block) proceeds with essentially the same coding efficiency as full HTJ2K encoding (all possible coding passes), without any reliance on statistics collected from earlier frames of a video or by training a background model.
    • Other tools: The `kdu_stripe_decompressor' interface has been augmented with features to facilitate the construction of low-latency high throughput video decompression machinery that can produce rendered video lines as soon as possible after the arrival of compressed data that may have been flushed incrementally from the corresponding encoder.
    • In the demo-apps: All of Kakadu's primary compression demo-apps support low-latency compression with Scbr and Cplex options, and without the "-quiet" option they will print a latency report detailing all relevant contributions to latency.
  2. A JPEG 2000 Quality Factor is finally available from this version of Kakadu.
    • Background: One point of concern for some users of JPEG 2000 has been the lack of a well defined, intuitive quality factor that can be used to control the compressed image quality in a similar way to the quality factor used with the original JPEG compression standard. The first road block to this was cleared away by a recently published study:

A. Ahar, S., S. Mahmoudpour, O. Watanabe, D. Taubman and P. Schelkens, "Parameterization of the quality factor for the High Throughput JPEG 2000," in proc. SPIE Photonics Europe, vol. 11353, Optics, Photonics and Digital Technologies for Imaging Applications VI; SPIE Optics and Photonics: Digital Technologies for Imaging Applications VI, April 2020.

In that work, it was established that a resaonable equivalent to JPEG quality factor Q, for 4:2:0 YCbCr colour imagery (the most common format employed for colour JPEG image compression) could be derived setting `Qstep' equal to 0.04*(50/Q) for 0<Q<50 and 0.04*(1-Q/100) for 50<=Q<=100.

    • New capability: Kakadu essentially implements the policy described above with its new `Qfactor' attribute, but goes a few steps further, as follows:
      • The research work cited above is not applicable for very high Q factors beyond about 85. This is because the JPEG Q factor expression has a built in dependence on the minimum allowed quantization step size for any DCT coefficient, which is much more limited than in JPEG 2000. In particular, the expression above maps Q=100 to a practically infinitessimal set of quantization step sizes, while Q=100 in JPEG leads only to a high image quality with quantization distortion similar to the distortion produced by digitizing continuous image intensities to 8-bit precision. Kakadu adjusts the Q factor expression for JPEG 2000 so that a similar property holds as Q approaches 100, except that the distortion associated with Q=100 depends on the bit-depth of the source imagery (or 8 if the source samples have lower bit-depth), which properly handles 10-, 12-, 16- or even much higher image precisions.
      • To avoid dependence of the visual appearance associated with a given `Qfactor' on application-defined `Cband_weights' values (visual weighting factors), Kakadu can now synthesize these automatically from a list of component types, given by the new `Ctype' attribute -- in most cases, the attribute will have value "Ctype=Y,Cb,Cr" or "Ctype=N" (non-visual), but other possibilities exist. Kakadu can convert the component visual (or non-visual) types into visual weighting factors, even taking component sub-sampling properly into account, so that the same visual weights previously installed automatically by Kakadu's demo-apps are now configured within the core system in response to a `Ctypes' list.
      • Furthermore, Kakadu adjusts the visual weights synthesized from `Ctype' in the presence of the `Qfactor' attribute, so that at very high Q factors, the visual weights are attenuated towards the unweighted situation that is optimal from the perspective of directly minimizing MSE (equivalently, maximizing PSNR). This ensures that Q=100 has a well defined objective interpretation, yielding quantization distortion whose MSE is roughly 3dB below the noise level associated with digitizing continuous image intensity values to the precision associated with the source imagery.
      • The properties of the Kakadu `Qfactor' algorithm can be adjusted via the new `Qfparams' attribute, for which the defaults are intended to substantially reproduce the conditions determined in the above-mentioned research paper over the range of quality factors tested.
      • Importantly, the Kakadu `Qfactor', implemented in the manner roughly described above, retains a consistent meaning across a wide range of image bit-depths and chrominance sub-sampling schemes such as 4:4:4, 4:2:2 and 4:2:0.
    • In the demo-apps: All compression demo-apps support the simultaneous specification of a `Qfactor' and a `-rate' or `slope' constraint. The visual weighting policy of Kakadu's compression demo-apps  has not changed, but it is now realized internally simply by setting the `Ctype' attribute (component visual type), unless you do specify it explicitly. The option "-no_weights", that has always instructed Kakadu demo-apps to avoid visual weighting, is internally (or equivalently) achieved by setting "Ctype=N".
Go Top