ITU-T T 808 CORR 2-2008 Information technology C JPEG 2000 image coding system Interactivity tools APIs and protocols Technical Corrigendum 2 Clarifications to the metadata transfe.pdf

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

2、l Corrigendum 2: Clarifications to the metadata transfers between server and client Recommendation ITU-T T.808 (2005) Technical Corrigendum 2 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 pro

3、tocols T.30T.39 Colour representation T.40T.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

4、protocols for multimedia conferencing T.120T.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.429Document transfer and manipulation T.430T.449 Document appli

5、cation profile T.500T.509 Communication application profile T.510T.559 Telematic services Equipment characteristics T.560T.649 Still-image compression JPEG 2000 T.800T.849 Still-image compression JPEG-1 extensions T.850T.899 For further details, please refer to the list of ITU-T Recommendations. Rec

6、. ITU-T T.808 (2005)/Cor.2 (06/2008) i INTERNATIONAL STANDARD ISO/IEC 15444-9 RECOMMENDATION ITU-T T.808 Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols Technical Corrigendum 2 Clarifications to the metadata transfers between server and client Summary Co

7、rrigendum 2 to Recommendation ITU-T T.808 | ISO/IEC 15444-9 provides clarifications to the metadata transfers between server and client. Source Corrigendum 2 to Recommendation ITU-T T.808 (2005) was approved on 13 June 2008 by ITU-T Study Group 16 (2005-2008) under Recommendation ITU-T A.8 procedure

8、. An identical text is also published as Technical Corrigendum 2 to ISO/IEC 15444-9. ii Rec. ITU-T T.808 (2005)/Cor.2 (06/2008) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technolo

9、gies (ICTs). 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 view to standardizing telecommunications on a worldwide basis. The World Telecommu

10、nication 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 Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas

11、of information technology which fall within ITU-Ts purview, the necessary 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 operat

12、ing agency. Compliance with this Recommendation is voluntary. However, the 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“ o

13、r some other obligatory language such as “must“ and the negative equivalents 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 practic

14、e or implementation of this Recommendation may involve the use of a claimed 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 developme

15、nt process. As of the date of approval of this Recommendation, ITU had not 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

16、strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2008 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ISO/IEC 15444-9:2005/Cor.2:2008 (E) Rec. ITU-T T.808 (2005)/Cor.2 (06/

17、2008) 1 INTERNATIONAL STANDARD RECOMMENDATION ITU-T Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols Technical Corrigendum 2 Clarifications to the metadata transfers between server and client 1) Subclause C.5.2 Replace the entire body of C.5.2 by the foll

18、owing text: C.5.2 Metadata Request (metareq) C.5.2.1 Description metareq = “metareq“ “=“ 1#(“ 1$(req-box-prop) “ root-bin max-depth) metadata-only req-box-prop = box-type limit metareq-qualifier priority limit = “:“ (UINT / “r“) metareq-qualifier = “/“ 1*(“w“ / “s“ / “g“ / “a“) priority = “!“ root-b

19、in = “R“ UINT max-depth = “D“ UINT metadata-only = “!“ This field specifies what metadata is desired in response to a request, in addition to any metadata required for the client to decode or interpret the requested image data as defined by C.5.1. The purpose of this request is to allow the client t

20、o request selected parts of the contents and the layout of the metadata encoded in the JP2 and JPX file formats a server did not choose to transmit according to C.5.1. The value string in this request field is a list of independent requests; however, the server may handle the requests as a group, an

21、d there may be overlap between the requests. It is then sufficient (but not necessary) that the server sends the requested data only once. The way how the server decides to break up the initial stream into bins is irrelevant for defining the target of the request except that the root-bin field can b

22、e used to limit a request to parts of the file structure, once a client has identified the layout. Once a request is confined to a specific bin, the way how that bin is broken up into more bins or if it is broken up at all is irrelevant for the client and the way how that data is addressed within th

23、e request. Note, however, that data a server returns upon a request will, in general, depend on that layout because the division of the logical target into metadata-bins may force the server to return additional data, including the contents or headers of some other, potentially unrequested boxes. Al

24、l a server has to ensure that at least the requested data is contained, and that enough data is returned to allow a client to parse it. Examples when additional data must be returned are given below in C.5.2.7. The following text uses the wording “request“ to point out which data is desired by the c

25、lient, which might be a sub-set of the data actually returned by the server due to reasons pointed out in C.5.2.7. ISO/IEC 15444-9:2005/Cor.2:2008 (E) 2 Rec. ITU-T T.808 (2005)/Cor.2 (06/2008) Example For better illustration, examples in the following subclauses all refer to the following segment of

26、 a JPX file, see Rec. ITU-T T.801 | ISO/IEC 15444-2 for the definition of the boxes used here. The labels on the right-hand side have been added for later reference: Content Label association box header (asoc) A number list box header (nlst) B number list box content C association box header (asoc)

27、D ROI description box header (roid) E ROI description box content F association box header (asoc) G label box header (lbl040) H label box content I XML box header (xml040) J XML box content K The sub-box structure of the above example is indicated by indention, e.g., items H to K establish the conte

28、nts of the superbox at label G. C.5.2.2 root-bin Each request is relative to the data-bin specified by its root-bin value. If a root-bin value is not specified, the root is meta-data bin 0. The request pertains only to data within or referenced by that particular data-bin. Example If the server deci

29、ded to place the contents of association box A in the above example into a separate bin with bin id #3, the association box header A would be encoded in a placeholder box, and items B to K would establish bin #3. In that case, a root-bin field of 3 would limit the scan to items B to K only. Specific

30、ally, metareq=roidR3 would request items E and F from the server and no other data outside of this example (but see also C.5.2.3 and C.5.2.7 for additional data outside of the request potentially returned by the server along). An alternative layout might be to include items B to G in bin #3 as above

31、, but in addition place items H to K into the separate bin #4. Thus G would be represented by a placeholder box in bin #3 and H to K would be part of bin #4. A root-bin field of 3 would still scan the items H to K because they are referenced by a placeholder in bin #3 and the way how bin #3 is broke

32、n up into sub-bins is irrelevant to the request. Thus, even though the server response would be different, the items identified by the request remain the same. A root-bin field of 0 imposes no further restriction on the request each item, box or superbox, is somehow reachable from the metadata-bin #

33、0. Whether placeholder boxes are used or not is completely irrelevant. Thus, metareq=roid would request all ROI description boxes from the server, and thus also include items E and F along with all other ROI description boxes available. C.5.2.3 max-depth If a value for max-depth is specified, then o

34、nly boxes contained within the root metadata-bin, and those no more than max-depth levels in the file hierarchy below that box are requested. If a value for max-depth is not specified, there is no limit on the depth of the file hierarchy for this request. Example If items B to K establish the conten

35、ts of metadata-bin #3 as in the example for C.5.2.1, the root-bin field is set to 3 and max-depth is set to 0, then the request is limited to items B to D. If max-depth is set to 1, the request is limited to items B to G. The request metareq=roidR3D0 would therefore not request any data from the ser

36、ver because the only ROI description box within the specified bin is one level below the start of bin #3. The request metareq=asocR3D0 would request the association box starting at label D and its contents, items E to K. This request is identical to metareq=asocR3D3 because, even though the latter e

37、xample also requests the association box starting at label G, this box is part of the box starting at label D and is thus included in the former request anyhow. ISO/IEC 15444-9:2005/Cor.2:2008 (E) Rec. ITU-T T.808 (2005)/Cor.2 (06/2008) 3 C.5.2.4 I-box-prop The req-box-prop portion of the request sp

38、ecifies a list of box types that are of interest to the client. The special string “*“ may be substituted for the box type, in which case all box types are implied. Thus, this field confines the request to apply only to the specific box type (or types) listed and instructs the server to deliver the

39、box header and box contents of all matching boxes within all additional constraints. The contents of a superbox is defined by its complete sub-box hierarchy. This implies that in case superboxes match the box type, the complete sub-box hierarchy of the matching superbox is requested, regardless of t

40、he max-depth field. Example Consider again the example layout of C.5.2. Then, a req-box-prop of type asoc would include all items A to K in the request because they establish the content of the matching box defined at label A. Note that, once the association box at label A has been identified to mat

41、ch the request, the depth limit does not limit the delivery of its contents. A req-box-prop of type lbl040 would only include items H and I, along with all other label boxes, provided they match all other specifications of the request, e.g., are contained in the addressed root bin above the depth-li

42、mit. The request metareq=*R3D0 instructs the server to return the entire contents of all boxes it finds in the contents of bin 3, and thus requests items B to K. While a restriction on the desired depth has been specified, the server shall ignore that restriction because items E to K are part of the

43、 box starting at label D and no other constraints apply. C.5.2.5 limit The limit attribute optionally following the req-box-prop field further confines the type of request, and how many bytes of the box contents identified by the req-box-prop field the client is interested in. The limit parameter ta

44、kes the form of a colon followed by either an unsigned integer (the limit value) or the character “r“. The same limit value applies to all boxes that match the req-box-prop of which it is an attribute. If it is not present, the client is requesting all matching boxes entirely. If the limit field is

45、an integer n greater than zero, then the server is requested to return the unlimited box header and only the first n bytes of the box content of the matching boxes. The byte count is here defined to count the data as it appeared in the original file before it was broken up into bins. Furthermore, if

46、 req-box-prop matches any superboxes, the contents of a superbox is to be understood as the complete and unlimited sequence of box headers and box contents contained within that superbox, and the byte limit by that also counts the box headers of all boxes contained within the matching super box. It

47、may thus happen that the limit field instructs the server to deliver only parts of a (sub-)box header even though the full header of the matching box itself is always included. However, using the limit field in this way is discouraged and should be avoided. If the limit field is zero, only the box h

48、eaders of the matching boxes are requested. If the limit value is “r“, then the server is requested to deliver the minimum data required to reconstruct the box-headers of all matching boxes, as well as the minimum data to reconstruct the box-headers of all of its descendant sub-boxes up to the maxim

49、um depth specified, regardless of their box-type. Note that, as an exception, max-depth does apply for the limit value “r“ to limit the contents of superboxes, which makes this type of request special as far as the interpretation of max-depth is concerned. Example Consider again a file layout as in C.5.2 above with items B to K in data bin #3 and the metadata request metareq=asoc:8R3D1. By that,