| synopsis || arguments || prev || next |
void initialize( kdu_serve_target * target, int max_chunk_size, int chunk_prefix_bytes, bool ignore_relevance_info=false)
Java: void Initialize( Kdu_serve_target target, int max_chunk_size, int chunk_prefix_bytes, boolean ignore_relevance_info)
[Declared in "../apps/kdu_server/kdu_serve.h"]
The real construction takes place here — somewhat safer, since we prefer to avoid having exceptions thrown from within the constructor itself. The function configures the server to work with the existing kdu_serve_target object, which should have already been created and configured as necessary.
A single target may be shared between multiple 'kdu_serve' objects, although kdu_serve_target::lock_codestream and kdu_serve_target::release_codestream may need to implement appropriate synchronization mechanisms if the kdu_serve objects are to operate in different threads of execution. In general, it is important that all other users of the target object close their open tiles while calls to the present function ( initialize) and the generate_increments function are in progress.
Once the kdu_serve object has been initialized, the application should call the set_window function to identify the image code-streams, image components, resolution, spatial region, etc., which are of interest. The application then issues one or more calls to generate_increments, letting kdu_serve itself decide what compressed data and meta-data increments should be assembled (usually, on behalf of an interactive client). In interactive client-server applications, the serving application will also listen for changes in the client's window of interest, issuing new calls to set_window, as appropriate. This affects the present object's decisions as to what compressed data should actually be packaged up in response to subsequent calls to generate_increments.
This argument determines the maximum size of the data chunks into which the generate_increments function packs compressed data. This size includes any prefix which the application reserves in its calls to generate_increments.
Indicates the number of bytes which should be reserved at the beginning of each data chunk, for application use. This value will be written into the kds_chunk::prefix_bytes member of each chunk in the list returned by generate_increments.
If this argument is true, the object will serve all relevant precinct data layer by layer, with the lowest resolution subbands appearing before the higher resolution subbands, within each layer. This is the behaviour offered by previous implementations of the object. On the other hand, if this argument is false, the function will process the precincts in order of their relevance (percentage overlap with the region of interest). Moreover, if information is available concerning the rate-distortion slope thresholds associated with the code-stream quality layers, this information is used in conjunction with the relevance factors to re-sequence the original code-stream packets, in a manner which is expected to reduce the distortion within the window of interest as quickly as possible. This often means that lower resolution precincts and precincts with relatively little overlap with the window tend to get sequenced later (sometimes several layers later) than they otherwise would.