BACKGROUND

FIELD OF THE INVENTION

[001] This invention relates to systems and methods for lossless compression of data.

BACKGROUND OF THE INVENTION

[002] Huffman coding is an entropy encoding algorithm used for lossless data compression (see D. A. Huffman, "A method for the construction of minimum- redundancy codes" Proc. IRE 40 (9). pp. 1098-1101. 1952). Huffman coding refers to the use of a variable-length code table for encoding a source literal (such as a character in a file) where the variable-length code table has been derived in a particular way based on the estimated probability of occurrence for each possible value of the source literal. Huffman coding uses a specific method for choosing the representation for each literal, resulting in a prefix code (sometimes called "prefix-free codes", that is, the bit string representing some particular literal is never a prefix of the bit string representing any other literal) that expresses the most common source literals using shorter strings of bits than are used for less common source literals. Huffman was able to design the most efficient compression method of this type: no other mapping of individual source literals to unique strings of bits will produce a smaller average output size when the actual literal frequencies agree with those used to create the code. The pseudo code of the Huffman algorithm is described below.

Algorithm 1 : Compute Binary Huffman code

Input: Set of N pairs of (literal, count/probability). Output: Set of N pairs of (literal, hufcode).

1- Sort the literal ensemble by decreasing count.

2- Select the 2 least probable literals, and assign each a bit 0 and 1, respectively.

3- Substitute the selected literals by a composite literal summing their count, and re-order it.

4- While there remains more than one literal, do steps through 6.

5- Select two least probable literals, and append 0 and 1 respectively.

6- Substitute the selected literals by a composite literal summing their counts, and re-order it.

7- The hufcode of each literal is given by the concatenation of the aggregate bits.

[003] The above Huffman tree introduces two critical inefficiencies into an implementation of the coding scheme. Firstly, each node of the tree must store either references to its child nodes or the literal that it represents. This is expensive in memory usage and if there are a high proportion of unique literals in the source data then total the size of the code tree can account for a significant amount of the overall encoded data. Secondly, traversing the tree is computationally costly, since it requires the algorithm to jump randomly through the structure in memory as each bit in the encoded data is read in.

[004] Canonical Huffman codes address these two issues by generating the codes in a clear standardized format; all the codes for a given length are assigned their values sequentially. This means that instead of storing the structure of the code tree for decompression only the lengths of the codes are required, reducing the size of the encoded data. Additionally, because the codes are sequential, the decoding algorithm can be dramatically simplified so that it is computationally efficient. [005] Given a list of literals sorted by Huffman code length (denoted by L) in increasing order, the following pseudo code will print a canonical Huffman code book: [006] Algorithm 2: Compute Canonical Huffman Code through its Bit Length

Set , o 0

For = 0,l,...,N-2, do:

Set . ₊₁ = ( . +l) D (L _M

[007] Software compression is very well understood and the source code for programs like GZIP are readily accessible in the public domain. The algorithm to implement compression is relatively complex to do in hardware for high bandwidth application given that the GZIP compression is based on the DEFLATE algorithm and Huffman coding (DEFLATE Compressed Data Format Specification version 1.3. IETF. May 1996. p. 1. sec. Abstract. RFC 1951. Retrieved 11 November 2012). The idea behind compression is to use copy commands later in a data stream that appears earlier in the data stream. As such all compression implementations require a search history buffer and some type of compare length function to determine the longest length that can be used for the copy command. One method to implement the search matching in the previous history is to implement a hash function, which maps the variable length string to fixed value, which can be used to compare the data stream being compressed. The data is hashed and compared to generate a copy or literal command per Lempel-Ziv algorithm or comparable algorithm (Ziv, J.; Lempel, A. (1978). "Compression of individual sequences via variable-rate coding". IEEE Transactions on Information Theory 24 (5): 530). Once the statistics for the data to be compressed are gathered, they are then Huffman encoded and then compressed to be sent out.

[008] Huffman coding is not a simple algorithm to implement in hardware as outlined above. The systems and methods disclosed herein provide an improved approach for implementing canonical Huffman coding using very large scale integration (VLSI) circuits.

BRIEF DESCRIPTION OF THE DRAWINGS

[009] In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which:

[0010] Fig. 1 is a schematic block diagram of a computer system suitable for implementing methods in accordance with embodiments of the invention;

[0011] Fig. 2 is a schematic block diagram of components for VLSI efficient implementation of Huffman encoding in accordance with an embodiment of the present invention;

[0012] Fig. 3 is a process flow diagram of a method simultaneously sorting and generating Huffman code lengths for an input file in accordance with an embodiment of the present invention; [0013] Fig. 4 is a process flow diagram of a method for normalizing canonical Huffman bit lengths to a specified length in accordance with an embodiment of the present invention; and

[0014] Fig. 5 is a process flow diagram of a method for Huffman encoding a data file in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

[0015] It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout.

[0016] The invention has been developed in response to the present state of the art and, in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available apparatus and methods. Accordingly, the invention has been developed to provide apparatus and methods performing Huffman encoding that is well suited for VLSI implementation.

[0017] It is well understood that, using canonical Huffman code, it suffices to transmit the Huffman code lengths for the decompressor to reconstruct Huffman tree, and moreover, the construction algorithm can be easily implemented, as discussed in the Background section. The systems and methods below provide an improved implementation of computing Huffman code length in this section. In particular, the disclosed systems and methods have two aspects. The first aspect transforms the Huffman algorithm to be more readily implemented using very large scale integration (VLSI) design. A second aspect derives a hardware amenable algorithm to limit the maximum Huffman length (so as to limit the number of bits to transmit the Huffman code lengths).

[0018] Embodiments in accordance with the present invention may be embodied as an apparatus, method, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module" or "system." Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0019] Any combination of one or more computer-usable or computer-readable media may be utilized, including non-transitory media. For example, a computer- readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. In selected embodiments, a computer-readable medium may comprise any non- transitory medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0020] Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on a computer system as a stand-alone software package, on a stand-alone hardware unit, partly on a remote computer spaced some distance from the computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0021] The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions or code. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0022] These computer program instructions may also be stored in a non- transitory computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

[0023] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0024] Fig. 1 is a block diagram illustrating an example computing device 100. Computing device 100 may be used to perform various procedures, such as those discussed herein. Computing device 100 can function as a server, a client, or any other computing entity. Computing device can perform various monitoring functions as discussed herein, and can execute one or more application programs, such as the application programs described herein. Computing device 100 can be any of a wide variety of computing devices, such as a desktop computer, a notebook computer, a server computer, a handheld computer, tablet computer and the like.

[0025] Computing device 100 includes one or more processor(s) 102, one or more memory device(s) 104, one or more interface(s) 106, one or more mass storage device(s) 108, one or more Input/Output (I/O) device(s) 110, and a display device 130 all of which are coupled to a bus 112. Processor(s) 102 include one or more processors or controllers that execute instructions stored in memory device(s) 104 and/or mass storage device(s) 108. Processor(s) 102 may also include various types of computer-readable media, such as cache memory. [0026] Memory device(s) 104 include various computer-readable media, such as volatile memory (e.g., random access memory (RAM) 114) and/or nonvolatile memory (e.g., read-only memory (ROM) 116). Memory device(s) 104 may also include rewritable ROM, such as Flash memory.

[0027] Mass storage device(s) 108 include various computer readable media, such as magnetic tapes, magnetic disks, optical disks, solid-state memory (e.g., Flash memory), and so forth. As shown in Fig. 1, a particular mass storage device is a hard disk drive 124. Various drives may also be included in mass storage device(s) 108 to enable reading from and/or writing to the various computer readable media. Mass storage device(s) 108 include removable media 126 and/or non-removable media.

[0028] I/O device(s) 110 include various devices that allow data and/or other information to be input to or retrieved from computing device 100. Example I/O device(s) 110 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.

[0029] Display device 130 includes any type of device capable of displaying information to one or more users of computing device 100. Examples of display device 130 include a monitor, display terminal, video projection device, and the like.

[0030] Interface(s) 106 include various interfaces that allow computing device 100 to interact with other systems, devices, or computing environments. Example interface(s) 106 include any number of different network interfaces 120, such as interfaces to local area networks (LANs), wide area networks (WANs), wireless networks, and the Internet. Other interface(s) include user interface 118 and peripheral device interface 122. The interface(s) 106 may also include one or more user interface elements 118. The interface(s) 106 may also include one or more peripheral interfaces such as interfaces for printers, pointing devices (mice, track pad, etc.), keyboards, and the like.

[0031] Bus 112 allows processor(s) 102, memory device(s) 104, interface(s) 106, mass storage device(s) 108, and I/O device(s) 110 to communicate with one another, as well as other devices or components coupled to bus 112. Bus 112 represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.

[0032] For purposes of illustration, programs and other executable program components are shown herein as discrete blocks, although it is understood that such programs and components may reside at various times in different storage components of computing device 100, and are executed by processor(s) 102. Alternatively, the systems and procedures described herein can be implemented in hardware, or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out one or more of the systems and procedures described herein.

[0033] There are two sorting operations in the original Huffman algorithm. First, literals are sorted in decreasing order of count, and then step-wise re-orders messages based upon the combined count of the least two. This is undesirable as each requires dedicated hardware design. Equivalently, it suffices to determine the two least probable messages step-wise, so that both sorting operations are eliminated. Moreover, there is a hidden scenario where some messages may have zero count. These messages need to be precluded from Huffman coding. A natural way is to first preclude those absent messages and then carry out the Huffman algorithm. This, however, takes extra step for preclusion, and the original sequence of literals is (arbitrarily) shortened (entailing a dedicated memory to store it).

[0034] In some embodiments, a simpler and homogeneous way is to avoid picking zero count when determining two least counts. The pseudo code is given below

[0035] Algorithm 3 : Computing Huffman Code Lengths

Input: (S„i ^> ), / = 0,1,2,..., N -1

Output: (S^L , i = 0,1, 2, ..., N - 1

1. Set L, = 0, /, = i, z = 0,l,2,..., N -l

2. For r = 0,1,2, ..., N - 2, do:

3. m _l = argmin{/-J > 0}, m ₂ = argmin{/-J > 0}

i<N i<N,i≠m _l

4. If m ₂ =∞, then

5. If m _l ≠∞ & r = 0, then L = 1

6. Early termination

7 - + - 0

8. If l _t = m ₂ , then l _t = m _l , i = 0,1,2, ..., N -1

[0036] 9. If/, = /« _! , then + 1, i = 0,1, 2, ..., N -1

[0037] Where Si is a literal, Pi is the count (e.g. probability) for literal Si, Li is the bit length for literal Li, Ii is a map value for Li 7bit code created one by one. On each iteration, two count values are merged, and their map values are likewise merged and set equal to one another. For example, once can create values of 0 and 1. In a next round merged counts and maps may be merged with the count and map value for another literal or another set of merged values. On each iteration, another bit is assigned to the literals or merged values having the two lowest counts. Effetively, one begins at the left and proceeds merging values. After merging, a map value Ii represents an entire branch of a tree. When the bit length for a map value Ii is incrematned, the bit lengths of all code lengths having that value are incremented.

[0038] Upon computing optimal Huffman code lengths, we proceed to enforce length limitation. Let L be the maximum allowed length. We first check and enforce the length limitation

[0039] If L, > L, then set L, <^ L, i = 0,1, 2,..., N - l .

[0040] Denote by he overflow probability scaled by a factor of 2 ^Z , mathematically

[0041] P _o =∑2 ^Z - ^L< - 2\

[0042] A positive overflow probability indicates that the resulting Huffman lengths are invalid and need to revised, by increasing some lengths, to make it non- positive (zero is optimal).

[0043] We then sort the lengths Z., i = 0,1, 2, ..., N - l, firstly by increasing length values and secondly by increasing alphabetic order (when lengths are equal). This immediately enables to construct canonical Huffman codes (Algorithm 2). Noting that the maximum length satisfies L = O(log N) , the sorting can be implemented more efficiently by the following.

[0044] Algorithm 4: Sort of Huffman Lengths in Increasing Order n = 0;

for(/ = l; l≤L; l ^ l + l)

ΐοτ(ι = 0; I < N; + 1)

n *- n + 1; }

[0046] In L. L. Larmore and D. S. Hirschberg, "A fast algorithm for optimal length-limited Huffman codes," Journal of the Association for Computing Machinery, (37)3, pp. 464-473, July 1990, the authors proposed a fast algorithm to compute optimal length-limited Huffman codes with time complexity 0(LN) and space complexity O(N) . The algorithm, however, is still too complex to be implemented in hardware. We next propose a suboptimal algorithm to reduce P _o to non-positive, while maintaining the sorted order (so that canonical Huffman codes can be readily constructed). The idea is to find the latest length such that increasing it by one releases (barely) enough probability to subdue P _o . The algorithmic procedure is given below with respect to Fig. 4.

[0047] Algorithm 5: Suboptimal Construction of Length-Limited Huffman Codes i = 0; whiles ¹ - ^1-2, > ) { i «- i + 1; }

while(L = Lj & s > Si) { Si-i *- Si ; i *- i + 1; }

[0049] Note the second part of the above Algorithm 5 inserts the literal with increased length L _j + 1 to enforce proper alphabetical order among literals with equal length. Since Algorithm 5 suppresses the overflow probability, at the same time keeps the literals in order, Algorithm 2 in preceding section is readily deployed to compute the corresponding canonical Huffman codes.

[0050] Referring to Fig. 2, the algorithms above may be implanted using the illustrated modules either as separate electronic components or software modules. As noted above, the methods described herein are readily implemented using VLSI design techniques.

[0051] An input file 202 may be input into a copy/literal command generator 204. The copy/literal commands may be generated according to a conventional duplicate string elimination algorithm, such as the LZ77 (Lempel and Ziv) or LZ78 algorithm. As known in the art, duplicate string elimination processes literals of a file. If string of literals (one or more) is found to be preceded in the file by an identical string of literals, the string of literals is replaced with a flag indicating it is a copy as well as a length indicating the number of literals in the string and an offset indicating how far back in the file to the beginning (or end) of the identical string of literals. A literal that is not preceded in the file by an identical literal may be flagged in a different manner such as a "literal" flag. In some instances, literals are flagged with a one bit and the copies are flagged with a zero bit, or vice-versa.

[0052] The input file 202 as processed to include the copy/literal commands by the copy/literal command generator 204 (the "processed file") may be input to a statistics generator 206. The statistics generator counts the number of instances of each literal represented in processed file. In some embodiments, separate sets of usage statistics may be generated for different types of data. For example, usage statistics may be determined for each literal command (e.g. count the number of occurrences of each literal flagged as a literal. Usage statistics may be determined for each copy command. Separate sets of usage statistics may be determined for the length values (e.g. count the number of occurrences of each length value represented) and the offset values of the copy commands (e.g. count the number of occurrences of each offset value represented).

[0053] For example, statistics may be gathered for the LZ commands consisting of the FlagRun, Offset, Length and Literal. The FlagRun command may be a command that indicates that N of the following bytes are should be treated as literals, thereby eliminating the need to flag each literal as a "literal." The FlagRun command may be assigned as described in U.S. Application Serial No. 14/274,364, filed May 9, 2014, and entitled IMPROVED DEFLATE COMPRESSION ALGORITHM.

[0054] The statistics can be gathered in many different bins for the dynamic Huffman Encoding. In some embodiments, the statistics gathered for each LZ command are limited to at most 16 bins.

[0055] The statistics are gathered to generate a dynamic Huffman Codes used to compress the data stream. The dynamic Huffman Code is generated using a two stage engine as shown in Fig. 2. The first engine (Huffman bit length engine 208) generates the Huffman bit lengths which will be sent as part of the compression header for decompression. The second engine (Huffman code generation engine) enforces a Huffman tree code length so that it is not longer than N bits long (e.g. 7, 15, 31, or some other value) even though the tree depth can be more than N bits long for the dynamic Huffman coding.

[0056] The canonical Huffman code output by the Huffman code generation engine 210 may be input with the processed file to a Huffman coder 212, which performs Huffman coding of the processed file using the canonical Huffman code to produce a compressed output file.

[0057] The Huffman Bits Length Engine 208 may perform the method 300 of Fig. 3. The conventional approach for generating the canonical Huffman bit lengths is to sort all the data. The method 300 does not require the sorting first. The hardware may therefore be simplified to only find the lowest to nodes at each iteration while the Huffman bit lengths are being generated. The map values alluded in the flow chart refer to the element that is being Huffman coded meaning it can be literal, offset, flagRun, or length. The count refers to the frequency count of the map values to be Huffman coded.

[0058] The method 300 may include obtaining 302 counts P(0) to P(N) for each symbol S(0) to S(N), respectively, of a data set (literal, flagRun, offset, or length). Each count P(i) represents the number of occurrences of symbol S(i) in the data set. Bit lengths L(0) to L(N) for each symbol S(0) to S(N), respectively, may be initialized 304 to zero and invalid entries may be removed. Invalid entries may be symbols S(i) having corresponding counts P(i) equal to zero. For the remainder of the method 300, the symbols S(0) to S(N) considered may include only those that are valid, i.e. have a nonzero count P(0) to P(N). Likewise, map values 1(0) to I(N) for each symbol S(0) to S(N), respectively, may be initialized 306. Initializing the map values 1(0) to I(N) may include setting each map value I(i) equal to i, i = 0 to N.

[0059] The method 300 may then include finding 308 two symbols S(a) and S(b) having the two lowest corresponding counts P(a) and P(b). The sum of these counts Pt = P(a) + P(b) may then be determined 310. The symbol S(min) of the symbols S(a) and S(b) having the smallest map value 1(a), 1(b) may also be determined 312. The count P(min) corresponding to the smaller map value may be set 314 equal to the sum of the counts (Pt). The count P(max) of the symbol S(max) of the symbols S(a), S(b) having the largest map value 1(a), 1(b) may be set 316 equal to zero. The map values 1(a) and 1(b) may both be set 318 to be equal to the smaller map value, i.e. I(max) may be set equal to I(min). Although both map values 1(a) and 1(b) for both counts P(a) and P(b) are set equal to the smaller map value in this embodiment, in other embodiments, the map value to which 1(a) and 1(b) are set equal may be either map value selected in any manner provided they are equal to one another. Likewise, whichever map value is selected, the count P(i) corresponding to the selected map value I(i) may be set equal to Pt.

[0060] The bit lengths L(a) and L(b) corresponding to both symbols S(a) and S(b) may be incremented 320 by one. In subsequent iterations, one or both of the counts P(a) and P(b) may correspond to one or more literals that have been previously processed. Accordingly, the bit lengths L(i) of all symbols S(i) having a map value I(i) matching either of the map values 1(a) or 1(b) may be incremented 320 in subsequent iterations of steps 308-322.

[0061] The method 300 may then include determining 322 whether all of the counts P(0) to P(N) 1(0) are equal to zero. If not, the method continues at step 308. If so, then the method 300 may end. In some embodiments, rather than determining whether all counts are equal to zero, step 322 may include evaluating a counter to determine whether all non-zero counts have been processed, the counter being incremented upon each iteration of steps 308-322 or initialized to the number of non-zero counts and decremented upon each iteration of steps 308-322. [0062] The bit lengths L(0) to L(N) as determined according to the method 300 may then be sorted into canonical order and stored as a header of a compressed file for use by a decompression engine to decompress a data file. The bit lengths L(0) to L(N) are also used to compress the data file according to conventional Huffman coding using a canonical Huffman code.

[0063] The bit lengths L(0) to L(N) determined according to the method 400 may then be processed further in order to limit the length of the bit lengths to some fixed value Lmax. For example, Lmax may be equal to 7 bits.

[0064] Fig. 4 illustrates an example method 400 for limiting the length of Huffman codes. The method 400 may include constructing 402 Huffman codes without length limitation and sorting 404 the Huffman codes into canonical order, such as performing generation and sorting simultaneously using the method 300 or a conventional approach in which codes are generated and sorted in separate steps.

[0065] Bit lengths larger than Lmax are converted 406 to Lmax. For example, each bit length L(i) having an original value greater than Lmax (e.g. 7) may be set equal to 7 (L(i) = Lmax).

[0066] The overflow probability for the bit lengths L(0) to L(N) as limited at step 406 may then be computed 408. The overflow probability P ₀ may be computed as

JV-l

[0067] = ^2 ^Zmax~z(0 -2 ^Zmax .

i=0

[0068] A length Lmin may then be found 410 that, when incremented, causes the overflow probability to be less than zero. As noted above, a positive overflow probability indicates that a Huffman code is invalid. In particular, Lmin may be the largest bit length L(i) that when incremented by one causes the overflow probability to change from positive to less than or equal to zero. A second bit length L(j) = Lmin - 1 may then be incremented 412. In some instances there may be multiple bit lengths L(i) having equal lengths. In this case, the bit lengths of equal length may be arranged alphabetically in list of bite lengths. Accordingly, the second bit length L(j) = Lmin - 1 that is incremented may be selected as the last bit length equal to Lmin - 1.

[0069] As noted above, in the canonical ordering, bit lengths of equal lengths are ordered alphabetically. Accordingly, the method 400 may include evaluating 414 whether L(j) is no longer in canonical order. If L(j) is not found 416 to be in canonical order it may be shifted 418 to the right. For example, assume the bit lengths before incrementing are in the order L('B') = 4, L('E') = 4, and L('A') = 5. If L('E') is incremented to be 5, the ordering will now be L('B') = 4, L('E') = 5, and L('A') = 5. L('E') and L('A') are no longer in canonical order. Accordingly, right shifting 418 may include shifting L('E') to the right such that the ordering is now L('B') = 4, L('A') = 5, and L('E') = 5. The right shifting may continue until the incremented bit length B(j) is in the canonical order.

[0070] The bit lengths L(0) to L(N) ordered in canonical order may then be used to create 420 the correct codes, such as according to Algorithm 2.

[0071] Referring to Fig. 5, as noted above, when generating a dynamic Huffman code for the symbols of dataset (fiagrun, offset, length, literal) the numer of bins in which usage statistics may be accumulated may be limited. To facilitate this, symbols encoded as bytes may be treated as two 4 bit quantities labeled as MSBHufflits (most significant four bits) and LSBHuffLits (least significant four bits). This guarantees that the total bits for the literal statistics gathered will only complete fit in 16 binning statistics.

[0072] A method 500 for encoding a processed file may include assigning flagRun literals to bins for only a first portion of a M kB file to N+l bins, where N is the maximum Huffman code length imposed according to the method 400. For example, a flagRun values from 1 to 8 literals will be assigned to bins 0 to 7 as shown in Table 1 , below. The method 500 may include omitting 504 compression of flagRun literals for a second portion of a data file, which may include omitting counting flagRun literals for the second portion of the data file.

Table 1. FlagRun Bins

[0073] FlagRun symbols in a second portion of a file, e.g. a second half, may be Huffman coded. For example, the flagRun literals can be dynamically coded using an average formula of literals versus copy commands or some other formulate rather than just half of the compression coding frame, or it can be dynamically coded for a fixed percentage of the compression frame other than half. [0074] The method 500 may include mapping 506 the offset values to a fixed number of bins, such as 2*(N+1) bins, or 16 bins for N = 7. For example, the Offset Map may consist of 16 bins for the statistics gathering segmented according to Table 2. In some embodiments, for the offset binning, the "same as last copy offset" can use another binning value other than 0 such as 15 or any number in between. Likewise, The bin used for 'Dictionary' copy may use some other bin value than 0.

Table 2.

Offset Bin Mapping

[0075] As is readily apparent, the number of possible values for the offset greatly exceeds the number of bins. However, as noted above, constraining the offset values to a fixed number of bins enables the offset values to be dynamically Huffman coded using a VLSI device.

[0076] The method 500 may include mapping 508 length values to 2*(N+1) bins or 16 bins for N = 7. For example, length values may be assigned to one of 16 bins according to Table 3.

Table 3. Length Bin Mapping

[0077] The method 500 may include mapping 508 length values to 2*(N+1) bins or 16 bins for N = 7. For example, length values may be assigned to one of 16 bins according to Table 3.

[0078] The method 500 may include generating 510 canonical Huffman codes for each set of bins. For example, for the counts for each set of bins (flagRun, length, offset, and literal) a canonical Huffman code may be generated according to the method 300. The Huffman codes generated at step 510 may then be Normalized 512. Normalizaiton may include transforming the Huffman codes such that the bit lengths are not greater than N according to the method 400 of Fig. 4. The symbols of each data set (flagRun, length, offset, and literal) may then be Huffman encoded 514 using the Huffman codes determined for each data set at step 512.

[0079] The Huffman encoded data sets may be written to an output stream and transmitted to a receiving device with a header including the Huffman codes used to encode each data set. The output stream or output file for an input data file may be written in the form of a Header Tree Header which is 6 bytes long for the Huffman code determined for each of the MSB of literals, LSB of literals, lengths, offsets. The Header Tree Header may be 3 bytes long for the flagRun for literals, i.e. because for 7 bits, only three bytes are needed.

[0080] In the example, above, an input data file of 4K bytes, however other file sizes may be used, such as 8K, 16K, 32K, 64K, or some other size. Likewise, rather than limiting the code length to 7 bits, the code lengths may be limited to some other value, such as 15 bits, 31 bits, or some other value, which may depend on the size of the input file. Likewise, a partial mapping may be performed of an offset values table for copy command for a 4K Offset. Likewise, dynamic Huffman coding of literal commands for 2K bytes of a 4K sector may be performed.

[0081] The following references are incorporated herein in their entirety:

[0082] [1]. D. A. Huffman, "A method for the construction of minimum- redundancy codes" Proc. IRE 40 (9). pp. 1098-1101. 1952. [0083] [2]. L. L. Larmore and D. S. Hirschberg, "A fast algorithm for optimal length-limited Huffman codes," Journal of the Association for Computing Machinery, (37)3, pp. 464-473, July 1990.

[0084] [3]. DEFLATE Compressed Data Format Specification version 1.3. IETF. May 1996. p. 1. sec. Abstract. RFC 1951. Retrieved 11 November 2012.

[0085] [4]. Ziv, J.; Lempel, A. (1978). "Compression of individual sequences via variable-rate coding". IEEE Transactions on Information Theory 24 (5): 530.

[0086] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative, and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0087] What is claimed is: