# Improving Lossless Image Compression with Contextual Memory
## 5 Experimental Results
### Discussion on the Results  
The reason for choosing these benchmarks is that they are publicly available and that they are provided without conflicts of interest. They contain images of various types such as artificially generated, edited, photographs, and scans. This makes them suitable for publications and there are published papers using them, such as [11]. We present our results on all the images in the datasets in order to prove that we did not tune the algorithm to a selected few. The images are compressed separately (as in _not a solid archive_) to prevent reusing correlations.  
The PAQ8 family of algorithms was designed to achieve good compression ratios at the expense of a long compression time and a large memory footprint. Even though there are some optimizations applied, the running time will be much larger than some of the other algorithms. The contextual memory algorithm also does not contain too many speed optimizations in its provided form. Therefore, a running time comparison is out of the scope of this paper, but to give the reader a sense of the execution time scale, we provide a relative comparison on the image _lena2_ from the Waterloo gray test set (see Table 5). The algorithms where run on the same processing architecture.  
The compression running time does not equal the decompression running time for all the algorithms. For instance, the MRP algorithm is highly asymmetric due to its multiple pass optimizations, decompression of the same image taking only 0.6 seconds. The timings were measured using the x64 version of the Timer 14.00 tool created by [PERSON] and available for public domain on the 7-cpu website [34].  
Memory requirements depend on the compression parameters. PAQ8 PX reports using 2493 MB of memory for command line parameter -8a. The contextual memory algorithm adds to this depending on the parameters set. We can estimate the memory consumption of the current implementation  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Set** & **MRP** & **cmix v14f** & **GraLIC** & **Paq8 px167** &
\begin{tabular}{c} **Paq8 px167+CM** \\ **(proposed)** \\ \end{tabular} \\ \hline
**bloods** & 2,1670 & 2,1600 & 2,3200 & 2,1308 & **2,1304** \\
**cathether8** & **1,535** & 1,5351 & 1,6580 & 1,5382 & 1,5380 \\
**fetus** & 4,0650 & 3,9730 & 4,1310 & 3,8236 & **3,8225** \\
**shoulder** & **2,866** & 2,9080 & 3,1130 & 2,8607 & 2,8676 \\
**sigma8** & 2,6870 & 2,6290 & 2,7200 & 2,6266 & **2,6263** \\ \hline
**Average** & 2,6640 & 2,6410 & 2,7880 & 2,5978 & **2,5970** \\ \hline \hline \end{tabular}
\end{table}
Table 4: Squeezechart 8 bpp grayscale.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Image** & **MRP** & **JPEG 2000** & **JPEG-LS** & **GraLIC** & **Paq8 px167** &
\begin{tabular}{c} **Paq8 px167+CM** \\ **(proposed)** \\ \end{tabular} \\ \hline
**lena2** & 258 s & 0.04 s & 0.02 s & 0.25 s & 12 s & 24 s \\ \hline \hline \end{tabular}
\end{table}
Table 5: Compression running time comparison on image lena2 (expressed in seconds).  
by multiplying the number of rays by ray length, table size (\(2^{\text{memory size}}\)), 4 (no quantization plus 3 quantized derivatives), 3 (number of bytes per memory location). For ray length 5 and memory size 20, we estimate that it adds another 240 MB of memory.  
The results in Tables 1-3 for all the compressors, except Paq8 px167 and the proposed method, were taken directly from [11], and the results in Table 4 were taken from the PAQ8 PX thread [21]. The results missing in the paper for GraLIC and the results for Paq8 px167 and the proposed method are computed using a tool we created for this purpose, available at [35]. The tool does not exclude the file headers when computing the bits per pixel.