ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf

上传人:medalangle361 文档编号:803935 上传时间:2019-02-04 格式:PDF 页数:22 大小:222.54KB
下载 相关 举报
ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf_第1页
第1页 / 共22页
ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf_第2页
第2页 / 共22页
ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf_第3页
第3页 / 共22页
ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf_第4页
第4页 / 共22页
ITU-T T 808 AMD 5-2013 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP (.pdf_第5页
第5页 / 共22页
点击查看更多>>
资源描述

1、 International Telecommunication Union ITU-T T.808TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 5(03/2013) SERIES T: TERMINALS FOR TELEMATIC SERVICES Still-image compression JPEG 2000 Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols Amendment

2、5: UDP transport and additional enhancements to JPIP Recommendation ITU-T T.808 (2005) Amendment 5 ITU-T T-SERIES RECOMMENDATIONS TERMINALS FOR TELEMATIC SERVICES Facsimile Framework T.0T.19 Still-image compression Test charts T.20T.29 Facsimile Group 3 protocols T.30T.39 Colour representation T.40T

3、.49 Character coding T.50T.59 Facsimile Group 4 protocols T.60T.69 Telematic services Framework T.70T.79 Still-image compression JPEG-1, Bi-level and JBIG T.80T.89 Telematic services ISDN Terminals and protocols T.90T.99 Videotext Framework T.100T.109 Data protocols for multimedia conferencing T.120

4、T.149 Telewriting T.150T.159 Multimedia and hypermedia framework T.170T.189 Cooperative document handling T.190T.199 Telematic services Interworking T.300T.399 Open document architecture T.400T.429 Document transfer and manipulation T.430T.449 Document application profile T.500T.509 Communication ap

5、plication profile T.510T.559 Telematic services Equipment characteristics T.560T.649 Still-image compression JPEG 2000 T.800T.829Still-image compression | JPEG XR T.830T.849 Still-image compression JPEG-1 extensions T.850T.899 For further details, please refer to the list of ITU-T Recommendations. R

6、ec. ITU-T T.808 (2005)/Amd.5 (03/2013) i INTERNATIONAL STANDARD ISO/IEC 15444-9 RECOMMENDATION ITU-T T.808 Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP Summary Amendment 5 to ITU-T T.808 |

7、ISO/IEC 15444-9 contains a minor enhancement that provides tools and definitions to enable the user datagram protocol (UDP) as transport layer for the JPEG 2000 Interactive Protocol (JPIP). A UDP packaging of messages into chunks is described, and mechanisms for flow control and to detect and recove

8、r from package loss are introduced. UDP transport is defined in the new Annex K. Amendment 5 also includes a minor clarification in the definition of the Placeholder box. Since Amendment 3 of ITU-T T.801 | ISO/IEC 15444-2 adds the possibility to rotate compositing layers by multiples of 90 degrees a

9、nd/or to flip them horizontally and vertically, the definition of the view window and context range of ITU-T T.808 | ISO/IEC 15444-9 had to be extended to respect this additional feature. A further addition allows a JPIP client to identify the request fields that a server is prepared to handle. This

10、 new request addresses the need of a client to identify the capabilities of the server beforehand, and thus to adapt and optimize its strategy to retrieve data from the server. History Edition Recommendation Approval Study Group 1.0 ITU-T T.808 2005-01-08 16 1.1 ITU-T T.808 (2005) Amd. 1 2006-05-29

11、16 1.2 ITU-T T.808 (2005) Cor. 1 2007-01-13 16 1.3 ITU-T T.808 (2005) Amd. 2 2007-08-29 16 1.4 ITU-T T.808 (2005) Cor. 2 2008-06-13 16 1.5 ITU-T T.808 (2005) Amd. 3 2008-06-13 16 1.6 ITU-T T.808 (2005) Amd. 4 2010-05-22 16 1.7 ITU-T T.808 (2005) Cor. 3 2011-05-14 16 1.8 ITU-T T.808 (2005) Amd. 5 201

12、3-03-16 16 ii Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a

13、 permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, es

14、tablishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations 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

15、standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the

16、 Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equival

17、ents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a clai

18、med Intellectual Property Right. ITU takes no position 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 n

19、ot received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/I

20、TU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) iii CONTENTS Page 1) Clause 6.1 . 1 2) Clause A.3.6.4 1 3) Clause B.1 1 4) Clause C.1.2 . 2 5) Clause

21、C.3.3 . 2 6) Equation C-3 2 7) Clause C.4.7 . 4 8) New clause C.7.5 Sendto 5 9) New clause C.7.6 Abandon 5 10) New clause C.7.7 Barrier 6 11) New clause C.7.8 Timed wait . 6 12) New clause C.10.4 Handled . 7 13) Clause D.1.2 . 7 14) Clause D.2.3 . 7 15) Clause D.2.9 . 7 16) New clause D.2.26 Handled

22、 request (handled) 7 17) Clause G.1 8 18) Clause H.1 8 19) Clause H.2 8 20) New Annex K . 9 Annex K Using JPIP with HTTP requests and UDP returns 9 K.1 Introduction . 9 K.2 Client requests . 9 K.3 Response data delivery and channel establishment . 9 K.4 Server responses 10 K.5 Framing of response da

23、ta into chunks . 10 K.6 Client acknowledgement of server responses 11 K.7 UDP and Maximum Response Length Field (informative) . 12 K.8 Implementation strategies for acknowledged communication (informative) 12 K.9 Implementation strategies for unacknowledged communication (informative) 13 ISO/IEC 154

24、44-9:2005/Amd.5:2014 (E) Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) 1 INTERNATIONAL STANDARD RECOMMENDATION ITU-T Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols Amendment 5 UDP transport and additional enhancements to JPIP 1) Clause 6.1 Replace the third p

25、aragraph in this clause (between Figure 3 and Figure 4) with the following text: This protocol can be used over several different transports as shown in Figure 4. This Recommendation | International Standard includes informative annexes on the use of the JPIP protocol over HTTP, TCP and UDP, and pro

26、vides suggestions for other example implementations. The JPIP protocol itself is neutral with respect to underlying transport mechanisms for the client requests and server responses, except in regard to channel requests represented by the New Channel (“cnew“) request field (see C.3.3) and the New Ch

27、annel (“JPIP-cnew“) response header (see D.2.3), where transport-specific details shall be communicated. This Recommendation | International Standard defines four specific transports, which are identified by the strings “http“, “https“, “http-tcp“ and “http-udp“ in the value string associated with N

28、ew Channel requests. 2) Clause A.3.6.4 Replace clause A.3.6.4 with the following new clause A.3.6.4: Wherever header, precinct or tile data bins exist, their codestream ID shall appear in a Placeholder box within an appropriate metadata bin. The only exception to this requirement is for unwrapped JP

29、EG 2000 codestreams, which are not embedded within a JPEG 2000 family file format. The codestream ID values that appear within the relevant Placeholder box shall conform to any requirements imposed by the containing file format. For example, JPX files formally assign a sequence number to codestreams

30、 that are found in Contiguous Codestream boxes or Fragment Table boxes, either at the top level of the file, or within Multiple Codestream boxes. The first codestream in the logical target shall have a codestream ID of 0; the next shall have a codestream ID of 1; and so forth. Placeholders that refe

31、rence multiple codestream IDs may be used only where the meaning of those codestreams is well defined by the type of the box that is being replaced. For JPX files, Contiguous Codestream boxes, Fragment Table boxes and Multiple Codestream boxes may be replaced by Placeholder Boxes that specify codest

32、ream IDs. Placeholders replacing Contiguous Codestream boxes and Fragment Table boxes may specify only a single codestream ID, while a placeholder replacing a Multiple Codestream box may specify multiple codestream IDs, corresponding to the number of codestreams that are found within the box. 3) Cla

33、use B.1 Replace the second paragraph of B.1 with the following: The purpose of sessions is to reduce the amount of explicit communication required between the client and server. Within a session, the server is expected to remember client capabilities and preferences supplied in previous requests so

34、that this information need not be sent in every request. Even more importantly, the server may keep a log of data it knows the client to have received so that this information need not be re-transmitted in response to future requests. This log is subsequently referred to as the cache model. The cach

35、e model would typically be persistent for the duration of a session. Unless explicitly instructed otherwise, the server may assume that the client caches all data it receives within a session, and may model the clients cache, sending only those portions of the compressed image data or metadata which

36、 the client does not already have in its cache. ISO/IEC 15444-9:2005/Amd.5:2014 (E) 2 Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) 4) Clause C.1.2 Replace the server-control-field and client-cap-pref-field lists with the following: server-control-field = align ; C.7.1 / wait ; C.7.2 / type ; C.7.3 / drat

37、e ; C.7.4 / sendto ; C.7.5 / abandon ; C.7.6 / barrier ; C.7.7 / twait ; C.7.8 client-cap-pref-field = cap ; C.10.1 / pref ; C.10.2 / csf ; C.10.3 / handled ; C.10.4 5) Clause C.3.3 Replace the second and third paragraphs with the following text: The value string identifies the names of one or more

38、transport protocols that the client is willing to accept. This Recommendation | International Standard defines only the transport names, “http“, “https“, “http-tcp“, and “http-udp“. Details of the use of JPIP over the “http“ transport appear in Annex F. Annex G describes the use of JPIP over the “ht

39、tp-tcp“ transport and Annex K describes the use of JPIP over the “http-udp“ transport. If the server is willing to open a new channel, using one of the indicated transport protocols, it shall return the new channel identifier token using the New Channel response header (see D.2.3). In this case, the

40、 present request is the first request within the new channel. 6) Equation C-3 Modify equation C-3 with the following augmented version of the equation and subsequent explanatory text, to take account of the new rotation support in ISO/IEC 15444-2:2004/Amd.3. While making these editorial changes, not

41、e that many of the symbols from the original equation are similar. First, define the rotated frame size, offset, width and height of the composite image as follows: ISO/IEC 15444-9:2005/Amd.5:2014 (E) Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) 3 ()()() )=Flip|270= RifWt,Ht,XO,YO,W,H,ox,oy,fx,fyFlip|180

42、= RifHt,Wt,YO,XO,H,W,oy,ox,fy,fxFlip|90= RifWt,Ht,XO,YO,W,H,ox,oy,fx,fyFlip|0= RifHt,Wt,YO,XO,H,W,oy,ox,fy,fxNoFlip|270= RifWt,Ht,XO,YO,W,H,ox,oy,fx,fyNoFlip|180= RifHt,Wt,YO,XO,H,W,oy,ox,fy,fxNoFlip|90= RifWt,Ht,XO,YO,W,H,ox,oy,fx,fyNoFlip|0= RifHt,Wt,YO,XO,H,W,oy,ox,fy,fxHt,Wt,YO,XO,H,W,oy,ox,fy,f

43、xHtYOH,WtXOW,sy-oy-fy,sx-ox-fxYO,XO,oy,oxinstinstinstinstinstcompcompFFinstinstinstinstinstcompcompFinstinstinstinstinstcompcompinstinstinstinstinstcompcompFinstinstinstinstinstcompcompFinstinstinstinstinstcompcompFFinstinstinstinstinstcompcompFinstinstinstinstinstcompcompinstinstinstinstcompcompins

44、tinstcompinstinstcompinstinstFFFFFFFFFFFF(C-3a) In the above, Wcompand Hcompare the width and height of the composited image, specified in the composition box; Wtinstand Htinstare the composited width and height as determined by the compositing instruction; XOinstand YOinstare the horizontal and ver

45、tical compositing offsets as determined by the compositing instruction; Wsinstand Hsinstare the width and height of the potentially cropped compositing layer as determined by the compositing instruction; XCinstand YCinstare the horizontal and vertical compositing layer cropping offsets as determined

46、 by the compositing instruction; and Rinstis derived from the ROT field of the compositing instruction, if any. If the compositing instruction contains no ROT field or the ROT field is 0, Rinst=0o|NoFlip. Otherwise, the rotation angle for Rinst(expressed in degrees clockwise) is obtained from the le

47、ast significant 3 bits of the ROT field using Table M-47 of Rec. ITU-T T.801 | ISO/IEC 15444-2, while the Flip|NoFlip status for Rinstis set to Flip if bit 4 of the ROT field is non-zero and NoFlip otherwise. Then, define the modified frame size fx, fy as follows: =compcodinstinstregregcompcodinstin

48、stregregHHHsHtYSYRfyfy“;WWWsWtXSXRfxfx“ (C-3b) To compute the modified region, first define the clipped region edges: () ()+=+=compinstinstlimcompinstinstlimcompinstmincompinstminHfyHtYO;WfxWtXOHfyYO;WfxXOyxyx(C-3c) ISO/IEC 15444-9:2005/Amd.5:2014 (E) 4 Rec. ITU-T T.808 (2005)/Amd.5 (03/2013) The modified region size sx and sy and region offsets ox and oy are then given as: ( ) ()=+=+

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1