You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/thesis/src/analyse.tex
+21-2Lines changed: 21 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -61,14 +61,16 @@ \section{Initial Findings}
61
61
\par{
62
62
However after some analysis of the corpus data, it was shown that most runs had a value of one and almost no runs larger that 4 occurred, which lead to the conclusion, two bit for the run count should be plenty, which is also shown in Table \ref{tab:t5runlengtheval}.
63
63
Even with a run size of just two bits, there is still a increase in size of about 9\% and uses 8.74 $\frac{bits}{symbol}$. This is still useful as a kind of a base line.
64
+
Interestingly the binary implementation performs better on 2 bits per RLE number (4 \% increase in size) than the byte implementation (9 \% increase in size) but also worse with a higher amount of bits per run, where it expands the data to more than triple in size. It is unclear which kind of implementation will profit most of preprocessing, so both will be further analyzed.
64
65
}
65
66
66
67
\par{
67
-
Interestingly the binary implementation performs better on 2 bits per RLE number (4 \% increase in size) than the byte implementation (9 \% increase in size) but also worse with a higher amount of bits per run, where it expands the data to more than triple in size. It is unclear which kind of implementation will profit most of preprocessing, so both will be further analyzed.
68
+
If we take a more detailed look, we can see that while most files expand with larger RLE numbers, some files have their minimum size when encoded with higher RLE numbers of up to 7 bit. With the simple binary based RLE, almost all files of the Calgary Corpus expand linear related to the amount of bits used for the encoding. The file \textit{pic} decreases in size until 7 bits per RLE number used to a sizes of just $19.5\%$ of its original size with only $1.56\:\frac{bits}{symbol}$ while the other files just doubled or even tripled in size. Using the byte wise operating RLE we see a similar result but not as decent with $27.2\%$ of its original size using $2.17\:\frac{bits}{symbol}$ using 6 bits per run. The benefit of the byte wise RLE is the better worst case performance of $1.5$ up to $1.7$ times the original size.
Instead of performing compute intense operation on the data, we could also interpret the data in a different way and apply the original run length encoding on binary data. By reading the data in chunks of a fixed size, it is possible to read all most significant bits of all bytes, then the second most significant bits of all bytes and so on. This interpretation results in longer runs as shown in the example below.
92
94
}
93
95
96
+
TODO: example
94
97
95
98
\par{
99
+
It is clear that simply a different way of reading the input does not compress the actual data, instead it enables a better application of existing compression. Without any further action, no performance improvements will be made.
100
+
}
101
+
102
+
\subsection{Byte remapping}
103
+
\par{
104
+
One idea might be a dynamic byte remapping as the input data is read in parts. Some sections have more specific characters or bytes than others, or this idea can be applied to the whole file. This way the values are not alternating in the whole range of 0 to 255 but rather in a smaller subset and the most frequent ones should be mapped to the smallest values.
105
+
}
96
106
107
+
TODO: Example
108
+
109
+
\par{
110
+
111
+
}
112
+
113
+
\subsection{Combined approaches}
114
+
\par{
115
+
The idea of combining different compression methods into a superior method is not new and was also performed on RLE as mentioned in Section \ref{ch:Principlesofcompression:sec:RunLengthEncoding:subSec:History}. While the idea of encoding the RLE numbers with Huffman codes is already known and analyzed well, the vertical byte reading enables new approaches, even more in combination with the idea of byte remapping.
Copy file name to clipboardExpand all lines: doc/thesis/src/grundlagen.tex
+9-2Lines changed: 9 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -5,8 +5,8 @@
5
5
\chapter{Principles of compression}
6
6
\label{ch:Principlesofcompression}
7
7
%% ==============================
8
-
9
-
To understand compression, one first has to understand some basic principles of information theory like Entropy and different approaches to compress different types of data with different encoding and entropy. I will also show the key differences between probability coding and dictionary coding and a few comments on lossy compression.
8
+
\par{
9
+
The basic idea of compression is to remove redundancy in data. Compression can be broken down into two broad categories: Lossless and lossy compression. Lossless compression makes it possible to reproduce the original data exactly while lossy compression allows the some degradation in the encoded data to gain even higher compression at the cost of some of the original information. To understand compression, one first has to understand some basic principles of information theory like Entropy and different approaches to compress different types of data with different encoding. We will also show the key differences between probability coding and dictionary coding.}
The ITU-T T4 (Group 3) standard for Facsimile (fax) machines \cite{ITU} is still in force for all devices used over regular phone lines. Each transmission sends a black and white image, where each pixel is called a \textit{pel} and with a horizontal resolution of $8.05\:\frac{pels}{mm}$ and the vertical resolution depending on the mode. To encode each sequence of black and white pixels, the T4 standard uses RLE to encode each sequence of black and white pixels and since there are only two values, only the run length itself has to be encoded. It is assumed that the first run is always a white run, so there is a dummy white pel at the beginning of each sequence. For example, the sequence $bbbbwwbbbbb$ can be encoded as 1,4,2,5 with the leading white dummy pixel.
103
104
}
@@ -136,6 +137,12 @@ \subsection{Limitations}
136
137
\par{
137
138
As mentioned in the Section \ref{ch:Introduction:sec:Problemstatement}, run length encoding is rarely used for regular text or continuous tone images because its potentially increase in size, due to non repetitive characters or bytes. To reduce this problem there are several approaches known, partly implemented and used some of which will be addressed like a Burrows-Wheeler-Transformation.
138
139
}
140
+
141
+
\subsection{Run Length Encoding today}
142
+
\par{
143
+
While it is still in use by fax transmission or other highly specific tasks, it is mostly used in combination with other approaches.
0 commit comments