ISO/IEC 19566-10:2026

International
Standard
ISO/IEC 19566-10
Second edition
Information technology — JPEG
2026-09
systems —
Part 10:
Reference software
Reference number
© ISO/IEC 2026
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
© ISO/IEC 2026 – All rights reserved
ii
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 .1
4 Reference software . 2
4.1 Purpose .2
4.2 Examples of use .2
4.3 Warranty disclaimer .3
4.4 General .3
5 Copyright, licensing and intellectual property . 3
Annex A (informative) Validation of ISO/IEC 19566-5 (JUMBF) reference software. 4
Annex B (informative) JUMBF reference software: Java implementation. 9
Annex C (informative) JUMBF reference software: C++ implementation .18
Annex D (informative) Validation of ISO/IEC 19566-4 reference software .26
Annex E (informative) Privacy and security reference software: Java implementation .31
Annex F (informative) Validation of ISO/IEC 19566-6 reference software .36
Annex G (informative) JPEG 360 reference software: Java implementation .44
Annex H (informative) Validation of ISO/IEC 19566-7 reference software .49
Annex I (informative) JLINK reference software: Java implementation .57
Annex J (informative) Validation of ISO/IEC 19566-8 reference software .63
Annex K (informative) JPEG Snack reference software: Java implementation .71
Annex L (informative) JPEG Snack reference software: C++ implementation . 76
Bibliography .80

© ISO/IEC 2026 – All rights reserved
iii
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 29, Coding of audio, picture, multimedia and hypermedia information.
This second edition cancels and replaces the first edition (ISO/IEC 19566-10:2024), which has been
technically revised. It also incorporates the Amendment ISO/IEC 19566-10:2024/Amd 1:2025.
The main changes are as follows:
— Inclusion of more reference implementation supporting all JUMBF Content Types defined throughout the
ISO/IEC 19566 series,
— Revision of the JUMBF reference implementation to support the processing of JUMBF data in more image
file formats,
— Enhancement of the reference dataset to include more scenarios from different image file formats.
A list of all parts in the ISO 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.

© ISO/IEC 2026 – All rights reserved
iv
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.
This document specifies reference software implementations that handle JUMBF data according to the
Content Types specified in the ISO/IEC 19566 series. For each part of the ISO/IEC 19566 series, a reference
dataset is also provided, allowing for the conformance checking of candidate applications. The dataset
provides cases focusing on the intrinsic characteristics of the JUMBF data model, but also expands to the
encoding of JUMBF files in image file formats.
In the second edition of this document (JPEG Systems reference implementations), more reference
implementations are included covering all JUMBF Content Types specified in ISO/IEC 19566 specifications.
At least one reference implementation exists per ISO/IEC 19566 parts, while more implementations are
[1] [2]
specified in ISO/IEC 19566-5 (JUMBF) and ISO/IEC 19566-8 (JPEG Snack).

© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 19566-10:2026(en)
Information technology — JPEG systems —
Part 10:
Reference software
1 Scope
[1]
This document specifies a reference software implementation of ISO/IEC 19566-5 . The reference
software is accompanied with a reference dataset which provides an extensive list of the various JUMBF
[1]
data structures specified in ISO/IEC 19566-5 .
2 Normative references
There are no normative references in this document.
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
codestream
compressed image data representation that includes all necessary data to allow a (full or approximate)
reconstruction of the sample values of a digital image
3.2 Abbreviated terms
APP11 application marker 11: JPEG XT extension marker
CBOR concise binary object representation
CLI command line interface
CSV comma separated values
GUI graphical user interface
IoC inversion of controls
ISOBMFF ISO base media file format
IV initial value
JPEG joint photographic experts group

© ISO/IEC 2026 – All rights reserved
JPEG-1 image complying to Rec. ITU-T T.81 | ISO/IEC 10918-1
JP2C JPEG contiguous codestream
1)
JSON JavaScript object notation
JUMBF JPEG universal metadata box format
POJO plain old Java object
UUID universally unique identifier
XML extensible markup language
4 Reference software
4.1 Purpose
The use of the reference software is not required for making an implementation of parser or generator in
conformance to any of the parts of the ISO/IEC 19566 series. Requirements established in all parts of the
ISO/IEC 19566 series take precedence over the behaviour of the reference software.
4.2 Examples of use
This subclause enumerates possible uses of the reference implementations presented in the annexes:
a) Sample parser. Users can use the reference implementations to inspect, even through visualization, the
[1]
structure and contents of the JUMBF data model as specified in ISO/IEC 19566-5 .
b) Sample generator. Users could use the reference implementations to create JUMBF files that could
be used to facilitate the development of applications that take advantage of the benefits of JUMBF
specification.
c) Provide anchor implementations for development purposes. JUMBF data model developers could study
the reference implementations presented in the annexes in order to gain better insight on the algorithms
as well as on how JUMBF Boxes are interconnected.
d) Provide anchor implementations to test possible conformant software. This facilitates developers to
have an existing implementation act as a ground truth which will assist them assess the validity of their
own implementations.
The lack of detection of any conformance violation by any reference software implementation should not
be considered as a definite proof that the codestream under testing conforms to all constraints required
for it to be conforming to one of the parts of the ISO/IEC 19566 series. Similarly, the computation resource
characteristics in terms of program or data memory usage, execution speed, etc. of sample software
encoder or decoder implementations shall not be construed as a representative of the typical, minimal or
maximal computational resource characteristics to be exhibited by implementations of some parts of the
ISO/IEC 19566 series.
TM
1) JavaScript is the trademark of a product supplied by Oracle® Corporation. This information is given for the
convenience of users of this document and does not constitute an endorsement by ISO or IEC of the product named.
Equivalent products may be used if they can be shown to lead to the same results.

© ISO/IEC 2026 – All rights reserved
4.3 Warranty disclaimer
Regardless of any and all statements made herein or elsewhere regarding the possible uses of the reference
software, the following disclaimers of warranty apply to the provided reference software implementations:
— ITU, ISO and IEC disclaim any and all warranties, whether express, implied, or statutory, including any
implied warranties of merchantability or of fitness for a particular purpose.
— In no event shall the contributor(s) or ITU, ISO or IEC be liable for any incidental, punitive or consequential
damages of any kind whatsoever arising from the use of these programs.
— This disclaimer of warranty extends to the user of these programs and the user’s customers, employees,
agents, transferees, successors, and assignees.
— ITU, ISO and IEC do not represent or warrant that the software is free of infringements of any patents.
— Commercial applications of ITU-T Recommendations and ISO/IEC International Standards, including
shareware, may be subject to royalty fees to patent holders.
4.4 General
The rest of the document describes several reference software implementations. Reference software
implementations do not intend to be unique. Therefore, some parts of JPEG Systems can have more than
one implementation. On the other hand, reference software implementations need to be validated, from
functionality and interoperability points of view. Hence, Annex A describes the mechanism followed for
validation of the JUMBF reference software. Annex B describes an implementation of reference software for
[1]
JUMBF (as specified in ISO/IEC 19566-5 ). The implementations presented in the subsequent annexes are
summarized in Table 1, including information related to the parts of the ISO/IEC 19566 series they cover, the
provided functionalities as well as the technology used.
The reference software implementations along with the respective reference datasets are available at
https:// standards .iso .org/ iso -iec/ 19566/ -10/ ed -2/ en.
Table 1 — Reference software implementations for the ISO/IEC 19566 series
Annex Software ISO/IEC 19566 parts Decoder Encoder Technology
[1] a
Annex B jumbf-2.2 library ISO/IEC 19566-5 Yes Yes Java
[1]
Annex C dbench-jumbf-1.0 ISO/IEC 19566-5 Yes Yes C++
[3]
Annex E privsec-1.2 library ISO/IEC 19566-4 Yes Yes Java
[4]
Annex G jpeg360-1.2 library ISO/IEC 19566-6 Yes Yes Java
[5]
Annex I jlink-1.2 library ISO/IEC 19566-7 Yes Yes Java
[2]
Annex K jpegsnack-1.2 library ISO/IEC 19566-8 Yes Yes Java
[2]
Annex L dbench-jpeg-snack-1.0 ISO/IEC 19566-8 Yes Yes C++
a TM
Java is the trademark of a product supplied by Oracle® Corporation. This information is given for the convenience of users
of this document and does not constitute an endorsement by ISO or IEC of the product named. Equivalent products may be used if
they can be shown to lead to the same results.
5 Copyright, licensing and intellectual property
The source code for all reference implementations is provided within the package accompanying this
document. ISO/IEC draws the attention of the users of this software to the licence terms and conditions
specified in the LICENSE file located in the main directory of each reference software implementation.

© ISO/IEC 2026 – All rights reserved
Annex A
(informative)
Validation of ISO/IEC 19566-5 (JUMBF) reference software
A.1 General
This subclause describes the validation process that is followed in order to verify the correctness of
[1]
ISO/IEC 19566-5 reference software implementations. The validation procedure deals with parser and
generator implementations separately. Along with the validation procedure, the JPEG Systems reference
dataset is included. In principle, any reference implementation presented in this document can parse/
generate the reference files of the related ISO/IEC 19566 part.
In general, the aim of the JPEG Systems reference dataset is to address all the available JUMBF Content Types
specified in scope of ISO/IEC 19566 series and covering cases of standalone JUMBF files, but also embedding
JUMBF Boxes in supporting image file formats. The JPEG Systems reference dataset is split into multiple
subdirectories, each of which corresponds to a specific ISO/IEC 19566 part that specifies JUMBF data
structures. All the available ISO/IEC 19566 parts and the respective JUMBF Content Types that are specified
in each one of them is listed in Table A.1.
Table A.1 — JUMBF Content Types as defined in the ISO/IEC 19566 series
Directory name JUMBF Content Types
Part 5 XML, JSON, JP2C, CBOR, UUID, Embedded File
Part 4 Protection, Replacement
Part 6 JPEG 360
Part 7 JLINK
Part 8 JPEG Snack
A.2 JUMBF reference dataset
The JPEG Systems reference dataset — which is attached along with this document — consists of multiple
directories, one of which is related to the JUMBF reference dataset. This directory consists of an exhaustive
[1]
list of standalone JUMBF files covering ISO/IEC 19566-5 . In addition, a set of examples of JUMBF data
embedded inside images expressed in JPEG encoding formats is presented. All these files cover plenty of
[1]
combinations for the available JUMBF Description box attributes and Content Types in ISO/IEC 19566-5 .
A detailed description about the information of each of the available files is given in the reference dataset
description, a csv file which accompanies the dataset and signals the contents of the Description box and the
respective Content Boxes. The columns of the reference dataset description file for JUMBF reference dataset
are presented in Table A.2. To specify the content of a JUMBF Box (e.g. the XML payload of an XML Content
type JUMBF box), a set of input files is included in the dataset. The file name of each of the input documents
[1]
is referenced through the csv file in the respective columns. In scope of ISO/IEC 19566-5 the contents of
a JUMBF Box can be an XML serialized content, a JSON serialized content, a CBOR serialized content, a JPEG
codestream or a generic bytestream. In principle, with the reference dataset description file it is possible to
define any combination of JUMBF data. Specifically, columns A-K refer to all the various combinations related
to the Description box data model. Columns L and M specify the expected number and content (i.e. input file)
[1]
of the Content Box for each JUMBF Box defined in ISO/IEC 19566-5 . Next, columns N-O correspond to the
specific fields defined in UUID Content type JUMBF box, while columns P-R correspond to those of Embedded
File Content type JUMBF box. Finally, column S points to the file name of the generated file where the JUMBF
data is going to be stored. If a column is not applicable for a specific JUMBF structure, “NULL” value is used.
Each line of the csv defines a JUMBF Box that is stored either as a standalone file or embedded in a host
image which is encoded using one of the available JPEG encoding formats. Normally, each line corresponds

© ISO/IEC 2026 – All rights reserved
to a unique file. However, it is also possible for multiple lines to specify a common value in column S. This
means that multiple JUMBF Boxes are concatenated to a single file.
Table A.2 — Definition of the JUMBF reference dataset description csv file.
Csv column NULL value
Csv column name Csv column description
number allowed?
A Test Id Name of the specific scenario described in the No
row
B Content Type (UUID) The JUMBF Content Type of the JUMBF Box to be No
generated.
C Host JPEG Image The name of the JPEG Encoded image that will Yes
host the generated JUMBF Box. If NULL, the
resulted JUMBF Box will be stored in a separate
file (i.e. JUMBF standalone file) with the .jumbf
extension.
D LBox Value of the LBox attribute of the JUMBF Box Yes
header. Available values: 0 (i.e. Read until the end
of file), 1 (i.e. the size in bytes of the box is ex-
pressed in the XLBox attribute of the JUMBF Box
header), NULL (The actual size in bytes of the
JUMBF Box is stored in LBox JUMBF Box header).
E Is Requestable? Boolean value included in the Description box. It No
corresponds to the “Requestable” field as speci-
[1]
fied in ISO/IEC 19566-5 .
F Label String value included in the Description box. It Yes
corresponds to the “Label” field as specified in
[1]
ISO/IEC 19566-5 .
G ID Numerical value included in the Description box. Yes
It corresponds to the “Id” field as specified in
[1]
ISO/IEC 19566-5 .
H SHA256HASH (file name) The name of the file pointing to the bytestream Yes
value included in the Description box. It corre-
sponds to the “SHA256Hash” field as specified in
[1]
ISO/IEC 19566-5 .
I Contains multiple private fields? Boolean value that specifies whether there is a No
private field included in the requested Descrip-
tion box. If set to FALSE, it means that either
there is no Private field or there is a single ISOB-
MFF Box. If set to TRUE, it means that the Private
field consists of a ‘priv’ box.
J Private Field (JUMBF Box file The name of the JUMBF standalone file that Yes
name) contains the bytestream that corresponds to
the contents of the private field of the requested
Description box.
K Padding (Number of bytes) The number of bytes allocated for the padding No
box content. If set to 0 then no Padding box is
added.
L Number of Content Boxes The number of Content Boxes included in the No
requested JUMBF Box.
M Content Box (file name) The name of the file that corresponds to a No
Content Box of the requested JUMBF Box. For
instance, if the requested JUMBF Box is of XML
Content type, then this column could specify a
“example.xml” file, pointing to the contents of
such JUMBF Box.
N UUID The 16-byte UUID field as specified in the UUID Yes
[1]
Content type in ISO/IEC 19566-5 .

© ISO/IEC 2026 – All rights reserved
TTaabbllee AA.22 ((ccoonnttiinnueuedd))
Csv column NULL value
Csv column name Csv column description
number allowed?
O Data The name of the file pointing to the bytestream Yes
included in a UUID Content type JUMBF box.
P Media Type String value included in the Embedded File De- Yes
scription box. It corresponds to the “Media Type”
[1]
field as specified in ISO/IEC 19566-5 .
Q Filename String value included in the Embedded File De- Yes
scription box. It corresponds to the “FILE NAME”
[1]
field as specified in ISO/IEC 19566-5 .
R Is Externally Referenced? Boolean value included in the Embedded File Yes
Description box. It corresponds to the “External
Reference” field as specified in ISO/IEC 19566-5
[1]
.
S Expected file (file name) The name of the generated file that contains the No
JUMBF Box described in the Test ID of the respec-
tive entry.
Finally, apart from the reference dataset and its description file, the JUMBF reference dataset contains
another csv file which corresponds to a reference report. The reference report contains information that a
[1]
parser information can extract from a JUMBF file in the context of ISO/IEC 19566-5 . The columns of this
csv file are different from the reference dataset description file and their definition is listed in Table A.3.
Table A.3 — Definition of the JUMBF reference dataset report csv file.
Csv column Csv column name Csv column description NULL value
number allowed?
A File name Name of the parsed file which contains No
JUMBF-related information
B Standalone file? Boolean value that specifies whether the parsed No
file contains JUMBF information embedded in a
(host) JPEG image or contains JUMBF data only.
C LBox Numerical value of LBox attribute in JUMBF No
header.
D XLBox Numerical value of XLBox attribute in JUMBF Yes
header.
E Content Type UUID String value specifying the UUID field included in No
the parsed Description box.
F Description box Toggle Numerical value included in the parsed Descrip- No
tion box. It corresponds to the “Toggle” field as
[1]
specified in ISO/IEC 19566-5 .
G Is requestable Boolean value that specifies whether the parsed No
JUMBF Box is requestable. It corresponds to
the “Requestable” field as specified in ISO/IEC
[1]
19566-5 .
H Label String value specifying the Label field included in Yes
the parsed Description box. It corresponds to the
[1]
“Label” field as specified in ISO/IEC 19566-5 .
I ID Numerical value specifying the ID field included Yes
in the parsed Description box. It corresponds to
[1]
the “ID” field as specified in ISO/IEC 19566-5 .
J SHA256 Hash String value specifying the HEX encoded SHA- Yes
256Has value of the parsed Description box. It
corresponds to the “SHA256Hash” field as speci-
[1]
fied in ISO/IEC 19566-5 .
© ISO/IEC 2026 – All rights reserved
TTaabbllee AA.33 ((ccoonnttiinnueuedd))
Csv column Csv column name Csv column description NULL value
number allowed?
K Private field Exists? Boolean value specifying whether a private field No
is included in the parsed Description box.
L UUID box UUID field String value specifying the UUID field included in Yes
the parsed UUID box. The 16-byte UUID field is
specified in the “UUID Content type” subclause of
[1]
ISO/IEC 19566-5 .
M Embedded File Description box Numerical value specifying the toggle of the Yes
Toggle parsed Embedded File Description box. It corre-
sponds to the “Toggle” field as specified in the
“Embedded File Content type” subclause of ISO/
[1]
IEC 19566-5 .
N Embedded File Description box String value specifying the media type of the Yes
Media Type parsed Embedded File Description box. It corre-
sponds to the “Media Type” field as specified in
the “Embedded File Content type” subclause of
[1]
ISO/IEC 19566-5 .
O Embedded File Description box String value specifying the file name of the Yes
File Name parsed Embedded File Description box. It corre-
sponds to the “File name” field as specified in the
“Embedded File Content type” subclause of ISO/
[1]
IEC 19566-5 .
P Embedded File Description box Boolean value specifying whether the parsed Yes
Content Referenced Externally Embedded File Content type JUMBF box is refer-
enced externally or it is embedded in the current
box. It corresponds to the “External file” field as
specified in the “Embedded File Content type”
[1]
subclause of ISO/IEC 19566-5 .
Q Content Box TBox field String value of four characters specifying the Yes
4-byte-type value of the Content Box of the
parsed JUMBF Box (e.g. ‘json’, ‘bidb’).
R Content Box Size Numerical value specifying the number of bytes Yes
of the Content Box of the parsed JUMBF Box.
S JUMBF Box Padding box Size Numerical value specifying the number of bytes No
included in the Padding box of the parsed JUMBF
Box.
A.3 Validation procedure
A.3.1 General
Given the reference dataset along with its description and report files it is possible to define a validation
procedure that parser and generator implementations could use in order to verify their conformance
[1]
with ISO/IEC 19566-5 . Specifically, this section uses the dataset introduced in Clause A.2 and defines
[1]
the validation procedures for reference implementations in scope of ISO/IEC 19566-5 . The validation
procedure could be easily generalized for all parts of the ISO/IEC 19566 series mentioned in the annexes.
A.3.2 Parser validation
Figure A.1 shows the procedure of validating a candidate parser implementation. For a parser implementation
[1]
to check its conformance with ISO/IEC 19566-5 , it shall be able to provide a report which describes the
contents of a JUMBF Box following the structure presented in the reference report.
Initially, the JUMBF reference dataset is provided to the candidate implementation which parses all the files
and generates a report. The generated report is first sorted by the first column (i.e. the name of the JUMBF

© ISO/IEC 2026 – All rights reserved
file) and it is compared with the JUMBF reference dataset report. Provided that the two reports are identical,
[1]
the candidate parser implementation is considered conformant to ISO/IEC 19566-5 .
Figure A.1 — Steps to show that a candidate parser implementation conforms to ISO/IEC 19566-5
A.3.3 Generator validation
Figure A.2 shows the procedure of validating a candidate generator implementation. For a generator
[1]
implementation to check its conformance with ISO/IEC 19566-5 it shall be able to reconstruct the available
JUMBF reference dataset, given the respective reference dataset description file.
Initially, the JUMBF reference dataset description is provided to the generator implementation along with
all the input files that are referenced in it. The candidate implementation should parse the csv file and
generate the corresponding JUMBF data. Finally, the generated dataset is submitted for cross-checking
with the reference dataset. Assuming that all files are identical, the candidate generator implementation is
[1]
considered conformant to ISO/IEC 19566-5 .
Figure A.2 — Steps to show that a candidate generator implementation conforms to ISO/IEC 19566-5

© ISO/IEC 2026 – All rights reserved
Annex B
(informative)
JUMBF reference software: Java implementation
B.1 General
This annex describes a Reference Software implementation (identified as Implementation 1) for
[1]
ISO/IEC 19566-5 (JUMBF). The software library is called jumbf-2.2 and it is the main part of a multi-
module project, namely jpeg-systems-1.2, whose goal is to support all the JUMBF Boxes presented in
[6]
the JPEG Systems specifications. It is written in Java and it allows parsing and generating JUMBF data
[1]
according to ISO/IEC 19566-5 . The design of this software aims to be extended in order to support JUMBF
structures from other ISO/IEC 19566 parts. The source code is included under the directory “Reference
Implementation/annex-b/java-reference-implementation”.
This annex provides background information on the software design approach followed for the development
of this reference software for JPEG Universal Metadata Box Format (JUMBF). In addition, it provides details
on how to compile the jumbf-2.2 library and how it could be used by other Java applications in order to
successfully handle JUMBF data. Clause B.2 defines the hierarchical software design which translates the
[1]
JUMBF model presented in ISO/IEC 19566-5 , into a set of Java classes in a structured and future-proof
manner. Next, B.2.4 presents the requirements and the third-party dependencies required in order to
compile and use the jumbf-2.2 library. Finally, Clause B.3 demonstrates how two different applications use
the library in order to provide an interface which allows the users to interact with JUMBF data.
B.2 Software design
B.2.1 General
The aim of the jumbf-2.2 library is to provide the means to support the manipulation of JUMBF data as
[1]
specified in ISO/IEC 19566-5 . Since there are additional JUMBF Boxes defined in other ISO/IEC 19566 parts,
the jumbf-2.2 library is a module of a broader project where additional libraries extend its functionalities
to define other JUMBF structures. The jumbf-2.2 library, as all the other modules defined in this project,
cover a specific ISO/IEC 19566 part including the amendments and revised editions that have been issued.
The versioning system of the project follows that of the ISO/IEC 19566 parts. Thus, for the JUMBF reference
software, the jumbf-2.2 library supports the model and functionalities specified in scope of ISO/IEC 19566-5
[1]
.
Following the logical structure between the various ISO/IEC 19566 parts, jumbf-2.2 is the main library
that all other libraries of the project should rely on. In fact, the jumbf-2.2 library provides the means to
generate and parse information that is stored in JUMBF format. The library is written in Java and it uses
2)
the Spring Framework . It provides an architecture where the JUMBF model is implemented in a way that
other libraries could inherit the JUMBF structure characteristics by simply adding jumbf-2.2 library as a
dependency. This allows the architecture to be minimal and extendable.
[1]
As specified in ISO/IEC 19566-5 , it is possible to store JUMBF data as standalone files or inside a host
image (e.g. by embedding the boxes in APP11 markers in the case of JPEG 1). Regarding the first case, the
jumbf-2.2 library provides the classes to parse and generate JUMBF data directly from standalone files using
the CoreParserService and CoreParserGenerator classes. In this case, the encoded JUMBF data is expressed
as standalone files with extension “.jumbf”. Regarding the latter case, dedicated classes are implemented for
each JPEG file format. As of this version of the jumbf-2.2 library it is possible to process JUMBF data in JPEG
2) Spring™ is the trademark of a product supplied by Broadcom Inc. This information is given for the convenience of
users of this document and does not constitute an endorsement by ISO or IEC of the product named. Equivalent products
may be used if they can be shown to lead to the same results.

© ISO/IEC 2026 – All rights reserved
1, JPEG XL and JPEG 2000 images. In essence, these classes traverse through the entire JPEG codestream and
focus only on the segments that are related to JUMBF serialized data.
The rest of the section describes the implementation of the classes that are defined to support specifically
[1]
the ISO/IEC 19566-5 . The core concept in this data model is a Box. To describe a Box structure in the
jumbf-2.2 library two classes need to be specified: an Entity class and a Service class. An Entity class contains
the information concerning the fields that are defined in a particular JUMBF Box. Next, the functionalities
to parse and generate a particular box, are included in the respective Service class. This allows for a better
separation of concerns in our software. The class hierarchies for Entity and Services classes are defined in
B.2.2. Finally, once all JUMBF Boxes are defined, it is possible to define the JUMBF Content Types which are
[1]
supported in ISO/IEC 19566-5 . The definition of the hierarchy of Content Type classes is presented in
B.2.3.
B.2.2 JUMBF Box definition: Entity and Service classes
This section presents the two class hierarchies required for the implementation of any JUMBF Box, namely
the Entity and the Service class hierarchies. Figure B.1 presents the class hierarchy for all the Entity classes.
At the top of the figure, the BoxInterface interface defines two methods that each Box structure should
support: “Get the Box Type Id” and “Get the size of the Box”. In other words, each Entity class should be
[7]
able to specify its ISOBMFF ISO/IEC 18477-3 TBox and its size including the length of its headers. Next, a
BmffBox abstract class is defined, implementing the BoxInterface. By definition, the first bytes of any Box
[1]
that is defined in ISO/IEC 19566-5 , correspond to the ISOBMFF header. Specifically, these bytes signal:
— The Length of the box (LBox): 4 Bytes,
— The Type of the box (TBox): 4 Bytes,
— (Optional) The box length extension (XLBox): 8 Bytes.

© ISO/IEC 2026 – All rights reserved
Figure B.1 — Entity class hierarchy in jumbf-2.2
Subsequently, a DescriptionBox class is implemented in order to cover the Description box definition. This
class is a Plain Old Java Object (POJO) that specifies fields as defined in the second edition of ISO/IEC 19566-5
[1]
. The final field of a DescriptionBox class is of type BmffBox and it is intended to describe a private field
[1]
as defined in ISO/IEC 19566-5 . A private field can be any ISOBMFF box, or a Private Box the definition of
[1]
which is covered in the PrivateBox class. Furthermore, the second edition of ISO/IEC 19566-5 defines a
Padding Box structure (implemented in the PaddingBox Entity class) which allows for size manipulation
of a JUMBF box. With these Box definitions, it is possible to implement the Entity class of a generic JUMBF
Box. In the jumbf-2.2 library, it is defined as a set of fields consisting of i. one DescriptionBox field, ii. a list
of BmffBox elements corresponding to the Content Boxes of a JUMBF Box and iii. a field of type PaddingBox.
[1]
The remaining box structures of the 2nd edition of ISO/IEC 19566-5 are defined. These boxes are used for
storing textual and binary data according to the Content Type of each JUMBF Box.
NOTE The validity of the content of each content box is out of scope of the functionalities of the jumbf-2.2 library.
For example, the library does not verify that the content of a JsonBox class is a valid JSON representation. It is up to the
application that uses this library to evaluate the content of a Content Box.
To benefit from code-reusability, jumbf-2.2 library defines two abstract classes (depicted as dashed
rectangles) that distinguish how the data of a content box is handled: a FileBox and a MemoryBox. The
former one defines a String field “fileUrl” which contains the absolute path to the file containing the contents
that should be included in that particular Content Box. The latter abstract box defines a byte array that
allows the storage of the entire information of a Content Box in the buffer.

© ISO/IEC 2026 – All rights reserved
So far, with the class hierarchy of the Entity classes it is possible to define the structure of any Box that
is specified. However, the jumbf-2.21 library provides the means to parse and generate each Box. This is
achieved through the Service class hierarchy, which provides the means to parse/generate each structure
that has been defined in the Entity classes. Figure B.2 presents the Service class hierarchy at the top of
which the BoxService interface is defined. This interface is implemented by every Service class and dictates
every class to provide a method for writing and for parsing the bytes related to that Box. The first class is
the BmffBoxService abstract class. This class implements the two aforementioned methods (i.e. parse and
generate) for the bytestreams that correspond to the ISOBMFF fields, as defined in the respective BmffBox
class. Each of the Service classes that is specified in Figure B.2 inherits from the BmffBoxService as before
handling the internals of each structure it is essential that the ISOBMFF fields are processed. Each Service
class is implemented as Spring Bean, a core object of the Spring Framework. It is managed (instantiated,
assembled) by the Spring Inversion of Controls (IoC) container. With Spring Beans, it is possible to decouple
the dependencies between various classes but also to provide algorithms which are valid for Beans that
haven’t been defined in the jumbf library; instead, Spring Beans could be defined and loaded by a child
library that is dependent on the jumbf library.
Figure B.2 — Service class hierarchy in jumbf-2.2
Having defined all the dependent services, it is worth showcasing the algorithm that handles any JUMBF
Box definition. The implemented algorithm for parsing and generating JUMBF data is future-proof in the
sense that it defines generic steps which allow external libraries to define their own JUMBF structures being
required to handle the JUMBF data model from scratch. From now on, the term “handle” will be used in
order to cover both parsing and generating activities as the algorithm is similar in both cases. First of all,
since JumbfBoxService class is inheriting from the BmffService class, the first bytes that are going to be
handled are the ones related to ISOBMFF headers. Next, the algorithm calls the DescriptionBoxService in
order to handle the DescriptionBox. Based on the UUID field of the Description box the algorithm calls a
discovery process, namely ContentTypeDiscoveryManager. This class is responsible for assigning a new
object which belongs to a new family of classes that implement the interface ContentType. The details of
this class hierarchy are presented in B.2.3. In brief the ContentType classes provide the means to handle a
set of Boxes based on the definition of a Content Type JUMBF Box. The ContentType classes are implemented

© ISO/IEC 2026 – All rights reserved
as Spring Beans. Upon initialization of the context of the application that uses jumbf-2.2 library, the
ContentTypeDiscoveryManager collects all the Spring Beans that extend the ContentType interface.
This provides the capability for additional libraries who depend on jumbf-2.2 library to define their own
ContentType classes and use their own Entity and Service classes without getting involved into the internals
of how a JUMBF Box is structured. Once the ContentType class has handled the byte stream corresponding
to the Content Box(es) of a JUMBF Box, the JumbfBoxService class covers the cases where there is a Padding
box to be handled. Provided that there are sufficient bytestreams allocated for the particular JUMBF Box,
the PaddingBoxService is invoked.
B.2.3 Content Type classes
As mentioned above, apart from the two class hierarchies presented to define all the box structures defined
[1]
in ISO/IEC 19566-5 , the ContentType class hierarchy is implemented in order to combine the correct box
[1]
classes and shape a supported JUMBF Box. In ISO/IEC 19566-5 , there are two categories of ContentType
classes, similar to the two different structures of Content Type JUMBF Boxes: JUMBF Boxes with one or
two Content Boxes. JSON, XML, CBOR, UUID and JP2C Content type JUMBF boxes fall in the former category
while Embedded
...