ITU - Telecommunication Standardization Sector
Temporary Document 11 (WP 1/16)
STUDY GROUP 16
Geneva, 13-17 November 2000
Question(s): X/16
SOURCE*:
Editor T.89
TITLE:
Proposed revision of the T.89 draft, documented in COM 8-115.
________
Introduction
This contribution contains a proposed revision to the version of draft T.89 that is
documented in COM 8-115. The edits include correction for an omission in the “Symbol
coding - memory limit” definition, specified as item 7 in Section 4.2 of the draft. The JBIG2
editor, Dr. W. Rucklidge, brought this edit to our attention. There is also editorial clean up
of rows 27 and 28 of the JBIG2 Fax Profiles table, specified in Section 4.1. These edits do
not change the intent of the COM 8-115 draft from that communicated in the ISO/IEC JTC
1/SC 29/WG 1 liaison, document as N 1787.
Edits
1. Section 4.2, “7. Symbol coding - memory limit”
The JBIG2 editor, Dr. W. Rucklidge, has indicated that a “fixed component” has been omitted from
the symbol dictionary memory (MSD) algorithm. The MSD algorithm is used in determination of
the total amount of decoder memory required to hold decoded symbol dictionaries. The value of the
current MSD algorithm is dependent on the number of dictionary symbols. The MSD algorithm,
however, should be composed of two components, a “fixed component” that does not depend on the
number of symbols, and the current “per-symbol component” that does depend on the number of
symbols.
The changes required, to “7. Symbol coding - memory limit” of Section 4.1, to accommodate
addition of the omitted fixed component from the MSD algorithm are reflected with revision marks
in the attached page.
2. Section 4.1, rows 27 “Striping (page)” and 28 “Stripe size” of the “JBIG2 Fax Profiles” table
a) Column 1 of the “Function Values” columns of row 27 contain a default strip size, “default =
1K lines”, which is in conflict with that specified in column 1 of row 28, “no default”.
The row 27 specification, “default = 1K lines”, is the correct default value. This is the value
specified by the ISO SC29/WG1 JBIG committee in the N1787 liaison. The row 28 discrepancy,
“no default”, reflects an oversight in failing to update row 28 when row 27 was edited.
Required action:
* Contact:
Lloyd McIntyre, Xerox Corp.
UIT-T\SG_DOC\SG16\WP1-16\1-011.DOC
Tel:
+1 650 813 6762
Fax:
+1 650 845 2340
E-mail: lmcintyre@pahv.xerox.com
2
Change row 28, column 1 “no default” to “default = 1K lines”.
b) Specification of the maximum strip size was omitted from column 1. The omitted maximum
should be designated as “full page max”, consistent with that in columns 2 and 3.
Required action:
Add “full page max” to column 1 of row 28.
c) Strip size specification is duplicated in columns 1, 2 and 3 of rows 27 and 28. Additionally, the
minimum strip-count requirement “minimum of 2 stripes” is duplicated in column 1 of rows 27
and 28. By definition, stripe size specification should only be present in row 27 while other
stripe specifications should be present in row 28.
Required action:
Column 1: Delete “default = 1K lines” from row 27 while retaining “default = 1K lines” and
“full page max” in row 28. Additionally, delete “minimum of two stripes” from row 28.
Column 2: Delete the “default = 1K lines” and “full page max” strip size specifications from
rows 27 and 28 since they are a duplication of the specification in column 1 of row 28.
Column 3: Move the stripe size specification from row 27 to column 2 of row 28 and delete the
contents of column 3.
d) Consistent with the above changes and for additional clarification, update the numeric values
under the Profiles columns as follows:
Profile 0x00000101 – row 27, change “1” to “1a & b”
Profile 0x00000102 – row 28, change “2” to “1”
Profile 0x00000103 – row 27, change “1” to “1a & b”
Profiles X, X+1 and X+2 – rows 27 and 28, change “3” to “2”
All of the edits from above are reflected with revision marks in the attached page.
UIT-T\SG_DOC\SG16\WP1-16\1-011.DOC
3
JBIG2 FAX PROFILES
FUNCTIONS
NUMBE
R
PROFILES
(related to the profiles recommended in ITU-T T.88 | ISO/IEC 14492 Annex F)
0x00000101 0x00000102 0x00000103
BASE8
(F.7 minimal
subset)
27
FUNCTION VALUES
6
Striping (page)
1a & b
Upper
MMR
(F.5)
1a
Lower
Arithmetic
(F.6 minimal
subset)
1a & b
X
X+1
X+2
Future
Study
Future
Study
Future
Study
1
2
Medium
Upper
FULL
Arithmetic Arithmetic Arithmetic
(F.3 w/o
(F.3)
and MMR
refinement)
(F.1 subset)
2
2
2
Required,
Required
a) minimum of 2
stripes
b) stripes
containing text
region segments
shall not contain
other region
segments such as
halftone or generic
28
3
Stripe size
UIT-T\SG_DOC\SG16\WP1-16\1-011.DOC
1
1
1
2
2
2
default = 1K lines,
full page max
default =
page, full
page max
3
-4-
7.
Symbol coding - memory limit
This limits the total amount of decoded symbol dictionary information a decoder will accommodate
in memory at one time to decode a file. This limit includes two components, a fixed and per-symbol
component. The fixed component does not depend on the number of symbols, while the per-symbol
component does depend on the number of symbols. The fixed component includes template size
dependent variables and a constant. The per-symbol component includes the space required to
accommodate the uncompressed symbol bitmaps and the overhead, such as stored width and height
information and symbol ID Huffman table memory. Note that the total symbol dictionary memory
"MSD" is the sum of the fixed component and all the outstanding decoded symbol dictionaries (i.e.
those for which their “scope” has not elapsed or the “forget” command has not been issued).
The MSD does have dependency on whether Huffman (see note 1) or Arithmetic (see note 2)
coding is used and whether the dictionaries contain symbols or halftone patterns (see note 3).
The decoder symbol dictionary memory requirement shall be determined as follows:
MSD = fixed component + per-symbol component
fixed component = 2^{direct coding template size}
+ 2^{refinement coding template size} + 8K
per-symbol component = SUM (32 + R(W(i)) * Hi) / 8) over i,
i= 1 to N
where:
symbol dictionary memory (in bytes) = MSD
index (ith symbol in dictionary) = i
number of symbols in dictionary = N
symbol width = (W(i))
symbol height = (H(i))
symbol overhead = 32 bytes per symbol
The overhead items here are things such as: width of symbol,
height of symbol, symbol ID Huffman code, length of symbol ID
Huffman code, and pointer to memory where symbol bitmap
resides.
rounded width = R(W(i))
W(i) rounded up to the next multiple of 32 bits (e.g., 33 rounds
to 64, 128 rounds to 128)
This means that for each symbol there are 32 bytes overhead, plus H(i) rows of bitmap data, each of
which is R(W(i))/8 bytes.
Note:
1)
For Huffman coding there are no templates, so the fixed component is about 8K bytes. The
fixed component can in fact be zero if custom Huffman tables are not used.
UIT-T\SG_DOC\SG16\WP1-16\1-011.DOC
13.02.16
-5-
2)
For Arithmetic coding the per-symbol component is the same. The amount of memory needed
to store the decoded dictionary bitmaps (that's the (R(W(I)) * Hi) / 8 component) is unchanged.
Differences occur in the 32 bytes per-symbol overhead component. The width, height and
pointer fractions of the overhead still apply, however the Huffman code parts do not apply.
There are, however, context tables for symbol ID probability modeling that take the place of
the Huffman code parts. Bottom line, 32 bytes is also a reasonable per-symbol overhead for
Arithmetic coding. The template options, documented in the JBIG2 Fax Profiles table of
Section 4.1, range from a 10 pixels direct bitmap template with no refinement bitmap coding to
a 16 pixels direct bitmap template with 13 pixels refinement bitmap template. Given this range
of templates, the fixed component will range from 9K to 80K bytes.
3) The same expression holds for pattern dictionaries of halftone image regions since pattern
dictionaries are similar to symbol dictionaries but contain halftone patterns. The pattern
dictionaries, however, tend to be small relative to symbol dictionaries since the pattern count is
frequently low. This is only a few K of memory. It is the space required by a decoder to hold
the halftone bit-planes that is of significance and determines the memory limit. This memory
requirement is, document in the JBIG2 Fax Profiles table of Section 4.1, typically 110% of the
resolution dependent page buffer size (i.e. 1.0 Mbytes at 300 dpi and 2.0 Mbytes at 400 dpi).
_________________
UIT-T\SG_DOC\SG16\WP1-16\1-011.DOC
13.02.16