C# Class BitMiracle.LibJpeg.Classic.Internal.huff_entropy_encoder

Initialize for a Huffman-compressed scan. If gather_statistics is true, we do not output anything during the scan, just count the Huffman symbols used and generate Huffman code tables.

Generate the best Huffman code table for the given counts, fill htbl. The JPEG standard requires that no symbol be assigned a codeword of all one bits (so that padding bits added at the end of a compressed segment can't look like a valid code). Because of the canonical ordering of codewords, this just means that there must be an unused slot in the longest codeword length category. Section K.2 of the JPEG spec suggests reserving such a slot by pretending that symbol 256 is a valid symbol with count 1. In theory that's not optimal; giving it count zero but including it in the symbol set anyway should give a better Huffman code. But the theoretically better code actually seems to come out worse in practice, because it produces more all-ones bytes (which incur stuffed zero bytes in the final file). In any case the difference is tiny. The JPEG standard requires Huffman codes to be no more than 16 bits long. If some symbols have a very small but nonzero probability, the Huffman tree must be adjusted to meet the code length restriction. We currently use the adjustment method suggested in JPEG section K.2. This method is *not* optimal; it may not choose the best possible limited-length code. But typically only very-low-frequency symbols will be given less-than-optimal lengths, so the code is almost optimal. Experimental comparisons against an optimal limited-length-code algorithm indicate that the difference is microscopic --- usually less than a hundredth of a percent of total size. So the extra complexity of an optimal algorithm doesn't seem worthwhile.

IRIGHT_SHIFT is like RIGHT_SHIFT, but works on int rather than int. We assume that int right shift is unsigned if int right shift is, which should be safe.

Outputting bits to the file Only the right 24 bits of put_buffer are used; the valid bits are left-justified in this part. At most 16 bits can be passed to emit_bits in one call, and we never retain more than 7 bits in put_buffer between calls, so 24 bits are sufficient.

Only the right 24 bits of put_buffer are used; the valid bits are left-justified in this part. At most 16 bits can be passed to emit_bits in one call, and we never retain more than 7 bits in put_buffer between calls, so 24 bits are sufficient.

Emit a restart marker and resynchronize predictions.

MCU encoding for AC initial scan (either spectral selection, or first pass of successive approximation).

MCU encoding for AC successive approximation refinement scan.

MCU encoding for DC initial scan (either spectral selection, or first pass of successive approximation).

MCU encoding for DC successive approximation refinement scan. Note: we assume such scans can be multi-component, although the spec is not very clear on the point.

Trial-encode one MCU's worth of Huffman-compressed coefficients. No data is actually output, so no suspension return is possible.

Encode and output one MCU's worth of Huffman-compressed coefficients.

Encode a single block's worth of coefficients

Finish up a statistics-gathering pass and create the new Huffman tables.

Finish up at the end of a Huffman-compressed scan.

Huffman coding optimization. We first scan the supplied data and count the number of uses of each symbol that is to be Huffman-coded. (This process MUST agree with the code above.) Then we build a Huffman coding tree for the observed counts. Symbols which are not needed at all for the particular image are not assigned any code, which saves space in the DHT marker as well as in the compressed data.

Expand a Huffman table definition into the derived format Compute the derived values for a Huffman table. This routine also performs some validation checks on the table.