kdu_stripe_compressor

This object provides a high level interface to the Kakadu compression machinery, which is capable of satisfying the needs of most developers while providing essentially a one-function-call solution for simple applications. Most new developers will probably wish to base their compression applications upon this object.

It should be noted, however, that some performance benefits can be obtained by creating compression engines yourself and directly passing them kdu_line_buf lines, since this can often avoid unnecessary copying and level shifting of image samples. Nevertheless, there has been a lot of demand for a dead-simple, yet also powerful interface to Kakadu, and this object is intended to fill that requirement. In fact, the various objects found in the "support" directory ( kdu_stripe_compressor, kdu_stripe_decompressor and kdu_region_decompressor) are aimed at meeting the needs of 90% of the applications using Kakadu. That is not to say that these objects are all that is required. You still need to open streams of one form or another and create a kdu_codestream interface.

In a typical compression application based on this object, you will need to do the following:

• Create a kdu_codestream object;
• Use the interface recovered using kdu_codestream::access_siz to install any custom compression parameters you have in mind, unless you are happy with all the defaults;
• Initialize the kdu_stripe_compressor object, by calling kdu_stripe_compressor::start.
• Push image stripes into kdu_stripe_compressor::push_stripe until the image is fully compressed (you can do it all in one go, from a memory buffer of your choice, if you like);
• Call kdu_stripe_compressor::finish.
• Call kdu_codestream::destroy.

For a tuturial example of how to use the present object in a typical application, consult the Kakadu demo application, "kdu_buffered_compress".

It is worth noting that this object is built directly on top of the services offered by kdu_multi_analysis, so for a thorough understanding of how things work, you might like to consult the documentation for that object as well.

Most notably, the image components which are supplied to the push_stripe function are those which are known (during decompression) as multi-component output components (or just output components). This means that the present object inverts any Part 2 multi-component transformation network, which may be involved.

From Kakadu version 5.1, this object offers multi-threaded processing capabilities for enhanced throughput. These capabilities are based upon the options for multi-threaded processing offered by the underlying kdu_multi_analysis object and the kdu_analysis and kdu_encoder objects which it, in turn, uses. Multi-threaded processing provides the greatest benefit on platforms with multiple physical CPU's, or where CPU's offer hyperthreading capabilities. Interestingly, although hyper-threading is often reported as offering relatively little gain, Kakadu's multi-threading model is typically able to squeeze 30-50% speedup out of processors which offer hyperthreading, in addition to the benefits which can be reaped from true multi-processor (or multi-core) architectures.

To take advantage of multi-threading, you need to create a kdu_thread_env object, add a suitable number of working threads to it (see comments appearing with the definition of kdu_thread_env) and pass it into the start function. You can re-use this kdu_thread_env object as often as you like — that is, you need not tear down and recreate the collaborating multi-threaded environment between calls to finish and start. Multi-threading could not be much simpler. The only thing you do need to remember is that all calls to start, process and finish should be executed from the same thread — the one identified by the kdu_thread_env reference passed to start. This constraint represents a slight loss of flexibility with respect to the core processing objects such as kdu_multi_analysis, which allow calls from any thread. In exchange, however, you get simplicity. In particular, you only need to pass the kdu_thread_env object into the start function, after which the object remembers the thread reference for you.

kdu_stripe_compressor {Java: Kdu_stripe_compressor} {C#: Ckdu_stripe_compressor} {VB: New}

~kdu_stripe_compressor {Java: Native_destroy} {C#: Dispose} {VB: Dispose}

start {Java: Start} {C#: start} {VB: start}

finish {Java: Finish} {C#: finish} {VB: finish}

get_recommended_stripe_heights {Java: Get_recommended_stripe_heights} {C#: get_recommended_stripe_heights} {VB: get_recommended_stripe_heights}

push_stripe (8 forms)