esajpip-0.1~bzr33/ 0000755 0001750 0001750 00000000000 12335423210 013734 5 ustar mathieu mathieu esajpip-0.1~bzr33/doc/ 0000755 0001750 0001750 00000000000 12335423210 014501 5 ustar mathieu mathieu esajpip-0.1~bzr33/doc/jpip_fig.fig 0000644 0001750 0001750 00000007170 12335423210 016764 0 ustar mathieu mathieu #FIG 3.2 Produced by xfig version 3.2.5b
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
0 32 #e7e7e7
0 33 #b6d5ae
0 34 #aeb2d5
1 2 0 1 0 33 56 -1 20 0.000 1 0.0000 1879 6225 521 75 1358 6150 2400 6300
1 2 0 1 0 33 50 -1 30 0.000 1 0.0000 1879 5625 521 75 1358 5625 2400 5625
1 2 2 1 0 33 50 -1 30 3.000 1 0.0000 3079 5625 521 75 2558 5625 3600 5625
1 2 2 1 0 33 56 -1 20 3.000 1 0.0000 3079 6225 521 75 2558 6150 3600 6300
1 2 2 1 0 33 56 -1 20 3.000 1 0.0000 5854 6225 521 75 5333 6150 6375 6300
1 2 2 1 0 33 50 -1 30 3.000 1 0.0000 5854 5625 521 75 5333 5625 6375 5625
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
1350 5625 1350 6225
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
2400 5625 2400 6225
2 2 0 0 0 33 55 -1 20 0.000 0 0 7 0 0 5
1350 5625 2400 5625 2400 6225 1350 6225 1350 5625
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
3075 5175 3075 5625
2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
7350 4875 6375 4875
2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
6375 5025 7350 5025
2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
7800 5175 7800 5700
2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
7950 5700 7950 5175
2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 0 1 2
1 1 1.00 60.00 120.00
3675 4875 5325 4875
2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 0 1 2
1 1 1.00 60.00 120.00
5325 5025 3675 5025
2 1 0 1 0 32 50 -1 31 4.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
6375 5925 7350 5925
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3600 5625 3600 6225
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
2550 5625 2550 6225
2 2 2 0 0 33 55 -1 20 3.000 0 0 7 0 0 5
2550 5625 3600 5625 3600 6225 2550 6225 2550 5625
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
5850 5175 5850 5625
2 2 2 1 0 7 70 -1 -1 3.000 0 0 7 0 0 5
1200 4200 3900 4200 3900 6450 1200 6450 1200 4200
2 2 2 1 0 7 70 -1 -1 3.000 0 0 7 0 0 5
5100 4200 8625 4200 8625 6450 5100 6450 5100 4200
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
2475 4725 3675 4725 3675 5175 2475 5175 2475 4725
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
5325 4725 6375 4725 6375 5175 5325 5175 5325 4725
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
7350 5700 8475 5700 8475 6150 7350 6150 7350 5700
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
7350 4725 8475 4725 8475 5175 7350 5175 7350 4725
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
6375 5625 6375 6225
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
5325 5625 5325 6225
2 2 2 0 0 33 55 -1 20 3.000 0 0 7 0 0 5
5325 5625 6375 5625 6375 6225 5325 6225 5325 5625
2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 0 1 3
1 1 1.00 60.00 120.00
2475 4950 1875 4950 1875 5625
4 0 0 50 -1 0 10 0.0000 6 105 315 6675 4800 WOI\001
4 0 0 50 -1 0 10 0.0000 6 105 570 6525 5850 data-bins\001
4 0 0 50 -1 0 10 0.0000 6 105 315 7350 5475 WOI\001
4 0 0 50 -1 0 10 0.0000 6 105 570 4125 5175 data-bins\001
4 0 0 50 -1 0 10 0.0000 6 105 390 1350 4500 Server\001
4 0 0 50 -1 0 10 0.0000 6 105 405 5250 4500 Client\001
4 0 0 50 -1 0 10 0.0000 6 90 375 6600 5175 status\001
4 0 0 50 -1 0 10 0.0000 6 105 360 5625 6000 Cache\001
4 0 0 50 -1 0 10 0.0000 6 135 360 8025 5475 image\001
4 0 0 50 -1 0 10 0.0000 6 105 525 7650 5025 Browser\001
4 0 0 50 -1 0 10 0.0000 6 105 690 5475 5025 JPIP client\001
4 0 0 50 -1 0 10 0.0000 6 150 795 4050 4800 WOI request\001
4 0 0 50 -1 0 10 0.0000 6 105 750 2625 5925 Client cache\001
4 0 0 50 -1 0 10 0.0000 6 105 390 2850 6150 model\001
4 0 0 50 -1 0 10 0.0000 6 105 645 1500 5925 JPEG2000\001
4 0 0 50 -1 0 10 0.0000 6 135 420 1650 6150 images\001
4 0 0 50 -1 0 10 0.0000 6 105 705 2700 5025 JPIP server\001
4 0 0 50 -1 0 10 0.0000 6 150 870 7500 6000 Decompressor\001
esajpip-0.1~bzr33/doc/architecture.fig 0000644 0001750 0001750 00000010634 12335423210 017656 0 ustar mathieu mathieu #FIG 3.2 Produced by xfig version 3.2.5b
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
0 32 #e7e7e7
0 33 #b6d5ae
0 34 #aeb2d5
6 8250 5850 9300 6600
6 8250 5850 9300 6600
1 2 0 1 0 33 56 -1 20 0.000 1 0.0000 8779 6525 521 75 8258 6450 9300 6600
1 2 0 1 0 33 50 -1 30 0.000 1 0.0000 8779 5925 521 75 8258 5925 9300 5925
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
8250 5925 8250 6525
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
9300 5925 9300 6525
2 2 0 0 0 33 55 -1 20 0.000 0 0 7 0 0 5
8250 5925 9300 5925 9300 6525 8250 6525 8250 5925
4 0 0 50 -1 0 10 0.0000 6 105 645 8400 6225 JPEG2000\001
4 0 0 50 -1 0 10 0.0000 6 135 420 8550 6450 images\001
-6
-6
6 5700 3900 6675 4500
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
5700 4425 5700 3900 6675 3900 6675 4425
3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 7
5700 4423 5819 4482 5992 4482 6169 4423 6342 4367 6525 4350
6675 4425
0.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.000
-6
6 5700 4800 6675 5400
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
5700 5325 5700 4800 6675 4800 6675 5325
3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 7
5700 5323 5819 5382 5992 5382 6169 5323 6342 5267 6525 5250
6675 5325
0.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.000
-6
6 5775 3225 6600 3525
4 0 0 50 -1 0 8 0.0000 6 90 825 5775 3375 UNIX domain\001
4 0 0 50 -1 0 8 0.0000 6 90 375 6000 3525 socket\001
-6
6 7275 2700 7875 3900
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
7275 2700 7875 2700 7875 3900 7275 3900 7275 2700
2 2 0 1 0 32 49 -1 20 0.000 0 0 -1 0 0 5
7575 2775 7800 2775 7800 3825 7575 3825 7575 2775
4 0 0 50 -1 0 10 1.5708 6 135 945 7500 3825 Client manager\001
4 0 0 48 -1 0 8 1.5708 6 90 885 7725 3750 Data-bin server\001
-6
6 8475 2700 9075 3900
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
8475 2700 9075 2700 9075 3900 8475 3900 8475 2700
2 2 0 1 0 32 49 -1 20 0.000 0 0 -1 0 0 5
8775 2775 9000 2775 9000 3825 8775 3825 8775 2775
4 0 0 50 -1 0 10 1.5708 6 135 945 8700 3825 Client manager\001
4 0 0 48 -1 0 8 1.5708 6 90 885 8925 3750 Data-bin server\001
-6
1 2 0 1 0 33 50 -1 30 0.000 1 0.0000 7579 5925 521 75 7058 5925 8100 5925
1 2 0 1 0 33 56 -1 20 0.000 1 0.0000 7579 6525 521 75 7058 6450 8100 6600
1 2 2 1 0 7 50 -1 -1 3.000 1 0.0000 6150 3098 75 127 6075 3098 6225 3098
2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 1 0 4
1 1 1.00 60.00 120.00
8775 5925 8775 5625 8325 5625 8325 5325
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
8175 4650 8175 5025
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
7575 5025 8775 5025 8775 5325 7575 5325 7575 5025
2 2 0 1 0 34 50 -1 28 0.000 0 0 -1 0 0 5
7575 4350 8775 4350 8775 4650 7575 4650 7575 4350
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 1.00 60.00 120.00
8175 4350 8175 4125
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
7575 3900 7575 4125 8775 4125 8775 3900
2 2 2 1 0 7 70 -1 -1 3.000 0 0 7 0 0 5
7125 2550 9225 2550 9225 5550 7125 5550 7125 2550
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
7575 5925 7575 5625 7950 5625 7950 5325
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
7050 5925 7050 6525
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
8100 5925 8100 6525
2 2 0 0 0 33 55 -1 20 0.000 0 0 7 0 0 5
7050 5925 8100 5925 8100 6525 7050 6525 7050 5925
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
5250 3075 7125 3075
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
6675 5025 7125 5025
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 120.00
1 1 1.00 60.00 120.00
5250 5025 5700 5025
2 2 2 1 0 7 70 -1 -1 3.000 0 0 7 0 0 5
4575 2550 5250 2550 5250 5475 4575 5475 4575 2550
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 1.00 60.00 120.00
5250 4125 5700 4125
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
6675 4125 7125 4125
4 0 0 50 -1 0 10 0.0000 6 135 900 7725 4575 Index manager\001
4 0 0 50 -1 0 10 0.0000 6 135 795 7725 5250 File manager\001
4 0 0 50 -1 0 10 0.0000 6 135 720 7200 6225 Image cache\001
4 0 0 50 -1 0 10 0.0000 6 105 285 7425 6450 files\001
4 0 0 50 -1 0 10 0.0000 6 150 840 7125 2475 Child process\001
4 0 0 50 -1 0 9 0.0000 6 135 885 5775 4125 Configuration\001
4 0 0 50 -1 0 9 0.0000 6 135 735 5850 4275 (server.cfg)\001
4 0 0 50 -1 0 9 0.0000 6 135 735 5850 5025 App. shared\001
4 0 0 50 -1 0 9 0.0000 6 105 750 5850 5175 information\001
4 0 0 50 -1 0 10 0.0000 6 150 885 4425 2475 Father process\001
4 0 0 50 -1 0 16 0.0000 6 30 300 8025 3450 . . .\001
esajpip-0.1~bzr33/doc/jpip.tex 0000644 0001750 0001750 00000035606 12335423210 016177 0 ustar mathieu mathieu
Part 9 of the JPEG2000 standard is almost
completely dedicated to the development of systems for
remote browsing of images. It defines a set of technologies
(protocols, file formats, architectures, etc.) that allow
to exploit efficiently all the characteristics of the JPEG2000
compression system for the development of this
kind of systems. The technology which Part 9 mainly focuses on is
the JPIP protocol (JPeg2000 Interactive Protocol).
\subsection{Architecture}
The common client/server architecture of a system for remote browsing of
images that uses the JPIP transmission protocol has the organization
shown in Fig. \ref{fig:jpip}.
\begin{figure}
\resizebox{\textwidth}{!}{
\input{../jpip_fig}
}
\caption{Client/server architecture of the JPIP protocol.}
\label{fig:jpip}
\end{figure}
As it can be observed in the figure, the client is divided
into four functional modules. The Browser module consists of
the interface which the user interacts with in order to
define the desired WOI. JPIP allows to use multiple parameters
to define the WOI of the remote image to show in form of
restrictions related to the partitions to transmit (number
of quality layers, components, etc.). Geometrically,
JPIP always imposes that the WOIs have to be defined in
rectangular regions over a certain resolution level.
Once the user has defined the desired WOI, it is sent to the
``JPIP client'' and ``Decompressor'' modules. The first one is
the responsible for communicating to the JPIP server
in order to send it the WOI using the messages and syntax
defined by JPIP. When the server receives this information,
it extracts from the associated image the required data for
the reconstruction of the WOI, and send it to the client.
This data is sent encapsulated in data-bins. In JPIP the
different elements of the data partitions of a JPEG2000 image
are reordered and encapsulated in data-bins, being the
transmission units.
As the client receives the data-bins from the server, it stores them
in a internal cache (``Cache'' module). The client cache is organized
in data-bins as well. This cache is continuously used by the ``Decompressor''
module for generating progressive reconstructions of the WOI,
that are passed to the ``Browser'' module to show to the user.
As it can be seen, except the ``Cache'' module which serves as a container,
the rest of the modules that composes the client work in parallel.
The Browser is continuously indicating to the JPIP client which
WOI is wanted by the user. The JPIP client keeps communicating to
the server for transmitting this WOI and, as it receives the data,
stores it within the cache. The decompressor generates every time
reconstructions of the current WOI with the existing data in the cache.
The modules begin their execution when the user defines the first WOI,
and they stop when all the data of the current WOI have been received.
The user can indicate a new WOI whenever, without
having to wait for the completion of the previous one.
The client cache stores all the data-bins received from the server, for all
the WOIs of all the images explored by the user. The server
maintains a model of the content of this cache, that allows it to avoid to
send to the client data that it already has. For instance, let's assume a user, after
exploring a certain $WOI_A$, requests then a new $WOI_B$ that has an
overlapping with $WOI_A$. If a server maintains updated the cache model of the
content of the client cache of the user, when the $WOI_B$ is requested, the
server only sends the data-bins necessary to reconstruct the part of $WOI_B$
that is not in common with $WOI_A$. If all the data-bins that allow to
construct a certain $WOI_i$ are defined by $D(WOI_i)$, we can say that the
server sends the data-bins $D(WOI_B) - \left( D(WOI_A) \bigcap D(WOI_B) \right)$.
The JPIP protocol was designed to be independent of
the used base protocol. However, the \href{http://www.ietf.org/rfc/rfc2616.txt}
{HTTP protocol}
is mainly used as base protocol, because
of the similarity of the syntax with JPIP. Moreover,
when the communication is based on HTTP, the \href{http://en.wikipedia.org/wiki/Chunked_transfer_encoding}
{chunked transfer encoding} is commonly used. The ESA JPIP server
always uses this kind of communication.
\subsection{Data-bin partition}
\label{sec:data-bins}
Data-bins encapsulate different items of the partition
of a JPEG2000 image. This new partition of data defined
by JPIP permits to identify and gather the different parts
of an image for their transmission. In the server code,
the class \hyperlink{classjpip_1_1DataBinWriter}{jpip::DataBinWriter}
is the responsible to generate the data-bins for the
transmission.
When a client/server communication is started, it is defined
which kind of data-bin stream is going to be used. JPIP
defines two kinds of streams, JPP, oriented to precincts, and
JPT, oriented to tiles. The stream type indicates what kind
of data-bins are used for the data transmission. The most used
stream type is JPP and is the only one supported by the ESA
JPIP server.
Each data-bin is unequivocally identified by the image or code-stream
to what belongs, the data-bin type and its identifier. This information
is included in the header of each data-bin.
The data-bins can be segmented for theirs transmission. A certain
set of data-bins can be divided into a random number of
segments, and they can be sent following any order. Each
segment of data-bin includes the necessary information for
its correct identification.
In Table \ref{tab:data-bins} the relation of the
different types of data-bins defined in JPIP can be observed,
showing which stream type they belongs and what information
they contain. Next the main kinds of data-bins are explained:
\begin{table}
\begin{center}
\begin{tabular}[]{{l}{l}{l}}
\textbf{Data-bin} & \textbf{Stream} & \textbf{Contained information} \\
\hline \hline
Precinct & JPP & All the packets of a precinct. \\\hline
Precinct extended & JPP & The same content with additional content. \\\hline
Tile & JPT & All the packets and markers of a tile.\\\hline
Tile extended & JPT & The same content with additional content. \\\hline
Tile header & JPT & The markers of the header of tile. \\\hline
Header & JPP/JPT & The markers of the header of a code-stream. \\\hline
Meta-data & JPP/JPT & Meta-data of an image. \\
\hline \hline
\end{tabular}
\caption{List of the data-bins defined by JPIP.}
\label{tab:data-bins}
\end{center}
\end{table}
\begin{itemize}
\item \textbf{Precinct data-bin:} Contains all the packets of
a precinct for a resolution $r$, a component $c$ and a tile $t$.
The packets are ordered within a data-bin for quality layer,
in increasing order.
Every precinct data-bin is identified by an index $I$ that is obtained
by means of the following expression:
\begin{equation*}
I = t + \left( (c + (s \times N_c)) \times N_t \right)
\end{equation*}
$N_c$ y $N_t$ are the number of components and the number of tiles
of the image to which the precinct belongs, respectively. The
index of tile, $t$, as well as the index of component $c$ and
the value $s$ begin with zero. To every precinct of every tile-component,
including all the resolutions, an unique number of
sequence $s$ is assigned. To all the precincts of the lowest resolution
a number of sequence is assigned that starts with zero to the one
located in the left-top border, and that continues increasing
by column and row respectively. In the next resolutions
a correlative sequence number is assigned to the precincts in the
same way.
\item \textbf{Tile data-bin:} Contains all the packets and markers associated
to a tile. It is composed by concatenating all the tile-parts
associated to a tile, including the markers SOT, SOD and all the
rest relevant markers. The data-bins of this kind are identified by means
of an incremental index, beginning with zero for the tile
located in the top-left border.
\item \textbf{Tile header data-bin:} Contains all the markers associated to
a certain tile. It is formed by all the markers of the headers of all the
tile-parts of a tile, without including neither the SOT nor the SOD markers.
The identifier of this data-bin has the same numeration that in the case
of the tile.
\item \textbf{Header data-bin:} Contains the main header of the code-stream,
from the SOC (included) to the first SOT marker (not included). Neither the
SOD nor the EOC marker is included either.
\item \textbf{Meta-data bins:} These data-bins appear only if
the associated image is a file of the JP2 family. The meta data-bins contain
a set of boxes of
the image file. The standard does not define
how these data-bins must be identified nor within which boxes
must be stored, but when a meta data-bin is identified by zero,
means that it will include all the boxes contained by an image.
\end{itemize}
\subsection{Sessions and channels}
A request of the client to the server can be either stateful or stateless.
The stateful requests are carried out within the context of a
communication session, which state is maintained by the server.
The stateless requests do not require any session. The use of
sessions improve the performance of the server because, for example,
when establishing a session with a certain image file, the server
opens that file and prepares it in order to be transmitted in
data-bins, so all the requests associated to that same session
do not provoke that the server makes again that process. The stateless
requests can be considered as unique sessions that end when the
server response ends.
Under a session, using stateful requests, the client can open
multiple channels, being able to perform multiple stateful
requests associated to the same session simultaneously. This
is specially useful for applications that show simultaneously
different regions of interest of the same image. The channels
can be closed and opened in independently, without affecting
to the session. To close a session would involve to close all
the channels opened associated to it.
A set of images is associated to each session. A session
implies that the server maintains a model of the client
cache. That model will be only maintained while
the session remains active. A channel, for a certain session,
is associated to a certain image and a kind of specific
data-bin stream (JPP or JPT). The channel is identified
in a unequivocal way by means of a alphanumeric assigned
by the server, and which format is completely free. The sessions
are not identified, since the identifier of the channel
must be enough to identify the channel as well as the session
to which belongs.
Many times clients are interested to maintain in the server
the client cache model between different sessions. The server
by default does not allow this possibility, beginning a new
session with a client always with a model of cache empty, although
the client cache contains initial information. In this case JPIP
defines a set of messages that allow the client to modify the model
that the server of its cache. Therefore, when the client starts
a new session with a server, it would send a resume of the current
content of its cache to improve the communication and to avoid
redundancy, usually by means of a POST message.
The cache models maintained by the servers not only
allow to avoid the redundancy between messages, but they
are also used in order to allow the client to perform
incremental requests and control the stream of data. Clients can
indicate in their requests a parameter with the maximum length
of the server response. Thanks to the cache model of
the server, the client can perform successive identical requests,
but varying that parameters, so the server sends as response
increments of information. Therefore the client has certain
control and can adapt the stream of information to the available
bandwidth and delay, but always taking into account that the server
can modify whenever the related parameter. This way of communication
is indeed the most common one in the existing implementations of
JPIP.
\subsection{Messages}
The JPIP requests are formed by means of a ASCII sequence of pairs
``parameter $=$ value''. This allows that a JPIP request can be encapsulated
within a GET message of the HTTP protocol, next to the
character '?', concatenating all the pairs with the symbol '\&'. It is
hence formed a typical HTTP request when dynamic objects are referenced
like CGI.
Some of the available parameters for a JPIP request are the followings:
\begin{itemize}
\item \textbf{``fsiz=$R_{x}$,$R_{y}$'':} Specifies the resolution
associated to the required region of interest. The server chooses
the biggest resolution of the image so its dimension $R_{x}' \times R_{y}'$
satisfies that $R_{x}' \geq R_{x}$ and $R_{y}' \geq R_{y}$. In general
this parameter includes the resolution of the user screen.
\item \textbf{``roff=$P_{x}$,$P_{y}$'':} Specifies the position of the
upper left border of the required region of interest within the
indicated resolution. If this position is not indicated, the
server assumes the value $(0,0)$.
\item \textbf{``rsiz=$S_{x}$,$S_{y}$'':} Specifies the size
of the required region of interest. The server cuts this size
in order to fit it into the real image according to the
specified resolution.
\item \textbf{``len=number of bytes'':} Client tells with
this parameter to the server the maximum number of bytes
that it can include in the response. The server takes into
account this limit, not only in the response to the
current request, but in the rest of the next client responses
within the same session.
\item \textbf{``target=image'':} This parameter identifies the image
file from which to extract the specified region of interest.
When the HTTP protocol is used, this parameter is not necessary
since the name of the image is obtained from the own URL
specified in the GET message.
\item \textbf{``cnew=protocol'':} When the client wants to open
a new channel under the same session, it uses this parameter,
indicating the protocol that must be used for this new channel. The
types of valid base protocols are ``http'' and ``http-tcp''.
\item \textbf{``cid=channel identifier'':} When the client creates
a new channel, the server sends the channel identifier, that must
be included in all the requests associated to that channel.
\item \textbf{``cclose=channel identifier'':} The client may decide
to close certain channel by means of this parameter, just specifying
the identifier of that channel.
\item \textbf{``type=stream type'':} When a new channel is created, the
client indicates what kind of data-bin stream is wanted. The main
types of data-bin streams are JPP (``jpp-stream'') and JPT
(``jpt-stream'').
\item \textbf{``model=\ldots'':} How it has been commented previously,
the client can need to tell to the server the content of its cache
in order to update the content of the cache model maintained by
the last one. For example, \texttt{model=Hm,H*,M2,P0:20}
would tell the server to include in the cache model
the main header of the code-stream, the headers of all the tiles,
the meta data-bin number 2 and the first $20$ bytes
of the precinct $0$.
\end{itemize}
esajpip-0.1~bzr33/doc/codestream.fig 0000644 0001750 0001750 00000012555 12335423210 017326 0 ustar mathieu mathieu #FIG 3.2 Produced by xfig version 3.2.5
Landscape
Center
Metric
A4
100.00
Single
-2
1200 2
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
1980 4050 3150 6660
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
1980 3375 3150 585
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
4230 585 4230 1530
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
4230 2475 4230 3420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
4230 4770 4230 5715
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 1530 4230 1530
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 3420 4230 3420
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 5715 4230 5715
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 585 6030 585
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 2475 6030 2475
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 4770 6030 4770
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 6660 6030 6660
2 2 0 1 0 0 50 -1 3 0.000 0 0 -1 0 0 5
1170 4950 1980 4950 1980 5625 1170 5625 1170 4950
2 2 0 1 0 0 50 -1 3 0.000 0 0 -1 0 0 5
1170 4050 1980 4050 1980 4725 1170 4725 1170 4050
2 2 0 1 0 0 50 -1 3 0.000 0 0 -1 0 0 5
1170 3375 1980 3375 1980 4050 1170 4050 1170 3375
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 4770 3960 4770 3960 5130 3150 5130 3150 4770
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 3060 3960 3060 3960 3420 3150 3420 3150 3060
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 2475 3960 2475 3960 2835 3150 2835 3150 2475
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 1170 3960 1170 3960 1530 3150 1530 3150 1170
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 585 3960 585 3960 945 3150 945 3150 585
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
1170 1260 1980 1260 1980 1620 1170 1620 1170 1260
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
3150 5355 3960 5355 3960 5715 3150 5715 3150 5355
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
1170 2790 1980 2790 1980 3150 1170 3150 1170 2790
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
1170 5625 1980 5625 1980 5985 1170 5985 1170 5625
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
1170 2205 1980 2205 1980 2565 1170 2565 1170 2205
2 2 0 1 0 1 50 -1 35 0.000 0 0 -1 0 0 5
1170 1620 1980 1620 1980 1980 1170 1980 1170 1620
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
3960 4365 6030 4365
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 2205 3960 2205 3960 2475 3150 2475 3150 2205
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 1530 3960 1530 3960 1980 3150 1980 3150 1530
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 5715 3960 5715 3960 6030 3150 6030 3150 5715
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 6255 3960 6255 3960 6660 3150 6660 3150 6255
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 3420 3960 3420 3960 3690 3150 3690 3150 3420
2 2 0 1 0 15 50 -1 35 0.000 0 0 -1 0 0 5
3150 3915 3960 3915 3960 4365 3150 4365 3150 3915
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
6030 585 6030 2475
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
6030 2475 6030 4365
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
1 1 1.00 60.00 60.00
1 1 1.00 60.00 60.00
6030 4770 6030 6660
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 1125 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 810 SOT\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 1440 SOD\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 4635 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 720 1620 2160 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 720 1620 2745 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 720 1620 3330 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 720 1620 4905 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 270 1575 1530 SOC\001
4 1 0 50 -1 0 11 0.0000 6 135 270 1575 1890 SIZ\001
4 1 0 50 -1 0 11 0.0000 6 135 270 1575 2475 COD\001
4 1 0 50 -1 0 11 0.0000 6 150 270 1575 3060 QCD\001
4 1 0 50 -1 0 11 0.0000 6 135 270 1575 5895 SOC\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 3015 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 2700 SOT\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 3330 SOD\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 5310 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 4995 SOT\001
4 1 0 50 -1 0 11 0.0000 6 135 270 3555 5625 SOD\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 5940 packet\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 2385 packet\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 2160 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 1800 packet\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 6210 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 6480 packet\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 3600 packet\001
4 1 0 50 -1 0 11 0.0000 6 135 720 3600 3870 $\\cdots$\001
4 1 0 50 -1 0 11 0.0000 6 165 540 3555 4185 packet\001
4 1 0 50 -1 0 11 0.0000 6 135 360 1575 3780 tile\001
4 1 0 50 -1 0 11 0.0000 6 135 360 1575 4410 tile\001
4 1 0 50 -1 0 11 0.0000 6 135 360 1575 5355 tile\001
4 0 0 50 -1 0 11 0.0000 6 135 630 4320 1350 or tile\001
4 0 0 50 -1 0 11 0.0000 6 165 1350 4320 1125 first tile-part\001
4 0 0 50 -1 0 11 0.0000 6 135 1170 4320 900 Header of the\001
4 0 0 50 -1 0 11 0.0000 6 165 810 6075 3465 tile-part\001
4 0 0 50 -1 0 11 0.0000 6 165 810 6075 5760 tile-part\001
4 0 0 50 -1 0 11 0.0000 6 165 810 4320 5310 tile-part\001
4 0 0 50 -1 0 11 0.0000 6 135 1170 4320 5085 Header of the\001
4 0 0 50 -1 0 11 0.0000 6 165 810 6075 1575 tile-part\001
4 0 0 50 -1 0 11 0.0000 6 165 810 4320 3015 tile-part\001
4 0 0 50 -1 0 11 0.0000 6 135 1260 4320 2790 Header of the \001
esajpip-0.1~bzr33/doc/doxygen.sty 0000644 0001750 0001750 00000016174 12335423210 016730 0 ustar mathieu mathieu \NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{doxygen}
% Packages used by this style file
\RequirePackage{alltt}
\RequirePackage{array}
\RequirePackage{calc}
\RequirePackage{color}
\RequirePackage{fancyhdr}
\RequirePackage{verbatim}
% Setup fancy headings
\pagestyle{fancyplain}
\newcommand{\clearemptydoublepage}{%
\newpage{\pagestyle{empty}\cleardoublepage}%
}
\renewcommand{\chaptermark}[1]{%
\markboth{#1}{}%
}
\renewcommand{\sectionmark}[1]{%
\markright{\thesection\ #1}%
}
\newcommand{\SERVER}{
\fancyplain{}{\bfseries SOHO JPIP server}
}
\lhead[\SERVER]{\fancyplain{}{\bfseries\rightmark}}
\rhead[\fancyplain{}{\bfseries\leftmark}]{\SERVER}
\rfoot[]{\fancyplain{}{\bfseries\thepage}}
\lfoot[\fancyplain{}{\bfseries\thepage}]{}
\cfoot{}
%---------- Internal commands used in this style file ----------------
% Generic environment used by all paragraph-based environments defined
% below. Note that the command \title{...} needs to be defined inside
% those environments!
\newenvironment{DoxyDesc}[1]{%
\begin{list}{}%
{%
\settowidth{\labelwidth}{40pt}%
\setlength{\leftmargin}{\labelwidth}%
\setlength{\parsep}{0pt}%
\setlength{\itemsep}{-4pt}%
\renewcommand{\makelabel}{\entrylabel}%
}%
\item[#1]%
}{%
\end{list}%
}
%---------- Commands used by doxygen LaTeX output generator ----------
% Used by ...
\newenvironment{DoxyPre}{%
\small%
\begin{alltt}%
}{%
\end{alltt}%
\normalsize%
}
% Used by @code ... @endcode
\newenvironment{DoxyCode}{%
\footnotesize%
\verbatim%
}{%
\endverbatim%
\normalsize%
}
% Used by @example, @include, @includelineno and @dontinclude
\newenvironment{DoxyCodeInclude}{%
\DoxyCode%
}{%
\endDoxyCode%
}
% Used by @verbatim ... @endverbatim
\newenvironment{DoxyVerb}{%
\footnotesize%
\verbatim%
}{%
\endverbatim%
\normalsize%
}
% Used by @verbinclude
\newenvironment{DoxyVerbInclude}{%
\DoxyVerb%
}{%
\endDoxyVerb%
}
% Used by numbered lists (using '-#' or ...
)
\newenvironment{DoxyEnumerate}{%
\enumerate%
}{%
\endenumerate%
}
% Used by bullet lists (using '-', @li, @arg, or )
\newenvironment{DoxyItemize}{%
\itemize%
}{%
\enditemize%
}
% Used by description lists (using ...
)
\newenvironment{DoxyDescription}{%
\description%
}{%
\enddescription%
}
% Used by @image, @dotfile, and @dot ... @enddot
% (only if caption is specified)
\newenvironment{DoxyImage}{%
\begin{figure}[H]%
\begin{center}%
}{%
\end{center}%
\end{figure}%
}
% Used by @image, @dotfile, @dot ... @enddot, and @msc ... @endmsc
% (only if no caption is specified)
\newenvironment{DoxyImageNoCaption}{%
}{%
}
% Used by @attention
\newenvironment{DoxyAttention}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @author and @authors
\newenvironment{DoxyAuthor}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @date
\newenvironment{DoxyDate}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @invariant
\newenvironment{DoxyInvariant}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @note
\newenvironment{DoxyNote}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @post
\newenvironment{DoxyPostcond}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @pre
\newenvironment{DoxyPrecond}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @remark
\newenvironment{DoxyRemark}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @return
\newenvironment{DoxyReturn}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @since
\newenvironment{DoxySince}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @see
\newenvironment{DoxySeeAlso}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @version
\newenvironment{DoxyVersion}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @warning
\newenvironment{DoxyWarning}[1]{%
\begin{DoxyDesc}{#1}%
}{%
\end{DoxyDesc}%
}
% Used by @internal
\newenvironment{DoxyInternal}[1]{%
\paragraph*{#1}%
}{%
}
% Used by @par and @paragraph
\newenvironment{DoxyParagraph}[1]{%
\begin{list}{}%
{%
\settowidth{\labelwidth}{40pt}%
\setlength{\leftmargin}{\labelwidth}%
\setlength{\parsep}{0pt}%
\setlength{\itemsep}{-4pt}%
\renewcommand{\makelabel}{\entrylabel}%
}%
\item[#1]%
}{%
\end{list}%
}
% Used by parameter lists
\newenvironment{DoxyParams}[1]{%
\begin{DoxyDesc}{#1}%
\begin{description}%
}{%
\end{description}%
\end{DoxyDesc}%
}
% is used for parameters within a detailed function description
\newenvironment{DoxyParamCaption}{%
\renewcommand{\item}[2][]{##1 {\em ##2}}%
}{%
}
% Used by return value lists
\newenvironment{DoxyRetVals}[1]{%
\begin{DoxyDesc}{#1}%
\begin{description}%
}{%
\end{description}%
\end{DoxyDesc}%
}
% Used by exception lists
\newenvironment{DoxyExceptions}[1]{%
\begin{DoxyDesc}{#1}%
\begin{description}%
}{%
\end{description}%
\end{DoxyDesc}%
}
% Used by template parameter lists
\newenvironment{DoxyTemplParams}[1]{%
\begin{DoxyDesc}{#1}%
\begin{description}%
}{%
\end{description}%
\end{DoxyDesc}%
}
\newcommand{\doxyref}[3]{\textbf{#1} (\textnormal{#2}\,\pageref{#3})}
\newenvironment{DoxyCompactList}
{\begin{list}{}{
\setlength{\leftmargin}{0.5cm}
\setlength{\itemsep}{0pt}
\setlength{\parsep}{0pt}
\setlength{\topsep}{0pt}
\renewcommand{\makelabel}{\hfill}}}
{\end{list}}
\newenvironment{DoxyCompactItemize}
{
\begin{itemize}
\setlength{\itemsep}{-3pt}
\setlength{\parsep}{0pt}
\setlength{\topsep}{0pt}
\setlength{\partopsep}{0pt}
}
{\end{itemize}}
\newcommand{\PBS}[1]{\let\temp=\\#1\let\\=\temp}
\newlength{\tmplength}
\newenvironment{TabularC}[1]
{
\setlength{\tmplength}
{\linewidth/(#1)-\tabcolsep*2-\arrayrulewidth*(#1+1)/(#1)}
\par\begin{tabular*}{\linewidth}
{*{#1}{|>{\PBS\raggedright\hspace{0pt}}p{\the\tmplength}}|}
}
{\end{tabular*}\par}
\newcommand{\entrylabel}[1]{
{\parbox[b]{\labelwidth-4pt}{\makebox[0pt][l]{\textbf{#1}}\vspace{1.5\baselineskip}}}}
\newenvironment{Desc}
{\begin{list}{}
{
\settowidth{\labelwidth}{40pt}
\setlength{\leftmargin}{\labelwidth}
\setlength{\parsep}{0pt}
\setlength{\itemsep}{-4pt}
\renewcommand{\makelabel}{\entrylabel}
}
}
{\end{list}}
\newenvironment{Indent}
{\begin{list}{}{\setlength{\leftmargin}{0.5cm}}
\item[]\ignorespaces}
{\unskip\end{list}}
\setlength{\parindent}{0cm}
\setlength{\parskip}{0.2cm}
\addtocounter{secnumdepth}{1}
\sloppy
\usepackage[T1]{fontenc}
\makeatletter
\renewcommand{\paragraph}{\@startsection{paragraph}{4}{0ex}%
{-3.25ex plus -1ex minus -0.2ex}%
{1.5ex plus 0.2ex}%
{\normalfont\normalsize\bfseries}}
\makeatother
\stepcounter{secnumdepth}
\stepcounter{tocdepth}
\definecolor{comment}{rgb}{0.5,0.0,0.0}
\definecolor{keyword}{rgb}{0.0,0.5,0.0}
\definecolor{keywordtype}{rgb}{0.38,0.25,0.125}
\definecolor{keywordflow}{rgb}{0.88,0.5,0.0}
\definecolor{preprocessor}{rgb}{0.5,0.38,0.125}
\definecolor{stringliteral}{rgb}{0.0,0.125,0.25}
\definecolor{charliteral}{rgb}{0.0,0.5,0.5}
\definecolor{vhdldigit}{rgb}{1.0,0.0,1.0}
\definecolor{vhdlkeyword}{rgb}{0.43,0.0,0.43}
\definecolor{vhdllogic}{rgb}{1.0,0.0,0.0}
\definecolor{vhdlchar}{rgb}{0.0,0.0,0.0}
esajpip-0.1~bzr33/doc/guide.tex 0000644 0001750 0001750 00000064724 12335423210 016335 0 ustar mathieu mathieu \chapter{User guide}
\section{Introduction}
\label{introduction}
The ESA JPIP server is capable to handle the following types of JPEG2000 image files:
raw J2C, JP2 and JPX with or without hyperlinks. The codestreams of the images
must comply with the following requirements:
\begin{itemize}
\item No tiles partition is allowed.
\item The progression order must be LRCP, RLCP or RPCL.
\item PLT markers must be included with the information of all the packets.
\end{itemize}
If one image does not fit these requirements then it can not be served by this
server. Moreover, although they are not mandatory, the following requirements
are strongly recommended:
\begin{itemize}
\item No tile-parts.
\item Use the RPCL progression order.
\item Use an appropriate precinct partition.
\end{itemize}
The ESA JPIP server does not transcode the images at all, serving them as it.
Therefore the last requirement is particularly recommended for big images in
order to improve the transmission efficiency. For resolution levels bigger
than $1024 \times 1024$ precincts of $512 \times 512$ or $256 \times 256$ are
recommended.
\section{Installation}
In order to install the server it is necessary to get the code (for example,
from \href{https://code.launchpad.net/esajpip}{Launchpad}) and compile it.
The code of the server has been specifically written for Linux systems, so it
has not been tested in any other platform.
For compiling the source code the libraries libproc, log4cpp and libconfig++
must be installed, for developing, on the system (see Section \ref{libraries}
for more details about these used libraries).
Just by means of one ``make'' the compilation is performed. If ``make doc'' is
used, this documentation is created automatically mixing this text with the
source code documentation (\href{http://www.stack.nl/~dimitri/doxygen/}{Doxygen}
and LaTeX are required to be installed).
In order to get running the application it is only necessary to modify the
configuration file as needed (see Section \ref{config}) and to have a caching
directory with the write permission enabled for the server.
\section{Configuration}
\label{config}
The configuration of the different parameters of the server is carried out by
means of the file ``server.cfg'', which must be located in the same directory
where the server is launched. The structure of this file is:
\begin{itemize}
\item Section ``\textit{listen\_at}'':
\begin{itemize}
\item Field ``\textit{port}'': Port used for listening.
\item Field ``\textit{address}'': IP server address used for listening. This
field can be empty meaning that the server will listen at any address available.
\end{itemize}
\item Section ``\textit{folders}'':
\begin{itemize}
\item Field ``\textit{images}'': Root of the folder where the images to serve
are stored.
\item Field ``\textit{caching}'': Root of the folder to store the cache files.
\item Field ``\textit{logging}'': Folder to store the log files.
\end{itemize}
\item Section ``\textit{connections}'':
\begin{itemize}
\item Field ``\textit{time\_out}'': It defines the timeout (in seconds) of every connection.
\item Field ``\textit{max\_number}'': The maximum number of simultaneous connections.
\end{itemize}
\item Section ``\textit{general}'':
\begin{itemize}
\item Field ``\textit{logging}'': It indicates if the log file is created (1 - Yes, 0 - No).
\item Field ``\textit{cache\_max\_time}'': Expiration time of the cache files, in seconds. If
this value is less than zero it means that no expiration time is used for the cache files.
\item Field ``\textit{max\_chunk\_size}'': Maximum chunk size used for transmission, in bytes.
\end{itemize}
\end{itemize}
Each time the server opens an image to be served, it creates a little associated cache file,
if it does not exist yet, with the related indexing information, within the configured
caching folder.
Here is an example of a configuration file, which is the default one
included in the Launchpad repository:
\lstinputlisting[numbers=none,xleftmargin=50pt]{../../server.cfg}
\section{Commands}
\label{commands}
The application accepts the following command line parameters:
\begin{itemize}
\item \textit{esa\_jpip\_server [start]}: It runs the server application.
\item \textit{esa\_jpip\_server status}: It shows some information (memory, num. of connections, etc.) of the current server process.
Currently the information shown is:
\begin{itemize}
\item The available total memory.
\item The memory consumed by the father process.
\item The memory consumed by the child process.
\item The number of connections.
\item The number of iterations (the number of times that the child process has been restarted).
\item The number of threads of the child process.
\item The CPU usage of the child process.
\end{itemize}
\item \textit{esa\_jpip\_server record [name\_file]}: It shows the same information in columns, being updated every 5 seconds. It accepts a third parameter, a name of a file where to store this information.
\item \textit{esa\_jpip\_server stop [child]}: Both processes or only the child process (depending on the second parameter) associated to the current server running are finished.
\item \textit{esa\_jpip\_server debug [child]}: It calls the debugger for the parent or child process depending on the second parameter.
\item \textit{esa\_jpip\_server clean cache}: It removes all the cache files from the cache root folder which have exceeded the ``cache\_max\_time'' field from the ``server.cfg'' file.
It also removes the existing ``.backup'' files from the same directory.
\end{itemize}
\chapter{Developer guide}
\section{Introduction}
The idea for the development of this application has been to implement a very
stable and scalable solution of a JPIP server, specifically designed for Linux
systems in order to fully profit from its characteristics. No portability
strategies has been followed.
The language chosen for the development is C++, writing the code following as
much as possible the
\href{http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml}{Google
style guide}. The code is commented according to the Javadoc format, what
allows to use the Doxygen tool and generate the documentation of the
Part \ref{sourcecode} automatically. This documentation includes, if the tool
\href{http://www.graphviz.org/}{Graphviz} is installed, the collaboration diagrams
of all the classes, as well as the call diagrams of all the functions are
generated.
No libraries strictly related to the server performance have been used, except
from the \href{http://www.sgi.com/tech/stl/}{standard STL library} and
\href{https://computing.llnl.gov/tutorials/pthreads/}{pthread}.
The used libraries (see Section \ref{libraries}) are only related to secondary
features of the application.
For the data/file
operations the classes of the namespace \hyperlink{namespacedata}{data}
are implemented. For example,
the class \hyperlink{classdata_1_1BaseFile}{data::BaseFile} is a
safe wrapper for the
FILE related functions; the classes \hyperlink{classdata_1_1InputStream}
{data::InputStream} and \hyperlink{classdata_1_1OutputStream}
{data::OutputStream} allow the binary serialization of the classes;
etc.
Regarding the IPC and threads management operations the classes of the
namespace \hyperlink{namespaceipc}{ipc} have been designed. For example,
the class \hyperlink{classipc_1_1Mutex}{ipc::Mutex} implements the
logic of a mutex; the class \hyperlink{classipc_1_1RdWrLock}
{ipc::RdWrLock} implements a reader/writer lock based on the
pthread\_rwlock functions; etc.
Working with socket has been easy thanks to the classes of the namespace
\hyperlink{namespacenet}{net}. For example, the class
\hyperlink{classnet_1_1Socket}{net::Socket} offers a powerful interface
for the socket Linux functions; the class \hyperlink{classnet_1_1SocketStream}
{net::SocketStream} allows working with sockets as continuous data streams,
compatible with the stream classes defined in the STL library; etc.
Finally, for working with the HTTP protocol the classes of the namespace
\hyperlink{namespacehttp}{http} have been implemented. Among others, the
classes \hyperlink{classhttp_1_1Request}{http::Request} and
\hyperlink{classhttp_1_1Response}{http::Response} permit to generate/generate
HTTP messages, being compatible with the STL streams.
With the help of the library \href{http://log4cpp.sourceforge.net/}{log4cpp}
a trace system has been designed in order to easy the server logging as well
as the debugging. The macros ``LOG'' and ``ERROR'' are defined to log
information and error messages respectively, whilst the macro ``TRACE'' is
defined to put debugging information in any part of the code. The debugging
logs can be enabled/disabled by means of the macro ``SHOW\_TRACES''. For
information see the content of the file \hyperlink{trace_8h}{trace.h}.
Before explaining in detail the server architecture in Section \ref{sec:architecture},
some concepts of the JPEG2000 standard (Section \ref{sec:jpeg2000}), as well as
the JPIP protocol (Section \ref{sec:jpip}) are explained, necessary to
correctly understand the server code.
The classes of the server code related to the JPEG2000 standard are defined in
the namespace \hyperlink{namespacejpeg2000}{jpeg2000}. The classes for working
with the JPIP protocol are located within the namespace \hyperlink{namespacejpip}
{jpip}. Within the text of the following sections, references to some classes
of these namespaces are given.
\section{The JPEG2000 standard}
\label{sec:jpeg2000}
\input{../jpeg2000}
\section{The JPIP protocol}
\label{sec:jpip}
\input{../jpip}
\newpage
\section{Server architecture}
\label{sec:architecture}
\begin{figure}[!b]
\centering
\resizebox{0.8\textwidth}{!}{
\input{../architecture}
}
\caption{Server architecture.}
\label{fig:server}
\end{figure}
Fig. \ref{fig:server} shows a basic representation of the server architecture. It
consists of a hybrid model combining both process and thread approaches.
There are two processes, herein after called father and child. The first one
creates the second one and is who listens for new client connections. When
a new client connection is accepted by the father process, it sends this
connection to the child process through a UNIX-domain socket in order
to be attended. The child process is who provides all the functionality
to handle the client connections. Each client connection is handled
in the child process by a dedicated thread.
The father process maintains a vector with all the open connections. When
a connection is closed by the client, the child process notifies to the
father process, through the UNIX-domain socket, in order to remove the
connection from the vector.
Since the father does not perform relevant operations, its probability of
crashing due to an error is low. On the contrary, taking into account
that the child process is how maintains all the image indexes and attends
all the client connections, it may fail due to errors or not yet fixed
bugs. When a process is crashed, all the related threads and connections
are automatically closed. In the case of the child process, the current
open connections are not closed because they are shared with the father
process. This last can detect when the child process is down and launch
a new child process. This new process, considering that it inherits the
connections vector of the father process, it is capable to reestablish the
connections without affecting the clients, that is, the clients do not
notice when the child process crashes.
This architecture provides a
fault-tolerant and robust approach for the server, as well as it
offers a good performance. The multi-threading solution
implemented in the child process is efficient in terms of memory
consumption and fast sharing/locking mechanisms. Having separated
the client handling code from the father process provides
robustness and security. In the source code of the main module
\hyperlink{esa__jpip__server_8cc}{esa\_jpip\_server.cc} can be
seen how this server architecture is created.
The configuration of the server is read from the file ``server.cfg''
(see Section \ref{config} for details). This configuration is parsed
by the class \hyperlink{classAppConfig}{AppConfig} and shared with both
the father and child process.
Between the father and child process is maintained a shared memory
block, carried out by the class \hyperlink{classAppInfo}{AppInfo}. This
allows to share information between the two processes, as well as to
provide a mechanism for getting information from other processes, like
in the case of the commands ``record'' and ``status'' (see Section
\ref{commands}).
The main parts of the child process, shown in Fig. \ref{fig:server}, are
the File manager, the Index manager and the Client manager, that
are explained in the following subsections.
Every client connection is handled by a Client manager module, in an
independent thread. This module manages the communication with the
client, serving as the JPIP interface with the sub-module Data-bin server.
This sub-module contains the code to properly generate the data-bins
associated to the client requests, implementing as well the client
cache model.
The Index manager module is the responsible to manage the image indexes stored
in memory. When client requests to open a certain JPEG2000 image, the related
Client manager module requests the Index module for the associated
indexing information. This module manages the indexing information in memory
of all the currently open images by all the Client manager modules.
The File manager module is in charge of parsing and extracting the indexing
information of the image files that are requested by the Index manager module.
The indexing information of each image is cached by means of little binary
``.cache'' files in order to avoid to repeat the indexing process when the
same image is open several times. These cache files are stored in the directory
specified in the configuration file.
\subsection{File manager}
The code of this module is contained in the class
\hyperlink{classjpeg2000_1_1FileManager}{jpeg2000::FileManager}. Its main
function is to extract the indexing information of the image files.
The supported format files are J2C, JP2 and JPX, with or without
hyperlinks. The files must also comply with the limitations specified
in Section \ref{introduction}.
The indexing information of an image file is stored in an
instance of the class \hyperlink{classjpeg2000_1_1ImageInfo}
{jpeg2000::ImageInfo}. It
contains mainly a set of \hyperlink{classdata_1_1FileSegment}
{data::FileSegment} objects (pair of offset and length information
about a file segment) regarding the main headers, PLT segments,
metadata segments, etc., of the image.
The class \hyperlink{classjpeg2000_1_1ImageInfo}
{jpeg2000::ImageInfo} as well as all of its members variables
can be serialized using the serialization classes defined in
the namespace \hyperlink{namespacedata}{data}. This makes
easy load/save indexing information from the ``.cache'' files.
When the Index manager requests to the File manager the
indexing information of an image file, this last firstly checks
whether the associated ``.cache'' file exists or not. If it
exists, it just reads it, using the serialization to an
\hyperlink{classjpeg2000_1_1ImageInfo}{jpeg2000::ImageInfo} object
and returns it. If there is not any cache file yet, it opens
the image file and parses it, generating the corresponding
cache file.
The cache files are stored in the directory defined in the configuration
file, and they are named using the full path of the image
files, replacing each directory separator '/' by underscores '\_',
and adding the extension ``.cache''.
The server does not remove any cache file during its execution. They
can be removed either manually or by means of the server command
``clean cache'' using a LRU policy specified in the server configuration
file (see Section \ref{commands}).
\subsection{Index manager}
The code of this module is contained in the class
\hyperlink{classjpeg2000_1_1IndexManager}{jpeg2000::IndexManager}. Its main
function is to manage the indexes of all the image files opened by the
server.
The index of each image is built from the indexing information retrieved
from the file manager module. Notice that the indexing information
generated by the file manager does not deal with packets, just the main
parts of the image, like the position of the main header or the
position of the PLT markers. From this initial information, the index
manager builds a complete index of all the packets of each image.
Each opened image is represented by an object of the class
\hyperlink{classjpeg2000_1_1ImageIndex}{jpeg2000::ImageIndex}. All
of these objects are handled by the index manager using a double linked
list in memory.
When a J2C, JP2 or JPX (without hyperlinks) image file is opened, a
new \hyperlink{classjpeg2000_1_1ImageIndex}{jpeg2000::ImageIndex} is created,
if it does not already exist, and inserted in the list. When a JPX
image file with hyperlinks is opened, the index manager handles each
contained hyperlink independently. In this case a new node is also
created in the list, but it contains references to all the nodes
associated to its hyperlinks. Some of them may already exist in the list,
or they have been created.
Each image node in the list contains a reference count When this
count value gets zero, the node is removed from the list. The number
of references is incremented each time a client manager requests
for the associated image file, or when a JPX file is opened that
contains a link to that image file.
When a client manager opens a new channel, it requests to the index
manager for the index of the image associated to this new channel.
The index manager returns a reference of an object of the class
\hyperlink{classjpeg2000_1_1ImageIndex}{jpeg2000::ImageIndex}.
The packet index (handled by means of the class
\hyperlink{classjpeg2000_1_1PacketIndex}{jpeg2000::PacketIndex}) of
each image file is created on demand, by resolution level. In order
to support this feature, the image file must be compressed
with the progression order RPCL. On the contrary, the packet index
is fully created at the beginning, when the image file is opened.
This way of creating the index allows to adjust the memory
consumption required for the indexes according to the user
movements through the image.
The modifications (inserting or removing nodes) of the list of indexes
are controlled by a mutex lock. However, each index node contains its
own independent locking mechanism for the modifications of the packet
index. Multiple threads, associated each one to a client manager,
can be working with the same image index node. If the packet index
does not allow to be generated on demand, the main operation of
all the threads over the packet index is to read. When the RPCL
progression is used and the packet index can be built on demand,
any thread can modify it (e.g. accessing to a new resolution
level). A reader/writer lock mechanism has been chosen for controlling
the modifications/accesses of the packet indexes, giving priority to
the read operations (the most common ones) over the write operations.
The class \hyperlink{classjpeg2000_1_1PacketIndex}{jpeg2000::PacketIndex}
uses internally the class \hyperlink{classdata_1_1vint__vector}
{data::vint\_vector} to stores the information of each packet. This
class allows to use vectors of integers where each integer value can
occupy a number of bytes not necessarily multiple of $2$. For example,
if an image contains less than $2^{24}$ packets, each packet can
be represented in the index by just $3$ bytes, instead of the minimal
standard $4$ bytes.
The information stored of each packet in the index vector
is only the associated file offset. If the image file contains several tile-parts,
not recommended, thus dividing the set of packets in not contiguous segments,
special markers are included to identify the offset jumps.
\subsection{Client manager}
The class \hyperlink{classClientManager}{ClientManager} contains the required
code to handle a client connection. When a new client connection is established
by the server, a new instance of this class is created passing a reference
to the application shared information (\hyperlink{classAppInfo}{AppInfo}), a
reference of the server configuration information (\hyperlink{classAppConfig}
{AppConfig}) and a reference to the Index manager (\hyperlink{classjpeg2000_1_1IndexManager}
{jpeg2000::IndexManager}). A new
thread is created for this connection which calls the method ``Run''
of the class.
The function of the code of the class \hyperlink{classClientManager}{ClientManager}
is basically to parse the client requests (with the help of the class
\hyperlink{classjpip_1_1Request}{jpip::Request}) and form the appropriate responses,
all of them according to the JPIP protocol in HTTP format. It implements a basic
channel handling mechanism, as well as the interface with the Index manager, in
order to, when a new image file is requested by the client, get the associated
index.
Although the standard allows to use several channels over the same connection,
this implementation does not allow this feature. In practice, the most of the
applications do not use more than just one channel per connection, like for example
in the case of the viewer kdu\_show, from the Kakadu library, or JHelioviewer. This
means that the JPIP concepts of channel and session refer in this implementation
to the same thing. However, in the same connection, the client can open and
close several channels as many times as required, but considering that only
one channel can be opened at the same time.
In order to identify the channel opened by the client, a simple integer number
is used, which is incremented each time the client opens and closes a channel.
The target identifier returned by the server, when a channel is opened, and
that is commonly used by the JPIP clients to perform local caching, is the
full path of the associated image file. This avoids the coherence problems
detected in other server implementations (like in the case of the kdu\_server)
when using complex hash values.
Taking into account that the child process can be restarted, and the client
manager might be started over an existing client connection, a mechanism to
find out the data already sent to the client, but without requesting it,
has been implemented. Each time all the complete data of a WOI has been
sent to the client, a little ``.backup'' file is created in the caching
directory with the content of the client cache model. Therefore, when
a client manager is started, it checks whether an associated ``.backup''
exists or not, loading its information as the current content of the
client cache model if so.
The main flow chart of the code of the client manager module can be observed in
Fig. \ref{fig:client_manager}. In the processing step of generating a new
chunk of data is when the data-bin server module is called.
\begin{figure}
\centering
\resizebox{0.9\textwidth}{!}{
\input{../client_manager}
}
\caption{Flow chart of the client manager.}
\label{fig:client_manager}
\end{figure}
\subsection{Data-bin server}
The code of this module is located at the class \hyperlink{classjpip_1_1DataBinServer}
{jpip::DataBinServer}. This module manages the data that is served to a client, having
methods to generate chunks and data-bins, as well as it maintains the client cache
model.
The client cache model is managed with the help of the class
\hyperlink{classjpip_1_1CacheModel}{jpip::CacheModel}. This class can be serialized,
what make easy saving/loading the ``.backup'' files generated by the client manager.
The data-bin server module uses the methods of the class
\hyperlink{classjpip_1_1DataBinWriter}{jpip::DataBinWriter} for generating the
data-bins that will be sent to the client by the client manager.
Once the client manager receives a WOI request from the client, it is passed to
the data-bin server, which parses it and prepares the related resources for
the data-bin generation. For
instance, when the WOI specifies a set of hyperlinked layers within a JPX file,
the data-bin server opens the associated files putting them ready for
extracting packets. An object of the class \hyperlink{classjpip_1_1WOIComposer}
{WOIComposer} is also prepared to explore the packets associated to the
WOI specified in the client request.
For each WOI request the client manager sends JPIP responses encapsulated in
HTTP messages, and using the chunked transfer encoding. The maximum length
of each chunk is determined by the value specified within the configuration
file. The method ``GenerateChunk'' of the class \hyperlink{classjpip_1_1DataBinServer}
{jpip::DataBinServer} is able to fill a memory buffer, usually related to
a chunk data, with data-bins, according to the current client cache model and
the last passed request. This is the method used by the client manager to
generate the responses.
The data-bin server generates a new chunk of data-bins considering the data
already sent, recorded in the client cache model. Therefore, if the first
$N$ bytes of a precinct data-bin has been already sent to the client, in
the next chunk generation, these first $N$ bytes of the same precinct are
not included.
The sequence of data-bins that are included when a new data chunk is generated,
calling the ``GenerateChunk'' method, is as follows:
\begin{enumerate}
\item All the metadatas
\item For each codestream:
\begin{enumerate}
\item Main-header
\item Tile-header
\end{enumerate}
\item For each packet given by the \hyperlink{classjpip_1_1WOIComposer}{WOIComposer}:
\begin{enumerate}
\item For each codestream: Precinct
\end{enumerate}
\end{enumerate}
Notice that, as it has been commented, the chunk generation and data-bin
inclusion is incremental according to the client cache model and the previous
sequence. For example, if
the metadata of an image file occupies $1$ MByte, and the chunk size is $1$ KB,
more than $1000$ chunks would be required to be generated before being able to
generate the first chunk with packet data (precinct).
\section{Libraries}
\label{libraries}
The application uses the following libraries:
\begin{itemize}
\item \textit{Libconfig++}: The libconfig++ library (\href{http://www.hyperrealm.com/libconfig/}{http://www.hyperrealm.com/libconfig/}) is used to read the
information of the configuration file of the server. The configuration
file accepts C-like comments.
\item \textit{Libproc}: The general information about the server process is shown thanks to this library (\href{http://packages.debian.org/sid/libproc-dev/}{http://packages.debian.org/sid/libproc-dev/}).
\item \textit{Log4cpp}: This library is in charge of flexible logging to file (\href{http://log4cpp.sourceforge.net/}{http://log4cpp.sourceforge.net/}).
\end{itemize}
esajpip-0.1~bzr33/doc/doxyfile 0000644 0001750 0001750 00000210611 12335423210 016250 0 ustar mathieu mathieu # Doxyfile 1.7.1
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project
#
# All text after a hash (#) is considered a comment and will be ignored
# The format is:
# TAG = value [value, ...]
# For lists items can also be appended using:
# TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ")
#---------------------------------------------------------------------------
# Project related configuration options
#---------------------------------------------------------------------------
# This tag specifies the encoding used for all characters in the config file
# that follow. The default is UTF-8 which is also the encoding used for all
# text before the first occurrence of this tag. Doxygen uses libiconv (or the
# iconv built into libc) for the transcoding. See
# http://www.gnu.org/software/libiconv for the list of possible encodings.
DOXYFILE_ENCODING = UTF-8
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
# by quotes) that should identify the project.
PROJECT_NAME = "ESA JPIP server"
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.
PROJECT_NUMBER = 0.1
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.
OUTPUT_DIRECTORY = __DOC_DIR__
# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.
CREATE_SUBDIRS = NO
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrilic, Slovak,
# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
OUTPUT_LANGUAGE = English
# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
# Set to NO to disable this.
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
# the brief description of a member or function before the detailed description.
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
# brief descriptions will be completely suppressed.
REPEAT_BRIEF = YES
# This tag implements a quasi-intelligent brief description abbreviator
# that is used to form the text in various listings. Each string
# in this list, if found as the leading text of the brief description, will be
# stripped from the text and the result after processing the whole list, is
# used as the annotated text. Otherwise, the brief description is used as-is.
# If left blank, the following values are used ("$name" is automatically
# replaced with the name of the entity): "The $name class" "The $name widget"
# "The $name file" "is" "provides" "specifies" "contains"
# "represents" "a" "an" "the"
ABBREVIATE_BRIEF = "The $name class" \
"The $name widget" \
"The $name file" \
is \
provides \
specifies \
contains \
represents \
a \
an \
the
# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
# Doxygen will generate a detailed section even if there is only a brief
# description.
ALWAYS_DETAILED_SEC = YES
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
# members were ordinary class members. Constructors, destructors and assignment
# operators of the base classes will not be shown.
INLINE_INHERITED_MEMB = NO
# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
# path before files name in the file list and in the header files. If set
# to NO the shortest path that makes the file name unique will be used.
FULL_PATH_NAMES = YES
# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
# can be used to strip a user-defined part of the path. Stripping is
# only done if one of the specified strings matches the left-hand part of
# the path. The tag can be used to show relative paths in the file list.
# If left blank the directory from which doxygen is run is used as the
# path to strip.
STRIP_FROM_PATH = __SRC_DIR__
# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
# the path mentioned in the documentation of a class, which tells
# the reader which header file to include in order to use a class.
# If left blank only the name of the header file containing the class
# definition is used. Otherwise one should specify the include paths that
# are normally passed to the compiler using the -I flag.
STRIP_FROM_INC_PATH =
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
# (but less readable) file names. This can be useful is your file systems
# doesn't support long names like on DOS, Mac, or CD-ROM.
SHORT_NAMES = NO
# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like regular Qt-style comments
# (thus requiring an explicit @brief command for a brief description.)
JAVADOC_AUTOBRIEF = YES
# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
# interpret the first line (until the first dot) of a Qt-style
# comment as the brief description. If set to NO, the comments
# will behave just like regular Qt-style comments (thus requiring
# an explicit \brief command for a brief description.)
QT_AUTOBRIEF = NO
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
# comments) as a brief description. This used to be the default behaviour.
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = NO
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
# re-implements.
INHERIT_DOCS = YES
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
# a new page for each member. If set to NO, the documentation of a member will
# be part of the file/class/namespace that contains it.
SEPARATE_MEMBER_PAGES = NO
# The TAB_SIZE tag can be used to set the number of spaces in a tab.
# Doxygen uses this value to replace tabs by spaces in code fragments.
TAB_SIZE = 2
# This tag can be used to specify a number of aliases that acts
# as commands in the documentation. An alias has the form "name=value".
# For example adding "sideeffect=\par Side Effects:\n" will allow you to
# put the command \sideeffect (or @sideeffect) in the documentation, which
# will result in a user-defined paragraph with heading "Side Effects:".
# You can put \n's in the value part of an alias to insert newlines.
ALIASES =
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
# sources only. Doxygen will then generate output that is more tailored for C.
# For instance, some of the names that are used will be different. The list
# of all members will be omitted, etc.
OPTIMIZE_OUTPUT_FOR_C = NO
# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
# sources only. Doxygen will then generate output that is more tailored for
# Java. For instance, namespaces will be presented as packages, qualified
# scopes will look different, etc.
OPTIMIZE_OUTPUT_JAVA = NO
# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
# sources only. Doxygen will then generate output that is more tailored for
# Fortran.
OPTIMIZE_FOR_FORTRAN = NO
# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
# sources. Doxygen will then generate output that is tailored for
# VHDL.
OPTIMIZE_OUTPUT_VHDL = NO
# Doxygen selects the parser to use depending on the extension of the files it
# parses. With this tag you can assign which parser to use for a given extension.
# Doxygen has a built-in mapping, but you can override or extend it using this
# tag. The format is ext=language, where ext is a file extension, and language
# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
EXTENSION_MAPPING =
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
# to include (a tag file for) the STL sources as input, then you should
# set this tag to YES in order to let doxygen match functions declarations and
# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
# func(std::string) {}). This also make the inheritance and collaboration
# diagrams that involve STL classes more complete and accurate.
BUILTIN_STL_SUPPORT = YES
# If you use Microsoft's C++/CLI language, you should set this option to YES to
# enable parsing support.
CPP_CLI_SUPPORT = NO
# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
# Doxygen will parse them like normal C++ but will assume all classes use public
# instead of private inheritance when no explicit protection keyword is present.
SIP_SUPPORT = NO
# For Microsoft's IDL there are propget and propput attributes to indicate getter
# and setter methods for a property. Setting this option to YES (the default)
# will make doxygen to replace the get and set methods by a property in the
# documentation. This will only work if the methods are indeed getting or
# setting a simple type. If this is not the case, or you want to show the
# methods anyway, you should set this option to NO.
IDL_PROPERTY_SUPPORT = YES
# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
# tag is set to YES, then doxygen will reuse the documentation of the first
# member in the group (if any) for the other members of the group. By default
# all members of a group must be documented explicitly.
DISTRIBUTE_GROUP_DOC = NO
# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
# the same type (for instance a group of public functions) to be put as a
# subgroup of that type (e.g. under the Public Functions section). Set it to
# NO to prevent subgrouping. Alternatively, this can be done per class using
# the \nosubgrouping command.
SUBGROUPING = YES
# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
# is documented as struct, union, or enum with the name of the typedef. So
# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
# with name TypeT. When disabled the typedef will appear as a member of a file,
# namespace, or class. And the struct will be named TypeS. This can typically
# be useful for C code in case the coding convention dictates that all compound
# types are typedef'ed and only the typedef is referenced, never the tag name.
TYPEDEF_HIDES_STRUCT = NO
# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
# determine which symbols to keep in memory and which to flush to disk.
# When the cache is full, less often used symbols will be written to disk.
# For small to medium size projects (<1000 input files) the default value is
# probably good enough. For larger projects a too small cache size can cause
# doxygen to be busy swapping symbols to and from disk most of the time
# causing a significant performance penality.
# If the system has enough physical memory increasing the cache will improve the
# performance by keeping more symbols in memory. Note that the value works on
# a logarithmic scale so increasing the size by one will rougly double the
# memory usage. The cache size is given by this formula:
# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
# corresponding to a cache size of 2^16 = 65536 symbols
SYMBOL_CACHE_SIZE = 0
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
# documentation are documented, even if no documentation was available.
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = YES
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = YES
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = YES
# This flag is only useful for Objective-C code. When set to YES local
# methods, which are defined in the implementation section but not in
# the interface are included in the documentation.
# If set to NO (the default) only methods in the interface are included.
EXTRACT_LOCAL_METHODS = YES
# If this flag is set to YES, the members of anonymous namespaces will be
# extracted and appear in the documentation as a namespace called
# 'anonymous_namespace{file}', where file will be replaced with the base
# name of the file that contains the anonymous namespace. By default
# anonymous namespace are hidden.
EXTRACT_ANON_NSPACES = NO
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES = NO
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
HIDE_FRIEND_COMPOUNDS = NO
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
HIDE_IN_BODY_DOCS = NO
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
INTERNAL_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# and Mac users are advised to set this option to NO.
CASE_SENSE_NAMES = YES
# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
HIDE_SCOPE_NAMES = NO
# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
# will put a list of the files that are included by a file in the documentation
# of that file.
SHOW_INCLUDE_FILES = YES
# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
# will list include files with double quotes in the documentation
# rather than with sharp brackets.
FORCE_LOCAL_INCLUDES = NO
# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
# is inserted in the documentation for inline members.
INLINE_INFO = YES
# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
# will sort the (detailed) documentation of file and class members
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
# brief documentation of file, namespace and class members alphabetically
# by member name. If set to NO (the default) the members will appear in
# declaration order.
SORT_BRIEF_DOCS = NO
# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
# will sort the (brief and detailed) documentation of class members so that
# constructors and destructors are listed first. If set to NO (the default)
# the constructors will appear in the respective orders defined by
# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
SORT_MEMBERS_CTORS_1ST = NO
# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
# hierarchy of group names into alphabetical order. If set to NO (the default)
# the group names will appear in their defined order.
SORT_GROUP_NAMES = NO
# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
# sorted by fully-qualified names, including namespaces. If set to
# NO (the default), the class list will be sorted only by class name,
# not including the namespace part.
# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
# Note: This option applies only to the class list, not to the
# alphabetical list.
SORT_BY_SCOPE_NAME = NO
# The GENERATE_TODOLIST tag can be used to enable (YES) or
# disable (NO) the todo list. This list is created by putting \todo
# commands in the documentation.
GENERATE_TODOLIST = YES
# The GENERATE_TESTLIST tag can be used to enable (YES) or
# disable (NO) the test list. This list is created by putting \test
# commands in the documentation.
GENERATE_TESTLIST = YES
# The GENERATE_BUGLIST tag can be used to enable (YES) or
# disable (NO) the bug list. This list is created by putting \bug
# commands in the documentation.
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
ENABLED_SECTIONS =
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
# the initial value of a variable or define consists of for it to appear in
# the documentation. If the initializer consists of more lines than specified
# here it will be hidden. Use a value of 0 to hide initializers completely.
# The appearance of the initializer of individual variables and defines in the
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
SHOW_USED_FILES = YES
# If the sources in your project are distributed over multiple directories
# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
# in the documentation. The default is NO.
SHOW_DIRECTORIES = NO
# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
# This will remove the Files entry from the Quick Index and from the
# Folder Tree View (if specified). The default is YES.
SHOW_FILES = YES
# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
# Namespaces page. This will remove the Namespaces entry from the Quick Index
# and from the Folder Tree View (if specified). The default is YES.
SHOW_NAMESPACES = YES
# The FILE_VERSION_FILTER tag can be used to specify a program or script that
# doxygen should invoke to get the current version for each file (typically from
# the version control system). Doxygen will invoke the program by executing (via
# popen()) the command , where is the value of
# the FILE_VERSION_FILTER tag, and is the name of an input file
# provided by doxygen. Whatever the program writes to standard output
# is used as the file version. See the manual for examples.
FILE_VERSION_FILTER =
# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
# by doxygen. The layout file controls the global structure of the generated
# output files in an output format independent way. The create the layout file
# that represents doxygen's defaults, run doxygen with the -l option.
# You can optionally specify a file name after the option, if omitted
# DoxygenLayout.xml will be used as the name of the layout file.
LAYOUT_FILE =
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
# The QUIET tag can be used to turn on/off the messages that are generated
# by doxygen. Possible values are YES and NO. If left blank NO is used.
QUIET = NO
# The WARNINGS tag can be used to turn on/off the warning messages that are
# generated by doxygen. Possible values are YES and NO. If left blank
# NO is used.
WARNINGS = YES
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some
# parameters in a documented function, or documenting parameters that
# don't exist or using markup commands wrongly.
WARN_IF_DOC_ERROR = YES
# This WARN_NO_PARAMDOC option can be abled to get warnings for
# functions that are documented, but have no documentation for their parameters
# or return value. If set to NO (the default) doxygen will only warn about
# wrong or incomplete parameter documentation, but not about the absence of
# documentation.
WARN_NO_PARAMDOC = NO
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# warning originated and the warning text. Optionally the format may contain
# $version, which will be replaced by the version of the file (if it could
# be obtained via FILE_VERSION_FILTER)
WARN_FORMAT = "$file:$line: $text"
# The WARN_LOGFILE tag can be used to specify a file to which warning
# and error messages should be written. If left blank the output is written
# to stderr.
WARN_LOGFILE =
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT = __SRC_DIR__
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
# also the default input encoding. Doxygen uses libiconv (or the iconv built
# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
# the list of possible encodings.
INPUT_ENCODING = UTF-8
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
FILE_PATTERNS = *.c \
*.cc \
*.cxx \
*.cpp \
*.c++ \
*.d \
*.java \
*.ii \
*.ixx \
*.ipp \
*.i++ \
*.inl \
*.h \
*.hh \
*.hxx \
*.hpp \
*.h++ \
*.idl \
*.odl \
*.cs \
*.php \
*.php3 \
*.inc \
*.m \
*.mm \
*.dox \
*.py \
*.f90 \
*.f \
*.vhd \
*.vhdl
# The RECURSIVE tag can be used to turn specify whether or not subdirectories
# should be searched for input files as well. Possible values are YES and NO.
# If left blank NO is used.
RECURSIVE = YES
# The EXCLUDE tag can be used to specify files and/or directories that should
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
EXCLUDE =
# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
# directories that are symbolic links (a Unix filesystem feature) are excluded
# from the input.
EXCLUDE_SYMLINKS = NO
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories. Note that the wildcards are matched
# against the file with absolute path, so to exclude all test directories
# for example use the pattern */test/*
EXCLUDE_PATTERNS =
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the
# output. The symbol name can be a fully qualified name, a word, or if the
# wildcard * is used, a substring. Examples: ANamespace, AClass,
# AClass::ANamespace, ANamespace::*Test
EXCLUDE_SYMBOLS =
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
# the \include command).
EXAMPLE_PATH =
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank all files are included.
EXAMPLE_PATTERNS = *
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
# searched for input files to be used with the \include or \dontinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
EXAMPLE_RECURSIVE = NO
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
# the \image command).
IMAGE_PATH =
# The INPUT_FILTER tag can be used to specify a program that doxygen should
# invoke to filter for each input file. Doxygen will invoke the filter program
# by executing (via popen()) the command , where
# is the value of the INPUT_FILTER tag, and is the name of an
# input file. Doxygen will then use the output that the filter program writes
# to standard output. If FILTER_PATTERNS is specified, this tag will be
# ignored.
INPUT_FILTER =
# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
# basis. Doxygen will compare the file name with each pattern and apply the
# filter if there is a match. The filters are a list of the form:
# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
# is applied to all files.
FILTER_PATTERNS =
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER) will be used to filter the input files when producing source
# files to browse (i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_FILES = NO
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
# If the SOURCE_BROWSER tag is set to YES then a list of source files will
# be generated. Documented entities will be cross-referenced with these sources.
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = NO
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.
INLINE_SOURCES = NO
# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
# doxygen to hide any special comment blocks from generated source code
# fragments. Normal C and C++ comments will always remain visible.
STRIP_CODE_COMMENTS = YES
# If the REFERENCED_BY_RELATION tag is set to YES
# then for each documented function all documented
# functions referencing it will be listed.
REFERENCED_BY_RELATION = NO
# If the REFERENCES_RELATION tag is set to YES
# then for each documented function all documented entities
# called/used by that function will be listed.
REFERENCES_RELATION = NO
# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
# link to the source code. Otherwise they will link to the documentation.
REFERENCES_LINK_SOURCE = YES
# If the USE_HTAGS tag is set to YES then the references to source code
# will point to the HTML generated by the htags(1) tool instead of doxygen
# built-in source browser. The htags tool is part of GNU's global source
# tagging system (see http://www.gnu.org/software/global/global.html). You
# will need version 4.8.6 or higher.
USE_HTAGS = NO
# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
# will generate a verbatim copy of the header file for each class for
# which an include is specified. Set to NO to disable this.
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
# of all compounds will be generated. Enable this if the project
# contains a lot of classes, structs, unions or interfaces.
ALPHABETICAL_INDEX = YES
# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
# in which this list will be split (can be a number in the range [1..20])
COLS_IN_ALPHA_INDEX = 5
# In case all classes in a project start with a common prefix, all
# classes will be put under the same header in the alphabetical index.
# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
# should be ignored while generating the index headers.
IGNORE_PREFIX =
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
# generate HTML output.
GENERATE_HTML = YES
# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `html' will be used as the default path.
HTML_OUTPUT = html
# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
# doxygen will generate files with .html extension.
HTML_FILE_EXTENSION = .html
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header.
HTML_HEADER =
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet. Note that doxygen will try to copy
# the style sheet file to the HTML output directory, so don't put your own
# stylesheet in the HTML output directory as well, or it will be erased!
HTML_STYLESHEET =
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
# Doxygen will adjust the colors in the stylesheet and background images
# according to this color. Hue is specified as an angle on a colorwheel,
# see http://en.wikipedia.org/wiki/Hue for more information.
# For instance the value 0 represents red, 60 is yellow, 120 is green,
# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
# The allowed range is 0 to 359.
HTML_COLORSTYLE_HUE = 220
# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
# the colors in the HTML output. For a value of 0 the output will use
# grayscales only. A value of 255 will produce the most vivid colors.
HTML_COLORSTYLE_SAT = 100
# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
# the luminance component of the colors in the HTML output. Values below
# 100 gradually make the output lighter, whereas values above 100 make
# the output darker. The value divided by 100 is the actual gamma applied,
# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
# and 100 does not change the gamma.
HTML_COLORSTYLE_GAMMA = 80
# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
# page will contain the date and time when the page was generated. Setting
# this to NO can help when comparing the output of multiple runs.
HTML_TIMESTAMP = YES
# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
# files or namespaces will be aligned in HTML using tables. If set to
# NO a bullet list will be used.
HTML_ALIGN_MEMBERS = YES
# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
# documentation will contain sections that can be hidden and shown after the
# page has loaded. For this to work a browser that supports
# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
HTML_DYNAMIC_SECTIONS = NO
# If the GENERATE_DOCSET tag is set to YES, additional index files
# will be generated that can be used as input for Apple's Xcode 3
# integrated development environment, introduced with OSX 10.5 (Leopard).
# To create a documentation set, doxygen will generate a Makefile in the
# HTML output directory. Running make will produce the docset in that
# directory and running "make install" will install the docset in
# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
# it at startup.
# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
# for more information.
GENERATE_DOCSET = NO
# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
# feed. A documentation feed provides an umbrella under which multiple
# documentation sets from a single provider (such as a company or product suite)
# can be grouped.
DOCSET_FEEDNAME = "Doxygen generated docs"
# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
# should uniquely identify the documentation set bundle. This should be a
# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
# will append .docset to the name.
DOCSET_BUNDLE_ID = org.doxygen.Project
# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
# the documentation publisher. This should be a reverse domain-name style
# string, e.g. com.mycompany.MyDocSet.documentation.
DOCSET_PUBLISHER_ID = org.doxygen.Publisher
# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
DOCSET_PUBLISHER_NAME = Publisher
# If the GENERATE_HTMLHELP tag is set to YES, additional index files
# will be generated that can be used as input for tools like the
# Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
# of the generated HTML documentation.
GENERATE_HTMLHELP = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
# be used to specify the file name of the resulting .chm file. You
# can add a path in front of the file if the result should not be
# written to the html output directory.
CHM_FILE =
# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
# be used to specify the location (absolute path including file name) of
# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
# the HTML help compiler on the generated index.hhp.
HHC_LOCATION =
# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
# controls if a separate .chi index file is generated (YES) or that
# it should be included in the master .chm file (NO).
GENERATE_CHI = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
# is used to encode HtmlHelp index (hhk), content (hhc) and project file
# content.
CHM_INDEX_ENCODING =
# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
# controls whether a binary table of contents is generated (YES) or a
# normal table of contents (NO) in the .chm file.
BINARY_TOC = NO
# The TOC_EXPAND flag can be set to YES to add extra items for group members
# to the contents of the HTML help documentation and to the tree view.
TOC_EXPAND = NO
# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
# that can be used as input for Qt's qhelpgenerator to generate a
# Qt Compressed Help (.qch) of the generated HTML documentation.
GENERATE_QHP = NO
# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
# be used to specify the file name of the resulting .qch file.
# The path specified is relative to the HTML output folder.
QCH_FILE =
# The QHP_NAMESPACE tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#namespace
QHP_NAMESPACE = org.doxygen.Project
# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#virtual-folders
QHP_VIRTUAL_FOLDER = doc
# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
# add. For more information please see
# http://doc.trolltech.com/qthelpproject.html#custom-filters
QHP_CUST_FILTER_NAME =
# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
# custom filter to add. For more information please see
#
# Qt Help Project / Custom Filters.
QHP_CUST_FILTER_ATTRS =
# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
# project's
# filter section matches.
#
# Qt Help Project / Filter Attributes.
QHP_SECT_FILTER_ATTRS =
# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
# be used to specify the location of Qt's qhelpgenerator.
# If non-empty doxygen will try to run qhelpgenerator on the generated
# .qhp file.
QHG_LOCATION =
# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
# will be generated, which together with the HTML files, form an Eclipse help
# plugin. To install this plugin and make it available under the help contents
# menu in Eclipse, the contents of the directory containing the HTML and XML
# files needs to be copied into the plugins directory of eclipse. The name of
# the directory within the plugins directory should be the same as
# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
# the help appears.
GENERATE_ECLIPSEHELP = NO
# A unique identifier for the eclipse help plugin. When installing the plugin
# the directory name containing the HTML and XML files should also have
# this name.
ECLIPSE_DOC_ID = org.doxygen.Project
# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
# top of each HTML page. The value NO (the default) enables the index and
# the value YES disables it.
DISABLE_INDEX = NO
# This tag can be used to set the number of enum values (range [1..20])
# that doxygen will group on one line in the generated HTML documentation.
ENUM_VALUES_PER_LINE = 4
# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
# structure should be generated to display hierarchical information.
# If the tag value is set to YES, a side panel will be generated
# containing a tree-like index structure (just like the one that
# is generated for HTML Help). For this to work a browser that supports
# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
# Windows users are probably better off using the HTML help feature.
GENERATE_TREEVIEW = YES
# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories,
# and Class Hierarchy pages using a tree view instead of an ordered list.
USE_INLINE_TREES = NO
# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
# used to set the initial width (in pixels) of the frame in which the tree
# is shown.
TREEVIEW_WIDTH = 250
# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
# links to external symbols imported via tag files in a separate window.
EXT_LINKS_IN_WINDOW = NO
# Use this tag to change the font size of Latex formulas included
# as images in the HTML documentation. The default is 10. Note that
# when you change the font size after a successful doxygen run you need
# to manually remove any form_*.png images from the HTML output directory
# to force them to be regenerated.
FORMULA_FONTSIZE = 10
# Use the FORMULA_TRANPARENT tag to determine whether or not the images
# generated for formulas are transparent PNGs. Transparent PNGs are
# not supported properly for IE 6.0, but are supported on all modern browsers.
# Note that when changing this option you need to delete any form_*.png files
# in the HTML output before the changes have effect.
FORMULA_TRANSPARENT = YES
# When the SEARCHENGINE tag is enabled doxygen will generate a search box
# for the HTML output. The underlying search engine uses javascript
# and DHTML and should work on any modern browser. Note that when using
# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
# (GENERATE_DOCSET) there is already a search function so this one should
# typically be disabled. For large projects the javascript based search engine
# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
SEARCHENGINE = NO
# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
# implemented using a PHP enabled web server instead of at the web client
# using Javascript. Doxygen will generate the search PHP script and index
# file to put on the web server. The advantage of the server
# based approach is that it scales better to large projects and allows
# full text search. The disadvances is that it is more difficult to setup
# and does not have live searching capabilities.
SERVER_BASED_SEARCH = NO
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
# generate Latex output.
GENERATE_LATEX = YES
# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `latex' will be used as the default path.
LATEX_OUTPUT = latex
# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
# invoked. If left blank `latex' will be used as the default command name.
# Note that when enabling USE_PDFLATEX this option is only used for
# generating bitmaps for formulas in the HTML output, but not in the
# Makefile that is written to the output directory.
LATEX_CMD_NAME = latex
# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
# generate index for LaTeX. If left blank `makeindex' will be used as the
# default command name.
MAKEINDEX_CMD_NAME = makeindex
# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
# LaTeX documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_LATEX = NO
# The PAPER_TYPE tag can be used to set the paper type that is used
# by the printer. Possible values are: a4, a4wide, letter, legal and
# executive. If left blank a4wide will be used.
PAPER_TYPE = a4wide
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
# packages that should be included in the LaTeX output.
EXTRA_PACKAGES =
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
# the generated latex document. The header should contain everything until
# the first chapter. If it is left blank doxygen will generate a
# standard header. Notice: only use this tag if you know what you are doing!
LATEX_HEADER = header.tex
# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
# is prepared for conversion to pdf (using ps2pdf). The pdf file will
# contain links (just like the HTML output) instead of page references
# This makes the output suitable for online browsing using a pdf viewer.
PDF_HYPERLINKS = YES
# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
# plain latex in the generated Makefile. Set this option to YES to get a
# higher quality PDF documentation.
USE_PDFLATEX = YES
# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
# command to the generated LaTeX files. This will instruct LaTeX to keep
# running if errors occur, instead of asking the user for help.
# This option is also used when generating formulas in HTML.
LATEX_BATCHMODE = NO
# If LATEX_HIDE_INDICES is set to YES then doxygen will not
# include the index chapters (such as File Index, Compound Index, etc.)
# in the output.
LATEX_HIDE_INDICES = NO
# If LATEX_SOURCE_CODE is set to YES then doxygen will include
# source code with syntax highlighting in the LaTeX output.
# Note that which sources are shown also depends on other settings
# such as SOURCE_BROWSER.
LATEX_SOURCE_CODE = NO
#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------
# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
# The RTF output is optimized for Word 97 and may not look very pretty with
# other RTF readers or editors.
GENERATE_RTF = NO
# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `rtf' will be used as the default path.
RTF_OUTPUT = rtf
# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
# RTF documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_RTF = NO
# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
# will contain hyperlink fields. The RTF file will
# contain links (just like the HTML output) instead of page references.
# This makes the output suitable for online browsing using WORD or other
# programs which support those fields.
# Note: wordpad (write) and others do not support links.
RTF_HYPERLINKS = NO
# Load stylesheet definitions from file. Syntax is similar to doxygen's
# config file, i.e. a series of assignments. You only have to provide
# replacements, missing definitions are set to their default value.
RTF_STYLESHEET_FILE =
# Set optional variables used in the generation of an rtf document.
# Syntax is similar to doxygen's config file.
RTF_EXTENSIONS_FILE =
#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------
# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
# generate man pages
GENERATE_MAN = NO
# The MAN_OUTPUT tag is used to specify where the man pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `man' will be used as the default path.
MAN_OUTPUT = man
# The MAN_EXTENSION tag determines the extension that is added to
# the generated man pages (default is the subroutine's section .3)
MAN_EXTENSION = .3
# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.
MAN_LINKS = NO
#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------
# If the GENERATE_XML tag is set to YES Doxygen will
# generate an XML file that captures the structure of
# the code including all documentation.
GENERATE_XML = NO
# The XML_OUTPUT tag is used to specify where the XML pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `xml' will be used as the default path.
XML_OUTPUT = xml
# The XML_SCHEMA tag can be used to specify an XML schema,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_SCHEMA =
# The XML_DTD tag can be used to specify an XML DTD,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_DTD =
# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
# dump the program listings (including syntax highlighting
# and cross-referencing information) to the XML output. Note that
# enabling this will significantly increase the size of the XML output.
XML_PROGRAMLISTING = YES
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
# generate an AutoGen Definitions (see autogen.sf.net) file
# that captures the structure of the code including all
# documentation. Note that this feature is still experimental
# and incomplete at the moment.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# configuration options related to the Perl module output
#---------------------------------------------------------------------------
# If the GENERATE_PERLMOD tag is set to YES Doxygen will
# generate a Perl module file that captures the structure of
# the code including all documentation. Note that this
# feature is still experimental and incomplete at the
# moment.
GENERATE_PERLMOD = NO
# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
# the necessary Makefile rules, Perl scripts and LaTeX code to be able
# to generate PDF and DVI output from the Perl module output.
PERLMOD_LATEX = NO
# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
# nicely formatted so it can be parsed by a human reader. This is useful
# if you want to understand what is going on. On the other hand, if this
# tag is set to NO the size of the Perl module output will be much smaller
# and Perl will parse it just the same.
PERLMOD_PRETTY = YES
# The names of the make variables in the generated doxyrules.make file
# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
# This is useful so different doxyrules.make files included by the same
# Makefile don't overwrite each other's variables.
PERLMOD_MAKEVAR_PREFIX =
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
# evaluate all C-preprocessor directives found in the sources and include
# files.
ENABLE_PREPROCESSING = YES
# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
# names in the source code. If set to NO (the default) only conditional
# compilation will be performed. Macro expansion can be done in a controlled
# way by setting EXPAND_ONLY_PREDEF to YES.
MACRO_EXPANSION = NO
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
# then the macro expansion is limited to the macros specified with the
# PREDEFINED and EXPAND_AS_DEFINED tags.
EXPAND_ONLY_PREDEF = NO
# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
# in the INCLUDE_PATH (see below) will be search if a #include is found.
SEARCH_INCLUDES = YES
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by
# the preprocessor.
INCLUDE_PATH =
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
# patterns (like *.h and *.hpp) to filter out the header-files in the
# directories. If left blank, the patterns specified with FILE_PATTERNS will
# be used.
INCLUDE_FILE_PATTERNS =
# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.
PREDEFINED =
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
# this tag can be used to specify a list of macro names that should be expanded.
# The macro definition that is found in the sources will be used.
# Use the PREDEFINED tag if you want to use a different macro definition.
EXPAND_AS_DEFINED =
# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
# doxygen's preprocessor will remove all function-like macros that are alone
# on a line, have an all uppercase name, and do not end with a semicolon. Such
# function macros are typically used for boiler-plate code, and will confuse
# the parser if not removed.
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration::additions related to external references
#---------------------------------------------------------------------------
# The TAGFILES option can be used to specify one or more tagfiles.
# Optionally an initial location of the external documentation
# can be added for each tagfile. The format of a tag file without
# this location is as follows:
# TAGFILES = file1 file2 ...
# Adding location for the tag files is done as follows:
# TAGFILES = file1=loc1 "file2 = loc2" ...
# where "loc1" and "loc2" can be relative or absolute paths or
# URLs. If a location is present for each tag, the installdox tool
# does not have to be run to correct the links.
# Note that each tag file must have a unique name
# (where the name does NOT include the path)
# If a tag file is not located in the directory in which doxygen
# is run, you must also specify the path to the tagfile here.
TAGFILES =
# When a file name is specified after GENERATE_TAGFILE, doxygen will create
# a tag file that is based on the input files it reads.
GENERATE_TAGFILE =
# If the ALLEXTERNALS tag is set to YES all external classes will be listed
# in the class index. If set to NO only the inherited external classes
# will be listed.
ALLEXTERNALS = NO
# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will
# be listed.
EXTERNAL_GROUPS = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of `which perl').
PERL_PATH = /usr/bin/perl
#---------------------------------------------------------------------------
# Configuration options related to the dot tool
#---------------------------------------------------------------------------
# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
# or super classes. Setting the tag to NO turns the diagrams off. Note that
# this option is superseded by the HAVE_DOT option below. This is only a
# fallback. It is recommended to install and use dot, since it yields more
# powerful graphs.
CLASS_DIAGRAMS = YES
# You can define message sequence charts within doxygen comments using the \msc
# command. Doxygen will then run the mscgen tool (see
# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
# documentation. The MSCGEN_PATH tag allows you to specify the directory where
# the mscgen tool resides. If left empty the tool is assumed to be found in the
# default search path.
MSCGEN_PATH =
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz, a graph visualization
# toolkit from AT&T and Lucent Bell Labs. The other options in this section
# have no effect if this option is set to NO (the default)
HAVE_DOT = YES
# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
# allowed to run in parallel. When set to 0 (the default) doxygen will
# base this on the number of processors available in the system. You can set it
# explicitly to a value larger than 0 to get control over the balance
# between CPU load and processing speed.
DOT_NUM_THREADS = 0
# By default doxygen will write a font called FreeSans.ttf to the output
# directory and reference it in all dot files that doxygen generates. This
# font does not include all possible unicode characters however, so when you need
# these (or just want a differently looking font) you can specify the font name
# using DOT_FONTNAME. You need need to make sure dot is able to find the font,
# which can be done by putting it in a standard location or by setting the
# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
# containing the font.
DOT_FONTNAME = FreeSans.ttf
# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
# The default size is 10pt.
DOT_FONTSIZE = 10
# By default doxygen will tell dot to use the output directory to look for the
# FreeSans.ttf font (which doxygen will put there itself). If you specify a
# different font using DOT_FONTNAME you can set the path where dot
# can find it using this tag.
DOT_FONTPATH =
# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect inheritance relations. Setting this tag to YES will force the
# the CLASS_DIAGRAMS tag to NO.
CLASS_GRAPH = YES
# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect implementation dependencies (inheritance, containment, and
# class references variables) of the class with other documented classes.
COLLABORATION_GRAPH = YES
# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for groups, showing the direct groups dependencies
GROUP_GRAPHS = YES
# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
# collaboration diagrams in a style similar to the OMG's Unified Modeling
# Language.
UML_LOOK = YES
# If set to YES, the inheritance and collaboration graphs will show the
# relations between templates and their instances.
TEMPLATE_RELATIONS = NO
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
# tags are set to YES then doxygen will generate a graph for each documented
# file showing the direct and indirect include dependencies of the file with
# other documented files.
INCLUDE_GRAPH = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
# documented header file showing the documented files that directly or
# indirectly include this file.
INCLUDED_BY_GRAPH = YES
# If the CALL_GRAPH and HAVE_DOT options are set to YES then
# doxygen will generate a call dependency graph for every global function
# or class method. Note that enabling this option will significantly increase
# the time of a run. So in most cases it will be better to enable call graphs
# for selected functions only using the \callgraph command.
CALL_GRAPH = YES
# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
# doxygen will generate a caller dependency graph for every global function
# or class method. Note that enabling this option will significantly increase
# the time of a run. So in most cases it will be better to enable caller
# graphs for selected functions only using the \callergraph command.
CALLER_GRAPH = YES
# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
# will graphical hierarchy of all classes instead of a textual one.
GRAPHICAL_HIERARCHY = YES
# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
# then doxygen will show the dependencies a directory has on other directories
# in a graphical way. The dependency relations are determined by the #include
# relations between the files in the directories.
DIRECTORY_GRAPH = YES
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. Possible values are png, jpg, or gif
# If left blank png will be used.
DOT_IMAGE_FORMAT = png
# The tag DOT_PATH can be used to specify the path where the dot tool can be
# found. If left blank, it is assumed the dot tool can be found in the path.
DOT_PATH =
# The DOTFILE_DIRS tag can be used to specify one or more directories that
# contain dot files that are included in the documentation (see the
# \dotfile command).
DOTFILE_DIRS =
# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
# nodes that will be shown in the graph. If the number of nodes in a graph
# becomes larger than this value, doxygen will truncate the graph, which is
# visualized by representing a node as a red box. Note that doxygen if the
# number of direct children of the root node in a graph is already larger than
# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
DOT_GRAPH_MAX_NODES = 50
# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
# graphs generated by dot. A depth value of 3 means that only nodes reachable
# from the root by following a path via at most 3 edges will be shown. Nodes
# that lay further from the root node will be omitted. Note that setting this
# option to 1 or 2 may greatly reduce the computation time needed for large
# code bases. Also note that the size of a graph can be further restricted by
# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
MAX_DOT_GRAPH_DEPTH = 0
# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, because dot on Windows does not
# seem to support this out of the box. Warning: Depending on the platform used,
# enabling this option may lead to badly anti-aliased labels on the edges of
# a graph (i.e. they become hard to read).
DOT_TRANSPARENT = YES
# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10)
# support this, this feature is disabled by default.
DOT_MULTI_TARGETS = NO
# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
# generate a legend page explaining the meaning of the various boxes and
# arrows in the dot generated graphs.
GENERATE_LEGEND = YES
# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
# remove the intermediate dot files that are used to generate
# the various graphs.
DOT_CLEANUP = YES
esajpip-0.1~bzr33/doc/client_manager.fig 0000644 0001750 0001750 00000012405 12335423210 020142 0 ustar mathieu mathieu #FIG 3.2 Produced by xfig version 3.2.5b
Portrait
Center
Metric
A4
100.00
Single
-2
1200 2
0 32 #ffffff
6 2340 2610 4770 3960
6 2925 3060 4140 3555
4 1 0 0 0 16 10 0.0000 6 120 735 3533 3197 Is there an\001
4 1 0 0 0 16 10 0.0000 6 150 1155 3533 3364 associate backup\001
4 1 0 0 0 16 10 0.0000 6 120 285 3533 3531 file?\001
-6
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
3555 2610 4770 3285 3555 3960 2340 3285 3555 2610
-6
6 -1125 2790 1350 3780
6 -900 3105 1125 3465
4 1 0 0 0 16 10 0.0000 6 150 1875 114 3240 Load the content, removes\001
4 1 0 0 0 16 10 0.0000 6 150 1995 114 3407 the file and open the channel\001
-6
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
-1125 2790 1350 2790 1350 3780 -1125 3780 -1125 2790
-6
6 3150 7560 3960 7920
4 1 0 0 0 16 10 0.0000 6 120 795 3553 7715 Contains a \001
4 1 0 0 0 16 10 0.0000 6 120 630 3553 7881 ''cclose''?\001
-6
6 3105 9495 3960 9810
4 1 0 0 0 16 10 0.0000 6 120 570 3539 9783 ''cnew''?\001
4 1 0 0 0 16 10 0.0000 6 120 795 3539 9616 Contains a \001
-6
6 3150 11385 4005 11745
4 1 0 0 0 16 10 0.0000 6 120 795 3582 11542 Contains a \001
4 1 0 0 0 16 10 0.0000 6 120 405 3582 11709 ''cid''?\001
-6
6 2790 13050 4365 13365
4 1 0 0 0 16 10 0.0000 6 120 1530 3558 13178 Generate a new chunk\001
4 1 0 0 0 16 10 0.0000 6 120 1305 3558 13345 of data and send it\001
-6
6 2880 14625 4140 14985
4 1 0 0 0 16 10 0.0000 6 120 1245 3517 14747 Is the related WOI\001
4 1 0 0 0 16 10 0.0000 6 150 795 3517 14914 completed?\001
-6
6 6075 9405 7785 9945
4 1 0 0 0 16 10 0.0000 6 120 1380 6940 9568 Creates the channel\001
4 1 0 0 0 16 10 0.0000 6 150 1545 6940 9734 a gets the image index\001
4 1 0 0 0 16 10 0.0000 6 150 1665 6940 9901 from the Index manager\001
-6
6 6030 7515 8055 7875
4 1 0 0 0 16 10 0.0000 6 150 1995 7034 7676 Closes the specified channel,\001
4 1 0 0 0 16 10 0.0000 6 150 1965 7034 7843 and removes the backup file \001
-6
6 2634 16233 4389 16550
4 1 0 0 0 16 10 0.0000 6 120 1500 3511 16353 Store the client cache\001
4 1 0 0 0 16 10 0.0000 6 150 1755 3511 16520 model within a backup file\001
-6
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
2745 4534 4334 4534 4334 5220 2745 5220 2745 4534
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 3960 3555 4545
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 5220 3555 5805
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
2731 5794 4320 5794 4320 6480 2731 6480 2731 5794
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 6480 3555 7065
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
3554 7081 4769 7756 3554 8431 2339 7756 3554 7081
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 8415 3555 9000
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
3541 8993 4756 9668 3541 10343 2326 9668 3541 8993
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 10350 3555 10935
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
3556 10919 4771 11594 3556 12269 2341 11594 3556 10919
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 2025 3555 2610
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
2731 1339 4320 1339 4320 2025 2731 2025 2731 1339
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
2340 3285 1350 3285
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
2 1 3.00 120.00 120.00
90 3780 90 4905 2790 4905
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3555 12285 3555 12870
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
2610 12870 4545 12870 4545 13545 2610 13545 2610 12870
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3510 13545 3510 14130
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
3510 14130 4725 14805 3510 15480 2295 14805 3510 14130
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3510 15480 3510 16065
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
2430 16065 4590 16065 4590 16740 2430 16740 2430 16065
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
2 1 3.00 120.00 120.00
5760 9675 4770 9675
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
5760 7245 8235 7245 8235 8235 5760 8235 5760 7245
2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
5760 9180 8235 9180 8235 10170 5760 10170 5760 9180
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
2 1 3.00 120.00 120.00
5760 7740 4770 7740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
2 1 3.00 120.00 120.00
8280 7740 9180 7740 9180 4815 4365 4815
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
8235 9675 9180 9675 9180 7740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
4725 14805 9180 14805 9180 9675
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
3510 16740 3510 17370 9180 17370 9180 14805
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 1 3.00 120.00 120.00
3510 16785 3510 17370
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
4725 11610 9180 11610 9180 6480
4 1 0 0 0 16 10 0.0000 6 150 1110 3510 4950 Wait for request\001
4 1 0 0 0 16 10 0.0000 6 150 1215 3555 6210 Parse the request\001
4 1 0 0 0 16 10 0.0000 6 150 390 3555 1710 Begin\001
4 1 0 0 0 16 10 0.0000 6 120 225 2025 3150 yes\001
4 1 0 0 0 16 10 0.0000 6 90 180 3735 4185 no\001
4 1 0 0 0 16 10 0.0000 6 120 225 5175 7605 yes\001
4 1 0 0 0 16 10 0.0000 6 90 180 3780 8640 no\001
4 1 0 0 0 16 10 0.0000 6 120 225 5175 9540 yes\001
4 1 0 0 0 16 10 0.0000 6 90 180 3735 10575 no\001
4 1 0 0 0 16 10 0.0000 6 120 225 3780 12465 yes\001
4 1 0 0 0 16 10 0.0000 6 120 225 3735 15705 yes\001
4 1 0 0 0 16 10 0.0000 6 90 180 5130 14715 no\001
4 1 0 0 0 16 10 0.0000 6 90 180 5130 11520 no\001
esajpip-0.1~bzr33/doc/Makefile 0000644 0001750 0001750 00000001223 12335423210 016137 0 ustar mathieu mathieu SHELL=/bin/bash
FIGS = jpip_fig \
partition \
codestream \
architecture \
client_manager
%.eps %.tex: %.fig
fig2dev -L pstex $*.fig > $*.eps
(fig2dev -L pstex_t -p $* $< | sed 's/includegraphics{/includegraphics{..\//g') > $*.tex
%.pdf: %.eps
epstopdf $*.eps
doc: $(FIGS:%=%.pdf) documentation
clean:
rm -rf *.pdf latex html doxyfile.ok
rm -rf $(FIGS:%=%.pdf) $(FIGS:%=%.tex) $(FIGS:%=%.eps)
documentation:
n=$$(cd ..; pwd) && \
cat doxyfile | \
sed -e "s:__SRC_DIR__:$$n/src/:g" | \
sed -e "s:__DOC_DIR__:$$n/doc/:g" \
> doxyfile.ok && \
doxygen doxyfile.ok && \
make -C latex && \
mv latex/refman.pdf .
esajpip-0.1~bzr33/doc/partition.fig 0000644 0001750 0001750 00000013060 12335423210 017201 0 ustar mathieu mathieu #FIG 3.2 Produced by xfig version 3.2.5
Landscape
Center
Metric
A4
100.00
Single
-2
1200 2
0 32 #ff746e
0 33 #000000
0 34 #cf0000
0 35 #009b00
0 36 #0000cf
0 37 #b0b0b0
6 5670 6660 6840 7830
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
5985 6975 6255 6975
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
5985 6930 5985 7245
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
6255 7245 6795 7245
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
6255 7245 6255 7785
2 2 0 2 35 7 45 -1 -1 4.500 0 0 -1 0 0 5
5715 6705 5985 6705 5985 6975 5715 6975 5715 6705
2 2 0 2 35 7 45 -1 -1 4.500 0 0 -1 0 0 5
5715 6705 6255 6705 6255 7245 5715 7245 5715 6705
2 2 0 2 35 7 45 -1 -1 4.500 0 0 -1 0 0 5
5715 6705 6795 6705 6795 7785 5715 7785 5715 6705
2 2 2 0 0 37 52 -1 20 3.000 0 0 -1 0 0 5
5895 7425 6165 7425 6165 7695 5895 7695 5895 7425
2 2 1 0 0 37 52 -1 20 2.000 0 0 -1 0 0 5
6435 7425 6705 7425 6705 7695 6435 7695 6435 7425
2 2 1 0 0 37 52 -1 20 2.000 0 0 -1 0 0 5
6435 6885 6705 6885 6705 7155 6435 7155 6435 6885
-6
6 3780 5580 4680 6840
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4410 6570 4410 6120
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4230 6705 4230 6120
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4050 6840 4050 6120
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4050 6120 4590 6120
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4590 6435 4590 6120
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
4320 6120 4320 5760
4 0 0 52 -1 0 12 0.0000 6 150 900 3780 5715 components\001
-6
2 1 1 1 0 15 52 -1 20 4.000 0 0 -1 0 0 2
720 7110 3015 7110
2 1 1 1 0 15 52 -1 -1 4.000 0 0 -1 0 0 2
2340 6030 2340 8190
2 1 1 1 0 15 52 -1 -1 4.000 0 0 -1 0 0 2
2745 6030 2745 8190
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
1935 6030 1935 8190
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
1530 6030 1530 8190
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
1125 6030 1125 8190
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
720 6390 3015 6390
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
720 6750 3015 6750
2 1 1 1 0 15 52 -1 -1 4.000 0 0 -1 0 0 2
720 7470 3015 7470
2 1 1 1 0 7 52 -1 -1 4.000 0 0 -1 0 0 2
720 7830 3015 7830
2 2 0 2 0 11 56 -1 20 0.000 0 0 -1 0 0 5
900 6255 2880 6255 2880 8010 900 8010 900 6255
2 4 0 1 0 7 52 -1 -1 0.000 0 0 2 0 0 5
3015 8190 720 8190 720 6030 3015 6030 3015 8190
2 2 0 0 0 37 54 -1 20 0.000 0 0 -1 0 0 5
2340 7110 2745 7110 2745 7470 2340 7470 2340 7110
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
2745 7110 3510 6840
2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
2745 7470 3510 7920
2 2 0 2 34 7 51 -1 20 0.000 0 0 -1 0 0 5
3546 6831 4635 6831 4635 7920 3546 7920 3546 6831
2 2 0 2 1 7 53 -1 20 0.000 0 0 -1 0 0 5
3804 6570 4905 6570 4905 7659 3804 7659 3804 6570
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4770 7785 5715 7785
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
4770 6705 5715 6705
2 2 1 1 0 7 54 -1 20 4.000 0 0 -1 0 0 5
3951 6435 5040 6435 5040 7524 3951 7524 3951 6435
2 2 0 2 35 7 52 -1 20 0.000 0 0 -1 0 0 5
3657 6705 4770 6705 4770 7794 3657 7794 3657 6705
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
6705 6885 7650 6705
2 1 2 1 0 7 50 -1 20 3.000 0 0 -1 0 0 2
6705 7155 7605 7605
2 1 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 2
5805 6435 6570 6435
2 1 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 2
6120 6705 6120 6435
2 1 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 2
5805 6705 5805 6435
2 1 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 2
6570 6705 6570 6435
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
8100 6930 8325 6930 8325 7155 8100 7155 8100 6930
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
8325 6705 8550 6705 8550 6930 8325 6930 8325 6705
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
7650 7155 7875 7155 7875 7380 7650 7380 7650 7155
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
7650 6930 7875 6930 7875 7155 7650 7155 7650 6930
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
8325 7155 8550 7155 8550 7380 8325 7380 8325 7155
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
7875 7155 8100 7155 8100 7380 7875 7380 7875 7155
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
8100 7155 8325 7155 8325 7380 8100 7380 8100 7155
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
8100 6705 8325 6705 8325 6930 8100 6930 8100 6705
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
7650 6705 7875 6705 7875 6930 7650 6930 7650 6705
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
7650 7380 7875 7380 7875 7605 7650 7605 7650 7380
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
7875 7380 8100 7380 8100 7605 7875 7605 7875 7380
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
8100 7380 8325 7380 8325 7605 8100 7605 8100 7380
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
8325 7380 8550 7380 8550 7605 8325 7605 8325 7380
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
7875 6930 8100 6930 8100 7155 7875 7155 7875 6930
2 2 2 1 0 0 52 -1 -1 3.000 0 0 -1 0 0 5
7875 6705 8100 6705 8100 6930 7875 6930 7875 6705
2 2 2 0 0 37 54 -1 20 3.000 0 0 -1 0 0 5
7875 6705 8100 6705 8100 6930 7875 6930 7875 6705
2 1 2 1 0 0 52 -1 -1 3.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
6210 6435 6210 6030
2 1 2 1 0 0 45 -1 -1 3.000 0 0 -1 1 0 2
1 1 1.00 60.00 120.00
8010 6795 8010 6165
2 1 2 1 0 7 52 -1 20 3.000 0 0 -1 0 1 2
1 1 1.00 60.00 120.00
2115 5625 2115 6255
2 2 2 1 0 0 53 -1 -1 3.000 0 0 -1 0 0 5
8325 6930 8550 6930 8550 7155 8325 7155 8325 6930
2 2 0 1 35 0 45 -1 -1 4.500 0 0 -1 0 0 5
7650 6705 8550 6705 8550 7605 7650 7605 7650 6705
4 0 0 52 -1 0 12 0.0000 6 90 540 720 8370 canvas\001
4 0 0 52 -1 0 12 0.0000 6 150 450 1845 5580 image\001
4 0 0 52 -1 0 12 0.0000 6 135 360 3960 8145 tile\001
4 0 0 52 -1 0 12 0.0000 6 150 720 7785 7830 precinct\001
4 0 0 52 -1 0 12 0.0000 6 165 1260 5625 8010 tile-component\001
4 0 0 52 -1 0 12 0.0000 6 135 990 5715 5985 resolutions\001
4 0 0 52 -1 0 12 0.0000 6 135 900 7605 6120 code-block\001
esajpip-0.1~bzr33/doc/jpeg2000.tex 0000644 0001750 0001750 00000035275 12335423210 016466 0 ustar mathieu mathieu Part 1 of the \href{http://www.jpeg.org/jpeg2000/}{JPEG2000} standard describes
a core compression system that is based on the dyadic
\href{http://en.wikipedia.org/wiki/Discrete_wavelet_transform}
{DWT (Discrete Wavelet Transform)}
and the
EBCOT (Embedded Block Coding with Optimal Truncation). Some features of this
compression system are high compression ratios, error-resilience, lossless
and lossy compression, random access to the compressed stream, resolution and
quality scalability, and support for multiple components.
These characteristics make it ideal for the coding and retrieving of
large remote images.
\subsection{Data partitions}
The JPEG2000 standard defines a wide variety of partitions
for the image data, with the aim of exploiting at the maximum the
offered scalability. All of these partitions
allow an efficient manipulation of the image, or a part of it. Fig.
\ref{fig:partitions} shows a graphical example of the main partitions.
\begin{figure}[!b]
\begin{center}
\resizebox{0.95\textwidth}{!}{\input{../partition}}
\end{center}
\caption{Data partition defined by the JPEG2000 standard.}
\label{fig:partitions}
\end{figure}
In order to understand the concept of each partition defined
in the JPEG2000 standard, it is necessary to clarify the concept
of canvas. The canvas is a bidimensional drawing zone where
all the partitions are mapped to form the related image.
Hereinafter, all the used coordinates are in relation to
a canvas, which size, width ($I_{2}$) and height ($I_{1}$), corresponds to
the total size of the associated image. Each partition is
located and mapped over the canvas in a specific way.
An image is composed by one or more components. In the most
of the cases the images have only three components: red, green
and blue (RGB), with a size equals to the canvas.
The JPEG2000 standard allows to divide an image into smaller
rectangular regions called tiles. Each tile is compressed
independently in relation to the rest, hence the compression
parameters can be different among them. By default there is
always one tile as minimum, which equals to the whole image.
One of the possible applications of the tile partitioning is its use
with images that contain different elements and visually separated,
like text, graphics or photographic materials. When this does not
occur, and the images are continuous and homogeneous, the tiling
is not recommended because it produces artifacts in the borders of
the tiles, causing a mosaic effect. Moreover, the size of a
compressed image is larger when the tiles are used.
The DWT transform and all the quantification/coding stages
are applied independently to each tile-component. A tile-component,
of a tile $t$ and a component $c$, is defined by a bidimensional
zone limited by $t$ taking into account the zone occupied by
$c$. This means that, if an
image has only one tile, with three color components, there are
three tile-components, which are compressed independently.
For each tile-component, identified by the tile $t$ and the component
$c$, there are a total of $D_{t,c} + 1$
resolutions, where $D_{t,c}$ is the number
of DWT stages applied. The $r$-nth resolution level of a compressed
tile-component is obtained after applying $r$ times the inverse DWT
transform. The
$r$ value is in the range of $0 \leq r \leq D_{t,c}$.
Each tile-component, after being applied the DWT, is
divided into code-blocks, that are coded independently.
In each resolution $r$ of each tile-component $(t,c)$, the
code-blocks are grouped in precincts. This partition is
defined by the height, $P_{1}^{t,c,r}$,
and the width, $P_{2}^{t,c,r}$,
of each precinct. The number of precincts in vertical,
$N_{1}^{P,t,c,r}$,
as well as in horizontal, $N_{2}^{P,t,c,r}$ are given by
the following expression:
\begin{equation*}
N_{i}^{P,t,c,r} = \left\lceil \frac{I_{i}}{2^{D_{t,c}-r}P_{i}^{t,c,r}} \right\rceil
\end{equation*}
Code-blocks refer to the wavelet coefficients generated by the DWT
transform, thus rectangular regions within the wavelet
domain. However, precincts refer to rectangular regions within the
image domain. The spatial scalability offered by the standard is
carried out with the precincts.
The packet is the fundamental unit for the organization
of the compressed bit-stream of an image. Each precinct contributes
to the bit-stream as many packets as quality layers there are. The
compressed data of each code-block is divided in different segments
called quality layers. All the code-blocks of all the precincts
of the same tile are divided into the same number of quality layers,
although the length of the quality layers between code-blocks can be
different (the length can be even zero). For a certain layer $l$,
the set of all the layer $l$ of all the code-blocks related to a
precinct form a packet.
In order to decode a certain region of an image it is necessary
decode all the packets related to that region. In the server code,
the class \hyperlink{classjpip_1_1WOIComposer}{jpip::WOIComposer} allows to know,
for a given region of interest, hereinafter called WOI (Window
Of Interest), all the required packets to decode it.
A packet $\zeta_{t,c,r,p,l}$
is identified by the tile $t$, the
component $c$, the resolution $r$, the precinct $p$ (in precinct
coordinates)
and the quality layer $l$. In the server code, the class
\hyperlink{classjpeg2000_1_1Packet}{jpeg2000::Packet} is used to
identify a packet.
\subsection{Code-stream organization}
Part 1 of the JPEG2000 standard defines a basic structure for
organizing the image compressed data into code-streams. A code-stream
includes all the packets generated by a compression process of an image
plus a set of markers, that are used for signaling certain parts, as
well as for including information necessary for the decompression.
The code-stream is itself a simple file format for JPEG2000 image.
Any standard decompressor must be able to understand a code-stream
stored within a file. This basic format is also called raw, and
its most used extension is ``.J2C''.
The markers have an unique identifier, that consists of an unsigned
integer of $16$ bits. These markers can be found alone, that is,
only the identifier, or accompanied by additional information,
receiving in this case the name of marker segment.
The marker segment has, after the identifier, another unsigned
integer of $16$ bits with the length of the included data, including
as well the two bytes of this integer, but without counting the
two bytes of the identifier.
The code-stream always begins with the SOC (Start Of Code-stream)
marker, which does not include any additional information.
After this marker a set of markers called ``main header'' begins.
After the SOC marker there is always a SIZ marker, with global
information necessary for decompressing the data, e.g. the image
size, the tile size, the anchor point of the tiles, the number
of components, the sub-sampling factors, etc.
There are another two markers that are mandatory in the main header:
COD, with information related to the coding of the image, like the
number of layers, number of DWT stages, the size of the code-blocks,
the progression, etc.; and QCD, which contains the quantization
parameters. These two markers can be stored in any position within the
main header.
The rest of the code-stream, until the EOC (End Of Code-stream),
located just at the end of it, is organized as it is shown
in Fig. \ref{fig:code-stream}. For each image tile, there is
a set of data. This data is divided into one or more tile-parts.
Each tile-part is composed by a header and a set of packets.
The header of the first tile-part is the main header of the tile.
The header of each tile-part begins with the SOT (Start Of Tile)
marker and ends with the SOD (Start Of Data) marker, starting then
the related sequence of packets, according to the last COD or POC
marker. The main header ends when the first SOT is found.
\begin{figure}[!t]
\begin{center}
\resizebox{0.65\textwidth}{!}{\input{../codestream}}
\end{center}
\caption{Code-stream organization.}
\label{fig:code-stream}
\end{figure}
In order to permit a random access to the data of a code-stream,
that by default is not feasible, JPEG2000 offers the possibility
of including the TLM, PLM and/or PLT markers. The TLM and PLM markers
are included within the main header, whilst the PLT marker goes
in the header of a tile or tile-part. The goal of the TLM marker
is to store the length of each tile-part that appear within the
code-stream. This length includes the header as well
as the set of packets, so for knowing where is the beginning of the
data it is necessary to analyze firstly the header. The PLM marker
stores the length of each packet of each tile-part of the code-stream.
Each packet of the code-stream has a certain length, that can
not be known a priori. Therefore including this marker facilitates
a random access of the packets. The PLT marker has the same function
as the PLM marker, but at the level of tile-part, thus it stores
the length of all the packets of the belonging tile-part. This
marker is commonly most used than PLM.
The PLM and PLT markers produces an increase of the code-stream
length, although the way of coding the packet lengths helps to
avoid an excessive overhead: a length $L$ of a certain packet,
that can be represented with $B_{L}$ bits, is stored coded
with $\left \lceil \frac{B_{L}}{7} \right \rceil$ bytes. For a
length $L$ is generated a sequence of bytes where only the
less significant $7$ bits are used. The most significant
bit of each byte indicates if the belonging byte is ($1$) or
not ($0$) the last one of the sequence. This way of numeric
encoding is widely used in Part 9 of the standard, specially with
the JPIP protocol. With this protocol, to each variable sequence
of bytes that represents a number encoded in this way is called
VBAS (Variable Byte-Aligned Segment). The class
\hyperlink{classjpip_1_1DataBinWriter}{jpip::DataBinWriter}, within the server code,
contains methods to generate VBAS coded values.
\subsection{Progressions}
\label{sec:progresiones}
The packets generated by the JPEG2000 compression process
are neither independent nor self-contained. Having a certain packet,
it is not possible to figure out to which part of the related image
it belongs without additional information. The length of the packet
can not be determined before being decoded, and many packets can not
be decoded without decoding other packets before. This is why it is
necessary to include markers like TLM, PLT or PLM, previously
commented, in order to allow a random access without decoding.
The packets of each tile-part appear according the progression
specified by the last COD or POC marker read, before the
SOD marker. Part 1 of the JPEG2000 standard defines 5 possible kinds of
progressions for ordering the packets within a tile or tile-part.
Each progression is identified by means of a combination
of four letters: ``L'' for quality layer, ``R'' for resolution
level, ``C'' for component and ``P'' for precinct. Each letter identifies
the partition of the progression. Hence for the LRCP progression,
for example, the packets would be included as follows:\\
\\for each layer $l$\\
\hspace*{1cm} for each resolution $r$\\
\hspace*{2cm} for each component $c$\\
\hspace*{3cm} for each precinct $p$\\
\hspace*{4cm} include the packet $\zeta_{t,c,r,p,l}$\\
The different progressions allowed by the standard are: LRCP, RLCP,
RPCL, PCRL and CPRL. To choose a progression or another depends on
the application to
develop, and how the packet must to be decoded. For example,
if the packets are going to be accessed randomly, but
as minimum disk accesses as possible are required, RPCL would
be the ideal progression in this case.
In the case of image transmission, the packets must also follow a
specific order or progression when they are transmitted.
When an image is transmitted from a server to a client, the most
desired goal is to allow the client to be able to show reconstructions
of the image with a quality that is increased as the data is received.
The quality of the reconstruction must be always the maximum possible
according to the received data. Under this criteria, the LRCP progression
can be confirmed as the best one, and it is the progression used by
the class \hyperlink{classjpip_1_1WOIComposer}{jpip::WOIComposer}.
\subsection{File formats}
Although the code-stream is completely functional as a basic
file format, it does not allow to include additional information
that could be necessary in certain applications, e.g. meta-data,
copyright information, or color palettes. By means of the COM
marker auxiliary information can be included within a
code-stream, but it is not classified nor organized in
a standard way.
Part 1 of the standard also defines a file format based on ``boxes'' that
allows to include, for example, in the same file, several code-streams
and diverse information correctly identified. These files usually have
the extension ``.JP2'', extension also used for calling this kind
of files.
The JP2 files are easily extensible. A basic structure of box is defined,
which can contains any kind of information. Each box is unequivocally
classified by means of a $4$-bytes identifier. A file can contain
several boxes with the same identifier. The standard proposes an
initial set of boxes, that may be extended according to specific
requirements. In fact, the JP2 format is the base of the rest of
formats and extensions defined in the rest of parts of the standard.
Each box has a header of $8$ bytes. The first $4$ bytes, $L$, form
an unsigned integer with the length in bytes of the content of the
next $4$ bytes, $T$, contain the identifier of the kind of box. This
identifier is commonly treated like a string of $4$ ASCII characters.
The value of $L$ includes the header, hence the real length of the
content of the box is $L - 8$. $L$ can have any value bigger or
equal to $8$, but also $1$ or $0$. If $L = 1$ the length of the
content of the box is coded as an unsigned integer of $8$ bytes, $X$,
located after $T$. In this case the header occupies $16$ bytes and
the length of the content is then $X - 16$. If $L = 0$ the
length of the box content is undefined, being possible only for the
last box of the image file.
Boxes can contain another boxes inside. It is possible to know
whether a box contains or not sub-boxes depending on the value of
$T$. If a box contains sub-boxes, it only can contain sub-boxes,
so it can not combine sub-boxes with other data.
Within the server code, the class \hyperlink{classjpeg2000_1_1FileManager}
{jpeg2000::FileManager} contains all the necessary code to read and parse
JPEG2000 image files, from simple raw J2C files to complex JPX ones with
hyperlinks. When this class parses an image file, extract the associated
index information and stores it in an object of the class
\hyperlink{classjpeg2000_1_1ImageInfo}{jpeg2000::ImageInfo}.
esajpip-0.1~bzr33/doc/header.tex 0000644 0001750 0001750 00000002515 12335423210 016456 0 ustar mathieu mathieu \documentclass[a4paper]{book}
\usepackage{a4wide}
\usepackage{makeidx}
\usepackage{graphicx}
\usepackage{multicol}
\usepackage{float}
\usepackage{listings}
\usepackage{color}
\usepackage{textcomp}
\usepackage{alltt}
\usepackage{times}
\usepackage{ifpdf}
\usepackage{amsmath}
\ifpdf
\usepackage[pdftex,
pagebackref=true,
colorlinks=true,
linkcolor=blue,
unicode
]{hyperref}
\else
\usepackage[ps2pdf,
pagebackref=true,
colorlinks=true,
linkcolor=blue,
unicode
]{hyperref}
\usepackage{pspicture}
\fi
\usepackage[utf8]{inputenc}
\usepackage{../doxygen}
\lstset{language=C++,inputencoding=utf8,
basicstyle=\footnotesize,breaklines=true,
breakatwhitespace=true,tabsize=8,numbers=left}
\makeindex
\setcounter{tocdepth}{3}
\renewcommand{\footrulewidth}{0.4pt}
\begin{document}
\hypersetup{pageanchor=false}
\begin{titlepage}
\vspace*{7cm}
\begin{center}
{\Huge ESA JPIP server}\\
{\large Version \input{../../VERSION}}\\
\vspace*{1cm}
{\Large Documentation}\\
\vspace*{0.5cm}
{\today}\\
\end{center}
\end{titlepage}
\clearemptydoublepage
\pagenumbering{roman}
\tableofcontents
\clearemptydoublepage
\pagenumbering{arabic}
\hypersetup{pageanchor=true}
\part{Application}
\input{../guide.tex}
\part{Source code}
\label{sourcecode}
esajpip-0.1~bzr33/.cproject 0000644 0001750 0001750 00000037366 12335423210 015565 0 ustar mathieu mathieu
esajpip-0.1~bzr33/src/ 0000755 0001750 0001750 00000000000 12335423210 014523 5 ustar mathieu mathieu esajpip-0.1~bzr33/src/packet_information.cc 0000644 0001750 0001750 00000010041 12335423210 020702 0 ustar mathieu mathieu #include "trace.h"
#include "app_config.h"
#include "jpip/woi_composer.h"
#include "jpeg2000/index_manager.h"
using namespace std;
using namespace jpip;
using namespace jpeg2000;
struct ui
{
template static void read(T& v, T mn, T mx)
{
do
{
cin >> v;
} while ((v < mn) || (v > mx));
}
};
int main(void)
{
AppConfig cfg;
if (cfg.Load("server.cfg"))
cout << endl << cfg << endl;
else
{
cerr << "The configuration file can not be read" << endl;
return -1;
}
string name_image_file;
if (!File::Exists(cfg.caching_folder().c_str()))
cerr << "The cache folder does not exist" << endl;
IndexManager im;
im.Init(cfg.images_folder(), cfg.caching_folder());
ImageIndex::Ptr it_node;
int option;
do
{
cout << endl
<< "MENU:" << endl
<< "-----" << endl
<< "1) Open image file" << endl
<< "2) Close image file" << endl
<< "3) Get WOI packets from image file" << endl
<< "4) Image file list" << endl
<< "5) Exit" << endl << endl
<< "Option: ";
ui::read(option, 1, 5);
switch (option)
{
case 1:
cout << "Name image file (type 'exit' to finish): ";
cin >> name_image_file;
while (name_image_file.compare("exit") != 0)
{
if (im.OpenImage(name_image_file, &it_node)) cout << "Image file loaded..." << endl;
else cout << "Image file not loaded..." << endl;
cout << "Name image file (type 'exit' to finish): ";
cin >> name_image_file;
}
break;
case 2:
if (im.GetSize() <= 0) cout << "Image list is empty!" << endl;
{
if (im.CloseImage(it_node)) cout << "Image file closed." << endl;
else cout << "Image file not closed!" << endl;
}
break;
case 3:
if (im.GetSize() <= 0) cout << "Image list is empty!" << endl;
{
int wx, wy, ww, wh, wr, ind_codestream;
CodingParameters cp = *it_node->GetCodingParameters();
cout << "Number codestream [0-" << (it_node->GetNumCodestreams() - 1) << "]: ";
ui::read(ind_codestream, 0, (int)it_node->GetNumCodestreams() - 1);
cout << "Resolution [0-" << cp.num_levels << "]: ";
ui::read(wr, 0, cp.num_levels);
int max_x = ceil((double)cp.size.x / (1L << (cp.num_levels - wr))) - 1;
cout << "Coord. X [0-" << max_x << "]: ";
ui::read(wx, 0, max_x);
int max_y = ceil((double)cp.size.y / (1L << (cp.num_levels - wr))) - 1;
cout << "Coord. Y [0-" << max_y << "]: ";
ui::read(wy, 0, max_y);
int max_width = ceil((double)cp.size.x / (1L << (cp.num_levels - wr))) - wx;
cout << "Width [0-" << max_width << "]: ";
ui::read(ww, 0, max_width);
int max_height = ceil((double)cp.size.y / (1L << (cp.num_levels - wr))) - wy;
cout << "Height [0-" << max_height << "]: ";
ui::read(wh, 0, max_height);
WOIComposer woi_composer;
WOI woi(Point(wx, wy), Size(wh, ww), wr);
cout << woi << endl;
woi_composer.Reset(woi, it_node->GetCodingParameters());
cout << "ID\tL\tR\tC\tPY\tPX\tOFFSET:LENGTH" << endl;
cout << string(60, '-') << endl;
it_node->ReadLock(Range(0, 0));
Packet packet;
while (woi_composer.GetNextPacket(&packet))
cout << it_node->GetCodingParameters()->GetPrecinctDataBinId(packet)
<< "\t" << packet << "\t" << it_node->GetPacket(ind_codestream, packet) << endl;
cout << string(60, '-') << endl;
it_node->ReadUnlock(Range(0, 0));
}
break;
case 4:
int i = 0;
cout << endl;
for(ImageIndex::Ptr it = im.GetBegin(); it != im.GetEnd(); ++it)
{
cout
<< "Node " << i++ << ":" << endl
<< string(60, '-') << endl
<< *it << endl
<< string(60, '-') << endl
<< endl;
}
break;
}
} while (option != 5);
return 0;
}
esajpip-0.1~bzr33/src/args_parser.h 0000644 0001750 0001750 00000001515 12335423210 017206 0 ustar mathieu mathieu #ifndef _ARGS_PARSER_H_
#define _ARGS_PARSER_H_
#include "app_info.h"
#include "app_config.h"
/**
* Class that allows to parse and handle the application
* command line parameters.
*/
class ArgsParser
{
private:
AppConfig& cfg; ///< Application configuration
AppInfo& app_info; ///< Application run-time information
public:
/**
* Initializes the object.
* @param _cfg Application configuration.
* @param _app_info Application run-time information.
*/
ArgsParser(AppConfig& _cfg, AppInfo& _app_info) : cfg(_cfg), app_info(_app_info)
{
}
/**
* Parses and handles the application command line parameters.
* @param argc Number of parameters.
* @param argv Command line parameters.
* @return true if successful.
*/
bool Parse(int argc, char **argv);
};
#endif /* _ARGS_PARSER_H_ */
esajpip-0.1~bzr33/src/base.cc 0000644 0001750 0001750 00000000022 12335423210 015736 0 ustar mathieu mathieu #include "base.h"
esajpip-0.1~bzr33/src/client_info.h 0000644 0001750 0001750 00000002503 12335423210 017165 0 ustar mathieu mathieu #ifndef _CLIENT_INFO_H_
#define _CLIENT_INFO_H_
#include
/**
* Contains information of a connected client.
*/
class ClientInfo
{
private:
int sock_; ///< Client socket
int base_id_; ///< Base identifier
time_t tm_start; ///< When the connection started
int father_sock_; ///< Father socket
long bytes_sent_; ///< Total bytes sent
public:
/**
* Initializes the object.
* @param base_id Base identifier.
* @param sock Client socket.
* @param father_sock Father socket.
*/
ClientInfo(int base_id, int sock, int father_sock)
{
sock_ = sock;
bytes_sent_ = 0;
base_id_ = base_id;
tm_start = ::time(NULL);
father_sock_ = father_sock;
}
/**
* Returns the client socket.
*/
int sock() const
{
return sock_;
}
/**
* Returns the base identifier.
*/
int base_id() const
{
return base_id_;
}
/**
* Returns the father socket.
*/
int father_sock() const
{
return father_sock_;
}
/**
* Returns the total bytes sent.
*/
long bytes_sent() const
{
return bytes_sent_;
}
/**
* Returns the time spent from the starting
* of the connection.
*/
long time() const
{
time_t now = ::time(NULL);
return (long)(tm_start - now);
}
virtual ~ClientInfo()
{
}
};
#endif /* _CLIENT_INFO_H_ */
esajpip-0.1~bzr33/src/app_info.h 0000644 0001750 0001750 00000010177 12335423210 016475 0 ustar mathieu mathieu #ifndef _APP_INFO_H_
#define _APP_INFO_H_
#include
#include
#include
#ifndef _NO_READPROC
#include
#endif
using namespace std;
/**
* Contains the run-time information of the application.
* This class can be printed.
*/
class AppInfo
{
private:
/**
* Contains the data block that is maintained in
* shared memory.
*/
struct Data
{
int father_pid; ///< PID of the father process
int child_pid; ///< PID of the child process
int num_connections; ///< Number of open connections
int child_iterations; ///< Number of iterations done by the child
/**
* Clears the values.
*/
void Reset()
{
father_pid = 0;
child_pid = 0;
num_connections = 0;
child_iterations = 0;
}
};
int shmid; ///< Identifier of the shared memory block
int lock_file; ///< Lock file
Data *data_ptr; ///< Pointer to the shared memory block
bool is_running_; ///< true if the application is running
int num_threads_; ///< Number of active threads
double child_memory_; ///< Memory used by the child process
unsigned long time_; ///< Time spent by the father
double father_memory_; ///< Memory used by the father process
double available_memory_; ///< Available memory in the system
unsigned long child_time_; ///< Time spend by the child
/**
* Returns a specific field of /proc//stat as a string.
*/
string GetProcStat_(int pid, int field) const;
/**
* Returns a specific field of /proc//stat as a defined type.
*/
template TYPE GetProcStat(int pid, int field) const
{
TYPE val;
string str = GetProcStat_(pid, field);
istringstream(str) >> val;
return val;
}
public:
/**
* Initializes the object.
*/
AppInfo()
{
shmid = -1;
lock_file = -1;
child_memory_ = 0;
father_memory_ = 0;
is_running_ = false;
available_memory_ = 0;
child_time_ = 0;
data_ptr = NULL;
num_threads_ = 0;
time_ = 0;
}
/**
* Initializes the object and the handling of the application
* run-time information.
* @return true if successful.
*/
bool Init();
/**
* Returns true if the application is running.
*/
bool is_running() const
{
return is_running_;
}
friend ostream& operator <<(ostream &out, const AppInfo &app)
{
out << "Status: " << (app.is_running() ? "running" : "stopped") << endl;
out << "Available memory: " << setiosflags(ios::fixed) << setprecision(2) << app.available_memory() << " MB" << endl;
if(app.is_running()) {
out << "Father PID: " << app->father_pid << endl;
out << "Child PID: " << app->child_pid << endl;
out << "Child threads: " << app.num_threads() << endl;
out << "Child iterations: " << app->child_iterations << endl;
out << "Num. connections: " << app->num_connections << endl;
out << "Father used memory: " << setiosflags(ios::fixed) << setprecision(2) << app.father_memory() << " MB" << endl;
out << "Child used memory: " << setiosflags(ios::fixed) << setprecision(2) << app.child_memory() << " MB" << endl;
}
return out;
}
/**
* Updates the run-time information of the application.
*/
AppInfo& Update();
/**
* Returns the available memory of the system.
*/
double available_memory() const
{
return available_memory_;
}
/**
* Returns the memory used by the father process.
*/
double father_memory() const
{
return father_memory_;
}
/**
* Returns the memory used by the child process.
*/
double child_memory() const
{
return child_memory_;
}
/**
* Returns the number of active threads.
*/
int num_threads() const
{
return num_threads_;
}
/**
* Returns the time spent by the child process.
*/
unsigned long child_time() const
{
return child_time_;
}
/**
* Returns the time spent by the father process.
*/
unsigned long time() const
{
return time_;
}
Data *operator->() const
{
assert(data_ptr);
return data_ptr;
}
~AppInfo();
};
#endif /* _APP_INFO_H_ */
esajpip-0.1~bzr33/src/jpeg2000/ 0000755 0001750 0001750 00000000000 12335423210 015752 5 ustar mathieu mathieu esajpip-0.1~bzr33/src/jpeg2000/codestream_index.h 0000644 0001750 0001750 00000004111 12335423210 021435 0 ustar mathieu mathieu #ifndef _JPEG2000_CODESTREAM_INDEX_H_
#define _JPEG2000_CODESTREAM_INDEX_H_
#include
#include "base.h"
#include "data/file_segment.h"
namespace jpeg2000
{
using namespace data;
/**
* Class used for indexing the information of a JPEG2000
* codestream. The indexed information is the segment of
* the main header, the contiguous segments of packets
* (usually the data of each tile-part) and the segments
* of the existing PLT markers. This class can be printed
* and serialized.
*
* @see data::FileSegment
*/
class CodestreamIndex
{
public:
FileSegment header; ///< Main header segment
vector packets; ///< Tile-part packets segments
vector PLT_markers; ///< PLT markers segments
/**
* Empty constructor.
*/
CodestreamIndex()
{
}
/**
* Copy constructor.
*/
CodestreamIndex(const CodestreamIndex& index)
{
*this = index;
}
/**
* Clears the information.
*/
void Clear()
{
packets.clear();
PLT_markers.clear();
}
/**
* Copy assignment.
*/
const CodestreamIndex& operator=(const CodestreamIndex& index)
{
header = index.header;
base::copy(packets, index.packets);
base::copy(PLT_markers, index.PLT_markers);
return *this;
}
template T& SerializeWith(T& stream)
{
return (stream & header & packets & PLT_markers);
}
friend ostream& operator << (ostream &out, const CodestreamIndex &index)
{
out << "Header: " << index.header << endl;
out << "Packets: ";
for(vector::const_iterator i = index.packets.begin(); i != index.packets.end(); i++)
out << *i << " ";
out << endl << "PLT-markers: ";
for(vector::const_iterator i = index.PLT_markers.begin(); i != index.PLT_markers.end(); i++)
out << *i << " ";
out << endl;
return out;
}
virtual ~CodestreamIndex()
{
}
};
}
#endif /* _JPEG2000_CODESTREAM_INDEX_H_ */
esajpip-0.1~bzr33/src/jpeg2000/index_manager.cc 0000644 0001750 0001750 00000010520 12335423210 021060 0 ustar mathieu mathieu //#define SHOW_TRACES
#include
#include "trace.h"
#include "index_manager.h"
namespace jpeg2000
{
using namespace std;
bool IndexManager::OpenImage(string& path_image_file, ImageIndex::Ptr *image_index)
{
bool res = false;
if(mutex.Wait() != WAIT_OBJECT) {
ERROR("The mutex of the index manager can not be locked for opening");
return false;
}
res = UnsafeOpenImage(path_image_file, image_index);
if(!mutex.Release()) {
ERROR("The mutex of the index manager can not be unlocked");
return false;
}
return res;
}
bool IndexManager::UnsafeOpenImage(string& path_image_file, ImageIndex::Ptr *image_index)
{
if(path_image_file[0] == '/') path_image_file=path_image_file.substr(1, path_image_file.size()-1);
path_image_file = file_manager_.root_dir() + path_image_file;
// Look for the image in the list
for (*image_index = index_list.begin(); *image_index != index_list.end(); (*image_index)++)
{
if ((*image_index)->path_name.compare(path_image_file) == 0)
{
(*image_index)->num_references++;
return true;
}
}
// Get image info
ImageInfo image_info;
if (!file_manager_.ReadImage(path_image_file, &image_info))
{
ERROR("The image file '" << path_image_file << "' can not be read");
return false;
}
// IndexNode is created
ImageIndex index_node;
if(!index_node.Init(path_image_file, image_info)) {
ERROR("The index for the image file '" << path_image_file << "' can not be created");
return false;
}
// Repeat the process with the image hyperlinks
if(image_info.paths.size() > 0) {
index_node.hyper_links.resize(image_info.paths.size());
map hyperlinks_visited;
map hyperlinks_created;
multimap::const_iterator it_find;
pair::iterator,multimap::iterator> it_find_range;
// Increase the number of references of the hyperlinks in the index list
for (list::iterator i = index_list.begin() ; i != index_list.end(); i++)
{
it_find_range=image_info.paths.equal_range(i->path_name);
for (it_find=it_find_range.first; it_find!=it_find_range.second; ++it_find)
{
i->num_references++;
hyperlinks_visited.insert(*it_find);
index_node.hyper_links[(*it_find).second]=i;
}
}
// Add the rest of hyperlinks to the index list
for (multimap::const_iterator i = image_info.paths.begin(); i != image_info.paths.end(); i++)
{
if (hyperlinks_visited.find(i->first) == hyperlinks_visited.end())
{
if (hyperlinks_created.find(i->first) == hyperlinks_created.end())
{
ImageIndex index_node_linked;
if(!index_node_linked.Init(i->first, index_node.coding_parameters, image_info, i->second)) {
ERROR("The index for the image file '" << i->first << "' can not be created");
return false;
}
index_list.push_back(index_node_linked);
hyperlinks_created.insert(*i);
}
else index_list.back().num_references++;
index_node.hyper_links[i->second]=--index_list.end();
}
}
}
// The node is added to the list
index_list.push_back(index_node);
*image_index = --index_list.end();
return true;
}
bool IndexManager::CloseImage(const ImageIndex::Ptr& image_index)
{
bool res = false;
if(mutex.Wait() != WAIT_OBJECT) {
ERROR("The mutex of the index manager can not be locked for closing");
return false;
}
res = UnsafeCloseImage(image_index);
if(!mutex.Release()) {
ERROR("The mutex of the index manager can not be unlocked");
return false;
}
return res;
}
bool IndexManager::UnsafeCloseImage(const ImageIndex::Ptr& image_index)
{
TRACE("Closing the image '" << image_index->path_name << "'");
// Decrease the number of references
image_index->num_references--;
// If the number of references is zero, then the IndexNode is removed from the list
if (image_index->num_references == 0)
{
for (vector::iterator>::iterator i = image_index->hyper_links.begin(); i != image_index->hyper_links.end(); i++)
UnsafeCloseImage(*i);
index_list.erase(image_index);
}
return true;
}
}
esajpip-0.1~bzr33/src/jpeg2000/image_info.cc 0000644 0001750 0001750 00000000031 12335423210 020350 0 ustar mathieu mathieu #include "image_info.h"
esajpip-0.1~bzr33/src/jpeg2000/codestream_index.cc 0000644 0001750 0001750 00000000037 12335423210 021576 0 ustar mathieu mathieu #include "codestream_index.h"
esajpip-0.1~bzr33/src/jpeg2000/point.h 0000644 0001750 0001750 00000011434 12335423210 017257 0 ustar mathieu mathieu #ifndef _JPEG2000_POINT_H_
#define _JPEG2000_POINT_H_
#include
namespace jpeg2000
{
using namespace std;
/**
* Represents a couple of integer values that can
* be used to identify a coordinate as well as a
* size. This class can be printed and serialized.
*/
class Point
{
public:
int x; ///< Value X
int y; ///< Value Y
/**
* Initializes the object.
*/
Point()
{
x = y = 0;
}
/**
* Initializes the object.
* @param x Value X.
* @param y Value Y.
*/
Point(int x, int y)
{
this->x = x;
this->y = y;
}
/**
* Copy constructor.
*/
Point(const Point& p)
{
*this = p;
}
/**
* Copy assignment.
*/
Point& operator=(const Point& p)
{
x = p.x;
y = p.y;
return *this;
}
/**
* Increments by one the two values.
* @return The object itself.
*/
Point& operator++()
{
x++;
y++;
return *this;
}
/**
* Decrements by one the two values.
* @return The object itself.
*/
Point& operator--()
{
x--;
y--;
return *this;
}
/**
* Increments the two values.
* @param val Value to increment.
* @return The object itself.
*/
Point& operator+=(int val)
{
x += val;
y += val;
return *this;
}
/**
* Decrements the two values.
* @param val Value to decrement.
* @return The object itself.
*/
Point& operator-=(int val)
{
x -= val;
y -= val;
return *this;
}
/**
* Multiplies the two values by one value.
* @param val Value to multiply.
* @return The object itself.
*/
Point& operator*=(int val)
{
x *= val;
y *= val;
return *this;
}
/**
* Divides the two values by one value.
* @param val Value to divide.
* @return The object itself.
*/
Point& operator/=(int val)
{
x /= val;
y /= val;
return *this;
}
/**
* Returns the sum of a point with an integer value.
* The value is added to the two values of the point.
*/
friend Point operator+(const Point& a, int value)
{
return Point(a.x + value, a.y + value);
}
/**
* Returns the subtraction of a point with an integer value.
* The value is subtracted from the two values of the point.
*/
friend Point operator-(const Point& a, int value)
{
return Point(a.x - value, a.y - value);
}
/**
* Returns the multiplication of a point with an integer value.
* The value is multiplied to the two values of the point.
*/
friend Point operator*(const Point& a, int value)
{
return Point(a.x * value, a.y * value);
}
/**
* Returns the division of a point with an integer value.
* The value is divided to the two values of the point.
*/
friend Point operator/(const Point& a, int value)
{
return Point(a.x / value, a.y / value);
}
/**
* Returns the sum of two points. The operation is
* applied each value of each point.
*/
friend Point operator+(const Point& a, const Point& b)
{
return Point(a.x + b.x, a.y + b.y);
}
/**
* Returns the subtraction of two points. The operation is
* applied each value of each point.
*/
friend Point operator-(const Point& a, const Point& b)
{
return Point(a.x - b.x, a.y - b.y);
}
/**
* Returns the multiplication of two points. The operation is
* applied each value of each point.
*/
friend Point operator*(const Point& a, const Point& b)
{
return Point(a.x * b.x, a.y * b.y);
}
/**
* Returns the division of two points. The operation is
* applied each value of each point.
*/
friend Point operator/(const Point& a, const Point& b)
{
return Point(a.x / b.x, a.y / b.y);
}
/**
* Returns true if the two points are equal.
*/
friend bool operator==(const Point& a, const Point& b)
{
return ((a.x == b.x) && (a.y == b.y));
}
/**
* Returns true if the two points are not equal.
*/
friend bool operator!=(const Point& a, const Point& b)
{
return ((a.x != b.x) || (a.y != b.y));
}
friend ostream& operator << (ostream &out, const Point &point)
{
out << "(" << point.x << ", " << point.y << ")";
return out;
}
template T& SerializeWith(T& stream)
{
return (stream & x & y);
}
virtual ~Point()
{
}
};
/**
* It is a synonymous of the class Point.
*
* @see Point
*/
typedef Point Size;
}
#endif /* _JPEG2000_POINT_H_ */
esajpip-0.1~bzr33/src/jpeg2000/image_index.cc 0000644 0001750 0001750 00000017016 12335423210 020537 0 ustar mathieu mathieu #include "trace.h"
#include "image_index.h"
namespace jpeg2000
{
bool ImageIndex::Init(const string& path_name, const ImageInfo& image_info)
{
num_references = 1;
this->path_name = path_name;
this->coding_parameters = CodingParameters::Ptr(new CodingParameters(image_info.coding_parameters));
meta_data = image_info.meta_data;
if (image_info.paths.size() == 0) {
base::copy(codestreams, image_info.codestreams);
max_resolution.resize(codestreams.size(), -1);
for (vector::const_iterator i = codestreams.begin(); i != codestreams.end(); i++)
{
last_plt.push_back(0);
last_packet.push_back(0);
last_offset_PLT.push_back(0);
last_offset_packet.push_back(0);
packet_indexes.push_back(PacketIndex());
}
}
rdwr_lock = RdWrLock::Ptr(new RdWrLock());
return rdwr_lock->Init();
}
bool ImageIndex::Init(const string& path_name, CodingParameters::Ptr coding_parameters, const ImageInfo& image_info, int index)
{
num_references = 1;
this->path_name = path_name;
this->coding_parameters = coding_parameters;
meta_data=image_info.meta_data_hyperlinks[index];
codestreams.push_back(image_info.codestreams[index]);
max_resolution.push_back(-1);
last_plt.push_back(0);
last_packet.push_back(0);
last_offset_PLT.push_back(0);
last_offset_packet.push_back(0);
packet_indexes.push_back(PacketIndex());
rdwr_lock = RdWrLock::Ptr(new RdWrLock());
return rdwr_lock->Init();
}
bool ImageIndex::BuildIndex(int ind_codestream, int r)
{
File file;
bool res = true;
if(!(res = res && rdwr_lock->Release()))
ERROR("The lock of the image '" << path_name << "' can not be released");
if(!(res = res && (rdwr_lock->WaitForWriting() == WAIT_OBJECT)))
ERROR("The lock of the image '" << path_name << "' can not be taken for writing");
// Open file for reading
if((res = res && file.OpenForReading(path_name)))
{
// Check if PacketIndex has been created
if (packet_indexes[ind_codestream].Size() == 0)
packet_indexes[ind_codestream] = PacketIndex(file.GetSize());
// Check the upper top of the index (to build)
int max_index;
if ((r < coding_parameters->num_levels) && (coding_parameters->IsResolutionProgression()))
{
// The max_index is the last packet index of the resolution r
Packet packet(0, r + 1, 0, Size(0, 0));
max_index = coding_parameters->GetProgressionIndex(packet) - 1;
}
else
{
// The max_index is the last packet of the image file
Size precinct_point = coding_parameters->GetPrecincts(coding_parameters->num_levels, coding_parameters->size) - 1;
Packet packet(coding_parameters->num_layers - 1, coding_parameters->num_levels, coding_parameters->num_components - 1, precinct_point);
max_index = coding_parameters->GetProgressionIndex(packet);
}
uint64_t length_packet = 0;
while (packet_indexes[ind_codestream].Size() <= max_index)
{
//GetPLTLength(file, ind_codestream, &length_packet);
res = res && GetPLTLength(file, ind_codestream, &length_packet);
GetOffsetPacket(file, ind_codestream, length_packet);
}
file.Close();
}
if(!(res = res && rdwr_lock->Release()))
ERROR("The lock of the image '" << path_name << "' can not be released");
if(!(res = res && (rdwr_lock->Wait() == WAIT_OBJECT)))
ERROR("The lock of the image '" << path_name << "' can not be taken for reading");
return res;
}
bool ImageIndex::GetPLTLength(const File& file, int ind_codestream, uint64_t *length_packet)
{
bool res = true;
vector& plt = codestreams[ind_codestream].PLT_markers;
// Get packet plt offset
if (last_offset_PLT[ind_codestream] == 0) res = res && file.Seek(plt[last_plt[ind_codestream]].offset, SEEK_SET);
else res = res && file.Seek(last_offset_PLT[ind_codestream], SEEK_SET);
// Get packet length
uint8_t buf_packet = 0;
uint8_t length_packet_partial;
uint8_t partial = 1;
*length_packet = 0;
while (partial)
{
res = res && file.Read(&buf_packet, 1);
partial = buf_packet & 128; // To get if the packet is final or not
length_packet_partial = buf_packet & 127; // To get the packet length
*length_packet = (*length_packet << 7) | length_packet_partial;
}
last_offset_PLT[ind_codestream] = file.GetOffset();
if (last_offset_PLT[ind_codestream] == (plt[last_plt[ind_codestream]].offset + plt[last_plt[ind_codestream]].length))
{
last_plt[ind_codestream]++;
last_offset_PLT[ind_codestream] = 0;
}
return res;
}
void ImageIndex::GetOffsetPacket(const File& file, int ind_codestream, uint64_t length_packet)
{
uint64_t offset;
vector& packets = codestreams[ind_codestream].packets;
if (last_offset_packet[ind_codestream] == 0) offset = packets[last_packet[ind_codestream]].offset;
else offset = last_offset_packet[ind_codestream];
packet_indexes[ind_codestream].Add(FileSegment(offset, length_packet));
last_offset_packet[ind_codestream] = offset + length_packet;
if (last_offset_packet[ind_codestream] == (packets[last_packet[ind_codestream]].offset + packets[last_packet[ind_codestream]].length))
{
last_packet[ind_codestream]++;
last_offset_packet[ind_codestream] = 0;
}
}
FileSegment ImageIndex::GetPacket(int num_codestream, const Packet& packet, int *offset)
{
FileSegment segment = FileSegment::Null;
if (hyper_links.size()>0)
{
if(packet.resolution > hyper_links[num_codestream]->max_resolution.back()) {
if(!hyper_links[num_codestream]->BuildIndex(0,packet.resolution))
ERROR("The packet index could not be created");
hyper_links[num_codestream]->max_resolution.back() = packet.resolution;
}
}
else
{
if(packet.resolution > max_resolution[num_codestream]) {
if(!BuildIndex(num_codestream, packet.resolution))
ERROR("The packet index could not be created");
max_resolution[num_codestream] = packet.resolution;
}
}
PacketIndex& packet_index = (hyper_links.size()>0) ? hyper_links[num_codestream]->packet_indexes[0]: packet_indexes[num_codestream];
//PacketIndex& packet_index = packet_indexes[num_codestream];
int idx = coding_parameters->GetProgressionIndex(packet);
segment = packet_index[idx];
if(offset != NULL) {
*offset = 0;
if(coding_parameters->progression == CodingParameters::RPCL_PROGRESSION) {
for(int l = packet.layer; l > 0; l--)
*offset += packet_index[--idx].length;
} else {
Packet p_aux = packet;
for(int l = 0; l < packet.layer; l++) {
p_aux.layer = l;
idx = coding_parameters->GetProgressionIndex(p_aux);
*offset += packet_index[idx].length;
}
}
}
return segment;
}
bool ImageIndex::ReadLock(const Range& range)
{
bool res = true;
if (hyper_links.size() <= 0)
res = (rdwr_lock->Wait() == WAIT_OBJECT);
else
{
for(int i = range.first; i <= range.last; i++)
res = res && hyper_links[i]->ReadLock();
}
return res;
}
bool ImageIndex::ReadUnlock(const Range& range)
{
bool res = true;
if (hyper_links.size() <= 0)
res = rdwr_lock->Release();
else {
for(int i = range.first; i <= range.last; i++)
res = res && hyper_links[i]->ReadUnlock();
}
return res;
}
}
esajpip-0.1~bzr33/src/jpeg2000/image_info.h 0000644 0001750 0001750 00000005437 12335423210 020231 0 ustar mathieu mathieu #ifndef _JPEG2000_IMAGE_INFO_H_
#define _JPEG2000_IMAGE_INFO_H_
#include