2.7.3.3 XMHybridRLECompressionInfo<class XMRENoSplitCompressionInfo<2>>
This section specifies the compression algorithm that is used when the compression metadata specifies the compression to be of type XMHybridRLECompressionInfo<class XMRENoSplitCompressionInfo<2>>, as specified in section 2.5.2.40. The RLE portion of this compression follows the format described in section 2.7.3. The bit-packing subsegment portion of the compression is as follows.
Assume that each value to be compressed is named idVal. Each idVal value will be compressed into the compressed storage in the following manner: The maximum size of the value to be compressed MUST NOT exceed 32 bits. Assume that the resulting compressed storage area data value is named compressedStorage. The entire compressed storage area is a multiple of 64 bits, so each compressedStorage data value (the section of storage that is being written to) is 64 bits in size. For more details about the actual values that are compressed by using this type of compression, see section 2.3 and section 2.4.
To simply this explanation, the process is divided into two phases.
In Phase 1, the minimum value (Min) is subtracted from the value to be compressed. The value of Min can be found in the XML metadata file that is associated with the data file containing the compressed data (see section 2.5.2.40). The result of this subtraction (idVal - Min) is then left bit shifted by the current bit offset into the storage. Assume that this offset is named startBit, and the resulting value after the bit shifting and subtraction is named shiftedVal. The offset (startBit) is a multiple of 2.
The following pseudocode illustrates this phase:
-
SET shiftedVal = (idVal - Min) LEFT_BITSHIFT startBit
In Phase 2, the data value is placed into the compressed storage. A bitwise OR operation is performed on the value (shiftedVal) and the compressed storage (compressedStorage). This operation generates the final result, named storageWithValue.
SET storageWithValue = (compressedStorage) BITWISE_OR (shiftedVal)
Within the value, the order of the value’s bits is little-endian. Within the compressed storage, however, individual values are placed low to high, with the first value occupying the lowest bits, the second value occupying the next-lowest bits, and so on. All the file formats use little-endian values. It is only the way individual values are ordered within the file that is being emphasized here, because that specific ordering is required.
The same decompression method that is used in XMRENoSplit compression can be used here. For more information, see section 2.7.1.2.
The following diagram shows the compressed data values.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
values |
|||||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
values (8 bytes): The set of values, each occupying 2 bits, in sequence and ordered low to high. In the sequence, the first value occupies Bits 0 through 1, the second value occupies Bits 2 through 3, and so on.
-
The startBit offset followed the sequence of Bit 0, 2, 4, and so on, up to Bit 62 as the data was compressed into the 64-bit storage area. Any unused bits are thus only padding, and the value of the padding depends on the result of the various masking effects. For this compression algorithm, at most 32 values exist in the 64-bit compressed storage value, and the process will begin again at Offset 0 with the next compressedStorage value.