Information technologies — JPEG systems — Part 5: JPEG universal metadata box format (JUMBF)

This document describes the JPEG universal metadata box format (JUMBF), which provides a universal format to embed any type of metadata in any box-based JPEG file format. This document defines the syntax of the JUMBF box and the mechanism to assign specific content types. In particular, this document specifies XML, JSON, CBOR, Embedded File, codestream and UUID types. In addition, this document defines the syntax to reference or request the embedded metadata content within or outside the image.

Technologies de l'information — Systèmes JPEG — Partie 5: Format universel de fichier de métadonnées pour JPEG (JUMBF)

General Information

Status
Published
Publication Date
26-Jun-2023
Current Stage
6060 - International Standard published
Start Date
27-Jun-2023
Due Date
10-Aug-2023
Completion Date
27-Jun-2023
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 19566-5:2023 - Information technologies — JPEG systems — Part 5: JPEG universal metadata box format (JUMBF) Released:27. 06. 2023
English language
21 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 19566-5
Second edition
2023-06
Information technologies — JPEG
systems —
Part 5:
JPEG universal metadata box format
(JUMBF)
Technologies de l'information — Systèmes JPEG —
Partie 5: Format universel de fichier de métadonnées pour JPEG
(JUMBF)
Reference number
ISO/IEC 19566-5:2023(E)
© ISO/IEC 2023

---------------------- Page: 1 ----------------------
ISO/IEC 19566-5:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 19566-5:2023(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Conventions . 2
4.1 Conformance language . 2
4.2 Naming conventions for numerical values . 3
4.3 Boxes and superboxes . 3
4.4 Graphical descriptions . 4
5 Implementation . . 4
Annex A (normative) JUMBF Box file format .5
Annex B (normative) JUMBF Content Types . 9
Annex C (normative) JUMBF references and requests .15
Annex D (informative) JUMBF backwards compatibility and integration .17
Bibliography .21
iii
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/IEC 19566-5:2023(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of
any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC
had not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC SC 29, Coding of audio, picture, multimedia and hypermedia information.
This second edition cancels and replaces the first edition (ISO/IEC 19566-5:2019), which has been
technically revised. It also incorporates the Amendment ISO/IEC 19566-5:2019/Amd 1.
The main changes are as follows:
— Content Type for the Concise Binary Object Representation (CBOR) data as specified by RFC 8949;
— new box, the Padding Box;
— new Private entry in the JUMBF Description Box.
A list of all parts in the ISO/IEC 19566 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 19566-5:2023(E)
Introduction
The JPEG universal metadata box format (JUMBF) provides a mechanism to embed and refer generic
metadata in JPEG files. Specific content types can be assigned to identify the specific type of the
embedded metadata. In addition to the content types defined in this document, other types can be
defined by other standards or by third parties. ISO/IEC 19566-4 and ISO/IEC 19566-6 both use JUMBF
to embed additional metadata in JPEG images. The JPEG XT file format (see ISO/IEC 18477-3) is used to
embed JUMBF boxes in JPEG-1 images (see Rec. ITU-T T.81 | ISO/IEC 10918-1).
v
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 19566-5:2023(E)
Information technologies — JPEG systems —
Part 5:
JPEG universal metadata box format (JUMBF)
1 Scope
This document describes the JPEG universal metadata box format (JUMBF), which provides a universal
format to embed any type of metadata in any box-based JPEG file format. This document defines
the syntax of the JUMBF box and the mechanism to assign specific content types. In particular, this
document specifies XML, JSON, CBOR, Embedded File, codestream and UUID types. In addition, this
document defines the syntax to reference or request the embedded metadata content within or outside
the image.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 11578, Information technology — Open Systems Interconnection — Remote Procedure Call (RPC)
ISO/IEC 21778, Information technology — The JSON data interchange syntax
FIPS PUB 180-4, Secure Hash Standard (SHS)
,
W3C, Extensible Markup Language (XML 1.0)
IETF RFC 8949, Concise Binary Object Representation (CBOR)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
box
binary structure that encapsulates an object embedded in a file
3.1.2
codestream
sequence of bits representing a compressed image and associated metadata
1
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/IEC 19566-5:2023(E)
3.1.3
JUMBF Box
superbox (3.1.9) containing a JUMBF Description Box, JUMBF Content Boxes and possibly a Padding Box.
3.1.4
JUMBF Content Box
box (3.1.1) of any type embedded in a JUMBF Box (3.1.3) except the JUMBF Description Box or a Padding
Box
3.1.5
JUMBF Content Type
specific set of JUMBF Type (3.1.6) values
3.1.6
JUMBF Type
UUID that implies the type of content (3.1.4) embedded in a JUMBF Box
3.1.7
Media Type
standard description of the type and/or format of the data
[SOURCE: RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, (November
1996), Internet Engineering Task Force (IETF)]
3.1.8
parent image
image file in which a JUMBF Box is embedded
3.1.9
superbox
box (3.1.1) that only contains other boxes
3.2 Abbreviated terms
CBOR Concise Binary Object Representation
JPEG Joint Photographic Experts Group
JPEG-1 image complying to ISO/IEC 10918-1
JSON JavaScript object notation
JUMBF JPEG universal metadata box format
URI uniform resource identifier
XML extensible markup language
4 Conventions
4.1 Conformance language
The keyword "reserved" indicates a provision that is not specified at this time, shall not be used, and
may be specified in the future. The keyword "forbidden" indicates "reserved" and in addition indicates
that the provision will never be specified in the future.
2
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 19566-5:2023(E)
4.2 Naming conventions for numerical values
Integer numbers are expressed as bit patterns, hexadecimal values, or decimal numbers. Bit patterns
and hexadecimal values have both a numerical value and an associated particular length in bits.
Hexadecimal notation, indicated by prefixing the hexadecimal number "0x", may be used instead of
binary notation to denote a bit pattern having a length that is an integer multiple of 4. For example, 0x41
represents an eight-bit pattern having only its second most significant bit and its least significant bit
equal to 1. Numerical values that are indicated as "binary" are bit pattern values (specified as a string
of digits equal to 0, 1 or x in which the left-most bit is considered the most-significant bit and 'x' means
either 0 or 1). Other numerical values not prefixed by "0x" are decimal values. When used in expressions,
a hexadecimal value is interpreted as having a value equal to the value of the corresponding bit pattern
evaluated as a binary representation of an unsigned integer (i.e., as the value of the number formed by
prefixing the bit pattern with a sign bit equal to 0 and interpreting the result as a two's complement
representation of an integer value). For example, the hexadecimal value 0xF is equivalent to the 4-bit
pattern '1111' and is interpreted in expressions as being equal to the decimal number 15.
4.3 Boxes and superboxes
The annexes of this document focus on the definition of boxes. The details for embedding boxes in
specific file formats are defined in the particular documents, for example ISO/IEC 15444-1 for JPEG
2000, ISO/IEC 18477-3 for JPEG-1 / JPEG XT or the more generic ISO/IEC 14496-12 ISO base media file
format (ISOBMFF).
In general, each object in the file is encapsulated within a binary structure called a box. A box that only
contains other boxes is called a superbox. The binary structure is given in Figure 1.
Figure 1 — Binary structure of a box
— LBox: box length. This field specifies the length of the box, stored as a 4-byte big-endian unsigned
integer. This value includes all of the fields of the box, including the length and type. If the value of
this field is 1, then the 'XLBox' field shall exist and the value of that field shall be the actual length
of the box. If the value of this field is 0, this indicates that the box contains all bytes up to the end
of the file. If a box of length 0 is contained within another box (its superbox), then the length of
that superbox shall also be 0. This means that this box is the last box in the file. The values 2-7 are
reserved for ITU-T | ISO/IEC use.
— TBox: box type. This field specifies the type of information found in the Payload Data field. The
value of this field is encoded as a 4-byte big-endian unsigned integer. However, boxes are generally
referred to by an ISO/IEC 646 character string translation of the integer value. For all box types
defined within this document, box types will be indicated as both character string (normative) and
as 4-byte hexadecimal integers (informative). Also, a space character is shown in the character
string translation of the box type "s "\"40". All values of 'TBox' not defined within this document are
reserved for Rec. ITU-T T.81 | ISO/IEC 10918-1 use.
— XLBox: box extended length. This field specifies the actual length of the box if the value of the 'LBox'
field is 1. This field is stored as an 8-byte big-endian unsigned integer. The value includes all of the
fields of the box, including the 'LBox', 'TBox' and 'XLBox' fields.
— Payload Data: box contents. This field contains the actual information contained within this box.
The format of the box contents depends on the box type and will be defined individually for each
type.
3
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 19566-5:2023(E)
4.4 Graphical descriptions
Box definitions contain graphical description figures to illustrate the structure of the box. These figures
should be interpreted as follows.
— The figures do not include box type and size fields.
— A sequence of rectangles is used to indicate the fields of the box and their order.
— The width of the rectangle indicates the length of the field, a square rectangle indicates a 16 bit field.
— A grey background indicates a variable length field.
— Optional fields have a dashed border.
Figure 2 shows an illustrative example of a box with four fields:
— A: 8 bit required field;
— B: 16 bit required field;
— C: variable length required field;
— D: optional 32 bit field.
Figure 2 — Box with four fields
5 Implementation
JUMBF allows embedding any type of metadata in JPEG images that adopt a box-based file format and
enables referencing to the embedded data internally or externally to the image.
The JUMBF Box Format shall be implemented as defined in Annex A. JUMBF Content Types for common
data formats such as XML, JSON, CBOR, Embedded Files and image codestreams shall be used in
accordance with Annex B. The referencing and requesting mechanism shall be as specified in Annex C.
Annex D describes how to embed JUMBF Boxes in JPEG-1 images using the JPEG XT Box Format.
4
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 19566-5:2023(E)
Annex A
(normative)

JUMBF Box file format
A.1 Overview
This annex defines the JUMBF Box Format. Table A.1 lists all boxes defined in this annex. Indentation
within the table indicates the hierarchical containment structure of the boxes.
Table A.1 — Defined boxes
Box name Type Superbox Required? Comments
JUMBF Box 'jumb' This superbox encapsulates the JUMBF
Yes Required
Description box and JUMBF Content Boxes.
(0x6A75 6D62)
JUMBF Description Box This box is always contained within a
'jumd'
No Required JUMBF Box and specifies the content and
(0x6A75 6D64)
behaviour of the JUMBF Box.
If present, may be a box or superbox of in-
JUMBF Private Box 'PRIV' (or various) Maybe Optional
formation specific to a particular use case.
JUMBF Content Box At least one JUMBF Content Box shall be
(various) Maybe Required
present inside a JUMBF Box.
Padding Box If present, there shall be no more than one
'free' No Optional
Padding Box inside a JUMBF Box.
A.2 JUMBF Box
A JUMBF Box is a superbox that shall contain exactly one JUMBF Description Box followed by one or
more JUMBF Content Boxes and at most one Padding Box. The type of the JUMBF Content Boxes is
determined by the TYPE field in the JUMBF Description Box. JUMBF Boxes can be nested, i.e. the JUMBF
Content Boxes may, themselves, be JUMBF Boxes. The JUMBF Description Box shall always be the first
box in the JUMBF Box.
NOTE Multiple JUMBF Content Boxes can only be contained in the same JUMBF Box when they are
semantically related since they share a single label and TYPE.
The type of a JUMBF Box shall be 'jumb' (0x6A75 6D62). The structure of the JUMBF Box is illustrated
in Figure A.1.
5
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 19566-5:2023(E)
Figure A.1 — Structure of the JUMBF Box
A.3 JUMBF Description Box
The JUMBF Description Box provides additional information about the behaviour and content of the
JUMBF Box in which it is contained.
The type of a JUMBF Description Box shall be 'jumd' (0x6A75 6D64). The fields of the JUMBF Description
Box are illustrated in Figure A.2, the field values are summarized in Table A.3.
Figure A.2 — Structure of the JUMBF Description Box
— TYPE: this field shall contain a 16-byte UUID as specified in ISO/IEC 11578. The value of this UUID
specifies the format of the JUMBF Content Boxes contained in the JUMBF Box and the interpretation
of that information. This field is referred to as the JUMBF Type.
— TOGGLES (T): this 1-byte field signals the values of options related to the JUMBF Box as specified
in Table A.2 where bit value 1 means enabled and bit 0 disabled.
Table A.2 — TOGGLES
Binary value Meaning TOGGLE Details
0000 xx11 Requestable Requestable. This option signals whether the content of the JUMBF
Box can be requested using the request mechanism as specified in
0000 xxx0 Not requestable
Annex C. If Requestable is set to 1, the "label present" option should be
set to 1 as well.
The upper three bits are reserved for future use.
6
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 19566-5:2023(E)
TTabablele A A.22 ((ccoonnttiinnueuedd))
Binary value Meaning TOGGLE Details
 — If set to zero, any implementation i) shall provide an error message,
and ii) shall not act upon the request in a way that can possibly
expose the data.
— If set to 1, i) a supporting implementation will return the requested
data, and ii) a non-supporting implementation shall return an error
message.
0000 xx1x Label present Label present. This option signals if a Label field is present.
0000 xx0x No label present
0000 x1xx ID present ID present. This option signals if an ID field is present.
0000 x0xx No ID present
0000 1xxx Hash present Hash present. This option signals if a Hash field is present.
0000 0xxx No hash present
0001 xxxx Private present Private present. This option signals if a Private field is present.
0000 xxxx No private pres-
ent
The upper three bits are reserved for future use.
— LABEL: this optional field contains a variable length textual label that can be used to reference
or request the content of the JUMBF Box as specified in Annex C. Its presence is signalled in the
TOGGLES field. This value shall be stored as ISO/IEC 10646 characters in the UTF-8 encoding.
Characters in the ranges U+0000 to U+001F inclusive and U+007F to U+009F inclusive, as well as
the specific characters '/', ';', '?', ':' and '#', are not permitted in the label. The label shall be null-
terminated. The user is responsible for assigning a label which is unique within its scope.
— ID: this optional field contains a user assigned unique 4-byte ID that can be used for binary
references to this JUMBF Box. Its presence is signalled in the TOGGLES field. The user is responsible
for assigning an ID that is unique within its scope.
— SHA256HASH: this optional field, when present, shall contain a SHA-256 (FIPS PUB 180-4)
cryptographic hash of the JUMBF Content Boxes (in the order they appear). Its presence is signalled
in the TOGGLES field.
— PRIVATE: this optional field, when present, can be used to contain use-case specific data directly
connected to the contents of the associated JUMBF Content Box. The value of the field shall resemble
the structure of a box (see ‎4.3). If the value of the 'TBox' field of this box is 'PRIV', then it shall be
treated as a superbox with any set of boxes within. If the value of 'TBox' is anything else, then this
box shall be treated according to the definition of that box type.
NOTE One use of the 'PRIV' Box is to support having multiple PRIVATE fields.
Table A.3 — Format of the contents of the JUMBF Description box
Parameter Size (bits) Value
TYPE 128 UUID
TOGGLES 8 0-15
LABEL variable or 0 Null terminated UTF-8
string
ID 32 or 0 User assigned
SHA256HASH 256 or 0 SHA-256 hash
7
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC 19566-5:2023(E)
TTabablele A A.33 ((ccoonnttiinnueuedd))
Parameter Size (bits) Value
PRIVATE variable (>64) or 0 Box
NOTE The 64 bits of min-
imum length is the size of
'LBox' + 'TBox'
Additional fields are reserved for future use.
A.4 Padding Box
The Padding Box (a.k.a "Free" Box) enables adding padding to the size of a JUMBF Box. This is used
when the size of a data structure at the beginning of a file is not known, such as when recording a video
with a camera. It also helps with certain editing operations.
NOTE The Padding Box in JUMBF is identical in function to the Free Box present in other box-based formats
such as ISOBMFF and JPEG XL.
JUMBF Boxes may include a single, optional, Padding Boxes to represent free space, as illustrated in
Figure A.1. A Padding Box shall contain only values of 0x00.
The box type of Padding Box shall be 'free' (0x6672 6565). The contents of the box shall be as in
Figure A.3.
Figure A.3 — Organization of the contents of the Padding Box
8
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC 19566-5:2023(E)
Annex B
(normative)

JUMBF Content Types
B.1 Overview
This annex defines JUMBF Content Types that can be used to embed image codestreams, XML data,
JSON data, CBOR data, Embedded Files, or other content wrapped in a UUID box. Table B.1 gives an
overview of these JUMBF Content Types and their assigned JUMBF Type UUID values to be used in the
JUMBF Description Box.
Table B.1 — Overview of JUMBF Content Types
JUMBF type Meaning
0x6579D6FB-DBA2-446B- Codestream Content Type. The JUMBF Box contains exactly one Codestream
B2AC-1B82FEEB89D1 Box.
0x786D6C20-0011-0010- XML Content Type. The JUMBF Box contains exactly one XML Box.
8000-00AA00389B71
0x6A736F6E-0011-0010- JSON Content Type. The JUMBF Box contains exactly one JSON Box.
8000-00AA00389B71
0x75756964-0011-0010-8000- UUID Content Type. The JUMBF Box contains exactly one UUID Box.
00AA00389B71
0x40CB0C32-BB8A-489D- Embedded File Content Type. The JUMBF Box contains exactly one Embedded
A70B-2AD6F47F4369 File Description Box followed by one Binary Data Box.
0x63626F72-0011-0010-8000- CBOR Content Type. The JUMBF Box contains exactly one CBOR Box.
00AA00389B71
Other Content Types may be specified in other specifications. In the case where
there is exactly one JUMBF Content Box, it is recommended to specify the JUMBF
Type UUID by composing the 4-byte type value of the box with the 12-byte
ISO reserved value, 0xXXXXXXXX-0011-0010-8000-00AA00389B71 (see ISO/
IEC 14496-12). The four-character code replaces XXXXXXXX in the preceding
number. In other cases, the user shall use a random generated UUID.
If the last 12 bytes of the JUMBF Type are the ISO reserved value 0x0011 0010 8000 00AA 0038 9B71,
a decoder can replace the JUMBF Box with the single JUMBF Content Box of the JUMBF Box and proceed
decoding. If the JUMBF Type is not known by the reader, the reader shall ignore the entire JUMBF Box.
Table B.2 lists all boxes defined in this annex.
Table B.2 — Boxes defined in this annex
Box name Type Superbox Required? Comments
'jp2c' This box allows to embed image
Contiguous Codestream
No Optional
codestreams.
Box
(0x6A70 3263)
This allows to embed XML (W3C, Ex-
'xml\040'
XML Box No Optional tensible Markup Language (XML 1.0))
(0x786D 6C20)
formatted information.
'json' This allows to embed JSON (ISO/
JSON Box No Optional
IEC 21778) formatted information.
(0x6A73 6F6E)
9
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 14 ----------------------
ISO/IEC 19566-5:2023(E)
TTabablele B B.22 ((ccoonnttiinnueuedd))
Box name Type Superbox Required? Comments
This box provides a tool by which
'uuid'
vendors can add additional informa-
UUID Box No Optional
tion to a file without risking conflict
(0x7575 6964)
with other vendors.
'bidb' This is a box containing any arbitrary
Binary Data Box No Optional
(0x62696462) binary data.
Embedded File Descrip- 'bfdb' This is the description box when add-
No Optional
tion Box (0x62666462) ing arbitrary binary data.
'cbor' This allows to embed CBOR (RFC
CBOR Box No Optional
(0x63626F72) 8949) formatted information.
B.2 Codestream Content Type
B.2.1 JUMBF Content Box
JUMBF Boxes that embed image data shall use the 0x6579D6FB-DBA2-446B-B2AC-1B82FEEB89D1
JUMBF Type. The JUMBF Content Box shall contain exactly one Contiguous Codestream Box as
illustrated in Figure B.1.
Figure B.1 — Structure of a Codestream Content Box
Codestream Content Type Boxes that do not contain other boxes can also use the 0x6A703263-0011-
0010-8000-00AA00389B71 JUMBF type.
B.2.2 Contiguous Codestream Box
The Contiguous Codestream Box contains a valid and complete image codestream. The image
codestream shall be of the same type than the parent image in which the JUMBF Box is embedded.
NOTE 1 If there is a need to embed an image codestream that is not the same type as the parent image, use an
Embedded File Content Type JUMBF Box.
10
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 15 ----------------------
ISO/IEC 19566-5:2023(E)
The type of a Contiguous Codestream Box shall be 'jp2c' (0x6A70 3263). The contents of the box shall be
as in Figure B.2, the fields are summarized in Table B.3.
NOTE 2 Despite the 'jp2c' type name, a Contiguous Codestream Box is not restricted to JPEG 2000 codestreams.
The codestream type is determined by the Image Header Box if present or the parent image codestream type
otherwise.
Figure B.2 — Organization of the contents of the Contiguous Codestream box
— CODE: this field contains a valid and complete codestream of the same type than the parent image
in which the JUMBF Box is embedded.
Table B.3 — Format of the contents of the Contiguous Codestream Box
Field name Size (bits) Value
Code Variable Variable
B.3 XML Content Type
JUMBF Boxes that embed XML shall use the 0x786D6C20-0011-0010-8000-00AA00389B71 JUMBF
Type. The JUMBF Content Box shall contain exactly one XML box. An XML Box shall contain XML (W3C,
Extensible Markup Language (XML 1.0)) formatted information.
The type of an XML box is 'xml\040' (0x786D 6C20). The contents of the box shall be as in Figure B.3.
Figure B.3 — Organization of the contents of the XML Box
— DATA: this field shall contai
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.