Browse Source

git-svn-id: http://newslabx.csie.ntu.edu.tw/svn/Ginger@7 5747cdd2-2146-426f-b2b0-0570f90b98ed

master
Hobe 7 years ago
parent
commit
1446b17db0
12 changed files with 124 additions and 80 deletions
  1. +1
    -1
      trunk/00Abstract.tex
  2. +3
    -3
      trunk/01Introduction.tex
  3. +7
    -7
      trunk/02Background.tex
  4. +45
    -19
      trunk/03Design.tex
  5. +12
    -10
      trunk/04Evaluation.tex
  6. +1
    -1
      trunk/05Conclusion.tex
  7. +14
    -12
      trunk/Main.aux
  8. +40
    -26
      trunk/Main.log
  9. BIN
      trunk/Main.pdf
  10. BIN
      trunk/Main.synctex.gz
  11. +1
    -1
      trunk/Main.tex
  12. BIN
      trunk/figures/computeTime.pdf

+ 1
- 1
trunk/00Abstract.tex View File

@ -1,5 +1,5 @@
\begin{abstract}
In a IoT environment, many devices will periodically transmit data. However, most of the data are redundant, but sensor itself may not have a good standard to decide send or not. Some static rule maybe useful on specific scenario, and become ineffective when we change the usage of the sensor. Hence, we design an algorithm to solve the problem of data redundant. In the algorithm, we iteratively separate an image into some smaller regions. Each round, choose a region with highest variability, and separate it into four regions. Finally, each region has different size and uses its average value to represent itself. If an area is more various, the density of regions will be higher. In this paper, we present a method to reduce the file size of thermal sensor which can sense the temperature of a surface and outputs a two dimension gray scale image. In our evaluation result, we can reduce the file size to $50\%$ less than JPEG when $0.5\%$ of distortion, and up to $93\%$ less when there is $2\%$ of distortion.
In a IoT environment, many devices will periodically transmit data. However, most of the data are redundant, but sensor itself may not have a good standard to decide to send or not. Some static rule maybe useful on specific scenario, and become ineffective when we change the usage of the sensor. Hence, we design an algorithm to solve the problem of data redundant for IoT devices. In the algorithm, we iteratively separate a data region into some smaller regions. Each round, choose a region with highest variability, and separate it into four regions. Finally, each region has different size and uses its average value to represent itself. If an area has more dynamical diverse data, the density of regions will be higher. In this paper, we present a method to reduce the file size of thermal sensor which can sense the temperature of a surface and outputs a two dimension gray scale image. In our evaluation result, we can reduce the file size to $50\%$ less than JPEG when $0.5\%$ of distortion is allowed, and up to $93\%$ less when $2\%$ of distortion is allowed.
\end{abstract}

+ 3
- 3
trunk/01Introduction.tex View File

@ -19,13 +19,13 @@ Shih and his colleagues~\cite{Shih17b} proposed a sensing system to be installed
\label{fig:gaitVelocitySmartHome}
\end{figure}
Many sensors are needed for getting an accurate result. They will periodically send sensing data and let the host server make the final decision. Sensors have high sensing frequency to prevent unexpected events, and many redundant data were produced. For some normal sensors, e.g., temperature sensor on a gas stove, infared sensor for light control, $CO_2$ sensor for avoiding bad ventilation, we can make a threshold and only send the data that is higher or lower than the predefined threshold. This is a very easy solution if we only have a few devices, but when we have hundreds or thousands devices, it is impossible to manually configure all devices, and the setting may need to change in the winter and summer, or different location. Also, some slightly difference between useful data and redundant data will need more computing power or other information from nearby sensors to distinguish.
In a IoT environment, many devices will periodically transmit data. Some sensors are used for avoid accidents, so they will have very high sensing frequency. However, most of the data are redundant. Like a temperature sensor on a gas stove, the temperature value is the same as the value from air conditioner and does not change very frequently, but it will have dramatically difference when we are cooking. We can simply make a threshold that when temperature is higher or lower than some degrees, the data will be transmitted, and drop the data that we don't interest. This is a very easy solution if we only have a few devices, but when we have hundreds or thousands devices, it is impossible to manually configure all devices, and the setting may need to change in the winter and summer, or different location.
In this paper, we study the data from Panasonic Grid-EYE, a $8 \times 8$ pixels infrared array sensor, and FLIR ONE PRO, a $480 \times 640$ pixels thermal camera. Both are setting on ceiling and taking a video of a person walking under the camera.
In Figure~\ref{fig:gaitVelocitySmartHome}, there are fifteen thermal sensor in a house. If they are Panasonic Grid-EYE, it will have 2 bytes per pixel, 64 pixels per frame, 10 frames per second, and total need 1.7GB storage space per day. If they are FLIR ONE PRO, it can only generate 5 frames per second but needs about 45KB per frame, and it will need 291.6GB everyday.
In Figure~\ref{fig:gaitVelocitySmartHome}, there are fifteen thermal sensor in a house. If they are Panasonic Grid-EYE, it will have 2 bytes per pixel, 64 pixels per frame, 10 frames per second, and total need 1.7GB storage space per day. If they are FLIR ONE PRO, it generates 5 frames per second but needs about 45KB per frame, and it will need 291.6GB everyday.
{\bf Contribution} The target of our work is to compress the thermal image retrieved from FLIR ONE PRO to targeted data size and keep the quality of data. Nearby pixels in a thermal image mostly have similar value, so we can easily separate an image into several regions and use its average value to represent it wont cause too much error. By the method we proposed, the size of file can reduce more than $50\%$ compare to JPEG image when both have $0.5\% (0.18^\circ C)$ of root-mean-square error.
{\bf Contribution} The target of our work is to compress the thermal data retrieved from FLIR ONE PRO to targeted data size and keep the quality of data. Nearby pixels in a thermal data mostly have similar value, so we can easily separate an data region into several regions and use its average value to represent it but will not cause too much error. By the method we proposed, the size of file can reduce more than $50\%$ compare to using JPEG compression algorithm when both have $0.5\% (0.18^\circ C)$ of root-mean-square error.
The remaining of this paper is organized as follow. Section~\ref{sec:bk_related} presents related works and background for developing the methods. Section~\ref{sec:design} presents the system architecture, challenges, and the developed mechanisms. Section~\ref{sec:eval} presents the evaluation results of proposed mechanism and Section~\ref{sec:conclusion} summaries our works.

+ 7
- 7
trunk/02Background.tex View File

@ -2,9 +2,9 @@
\label{sec:bk_related}
\subsection{Panasonic Grid-EYE Thermal Sensor}
First, we study the sensor Panasonic Grid-EYE which is a thermal camera that can output $8 \times 8$ pixels images with $2.5^\circ C$ accuracy and $0.25^\circ C$ resolution at $10$ frames per second. In normal mode, the current consumption is 4.5mA. It is a low resolution camera and infrared array sensor, so we install it in our house at ease without some privacy issue that may cause by a surveillance camera.
First, we study the sensor Panasonic Grid-EYE which is a thermal camera that can output $8 \times 8$ pixels thermal data with $2.5^\circ C$ accuracy and $0.25^\circ C$ resolution at $10$ frames per second. In normal mode, the current consumption is 4.5mA. It is a low resolution camera and infrared array sensor, so we install it in our house at ease without some privacy issue that may cause by a surveillance camera.
When someone walks under a Grid-EYE sensor, we will see some pixels with higher temperature than others. Figure~\ref{fig:GridEye} shows an example of image from Grid-EYE sensor. The sensor value will look like a cone shape. The pixel with our head will have the highest temperature, body is lower, and leg is the lowest except background because when the distance from camera to our body is longer, the area cover by the camera will be wider and the ratio of background temperature in the pixel will increase, also our head does not cover by cloth, so the surface temperature will higher than other place. While we are walking in an area, the temperature of air in the area will become warmer, and the shape of human will become harder to recognize.
When someone walks under a Grid-EYE sensor, we will see some pixels with higher temperature than others. Figure~\ref{fig:GridEye} shows an example of thermal from Grid-EYE sensor. The sensor signal will form a signal cone. The pixel sampling our head temperature will have the highest reading, body is lower, and leg is the lowest except background because when the distance from camera to our body is longer, the area covered by the camera will be wider and the ratio of background temperature in the pixel will increase, also our head does not cover by cloth, so the surface temperature will higher than other place. While we are walking in an area, the temperature of air in the area will become warmer, and the shape of human will be more difficult to recognize.
\begin{figure}[htbp]
\centering
@ -13,19 +13,19 @@ When someone walks under a Grid-EYE sensor, we will see some pixels with higher
\label{fig:GridEye}
\end{figure}
The data we used is from a solitary elder's home. We deployed four Grid-EYE sensors at the corner of her living room, and recorded the thermal video for three weeks at $10$ frames per second data rate, and the size of raw data is about 17.6GB.
The data we used is collected from a solitary elder's home. We deployed four Grid-EYE sensors at the corner of her living room, and recorded the thermal video for three weeks at $10$ frames per second data rate, and the size of raw data is about 17.6GB.
\subsection{FLIR ONE PRO}
FLIR ONE PRO is a thermal camera that can output $480 \times 640$ pixels images with $3^\circ C$ accuracy and $0.01^\circ C$ resolution, and capture speed is about 5 frames per second. In picture taking mode, it can retrieve the precise data from the header of picture file. However, in the video taking mode, it only store a gray scale video and show the range of temperature on the monitor. Hence, we use the data from picture taking mode as our test object. The data form FLIR ONE PRO has about $5000$ times resolution compare to Grid-EYE. The shape of object is not just a cone. The temperature in a same object is similar, but an Obvious edge between different objects. Hence, we developed a method to compress FLIR images. It can also treat as a normal image and be stored as jpeg, png, etc.
FLIR ONE PRO is a thermal camera that can output $480 \times 640$ pixels thermal data with $3^\circ C$ accuracy and $0.01^\circ C$ resolution, and capture speed is about 5 frames per second. In picture taking mode, it can retrieve the precise data from the header of picture file. However, in the video taking mode, it only store a gray scale video and show the range of temperature on the monitor. Hence, we use the data from picture taking mode as our test object. The data form FLIR ONE PRO has about $5000$ times resolution compared to Grid-EYE. The shape of object is not just a cone. The temperature in a same object is similar, but an Obvious edge between different objects. Hence, we developed a method to compress the thermal data from FLIR PRO ONE. It can also treat as a normal image and be stored as jpeg, png, etc.
\subsection{Raspberry Pi 3}
We use Raspberry Pi 3 as our testing environment. It has a 1.2 GHz 64-bit quad-core ARM Cortex-A53 CPU, 1 GB memory, and 802.11n wireless network. We run a Debian-based Linux operating system on it. While it is idling and turning off WiFi, it will consume 240mA and while uploading data at 24Mbit/s, it will consume 400mA.
We use Raspberry Pi 3 as our testing environment. It has a 1.2 GHz 64-bit quad-core ARM Cortex-A53 CPU, 1 GB memory, and 802.11n wireless network. We run a Debian-based Linux operating system on it. While it is idle and turning off WiFi, it will consume 240mA and while uploading data at 24Mbit/s, it will consume 400mA.
\subsection{Simple Data Compressing}
If we store a frame from Grid-EYE in a readable format, it will take about 380 bytes storage. However, the temperature range of indoor environment mostly from $5^\circ C$ to $40^\circ C$ and the resolution of Grid-EYE is $0.25^\circ C$, so we can easily represent each temperature by one byte. Hence, we only need $64$ bytes to store a frame. We had tried several ways to compress the frame.
If we save a frame from Grid-EYE in a readable format, it will take about 380 bytes storage. However, the temperature range of indoor environment mostly from $5^\circ C$ to $40^\circ C$ and the resolution of Grid-EYE is $0.25^\circ C$, so we can easily represent each temperature by one byte. Hence, we only need $64$ bytes to store a frame. We can use different ways to compress the frame.
\subsubsection{Huffman Coding}
Huffman coding is a lossless data compressing. In average, it can reduce the frame size from $64$ bytes to $40.7$ bytes with $6$ bytes standard deviation.
@ -34,5 +34,5 @@ Huffman coding is a lossless data compressing. In average, it can reduce the fra
We can only send the pixels with higher temperature since thermal sensors are mostly used for detect heat source. Z-score is defined as $z = \frac{\chi - \mu}{\sigma}$ where $\chi$ is the value of the temperature, $\mu$ is the average of the temperature and $\sigma$ is the standard deviation of the temperature. In our earlier work~\cite{Shih17b}, we use Z-score instead of a static threshold to detect human because the background temperature may have a $10^\circ C$ difference between day and night, and when people walk through the sensing area the Grid-EYE, the temperature reading will only increase $2^\circ C$ to $3^\circ C$. Hence, it is impossible to use a static threshold to detect human. In~\cite{Shih17b}, the pixels with useful data only if the Z-score is higher than $2$, so we can reduce the frame size by dropping all pixels with Z-score lower than $2$. We can reduce the file size from $64$ bytes to $12.6$ bytes with $2.9$ bytes standard deviation by Z-score threshold $2$ and compress by Huffman coding.
\subsubsection{Gaussian Function Fitting}
Since the shape of human in a image from Grid-EYE looks like a cone, we may use a Gaussian function to fit the image. A Gaussian function $y = Ae^{-(x-B)^2/2C^2}$ has three parameter $A$, $B$ and $C$. The parameter $A$ is the height of the cone, $B$ is the position of the cone's peak and $C$ controls the width of the cone. We let the pixel with highest temperature be the peak of the cone, so we only need to adjust $A$ and $C$ to fit the image. Guo~\cite{guo2011simple} offer a fast way to get the fitting Gaussian function. In our testing, it will be about $0.5^\circ C$ root-mean-square error, and only needs $5$ bytes to store the position of peak and two parameters.
Since the temperature readings of human body in a thermal data from Grid-EYE looks like a signal cone, we may use a Gaussian function to fit the thermal data. A Gaussian function $y = Ae^{-(x-B)^2/2C^2}$ has three parameter $A$, $B$ and $C$. The parameter $A$ is the height of the cone, $B$ is the position of the cone's peak and $C$ controls the width of the cone. We use the pixel with highest temperature to be the peak of the cone, so we only need to adjust $A$ and $C$ to fit the thermal data. Guo~\cite{guo2011simple} provides a fast way to determine the fitting Gaussian function. In our testing, it will have $0.5^\circ C$ root-mean-square error in average, and only needs $5$ bytes to store the position of peak and two parameters.

+ 45
- 19
trunk/03Design.tex View File

@ -1,9 +1,11 @@
\section{Data Size Decision Framework}
\label{sec:design}
This section presents the proposed method that can compress the image into a smaller size compare to jpeg image when we can tolerate some error of data. We use the image captured by FLIR ONE PRO. The temperature in a same object is similar, but an Obvious edge between different objects. Hence, we can separate an image into several regions, and the pixels in a same region has similar value so we can use the average value to represent it and do not cause too much error. However, precisely separate an image into some polygon region is very difficult, and need a lot of computation power. Also, decide the number of region also a problem. Hence, to effectively describe regions we design that every region most be a rectangle, and every region can only separate into 4 regions by cut in half at the middle of horizontal and vertical. The image will start from only contains one region, and 3 regions will be added per round since we cut a region into 4 pieces.
This section presents the proposed method to generate a data array that has less size compared to jpeg image when some of distortion is allowed. We use the thermal data from FLIR ONE PRO.
Our method is shown in Figure~\ref{fig:SystemArchitecture}. Data structure initialize only need to do once if the size of image doesn't change. A thermal image will be loaded into our data structure and separate into several regions. Finally, output data will be encoded by Huffman coding, and transmit to database. When users want to use the image, they can get the encoded data from database.
The nearby pixels usually have similar values, except at the edge of objects. Hence, we can divide an image into several regions, and the pixels in a same region has similar value so we can use the average value to represent it and do not cause too much error. However, precisely divide an image into some polygon region needs a lot of computation power and difficult to describe the edge of each region. Also, determining the number of region is a challenge. Hence, to effectively describe regions we design that every region most be a rectangle, and every region can divide into 4 regions by cut in half at the middle of horizontal and vertical. The image will start from only contains one region, and 3 regions will be added per round since we divide a region into 4 pieces.
Our method is shown in Figure~\ref{fig:SystemArchitecture}. Data structure initialization only needs to do once if the size of a frame doesn't change. A thermal data will be loaded into our data structure and divide into several regions. Finally, the compressed data will be encoded by Huffman coding, and transmitted to database. When users want to use the thermal data, they can restore the data from the encoded data in database.
\begin{figure}[htbp]
\centering
@ -23,8 +25,7 @@ For each frame, we can use a context-free language to represent it.
\end{tabular}
\end{center}
$R$ means a region of image, and it can either use the average $\alpha$ of the pixels in the region to represent whole region or separate into four regions and left a remainder $\beta$. Dependence on the image size we desired, we can choose the amount of separating regions.
The context-free grammar start from a region contain whole image. For each $R$ we calculate a score which is based on the data various in the region. After some operation, we can encode the image into a string $\omega$. Figure~\ref{fig:pngImage} shows an example of image which was took by FLIR ONE PRO. One of the possible outcome is Figure~\ref{fig:SeparateImage} if we separate the image 6 times and it will have 19 regions. By this method, we can iteratively separate an image until the number of regions reach our file size requirement.
$R$ refers to a region of frame, and it can either use the average $\alpha$ of the pixels in the region to represent the whole region or divide into four regions and left a remainder $\beta$. Dependence on size of compressed data, we can choose the amount of dividing regions. The context-free grammar starts from a region containing whole frame. For each $R$ we calculate a score based on the data the quality of data we can improve by dividing it into smaller regions. Figure~\ref{fig:pngImage} shows an example of thermal data which was took by FLIR ONE PRO. One of the possible outcome is Shown in Figure~\ref{fig:SeparateImage} if we divide the frame 6 times and it will have 19 regions. By this method, we can iteratively compress the thermal data until the number of regions reach our file size requirement or the error rate is less than the requirement.
\begin{figure}[ht]
@ -38,14 +39,14 @@ The context-free grammar start from a region contain whole image. For each $R$ w
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\linewidth]{figures/separate.png}
\caption{Region separate by CFG}
\caption{Region divided by our method}
\label{fig:SeparateImage}
\end{minipage}
\end{figure}
\subsection{Data Structure and Region Selection Algorithm}
To help us choose which region to be separated, we give every region a score, and put them into a heap. For each round, we pick the region with the highest score, separate it into four subregions, calculate the score of subregions, and put them into the heap. We use the sum of square error of pixels in the region $R$ as the score of the region.
To help us choose which region to be divided, we give every region a score, and put them into a heap. For each round, we pick the region with the highest score, and divide it into four subregions, calculate the score of subregions, and put them into the heap. We use the sum of square error of pixels in the region $R$ as the score of the region.
\begin{center}
\begin{tabular}{rl}
@ -55,7 +56,7 @@ To help us choose which region to be separated, we give every region a score, an
\end{tabular}
\end{center}
By the equation shows above, we just need to know the sum of squared and the mean of a region to calculate its score. We use a 4-dimension segment tree to store all possible regions and its scores. Since segment tree is a complete tree, the size of tree is less than 2 times the number if pixels. For each node of segment tree, it records the range on both width and height it covered, sum $\sum\limits_{X\in R} X$, and squared sum $\sum\limits_{X\in R} X^2$ of pixels in the region. By the property of segment tree, tree root start from $0$, and each node $X_i$ has four child $X_{i\times 4+1}$, $X_{i\times 4+2}$, $X_{i\times 4+3}$ and $X_{i\times 4+4}$. Hence, we only need to allocate a large array and recursively process all nodes form root. Algorithm~\ref{code:SegmentTreePreprocess} shows how we generate the tree.
By the equation shown above, we just need to know the sum of square and the sum of all pixels in the region to calculate the score of the region. We use a 4-dimension segment tree as a container to store all possible regions and its scores. Since segment tree is a complete tree, the size of tree is less than 2 times the number if pixels. For each node of segment tree, it records the range on both width and height it covered, sum $\sum\limits_{X\in R} X$, and sum of square $\sum\limits_{X\in R} X^2$ of pixels in the region. The root of segment tree starts is node number $0$, and each node $i$ has four child from node number from $i\times 4+1$ to $i\times 4+4$. Hence, we only need to allocate a large array and recursively process all nodes form root. Algorithm~\ref{code:SegmentTreePreprocess} shows how we generate the tree and calculate the sum of square and the sum of all nodes.
\begin{algorithm*}[h]
\caption{Segment Tree Preprocess}
@ -64,8 +65,8 @@ By the equation shows above, we just need to know the sum of squared and the mea
\State $Tree = Array()$
\Function{setTreeNode}{$x, left, right, top, bottom$}
\If {$left = right$ \and $top = bottom$}
\State $Tree[x].Sum = Image[left][top]$
\State $Tree[x].SquareSum = Image[left][top]^2$
\State $Tree[x].Sum = Frame[left][top]$
\State $Tree[x].SquareSum = Frame[left][top]^2$
\Else
\State $setTreeNode(4x+1, left, (left+right)/2, top, (top+bottom)/2)$
\State $setTreeNode(4x+2, (left+right)/2, right, top, (top+bottom)/2)$
@ -76,28 +77,53 @@ By the equation shows above, we just need to know the sum of squared and the mea
\EndIf
\State $Tree[x].SquaredError = Tree[x].SquareSum - \frac{Tree[x].Sum^2}{(right-left+1)\times(bottom-top+1)}$
\EndFunction
\State $setTreeNode(0, 0, Image.Width, 0, Image.Height)$
\State $setTreeNode(0, 0, Frame.Width, 0, Frame.Height)$
\end{algorithmic}
\end{algorithm*}
For region selection, we use a priority queue to retrieve the region of considerate regions with highest score. The priority queue is made by heap, and start with only root of the segment tree. For each round the priority queue pop the item with highest score and push all its child in to the queue. Algorithm~\ref{code:RegionSelection} shows how we select a region by the priority queue. After the selection finished, we will generate the data string to be sent. The regions in $seperatedRegions$ will be $\beta$ and others in $PriorityQueue$ will be the average value, and then compress the string by Huffman Coding.
For region selection, we use a priority queue to retrieve the region of considerate regions with highest score. The priority queue is made by heap, and start with only root of the segment tree. For each round the priority queue pop the item with highest score and push all its child in to the queue.
The compressed data size is depended on how many iterations of dividing the regions. The compressed data size will be about the number of iterations times four bytes. Algorithm~\ref{code:RegionSpecifiedSize} shows how we divide regions until specified data size.
\begin{algorithm*}[h]
\caption{Region Selection}
\label{code:RegionSelection}
\caption{Dividing regions depends on compressed data size}
\label{code:RegionSpecifiedSize}
\begin{algorithmic}[1]
\State $seperatedRegions = Array()$
\State $PriorityQueue = Heap()$
\State $PriorityQueue.Push(Tree[0].SquaredError, 0)$
\For{\State $i = 0..SeperateRounds$}
\For{$i = 0..NumberOfIterations$}
\State $value, x = PriorityQueue.Pop()$
\State $seperatedRegions.push(x)$
\State $PriorityQueue.Push(Tree[4x+1].SquaredError, 4x+1)$
\State $PriorityQueue.Push(Tree[4x+2].SquaredError, 4x+2)$
\State $PriorityQueue.Push(Tree[4x+3].SquaredError, 4x+3)$
\State $PriorityQueue.Push(Tree[4x+4].SquaredError, 4x+4)$
\For{$j = 1..4$}
\State $PriorityQueue.Push(Tree[4x+j].SquaredError, 4x+j)$
\EndFor
\EndFor
\end{algorithmic}
\end{algorithm*}
The complexity of our algorithm can be separated into 3 parts. First part is to initialize the segment tree. The size of segment is depends on the size of the image. If the number of pixels is $N$, the height of segment tree is $O(Nlog(N))$, and the number of nodes will be $O(N)$. The time complexity of initialize is $O(N)$. Second part is loading the image. It will need to traverse whole tree from leaf to root. Since segment tree can be stored in an array, it also takes $O(N)$ time to load the image. Third part is to separate regions. For each round, we pop an element from heap and push four elements into heap. If we have separated image $K$ times, the size of heap will be $3K+1$. Time complexity of pop and push will be $O(log(K))$, and do it $5K$ times will be $O(Klog(K))$.
The error rate of the compressed data is the sum of the squared error of regions in priority queue. Algorithm~\ref{code:RegionSpecifiedError} shows how we divide regions until specified RMSE.
\begin{algorithm*}[h]
\caption{Dividing regions depends on compressed data RMSE}
\label{code:RegionSpecifiedError}
\begin{algorithmic}[1]
\State $seperatedRegions = Array()$
\State $PriorityQueue = Heap()$
\State $PriorityQueue.Push(Tree[0].SquaredError, 0)$
\State $SquaredError = Tree[0].SquaredError$
\While{$\sqrt{(SquaredError/FrameSize)} > SpecifiedRMSE$}
\State $value, x = PriorityQueue.Pop()$
\State $seperatedRegions.push(x)$
\State $SquaredError$ -= $value$
\For{$j = 1..4$}
\State $PriorityQueue.Push(Tree[4x+j].SquaredError, 4x+j)$
\State $SquaredError$ += $Tree[4x+j].SquaredError$
\EndFor
\EndWhile
\end{algorithmic}
\end{algorithm*}
After the region dividing finished, we will generate the data string to be sent. The regions in $seperatedRegions$ will be replaced by a reminder for dividing and others in $PriorityQueue$ will be the average sensor reading in the region, and then compress the string by Huffman Coding.
The complexity of our algorithm can be divided into 3 parts. First part is to initialize the segment tree. The size of segment is depends on the size of the frame. If the number of pixels is $N$, the height of segment tree is $O(Nlog(N))$, and the number of nodes will be $O(N)$. The time complexity of initialize is $O(N)$. Second part is loading the thermal data. It will need to traverse whole tree from leaf to root. Since segment tree can be stored in an array, it also takes $O(N)$ time to load the thermal data. Third part is to divide regions. For each round, we pop an element from heap and push four elements into heap. If there is $K$ iterations, the size of heap will be $3K+1$. Time complexity of pop and push will be $O(log(K))$, and do it $5K$ times will be $O(Klog(K))$.

+ 12
- 10
trunk/04Evaluation.tex View File

@ -1,27 +1,27 @@
\section{Performance Evaluation}
\label{sec:eval}
To evaluate the effectiveness of the proposed method, we did the different ratios of compressing on a thermal image by our method compared to JPEG image using different quality and png image, a lossless bit map image. We set the camera at the ceiling and view direction is perpendicular to the ground, and the image size is $480 \times 640$ pixels. The JPEG image is generated by OpenCV $3.3.0$, and image quality from $1$ to $99$.
To evaluate the effectiveness of the proposed method, we did the different ratios of compressing on a thermal data by our method compared to JPEG image using different quality and png image, a lossless bit map image. We set the camera at the ceiling and view direction is perpendicular to the ground, and the thermal data size is $480 \times 640$ pixels. The JPEG image is generated by OpenCV $3.3.0$ which is using libjpeg version 9 13-Jan-2013, and image quality from $1$ to $99$.
Figure~\ref{fig:4KMy} and Figure~\ref{fig:4KJpeg} show the different of JPEG and our method. JPEG image id generated by image quality level $3$, and image of our method does $1390$ rounds of separate and compressed by Huffman Coding. In this case, Huffman Coding can reduce $39\%$ of our image size.
Figure~\ref{fig:4KMy} and Figure~\ref{fig:4KJpeg} show the different of JPEG and our method. JPEG image id generated by image quality level $3$, and thermal data of our method does $1390$ rounds of separate and compressed by Huffman Coding. In this case, Huffman Coding can reduce $39\%$ of compressed data size.
\begin{figure}[ht]
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\linewidth]{figures/my4000.png}
\caption{4KB Image by Proposed Method}
\caption{Data compressed by Proposed Method (4KB)}
\label{fig:4KMy}
\end{minipage}
\hspace{0.05\linewidth}
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\linewidth]{figures/quality3.jpg}
\caption{4KB Image by JPEG}
\caption{Data compressed by JPEG (4KB)}
\label{fig:4KJpeg}
\end{minipage}
\end{figure}
Figure~\ref{fig:compareToJpeg} shows that the size of file can reduce more than $50\%$ compared to JPEG image when both have $0.5\% (0.18^\circ C)$ of root-mean-square error. Our method has $82\%$ less error rate when both size are $4KB$ image. The percentage of file size is compared to PNG image.
Figure~\ref{fig:compareToJpeg} shows that the size of file can reduce more than $50\%$ compared to JPEG image when both have $0.5\% (0.18^\circ C)$ of root-mean-square error. Our method has $82\%$ less error rate when the compressed data size is $4KB$. The percentage of file size is compared to PNG image.
\begin{figure}[ht]
\centering
@ -30,18 +30,20 @@ Figure~\ref{fig:compareToJpeg} shows that the size of file can reduce more than
\label{fig:compareToJpeg}
\end{figure}
The computing time of a $480 \times 640$ image on Raspberry Pi 3 is:
The computing time of a $480 \times 640$ thermal data on Raspberry Pi 3 is:
\subsubsection{Date Structure Initialize}
0.233997 second.
\subsubsection{Image Loading}
\subsubsection{Thermal Data Loading}
1.268126 second.
\subsubsection{Region Separation}
About 4.6 microsecond per separation. Figure~\ref{fig:computeTime}
\subsubsection{Regions dividing}
About 4.6 microsecond per separation. Figure~\ref{fig:computeTime} shows the computation time of Region dividing.
Total time is about 1.5 second.
\begin{figure}[ht]
\centering
\includegraphics[width=\columnwidth]{figures/computeTime.pdf}
\caption{Computation Time of Separate Regions}
\caption{Computation Time of Regions Dividing}
\label{fig:computeTime}
\end{figure}

+ 1
- 1
trunk/05Conclusion.tex View File

@ -1,3 +1,3 @@
\section{Conclusion\label{sec:conclusion}}
In this paper we present the design to reduce the data size of a two dimension thermal image. By using the property that thermal image is gray scale and nearby pixels are have similar value, we can use the average value to stand for whole region. By giving every regions different resolutions, we can reduce the file size to $50\%$ less than JPEG when there is $0.5\%$ of distortion, and up to $93\%$ less when there is $2\%$ of distortion.
In this paper we present the design to reduce the data size of a two dimension thermal data. Nearby pixels in a thermal data mostly have similar value, so we can easily separate an data region into several regions and use its average value to represent it but will not cause too much error. The method we proposed can either choose the data size or error rate of compressed data. By giving every regions different resolutions, we can reduce the file size to $50\%$ less than JPEG when there is $0.5\%$ of distortion, and up to $93\%$ less when there is $2\%$ of distortion.

+ 14
- 12
trunk/Main.aux View File

@ -50,25 +50,27 @@
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsection}{\numberline {\unhbox \voidb@x \hbox {III-A}}Region Represent Grammar}{7}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces PNG image, size = 46KB}}{8}}
\newlabel{fig:pngImage}{{4}{8}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Region separate by CFG}}{8}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Region divided by our method}}{8}}
\newlabel{fig:SeparateImage}{{5}{8}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsection}{\numberline {\unhbox \voidb@x \hbox {III-B}}Data Structure and Region Selection Algorithm}{8}}
\@writefile{loa}{\defcounter {refsection}{0}\relax }\@writefile{loa}{\contentsline {algorithm}{\numberline {1}{\ignorespaces Segment Tree Preprocess}}{9}}
\newlabel{code:SegmentTreePreprocess}{{1}{9}}
\@writefile{loa}{\defcounter {refsection}{0}\relax }\@writefile{loa}{\contentsline {algorithm}{\numberline {2}{\ignorespaces Region Selection}}{9}}
\newlabel{code:RegionSelection}{{2}{9}}
\@writefile{loa}{\defcounter {refsection}{0}\relax }\@writefile{loa}{\contentsline {algorithm}{\numberline {2}{\ignorespaces Dividing regions depends on compressed data size}}{9}}
\newlabel{code:RegionSpecifiedSize}{{2}{9}}
\@writefile{loa}{\defcounter {refsection}{0}\relax }\@writefile{loa}{\contentsline {algorithm}{\numberline {3}{\ignorespaces Dividing regions depends on compressed data RMSE}}{10}}
\newlabel{code:RegionSpecifiedError}{{3}{10}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {section}{\numberline {IV}Performance Evaluation}{10}}
\newlabel{sec:eval}{{IV}{10}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces 4KB Image by Proposed Method}}{10}}
\newlabel{fig:4KMy}{{6}{10}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces 4KB Image by JPEG}}{10}}
\newlabel{fig:4KJpeg}{{7}{10}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Proposed method and JPEG comparing}}{11}}
\newlabel{fig:compareToJpeg}{{8}{11}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Data compressed by Proposed Method (4KB)}}{11}}
\newlabel{fig:4KMy}{{6}{11}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Data compressed by JPEG (4KB)}}{11}}
\newlabel{fig:4KJpeg}{{7}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsubsection}{\numberline {\unhbox \voidb@x \hbox {IV-}1}Date Structure Initialize}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsubsection}{\numberline {\unhbox \voidb@x \hbox {IV-}2}Image Loading}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsubsection}{\numberline {\unhbox \voidb@x \hbox {IV-}3}Region Separation}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsubsection}{\numberline {\unhbox \voidb@x \hbox {IV-}2}Thermal Data Loading}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {subsubsection}{\numberline {\unhbox \voidb@x \hbox {IV-}3}Regions dividing}{11}}
\newlabel{sec:conclusion}{{V}{11}}
\@writefile{toc}{\defcounter {refsection}{0}\relax }\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{11}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces Computation Time of Separate Regions}}{12}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Proposed method and JPEG comparing}}{12}}
\newlabel{fig:compareToJpeg}{{8}{12}}
\@writefile{lof}{\defcounter {refsection}{0}\relax }\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces Computation Time of Regions Dividing}}{12}}
\newlabel{fig:computeTime}{{9}{12}}

+ 40
- 26
trunk/Main.log View File

@ -1,4 +1,4 @@
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (MiKTeX 2.9.6210 64-bit) (preloaded format=pdflatex 2018.3.9) 15 MAR 2018 13:49
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (MiKTeX 2.9.6210 64-bit) (preloaded format=pdflatex 2018.3.9) 15 MAR 2018 23:07
entering extended mode
**./Main.tex
(Main.tex
@ -979,16 +979,16 @@ File: figures/ThermalAtHome.pdf Graphic file (type pdf)
Package pdftex.def Info: figures/ThermalAtHome.pdf used on input line 17.
(pdftex.def) Requested size: 516.0pt x 343.26186pt.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <12> on input line 22.
(Font) <12> on input line 24.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <8> on input line 22.
(Font) <8> on input line 24.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <6> on input line 22.
(Font) <6> on input line 24.
[2]) (02Background.tex [3 <./figures/ThermalAtHome.pdf>]
pdfTeX warning: pdflatex (file ./figures/GridEye.pdf): PDF inclusion: found PDF
version <1.7>, but at most version <1.5> allowed
<figures/GridEye.pdf, id=50, 332.24126pt x 180.675pt>
<figures/GridEye.pdf, id=49, 332.24126pt x 180.675pt>
File: figures/GridEye.pdf Graphic file (type pdf)
<use figures/GridEye.pdf>
@ -1009,30 +1009,39 @@ LaTeX Warning: Citation 'guo2011simple' on page 6 undefined on input line 37.
pdfTeX warning: pdflatex (file ./figures/SystemArchitecture.pdf): PDF inclusion
: found PDF version <1.7>, but at most version <1.5> allowed
<figures/SystemArchitecture.pdf, id=63, 578.16pt x 325.215pt>
<figures/SystemArchitecture.pdf, id=62, 578.16pt x 325.215pt>
File: figures/SystemArchitecture.pdf Graphic file (type pdf)
<use figures/SystemArchitecture.pdf>
Package pdftex.def Info: figures/SystemArchitecture.pdf used on input line 10.
Package pdftex.def Info: figures/SystemArchitecture.pdf used on input line 12.
(pdftex.def) Requested size: 516.0pt x 290.26419pt.
[6]
<figures/real.png, id=68, 481.8pt x 642.4pt>
File: figures/real.png Graphic file (type png)
<use figures/real.png>
Package pdftex.def Info: figures/real.png used on input line 33.
Package pdftex.def Info: figures/real.png used on input line 34.
(pdftex.def) Requested size: 232.19843pt x 309.59338pt.
<figures/separate.png, id=69, 481.8pt x 642.4pt>
File: figures/separate.png Graphic file (type png)
<use figures/separate.png>
Package pdftex.def Info: figures/separate.png used on input line 40.
Package pdftex.def Info: figures/separate.png used on input line 41.
(pdftex.def) Requested size: 232.19843pt x 309.59338pt.
[7 <./figures/SystemArchitecture.pdf>]
[7 <./figures/SystemArchitecture.pdf>] [8 <./figures/real.png (PNG copy)> <./fi
gures/separate.png (PNG copy)>]
** WARNING: \and is valid only when in conference or peerreviewca
modes (line 66).
[8 <./figures/real.png (PNG copy)> <./figures/separate.png (PNG copy)>])
(04Evaluation.tex [9] <figures/my4000.png, id=87, 481.8pt x 642.4pt>
modes (line 67).
LaTeX Warning: `h' float specifier changed to `ht'.
Overfull \hbox (28.18843pt too wide) in paragraph at lines 127--128
[]\OT1/ptm/m/n/12 After the re-gion di-vid-ing fin-ished, we will gen-er-ate th
e data string to be sent. The re-gions in $\OML/cmm/m/it/12 seperatedRegions$
[]
[9]) (04Evaluation.tex <figures/my4000.png, id=87, 481.8pt x 642.4pt>
File: figures/my4000.png Graphic file (type png)
<use figures/my4000.png>
@ -1044,28 +1053,33 @@ File: figures/quality3.jpg Graphic file (type jpg)
<use figures/quality3.jpg>
Package pdftex.def Info: figures/quality3.jpg used on input line 18.
(pdftex.def) Requested size: 232.19843pt x 309.59338pt.
[10 <./figures/my4000.png (PNG copy)> <./figures/quality3.jpg>] <figures/compa
reToJpeg.pdf, id=92, 642.4pt x 385.44pt>
<figures/compareToJpeg.pdf, id=89, 642.4pt x 385.44pt>
File: figures/compareToJpeg.pdf Graphic file (type pdf)
<use figures/compareToJpeg.pdf>
Package pdftex.def Info: figures/compareToJpeg.pdf used on input line 28.
(pdftex.def) Requested size: 516.0pt x 309.61102pt.
[10]
<figures/computeTime.pdf, id=93, 642.4pt x 385.44pt>
File: figures/computeTime.pdf Graphic file (type pdf)
<use figures/computeTime.pdf>
Package pdftex.def Info: figures/computeTime.pdf used on input line 43.
Package pdftex.def Info: figures/computeTime.pdf used on input line 45.
(pdftex.def) Requested size: 516.0pt x 309.61102pt.
) (05Conclusion.tex) (06Acknowledge.tex)
) (05Conclusion.tex)
LaTeX Warning: Empty bibliography on input line 143.
\svn@write=\write7
\openout7 = `Main.svn'.
[11 <./figures/compareToJpeg.pdf>] [12 <./figures/computeTime.pdf>] (Main.aux)
[11 <./figures/my4000.png (PNG copy)> <./figures/quality3.jpg>] [12 <./figures/
compareToJpeg.pdf> <./figures/computeTime.pdf
pdfTeX warning: pdflatex (file ./figures/computeTime.pdf): PDF inclusion: multi
ple pdfs with page group included in a single page
>] (Main.aux)
LaTeX Warning: There were undefined references.
@ -1079,13 +1093,13 @@ Package logreq Info: Writing requests to 'Main.run.xml'.
)
Here is how much of TeX's memory you used:
22513 strings out of 493333
425347 string characters out of 3139189
928149 words of memory out of 3000000
25622 multiletter control sequences out of 15000+200000
22516 strings out of 493333
425405 string characters out of 3139189
930158 words of memory out of 3000000
25628 multiletter control sequences out of 15000+200000
37218 words of font info for 72 fonts, out of 3000000 for 9000
1141 hyphenation exceptions out of 8191
64i,8n,56p,1104b,1282s stack positions out of 5000i,500n,10000p,200000b,50000s
64i,8n,56p,1118b,1282s stack positions out of 5000i,500n,10000p,200000b,50000s
{C:/Program Files/MiKTeX 2.9/fonts/enc/dvips/base/8r.enc}<C:/Program Files/Mi
KTeX 2.9/fonts/type1/public/amsfonts/cm/cmex10.pfb><C:/Program Files/MiKTeX 2.9
/fonts/type1/public/amsfonts/cm/cmmi10.pfb><C:/Program Files/MiKTeX 2.9/fonts/t
@ -1099,9 +1113,9 @@ KTeX 2.9/fonts/type1/public/amsfonts/cm/cmsy8.pfb><C:/Program Files/MiKTeX 2.9/
fonts/type1/urw/times/utmb8a.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/urw/t
imes/utmr8a.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/urw/times/utmri8a.pfb>
Output written on Main.pdf (12 pages, 648701 bytes).
Output written on Main.pdf (12 pages, 651563 bytes).
PDF statistics:
158 PDF objects out of 1000 (max. 8388607)
157 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)
64 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
trunk/Main.pdf View File


BIN
trunk/Main.synctex.gz View File


+ 1
- 1
trunk/Main.tex View File

@ -137,7 +137,7 @@
% Conclusion
\input{05Conclusion}
% Acknowledgement
\input{06Acknowledge}
%\input{06Acknowledge}
\balance
\printbibliography


BIN
trunk/figures/computeTime.pdf View File


Loading…
Cancel
Save