Update of /cvsroot/dirac/compress/doc/latex_spec
In directory
sc8-pr-cvs12.sourceforge.net:/tmp/cvs-serv11932
Modified Files:
arith-encoder.tex arith.tex bs-spec.tex dataenc.tex
idwt.tex
layout-fullsize.tex low-delay.tex mc.tex motion-dec.tex
parsediagrams.tex ref-default-videoparams.tex
sourcepresets.tex spec-structure.tex state-macros.tex
stream-access.tex wlt-dec.tex
Log Message:
Modified arithmetic coding sections to place the arithmetic
coding engine
in an annex. The AC system now agrees with the code, using
the LUT
update implementation.
Various compile warnings also fixed.
Index: sourcepresets.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/sourcepresets.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** sourcepresets.tex 12 Sep 2006 08:59:19 -0000 1.1
--- sourcepresets.tex 11 Apr 2007 15:28:35 -0000 1.2
***************
*** 4,8 ****
tables, as specified in Section ref.
! begin[!h]
centering
begin{|c|c|c|}
--- 4,8 ----
tables, as specified in Section ref.
! begin[!ht]
centering
begin{|c|c|c|}
***************
*** 30,34 ****
end
! begin[!h]
centering
begin{|c|c|c|}
--- 30,34 ----
end
! begin[!ht]
centering
begin{|c|c|c|}
***************
*** 46,50 ****
end
! begin[!h]
centering
begin{|c|c|c|}
--- 46,50 ----
end
! begin[!ht]
centering
begin{|c|c|c|}
***************
*** 62,66 ****
end
! begin[!h]
centering
begin{|c|c|c|}
--- 62,66 ----
end
! begin[!ht]
centering
begin{|c|c|c|}
***************
*** 85,89 ****
end
! begin[!h]
centering
begin{|c|c|l|l|l|}
--- 85,89 ----
end
! begin[!ht]
centering
begin{|c|c|l|l|l|}
***************
*** 103,107 ****
end
! begin[!h]
centering
begin{|c|l|}
--- 103,107 ----
end
! begin[!ht]
centering
begin{|c|l|}
***************
*** 121,125 ****
end
! begin[!h]
centering
begin{|c|l|}
--- 121,125 ----
end
! begin[!ht]
centering
begin{|c|l|}
***************
*** 137,141 ****
end
! begin[!h]
centering
begin{|c|l|}
--- 137,141 ----
end
! begin[!ht]
centering
begin{|c|l|}
Index: idwt.tex
============================================================
=======
RCS file: /cvsroot/dirac/compress/doc/latex_spec/idwt.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** idwt.tex 9 Jan 2007 14:21:48 -0000 1.9
--- idwt.tex 11 Apr 2007 15:28:35 -0000 1.10
***************
*** 265,269 ****
! begin[h!]
begin{|l|l|}
--- 265,269 ----
! begin[!ht]
begin{|l|l|}
***************
*** 284,288 ****
end
! begin[h!]
begin{|l|l|}
--- 284,288 ----
end
! begin[!ht]
begin{|l|l|}
***************
*** 304,308 ****
end
! begin[h!]
begin{|l|l|}
--- 304,308 ----
end
! begin[!ht]
begin{|l|l|}
***************
*** 324,328 ****
end
! begin[h!]
begin{|l|l|}
--- 324,328 ----
end
! begin[!ht]
begin{|l|l|}
***************
*** 344,348 ****
end
! begin[h!]
begin{|l|l|}
--- 344,348 ----
end
! begin[!ht]
begin{|l|l|}
***************
*** 364,368 ****
end
! begin[h!]
begin{|l|l|}
--- 364,368 ----
end
! begin[!ht]
begin{|l|l|}
***************
*** 384,388 ****
end
! begin[h!]
begin{|l|l|}
hline
--- 384,388 ----
end
! begin[!ht]
begin{|l|l|}
hline
Index: dataenc.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/dataenc.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** dataenc.tex 9 Jan 2007 14:21:48 -0000 1.9
--- dataenc.tex 11 Apr 2007 15:28:35 -0000 1.10
***************
*** 9,14 ****
This section defines how data bits are extracted from the
bitstream and how
sequences of bits are interpreted as values of various
types using fundamental
! data-reading functions, covering encodings of the first
two sorts. The extraction
! of arithmetic-encoded data is defined in Section
ref.
subsection{Bit-packing and data input}
--- 9,14 ----
This section defines how data bits are extracted from the
bitstream and how
sequences of bits are interpreted as values of various
types using fundamental
! data-reading functions. The extraction of
arithmetic-encoded data makes use of
! an arithmetic decoding engine which is specified in
Appendix ref.
subsection{Bit-packing and data input}
***************
*** 282,283 ****
--- 282,440 ----
Note that when $ABitsLeft==0$, all subsequent values read
by $read_sintb()$ will be 0.
+
+ subsection{Arithmetic decoding}
+
+ label
+
+ This section defines the operations for reading and
writing arithmetically-coded
+ data. These make use of an arithmetic decoding engine
defined in Appendix
+ ref.
+
+ Arithmetically-coded data is present in the Dirac stream
in data blocks which consist of
+ a whole number of bytes and are byte aligned. Where
arithmetic coding is used, each such
+ block is preceded by data which includes a length code
$length$, which is equal to the length in
+ bytes of the data block. The function
$initialise_arithmetic_decoding(length)$
+ (Section ref) then initialises the arithmetic
decoder. Once the arithmetic
+ decoder is initialised, boolean and integer values may be
extracted.
+
+ After all values in a particular arithmetic coded block
have been parsed, and remaining data
+ is purged by calling $flush_inputb()$ (Section
ref).
+
+ subsubsection
+
+
+ Values are extracted by using binary {em contexts}, which
are estimates of the
+ probability of the binary values extracted being 0
($false$) or 1 ($true$).
+ Contexts are determined prior to values being extracted,
based on previously
+ decoded data, and are updated by the arithmetic decoding
engine to track
+ statistics. The structure of contexts and how they are
initialised and updated
+ is specified in Section ref.
+
+ The set of contexts is $AContexts$, and an individual
context is accessed via
+ an index $AContexts[i]$.
+
+ paragraph{Context indices\}
+ label
+
+ The following context indices are used within the Dirac
decoder:
+
+ Wavelet coefficient contexts:
+
+ SignZero\
+ SignPos\
+ SignNeg\
+ ZPZNFollowOne\
+ ZPNNFollowOne\
+ ZPFollowTwo\
+ ZPFollowThree\
+ ZPFollowFour\
+ ZPFollowFive\
+ ZPFollowSixPlus\
+ NPZNFollowOne\
+ NPNNFollowOne\
+ NPFollowTwo\
+ NPFollowThree\
+ NPFollowFour\
+ NPFollowFive\
+ NPFollowSixPlus\
+ CoeffData\
+ ZeroCodeblock\
+ QOffsetFollow\
+ QOffsetData\
+ QOffsetSign\
+
+ Motion data contexts:
+
+ SBSplitFollowOne\
+ SBSplitFollowTwo\
+ SBSplitData\
+ PredModeOne\
+ PredModeTwo\
+ BlockGlobal\
+ VectorFollowOne\
+ VectorFollowTwo\
+ VectorFollowThree\
+ VectorFollowFour\
+ VectorFollowFivePlus\
+ VectorData\
+ VectorSign\
+ DCFollowOne\
+ DCFollowTwoPlus\
+ DCData\
+ DCSign\
+
+ subsubsection{Arithmetic decoding of boolean values}
+
+ Given a context index $i$, the arithmetic decoding engine
supports a function
+ $read_boola(i)$, specified in Section
ref, which returns the
+ boolean value $true$ or $false$.
+
+ subsubsection{Arithmetic decoding of integer values}
+
+ label
+
+ This section defines the operation of the
$read_sinta(context_set)$ and
+ $read_uinta(context_set)$ function
+ for extracting integer values from a block of
arithmetically coded data.
+
+ paragraph{Binarisation and contexts \}
+
+ Signed and unsigned integer values are binarised using
interleaved exp-Golomb
+ binarisation as per Section ref: the
$read_sinta()$ and $read_uinta()$
+ processes are essentially identical to the
+ $read_sint()$ and $read_uint()$ processes, except that
instances of $read_bool()$ are replaced
+ by instances of $read_boola()$ (Section
ref) using suitable contextualisation.
+
+ A choice of context depends upon whether the bit is a data
bit, follow bit,
+ or sign bit, and upon the position of the bit within the
binarisation:
+ $context_set$ consists of three parts -
+ begin
+ item an array of follow context indices,
$context_set[follow]$ (indexed from 0 to
+ $length(context_set[follow])-1$)
+ item a single data context index, $context_set[data]$
+ item a sign context index, $context_set[sign]$ (ignored
for unsigned integer decoding)
+ end
+
+ Each follow context is used for decoding the corresponding
follow bit, with the
+ last follow context being used for all subsequent follow
bits (if any) also.
+ The follow context selection function $follow_context()$
is defined by:
+
+ begin{index, context_set}
+ bsCODE{pos= max(index, length(context_set[follow])-1 }
+ bsCODE{ctx_index = context_set[follow][pos]}
+ bsRET{AContexts[ctx_index]}
+ end
+
+ So the last follow context is used for all the remaining
follow bits also.
+
+ paragraph{Unsigned integer decoding \}
+
+ Unsigned integers are decoded by:
+
+ begin
+ bsCODE{value = 1}
+ bsCODE{index = 0}
+ bsWHILE{read_boola(follow_context(index,context_set)
)== false}
+ bsCODE{value ll = 1}
+
bsIF{read_boola(text{state[contexts]}[context_set[data])
])}
+ bsCODE{value += 1}
+ bsEND
+ bsCODE{index += 1}
+ bsEND
+ bsCODE{value -= 1}
+ bsRET
+ end
+
+ paragraph{Signed integer decoding \}
+
+ $read_sinta()$ decodes first the magnitude then the sign,
as necessary:
+
+ begin
+ bsCODE{value=read_uinta(context_set)}
+ bsIF{value != 0}
+ bsIF{read_boola(AContexts[context_set[sign])]) ==
true}
+ bsCODE{value=-value}
+ bsEND
+ bsEND
+ bsRET
+ end
No newline at end of file
Index: spec-structure.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/spec-structure.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** spec-structure.tex 9 Nov 2006 12:11:37 -0000 1.9
--- spec-structure.tex 11 Apr 2007 15:28:35 -0000 1.10
***************
*** 28,32 ****
appendix
! %section{Arithmetic Encoding}input
%section{Comments on coders}input
%section{Subband inverse quantizer
values}input
--- 28,33 ----
appendix
! clearpage
! section{Arithmetic Coding}input
%section{Comments on coders}input
%section{Subband inverse quantizer
values}input
***************
*** 45,52 ****
section{Profiles and levels}input
- clearpage
- begin{informative*}
- section{Arithmetic encoding
(Informative)}input
- end{informative*}
%clearpage
--- 46,49 ----
Index: ref-default-videoparams.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/ref-default-videopara
ms.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** ref-default-videoparams.tex 15 Feb 2007 16:44:31
-0000 1.7
--- ref-default-videoparams.tex 11 Apr 2007 15:28:35
-0000 1.8
***************
*** 13,17 ****
subsection{Sequence parameters}
! begin[!h]
begin{|l|c|c|c|c|c|c|c|}
hline
--- 13,17 ----
subsection{Sequence parameters}
! begin[!ht]
begin{|l|c|c|c|c|c|c|c|}
hline
***************
*** 31,35 ****
end
! begin[!h]
begin{|l|c|c|c|c|c|c|}
hline
--- 31,35 ----
end
! begin[!ht]
begin{|l|c|c|c|c|c|c|}
hline
***************
*** 53,57 ****
subsection{Source parameters}
! begin[!h]
begin{|l|c|c|c|c|c|c|c|}
hline
--- 53,57 ----
subsection{Source parameters}
! begin[!ht]
begin{|l|c|c|c|c|c|c|c|}
hline
***************
*** 95,99 ****
end
! begin[!h]
begin{|l|c|c|c|c|c|c|}
hline
--- 95,99 ----
end
! begin[!ht]
begin{|l|c|c|c|c|c|c|}
hline
***************
*** 139,143 ****
subsection{Decoding parameters}
! begin[!h]
begin{|l|c|c|c|c|c|c|c|}
hline
--- 139,143 ----
subsection{Decoding parameters}
! begin[!ht]
begin{|l|c|c|c|c|c|c|c|}
hline
***************
*** 180,184 ****
end
! begin[!h]
begin{|l|c|c|c|c|c|c|}
hline
--- 180,184 ----
end
! begin[!ht]
begin{|l|c|c|c|c|c|c|}
hline
Index: motion-dec.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/motion-dec.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** motion-dec.tex 4 Apr 2007 16:00:08 -0000 1.12
--- motion-dec.tex 11 Apr 2007 15:28:35 -0000 1.13
***************
*** 312,316 ****
setlength
! begin[!h]
centering
begin(15,20)
--- 312,316 ----
setlength
! begin[!ht]
centering
begin(15,20)
***************
*** 346,350 ****
setlength{.75em}
! begin[!h]
centering
begin(60,17.5)
--- 346,350 ----
setlength{.75em}
! begin[!ht]
centering
begin(60,17.5)
Index: stream-access.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/stream-access.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** stream-access.tex 22 Nov 2006 14:06:43 -0000 1.2
--- stream-access.tex 11 Apr 2007 15:28:35 -0000 1.3
***************
*** 5,10 ****
section{Data encodings}input
-
- clearpage
- section{Arithmetic decoding}input
-
--- 5,6 ----
Index: state-macros.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/state-macros.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** state-macros.tex 4 Apr 2007 16:00:08 -0000 1.16
--- state-macros.tex 11 Apr 2007 15:28:35 -0000 1.17
***************
*** 38,41 ****
--- 38,42 ----
kdefine
kdefine
+ kdefine
kdefine
Index: arith-encoder.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/arith-encoder.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** arith-encoder.tex 9 Nov 2006 12:11:37 -0000 1.3
--- arith-encoder.tex 11 Apr 2007 15:28:35 -0000 1.4
***************
*** 1,2 ****
--- 1,51 ----
+ This appendix provides three things:
+ begin
+ item a description of the principles of arithmetic
+ coding
+ item a specification of the arithmetic decoding
+ engine used in Dirac
+ item a description of a compatible arithmetic encoder
+ end
+
+ begin{informative*}
+ subsection{Arithmetic coding principles (INFORMATIVE)}
+
+ This section provides an introduction to the principles
underlying arithmetic
+ coding. Since arithmetic coding is very extensively
described in published literature,
+ this section is necessarily brief: for more information,
Alasdair Moffat's
+ article ''Arithmetic coding revisited'' is recommended.
+
+ Arithmetic coding is extremely powerful and can approach
the Shannon information
+ limit for given data. Arithmetic encoding consists of an
asynchronous state machine,
+ in which data
+ is fed to an arithmetic encoding engine, together with an
estimate of its
+ probability, and the encoder outputs bits. It is
asynchronous because data
+ input does not trigger any output directly, but changes
the state of the
+ engine. When a certain state is reached a variable amount
of output is produced.
+
+ This asynchronous nature makes arithmetic coding trickier
to implement
+ than Variable-Length Codes (VLCs) but is essential to its
optimal nature. Consider
+ a binary symbol $b$, with $p(b=0)=p_0$ and $p(b=1)=1-p_0$.
The entropy of $b$
+ is the expected number of bits required to encode $b$, and
is equal to
+ [e(p_0)=p_0log_2(1/p_0)+(1-p_0)log(1/(1-p_0))]
+
+ If $e(p_0)$ is plotted against $p_0$, it can be seen that
if $p_0$ is not equal
+ to 0.5 exactly, $e(p_0)<1$. This means that an optimal
binary entropy encoder
+ that operates symbol by symbol, cannot produce an output
for every symbol - i.e.
+ it must operate asynchronously.
+
+ subsubsection{Interval division and scaling}
+ The fundamental idea of arithmetic coding is interval
division and scaling. An
+ arithmetic code can be thought of as a single number lying
in an interval
+ determined by the sequence of values being coded. For
simplicity, this discussion
+ describes binary arithmetic coding, but larger symbol
alphabets can be treated
+ in an analogous manner.
+ [TBC]
+
+ subsubsection{Finite precision arithmetic}
+
+ subsection{Arithmetic encoding (INFORMATIVE)}
+ end{informative*}
+
This document only specifies the decoding of arithmetic
coded data.
However whilst it is clearly vital that an encoding
process matches the decoding
***************
*** 7,11 ****
the Dirac arithmetic decoding engine.
! subsection{Encoder variables}
An arithmetic encoder would require the following integer
variables:
--- 56,60 ----
the Dirac arithmetic decoding engine.
! subsubsection{Encoder variables}
An arithmetic encoder would require the following integer
variables:
***************
*** 111,113 ****
--- 160,599 ----
Where the ``write_bit(bit)'' function outputs a single
bit.
+ end
+
+
+ subsection{Arithmetic decoding engine}
+
+ This section is a normative specification of the operation
of the arithmetic
+ decoding engine.
+
+ label
+
+ This section specifies the arithmetic decoding engine and
+ processes for using it to extract data from coded
streams.
+
+ The arithmetic decoding engine consists of two elements:
+
+ begin
+ item a collection of state variables representing the
state of the arithmetic
+ decoder (Section ref)
+ item a function for extracting binary values from the
decoder
+ and updating the decoder state (Section
ref)
+ end
+
+ subsubsection{State and contexts}
+ label
+
+ The arithmetic decoder state consists of the following
decoder state variables:
+
+ begin
+ item $ALow$, an integer representing the beginning of
the current coding interval
+ item $ARange$, an integer representing the size of the
current coding interval
+ item $ACode$, an integer within the interval from
$ALow$ to $AHigh$, determined from the encoded bitstream
+ item $ABitsLeft$, a decrementing count of the number of
bits yet to be read in
+ item $AContexts$, a map of all the contexts used in the
Dirac decoder
+ end
+
+ A context $context$ is an integer array with a single
value which encapsulates
+ the probability of zero in that context represented as a
16 bit number, such that
+ [0<context[prob0]<text]
+
+ Contexts are accessed by decoding functions via the
indices defined in Section ref.
+
+ subsubsection
+ label
+
+ At the beginning of the decoding of any data unit, the
arithmetic
+ decoding state is initialised as follows:
+
+
begin{block_data
_length}
+ bsCODE{ABitsLeft=8*block_data_length}
+ bsCODE{ALow = text}
+ bsCODE{ARange =text}
+ bsCODE{ACode =text}
+ bsFOR{i=0}
+ bsCODE{ACode <<= 1}
+ bsCODE{ACode+= read_bitb()}
+ bsEND
+ bsCODE{init_contexts()}
+ end
+
+ Contexts are initialised by the $init_contexts()$
function as follows:
+
+ begin{}
+ bsFOR{i=0}{length(AContexts)-1}
+ bsCODE{AContexts[i][prob0]=0x8000}
+ bsEND
+ end
+
+ subsubsection{Data input}
+ label
+
+ The arithmetic decoding process accesses data in a
contiguous block of bytes
+ whose size is set on initialisation (Section
ref). The bits in this
+ block are sufficient to allow for the
+ decoding of all coefficients. However, the specification
of arithmetic
+ decoding operations in this section may occasionally cause
further bits to be read,
+ even though they are not required for determining decoded
values. For this
+ reason the bounded-block read function $read_bitb()$
(Section ref) is
+ used for data access.
+
+ Since the length of arithmetically coded data elements is
given in bytes within the Dirac
+ stream, there may be bits left unread when all values have
been extracted. These
+ are flushed as desribed in Section ref.
Since arithmetically coded blocks
+ are byte-aligned and a whole number of bytes, this aligns
data input with the beginning of the byte
+ after the arithmetically coded data i.e. at the end of
the
+ data chunk. $flush_inputb()$ is always called at the end
of decoding an arithmetically encoded
+ data element.
+
+ begin
+ The Dirac arithmetic decoding engine uses 16 bit words,
and so if all coefficients are
+ coded no more than 16 additional bits should be read
beyond the end of the block. Hence it
+ would seem sufficient to read in the entire block of data
and pad the end with two bytes of value 0xFF,
+ to avoid a branch condition on inputting data
+ However, an arithmetically encoded block may end with a
string of 1s, which an encoder could
+ conceivably strip out to save bits, in the knowledge that
$read_bitb()$ will re-insert them. Terminating
+ strings of 1s can occur (but not exclusively) in coding
many zero wavelet subband coefficients at the end
+ of a subband. So a larger number of pad bytes may be
required in practice.
+ end
+
+ subsubsection{Decoding boolean values}
+ label
+
+ The arithmetic decoding engine is a multi-context,
adaptive binary
+ arithmetic decoder, performing binary renormalisation and
producing
+ binary outputs. For each bit decoded, the semantics of the
relevant
+ calling decoder function determine which contexts are
passed to the
+ arithmetic decoding operations.
+
+ This section specifies the operation of the
$read_boola()$ function
+ for extracting a boolean value from the Dirac stream. The
overall decoding
+ process for extracting a symbol is as defined by the
following
+ pseudocode:
+
+ begin
+ bsCODE{context=AContexts[context_index]}
+ bsCODE{count = ACode-ALow+1}
+ bsCODE{range_times_prob = (ARange * context[prob0])gg
16}
+ bsIF{ count > range_times_prob }
+ bsCODE{value = true}
+ bsCODE{ALow += range_times_prob}
+ bsCODE{ARange -= range_time_prob}
+ bsELSE
+ bsCODE{value = false}
+ bsCODE{ARange = range_times_prob}
+ bsEND
+
bsCODE{update_context(AContexts[context_index],value)}
+ bsWHILE{ARange<=text}
+ bsCODE{renormalise()}
+ bsEND
+ bsRET(value)
+ end
+
+ begin
+ The function scales the probability of the symbol $0$ from
the decoding context
+ so that if this probability were $1$, then the interval
would equal that between
+ $ALow$ and
+ [high=ALow+ARange-1]
+ and $count$ is set to the normalised cut-off between 0 and
1 within this range.
+ end
+
+ subsubsection
+ label
+
+ Renormalisation is applied to stop the arithmetic decoding
+ engine from losing accuracy: the range must not get too
small,
+ in order that 0 and 1 may be distinguished.
Renormalisation is
+ applied while the range is less than or equal to a
quarter of
+ the total available 16-bit range ($text$).
+
+ For convenience let $low=ALow$ and $high=ALow+ARange-1$
+ represent the upper and lower bounds of the interval. If
the
+ range is $<=text$ then
+ one of three possibilities must obtain:
+ begin
+ item the msbs of $low$ and $high$ are both 0
+ item the msbs of $low$ and $high$ are both 1
+ item $low=b01...$, $high=b10....$, and the interval
straddles the half-way point 0x8000.
+ end
+
+ Renormalisation doubles the interval and reads a bit into
the codeword
+ as follows:
+
+ begin{}
+ bsIF{(ALow+ARange-1)^ALow>=text}
+ bsCODE{ACode ^= text}
+ bsCODE{ALow ^= text}
+ bsEND
+ bsCODE{ALow <<= 1}
+ bsCODE{ARange <<= 1}
+ bsCODE{ALow &= text}
+ bsCODE{ACode <<= 1}
+ bsCODE{ACode+= read_bitb()}
+ bsCODE{ACode &= text}
+ end
+
+ The second bit is flipped if there is a straddle condition
(case 3). The renormalisation
+ process has the effect that: in case 1, the interval
$[low,high]$ is doubled from 0 ($xmapsto 2*x$);
+ in case 2 it is doubled from 1 ($xmapsto 2*x-1$); and in
case 3 it is doubled from 1/2 ($xmapsto 2x-0.5$).
+
+ begin
+ Note that if 16-bit words (unsigned shorts) are used for
decoder state variables $ALow$,
+ and $ACode$ then there is no need for {&}-ing with
0xFFFF. However, the
+ operations specified here are defined in terms of
integers, since intermediate calculations
+ require higher dynamic range. In software, the efficiency
of using short word lengths may
+ or may not be offset by the requirement to cast to other
data types for these calculations.
+ end
+
+ begin
+ subsection{Alternative arithmetic decoding engines}
+
+ to
+ 16 consisting of three positive values:
+ begin
+ item $context[count0]$ is a count of the number of
zeroes
+ item $context[count1]$ is a count of the number of ones
+ item $context[prob0]$ is an estimate of the probability
of zero to 16 bit accuracy
+ end
+
+ Contexts are accessed by decoding functions
+ via the indices defined in Section ref.
+
+ Although counts are updated with each symbol decoded, the
probability is only updated occasionally, as it is
computationally
+ expensive (see Section ref below).
+
+ subsubsection{Rescaling contexts and probabilities}
+ label
+
+ Contexts maintain counts to 8 bit accuracy, and contexts
are rescaled when the total count (count0+count1) reaches
256. In addtion, prob0 is recalculated every
+ 8 symbols in each context. A context is rescaled by
halving the counts of $0$ and $1$.
+
+ begin{context,value}
+ bsIF{value==true}
+ bsCODE{context[count1] += 1}
+ bsELSE
+ bsCODE{context[count0] += 1}
+ bsEND
+ bsIF( (context[count0]+context[count1])%8==0)
+ bsIF{context[0]+context[1]== 256}
+ bsCODE{context[0] += 1}
+ bsCODE{context[0] gg= 1}
+ bsCODE{context[1] += 1}
+ bsCODE{context[1] gg= 1}
+ bsEND
+ bsCODE{calc_prob0(context)}
+ bsEND
+ end
+
+ The probability of zero is recalculated to approximate
+ [
frac{context[count0]*2^}{context[count0]+context[count1
]}]
+ to 16 bit accuracy:
+
+ begin
+ bsCODE{weight = context[count0]+context[count1]}
+ bsCODE{inverse_weight=(2^+(weight//2))//weight}
+ bsCODE{context[prob0]=context[count0]*inverse_weight}
+ end
+
+ begin
+ Note that since $context[count0]<weight$,
$context[prob0]$ is always a 16 bit unsigned quantity.
+ The inverse weight may easily be stored within a look-up
table.
+ end
+
+ subsection
+ label
+
+ At the beginning of the decoding of any data unit, the
arithmetic
+ decoding state is initialised as follows:
+
+
begin{block_data
_length}
+ bsCODE{ABitsLeft=8*block_data_length}
+ bsCODE{ALow = text}
+ bsCODE{ARange =text}
+ bsCODE{ACode =text}
+ bsFOR{i=0}
+ bsCODE{ACode <<= 1}
+ bsCODE{ACode+= read_bitb()}
+ bsEND
+ bsCODE{init_contexts()}
+ end
+
+ Contexts are initialised by the $init_contexts()$
function as follows:
+
+ begin{}
+ bsFOR{i=0}{length(AContexts)-1}
+ bsCODE{AContexts[i][count0]=1}
+ bsCODE{AContexts[i][count1]=1}
+ bsCODE{AContexts[i][prob0]=0x8000}
+ bsEND
+ end
+
+ subsection{Data input}
+ label
+
+ The arithmetic decoding process accesses data in a
contiguous block of bytes
+ whose size is set on initialisation (Section
ref). The bits in this
+ block are sufficient to allow for the
+ decoding of all coefficients. However, the specification
of arithmetic
+ decoding operations in this section may occasionally cause
further bits to be read,
+ even though they are not required for determining decoded
values. For this
+ reason the bounded-block read function $read_bitb()$
(Section ref) is
+ used for data access.
+
+ Since the length of arithmetically coded data elements is
given in bytes within the Dirac
+ stream, there may be bits left unread when all values have
been extracted. These
+ are flushed as desribed in Section ref.
Since arithmetically coded blocks
+ are byte-aligned and a whole number of bytes, this aligns
data input with the beginning of the byte
+ after the arithmetically coded data i.e. at the end of
the
+ data chunk. $flush_inputb()$ is always called at the end
of decoding an arithmetically encoded
+ data element.
+
+ begin
+ The Dirac arithmetic decoding engine uses 16 bit words,
and so if all coefficients are
+ coded no more than 16 additional bits should be read
beyond the end of the block. Hence it
+ would seem sufficient to read in the entire block of data
and pad the end with two bytes of value 0xFF,
+ to avoid a branch condition on inputting data
+ However, an arithmetically encoded block may end with a
string of 1s, which an encoder could
+ conceivably strip out to save bits, in the knowledge that
$read_bitb()$ will re-insert them. Terminating
+ strings of 1s can occur (but not exclusively) in coding
many zero wavelet subband coefficients at the end
+ of a subband. So a much larger number of pad bytes may be
required in practice.
+ end
+
+ subsection{Decoder functions}
+ label
+ The arithmetic decoding engine is a multi-context,
adaptive binary
+ arithmetic decoder, performing binary renormalisation and
producing
+ binary outputs. For each bit decoded, the semantics of the
relevant
+ calling decoder function determine which contexts are
passed to the
+ arithmetic decoding operations.
+
+ subsubsection{Decoding boolean values}
+
+ label
+
+ This section specifies the operation of the
$read_boola()$ function
+ for extracting a boolean value from the Dirac stream. The
overall decoding
+ process is defined for extracting a symbol is as defined
by the following
+ pseudocode:
+
+ begin
+ bsCODE{context=AContexts[context_index]}
+ bsCODE{count = ACode-ALow+1}
+ bsCODE{range_times_prob = (ARange * context[prob0])gg
16}
+ bsIF{ count > range_times_prob }
+ bsCODE{value = true}
+ bsCODE{ALow += range_times_prob}
+ bsCODE{ARange -= range_time_prob}
+ bsELSE
+ bsCODE{value = false}
+ bsCODE{ARange = range_times_prob}
+ bsEND
+
bsCODE{update_context(AContexts[context_index],value)}
+ bsCODE{renormalise()}
+ bsEND
+ bsRET(value)
+ end
+
+ begin
+ [Describe what's going on here]
+ end
+
+ subsubsection
+ label
+
+ Renormalisation is applied to stop the arithmetic decoding
engine from losing accuracy: the range
+ must not get too small to allow 0 and 1 to be
distinguished. Renormalisation is applied while the
+ range is less than or equal to a quarter of the total
available 16-bit range:
+
+ begin{}
+ bsWHILE{ARange<=text}
+ bsIF{(ALow+ARange-1)^ALow>=text}
+ bsCODE{resolve_straddle()}
+ bsEND
+ bsCODE{shift_bits()}
+ bsEND
+ end
+
+ begin
+ Let the bottom of the arithmetic coding interval is
represented by $low=ALow$ and the top by
$high=ALow+ARange-1$.
+ When the range is one quarter or less of the original
range ($2^$), then one of three possibilities occurs:
+ begin
+ item the top bits of $low$ and $high$ are both 0
+ item the top bits of $low$ and $high$ are both 1
+ item $low=b01...$, $high=b10....$, and the interval
straddles the half-way point 0x8000.
+ end
+
+ In all of these cases the interval can be doubled in size
to increase accuracy. In the first case, it is doubled from
zero ($xmapsto 2*x$);
+ in the second it is doubled from 1 ($xmapsto 2*x-1$); and
in the third it is doubled from 1/2 ($xmapsto 2x-0.5$).
+
+ end
+
+ begin{}
+ bsCODE{ACode ^= text}
+ bsCODE{ALow ^= text}
+ end
+
+ begin{}
+ bsCODE{ALow <<= 1}
+ bsCODE{ARange <<= 1}
+ bsCODE{ALow &= text}
+ bsCODE{ACode <<= 1}
+ bsCODE{ACode+= read_bitb()}
+ bsCODE{ACode &= text}
+ end
+
+ begin
+
+ begin
+ The function scales the probability of the symbol $0$ from
the decoding context
+ so that if this probability were $1$, then the interval
would equal that between
+ $ALow$ and $AHigh$. If $ACode$ is greater than this
cut-off, then 1 ($true$) has
+ been encoded, else 0 ($false$) has.
+ end
+
+ subsubsection{Shifting bits in}
+
+ label
+
+ This section defines the operation of the
$shift_bit_in()$
+ and $shift_all_bits()$ functions
+ for reading bits into the arithmetic decoding state
variables.
+
+ begin{}
+ bsCODE{AHigh ll= 1}
+ bsCODE{AHigh &= text}
+ bsCODE{AHigh += 1}
+ bsCODE{ALow ll= 1}
+ bsCODE{ALow &= text}
+ bsCODE{ACode ll= 1}
+ bsCODE{ACode &= text}
+ bsCODE{ACode += read_bitb()}
+ end
+
+ $shift_all_bits()$ expands the interval between $ALow$
and $AHigh$
+ until the msbs (bit 15) differ and the interval no longer
+ straddles the half-way point 0x8000.
+
+ begin{}
+ bsWHILE{ AHigh&text)==text text (ALow&text)==text}
+ bsCODE{shift_bit_in()}
+ bsEND
+ bsWHILE{ (AHigh&text)==text text (ALow&text)==text }
+ bsCODE{ACode wedge= text}
+ bsCODE{AHigh wedge= text}
+ bsCODE{ALow wedge= text}
+ bsCODE{shift_bit_in()}
+ bsEND
+ end
+
+ begin
+ Note that if 16-bit words (unsigned shorts) are used for
decoder state variables $ALow$,
+ $AHigh$ and $ACode$ then there is no need for
{&}-ing with 0xFFFF. However, the
+ operations specified here are defined in terms of
integers, since intermediate calculations
+ require higher dynamic range. In software, the efficiency
of using short word lengths may
+ or may not be offset by the requirement to cast to other
data types for these calculations.
+ end
+
+
+
end
No newline at end of file
Index: mc.tex
============================================================
=======
RCS file: /cvsroot/dirac/compress/doc/latex_spec/mc.tex,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** mc.tex 4 Apr 2007 16:00:08 -0000 1.13
--- mc.tex 11 Apr 2007 15:28:35 -0000 1.14
***************
*** 99,103 ****
end{informative*}
! begin[!h]
centering
includegraphics[width=0.7textwidth]{figs/block-coverage.ep
s}
--- 99,103 ----
end{informative*}
! begin[!ht]
centering
includegraphics[width=0.7textwidth]{figs/block-coverage.ep
s}
***************
*** 206,210 ****
{bf 1.} Note that the number of bits $total_wt_bits$
used for
the OBMC weighting matrix depends upon the block sizes -
specifically
! the block overlaps - selected. A Dirac decoder level
(ref)
specifies the maximum block overlaps allowable, and hence
the word widths necessary for processing OBMC. If we
assume that
--- 206,210 ----
{bf 1.} Note that the number of bits $total_wt_bits$
used for
the OBMC weighting matrix depends upon the block sizes -
specifically
! the block overlaps - selected. A Dirac decoder level
(Section ref)
specifies the maximum block overlaps allowable, and hence
the word widths necessary for processing OBMC. If we
assume that
***************
*** 361,365 ****
for interior blocks is as shown in Figure
ref{fig:weightprofile}.
! begin[!h]
centering
includegraphics[width=0.7textwidth]{figs/obmc-profile}
--- 361,365 ----
for interior blocks is as shown in Figure
ref{fig:weightprofile}.
! begin[!ht]
centering
includegraphics[width=0.7textwidth]{figs/obmc-profile}
Index: wlt-dec.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/wlt-dec.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** wlt-dec.tex 4 Apr 2007 08:08:11 -0000 1.19
--- wlt-dec.tex 11 Apr 2007 15:28:35 -0000 1.20
***************
*** 52,56 ****
setlength
! begin[!h]
centering
begin(25,35)
--- 52,56 ----
setlength
! begin[!ht]
centering
begin(25,35)
***************
*** 530,534 ****
%% Table of context sets for signed coefficient extraction
%%
! begin[h!]
begin{|c|c|c||l|l|}
hline
--- 530,534 ----
%% Table of context sets for signed coefficient extraction
%%
! begin[!ht]
begin{|c|c|c||l|l|}
hline
Index: bs-spec.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/bs-spec.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** bs-spec.tex 4 Apr 2007 08:11:32 -0000 1.12
--- bs-spec.tex 11 Apr 2007 15:28:35 -0000 1.13
***************
*** 129,133 ****
for applications where the required delay is less than a
picture -- perhaps much less.
! begin[!h]
centering
begin{|c|c|l|c|}
--- 129,133 ----
for applications where the required delay is less than a
picture -- perhaps much less.
! begin[!ht]
centering
begin{|c|c|l|c|}
***************
*** 443,447 ****
The supported chroma formats are specified in Table
ref{tab:chromaformats}:
! begin[!h]
centering
begin{|c|c|}
--- 443,447 ----
The supported chroma formats are specified in Table
ref{tab:chromaformats}:
! begin[!ht]
centering
begin{|c|c|}
***************
*** 956,960 ****
in Section ref).
! begin[!h]
centering
begin{|c|c|c|c|c|}
--- 956,960 ----
in Section ref).
! begin[!ht]
centering
begin{|c|c|c|c|c|}
***************
*** 1252,1256 ****
$WaveletIndex$ shall lie in the range 0 to 7.
! begin[!h]
centering
begin{|c|c|}
--- 1252,1256 ----
$WaveletIndex$ shall lie in the range 0 to 7.
! begin[!ht]
centering
begin{|c|c|}
***************
*** 1344,1348 ****
end
! begin[!h]
centering
begin{|c|c|}
--- 1344,1348 ----
end
! begin[!ht]
centering
begin{|c|c|}
Index: low-delay.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/low-delay.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** low-delay.tex 15 Feb 2007 16:41:24 -0000 1.4
--- low-delay.tex 11 Apr 2007 15:28:35 -0000 1.5
***************
*** 74,77 ****
--- 74,84 ----
the transform parameters for the components are placed in
the picture header.
+ begin[!ht]
+ centering
+
%includegraphics[width=0.7textwidth]{figs/wavelet-slice.ep
s}
+ caption{Partition of wavelet coefficients into slices}
+ label{fig:waveletslice}
+ end
+
This section specifies the syntax and parsing operations
only: picture decoding operations are as
specified in Section ref, ref and
ref. However, the slice
Index: layout-fullsize.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/layout-fullsize.tex,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** layout-fullsize.tex 15 Feb 2007 16:44:30 -0000 1.13
--- layout-fullsize.tex 11 Apr 2007 15:28:35 -0000 1.14
***************
*** 29,34 ****
pagestyle
fancyhf{}
! fancyhead[EL,OR]
! fancyhead[ER]
fancyhead[OL]
%fancyfoot[EC,OC]{input{.version-date}}
--- 29,34 ----
pagestyle
fancyhf{}
! fancyhead[L,OR]
! fancyhead[R]
fancyhead[OL]
%fancyfoot[EC,OC]{input{.version-date}}
***************
*** 78,82 ****
begin
! newcommand{text{0.10.5_pre1 }}
begin
--- 78,82 ----
begin
! newcommand{text{0.11.0 }}
begin
Index: arith.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/arith.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** arith.tex 4 Apr 2007 16:00:08 -0000 1.16
--- arith.tex 11 Apr 2007 15:28:35 -0000 1.17
***************
*** 1,11 ****
! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
! % - This chapter defines the arithmetic decoding - %
! % - engine - %
! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
! label
! This section describes the arithmetic decoding engine and
! processes for using it to extract data from the Dirac
stream.
The arithmetic decoding engine consists of two elements:
--- 1,251 ----
! label
! This appendix provides three things:
! begin
! item a description of the principles of arithmetic
! coding
! item a specification of the arithmetic decoding
! engine used in Dirac
! item a description of a compatible arithmetic encoder
! end
! begin{informative*}
! subsection{Arithmetic coding principles (Informative)}
!
! This section provides an introduction to the principles
underlying arithmetic
! coding. Since arithmetic coding is very extensively
described in published literature,
! this section is necessarily brief: for more information,
Alasdair Moffat's
! article ''Arithmetic coding revisited'' (ACM Transactions
on Information Systems,
! Vol. 16 #3, July 1998) is recommended.
!
! Arithmetic coding is an extremely powerful form of entropy
coding, which closely
! approximates the Shannon information limit for given data.
Arithmetic
! encoding consists of an asynchronous state machine,
! in which data
! is fed to an arithmetic encoding engine, together with an
estimate of its
! probability, and the encoder outputs bits (Figure
ref{fig:arithencoder}.
! It is asynchronous because data
! input does not trigger any output directly, but changes
the state of the
! engine. When a certain state is reached a variable amount
of output is produced.
! end{informative*}
! setlength
! begin[!ht]
! centering
! begin(45,12)
!
! %put(0,3){vector(1,0)}
! %put(10,3){oval(10,4.7)put(-1.75,0.5)
put(-1.25,-1)}
! %put(15,3){vector(1,0)}
!
%put(25,3){oval(10,4.7)put(-1.75,0.5)put(-1.3,-1
)}
! %put(30,3){vector(1,0)}
! %put(17.5,3){line(0,1)}
! %put(32.5,3){line(0,1)}
! %put(32.5,8){vector(-1,0)}
! %put(17.5,8){line(1,0)}
!
! end
! caption{Arithmetic encoder}label{fig:arithencoder}
! end
!
! begin{informative*}
! This asynchronous nature makes arithmetic coding trickier
to implement
! than Variable-Length Codes (VLCs) but is essential to its
optimal nature. Consider
! a binary symbol $b$, with $p(b=0)=p_0$ and $p(b=1)=1-p_0$.
The entropy of $b$
! is the expected number of bits required to encode $b$, and
is equal to
! [e(p_0)=p_0log_2(1/p_0)+(1-p_0)log_2(1/(1-p_0))]
!
! If $e(p_0)$ is plotted against $p_0$, it can be seen that
if $p_0$ is not equal
! to 0.5 exactly, $e(p_0)<1$. This means that an optimal
binary entropy encoder
! that operates symbol by symbol, cannot produce an output
for every symbol - i.e.
! it must operate asynchronously.
!
! subsubsection{Interval division and scaling}
! The fundamental idea of arithmetic coding is interval
division and scaling. An
! arithmetic code can be thought of as a single number lying
in an interval
! determined by the sequence of values being coded. For
simplicity, this discussion
! describes binary arithmetic coding, but larger symbol
alphabets can be treated
! in an analogous manner.
!
! Let us begin with the interval $[0,1)$, and suppose that
we know (or have some
! estimate of) the probability of zero, $p_0$. Conceptually
we divide the interval
! into the intervals $[0,p0)$ and $[p_0,1)$. Suppose we code
a 0 as the
! first symbol. In this case the interval is changed to
$[0,p0)$. If we code a 1,
! then the interval is changed to $[p0,1)$. After coding 1
or more symbols we
! arrive at an interval $[low,high)$. To code the next
symbol we partition this interval
! into $[low,low+p_0(high-low))$ and
$[low+p_0(high-low),b)$, and if there is a 0 we choose the
! first interval, and if a 1 the second.
!
! For any integer $N$, this process clearly partitions the
interval $[0,1)$ into
! a set of disjoint intervals that correspond to all the
sequences of $N$ bits.
! Identifying such a bit sequence is equivalent to choosing
a value in the
! corresponding interval, and for an interval width $w$ that
in general requires
! [leftlceillog_2(1/w)rightrceil]
! bits. With static probabilities, on average,
! [w=p_0^(1-p_0)^{N(1-p_0)}]
! resulting in
! [leftlceil Ne(p_0)rightrceil]
! being used, demonstrating the near-optimality of
arithmetic coding.
! Moreover, it is clearly possible to create an adaptive
arithmetic code by
! changing the estimate of $p_0$ based on previously coded
data.
!
! subsubsection{Finite precision arithmetic}
! As it stands, the procedure outlined in the previous
section has a number of
! drawbacks for practical application. Firstly, it requires
unlimited precision
! to scale the interval, which is not available in real
hardware or software.
! Secondly, it only produces an output when all values have
been coded. These
! problems are addressed by renormalisation and progressive
output: periodically rescaling the
! interval, and outputting the most significant bits of
$low$ and $high$ whenever they agree.
!
! For example, if we know that $low=b0xyz...$ and
$high=b0pqr...$ then we can
! output $0$, since this must prefix any value lying in the
interval,
! and shift $low$ and $high$ to get $low=bxyz...$ and
$high=bpqr...$.
! This has the effect of doubling the interval from 0
($xmapsto 2x$). Likewise
! if $low=b1xyz...$ and $high=b1pqr...$ we can output $1$
and shift to get
! $low=bxyz...$ and $high=bpqr...$ again: this is equivalent
to doubling the interval
! from 1 ($xmapsto 2x-1$).
!
! One problem remains, when the interval resolutely sits on
the fence, straddling
! 1/2 whilst getting smaller and smaller, with the most
! significant bits of low and high staying as 0 and 1
respectively.
! In this case, when the straddle is finally resolved, $low$
and $high$ will
! both be of the form $b10000...xyz$ or $b01111...pqr$.
!
! The resolution strategy is to again rescale $low$ and
$high$, but this time
! double from 1/2 ($xmapsto 2x-frac$), and keep a
count of the number $k$
! of times this is done, as this is the number of carry bits
that are
! required. When the straddle is resolved as 1, then 1
followed by $k$ zero bits is
! output, otherwise 0 followed by k 1s is output. This
ensures that the
! output exactly represents the small straddling interval.
!
! A decoder can determine a symbol as soon as it has
sufficient bits to distinguish
! whether a value lies in one interval or another. If
constraints are placed on the
! size of the smallest interval before
! renormalisation (for example, by renormalising often
enough and by having a fixed
! smallest allowable probability), then this can be
accomplished within a fixed word width.
!
! end{informative*}
! begin{informative*}
! subsection{Arithmetic encoding (Informative)}
!
! This document only normatively specifies the decoding of
arithmetic coded data.
! However whilst it is clearly vital that an encoding
process matches the decoding
! process, it is not entirely straightforward to derive an
implementation of the
! encoder by only looking only at the decoder specification.
Therefore this
! informative section describes a possible implementation
for an
! arithmetic encoding engine that will produce output
decodeable by
! the Dirac arithmetic decoding engine.
!
! subsubsection{Encoder variables}
!
! An arithmetic encoder would require the following unsigned
integer variables:
! begin
! item $text$, a value indicating the bottom of the
encoding interval
! item $text$, a value indicating the width of the
encoding interval
! item $text$, a value tracking the number of
unresolved ``straddle" conditions
! (described below)
! end
!
! A Dirac binary arithmetic encoder implementation will code
a set of data in three stages:
! begin
! item Initialisation
! item Processing of all values
! item Flushing
! end
!
! subsubsection
!
! Initialisation of the arithmetic encoder is very simple --
the internal variables are
! set as:
! begin{eqnarray*}
! text&=&text \
! text&=&text \
! text&=&0
! end{eqnarray*}
!
! With 16 bit accuracy, $0x10000$ corresponds to an interval
width value of 1.
!
! subsubsection{Processing of binary values}
! begin
! Bits are encoded one at a time based on an estimated
probability
! embodied in a ``context''. As with decoding, the context
simply relates to
! counts of the number of zeros or ones that have been
previously encoded.
!
! A possible algorithm for encoding a single bit, given a
context, is:
!
! Encode Binary Arithmetic Coded Bit
! begin
! write_ba(symbol, context):
! while ( ((high&0x4000)==0x0) and
! ((low&0x4000)==0x4000) ):
! code ^= 0x4000
! high ^= 0x4000
! low ^= 0x4000
! shift_bit_out()
! weight = context[0] + context[1]
! scaler = (0x10000+weight//2)//weight
!
! probability0 = context[0]*scaler
! range = high-low+1
! range_x_prob = (range * probability0)>>16
! if ( symbol )
! context[1] += 1
! low = low + range_x_prob
! else
! context[0] += 1
! high = low + range_x_prob - 1
! if ( (context[0] + context[1]) > 255 ):
! #Halve counts in the context
! context[0] >> 1
! context[0] += 1
! context[1] >> 1
! context[1] += 1
! while (((high&0x8000)==0x0) and
((low&0x8000)==0x0)):
! output_bits()
! shift_bit_out()
! end
!
! Shift Bit Out
! begin
! shift_bit_out():
! high << 1
! high &= 0xFFFF
! high += 1
! low << 1
! low &= 0xFFFF
! end
!
! Output Bits
! begin
! output_bits():
! write_bit( (high&0x8000)==0x8000 )
! while ( underflow > 0 ):
! write_bit( high&0x8000)==0x0 )
! underflow -= 1
! end
!
! Flush Encoder
! begin
! flush_encoder():
!
! write_bit( (high&0x4000)==0x4000 )
! while ( underflow >= 0 ):
! write_bit( high&0x4000)==0x0 )
! underflow -= 1
! end
!
! Where the ``write_bit(bit)'' function outputs a single
bit.
! end
! end{informative*}
!
! subsection{Arithmetic decoding engine}
! label
!
! This section is a normative specification of the operation
of the arithmetic
! decoding engine.
!
!
!
! This section specifies the arithmetic decoding engine and
! processes for using it to extract data from coded
streams.
The arithmetic decoding engine consists of two elements:
***************
*** 14,22 ****
item a collection of state variables representing the
state of the arithmetic
decoder (Section ref)
! item a set of functions for extracting values from the
decoder
! and updating the decoder state (Section
ref)
end
! subsection{State and contexts}
label
--- 254,262 ----
item a collection of state variables representing the
state of the arithmetic
decoder (Section ref)
! item a function for extracting binary values from the
decoder
! and updating the decoder state (Section
ref)
end
! subsubsection{State and contexts}
label
***************
*** 31,35 ****
end
! A context $context$ is an integer array consisting of
three positive values:
begin
item $context[count0]$ is a count of the number of
zeroes
--- 271,509 ----
end
! A context $context$ is an integer array with a single
value which encapsulates
! the probability of zero in that context represented as a
16 bit number, such that
! [0<context[prob0]<text]
!
! Contexts are accessed by decoding functions via the
indices defined in Section ref.
!
! subsubsection
! label
!
! At the beginning of the decoding of any data unit, the
arithmetic
! decoding state is initialised as follows:
!
!
begin{block_data
_length}
! bsCODE{ABitsLeft=8*block_data_length}
! bsCODE{ALow = text}
! bsCODE{ARange =text}
! bsCODE{ACode =text}
! bsFOR{i=0}
! bsCODE{ACode <<= 1}
! bsCODE{ACode+= read_bitb()}
! bsEND
! bsCODE{init_contexts()}
! end
!
! Contexts are initialised by the $init_contexts()$
function as follows:
!
! begin{}
! bsFOR{i=0}{length(AContexts)-1}
! bsCODE{AContexts[i][prob0]=text}
! bsEND
! end
!
! subsubsection{Data input}
! label
!
! The arithmetic decoding process accesses data in a
contiguous block of bytes
! whose size is set on initialisation (Section
ref). The bits in this
! block are sufficient to allow for the
! decoding of all coefficients. However, the specification
of arithmetic
! decoding operations in this section may occasionally cause
further bits to be read,
! even though they are not required for determining decoded
values. For this
! reason the bounded-block read function $read_bitb()$
(Section ref) is
! used for data access.
!
! Since the length of arithmetically coded data elements is
given in bytes within the Dirac
! stream, there may be bits left unread when all values have
been extracted. These
! are flushed as desribed in Section ref.
Since arithmetically coded blocks
! are byte-aligned and a whole number of bytes, this aligns
data input with the beginning of the byte
! after the arithmetically coded data i.e. at the end of
the
! data chunk. $flush_inputb()$ is always called at the end
of decoding an arithmetically encoded
! data element.
!
! begin
! The Dirac arithmetic decoding engine uses 16 bit words,
and so if all coefficients are
! coded no more than 16 additional bits should be read
beyond the end of the block. Hence it
! would seem sufficient to read in the entire block of data
and pad the end with two bytes of value 0xFF,
! to avoid a branch condition on inputting data
! However, an arithmetically encoded block may end with a
string of 1s, which an encoder could
! conceivably strip out to save bits, in the knowledge that
$read_bitb()$ will re-insert them. Terminating
! strings of 1s can occur (but not exclusively) in coding
many zero wavelet subband coefficients at the end
! of a subband. So a larger number of pad bytes may be
required in practice.
! end
!
! subsubsection{Decoding boolean values}
! label
!
! The arithmetic decoding engine is a multi-context,
adaptive binary
! arithmetic decoder, performing binary renormalisation and
producing
! binary outputs. For each bit decoded, the semantics of the
relevant
! calling decoder function determine which contexts are
passed to the
! arithmetic decoding operations.
!
! This section specifies the operation of the
$read_boola()$ function
! for extracting a boolean value from the Dirac stream. The
overall decoding
! process for extracting a symbol is as defined by the
following
! pseudocode:
!
! begin
! bsCODE{context=AContexts[context_index]}
! bsCODE{count = ACode-ALow}
! bsCODE{range_times_prob = (ARange * context[prob0])gg
16}
! bsIF{ count >= range_times_prob }
! bsCODE{value = true}
! bsCODE{ALow += range_times_prob}
! bsCODE{ARange -= range_time_prob}
! bsELSE
! bsCODE{value = false}
! bsCODE{ARange = range_times_prob}
! bsEND
!
bsCODE{update_context(AContexts[context_index],value)}
! bsWHILE{ARange<=text}
! bsCODE{renormalise()}
! bsEND
! bsRET
! end
!
! begin
! The function scales the probability of the symbol $0$ from
the decoding context
! so that if this probability were $1$, then the interval
would equal that between
! $ALow$ and
! [high=ALow+ARange-1]
! and $count$ is set to the normalised cut-off between 0 and
1 within this range.
! end
!
! subsubsection
! label
!
! Renormalisation is applied to stop the arithmetic decoding
! engine from losing accuracy: the range must not get too
small,
! in order that 0 and 1 may be distinguished.
Renormalisation is
! applied while the range is less than or equal to a
quarter of
! the total available 16-bit range ($text$).
!
! For convenience let $low=ALow$ and $high=ALow+ARange-1$
! represent the upper and lower bounds of the interval. If
the
! range is $<=text$ then
! one of three possibilities must obtain:
! begin
! item the msbs of $low$ and $high$ are both 0
! item the msbs of $low$ and $high$ are both 1
! item $low=b01...$, $high=b10....$, and the interval
straddles the half-way point 0x8000.
! end
!
! Renormalisation doubles the interval and reads a bit into
the codeword
! as follows:
!
! begin{}
! bsIF{(ALow+ARange-1)^ALow>=text}
! bsCODE{ACode ^= text}
! bsCODE{ALow ^= text}
! bsEND
! bsCODE{ALow <<= 1}
! bsCODE{ARange <<= 1}
! bsCODE{ALow &= text}
! bsCODE{ACode <<= 1}
! bsCODE{ACode+= read_bitb()}
! bsCODE{ACode &= text}
! end
!
! The second bit is flipped if there is a straddle condition
(case 3). The renormalisation
! process has the effect that: in case 1, the interval
$[low,high]$ is doubled from 0 ($xmapsto 2*x$);
! in case 2 it is doubled from 1 ($xmapsto 2*x-1$); and in
case 3 it is doubled from 1/2 ($xmapsto 2x-0.5$).
!
! begin
! Note that if 16-bit words (unsigned shorts) are used for
decoder state variables $ALow$,
! and $ACode$ then there is no need for {&}-ing with
0xFFFF. However, the
! operations specified here are defined in terms of
integers, since intermediate calculations
! require higher dynamic range. In software, the efficiency
of using short word lengths may
! or may not be offset by the requirement to cast to other
data types for these calculations.
! end
!
! subsubsection{Updating contexts}
! label
!
! Contexts are updated according to a probability look-up
table:
!
! begin{ctx,value}
! bsIF{value==true}
! bsCODE{ctx[prob0] -= ALUT[ctx[prob0]>>8]}
! bsELSE
! bsCODE{ctx[prob0] +=
ALUT[255-(ctx[prob0]>>8)]}
! bsEND
! end
!
! The look-up table $ALUT$ supplies a value for
decrementing
! or incrementing the probability of zero based on the first
! 8 bits of its current value, according to Table
ref{table:lut}.
!
! begin[!ht]
! begin{|cccccccc|}
! hline
! multicolumn{|c|}{{bf ALUT[] (indexes 0 to 255)}} \
! hline
! 0,& 2,& 5,& 8,&
11,& 15,& 20,& 24,\
! 29,& 35,& 41,& 47,&
53,& 60,& 67,& 74,\
! 82,& 89,& 97,& 106,&
114,& 123,& 132,& 141,\
! 150,& 160,& 170,& 180,&
190,& 201,& 211,& 222,\
! 233,& 244,& 256,& 267,&
279,& 291,& 303,& 315,\
! 327,& 340,& 353,& 366,&
379,& 392,& 405,& 419,\
! 433,& 447,& 461,& 475,&
489,& 504,& 518,& 533,\
! 548,& 563,& 578,& 593,&
609,& 624,& 640,& 656,\
! 672,& 688,& 705,& 721,&
738,& 754,& 771,& 788,\
! 805,& 822,& 840,& 857,&
875,& 892,& 910,& 928,\
! 946,& 964,& 983,& 1001,&
1020,& 1038,& 1057,& 1076,\
! 1095,& 1114,& 1133,& 1153,&
1172,& 1192,& 1211,& 1231,\
! 1251,& 1271,& 1291,& 1311,&
1332,& 1352,& 1373,& 1393,\
! 1414,& 1435,& 1456,& 1477,&
1498,& 1520,& 1541,& 1562,\
! 1584,& 1606,& 1628,& 1649,&
1671,& 1694,& 1716,& 1738,\
! 1760,& 1783,& 1806,& 1828,&
1851,& 1874,& 1897,& 1920,\
! 1935,& 1942,& 1949,& 1955,&
1961,& 1968,& 1974,& 1980,\
! 1985,& 1991,& 1996,& 2001,&
2006,& 2011,& 2016,& 2021,\
! 2025,& 2029,& 2033,& 2037,&
2040,& 2044,& 2047,& 2050,\
! 2053,& 2056,& 2058,& 2061,&
2063,& 2065,& 2066,& 2068,\
! 2069,& 2070,& 2071,& 2072,&
2072,& 2072,& 2072,& 2072,\
! 2072,& 2071,& 2070,& 2069,&
2068,& 2066,& 2065,& 2063,\
! 2060,& 2058,& 2055,& 2052,&
2049,& 2045,& 2042,& 2038,\
! 2033,& 2029,& 2024,& 2019,&
2013,& 2008,& 2002,& 1996,\
! 1989,& 1982,& 1975,& 1968,&
1960,& 1952,& 1943,& 1934,\
! 1925,& 1916,& 1906,& 1896,&
1885,& 1874,& 1863,& 1851,\
! 1839,& 1827,& 1814,& 1800,&
1786,& 1772,& 1757,& 1742,\
! 1727,& 1710,& 1694,& 1676,&
1659,& 1640,& 1622,& 1602,\
! 1582,& 1561,& 1540,& 1518,&
1495,& 1471,& 1447,& 1422,\
! 1396,& 1369,& 1341,& 1312,&
1282,& 1251,& 1219,& 1186,\
! 1151,& 1114,& 1077,& 1037,&
995,& 952,& 906,& 857,\
! 805,& 750,& 690,& 625,&
553,& 471,& 376,& 255\
! hline
! end
! caption{Look-up table for context probability
adaptation}
! label{table:lut}
! end
!
! begin
! The look-up table approximates a count-based adaption
mechanism. In
! a count-based system, a context would maintain a weight
$w$ and a
! count of zeroes $n_0$, such that the probability of zero
would
! be
! [prob0=dfrac]
! If 0 is then coded, this probability becomes
$dfrac{n_0+1}{w+1}$,
! i.e. and if 1 is coded, $prob0=dfrac{w+1}$. In other
words,
! [prob0+=left(dfrac{w+1}right)]
! if a 0 is coded, and
! [prob0-=left(dfrac{w+1}right)]
!
! The LUT updates $prob0$ by implicitly defining $w$ as a
function of
! $prob0$. The values have been chosen so that if $prob0$ is
close
! to 0, $w=256$, and if $prob0$ is close to $0.5$, $w=32$.
This allows
! for fast initial adaptation and good representation of
highly biased
! probabilities.
! end
!
! begin
! subsection{Alternative arithmetic decoding engines}
!
! to
! 16 consisting of three positive values:
begin
item $context[count0]$ is a count of the number of
zeroes
***************
*** 276,396 ****
end
- end
-
- subsubsection{Arithmetic decoding of integer values}
- label
! This section defines the operation of the
$read_sinta(context_set)$ function
! for extracting integer values from a block of
arithmetically coded data.
!
! paragraph{Binarisation and contexts \}
!
! Signed and unsigned integer values are binarised using
interleaved exp-Golomb
! binarisation as per Section ref: the
$read_sinta()$ and $read_uinta()$
! processes are essentially identical to the
! $read_sint()$ and $read_uint()$ processes, except that
instances of $read_bool()$ are replaced
! by instances of $read_boola()$ (Section
ref) using suitable contextualisation.
!
! A choice of context depends upon whether the bit is a data
bit, follow bit, or sign bit, and upon the
! position of the bit within the binarisation:
$context_set$ consists of three parts -
! begin
! item an array of follow contexts, $context_set[follow]$
(indexed from 0 to
! $length(context_set[follow])-1$)
! item a single data context $context_set[data]$
! item a sign context $context_set[sign]$ (ignored for
unsigned integer decoding)
! end
!
! Each follow context is used for decoding the corresponding
follow bit, with the
! last follow context being used for all subsequent follow
bits (if any) also.
! The follow context selection function $follow_context()$
is defined by:
!
! begin{index, context_set}
! bsCODE{pos= max(index, length(context_set[follow])-1 }
! bsCODE{ctx_index = context_set[follow][pos]}
! bsRET{Contexts[ctx_index]}
! end
!
! So the last follow context is used for all the remaining
follow bits also.
!
! paragraph{Unsigned integer decoding \}
!
! Unsigned integers are decoded by:
!
! begin
! bsCODE{value = 1}
! bsCODE{index = 0}
! bsWHILE{read_boola(follow_context(index,context_set)
)== false}
! bsCODE{value ll = 1}
!
bsIF{read_boola(text{state[contexts]}[context_set[data])
])}
! bsCODE{value += 1}
! bsEND
! bsCODE{index += 1}
! bsEND
! bsCODE{value -= 1}
! bsRET
! end
!
! paragraph{Signed integer decoding \}
!
! $read_sinta()$ decodes first the magnitude then the sign,
as necessary:
!
! begin
! bsCODE{value=read_uinta(context_set)}
! bsIF{value != 0}
! bsIF{read_boola(Contexts[context_set[sign])]) ==
true}
! bsCODE{value=-value}
! bsEND
! bsEND
! bsRET
! end
!
! subsection{Context indices}
! label
!
! The following is a list of all the context indices used in
Dirac arithmetic decoding operations:
!
! Wavelet coefficient contexts:
!
! SignZero\
! SignPos\
! SignNeg\
! ZPZNFollowOne\
! ZPNNFollowOne\
! ZPFollowTwo\
! ZPFollowThree\
! ZPFollowFour\
! ZPFollowFive\
! ZPFollowSixPlus\
! NPZNFollowOne\
! NPNNFollowOne\
! NPFollowTwo\
! NPFollowThree\
! NPFollowFour\
! NPFollowFive\
! NPFollowSixPlus\
! CoeffData\
! ZeroCodeblock\
! QOffsetFollow\
! QOffsetData\
! QOffsetSign\
!
! Motion data contexts:
!
! SBSplitFollowOne\
! SBSplitFollowTwo\
! SBSplitData\
! PredModeOne\
! PredModeTwo\
! BlockGlobal\
! VectorFollowOne\
! VectorFollowTwo\
! VectorFollowThree\
! VectorFollowFour\
! VectorFollowFivePlus\
! VectorData\
! VectorSign\
! DCFollowOne\
! DCFollowTwoPlus\
! DCData\
! DCSign\
--- 750,754 ----
end
! end
No newline at end of file
Index: parsediagrams.tex
============================================================
=======
RCS file:
/cvsroot/dirac/compress/doc/latex_spec/parsediagrams.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** parsediagrams.tex 28 Sep 2006 09:08:55 -0000 1.2
--- parsediagrams.tex 11 Apr 2007 15:28:35 -0000 1.3
***************
*** 6,10 ****
setlength
! begin[!h]
centering
begin(20,12)
--- 6,10 ----
setlength
! begin[!ht]
centering
begin(20,12)
***************
*** 23,27 ****
setlength
! begin[!h]
centering
begin(45,12)
--- 23,27 ----
setlength
! begin[!ht]
centering
begin(45,12)
***************
*** 44,48 ****
setlength
! begin[!h]
centering
begin(45,8)
--- 44,48 ----
setlength
! begin[!ht]
centering
begin(45,8)
***************
*** 62,66 ****
% AU
setlength
! begin[!h]
centering
begin(50,8)
--- 62,66 ----
% AU
setlength
! begin[!ht]
centering
begin(50,8)
***************
*** 87,91 ****
% AU header
setlength
! begin[!h]
centering
begin(40,8)
--- 87,91 ----
% AU header
setlength
! begin[!ht]
centering
begin(40,8)
***************
*** 104,108 ****
%% AU parse params
setlength
! begin[!h]
centering
begin(45,5)
--- 104,108 ----
%% AU parse params
setlength
! begin[!ht]
centering
begin(45,5)
***************
*** 123,127 ****
% AU sequence params
setlength
! begin[!h]
centering
begin(45,8)
--- 123,127 ----
% AU sequence params
setlength
! begin[!ht]
centering
begin(45,8)
***************
*** 142,146 ****
% Setting image dimensions
setlength
! begin[!h]
centering
begin(35,12)
--- 142,146 ----
% Setting image dimensions
setlength
! begin[!ht]
centering
begin(35,12)
***************
*** 162,166 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 162,166 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 183,187 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 183,187 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 202,206 ****
setlength
! begin[!h]
centering
begin(40,14)
--- 202,206 ----
setlength
! begin[!ht]
centering
begin(40,14)
***************
*** 231,235 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 231,235 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 250,254 ****
setlength
! begin[!h]
centering
begin(48,15)
--- 250,254 ----
setlength
! begin[!ht]
centering
begin(48,15)
***************
*** 283,287 ****
% frame rate
setlength
! begin[!h]
centering
begin(48,15)
--- 283,287 ----
% frame rate
setlength
! begin[!ht]
centering
begin(48,15)
***************
*** 311,315 ****
% Aspect ratio
setlength
! begin[!h]
centering
begin(48,15)
--- 311,315 ----
% Aspect ratio
setlength
! begin[!ht]
centering
begin(48,15)
***************
*** 340,344 ****
setlength
! begin[!h]
centering
begin(48,15)
--- 340,344 ----
setlength
! begin[!ht]
centering
begin(48,15)
***************
*** 365,369 ****
setlength
! begin[!h]
centering
begin(48,26)
--- 365,369 ----
setlength
! begin[!ht]
centering
begin(48,26)
***************
*** 401,405 ****
% Colour specification
setlength
! begin[!h]
centering
begin(48,25)
--- 401,405 ----
% Colour specification
setlength
! begin[!ht]
centering
begin(48,25)
***************
*** 436,440 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 436,440 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 454,458 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 454,458 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 472,476 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 472,476 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 491,495 ****
setlength
! begin[!h]
centering
begin(40,12)
--- 491,495 ----
setlength
! begin[!ht]
centering
begin(40,12)
***************
*** 513,517 ****
% Picture header
setlength
! begin[!h]
centering
begin(40,12)
--- 513,517 ----
% Picture header
setlength
! begin[!ht]
centering
begin(40,12)
***************
*** 533,537 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 533,537 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 550,554 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 550,554 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 572,576 ****
% Picture prediction
setlength
! begin[!h]
centering
begin(30,8)
--- 572,576 ----
% Picture prediction
setlength
! begin[!ht]
centering
begin(30,8)
***************
*** 586,590 ****
% Picture prediction parameters
setlength
! begin[!h]
centering
begin(51,8)
--- 586,590 ----
% Picture prediction parameters
setlength
! begin[!ht]
centering
begin(51,8)
***************
*** 606,610 ****
% Block parameters
setlength
! begin[!h]
centering
begin(48,25)
--- 606,610 ----
% Block parameters
setlength
! begin[!ht]
centering
begin(48,25)
***************
*** 645,649 ****
%Motion vector precision
setlength
! begin[!h]
centering
begin(40,12)
--- 645,649 ----
%Motion vector precision
setlength
! begin[!ht]
centering
begin(40,12)
***************
*** 663,667 ****
% Global motion
setlength
! begin[!h]
centering
begin(35,12)
--- 663,667 ----
% Global motion
setlength
! begin[!ht]
centering
begin(35,12)
***************
*** 684,688 ****
% Global motion parameters
setlength
! begin[!h]
centering
begin(40,10)
--- 684,688 ----
% Global motion parameters
setlength
! begin[!ht]
centering
begin(40,10)
***************
*** 700,704 ****
% Pan/tilt
setlength
! begin[!h]
centering
begin(35,12)
--- 700,704 ----
% Pan/tilt
setlength
! begin[!ht]
centering
begin(35,12)
***************
*** 719,723 ****
% Zoom, rotation and shear matrix
setlength
! begin[!h]
centering
begin(48,20)
--- 719,723 ----
% Zoom, rotation and shear matrix
setlength
! begin[!ht]
centering
begin(48,20)
***************
*** 751,755 ****
% Perspective
setlength
! begin[!h]
centering
begin(45,15)
--- 751,755 ----
% Perspective
setlength
! begin[!ht]
centering
begin(45,15)
***************
*** 775,779 ****
% Picture prediction mode
setlength
! begin[!h]
centering
begin(33,12)
--- 775,779 ----
% Picture prediction mode
setlength
! begin[!ht]
centering
begin(33,12)
***************
*** 793,797 ****
% Reference picture weights
setlength
! begin[!h]
centering
begin(35,12)
--- 793,797 ----
% Reference picture weights
setlength
! begin[!ht]
centering
begin(35,12)
***************
*** 816,820 ****
% Wavelet transform
setlength
! begin[!h]
centering
begin(51,8)
--- 816,820 ----
% Wavelet transform
setlength
! begin[!ht]
centering
begin(51,8)
***************
*** 845,849 ****
% Transform parameters
setlength
! begin[!h]
centering
begin(40,10)
--- 845,849 ----
% Transform parameters
setlength
! begin[!ht]
centering
begin(40,10)
***************
*** 861,865 ****
% Wavelet filter
setlength
! begin[!h]
centering
begin(30,12)
--- 861,865 ----
% Wavelet filter
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 878,882 ****
% Wavelet depth
setlength
! begin[!h]
centering
begin(30,12)
--- 878,882 ----
% Wavelet depth
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 895,899 ****
% Spatial partition
setlength
! begin[!h]
centering
begin(43,18)
--- 895,899 ----
% Spatial partition
setlength
! begin[!ht]
centering
begin(43,18)
***************
*** 929,933 ****
setlength
! begin[!h]
centering
begin(31,15)
--- 929,933 ----
setlength
! begin[!ht]
centering
begin(31,15)
***************
*** 948,952 ****
setlength
! begin[!h]
centering
begin(33,15)
--- 948,952 ----
setlength
! begin[!ht]
centering
begin(33,15)
***************
*** 967,971 ****
setlength
! begin[!h]
centering
begin(30,15)
--- 967,971 ----
setlength
! begin[!ht]
centering
begin(30,15)
***************
*** 1001,1005 ****
setlength
! begin[!h]
centering
begin(30,12)
--- 1001,1005 ----
setlength
! begin[!ht]
centering
begin(30,12)
***************
*** 1020,1024 ****
setlength
! begin[!h]
centering
begin(36,8)
--- 1020,1024 ----
setlength
! begin[!ht]
centering
begin(36,8)
***************
*** 1036,1040 ****
setlength
! begin[!h]
centering
begin(48,10)
--- 1036,1040 ----
setlength
! begin[!ht]
centering
begin(48,10)
***************
*** 1072,1076 ****
setlength
! begin[!h]
centering
begin(20,12)
--- 1072,1076 ----
setlength
! begin[!ht]
centering
begin(20,12)
***************
*** 1089,1093 ****
setlength
! begin[!h]
centering
begin(40,10)
--- 1089,1093 ----
setlength
! begin[!ht]
centering
begin(40,10)
***************
*** 1117,1121 ****
setlength
! begin[!h]
centering
begin(40,12)
--- 1117,1121 ----
setlength
! begin[!ht]
centering
begin(40,12)
------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Dirac-commits mailing list
Dirac-commits lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dirac-com
mits
|