ISO/IEC 19566-10:2024/Amd 1:2025
(Amendment)Information technology — JPEG Systems — Part 10: Reference software — Amendment 1: Additional reference software implementations
Information technology — JPEG Systems — Part 10: Reference software — Amendment 1: Additional reference software implementations
Titre manque — Partie 10: Titre manque — Amendement 1: Implémentations de logiciels de référence supplémentaires
General Information
Relations
Standards Content (Sample)
International
Standard
ISO/IEC 19566-10
First edition
Information technology — JPEG
2024-12
Systems —
AMENDMENT 1
Part 10:
2025-10
Reference software
AMENDMENT 1: Additional reference
software implementations
Reference number
ISO/IEC 19566-10:2024/Amd. 1:2025(en) © ISO/IEC 2025
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
© ISO/IEC 2025
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 2025 – All rights reserved
ii
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
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.
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.
© ISO/IEC 2025 – All rights reserved
iii
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Information technology — JPEG Systems —
Part 10:
Reference software
AMENDMENT 1: Additional reference software implementations
Subclause 4.4, Table 1
Add the following entries in the table:
Annex C dbench-jumbf-2.0 ISO/IEC 19566-5 Yes Yes C++
Annex E privsec-1.0 library ISO/IEC 19566-4 Yes Yes Java
Annex G jpeg360-1.0 library ISO/IEC 19566-6 Yes Yes Java
Annex I jlink-1.0 library ISO/IEC 19566-7 Yes Yes Java
Annex K jpeg-snack-1.0 library ISO/IEC 19566-8 Yes Yes Java
Annex L dbench-jpeg-snack-1.0 ISO/IEC 19566-8 Yes Yes C++
Subclause 4.4
Add the sentence at the end of the subclause:
The reference software implementations along with the respective reference datasets are available at
https:// standards .iso .org/ iso -iec/ 19566/ -10/ ed -1/ en/ amd/ 1.
Annex C,
Add the following new annexes after Annex B:
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Annex C
(informative)
JUMBF reference software: C++ implementation
C.1 General
This annex describes a Reference Software implementation (identified as Implementation Dbench-JUMBF)
for ISO/IEC 19566-5 JPEG Systems – Part 5: JPEG universal metadata box format (JUMBF) [1].
This software is called “Dbench-JUMBF” written in C++ [7], and it is part of Doublebench’s JPEG Systems
Solution. The software has two parts: a core library and a command line interface (CLI) application. The
core library provides classes for different data structures to support handling of different boxes defined
in ISO/IEC DIS 19566-5:2022. The CLI provides the interface to use the functionalities of core library and
allow parsing and generating standalone JUMBF files through the command line arguments. In addition, it
implements the embedding and parsing of JUMBF structures inside JPEG images. The design of this software
aims to be extended to support JUMBF structures from other JPEG Systems standards.
This annex provides information on the software design approach followed for this reference software
for JPEG Universal Metadata Box Format (JUMBF), as defined in ISO/IEC DIS 19566-5:2022 Information
technologies - JPEG systems - Part 5: JPEG universal metadata box format (JUMBF). In addition, it provides
details on how to use the Dbench-JUMBF library and CLI application to successfully handle JUMBF data.
Subclause C.2 defines the hierarchical software design which translates the JUMBF model presented in
ISO/IEC 19566-5, into a set of C++ classes in a structured and future-proof manner. Next, Subclause C.3
presents the requirements and the third-party dependencies required to compile, build and use the Dbench-
JUMBF library. Finally, subclause C.4 demonstrates two example applications that use the library to provide
an interface that allows the users to interact with JUMBF data.
C.2 Software design
C.2.1 General
The Doublebench JPEG Systems Solution aims to provide the means to support the generation and
manipulation of JUMBF data. Doublebench JPEG Systems Solution imitates the structure of the JPEG Systems
standards in the sense that it is a multi-module project. The basis of this multi-module project is the Dbench-
JUMBF library which constitutes the main topic of this Annex. The jumbf library, as all defined modules of
the project, covers the respective JPEG Systems standards including the amendments and revised editions
that have been issued.
Like the JPEG Systems standards, jumbf is the main library that all other libraries rely on. The jumbf library
provides the means to generate and parse information that is stored in JUMBF format. The library is
implemented in C++ with an object-oriented approach, and it uses ISO C++14 Standard.
As specified in ISO/IEC 19566-5, it is possible to store JUMBF data as standalone files or inside a host image
by embedding the boxes in APP11 markers. Regarding the first case, the jumbf library provides the classes
to parse and generate JUMBF data directly from standalone files. Regarding the generation of standalone
JUMBF data, the file extension “.jumbf” is used, corresponding to the concatenation of ISO Base Media File
Format boxes. The current version of the library supports JPEG-1 files and standalone jumbf files.
The rest of the section describes the implementation of the classes that are defined in the scope of
ISO/IEC 19566-5 standard. The core concept in this data model is a DbBox class. All other type boxes are
derived from the DbBox class as shown in Figure C.1. The DbBox class has all the necessary fields like
“lbox”, “tbox”, “xl_box” and a pointer to “payload”. All the fields are kept private to ensure the integrity and
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
consistency of the field’s data. Similarly, the DbBox class has all the necessary public methods implemented
to set the values of fields and access those values. Implementation for any new box can be added by deriving
it from DbBox and adding respective new fields and methods and overriding the existing methods.
Figure C.1 — Dbench-JUMBF class hierarchy.
C.2.2 Classes for Content Boxes
The Dbench-JUMBF library has the implementations for all the content boxes defined in ISO/IEC-19566-5
also listed in Table C.1. These boxes are derived from DbBox and implementation for each box specific fields
and method are provided. Vertical lines shaded boxes in Figure C.1 shows content boxes. These boxes are
defined to be contained by different JUMBF boxes.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Table C.1 — Content Boxes
Class Name Box Type Superbox Comment
DbXmlBox ‘xml\040’ No This class allows to embed XML
(W3C, Extensible Markup Language)
(0x786D 6C20)
formatted information.
DbJsonBox ‘json’ No This allows to embed JSON (ISO/IEC
21778) formatted information.
(0x6A73 6F6E)
DbCodestreamBox ‘jp2c’ No This class allows to embed image
codestreams.
(0x6A70 3263)
DbUuidBox ‘uuid’ No This class provides a tool by which
vendors can add additional informa-
(0x7575 6964)
tion to a file without risking conflict
with other vendors.
DbBinaryDataBox ‘bidb’ No This class allows to embed any arbi-
trary binary data.
0x 6269 6462)
DbFileDescBox ‘bfdb’ No This class allows to embed the
description when adding arbitrary
binary data.
DbCborBox ‘cbor’ No This allows to embed CBOR (RFC
8949) formatted information.
(0x6362 6F72)
DbFreeBox ‘free’ No This class allows user to add padding
bytes.
(0x6672 6565).
DbJumbDescBox ‘jumd’ No This class allows to provides addi-
tional information about the behav-
(0x6A75 6D64)
iour and content of the JUMBF Box in
which it is contained.
C.2.3 Classes for JUMBF Boxes
The Dbench-JUMBF library has the implementations for all the JUMBF boxes as defined in ISO/IEC-19566-
5. These classes are “DbXmlJumbBox”, “DbJsonJumbBox”, “DbCodestreamJumbBox”, “DbCborJumbBox”,
“DbUuidJumbBox”, and “DbEmbdFileJumbBox” as shown in Figure C.1. The library also contains the
implementation for the class “DbJumbBox”, from which all other content type JUMBF box classes are derived.
Each class has fields to hold the data according to their respective specifications. Each class has fields and
methods derived from “DbBox” and “DbJumbBox”, while the methods of each content box are overridden
to support the functionality related to the box. Each class has the implementation of overridden method to
serialize the contents of the box to an array. Implementation for any new JUMBF box can be added by deriving
it from DbJumbBox and adding respective new fields and methods and overriding the existing methods.
C.3 Command line application.
Doublebench’s JUMBF CLI application “dbench_jumbf_app” is developed on the top of Doublebench’s JUMBF
library which enables users to generate JUMBF boxes and JUMBF bitstream. The application enables users
to create specific content type JUMBF as defined in ISO/IEC 19566-5 and embed the generated bitstream
in a JPEG 1 file. User can also parse JUMBF standalone files and JUMBFs present in JPEG file. Figure C.2 and
Figure C.3 shows a screen-capture of encoding and parsing. Table C.2 lists all the command line parameters
defined in the application along with the possible values and description.
Table C.2 — The different command lines for “dbench_jumbf_app”
S. No Argument Possible Value Description
1 -encode Encode or Generate JUMBF (default)
2 -parse Parse a .jumbf or .jpg file
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
TTabablele C C.22 ((ccoonnttiinnueuedd))
S. No Argument Possible Value Description
3 -host_file INPUT FILENAME For encoding (-encode), Specify input JPEG 1 file name
that will host the JUMBF. It has .jpg or .jpeg file exten-
sion.
4 -i INPUT FILE NAME Specify input file name with .jpg or .jumbf extension for
parsing.
5 -o OUTPUT FILENAME Specify output file name. If -host_file is provided then
the output is .jpg or .jpeg else the output is .jumbf.
If this argument is not provided then the default file
name “db_output.jumbf” will be used.
6 -content_type XML, JSON, JP2C, UUID, Specify JUMBF content type. If not provided then it will
CBOR, EMBEDDED_FILE. be determined from content data file extension.
7 -lbox 0, 1 or NULL Specify Lbox field .
0 = box size will be file size i.e Box will continue till EOF.
1 = box size will be present in XLbox field
NULL = box size will be present in Lbox or XLbox field.
If this field is not provided then the “NULL” will be used
by default.
8 -requestable Set requestable field to true in JUMBF Description box.
9 -label LABEL STRING Specify Label for JUMB Description box.
10 -id Any Positive Integer less Specify ID for JUMB Description box.
than 2 - 1
11 -hash HASH Specify hash/signature for JUMB Description box. HASH
is string of 64 characters. each 2 characters represent a
HEX byte.
12 -hash_file HASH FILE NAME Specify file name for hash/signature to put in JUMB
Description box. HASH_FILE contains only string of 64
characters in binary. each 2 characters represent a HEX
byte
13 -private_data_file FILE NAME Specify file name for private box data to put in JUMB
Description box. FILE NAME contains binary bitstream
in accordance with Box definition
14 -xml_file XML FILE NAME Specify file name (.xml) for xml data to put in JUMBF
Content box.
If -xml_file is provided then “-content_type” become
optional as the software will assign “XML” to JUMBF
Content box type (-content_type).
15 -codestream_file FILE NAME Specify file name for codestream data to put in JUMBF
Content box.
If -codestream_file is provided then “-content_type”
become optional as the software will assign “CODE-
STREAM” to JUMBF Content box type (-content_type).
16 -json_file JSON FILE NAME Specify file name (.json) for json data to put in JUMBF
Content box.
If -json_file is provided then “-content_type” become
optional as the software will assign “JSON” to JUMBF
Content box type (-content_type).
17 -uuid UUID Specify UUID for UUID field to put in JUMBF Content box.
UUID is string of characters. each 2 characters represent
a HEX byte
character \"-\" will ignored by the software.
Examples:
663295b0-2158-42de-b16f-a4e458237885
663295b0215842deb16fa4e458237885
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
TTabablele C C.22 ((ccoonnttiinnueuedd))
S. No Argument Possible Value Description
18 -uuid_data_file FILE NAME Specify file name for UUID box payload data to put in
JUMBF Content box.
19 -embed_file FILE NAME Specify name of the file, the content of which will be
embed in JUMBF Content box.
20 -media_type MEDIA_TYPE Specify media type to put in File Description box.
21 -include_filename Specify flag for file name to put in File Description box.
22 -reference_external Specify flag reference as external flag in File Description
box.
If this flag is provided then “-embed_file” wil be used as
external link and the flag will on.
23 -cbor_file FILE NAME Specify file name (.cbor) for CBOR data to put in JUMBF
Content box.
24 -free_bytes A Positive Integer Specify number of padding bytes for JUMBF padding box.
If this is provided then padding box with tbox = FREE
will be generated and included in JUMBF.
25 -csv_file DATASET FILE NAME Specify the “.csv” file name.
For encoding (-encode), the “.csv” file should have the
data in accordance with JPEG JUMBF Dataset
For parsing (-parse), the values by parsing different
fields will be written to “.csv” file. The values will be in
accordance with the JPEG JUMBF reference report.
26 -row_number A positive integer Specify row number in dataset file name. If this is pro-
vided then specified row number data will be used and
single output file will be generated otherwise all the
rows will be considered and number of output files will
be same as the number of rows in the dataset file.
27 -input_dir INPUT FOLDER PATH Specify input directory name.
In encoding process (-encode), this folder exists and
contains all input files.
In parsing process (-parse), this folder exists and con-
tains all the .jumbf or .jpg files.
28 -output_dir OUTPUT FOLDER PATH Specify directory name for output files.
29 -h or -help Print description of command line arguments.
30 -v or -version Print version of the application.
A few example commands are listed below:
Example 1.
dbench_jumbf_app.exe -encode -xml_file XML_FILE.xml
This command will generate XML JUMBF Box and will write the JUMBF bitstream to db_output.jumbf
file.
Example 2.
dbench_jumbf_app.exe -encode -json_file JSON_FILE.json -label “Example of JSON Content
Box” -o example_json.jumbf
This command will generate a JSON JUMBF Box and will write the JUMBF bitstream to example_json.
jumbf file.
Example 3.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
dbench_jumbf_app.exe -encode -host_file image.jpg -xml_file content.xml -label “This is
a sample xml content JUMBF box” -o image_with_jumbf.jpg
This command will generate XML JUMBF Box with the provided label and will embed the JUMBF
bitstream to “image_with_jumbf.jpg” file.
Example 4.
dbench_jumbf_app.exe -parse -i db_output.jumbf.
This command will parse the “db_output.jumbf” file and will print the values to the screen.
Figure C.2 — Encoding Example.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Figure C.3 — Parsing Example.
C.4 Build and run
To build the software, CMake Scripts are included. Using the following commands the software can be build.
The CMake is required to be installed on the machine.
Windows®:
a) Open command prompt in folder where the source code is present.
b) Run the following commands.
1) mkdir build
2) cd build
3) cmake .\.
4) cmake --build .
c) The software is built and ready to use. Note that CMake GUI can also be used for building on Windows®
machines.
Linux®:
d) In terminal go to the directory where the source code lies.
e) Run the following commands.
1) mkdir build
2) cd build
3) cmake ./
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
4) make
f) The software is built and ready to use.
C.5 Software dependencies
The software is developed in ISO C++14 Standard with CMake build system support. Third party libraries or
software are not used. Only C++ standard libraries are used.
Annex D
Add the following new annex after Annex C:
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Annex D
(informative)
Validation of ISO/IEC 19566-4 reference software
D.1 Introduction
This section describes the validation process that is followed in order to verify the correctness of
ISO/IEC 19566-4 reference software implementations. The validation procedure deals with parser and
generator implementations separately. This section presents the JPEG Privacy & Security reference dataset
as well as the validation procedure for verifying the conformance of candidate implementations.
D.2 Privacy and security reference dataset
The Privacy & Security reference dataset is part of the broader JPEG Systems reference dataset and it
contains JUMBF serialized data related to the JUMBF Content Types specified in ISO/IEC 19566-4. The JPEG
Privacy & Security reference dataset description is included along with the dataset. The CSV columns of
the reference dataset descriptions are specified in Table D.1. The goal is to describe all possible fields that
are available in order to generate valid structures of a Protection or a Replacement Content type JUMBF
box. Specifically, columns A-K are allocated for describing the possible values for a Description box, while
columns L-M describe the contents of each of the supported JUMBF Content Types. Next, column N provides
a file name that corresponds to the plaintext of the encrypted contents given in the previous column M.
Subsequently, columns O-R are focusing on the internal structure of a Protection Description box while
columns S-X describe the contents of a Replacement Description box, covering all the possible structures
depending on the replacement type. Finally, column Y 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
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.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Table D.1 — Definition of the JPEG Privacy & Security reference dataset description.
Column Num- NULL value
Column Name Column Description
ber 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
expressed 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-
fied per the ISO/IEC 19566-5 standard.
F Label String value included in the Description box. It Yes
corresponds to the “Label” field as specified per
the ISO/IEC 19566-5 standard.
G ID Numerical value included in the Description box. Yes
It corresponds to the “Id” field as specified per
the ISO/IEC 19566-5 standard.
H SHA256HASH (filename) 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
per the ISO/IEC 19566-5 standard.
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 (filename) 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
Content type in ISO/IEC 19566-5 standard.
O Data The name of the file pointing to the bytestream Yes
included in a UUID Content type JUMBF box.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
TTabablele D D.11 ((ccoonnttiinnueuedd))
Column Num- NULL value
Column Name Column Description
ber allowed?
P Media Type String value included in the Embedded File Yes
Description box. It corresponds to the “Media
Type” field as specified per the ISO/IEC 19566-5
standard.
Q Filename String value included in the Embedded File Yes
Description box. It corresponds to the “FILE
NAME” field as specified per the ISO/IEC 19566-
5 standard.
R Is Externally Referenced? Boolean value included in the Embedded File Yes
Description box. It corresponds to the “External
Reference” field as specified per the ISO/IEC
19566-5 standard.
S Expected file (filename) 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
parser information can extract from a JUMBF file in the context of ISO/IEC 19566-4. The columns of this csv
file are different from the reference dataset description file and their definition is listed in Table D.2.
Table D.2 — Definition of the JPEG Privacy & Security reference dataset report.
Column Num- NULL value
Column Name Column Description
ber 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 Numberical value of LBox attribute in JUMBF No
header.
D XLBox Numberical value of LBox 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
specified per the ISO/IEC 19566-5 standard.
G Is requestable Boolean value that specifies whether the parsed No
JUMBF Box is requestable. It corresponds to the
“Requestable” field as specified per the ISO/IEC
19566-5 standard.
H Label String value specifying the Label field included in Yes
the parsed Description box. It corresponds to the
“Label” field as specified per the ISO/IEC 19566-
5 standard.
I ID Numerical value specifying the ID field included Yes
in the parsed Description box. It corresponds to
the “ID” field as specified per the ISO/IEC 19566-
5 standard.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
TTabablele D D.22 ((ccoonnttiinnueuedd))
Column Num- NULL value
Column Name Column Description
ber allowed?
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-
fied per the ISO/IEC 19566-5 standard.
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 Yes
in the parsed UUID box. The 16-byte UUID field
is specified in the “UUID Content type” section of
the ISO/IEC 19566-5 standard.
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” section of the ISO/
IEC 19566-5 standard.
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” section of the
ISO/IEC 19566-5 standard.
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” section of the ISO/
IEC 19566-5 standard.
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”
section of the ISO/IEC 19566-5 standard.
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.
D.3 Validation procedure
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 with
ISO/IEC 19566-4. Specifically, this section uses the dataset introduced in D.2 and defines the validation
procedures for reference implementations in scope of ISO/IEC 19566-4 standard. The validation procedure
could be easily generalized for the all the JPEG Systems standards that are mentioned in this annex.
D.3.1 Parser validation
Figure D.1 shows the procedure of validating a candidate parser implementation. For a parser implementation
to check its conformance with ISO/IEC 19566-4, it can provide a report which describes the contents of a
JUMBF Box following the structure presented in the reference report.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Initially, the Privacy and Security 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 file) and it is compared with the Privacy and Security reference dataset report. Provided
that the two reports are identical, the candidate parser implementation is considered conformant to
ISO/IEC 19566-4.
Figure D.1 — Steps to show that a candidate parser implementation conforms to ISO/IEC 19566-5
standard.
D.2.3 Generator validation
Figure D.2 shows the procedure of validating a candidate generator implementation. For a generator
implementation to check its conformance with ISO/IEC 19566-4 it can reconstruct the available JUMBF
reference dataset, given the respective reference dataset description file.
Initially, the Privacy and Security reference dataset description is provided to the generator implementation
along with all the input files that are referenced in it. The candidate implementation parses 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
considered conformant to ISO/IEC 19566-4.
Figure D.2 — Steps to show that a candidate generator implementation conforms to ISO/IEC 19566-5
standard.
Annex E
Add the following new annex after Annex D:
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Annex E
(informative)
Privacy and security reference software: Java implementation
E.1 General
This annex describes a Reference Software implementation (identified as Implementation 2) for
ISO/IEC 19566-4 JPEG Systems — Part 4: Privacy and Security ISO/IEC 19566-4. This implementation has
been developed by extending the software presented in Annex B. Specifically, one of the main characteristics
of the presented multi-module project is its ability to support additional JUMBF Box structures defined in
other JPEG standards. Thus, this annex showcases how the functionality of the proposed JUMBF reference
software could be extended in order to support the JUMBF boxes defined in ISO/IEC 19566-4. This software
is called privsec-1.0. It is written in Java and it uses the functionalities presented in jumbf-2.0 library by
implementing the necessary classes in order to support Protection Content type and Replacement Content
type JUMBF Boxes. The following subsections are structured as follows: Subclause E.2 presents the software
implementation in a theoretical level, showcasing how Protection and Replacement Content type JUMBF
boxes are supported. Secondly, subclause E.3 specifies the requirements that are required to develop and
build from source the software. Finally, subclause E.4 demonstrates how the two applications presented in
Annex B.4 can be used in order to handle JUMBF information as specified in ISO/IEC 19566-4.
E.2 Software design
E.2.1 General
The software design presented in this subsection is based on the elements defined in Annex B.2. It
extends the Entity, Service and ContentType class hierarchies in order to support the new Box structures
and functionalities defined in ISO/IEC 19566-4, while using the required Box definitions (e.g., JUMBF Box
structure) as specified in ISO/IEC 19566-5.
E.2.2 Protection Content type JUMBF box
As per ISO/IEC 19566-4, a Protection box is defined as a JUMBF box with a new Content Type UUID consisting
of two Content Boxes, namely a Protection Description box and a Binary Data box. Consequently, the
jumbf-2.0 library needs to be extended in order to support the new Protection Description box Entity and
Service classes and define the new Protection Content Type box. First, regarding the Protection Description
box, a new Entity class is defined, namely ProtectionDescriptionBox, that specifies the fields defined in this
box based on the ISO/IEC 19566-4 standard. Thus, as shown in Figure E.1, the new ProtectionDescriptionBox
class needs to extend the BmffBox class.
Figure E.1 — Entity class hierarchy in privsec-1.0 for Protection Description box
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
The next step is to define the respective Service class that parses/generates the fields that reside in a
Protection Description box. Specifically, Figure E.2, illustrates how ProtectionDescriptionService class
extends the functionality of BmffBoxService class.
Figure E.2 — Service class hierarchy in privsec-1.0 for Protection Description box
As specified in Annex B, a ContentType class in jumbf-2.0 library provides the means to parse/generate the
content boxes of a JUMBF box. Depending on the Content Type UUID that resides in the Description box, the
JumbfBoxService class decides the proper ContentType class which handles the JUMBF Box Content Boxes.
The definition of the ProtectionContentType class is depicted in Figure E.3.
Figure E.3 — Content Type class hierarchy in privsec-1.0 for Protection Content type JUMBF box
E.2.3 Replacement Content type JUMBF box
This section focuses on the Replacement Content type JUMBF box definition supporting all the different
types of replacement defined in ISO/IEC 19566-4. In general, the Content Boxes of a Replacement Content
type JUMBF box are comprised of one Replacement Description Box and one or more Replacement Data
Boxes, depending on the type of replacement. Specifically, there are four different types of replacement:
— Box Replacement: Replacing a box referenced by either an offset or a label with a list of one or more
boxes specified in the Replacement Data Box section.
— APP Replacement: Replacing an APP marker segment that is referenced using the offset in the file with
the contents (i.e. one or more app segments) of exactly one * Replacement Data Box which is a Binary
Data box.
— ROI Replacement: Replacing a region of interest (ROI) — as specified by the corresponding offset — in the
parent image with the content of exactly one Replacement Data Box which is a Contiguous Codestream box.
— File Replacement: Replacing the entire file where this box resides with the content of exactly one
Replacement Data Box which is a Contiguous Codestream box.
First of all, a new box is defined, namely the Replacement Description box. Hence, a new class
ReplacementDescriptionBox is created extending the BmffBox class as shown in Figure E.4.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Figure E.4 — Entity class hierarchy in privsec-1.0 for Replacement Description box
Each replacement type defines a different set of parameters. However, since the resulting Replacement Content
type is the same for all replacement types (i.e. single Content Type UUID), a single ReplacementDescriptionBox
class is implemented. This class defines different parameter handler classes handling the parameters of
each replacement type. Thus, as shown at the bottom of Figure E.4, a field of type ParamHandlerInterface
is defined in the Replacement Description Box Entity class. These ParamHandlerInterface classes — apart
from specifying the exact parameters of each replacement type — provide the functionality to parse and
generate the specific parameter fields to bytes in order to be later included in the Replacement Description
box JUMBF structure. The class inheritance of the parameter handling classes is depicted in Figure E.5.
Figure E.5 — Class inheritance implementing the various parameters specified in a Replacement
Description box.
Similarly to the Protection Description box approach, the software specifies the methods that parse and
generate a Replacement Description box to a JUMBF structure. The ReplacementDescriptionBoxService
class is depicted in Figure E.6.
Figure E.6 — Service class hierarchy in privsec-1.0 for Replacement Description box.
Eventually, to define the new Replacement Content type, the class “ReplacementContentType” is specified
as shown in Figure E.7. As in the case of the Protection Content type, there are two services residing in the
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
ReplacementContentType class: the first one is responsible for handling the Replacement Description box
while the second one, namely DataBoxHandlerFactory class, provides the means to write the corresponding
Replacement Data Boxes according to the replacement type.
Figure E.7 — Content Type class hierarchy for privsec-1.0 (Replacement Content type JUMBF box)
Specifically, the DataBoxHandler interface (Figure E.8) provides the means to parse/generate the
Replacement Data Boxes of each replacement type. For the selection of the correct DataBoxHandler, a new
DataBoxHandlerFactory class is defined that act based on the replacementTypeId field provided by the
Replacement Description box. For each DataBoxHandler class there is a service field assigned. From the
enumeration of the various Replacement Data Boxes at the beginning of this subsection, it is clear that the
required Content Boxes are already implemented in jumbf-2.0 library. Thus, the services to parse/generate
the Replacement Data Boxes have already been defined and each DataBoxHandler class needs to invoke the
correct jumbf-2.0 class.
Figure E.8 — Class inheritance implementing the possible Content Boxes in a Replacement
Description box.
E.2.4 Software dependencies
As stated in the introduction of this annex, the privsec-1.0 library depends on the jumbf-2.0 library presented
in Annex B. The latter library has been designed in a way that no additional requirements are required for
the support of the Protection and Replacement Content type JUMBF boxes. The privsec-1.0 library has as
a single dependency, namely the jumbf-2.0 library. Thus, no more third-party dependencies are required
except from the ones listed in Subclause B.2.4.
E.3 Applications
This section presents how the CLI applications presented in B.3 is extended in order to support the JUMBF
Boxes of ISO/IEC 19566-4. Specifically, it is demonstrated how a new template “part4” is developed to support
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
the consumption of the reference dataset description as well as the production of a reference dataset report
in the context of JPEG Privacy and Security.
E.3.1 Command line interface
The application presented in B.3.1 is extended in order to support the JUMBF Boxes specified in
ISO/IEC 19566-4. This gives a user the ability to generate and parse any Privacy and Security related
JUMBF Box from a Unix system. For the CLI application to support the JPEG Privacy and Security Boxes,
the dependencies are updated in order to include the privsec-1.0 library. No other dependency is required
since the library introduces jumbf-2.0 as a transient dependency. Hence, the CLI application is able to handle
JUMBF Boxes from both ISO/IEC 19566-5 and ISO/IEC 19566-4.
To extend the existing CLI application to support JUMBF Boxes according to ISO/IEC 19566-4 standard, a
new template “part4” is implemented. When this template is provided as a command line parameter, the
CLI application parses and generates JUMBF Boxes according to input files which provide the required
information by the JPEG Privacy and Security reference dataset description (Table D.1) and report (Table D.2)
files. To perform the generation of JPEG Privacy and Security related JUMBF Boxes a user specifies the
“part4” template and specify the path pointing to the directory where all the input files (e.g., the ciphertext
and the plaintext of a content to be included in a Protection Content type JUMBF box) are located and are
referenced by the JPEG Privacy and Security reference description file. Along with these parameters the
user specifies the directory where the produced results are stored. An execution of the CLI application is
presented in Figure E.11.
Figure E.9 — Command line to generate Privacy and Security data
In parallel, it is possible to parse JUMBF Boxes related to ISO/IEC 19566-4 using the following command
(Figure E.12). By specifying the template as “part4”, the CLI application understands that the generated
report is aligned with the JPEG Privacy and Security reference dataset report.
Figure E.10 — Command line to parse Privacy and Security data
In the example presented above, the report is eventually stored in the “privsec_report.csv” file. The contents
of this report provide information about the value of a field. In the case of binary data, the size of the related
content is reported instead. Each column of this report file is aligned with the definition presented in
Table D.2.
Annex F
Add the following new annex after Annex E:
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19566-10:2024/Amd. 1:2025(en)
Annex F
(informative)
Validation of ISO/IEC 19566-6 reference software
F.1 Introduction
This annex describes the validation process that is followed in order to verify the correctness of
ISO/IEC 19566-6 reference software implementations. Two independent procedures are identified: one
for parser and one for generator applications. One core component of these procedures is the JPEG 360
reference dataset, which is presented as part of the JPEG Systems reference dataset. In principle, any
reference implementation presented in this document can parse/generate the reference files of the related
JPEG Systems stand
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...