ComponentOne PdfViewer for WPF and Silverlight
C1.WPF.PdfViewer.4.6.2 Assembly / CSJ2K.j2k.entropy.encoder Namespace
Inheritance Hierarchy
In This Topic
    CSJ2K.j2k.entropy.encoder Namespace
    In This Topic
    Classes
     ClassDescription
    ClassThis class provides a buffering output stream similar to ByteArrayOutputStream, with some additional methods.

    Once an array has been written to an output stream or to a byte array, the object can be reused as a new stream if the reset() method is called.

    Unlike the ByteArrayOutputStream class, this class is not thread safe.

    ClassThis class stores coded (compressed) code-blocks with their associated rate-distortion statistics. This object should always contain all the compressed data of the code-block. It is applicable to the encoder engine only. Some data of the coded-block is stored in the super class, see CodedCBlk.

    The rate-distortion statistics (i.e. R-D slope) is stored for valid points only. The set of valid points is determined by the entropy coder engine itself. Normally they are selected so as to lye in a convex hull, which can be achived by using the 'selectConvexHull' method of this class, but some other strategies might be employed.

    The rate (in bytes) for each truncation point (valid or not) is stored in the 'truncRates' array. The rate of a truncation point is the total number of bytes in 'data' (see super class) that have to be decoded to reach the truncation point.

    The slope (reduction of distortion divided by the increase in rate) at each of the valid truncation points is stored in 'truncSlopes'.

    The index of each valid truncation point is stored in 'truncIdxs'. The index should be interpreted in the following way: a valid truncation point at position 'n' has the index 'truncIdxs[n]', the rate 'truncRates[truncIdxs[n]]' and the slope 'truncSlopes[n]'. The arrays 'truncIdxs' and 'truncRates' have at least 'nVldTrunc' elements. The 'truncRates' array has at least 'nTotTrunc' elements.

    In addition the 'isTermPass' array contains a flag for each truncation point (valid and non-valid ones) that tells if the pass is terminated or not. If this variable is null then it means that no pass is terminated, except the last one which always is.

    The compressed data is stored in the 'data' member variable of the super class.

    ClassThis implements the EBCOT post compression rate allocation algorithm. This algorithm finds the most suitable truncation points for the set of code-blocks, for each layer target bitrate. It works by first collecting the rate distortion info from all code-blocks, in all tiles and all components, and then running the rate-allocation on the whole image at once, for each layer.

    This implementation also provides some timing features. They can be enabled by setting the 'DO_TIMING' constant of this class to true and recompiling. The timing uses the 'System.currentTimeMillis()' Java API call, which returns wall clock time, not the actual CPU time used. The timing results will be printed on the message output. Since the times reported are wall clock times and not CPU usage times they can not be added to find the total used time (i.e. some time might be counted in several places). When timing is disabled ('DO_TIMING' is false) there is no penalty if the compiler performs some basic optimizations. Even if not the penalty should be negligeable.

    ClassThis abstract class provides the general interface for block-based entropy encoders. The input to the entropy coder is the quantized wavelet coefficients, or codewords, represented in sign magnitude. The output is a compressed code-block with rate-distortion information.

    The source of data for objects of this class are 'CBlkQuantDataSrcEnc' objects.

    For more details on the sign magnitude representation used see the Quantizer class.

    This class provides default implemenations for most of the methods (wherever it makes sense), under the assumption that the image and component dimensions, and the tiles, are not modifed by the entropy coder. If that is not the case for a particular implementation then the methods should be overriden.

    ClassThis class stores the specification of a layer distribution in the bit stream. The specification is made of optimization points and a number of extra layers to add between the optimization points. Each optimization point creates a layer which is optimized by the rate allocator to the specified target bitrate. The extra layers are added by the rate allocator between the optimized layers, with the difference that they are not optimized (i.e. they have no precise target bitrate).

    The overall target bitrate for the bit stream is always added as the last optimization point without any extra layers after it. If there are some optimization points whose target bitrate is larger than the overall target bitrate, the overall target bitrate will still appear as the last optimization point, even though it does not follow the increasing target bitrate order of the other optimization points. The rate allocator is responsible for eliminating layers that have target bitrates larger than the overall target bitrate.

    Optimization points can be added with the addOptPoint() method. It takes the target bitrate for the optimized layer and the number of extra layers to add after it.

    Information about the total number of layers, total number of optimization points, target bitrates, etc. can be obtained with the other methods.

    Class 
    ClassThis is the abstract class from which post-compression rate allocators which generate layers should inherit. The source of data is a 'CodedCBlkDataSrcEnc' which delivers entropy coded blocks with rate-distortion statistics.

    The post compression rate allocator implementation should create the layers, according to a rate allocation policy, and send the packets to a CodestreamWriter. Since the rate allocator sends the packets to the bit stream then it should output the packets to the bit stream in the order imposed by the bit stream profiles.

    ClassThis class implements the JPEG 2000 entropy coder, which codes stripes in code-blocks. This entropy coding engine can function in a single-threaded mode where one code-block is encoded at a time, or in a multi-threaded mode where multiple code-blocks are entropy coded in parallel. The interface presented by this class is the same in both modes.

    The number of threads used by this entropy coder is specified by the "jj2000.j2k.entropy.encoder.StdEntropyCoder.nthreads" Java system property. If set to "0" the single threaded implementation is used. If set to 'n' ('n' larger than 0) then 'n' extra threads are started by this class which are used to encode the code-blocks in parallel (i.e. ideally 'n' code-blocks will be encoded in parallel at a time). On multiprocessor machines under a "native threads" Java Virtual Machine implementation each one of these threads can run on a separate processor speeding up the encoding time. By default the single-threaded implementation is used. The multi-threaded implementation currently assumes that the vast majority of consecutive calls to 'getNextCodeBlock()' will be done on the same component. If this is not the case, the speed-up that can be expected on multiprocessor machines might be significantly decreased.

    The code-blocks are rectangular, with dimensions which must be powers of 2. Each dimension has to be no smaller than 4 and no larger than 256. The product of the two dimensions (i.e. area of the code-block) may not exceed 4096.

    Context 0 of the MQ-coder is used as the uniform one (uniform, non-adaptive probability distribution). Context 1 is used for RLC coding. Contexts 2-10 are used for zero-coding (ZC), contexts 11-15 are used for sign-coding (SC) and contexts 16-18 are used for magnitude-refinement (MR).

    This implementation buffers the symbols and calls the MQ coder only once per stripe and per coding pass, to reduce the method call overhead.

    This implementation also provides some timing features. They can be enabled by setting the 'DO_TIMING' constant of this class to true and recompiling. The timing uses the 'System.currentTimeMillis()' Java API call, which returns wall clock time, not the actual CPU time used. The timing results will be printed on the message output. Since the times reported are wall clock times and not CPU usage times they can not be added to find the total used time (i.e. some time might be counted in several places). When timing is disabled ('DO_TIMING' is false) there is no penalty if the compiler performs some basic optimizations. Even if not the penalty should be negligeable.

    The source module must implement the CBlkQuantDataSrcEnc interface and code-block's data is received in a CBlkWTData instance. This modules sends code-block's information in a CBlkRateDistStats instance.

    Interfaces
     InterfaceDescription
    InterfaceThis interface defines a source of entropy coded data and methods to transfer it in a code-block by code-block basis. In each call to 'getNextCodeBlock()' a new coded code-block is returned. The code-block are retruned in no specific-order.

    This interface is the source of data for the rate allocator. See the 'PostCompRateAllocator' class.

    For each coded-code-block the entropy-coded data is returned along with the rate-distortion statistics in a 'CBlkRateDistStats' object.

    See Also