1. At the low level, this release applies a flexible yet rigorous memory management structure to Kakadu, both at the core system level and in most of the higher level components, allowing you to regulate and monitor memory consumption and prevent catastrophic failures from undisciplined or falacious memory allocation requests. This is especially important for the robustness of large systems in which Kakadu may form one component that should not disturb the others. With just a few lines of code, one can now bring disciplined control to the allocation and accounting of memory allocations throughout a Kakadu-based system, but with extra effort one can provide more refined control. Several of the demo-apps now come with a "-mem_limit" argument that can be used to demonstrate these capabilities.
2. At the opposite end of the scale, the kdu_macshow application (kdu_show for MAC) has been substantially revamped to add more usability features, demonstrate more of what the underlying API's can do, and to form the cornerstone of what will be a platform neutral rendering and navigation engine that can be deployed in mobile and desktop environments with relatively little customization, assuming only that basic OpenGL support is available. This should bear fruit in the next release, but for now you will find that the kdu_macshow application is a good example of what Kakadu can do in the rendering/browsing/animation space. This includes:a. Super responsive full retina rendering. b. A rich set of decompression/rendering-backed animation capabilities, including video, metadata-driven animations, and user-driven dynamics that work with image surfaces of any size.
c. Interactive image/video/animation browsing via JPIP.
d. Integrated rendering and browsing of imagery and metadata.
e. Natural gesture recognition and window/view resizing controls.
f. Page transitions (and flicking) as an extra idiom for navigation within rich multi-frame composited content, such as albums, along with automatic multi-frame page rendering when content is heavily zoomed out relative to the window 0dimensions.
g. Efficient all-OpenGL drawing, for both incremental and animated rendering, including the drawing of scroll-bars, JPIP progress bars, page boundaries, etc.
3. Beyond these two very large changes, there are a multitude of improvements.a. The use of stack-based variables has been reigned in to the extent that typical uses cases should not consume more than 16kB of stack-space per thread -- usually much less. b. The underlying sample allocator that is used to manage the efficient allocation of working memory for compression data processing now provides for fragmented memory blocks, avoiding some of the difficulties occasionally encountered when processing truly huge images.
c. The JP2/JPX file-format parser is more tolerant of wrongly constructed file headers and metadata that unfortunately still show up in the wild.
d. The kdu_compress and kdu_expand demo apps work with more image file types, including high precision PGM/PPM files and floating point PFM files.
e. The kdu_v_compress and kdu_v_expand demo apps work with pretty much all YUV files, in addition to the VIX files that have always been well supported. YUV file support now includes high precisions, reading and writing, Y, RGB, and YUV formats with common sub-samplings, and a fairly tolerant parser (or writer) for common file name conventions that encode dimensions, precision, colour space and frame rate information. Moreover, sequences of YUV files with numeric suffices can be automatically read as a single source.
f. There are now fewer occasions when kdu_compress will warn about potentially insufficient quantization precision if Qstep is not explicitly specified, since the default policy now automatically configures Qstep to take into account the channel bit-depth of the source material.
4. A host of bug fixes for minor issues that have been uncovered by us and advanced users, as documented in the usual updates list that ships with licensed copies of the toolkit.