ISO/IEC 15444-9:2005/Cor 2:2008
(Corrigendum)Information technology — JPEG 2000 image coding system: Interactivity tools, APIs and protocols — Part 9: — Technical Corrigendum 2
Information technology — JPEG 2000 image coding system: Interactivity tools, APIs and protocols — Part 9: — Technical Corrigendum 2
Technologies de l'information — Système de codage d'images JPEG 2000: Outils d'interactivité, interfaces de programmes d'application et protocoles — Partie 9: — Rectificatif technique 2
General Information
Relations
Standards Content (Sample)
INTERNATIONAL STANDARD ISO/IEC 15444-9:2005
TECHNICAL CORRIGENDUM 2
Published 2008-12-15
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION • МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ • ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
Information technology — JPEG 2000 image coding system:
Interactivity tools, APIs and protocols
TECHNICAL CORRIGENDUM 2
Technologies de l'information — Système de codage d'images JPEG 2000: Outils d'interactivité, interfaces de
programmes d'application et protocoles
RECTIFICATIF TECHNIQUE 2
Technical Corrigendum 2 to ISO/IEC 15444-9:2005 was prepared by Joint Technical Committee ISO/IEC
JTC 1, Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia
information, in collaboration with ITU-T. The identical text is published as ITU-T Rec.T.808 (2005)/Cor.2.
ICS 35.040 Ref. No. ISO/IEC 15444-9:2005/Cor.2:2008(E)
© ISO/IEC 2008 – All rights reserved
Published in Switzerland
ISO/IEC 15444-9:2005/Cor.2:2008 (E)
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 following 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-bin = "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 to
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, and 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 be 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 the 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. All 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 client, which
might be a sub-set of the data actually returned by the server due to reasons pointed out in C.5.2.7.
Rec. ITU-T T.808 (2005)/Cor.2 (06/2008) 1
ISO/IEC 15444-9:2005/Cor.2:2008 (E)
Example
For better illustration, examples in the following subclauses all refer to the following segment of 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') D
ROI description box header ('roid') E
ROI description box content F
association box header ('asoc') G
label box header ('lbl\040') H
label box content I
XML box header ('xml\040') 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 contents 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 decided 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. Specifically, metareq=[roid]R3 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, 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 broken 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 #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 only 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 contents 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=[roid]R3D0 would therefore not request any data from the server because the only ROI
description box within the specified bin is one level below the start of bin #3. The request metareq=[asoc]R3D0
would request the association box starting at label 'D' and its contents, items 'E' to 'K'. This request is identical to
metareq=[asoc]R3D3 because, even though the latter example 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.
2 Rec. ITU-T T.808 (2005)/Cor.2 (06/2008)
ISO/IEC 15444-9:2005/Cor.2:2008 (E)
C.5.2.4 I-box-prop
The req-box-prop portion of the request specifies 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 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 the 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 match the request, the depth limit does not limit the delivery of its contents. A
req-box-prop of type 'lbl\040' 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-limit.
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 box starting at label 'D' and no other constraints apply.
C.5.2.5 limit
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.