ITU-T T 89-2001 Application Profiles for Recommendation T 88 -Lossy Lossless Coding of Bi-Level Images (JBIG2) for Facsimile Series T Terminals for Telematic Services (Study Group .pdf

《ITU-T T 89-2001 Application Profiles for Recommendation T 88 -Lossy Lossless Coding of Bi-Level Images (JBIG2) for Facsimile Series T Terminals for Telematic Services (Study Group .pdf》由会员分享，可在线阅读，更多相关《ITU-T T 89-2001 Application Profiles for Recommendation T 88 -Lossy Lossless Coding of Bi-Level Images (JBIG2) for Facsimile Series T Terminals for Telematic Services (Study Group .pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU T.89 (09/200 I ) SERIES T: TERMINALS FOR TELEMATIC SERVICES Application profiles for Recommendation T.88 - Lossy/lossIess coding of bi-level images (JBIG2) for facsimile ITU-T Recommendation T.89 ITU-T Recomm

2、endation T.89 Application profiles for Recommendation T.88 - Lossyhossless coding of bi-level images (JBIG2) for facsimile Summary This Recommendation, “Application Profiles for Recommendation T.88“, specifies application profiles of the JBIG2 coding scheme, defined in ITU-T Rec. T.88 1 ISO/IEC 1449

3、2, for facsimile applications. The JBIG2 Recommendation specifies a collection of standard encodeddecoder components, referenced as a tool kit, that are used in generating and decoding JE3IG2 conformant data streams. JBIG2 has standardized seven profiles, and encourages definition of additional appl

4、ication profiles to satis further needs of various application environments. Source ITU-T Recommendation T.89 was revised by ITU-T Study Group 16 (2001-2004) and approved under the WTSA Resolution 1 procedure on 5 September 2001. 1 ITU-T Rec. T.89 (09/2001) FOREWORD The International Telecommunicati

5、on Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a vie

6、w to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendat

7、ions is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for concisen

8、ess to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no positio

9、n concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protecte

10、d by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. o ITU 2002 All rights reserved. No part of this publication may be reprodu

11、ced, by any means whatsoever, without the prior written permission of ITU. ii ITU-T Rec. T.89 (09/2001) CONTENTS Page 1 Scope 1 . 2 References 1 . 3 Principle 1 4 Facsimile profiles 2 4.1 JBIG2 FAX profiles 2 4.2 Function constraints 10 ITU-T Rec . T.89 (09/2001) . 111 ITU-T Recommendation T.89 Appl

12、ication profdes for Recommendation T.88 - Lossyhossless coding of bi-level images (JBIG2) for facsimile 1 Scope This Recommendation defines application profiles of ITU-T Rec. T.88 I ISO/IEC 14492 “Lossy/lossless coding of bi-level images (JBIG2)“ for facsimile applications. 2 References The followin

13、g ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommen

14、dation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. - - ITU-T Recommendation T.44 (1999), Mixed raster content (MRC). I

15、TU-T Recommendation T.4 (1999), Standardization of Group 3 facsimile terminals for document transmission. ITU-T Recommendation T.88 (2000) I ISO/IEC 14492:2001, Information technology - Lossy/lossless coding of bi-level images. (Commonly referred to as JBIG2 standard.) - 3 Principle This Recommendat

16、ion specifies application profiles of ITU-T Rec. T.88 I ISO/IEC 14492 for facsimile applications. JBIG2s tunable lossy/lossless compression of bi-level images is made possible by mixing and matching the various components and parameters within its tool-kit collection of components and parameters. Th

17、e BIG2 tool kit contains two basic categories of image and integer coding methods: 1) Arithmetic coding, as defined in Annex E/T.88, is used in the encoding of both image and integer data; 2) MMR coding, as defined in 6.2.6/T.88 and Huffman coding, as defined in Annex B/T.88, are used in the encodin

18、g of image and integer data respectively. These encodings are selectively applied, using a variety of parameter values, to segmented image regions containing image types such as text, dithered (half-tone) and generic bit-map data. This Recommendation defines a set of JBIG2 application profiles to be

19、 used in the decoding of a JBIG2 data stream. Given that the JBIG2 Recommendation (T.88) is a decoder-only standard, the profiles defined within this Recommendation do not address encoding. The profiles are categorized by image and integer coding methodology, image region types and memory constraini

20、ng parameters. To insure interoperability between various implementations, this Recommendation defines a base profile, which shall be implemented by all facsimile implementations that use JBIG2. The base profile is augmented by a set of standardized optional profiles. Collectively these profiles del

21、iver different levels of performance over a range of facsimile implementations. Error-free or error-corrected transmission, as defined in Annex AlT.4, and the shared data structure defined in ITU-T Rec. T.44 shall be used in JBIG2 facsimile implementations. Mode 4 or higher of ITU-T Rec. T.44 and An

22、nex wT.4 (“Black-and-white Mixed Raster Content Profile (MRCbw“) ITU-T Rec. T.89 (09/2001) 1 clause) shall be used when the “JBIG2 fax profiles“, specified within this Recommendation, are implemented in colour and in black-and-white-only applications respectively. 4 Facsimile profiles Multiple facsi

23、mile profiles are defined in 4.1 “JBIG2 fax profiles“. These profiles are intended to accommodate applications spanning a range of implementation resource requirement from stand-alone terminals to laptop and desktop computers. 4.1 JBIGZ FAX profiles Table 1 defines one mandatory profile - Profile 1

24、: BASE - and four optional profiles - Profiles 2: Upper Huffrilan, Profile 3: Lower arithmetic, Profile 4: Medium lossy/lossless arithmetic and Profile 5: Medium lossy/lossless arithmeticLHuffinan. The JBIG2 fax profiles table also contains the outline for an additional optional profile, which is pr

25、ovided for information as it is still under study and has not been approved for implementation. Profiles 1 through 5 have been reserved by the ITU and communicated to ISO/IEC JTC1 SC29, which has reserved profile identification numbers Ox00000 1 O0 through Ox00000FFF for ITU-T disposition. Profile i

26、dentification numbers 0x00000101 through 0x00000105 are assigned to Profiles 1 through 5 above respectively. The relative complexity and working memory requirements of a profile generally increases as the value of its profile number increase for a particular base coder (Le. arithmetic or Huffinan).

27、Accordingly, a reader supporting a profile with a higher value profile number shall be capable of also supporting a profile with a lower value profile number if it utilizes the same base coder. The BASE profile (Profile 1 or 0x00000101) is designed to accommodate minimal implementation resources in

28、a stand-alone application environment. It is effectively the minimum subset of the lowest level JBIG2 profile, Profile 0x00000007 (see Table F.7/T.88). Consistent with the most prevalent facsimile implementations of today, the BASE profile use MMR coding in the coding of bitmap data and Huffinan cod

29、ing scheme in the coding of numeric (integer) data. The main advantage of the profile is the greatly increased compression available through the use of lossy JBIG2 coding. The optional Upper Huffman profile (Profile 2 or 0x00000102), using MMR and Huffman coders for bitmap and numeric respectively,

30、is based on the less constrained JBIG2 Huffinan-based profile, Profile 0x00000005 (see Table F.5E.88). Profile 2 is defined to provide enhanced performance, including specific half-tone region coding via pattern matching and provisions that accommodate use of “color tags“ as defined in ITU-T Rec. T.

31、44, to the stand-alone facsimile application environment. Use of Profiles 1 and 2 may be suitable for other low complexity and low-speed processor applications, such as high-speed printing. Definition of Profile 3 (Ox00000 103) “Lower arithmetic“ recognizes the growing trend towards adoption of arit

32、hmetic-based coders in facsimile applications and uses arithmetic for both bitmap and numeric coding. Profile 3 is intended to provide a minimal subset of the most highly constrained JBIG2 arithmetic profile, Profile 0x00000006 (see Table F.6T.88). The Medium 1ossyAossless arithmetic profile (Profil

33、e 4 or 0x00000104) is defined to provide lossless enhancement to Profile 3. Profile 4 is a subset of the less constrained JBIG2 arithmetic profile, Profile 0x00000003 (see Table F.3E.88). The Medium lossy/lossless arithmetic/Hufhan profile (Profile 5 or 0x000001 05) is defined to accommodate the fle

34、xibility of using arithmetic, Huffman and MMR base coders as appropriate, along with provisions for both lossy and lossless JBIG2 coding modes. Selectively, arithmetic or MMR may be used for bitmap, arithmetic or Huffman for numeric, and arithmetic for refinement region coding. Additionally, there i

35、s provision for specific half-tone region coding via pattern matching. The provisions that accommodate use of “colour tags, which are associated with Profiles 2 and 4, are retained in Profile 5. Profile 5 is a combined subset of the two less constrained and refinement enabled JBIG2 arithmetic and Hu

36、ffman-based profiles, Profiles 0x00000003 and 0x00000004 (see Tables F.3jT.88 and F.4E88). Profiles 1 through 3 uses the Ilossy JBIG2 coding mode while Profiles 4 and 5 accommodate both “lossy“ and “lossless“ modes. Use of Profiles 3 through 5 may be suitable for medium complexity and medium-speed p

37、rocessor applications such 2 ITU-T Rec. T.89 (09/2001) as high-end facsimile or other applications, such as multi-function and web-based applications. All profiles can also support “lossless“ coding for generated data or if symbol coding is not used (as in Clause 4.2 provides background on the memor

38、y-related function constraints. NOTE - For conciseness, ITU-T Rec. T.88 terminology such as “Generic region decoding procedure“ has been replaced in T.89 by “direct bitmap coding“, and “Generic refinement region decoding procedure“ has been replaced by “refinement bitmap coding“. JBIG- 1). ITU-T Rec

39、. T.89 (09/2001) 3 N 3 3 3 rn .8 a 2 3 i z - i z m r( m 3 m m 4 2 m .3 3 -8 Q Z 3 m N m rn N 3 N o d B a e c a 8 O c N N 3 3 3 O N o 3 m z a z a 3 d 2 I 3 N N s - N d 2 s N 3 - N 3 - N 8 Y 3 N N m N 3 3 3 8 O 3 8 O O O O Cu Cu Cu Cu u r4 rd 3 3 3 3 3 3 4 2 rd 3 3 3 3 9 d 4 3 3 3 3 3 d 3 3 3 e rd 4 3

40、 i z 3 3 3 3 O s s m Cu 00 Cu O m Cu m 3 m N 9 9 o 8 6 X o 8 x d O ri ri 3 3 i z 3 3 G u 3 .k u 4 o id e 2 5 e B a FI E B Il a B I 00 3 II drn m m d m All JBIG2 T.89 implementations shall include support for this profile. Table 1 is read by selecting one of the profiles and traversing down the assoc

41、iated column to the various value entries. The values are interpreted by looking to the left along the associated row to determine the function name, listed in the function column. If the function name contains a (Note 3) designation then it is a function constraint, (see 4.2 for background descript

42、ions), of the function in the row directly above. The values of function constraints are self-explanatory and require no further interpretation. Further interpretation of function values is obtained by looking to the right, along the associated row, to identi the value interpretation that is listed

43、in the value column corresponding to the value number. 4.2 Function constraints The objective in introducing memory or other function constraints for these profiles is to prevent a BIG2 T.89 encoder from overrunning a decoder. Overrun may occur just by sending many dictionaries in succession; this i

44、s clearly not appropriate for fax. It is desirable for the encoder to know not to make dictionaries too large, because this can result in decoder failures. For these reasons, it is necessary to have some targets for implementers to aim for. These proposed FAX profiles establish constraints so that t

45、here are a few fixed points (e.g. the decoder has 2 M of memory besides its page buffer) that implementers know are out there and can target their encoders at. Function constraints 1) Direct bitmap arithmetic coding - Template size This specifies how large a template is used when doing arithmetic co

46、ding of pixels. Basically, an encoder looks at the surrounding N pixels (where N = 10, 13, or 16) and from that it can learn statistics of whether the current pixel, given the value of those N pixels, is going to be a O or a 1, and use those statistics to gain compression. If its highly likely to be

47、 a O, then the encoder can transmit the information Itit was a O“ in very little space (a small fraction of a bit). Memory requirement is 2“N bytes (i.e. 1 K-64 K). Larger templates (larger N) are also more expensive to implement in hardware: more on- chip buffers required, more memory operations to

48、 schedule, etc. Direct bitmap arithmetic coding - ATpljcel location limit Of the surrounding N pixels, an encoder is allowed to specie the location of 1 or 4 of them (1 if N = 10 or 13, 4 if N = 16). However, if it is stated that “the template pixel is 55 rows above the current pixel“, the encoder m

49、ust then be able to buffer at least the previous 55 rows; in a hardware implementation, that buffer might have to be on-chip. JBIG2 allows the pixel to be up to 127 rows above the current row; it might be desirable to restrict that to a smaller number to reduce the number of rows required to buffer. Refinement bitmap arithmetic coding - Template size When a lossy to lossless refinement is performed, the encoder is essentially transmitting the lossless version of each pixel (in some box), given all the information it knows so far. This information may include the lossy versio