<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Algorithms</journal-id>
<journal-title>Algorithms</journal-title>
<issn pub-type="epub">1999-4893</issn>
<publisher>
<publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3390/a4030183</article-id>
<article-id pub-id-type="publisher-id">algorithms-04-00183</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>Lempel–Ziv Data Compression on Parallel and Distributed Systems</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>De Agostino</surname><given-names>Sergio</given-names></name></contrib>
<aff id="af1-algorithms-04-00183">Computer Science Department, Sapienza University, Via Salaria 113, Rome, Italy; E-Mail: <email>eagostino@di.uniroma1.it</email>; Tel.: +39-06-4991-8529; Fax: +39-06-857-1842</aff></contrib-group>
<pub-date pub-type="collection">
<year>2011</year></pub-date>
<pub-date pub-type="epub">
<day>14</day>
<month>09</month>
<year>2011</year></pub-date>
<volume>4</volume>
<issue>3</issue>
<fpage>183</fpage>
<lpage>199</lpage>
<history>
<date date-type="received">
<day>29</day>
<month>07</month>
<year>2011</year></date>
<date date-type="rev-recd">
<day>23</day>
<month>08</month>
<year>2011</year></date>
<date date-type="accepted">
<day>30</day>
<month>08</month>
<year>2011</year></date></history>
<permissions>
<copyright-statement>© 2011 by the author; licensee MDPI, Basel, Switzerland.</copyright-statement>
<copyright-year>2011</copyright-year>
<license>
<p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/.)</p></license></permissions>
<abstract>
<p>We present a survey of results concerning Lempel–Ziv data compression on parallel and distributed systems, starting from the theoretical approach to parallel time complexity to conclude with the practical goal of designing distributed algorithms with low communication cost. Storer's extension for image compression is also discussed.</p></abstract>
<kwd-group>
<kwd>dictionary-based compression</kwd>
<kwd>string factorization</kwd>
<kwd>parallel complexity</kwd>
<kwd>distributed algorithm</kwd>
<kwd>binary image</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>Lempel–Ziv compression [<xref ref-type="bibr" rid="b1-algorithms-04-00183">1</xref>–<xref ref-type="bibr" rid="b3-algorithms-04-00183">3</xref>] is based on string factorization. Two different factorization processes exist with no memory constraints. With the first one (LZ1) [<xref ref-type="bibr" rid="b2-algorithms-04-00183">2</xref>], each factor is independent from the others since it extends by one character the longest match with a substring to its left in the input string. With the second one (LZ2) [<xref ref-type="bibr" rid="b3-algorithms-04-00183">3</xref>], each factor is instead the extension by one character of the longest match with one of the previous factors. This computational difference implies that while LZ1 compression has efficient parallel algorithms [<xref ref-type="bibr" rid="b4-algorithms-04-00183">4</xref>,<xref ref-type="bibr" rid="b5-algorithms-04-00183">5</xref>] LZ2 compression is hard to parallelize [<xref ref-type="bibr" rid="b6-algorithms-04-00183">6</xref>]. This difference is maintained when bounded memory versions of Lempel–Ziv compression are considered [<xref ref-type="bibr" rid="b5-algorithms-04-00183">5</xref>,<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>,<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>]. On the other hand, parallel decompression is possible for both approaches [<xref ref-type="bibr" rid="b9-algorithms-04-00183">9</xref>]. Moreover, distributed algorithms for the LZ1 and LZ2 methods approximating in practice their compression effectiveness have been realized [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>,<xref ref-type="bibr" rid="b10-algorithms-04-00183">10</xref>–<xref ref-type="bibr" rid="b12-algorithms-04-00183">12</xref>]. The LZ2 method is less effective than LZ1 but it is more scalable if we use a tree architecture. In Section 2, we describe the Lempel–Ziv compression techniques and in Section 3, we present the bounded memory versions. In Sections 4 and and 5 we discuss how Lempel–Ziv data compression and decompression can be implemented on parallel and distributed systems, respectively. The Storer's extension [<xref ref-type="bibr" rid="b13-algorithms-04-00183">13</xref>] for image compression is discussed in Section 6. Conclusions and future work are given in Section 7.</p></sec>
<sec sec-type="methods">
<label>2.</label>
<title>Lempel–Ziv Data Compression</title>
<p>Lempel–Ziv compression is a dictionary-based technique. In fact, the factors of the string are substituted by <italic>pointers</italic> to copies stored in a dictionary which are called <italic>targets</italic>. LZ1 (LZ2) compression is also called the sliding (dynamic) dictionary method.</p>
<sec>
<label>2.1.</label>
<title>LZ1 Compression</title>
<p>Given an alphabet <italic>A</italic> and a string <italic>S</italic> in <italic>A</italic>*, the LZ1 factorization of <italic>S</italic> is <italic>S</italic> = <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f<sub>i</sub></italic> ⋯ <italic>f<sub>k</sub></italic> where <italic>f<sub>i</sub></italic> is the shortest substring which does not occur previously in the prefix <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f<sub>i</sub></italic> for 1 ≤ <italic>i</italic> ≤ <italic>k</italic>. With such factorization, the encoding of each factor leaves one character uncompressed. To avoid this, a different factorization was introduced (LZSS factorization) where <italic>f<sub>i</sub></italic> is the longest match with a substring occurring in the prefix <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f<sub>i</sub></italic> if <italic>f<sub>i</sub></italic> ≠ λ, otherwise <italic>f<sub>i</sub></italic> is the alphabet character next to <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f</italic><sub><italic>i</italic>−1</sub> [<xref ref-type="bibr" rid="b15-algorithms-04-00183">15</xref>]. <italic>f<sub>i</sub></italic> is encoded by the pointer <italic>q<sub>i</sub></italic> = (<italic>d<sub>i</sub>, ℓ<sub>i</sub></italic>), where <italic>d<sub>i</sub></italic> is the displacement back to the copy of the factor and <italic>ℓ<sub>i</sub></italic> is the length of the factor (LZSS compression). If <italic>d<sub>i</sub></italic> = 0, <italic>l<sub>i</sub></italic> is the alphabet character. In other words the dictionary is defined by a window sliding its right end over the input string, that is, it comprises all the substrings of the prefix read so far in the computation. It follows that the dictionary is <italic>both prefix</italic> and <italic>suffix</italic> since all the prefixes and suffixes of a dictionary element are dictionary elements. The position of the longest match in the prefix with the current position can be computed in real time by means of a suffix tree data structure [<xref ref-type="bibr" rid="b16-algorithms-04-00183">16</xref>,<xref ref-type="bibr" rid="b17-algorithms-04-00183">17</xref>].</p></sec>
<sec>
<label>2.2.</label>
<title>LZ2 Compression</title>
<p>The LZ2 factorization of a string <italic>S</italic> is <italic>S</italic> = <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f<sub>i</sub></italic>⋯ <italic>f<sub>k</sub></italic> where <italic>f<sub>i</sub></italic> is the shortest substring which is different from one of the previous factors. As for LZ1 the encoding of each factor leaves one character uncompressed. To avoid this a different factorization was introduced (LZW factorization) where each factor <italic>f<sub>i</sub></italic> is the longest match with the concatenation of a previous factor and the next character [<xref ref-type="bibr" rid="b18-algorithms-04-00183">18</xref>]. <italic>f<sub>i</sub></italic> is encoded by a pointer <italic>q<sub>i</sub></italic> to such concatenation (LZW compression). LZ2 and LZW compression can be implemented in real time by storing the dictionary with a trie data structure. Differently from LZ1 and LZSS, the dictionary is only prefix.</p></sec>
<sec>
<label>2.3.</label>
<title>Greedy versus Optimal Factorization</title>
<p>The pointer encoding the factor <italic>f<sub>i</sub></italic> has a size increasing with the index <italic>i</italic>. This means that the lower is the number of factors for a string of a given length, the better is the compression. The factorizations described in the previous subsections are produced by greedy algorithms. The question is whether the greedy approach is always optimal, that is, if we relax the assumption that each factor is the longest match, can we do better than greedy? The answer is negative with suffix dictionaries as for LZ1 or LZSS compression. On the other hand, the greedy approach is not optimal for LZ2 or LZW compression. However, the optimal approach is NP-complete [<xref ref-type="bibr" rid="b19-algorithms-04-00183">19</xref>] and the greedy algorithm approximates with an 
<inline-formula>
<mml:math id="mm1" display="inline">
<mml:semantics id="sm1">
<mml:mrow>
<mml:mtext>O</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mrow>
<mml:mfrac>
<mml:mn>1</mml:mn>
<mml:mn>4</mml:mn></mml:mfrac></mml:mrow></mml:msup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></inline-formula> multiplicative factor the optimal solution [<xref ref-type="bibr" rid="b20-algorithms-04-00183">20</xref>].</p></sec></sec>
<sec>
<label>3.</label>
<title>Bounded Size Dictionary Compression</title>
<p>The factorization processes described in the previous section are such that the number of different factors (that is, the dictionary size) grows with the string length. In practical implementations instead the dictionary size is bounded by a constant and the pointers have equal size. While for LZSS (or LZ1) compression this can be simply obtained by sliding a fixed length window and by bounding the match length, for LZW (or LZ2) compression dictionary elements are removed by using a deletion heuristic. The deletion heuristics we describe in this section are FREEZE, RESTART and LRU [<xref ref-type="bibr" rid="b21-algorithms-04-00183">21</xref>]. Then, we give more details on sliding window compression.</p>
<sec>
<label>3.1.</label>
<title>The Deletion Heuristics</title>
<p>Let <italic>d</italic>+<italic>α</italic> be the cardinality of the fixed size dictionary where <italic>α</italic> is the cardinality of the alphabet. With the FREEZE deletion heuristic, there is a first phase of the factorization process where the dictionary is filled up and “frozen”. Afterwards, the factorization continues in a “static” way using the factors of the frozen dictionary. In other words, the LZW factorization of a string <italic>S</italic> using the FREEZE deletion heuristic is <italic>S</italic> = <italic>f</italic><sub>1</sub><italic>f<sub>2</sub></italic> ⋯ <italic>f<sub>i</sub></italic> ⋯ <italic>f<sub>k</sub></italic> where <italic>f<sub>i</sub></italic> is the longest match with the concatenation of a previous factor <italic>f<sub>j</sub></italic>, with <italic>j</italic> ≤ <italic>d</italic>, and the next character. The shortcoming of this heuristic is that after processing the string for a while the dictionary often becomes obsolete. A more sophisticated deletion heuristic is RESTART, which monitors the compression ratio achieved on the portion of the input string read so far and, when it starts deteriorating, restarts the factorization process. Let <italic>f</italic><sub>1</sub><italic>f</italic><sub>2</sub> ⋯ <italic>f<sub>j</sub></italic> ⋯ <italic>f<sub>i</sub></italic> ⋯ <italic>f<sub>k</sub></italic> be such factorization with <italic>j</italic> the highest index less than <italic>i</italic> where the restart operation happens. Then, <italic>f<sub>j</sub></italic> is an alphabet character and <italic>f<sub>i</sub></italic> is the longest match with the concatenation of a previous factor <italic>f<sub>h</sub></italic>, with <italic>h</italic> ≥ <italic>j</italic>, and the next character (the restart operation removes all the elements from the dictionary but the alphabet characters). This heuristic is used by the Unix command Compress since it has a good compression effectiveness and it is easy to implement. However, the best deletion heuristic is LRU (last recently used strategy). The LRU deletion heuristic removes elements from the dictionary in a continuous way by deleting at each step of the factorization the least recently used factor which is not a proper prefix of another one.</p></sec>
<sec>
<label>3.2.</label>
<title>Compression with Finite Windows</title>
<p>As mentioned at the beginning of this section, LZSS (or LZ1) bounded size dictionary compression is obtained by sliding a fixed length window and by bounding the match length. A real time implementation of compression with finite window is possible using a suffix tree data structure [<xref ref-type="bibr" rid="b22-algorithms-04-00183">22</xref>]. Much simpler real time implementations are realized by means of hashing techniques providing a specific position in the window where a good approximation of the longest match is found on realistic data. In [<xref ref-type="bibr" rid="b23-algorithms-04-00183">23</xref>], the three current characters are hashed to yield a pointer into the already compressed text. In [<xref ref-type="bibr" rid="b24-algorithms-04-00183">24</xref>], hashing of strings of all lengths is used to find a match. In both methods, collisions are resolved by overwriting. In [<xref ref-type="bibr" rid="b25-algorithms-04-00183">25</xref>], the two current characters are hashed and collisions are chained via an offset array. Also the Unix gzip compressor chains collisions but hashes three characters [<xref ref-type="bibr" rid="b26-algorithms-04-00183">26</xref>].</p></sec>
<sec>
<label>3.3.</label>
<title>Greedy versus Optimal Factorization</title>
<p>Greedy factorization is optimal for compression with finite windows since the dictionary is suffix. With LZW compression, after we fill up the dictionary using the FREEZE or RESTART heuristic, the greedy factorization we compute with such dictionary is not optimal since the dictionary is not suffix. However, there is an optimal semi-greedy factorization which is computed by the procedure of <xref ref-type="fig" rid="f1-algorithms-04-00183">figure 1</xref> [<xref ref-type="bibr" rid="b27-algorithms-04-00183">27</xref>,<xref ref-type="bibr" rid="b28-algorithms-04-00183">28</xref>]. At each step, we select a factor such that the longest match in the next position with a dictionary element ends to the rightest. Since the dictionary is prefix, the factorization is optimal. The algorithm can even be implemented in real time with a modified suffix tree data structure [<xref ref-type="bibr" rid="b27-algorithms-04-00183">27</xref>].</p></sec></sec>
<sec>
<label>4.</label>
<title>Lempel–Ziv Compression on a Parallel System</title>
<p>LZSS (or LZ1) compression can be efficiently parallelized on a PRAM EREW [<xref ref-type="bibr" rid="b4-algorithms-04-00183">4</xref>,<xref ref-type="bibr" rid="b5-algorithms-04-00183">5</xref>,<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>], that is, a parallel machine where processors access a shared memory without reading and writing conflicts. On the other hand, LZW (or LZ2) compression is P-complete [<xref ref-type="bibr" rid="b6-algorithms-04-00183">6</xref>] and, therefore, hard to parallelize. Decompression, instead, is parallelizable for both methods [<xref ref-type="bibr" rid="b9-algorithms-04-00183">9</xref>]. As far as bounded size dictionary compression is concerned, the “parallel computation thesis” claims that sequential work space and parallel running time have the same order of magnitude giving theoretical underpinning to the realization of parallel algorithms for LZW compression using a deletion heuristic. However, the thesis concerns unbounded parallelism and a practical requirement for the design of a parallel algorithm is a limited number of processors. A stronger statement is that sequential logarithmic work space corresponds to parallel logarithmic running time with a polynomial number of processors. Therefore, a fixed size dictionary implies a parallel algorithm for LZW compression satisfying these constraints. Realistically, the satisfaction of these requirements is a necessary but not a sufficient condition for a practical parallel algorithm since the number of processors should be linear, which does not seem possible for the RESTART deletion heuristic. Moreover, the SC<italic><sup>k</sup></italic>-completeness of LZ2 compression using the LRU deletion heuristic and a dictionary of polylogarithmic size shows that it is unlikely to have a parallel complexity involving reasonable multiplicative constants [<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>]. In conclusion, the only practical LZW compression algorithm for a shared memory parallel system is the one using the FREEZE deletion heuristic. We will see these arguments more in details in the next subsections.</p>
<sec>
<label>4.1.</label>
<title>Sliding Window Compression on a Parallel System</title>
<p>We present compression algorithms for sliding dictionaries on an exclusive read, exclusive write shared memory machine requiring O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors if <italic>k</italic> is Ω(log <italic>n</italic>), with the practical and realistic assumption that the dictionary size and the match length are constant [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>]. As previously mentioned, greedy factorization is optimal with sliding dictionaries. In order to compute a greedy factorization in parallel we find the greedy match in each position <italic>i</italic> of the input string and link <italic>i</italic> to <italic>j</italic> + 1, where <italic>j</italic> is the last position of the match. If the greedy match ends the string <italic>i</italic> is linked to <italic>n</italic> + 1, where <italic>n</italic> is the length of the string. It follows that we obtain a tree rooted in <italic>n</italic> + 1 and the positions of the factors are given by the path from 1 to <italic>n</italic> + 1. Such tree can be built in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors. In fact, on each block of <italic>k</italic> positions one processor has to compute a match having constant length and the reading conflicts with other processors are solved in logarithmic time by standard broadcasting techniques. Then, since for each node of the tree the number of children is bounded by the constant match length it is easy to add the links from a parent node to its children in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors and apply the well-known Euler tour technique to this doubly linked tree structure to compute the path from 1 to <italic>n</italic> + 1.</p></sec>
<sec sec-type="results">
<label>4.2.</label>
<title>The Completeness Results</title>
<p>NC is the class of problems solvable with a polynomial number of processors in polylogarithmic time on a parallel random access machine and it is conjectured to be a proper subset of P, the class of problems solvable in sequential polynomial time. LZ2 and LZW compression with an unbounded dictionary have been proved to be P-complete [<xref ref-type="bibr" rid="b6-algorithms-04-00183">6</xref>] and, therefore, hard to parallelize. SC is the class of problems solvable in polylogarithmic space and sequential polynomial time. The LZ2 algorithm with LRU deletion heuristic on a dictionary of size O(log<italic><sup>k</sup> n</italic>) can be performed in polynomial time and O(log<italic><sup>k</sup> n</italic> log log <italic>n</italic>) space, where <italic>n</italic> is the length of the input string. In fact, the trie requires O(log<italic><sup>k</sup> n</italic>) space by using an array implementation since the number of children for each node is bounded by the alphabet cardinality. The log log <italic>n</italic> factor is required to store the information needed for the LRU deletion heuristic since each node must have a different age, which is an integer value between 0 and the dictionary size. Obviously, this is true for the LZW algorithm as well. If the size of the dictionary is O(log<italic><sup>k</sup> n</italic>), the LRU strategy is log-space hard for SC<italic><sup>k</sup></italic>, the class of problems solvable simultaneously in polynomial time and O(log<italic><sup>k</sup> n</italic>) space [<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>]. The problem belongs to SC<italic><sup>k</sup></italic><sup>+1</sup>. This hardness result is not so relevant for the space complexity analysis since Ω(log<italic><sup>k</sup> n</italic>) is an obvious lower bound to the work space needed for the computation. Much more interesting is what can be said about the parallel complexity analysis. In [<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>] it was shown that LZ2 (or LZW) compression using the LRU deletion heuristic with a dictionary of size <italic>c</italic> can be performed in parallel either in O(log <italic>n</italic>) time with 2<sup>O(<italic>c</italic> log <italic>c</italic>)</sup> <italic>n</italic> processors or in 2<sup>O(<italic>c</italic> log <italic>c</italic>)</sup> log <italic>n</italic> time with O(<italic>n</italic>) processors. This means that if the dictionary size is constant, the compression problem belongs to NC. NC and SC are classes that can be viewed in some sense symmetric and are believed to be incomparable. Since log-space reductions are in NC, the compression problem cannot belong to NC when the dictionary size is polylogarithmic if NC and SC are incomparable. We want to point out that the dictionary size <italic>c</italic> figures as an exponent in the parallel complexity of the problem. This is not by accident. If we believe that SC is not included in NC, then the SC<italic><sup>k</sup></italic>-hardness of the problem when <italic>c</italic> is O(log<italic><sup>k</sup> n</italic>) implies the exponentiation of some increasing and diverging function of <italic>c</italic>. In fact, without such exponentiation either in the number of processors or in the parallel running time, the problem would be SC<italic><sup>k</sup></italic>-hard and in NC when <italic>c</italic> is O(log<italic><sup>k</sup> n</italic>). Observe that the P-completeness of the problem, which requires a superpolylogarithmic value for <italic>c</italic>, does not suffice to infer this exponentiation since <italic>c</italic> can figure as a multiplicative factor of the time function. Moreover, this is a unique case so far where somehow we use hardness results to argue that practical algorithms of a certain kind (NC in this case) do not exist because of huge multiplicative constant factors occurring in their analysis. In [<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>] a relaxed version (RLRU) was introduced which turned out to be the first (and only so far) natural SC<italic><sup>k</sup></italic>-complete problem. RLRU partitions the dictionary in <italic>p</italic> equivalence classes, so that all the elements in each class are considered to have the same “age” for the LRU strategy. RLRU turns out to be as good as LRU even when <italic>p</italic> is equal to 2 [<xref ref-type="bibr" rid="b29-algorithms-04-00183">29</xref>]. Since RLRU removes an arbitrary element from the equivalence class with the “older” elements, the two classes (when p is equal to 2) can be implemented with a couple of stacks, which makes RLRU slightly easier to implement than LRU in addition to be more space efficient.</p></sec>
<sec>
<label>4.3.</label>
<title>LZW Compression on a Parallel System</title>
<p>As mentioned at the beginning of this section, the only practical LZW compression algorithm for a shared memory parallel system is the one using the FREEZE deletion heuristic. After the dictionary is built and frozen, a parallel procedure similar to the one for LZ1 compression is run. To compute a greedy factorization in parallel we find the greedy match with the frozen dictionary in each position <italic>i</italic> of the input string and link <italic>i</italic> to <italic>j</italic> + 1, where <italic>j</italic> is the last position of the match. If the greedy match ends the string <italic>i</italic> is linked to <italic>n</italic> + 1, where <italic>n</italic> is the length of the string. It follows that we obtain a tree rooted in <italic>n</italic> + 1 and the positions of the factors of the greedy parsing are given by the path from 1 to <italic>n</italic> + 1. In order to compute an optimal factorization we parallelize the semi-greedy procedure. The longest sequence of two matches in each position <italic>i</italic> of the string can be computed in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors, in a similar way as for the greedy procedure. Then, position <italic>i</italic> is linked to the position of the second match. If the second match is empty, <italic>i</italic> is linked to <italic>n</italic> + 1. Again, we obtain a tree rooted in <italic>n</italic> + 1 and the positions of the factors are given by the path from 1 to <italic>n</italic> + 1. The tree and the path are computed in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors if <italic>k</italic> is Ω(log <italic>n</italic>), as in the first subsection without reading and writing conflicts [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>]. The parallelization of the sequential LZW compression algorithm with the RESTART deletion heuristic is not practical enough since it requires a quadratic number of processors [<xref ref-type="bibr" rid="b7-algorithms-04-00183">7</xref>].</p></sec>
<sec>
<label>4.4.</label>
<title>Parallel Decompression</title>
<p>The design of parallel decoders is based on the fact that the Euler tour technique can also be used to find the trees of a forest in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors on a shared memory parallel machine without writing and reading conflicts, if <italic>k</italic> is Ω(log <italic>n</italic>) and <italic>n</italic> is the number of nodes. We present decoders paired with the practical coding implementations using bounded size dictionaries. First, we see how to decode the sequence of pointers <italic>q<sub>i</sub></italic> = (<italic>d<sub>i</sub>, ℓ<sub>i</sub></italic>) produced by the LZSS method with 1 ≤ <italic>i</italic> ≤ <italic>m</italic> [<xref ref-type="bibr" rid="b9-algorithms-04-00183">9</xref>]. If <italic>s</italic><sub>1</sub>, …, <italic>s<sub>m</sub></italic> are the partial sums of <italic>l</italic><sub>1</sub>, …, <italic>l<sub>m</sub></italic>, the target of <italic>q<sub>i</sub></italic> encodes the substring over the positions <italic>s</italic><sub><italic>i</italic>−1</sub> +1 ⋯ <italic>s<sub>i</sub></italic> of the output string. Link the positions <italic>s</italic><sub><italic>i</italic>−1</sub> +1 ⋯ <italic>s<sub>i</sub></italic> to the positions <italic>s</italic><sub><italic>i</italic>−1</sub> +1 − <italic>d<sub>i</sub></italic> ⋯ <italic>s</italic><sub><italic>i</italic>−1</sub> + 1 − <italic>d<sub>i</sub></italic> + <italic>l<sub>i</sub></italic> − 1, respectively If <italic>d<sub>i</sub></italic> = 0, the target of <italic>q<sub>i</sub></italic> is an alphabet character and the corresponding position in the output string is not linked to anything. Therefore, we obtain a forest where all the nodes in a tree correspond to positions of the decoded string where the character is represented by the root. The reduction from the decoding problem to the problem of finding the trees in a forest can be computed in O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors where <italic>n</italic> is the length of the output string, because this is the complexity of computing the partial sums since <italic>m</italic> ≤ <italic>n</italic>. Afterwards, one processor stores the parent pointers in an array of size <italic>n</italic> for a block of <italic>k</italic> positions. We can make the forest a doubly linked structure since the window size is constant and apply the Euler tour technique to find the trees.</p>
<p>With LZW compression using the FREEZE deletion heuristic the parallel decoder is trivial. We wish to point out that the decoding problem is interesting independently from the computational efficiency of the encoder. In fact, in the case of compressed files stored in a ROM only the computational efficiency of decompression is relevant. With the RESTART deletion heuristic, a special mark occurs in the sequence of pointers each time the dictionary is cleared out so that the decoder does not have to monitor the compression ratio. The positions of the special mark are detected by parallel prefix. Each subsequence <italic>q</italic><sub>1</sub> ⋯ <italic>q<sub>m</sub></italic> of pointers between two consecutive marks can be decoded in parallel but the pointers do not contain the information on the length of their targets and it has to be computed. The target of the pointer <italic>q<sub>i</sub></italic> in the subsequence is the concatenation of the target of the pointer in position <italic>q<sub>i</sub></italic> − <italic>α</italic> with the first character of the target of the pointer in position <italic>q<sub>i</sub></italic> − <italic>α</italic> + 1, where <italic>α</italic> is the alphabet cardinality. Then, in parallel for each <italic>i</italic>, link pointer <italic>q<sub>i</sub></italic> to the pointer in position <italic>q<sub>i</sub></italic> − <italic>α</italic>, if <italic>q<sub>i</sub></italic> &gt; <italic>α</italic>. Again, we obtain a forest where each tree is rooted in a pointer representing an alphabet character and the length <italic>l<sub>i</sub></italic> of the target of a pointer <italic>q<sub>i</sub></italic> is equal to the level of the pointer in the tree plus 1. It is known from [<xref ref-type="bibr" rid="b1-algorithms-04-00183">1</xref>] that the largest number of distinct factors whose concatenation forms a given string of length <italic>ℓ</italic> is O(<italic>ℓ</italic>/log <italic>ℓ</italic>). Since a factor of the LZW factorization of a string appears a number of times which is at most equal to the alphabet cardinality, it follows that <italic>m</italic> is O(<italic>ℓ</italic>/log <italic>ℓ</italic>) if <italic>ℓ</italic> is the length of the substring encoded by the subsequence <italic>q</italic><sub>1</sub> ⋯ <italic>q<sub>m</sub></italic>. Then, building such a forest takes O(<italic>k</italic>) time with O(<italic>n/k</italic>) processors on a shared memory parallel machine without writing and reading conflicts if <italic>k</italic> is Ω(log <italic>n</italic>). By means of the Euler tour technique, we can compute the trees of such forest and the level of each node in its own tree in O(<italic>k</italic>) time with O(<italic>n/k</italic>). Therefore, we can compute the lengths <italic>l</italic><sub>1</sub>, …, <italic>l<sub>m</sub></italic> of the targets. If <italic>s</italic><sub>1</sub>, …, <italic>s<sub>m</sub></italic> are the partial sums, the target of <italic>q<sub>i</sub></italic> is the substring over the positions <italic>s</italic><sub><italic>i</italic>−1</sub> + 1 ⋯ <italic>s<sub>i</sub></italic> of the output string. For each <italic>q<sub>i</sub></italic> which does not correspond to an alphabet character, define <italic>first</italic>(<italic>i</italic>) = <italic>s</italic><sub><italic>q<sub>i</sub></italic>−<italic>α</italic>−1</sub> + 1 and <italic>last</italic>(<italic>i</italic>) = <italic>s</italic><sub><italic>q<sub>i</sub></italic>−<italic>α</italic></sub> + 1. Since the target of the pointer <italic>q<sub>i</sub></italic> is the concatenation of the target of the pointer in position <italic>q<sub>i</sub></italic> − <italic>α</italic> with the first character of the target of the pointer in position <italic>q<sub>i</sub></italic> − <italic>α</italic> + 1, link the positions <italic>s</italic><sub><italic>i</italic>−1</sub> + 1 ⋯ <italic>s<sub>i</sub></italic> to the positions <italic>s</italic><sub><italic>first</italic>(<italic>i</italic>)</sub> ⋯ <italic>s</italic><sub><italic>last</italic>(<italic>i</italic>)</sub>, respectively. As in the sliding dictionary case, if the target of <italic>q<sub>i</sub></italic> is an alphabet character the corresponding position in the output string is the root of a tree in a forest and all the nodes in a tree correspond to positions of the decoded string where the character is the root. Since the number of children for each node is at most <italic>α</italic>, in O(<italic>k</italic>) time and O(<italic>n/k</italic>) processors we can store the forest in a doubly linked structure and decode by means of the Euler tour technique [<xref ref-type="bibr" rid="b9-algorithms-04-00183">9</xref>]. Las Vegas work-optimal parallel decoders for LZ1 and LZ2 compression were presented in [<xref ref-type="bibr" rid="b30-algorithms-04-00183">30</xref>,<xref ref-type="bibr" rid="b31-algorithms-04-00183">31</xref>] with a computational complexity independent from the dictionary size and the match length.</p></sec></sec>
<sec>
<label>5.</label>
<title>Lempel-Ziv Compression on a Distributed System</title>
<p>Distributed systems have two types of complexity, the interprocessor communication and the input-output mechanism. While the input/output issue is inherent to any parallel algorithm and has standard solutions, the communication cost of the computational phase after the distribution of the data among the processors and before the output of the final result is obviously algorithm-dependent. So, we need to limit the interprocessor communication and involve more local computation to design a practical algorithm. The simplest model for this phase is, of course, a simple array of processors with no interconnections and, therefore, no communication cost. We describe on such model for every integer <italic>k</italic> greater than 1 an O(<italic>kw</italic>) time, O(<italic>n/kw</italic>) processors distributed algorithm factorizing an input string <italic>S</italic> with a cost which approximates the cost of the LZSS factorization within the multiplicative factor (<italic>k</italic> + <italic>m</italic> − 1)/<italic>k</italic>, where <italic>n, m</italic> and <italic>w</italic> are the lengths of the input string, the longest factor and the window respectively [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>]. As far as LZW compression is concerned, if we use a RESTART deletion heuristic clearing out the dictionary every <italic>ℓ</italic> characters of the input string we can trivially parallelize the factorization process with an O(<italic>ℓ</italic>) <italic>time</italic>, O(<italic>n/ℓ</italic>) processors distributed algorithm. We also present on a tree architecture an algorithm which in time O(<italic>km</italic>) with O(<italic>n/km</italic>) processors is guaranteed to produce a factorization of <italic>S</italic> with a cost approximating the cost of the optimal factorization within the multiplicative factor (<italic>k</italic> + 1)/<italic>k</italic> [<xref ref-type="bibr" rid="b10-algorithms-04-00183">10</xref>,<xref ref-type="bibr" rid="b12-algorithms-04-00183">12</xref>]. These algorithms provide approximation schemes for the corresponding factorization problems since the multiplicative approximation factors converge to 1 when <italic>km</italic> and <italic>kw</italic> converge to <italic>ℓ</italic> and to <italic>n</italic>, respectively.</p>
<sec>
<label>5.1.</label>
<title>Sliding Window Compression on a Distributed System</title>
<p>We simply apply in parallel sliding window compression to blocks of length <italic>kw</italic>. It follows that the algorithm requires O(<italic>kw</italic>) time with <italic>n/kw</italic> processors and the multiplicative approximation factor is (<italic>k</italic> + <italic>m</italic> − 1))/<italic>k</italic> with respect to any parsing. In fact, the number of factors of an optimal (greedy) factorization on a block is at least <italic>kw/m</italic> while the number of factors of the factorization produced by the scheme is at most (<italic>k</italic> − 1)<italic>w/m</italic> + <italic>w</italic>. As shown in <xref ref-type="fig" rid="f2-algorithms-04-00183">Figure 2</xref>, the boundary might cut a factor (sequence of plus signs) and the length <italic>w</italic> of the initial full size window of the block (sequence of w's) is the upper bound to the factors produced by the scheme in it. Yet, the factor cut by the boundary might be followed by another factor (sequence of x's) which covers the remaining part of the initial window. If this second factor has a suffix to the right of the window, this suffix must be a factor of the sliding dictionary defined by it (dotted line) and the multiplicative approximation factor follows.</p>
<p>We obtain an approximation scheme which is suitable for a small scale system but due to its adaptiveness it works on a large scale parallel system when the file size is large. From a practical point of view, we can apply something like the gzip procedure to a small number of input data blocks achieving a satisfying degree of compression effectiveness and obtaining the expected speed-up on a real parallel machine. Making the order of magnitude of the block length greater than the one of the window length largely beats the worst case bound on realistic data. The window length is usually several thousands kilobytes. The compression tools of the Zip family, as the Unix command “gzip” for example, use a window size of at least 32 K. It follows that the block length in our parallel implementation should be about 300 K and the file size should be about one third of the number of processors in megabytes. An approach using a tree architecture slightly improves compression effectiveness [<xref ref-type="bibr" rid="b11-algorithms-04-00183">11</xref>]. However, the scalability of a parallel implementation of sliding window compression on a distributed system with low communication cost seems to guarantee robustness only on very large files. We show in the next subsection that LZW compression is scalable and robust on arbitrary files if implemented on a tree architecture [<xref ref-type="bibr" rid="b12-algorithms-04-00183">12</xref>].</p></sec>
<sec>
<label>5.2.</label>
<title>LZW Compression on a Distributed System</title>
<p>As mentioned at the beginning of this section, if we use a RESTART deletion heuristic clearing out the dictionary every <italic>ℓ</italic> characters of the input string we can trivially parallelize the factorization process with an O(<italic>ℓ</italic>) time, O(<italic>n/ℓ</italic>) processors distributed algorithm. LZW compression with the RESTART deletion heuristic was initially presented in [<xref ref-type="bibr" rid="b18-algorithms-04-00183">18</xref>] with a dictionary of size 2<sup>12</sup> and is employed by the Unix command “compress” with a dictionary of size 2<sup>16</sup>. Therefore, in order to have a satisfying compression effectiveness the distributed algorithm might work with blocks of length <italic>ℓ</italic> even greater than 300K on realistic data. After a dictionary is filled up for each block though, the factorization of the remaining suffix of the block can be approximated within the multiplicative factor (<italic>k</italic> + 1)/<italic>k</italic> in time O(<italic>km</italic>) with O(<italic>n/km</italic>) processors on a tree architecture. Every leaf processor stores a sub-block of length <italic>m</italic>(<italic>k</italic> + 2) and a copy of the dictionary which are broadcasted from some level of the tree where the first phase of the computation has been executed. Adjacent sub-blocks overlap on 2<italic>m</italic> characters. We call a <italic>boundary match</italic> a factor covering positions of two adjacent sub-blocks. We execute the following algorithm:
<list list-type="bullet">
<list-item>
<p>for each block, every processor but the one associated with the last sub-block computes the boundary match between its sub-block and the next one which ends furthest to the right;</p></list-item>
<list-item>
<p>each processor computes the optimal factorization from the beginning of the boundary match on the left boundary of its sub-block to the beginning of the boundary match on the right boundary.</p></list-item></list></p>
<p>Stopping the factorization of each sub-block at the beginning of the right boundary match might cause the making of a surplus factor, which determines the multiplicative approximation factor (<italic>k</italic> + 1)/<italic>k</italic> with respect to any factorization. In fact, as it is shown in <xref ref-type="fig" rid="f3-algorithms-04-00183">Figure 3</xref>, the factor in front of the right boundary match (sequence of x's) might be extended to be a boundary match itself (sequence of plus signs) and to cover the first position of the factor after the boundary (dotted line). In [<xref ref-type="bibr" rid="b10-algorithms-04-00183">10</xref>], it is shown experimentally that for <italic>k</italic> = 10 the compression ratio achieved by such factorization is about the same as the sequential one. Then, compression can be effective on a large scale system even if the size of the file is not large.</p></sec>
<sec>
<label>5.3.</label>
<title>Decompression on a Distributed System</title>
<p>To decode the compressed files on a distributed system, it is enough to use a special mark occurring in the sequence of pointers each time the coding of a block ends. The input phase distributes the subsequences of pointers coding each block among the processors. If the file is encoded by an LZ2 compressor implemented on a large scale tree architecture, a second special mark indicates for each block the end of the coding of a sub-block and the coding of each block is stored at the same level of the tree. The first sub-block for each block is decoded by one processor to learn the corresponding dictionary. Then, the subsequences of pointers coding the sub-blocks are broadcasted to the leaf processors with the corresponding dictionary.</p></sec></sec>
<sec>
<label>6.</label>
<title>Image Compression</title>
<p>The best lossless image compressors are enabled by arithmetic encoders based on the model driven method [<xref ref-type="bibr" rid="b32-algorithms-04-00183">32</xref>]. The <italic>model driven method</italic> consists of two distinct and independent phases: <italic>modeling</italic> [<xref ref-type="bibr" rid="b33-algorithms-04-00183">33</xref>] and <italic>coding</italic> [<xref ref-type="bibr" rid="b34-algorithms-04-00183">34</xref>]. Arithmetic encoders are the best model driven compressors both for binary images (JBIG) [<xref ref-type="bibr" rid="b35-algorithms-04-00183">35</xref>] and for grey scale and color images (CALIC) [<xref ref-type="bibr" rid="b36-algorithms-04-00183">36</xref>], but they are often ruled out because they are too complex. As far as the model driven method for grey scale and color image compression is concerned, the modeling phase consists of three components: the determination of the context of the next pixel, the prediction of the next pixel and a probabilistic model for the <italic>prediction residual</italic>, which is the value difference between the actual pixel and the predicted one. In the coding phase, the prediction residuals are encoded. The use of prediction residuals for grey scale and color image compression relies on the fact that most of the times there are minimal variations of color in the neighborhood of one pixel. LOCO-I (JPEG-LS) [<xref ref-type="bibr" rid="b37-algorithms-04-00183">37</xref>] is the current lossless standard in low-complexity applications and involves Golomb-Rice codes [<xref ref-type="bibr" rid="b38-algorithms-04-00183">38</xref>,<xref ref-type="bibr" rid="b39-algorithms-04-00183">39</xref>] rather than the arithmetic ones. A low-complexity application compressing 8x8 blocks of a grey-scale or color image by means of a header and a fixed-length code is PALIC [<xref ref-type="bibr" rid="b40-algorithms-04-00183">40</xref>] which can be implemented on an arbitrarily large scale system at no communication cost. As explained in [<xref ref-type="bibr" rid="b40-algorithms-04-00183">40</xref>], parallel implementations of LOCO-I would require more sophisticated architectures than a simple array of processors. PALIC achieves 80 percent of the compression obtained with LOCO-I and is an extremely local procedure which is able to achieve a satisfying degree of compression by working independently on different very small blocks. On the other hand, no perfectly scalable low-complexity binary image compressor has been designed so far on an array architecture with no interprocessor communication. BLOCK MATCHING [<xref ref-type="bibr" rid="b13-algorithms-04-00183">13</xref>,<xref ref-type="bibr" rid="b14-algorithms-04-00183">14</xref>] is the best low-complexity compressor for binary images and extends data compression via textual substitution to two-dimensional data by compressing sub-images rather than substrings [<xref ref-type="bibr" rid="b2-algorithms-04-00183">2</xref>,<xref ref-type="bibr" rid="b15-algorithms-04-00183">15</xref>], achieving 80 percent of the compression obtained with JBIG. However, it does not work locally since it applies a generalized LZ1-type method with an unrestricted window. Storer extended the LZ1 method to binary image lossless compression by means of a square block matching technique [<xref ref-type="bibr" rid="b13-algorithms-04-00183">13</xref>]. A slower but more effective binary image compressor employs rectangular matches [<xref ref-type="bibr" rid="b14-algorithms-04-00183">14</xref>] and it is more suitable for scalable parallel and distributed implementations [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>].</p>
<sec>
<label>6.1.</label>
<title>The Generalized LZ1-Type Method</title>
<p>The square matching compression procedure scans an <italic>m</italic> × <italic>m′</italic> image by a raster scan (the greedy matching technique could work with any other scan described in [<xref ref-type="bibr" rid="b14-algorithms-04-00183">14</xref>]). A 64K table with one position for each possible 4 × 4 subarray is the only data structure used. All-zero and all-one squares are handled differently. The encoding scheme is to precede each item with a flag field indicating whether there is a monochromatic square, a match, or raw data. When there is a match, the 4 × 4 subarray in the current position (<italic>i, j</italic>) is hashed to yield a pointer to a copy in some position (<italic>k, h</italic>). This pointer is used for the current greedy match and then replaced in the hash table by a pointer to the current position. The procedure for computing the largest square match takes O(<italic>M</italic>) time, where <italic>M</italic> is the size of the match. Obviously, this procedure can be used to compute the largest monochromatic square in a given position (<italic>i, j</italic>) as well. If the 4 × 4 subarray in position (<italic>i, j</italic>) is monochromatic, then we compute the largest monochromatic square in that position. Otherwise, we compute the largest match in the position provided by the hash table and update the table with the current position. If the subarray is not hashed to a pointer, then it is left uncompressed and added to the hash table with its current position. The positions covered by matches are skipped in the linear scan of the image. We wish to point out that besides the proper matches we call a match every square of the parsing of the image produced by the heuristic. We also call pointer the encoding of a match. Each pointer starts with a flag field indicating whether there is a monochromatic match (0 for the white ones and 10 for the black ones), a proper match (110) or a raw match (111). If we use rectangular matches, the pointer is more expensive in size since two fields for the dimension of proper or monochromatic matches are needed. However, the matches are larger and there is a gain in compression effectiveness. The procedure for finding the largest rectangular match is described in <xref ref-type="fig" rid="f4-algorithms-04-00183">Figure 4</xref>. We denote with <italic>p<sub>i, j</sub></italic> the pixel in position (<italic>i, j</italic>). At the first step, the procedure computes the longest possible width for a rectangle match in (<italic>i, j</italic>) with respect to the position (<italic>k, h</italic>). The rectangle 1 × <italic>l</italic> computed at the first step is the current rectangular match and the sizes of its sides are stored in <italic>side</italic>1 and <italic>side</italic>2. In order to check whether there is a better match than the current one, the longest one-dimensional match on the next row and column <italic>j</italic>, not exceeding the current width, is computed with respect to the row next to the current copy and to column <italic>h</italic>. Its length is stored in the temporary variable <italic>width</italic> and the temporary variable <italic>length</italic> is increased by one. If the rectangle <italic>R</italic> whose sides have size <italic>width</italic> and <italic>length</italic> is greater than the current match, the current match is replaced by <italic>R</italic>. We iterate this operation on each row until the area of the current match is greater or equal to the area of the longest feasible <italic>width</italic>-wide rectangle, since no further improvement would be possible at that point.</p>
<p>For example, in <xref ref-type="fig" rid="f5-algorithms-04-00183">Figure 5</xref> we apply the procedure to find the largest rectangular match between position (0, 0) and (6, 6). A one-dimensional match of width 6 is found at step 1. Then, at step 2 a better match is obtained which is 2 × 4. At step 3 and step 4 the current match is still 2 × 4 since the longest match on row 3 and 9 has width 2. At step 5, another match of width 2 provides a better rectangle match which is 5 × 2. At step 6, the procedure stops since the longest match has width 1 and the rectangle match can cover at most 7 rows. It follows that 5 × 2 is the greedy match since a rectangle of width 1 cannot have a larger area. Obviously, this procedure can be used for computing the largest monochromatic rectangle in a given position (<italic>i, j</italic>) as well. For typical bi-level images this scheme is extremely fast for square matches and there is no significant slowdown over simply reading and writing the image. On the other hand, the procedure for computing the largest rectangular match takes O(<italic>M</italic> log <italic>M</italic>) time. In fact, in the worst case a rectangle of size <italic>M</italic> could be detected on row <italic>i</italic>, a rectangle of size <italic>M</italic>/2 on row <italic>i</italic> + 1, a rectangle of size <italic>M</italic>/3 on row <italic>i</italic> + 2 and so on. Therefore, the running time of the compression heuristic is Ω(<italic>n</italic>) or Ω(<italic>n</italic> log <italic>M</italic>) for square or rectangular matches respectively, where <italic>n</italic> is the size of the image. The analysis of the running time of such generalized LZ1-type method involves a so called <italic>waste factor</italic>, which is the average number of matches in the parsing of the image covering the same pixel. It is conjectured by Storer that this ia always less than 2 on realistic image data. Therefore, the square and rectangular block matching heuristics have a running time equal to O(<italic>n</italic>) and O(<italic>n</italic> log <italic>M</italic>).</p></sec>
<sec>
<label>6.2.</label>
<title>The Implementation on a Parallel System</title>
<p>Compression and decompression parallel implementations are described, requiring O(<italic>α</italic> log<italic>M</italic>) time with <italic>O</italic>(<italic>n/α</italic>) processors for any integer square value <italic>α</italic> ∈ Ω(log <italic>n</italic>) on a PRAM EREW [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>]. We partition an <italic>m</italic> × <italic>m′</italic> image <italic>I</italic> in <italic>x</italic> × <italic>y</italic> rectangular areas, where <italic>x</italic> and <italic>y</italic> are Θ(<italic>α</italic><sup>1/2</sup>). In parallel for each area, one processor applies the sequential rectangular block matching algorithm so that in O(<italic>α</italic> log <italic>M</italic>) time each area is parsed into rectangles, some of which are monochromatic. In the theoretical context of unbounded parallelism, <italic>α</italic> can be arbitrarily small and before encoding we wish to compute larger monochromatic rectangles. The monochromatic rectangles are computed by merging adjacent monochromatic areas without considering those monochromatic matches properly contained in some area. We denote with <italic>A<sub>i, j</sub></italic> for 1 ≤ <italic>i</italic> ≤ ⌈<italic>m/x</italic>⌉ and 1 ≤ <italic>j</italic> ≤ ⌈<italic>m′/y</italic>⌉ the areas into which the image is partitioned. In parallel for 1 ≤ <italic>i</italic> ≤ ⌈<italic>m/x</italic>⌉, if <italic>i</italic> is odd, a processor merges areas <italic>A</italic><sub>2<italic>i</italic>−1, <italic>j</italic></sub> and <italic>A</italic><sub>2<italic>i, j</italic></sub> provided they are monochromatic and have the same color. The same is done horizontally for <italic>A</italic><sub><italic>i</italic>,2<italic>j</italic>−1</sub> and <italic>A</italic><sub><italic>i</italic>,2<italic>j</italic></sub>. At the <italic>k</italic>-th step, if areas <italic>A</italic><sub>(<italic>i</italic>−1)2<sup><italic>k</italic>−1</sup>+1,<italic>j</italic></sub>, <italic>A</italic><sub>(<italic>i</italic>−1)2<sup><italic>k</italic>−1</sup>+2,<italic>j</italic></sub>, ⋯ <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>,<italic>j</italic></sub>, with <italic>i</italic> odd, were merged, then they will merge with areas <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>+1,<italic>j</italic></sub>, <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>+2,<italic>j</italic></sub>, ⋯ <italic>A</italic><sub>(<italic>i</italic>+1)2<sup><italic>k</italic>−1</sup>,<italic>j</italic></sub>, if they are monochromatic with the same color. The same is done horizontally for <italic>A</italic><sub><italic>i</italic>,(<italic>j</italic>−1)2<sup><italic>k</italic>−1</sup>+1</sub>, <italic>A</italic><sub><italic>i</italic>(<italic>j</italic>−1)2<sup><italic>k</italic>−1</sup>+2</sub>, ⋯ <italic>A</italic><sub><italic>i</italic>,<italic>j</italic>2<sup><italic>k</italic>−1</sup></sub>, with <italic>j</italic> odd, and <italic>A</italic><sub><italic>i</italic>,<italic>j</italic>2<sup><italic>k</italic>−1</sup>+1</sub>, <italic>A</italic><sub><italic>i</italic>,<italic>j</italic>2<sup><italic>k</italic>−1</sup>+2</sub>, ⋯ <italic>A</italic><sub><italic>i</italic>,(<italic>j</italic>+1)2<sup><italic>k</italic>−1</sup></sub>. After O(log <italic>M</italic>) steps, the procedure is completed and each step takes O(<italic>α</italic>) time and O(<italic>n/α</italic>) processors since there is one processor for each area. Therefore, the image parsing phase is realized in O(<italic>α</italic> log <italic>M</italic>) time with O(<italic>n/α</italic>) processors on an exclusive read, exclusive write shared memory machine. In order to implement parallel decompression, we need to indicate the end of the encoding of a specific area. So, we change the encoding scheme by associating the flag field 1110 to the raw match so that 1111 could indicate the end of the sequence of pointers corresponding to a given area. Then, the flag field 1110 is followed by sixteen bits uncompressed, flag fields 0 and 10 by the width and the length of the rectangle while flag field 110 is also followed by the position of the matching copy. The values following the flag fields are represented by a fixed length code. Since some areas could be entirely covered by a monochromatic rectangle 1111 is followed by the index associated with the next area by the raster scan. The interested reader can see how the coding and decoding phase are designed in [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>].</p></sec>
<sec>
<label>6.3.</label>
<title>The Implementation on a Distributed System</title>
<p>An implementation on a small scale system with no interprocessor communication was realized since we were able to partition an image into up to a hundred areas and to apply the square block matching heuristic independently to each area with no relevant loss of compression effectiveness. In [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>] we obtained the expected speed-up on the compression and decompression times doubling up the number of processors of a 256 Intel Xeon 3.06 GHz processors machine (avogadro.cilea.it) from 1 to 32. Working only with monochromatic matches and using a variable length encoding for the pointer fields after the flag, we were even able to preserve the compression effectiveness on a large scale system with a thousand processor and no interprocessor communication [<xref ref-type="bibr" rid="b41-algorithms-04-00183">41</xref>]. To obtain perfect scalability, however, we implemented in [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>] the PRAM EREW procedure on a full binary tree architecture under some realistic assumptions on the image data as follows. We extend the <italic>m</italic> × <italic>m′</italic> image <italic>I</italic> with dummy rows and columns so that <italic>I</italic> is partitioned into <italic>x</italic> × <italic>y</italic> areas <italic>A<sub>i, j</sub></italic> for 1 ≤ <italic>i, j</italic> ≤ 2<italic><sup>h</sup></italic>, where <italic>x</italic> and <italic>y</italic> are Θ(<italic>α</italic><sup>1/2</sup>), <italic>n</italic> = <italic>mm′</italic> is the size of the image and <italic>h</italic> =min {<italic>k</italic> : 2<italic><sup>k</sup></italic> ≥ max(<italic>m/x, m′/y</italic>)}. We store these areas into the leaves of the tree according to a one-dimensional layout which allows an easy way of merging the monochromatic ones at the upper levels. Let <italic>μ</italic> = 2<italic><sup>h</sup></italic>. The number of leaves is 2<sup>2<italic>h</italic></sup> and the leaves are numbered from 1 to 2<sup>2<italic>h</italic></sup> from left to right. It follows that the tree has height 2<italic>h</italic>. Therefore, the height of the tree is O(log <italic>n</italic>) and the number of nodes is O(<italic>n/α</italic>). Such layout is described by the recursive procedure of <xref ref-type="fig" rid="f6-algorithms-04-00183">Figure 6</xref>. The initial value for <italic>i, j</italic> and <italic>ℓ</italic> is 1 and <italic>ℓ</italic> is a global variable.</p>
<p>In parallel for each area, each leaf processor applies the sequential parsing algorithm so that in O(<italic>α</italic> log <italic>M</italic>) time each area is parsed into rectangles, some of which are monochromatic. Again, before encoding we wish to compute larger monochromatic rectangles. After the compression heuristic has been executed on each area, we have to show how the procedure to compute larger monochromatic rectangles can be implemented on a full binary tree architecture with the same number of processors without slowing it down. This is possible by making some realistic assumptions. Let <italic>ℓ<sub>R</sub></italic> and <italic>w<sub>R</sub></italic> be the length and the width of a monochromatic match <italic>R</italic>, respectively. We define <italic>s<sub>R</sub></italic> = max {<italic>ℓ<sub>R</sub>, w<sub>R</sub></italic>}. We make a first assumption that the number of monochromatic matches <italic>R</italic> with <italic>s<sub>R</sub></italic> ≥ 2<italic><sup>k</sup></italic> ⌈log<sup>1/2</sup> <italic>n</italic>⌉ is O(<italic>n</italic>/(2<sup>2<italic>k</italic></sup> log <italic>n</italic>)) for 1 ≤ <italic>k</italic> ≤ <italic>h</italic>−1. While computing larger monochromatic rectangles, we store in each leaf the partial results on the monochromatic rectangles covering the corresponding area (it is enough to store for each rectangle the indices of the areas at the upper left and lower right corners). If <italic>i</italic> is odd, it follows from the procedure of <xref ref-type="fig" rid="f6-algorithms-04-00183">Figure 6</xref> that the processors storing areas <italic>A</italic><sub>2<italic>i</italic>−1,<italic>j</italic></sub> and <italic>A</italic><sub>2<italic>i,j</italic></sub> are siblings. Such processors merge <italic>A</italic><sub>2<italic>i</italic>−1,<italic>j</italic></sub> and <italic>A</italic><sub>2<italic>i,j</italic></sub> provided they are monochromatic and have the same color by broadcasting the information through their parent. It also follows from such procedure that the same can be done horizontally for <italic>A</italic><sub><italic>i</italic>,2<italic>j</italic>−1</sub> and <italic>A</italic><sub><italic>i</italic>,2<italic>j</italic></sub> by broadcasting the information through the processors at level 2<italic>h</italic> − 2. At the <italic>k</italic>-th step, if areas <italic>A</italic><sub>(<italic>i</italic>−1)2<sup><italic>k</italic>−1</sup>+1,<italic>j</italic></sub>, <italic>A</italic><sub>(<italic>i</italic>−1)2<sup><italic>k</italic>−1</sup>+2,<italic>j</italic></sub>, ⋯ <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>,<italic>j</italic></sub>, with <italic>i</italic> odd, were merged for <italic>w</italic><sub>1</sub> ≤ <italic>j</italic> ≤ <italic>w</italic><sub>2</sub>, the processor storing area <italic>A</italic><sub>(<italic>i</italic>−1)2<sup><italic>k</italic>−1</sup>+1,<italic>w</italic><sub>1</sub></sub> will broadcast to the processors storing the areas <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>+1,<italic>j</italic></sub>, <italic>A</italic><sub><italic>i</italic>2<sup><italic>k</italic>−1</sup>+2,<italic>j</italic></sub>, ⋯ <italic>A</italic><sub>(<italic>i</italic>+1)2<sup><italic>k</italic>−1</sup>,<italic>j</italic></sub> to merge with the above areas for <italic>w</italic><sub>1</sub> ≤ <italic>j</italic> ≤ <italic>w</italic><sub>2</sub>, if they are monochromatic with the same color. The broadcasting will involve processors up to level 2<italic>h</italic> − 2<italic>k</italic> + 1. The same is done horizontally, that is, if <italic>A</italic><sub><italic>i</italic>,(<italic>j</italic>−1)2<sup><italic>k</italic>−1</sup>+1</sub>, <italic>A</italic><sub><italic>i</italic>,(<italic>j</italic>− 1)2<sup><italic>k</italic>−1</sup>+2</sub>, ⋯ <italic>A</italic><sub><italic>i</italic>,<italic>j</italic>2<sup><italic>k</italic>−1</sup></sub>, with <italic>j</italic> odd, were merged for <italic>ℓ</italic><sub>1</sub> ≤ <italic>i</italic> ≤ <italic>ℓ</italic><sub>2</sub>, the processor storing area <italic>A</italic><sub><italic>ℓ</italic><sub>1</sub>,(<italic>j</italic>−1)2<sup><italic>k</italic>−1</sup>+1</sub> will broadcast to the processors storing the areas <italic>A</italic><sub><italic>i,j</italic>2<sup><italic>k</italic>−1</sup>+1</sub>, <italic>A</italic><sub><italic>i, j</italic>2<sup><italic>k</italic>−1</sup>+2</sub>, ⋯ <italic>A</italic><sub><italic>i</italic>,(<italic>j</italic>+1)2<sup><italic>k</italic>−1</sup></sub> to merge with the above areas for <italic>ℓ</italic><sub>1</sub> ≤ <italic>i</italic> ≤ <italic>ℓ</italic><sub>2</sub>, if they are monochromatic with the same color. The broadcasting will involve processors up to level 2<italic>h</italic> − 2<italic>k</italic>. After O(log <italic>M</italic>) steps, the procedure is completed. If the waste factor is less than 2, as conjectured in [<xref ref-type="bibr" rid="b14-algorithms-04-00183">14</xref>], we can make a second assumption that each pixel is covered by a constant small number of monochromatic matches. It follows from this second assumption that the information about the monochromatic matches is distributed among the processors at the same level in a way very close to uniform. Then, it follows from the first assumption that the amount of information each processor of the tree must broadcast is constant. Therefore, each step takes O(<italic>α</italic>) time and the image parsing phase is realized with O(<italic>α</italic> log <italic>M</italic>) time and O(<italic>n/α</italic>) processors. The sequence of pointers is trivially produced by the processors which are leaves of the tree. For the monochromatic rectangles, the pointer is written in the leaf storing the area at the upper left corner. Differently from the shared memory machine decoder, the order of the pointers is the one of the leaves. As previously mentioned, some areas could be entirely covered by a monochromatic match and the subsequence of pointers corresponding to a given area is ended with 1111 followed by the index of the leaf storing the next area to decode. We define a variable for each leaf. This variable is set to 1 if the leaf stores at least a pointer, 0 otherwise. Then, the index of the next area to decode is computed for each leaf by parallel suffix computation. Moreover, with the possibility of a parallel output the sequence can be put together by parallel prefix. This is, obviously, realized in O(<italic>α</italic>) time with O(<italic>n/α</italic>) processors. The interested reader can see how the decoding phase is implemented with the same complexity in [<xref ref-type="bibr" rid="b8-algorithms-04-00183">8</xref>].</p></sec></sec>
<sec sec-type="conclusions">
<label>7.</label>
<title>Conclusions</title>
<p>In this paper, we presented a survey on parallel and distributed algorithms for Lempel–Ziv data compression. This field has developed in the last twenty years from a theoretical approach concerning parallel time complexity with no memory constraints to the practical goal of designing distributed algorithms with bounded memory and low communication cost. An extension to image compression has also been realized. As future work, we would like to implement distributed algorithms for Lempel–Ziv text compression and decompression on a parallel machine. As far as image compression is concerned, we wish to experiment with more processors on a graphical processing unit.</p></sec></body>
<back>
<sec sec-type="display-objects">
<title>Figures</title>
<fig id="f1-algorithms-04-00183" position="float">
<label>Figure 1.</label>
<caption>
<p>The semi-greedy factorization procedure.</p></caption>
<graphic xlink:href="algorithms-04-00183f1.gif"/></fig>
<fig id="f2-algorithms-04-00183" position="float">
<label>Figure 2.</label>
<caption>
<p>The making of the surplus factors.</p></caption>
<graphic xlink:href="algorithms-04-00183f2.gif"/></fig>
<fig id="f3-algorithms-04-00183" position="float">
<label>Figure 3.</label>
<caption>
<p>The making of a surplus factor.</p></caption>
<graphic xlink:href="algorithms-04-00183f3.gif"/></fig>
<fig id="f4-algorithms-04-00183" position="float">
<label>Figure 4.</label>
<caption>
<p>Computing the largest rectangle match in (<italic>i, j</italic>) and (<italic>k, h</italic>).</p></caption>
<graphic xlink:href="algorithms-04-00183f4.gif"/></fig>
<fig id="f5-algorithms-04-00183" position="float">
<label>Figure 5.</label>
<caption>
<p>The largest match in (0,0) and (6,6) is computed at step 5.</p></caption>
<graphic xlink:href="algorithms-04-00183f5.gif"/></fig>
<fig id="f6-algorithms-04-00183" position="float">
<label>Figure 6.</label>
<caption>
<p>Storing the image into the leaves of the tree.</p></caption>
<graphic xlink:href="algorithms-04-00183f6.gif"/></fig></sec>
<ref-list>
<title>References</title>
<ref id="b1-algorithms-04-00183"><label>1.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Lempel</surname><given-names>A.</given-names></name><name><surname>Ziv</surname><given-names>J.</given-names></name></person-group><article-title>On the Complexity of Finite Sequences</article-title><source>IEEE Trans. Inf. Theory</source><year>1976</year><volume>22</volume><fpage>75</fpage><lpage>81</lpage><pub-id pub-id-type="doi">10.1109/TIT.1976.1055501</pub-id></citation></ref>
<ref id="b2-algorithms-04-00183"><label>2.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Lempel</surname><given-names>A.</given-names></name><name><surname>Ziv</surname><given-names>J.</given-names></name></person-group><article-title>A Universal Algorithm for Sequential Data Compression</article-title><source>IEEE Trans. Inf. Theory</source><year>1977</year><volume>23</volume><fpage>337</fpage><lpage>343</lpage><pub-id pub-id-type="doi">10.1109/TIT.1977.1055714</pub-id></citation></ref>
<ref id="b3-algorithms-04-00183"><label>3.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Ziv</surname><given-names>J.</given-names></name><name><surname>Lempel</surname><given-names>A.</given-names></name></person-group><article-title>Compression of Individual Sequences via Variable-Rate Coding</article-title><source>IEEE Trans. Inf. Theory</source><year>1978</year><volume>24</volume><fpage>530</fpage><lpage>536</lpage><pub-id pub-id-type="doi">10.1109/TIT.1978.1055934</pub-id></citation></ref>
<ref id="b4-algorithms-04-00183"><label>4.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Crochemore</surname><given-names>M.</given-names></name><name><surname>Rytter</surname><given-names>W.</given-names></name></person-group><article-title>Efficient Parallel Algorithms to Test Square-freeness and Factorize Strings</article-title><source>Inf. Proc. Lett.</source><year>1991</year><volume>38</volume><fpage>57</fpage><lpage>60</lpage><pub-id pub-id-type="doi">10.1016/0020-0190(91)90223-5</pub-id></citation></ref>
<ref id="b5-algorithms-04-00183"><label>5.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>Parallelism and Dictionary-Based Data Compression</article-title><source>Inf. Sci.</source><year>2001</year><volume>135</volume><fpage>43</fpage><lpage>56</lpage><pub-id pub-id-type="doi">10.1016/S0020-0255(01)00100-1</pub-id></citation></ref>
<ref id="b6-algorithms-04-00183"><label>6.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>P-complete Problems in Data Compression</article-title><source>Theor. Comput. Sci.</source><year>1994</year><volume>127</volume><fpage>181</fpage><lpage>186</lpage><pub-id pub-id-type="doi">10.1016/0304-3975(94)90106-6</pub-id></citation></ref>
<ref id="b7-algorithms-04-00183"><label>7.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Silvestri</surname><given-names>R.</given-names></name></person-group><article-title>Bounded Size Dictionary Compression: SC<italic><sup>k</sup></italic>-Completeness and NC Algorithms</article-title><source>Inf. Comput.</source><year>2003</year><volume>180</volume><fpage>101</fpage><lpage>112</lpage><pub-id pub-id-type="doi">10.1016/S0890-5401(02)00013-5</pub-id></citation></ref>
<ref id="b8-algorithms-04-00183"><label>8.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cinque</surname><given-names>L.</given-names></name><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Lombardi</surname><given-names>L.</given-names></name></person-group><article-title>Scalability and Communication in Parallel Low-Complexity Lossless Compression</article-title><source>Math. Comput. Sci.</source><year>2010</year><volume>3</volume><fpage>391</fpage><lpage>406</lpage><pub-id pub-id-type="doi">10.1007/s11786-010-0034-5</pub-id></citation></ref>
<ref id="b9-algorithms-04-00183"><label>9.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>Almost Work-Optimal PRAM EREW Decoders of LZ-Compressed Text</article-title><source>Parallel Proc. Lett.</source><year>2004</year><volume>14</volume><fpage>351</fpage><lpage>359</lpage><pub-id pub-id-type="doi">10.1142/S0129626404001933</pub-id></citation></ref>
<ref id="b10-algorithms-04-00183"><label>10.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Belinskaya</surname><given-names>D.</given-names></name><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Storer</surname><given-names>J.A.</given-names></name></person-group><article-title>Near Optimal Compression with respect to a Static Dictionary on a Practical Massively Parallel Architecture</article-title><conf-name>Proceedings IEEE Data Compression Conference 1995</conf-name><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Washington, DC, USA</publisher-loc><year>1995</year><fpage>172</fpage><lpage>181</lpage></citation></ref>
<ref id="b11-algorithms-04-00183"><label>11.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Klein</surname><given-names>S.T.</given-names></name><name><surname>Wiseman</surname><given-names>Y.</given-names></name></person-group><article-title>Parallel Lempel-Ziv Coding</article-title><source>Discrete Appl. Math.</source><year>2005</year><volume>146</volume><fpage>180</fpage><lpage>191</lpage><pub-id pub-id-type="doi">10.1016/j.dam.2004.04.013</pub-id></citation></ref>
<ref id="b12-algorithms-04-00183"><label>12.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>LZW <italic>versus</italic> Sliding window Compression on a Distributed System: Robustness and Communication</article-title><comment>Unpublished work</comment><year>2011</year></citation></ref>
<ref id="b13-algorithms-04-00183"><label>13.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Storer</surname><given-names>J.A.</given-names></name></person-group><article-title>Lossless Image Compression using Generalized LZ1-Type Methods</article-title><conf-name>Proceedings IEEE Data Compression Conference 1996</conf-name><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Washington, DC, USA</publisher-loc><year>1996</year><fpage>290</fpage><lpage>299</lpage></citation></ref>
<ref id="b14-algorithms-04-00183"><label>14.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Storer</surname><given-names>J.A.</given-names></name><name><surname>Helfgott</surname><given-names>H.</given-names></name></person-group><article-title>Lossless Image Compression by Block Matching</article-title><source>Comput. J.</source><year>1997</year><volume>40</volume><fpage>137</fpage><lpage>145</lpage><pub-id pub-id-type="doi">10.1093/comjnl/40.2_and_3.137</pub-id></citation></ref>
<ref id="b15-algorithms-04-00183"><label>15.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Storer</surname><given-names>J.A.</given-names></name><name><surname>Szimansky</surname><given-names>T.G.</given-names></name></person-group><article-title>Data Compression via Textual Substitution</article-title><source>J. ACM</source><year>1982</year><volume>24</volume><fpage>928</fpage><lpage>951</lpage></citation></ref>
<ref id="b16-algorithms-04-00183"><label>16.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Rodeh</surname><given-names>M.</given-names></name><name><surname>Pratt</surname><given-names>V.R.</given-names></name><name><surname>Even</surname><given-names>S.</given-names></name></person-group><article-title>Linear Algorithms for Compression via String Matching</article-title><source>J. ACM</source><year>1980</year><volume>28</volume><fpage>16</fpage><lpage>24</lpage></citation></ref>
<ref id="b17-algorithms-04-00183"><label>17.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Mc Creight</surname><given-names>E.M.</given-names></name></person-group><article-title>A Space-Economical Suffix Tree Construction Algorithm</article-title><source>J. ACM</source><year>1976</year><volume>23</volume><fpage>262</fpage><lpage>272</lpage><pub-id pub-id-type="doi">10.1145/321941.321946</pub-id></citation></ref>
<ref id="b18-algorithms-04-00183"><label>18.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Welch</surname><given-names>T.A.</given-names></name></person-group><article-title>A Technique for High-Performance Data Compression</article-title><source>IEEE Comput.</source><year>1984</year><volume>17</volume><fpage>8</fpage><lpage>19</lpage></citation></ref>
<ref id="b19-algorithms-04-00183"><label>19.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Storer</surname><given-names>J.A.</given-names></name></person-group><article-title>On-Line <italic>versus</italic> Off-line Computation for Dynamic Text Compression</article-title><source>Inf. Proc. Lett.</source><year>1996</year><volume>59</volume><fpage>169</fpage><lpage>174</lpage><pub-id pub-id-type="doi">10.1016/0020-0190(96)00068-3</pub-id></citation></ref>
<ref id="b20-algorithms-04-00183"><label>20.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Silvestri</surname><given-names>R.</given-names></name></person-group><article-title>A Worst Case Analisys of the LZ2 Compression Algorithm</article-title><source>Inf. Comput.</source><year>1997</year><volume>139</volume><fpage>258</fpage><lpage>268</lpage><pub-id pub-id-type="doi">10.1006/inco.1997.2668</pub-id></citation></ref>
<ref id="b21-algorithms-04-00183"><label>21.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Storer</surname><given-names>J.A.</given-names></name></person-group><article-title>Data Compression: Methods and Theory</article-title><source>Comput. Sci. Press</source><year>1988</year><fpage>413</fpage></citation></ref>
<ref id="b22-algorithms-04-00183"><label>22.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Fiala</surname><given-names>E.R.</given-names></name><name><surname>Green</surname><given-names>D.H.</given-names></name></person-group><article-title>Data Compression with Finite Windows</article-title><source>Commun. ACM</source><year>1988</year><volume>32</volume><fpage>490</fpage><lpage>505</lpage></citation></ref>
<ref id="b23-algorithms-04-00183"><label>23.</label><citation citation-type="patent"><person-group person-group-type="author"><name><surname>Waterworth</surname><given-names>J.R.</given-names></name></person-group><article-title>Data Compression System</article-title><patent>U.S. Patent 4,701,745</patent><year>1987</year></citation></ref>
<ref id="b24-algorithms-04-00183"><label>24.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Brent</surname><given-names>R.P.</given-names></name></person-group><article-title>A Linear Algorithm for Data Compression</article-title><source>Aust. Comput. J.</source><year>1987</year><volume>19</volume><fpage>64</fpage><lpage>68</lpage></citation></ref>
<ref id="b25-algorithms-04-00183"><label>25.</label><citation citation-type="patent"><person-group person-group-type="author"><name><surname>Whiting</surname><given-names>D.A.</given-names></name><name><surname>George</surname><given-names>G.A.</given-names></name><name><surname>Ivey</surname><given-names>G.E.</given-names></name></person-group><article-title>Data Compression Apparatus and Method</article-title><patent>U.S. Patent 5,016,009</patent><year>1991</year></citation></ref>
<ref id="b26-algorithms-04-00183"><label>26.</label><citation citation-type="web"><person-group person-group-type="author"><name><surname>Gailly</surname><given-names>J.</given-names></name><name><surname>Adler</surname><given-names>M.</given-names></name></person-group><article-title>The Gzip homepage</article-title><comment>Available online: <ext-link xlink:href="http://www.gzip.org" ext-link-type="uri">http://www.gzip.org</ext-link> (accessed on 6 September 2011)</comment></citation></ref>
<ref id="b27-algorithms-04-00183"><label>27.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Hartman</surname><given-names>A.</given-names></name><name><surname>Rodeh</surname><given-names>M.</given-names></name></person-group><article-title>Optimal Parsing of Strings</article-title><source>Comb. Algorithms Words</source><person-group person-group-type="editor"><name><surname>Apostolico</surname><given-names>A.</given-names></name><name><surname>Galil</surname><given-names>Z.</given-names></name></person-group><publisher-name>Springer</publisher-name><publisher-loc>Berlin, Germany</publisher-loc><year>1985</year><fpage>155</fpage><lpage>167</lpage></citation></ref>
<ref id="b28-algorithms-04-00183"><label>28.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Crochemore</surname><given-names>M.</given-names></name><name><surname>Rytter</surname><given-names>W.</given-names></name></person-group><source>Jewels of Stringology</source><publisher-name>World Scitific Publishing Co.</publisher-name><publisher-loc>Singapore</publisher-loc><year>2003</year></citation></ref>
<ref id="b29-algorithms-04-00183"><label>29.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>Bounded Size Dictionary Compression: Relaxing the LRU Deletion Heuristic</article-title><source>Int. J. Found. Comput. Sci.</source><year>2006</year><volume>17</volume><fpage>1273</fpage><lpage>1280</lpage><pub-id pub-id-type="doi">10.1142/S0129054106004406</pub-id></citation></ref>
<ref id="b30-algorithms-04-00183"><label>30.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Farach</surname><given-names>M.</given-names></name><name><surname>Muthikrishnan</surname><given-names>S.</given-names></name></person-group><article-title>Optimal Parallel Dictionary Matching and Compression</article-title><source>Proc. SPAA</source><year>1995</year><fpage>244</fpage><lpage>253</lpage></citation></ref>
<ref id="b31-algorithms-04-00183"><label>31.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>De Agostino</surname><given-names>S.</given-names></name></person-group><article-title>Work-Optimal Parallel Decoders for LZ2 Data Compression</article-title><conf-name>Proceedings IEEE Data Compression Conference 2000</conf-name><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Washington, DC, USA</publisher-loc><year>2000</year><fpage>393</fpage><lpage>399</lpage></citation></ref>
<ref id="b32-algorithms-04-00183"><label>32.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Bell</surname><given-names>T.C.</given-names></name><name><surname>Cleary</surname><given-names>J.G.</given-names></name><name><surname>Witten</surname><given-names>I.H.</given-names></name></person-group><source>Text Compression</source><publisher-name>Prentice Hall</publisher-name><year>1990</year></citation></ref>
<ref id="b33-algorithms-04-00183"><label>33.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Rissanen</surname><given-names>J.</given-names></name><name><surname>Langdon</surname><given-names>G.G.</given-names></name></person-group><article-title>Universal Modeling and Coding</article-title><source>IEEE Trans. Inf. Theory</source><year>1981</year><volume>27</volume><fpage>12</fpage><lpage>23</lpage><pub-id pub-id-type="doi">10.1109/TIT.1981.1056282</pub-id></citation></ref>
<ref id="b34-algorithms-04-00183"><label>34.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Rissanen</surname><given-names>J.</given-names></name></person-group><article-title>Generalized Kraft Inequality and Arithmetic Coding</article-title><source>IBM J. Res. Dev.</source><year>1976</year><volume>20</volume><fpage>198</fpage><lpage>203</lpage><pub-id pub-id-type="doi">10.1147/rd.203.0198</pub-id></citation></ref>
<ref id="b35-algorithms-04-00183"><label>35.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Howard</surname><given-names>P.G.</given-names></name><name><surname>Kossentini</surname><given-names>F.</given-names></name><name><surname>Martinis</surname><given-names>B.</given-names></name><name><surname>Forchammer</surname><given-names>S.</given-names></name><name><surname>Rucklidge</surname><given-names>W.J.</given-names></name><name><surname>Ono</surname><given-names>F.</given-names></name></person-group><article-title>The Emerging JBIG2 Standard</article-title><source>IEEE Trans. Circuits Syst. Video Technol.</source><year>1998</year><volume>8</volume><fpage>838</fpage><lpage>848</lpage><pub-id pub-id-type="doi">10.1109/76.735380</pub-id></citation></ref>
<ref id="b36-algorithms-04-00183"><label>36.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Wu</surname><given-names>X.</given-names></name><name><surname>Memon</surname><given-names>N.D.</given-names></name></person-group><article-title>Context-Based, Adaptive, Lossless Image Coding</article-title><source>IEEE Trans. Commun.</source><year>1997</year><volume>45</volume><fpage>437</fpage><lpage>444</lpage><pub-id pub-id-type="doi">10.1109/26.585919</pub-id></citation></ref>
<ref id="b37-algorithms-04-00183"><label>37.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Weimberger</surname><given-names>M.J.</given-names></name><name><surname>Seroussi</surname><given-names>G.</given-names></name><name><surname>Sapiro</surname><given-names>G.</given-names></name></person-group><article-title>LOCO-I: A Low Complexity, Context Based, Lossless Image Compression Algorithm</article-title><conf-name>Proceedings IEEE Data Compression Conference 1996</conf-name><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Washington, DC, USA</publisher-loc><year>1996</year><fpage>140</fpage><lpage>149</lpage></citation></ref>
<ref id="b38-algorithms-04-00183"><label>38.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Golomb</surname><given-names>S.W.</given-names></name></person-group><article-title>Run-Length Encodings</article-title><source>IEEE Trans. Inf. Theory</source><year>1996</year><volume>12</volume><fpage>399</fpage><lpage>401</lpage></citation></ref>
<ref id="b39-algorithms-04-00183"><label>39.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Rice</surname><given-names>R.F.</given-names></name></person-group><source>Some Practical Universal Noiseless Coding Technique—part I</source><comment>Technical Report JPL-79-22</comment><publisher-name>Jet Propulsion Laboratory</publisher-name><publisher-loc>Pasadena, CA, USA</publisher-loc><year>1979</year></citation></ref>
<ref id="b40-algorithms-04-00183"><label>40.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cinque</surname><given-names>L.</given-names></name><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Liberati</surname><given-names>F.</given-names></name><name><surname>Westgeest</surname><given-names>B.</given-names></name></person-group><article-title>A Simple Lossless Compression Heuristic for Grey Scale Images</article-title><source>Int. J. Found. Comput. Sci.</source><year>2005</year><volume>16</volume><fpage>1111</fpage><lpage>1119</lpage><pub-id pub-id-type="doi">10.1142/S0129054105003686</pub-id></citation></ref>
<ref id="b41-algorithms-04-00183"><label>41.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cinque</surname><given-names>L.</given-names></name><name><surname>De Agostino</surname><given-names>S.</given-names></name><name><surname>Lombardi</surname><given-names>L.</given-names></name></person-group><article-title>Binary Image Compression via Monochromatic Pattern Substitution: Effectiveness and Scalability</article-title><source>Proc. Prague Stringol. Conf.</source><year>2010</year><fpage>103</fpage><lpage>115</lpage></citation></ref></ref-list></back></article>
