ISO/IEC 15444-2:2004/Amd 3:2015

INTERNATIONAL  ISO/IEC
STANDARD 15444-2
First edition
2004-05-15
AMENDMENT 3
2015-07-15
Information technology — JPEG 2000
image coding system: Extensions
AMENDMENT 3: Box-based file format for
JPEG XR, extended ROI boxes, XML boxing,
compressed channel definition boxes, and
representation of floating point
Technologies de l’information — Système de codage d’images JPEG
2000: Extensions
AMENDEMENT 3: Format des fichiers basé sur les boîtes pour JPEG-
XR, boîtes de région d’intérêt (ROI) étendues, boîtes XML, boîtes de
définition des canaux comprimées et représentation des données à
virgule flottante
Reference number
ISO/IEC 15444-2:2004/Amd.3:2015(E)
©
ISO/IEC 2015
ISO/IEC 15444-2:2004/Amd.3:2015(E)

©  ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

ISO/IEC 15444-2:2004/Amd.3:2015(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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 3 to ISO/IEC 15444-2:2004 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 29 Coding of audio, picture, multimedia and hypermedia
information, in collaboration with ITU-T. The identical text is published as ITU-T Rec. T.801 (02/2002)/Amd.3.
© ISO/IEC 2015 – All rights reserved iii

ISO/IEC 15444-2:2004/Amd.3:2015(E)
INTERNATIONAL STANDARD
ISO/IEC 15444-2:2004/FDAM 3(E)
Rec. ITU-T T.801 (02/2002)/Amd.3(200X E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – JPEG 2000 IMAGE CODING SYSTEM:
EXTENSIONS
AMENDMENT 3:
Box-based file format for JPEG XR, extended ROI boxes, XML boxing, compressed channel
definition boxes, and representation of floating point
1) Clause 2 (References)
Add the following items to the list of normative references:
– ITU-T Recommendation T.805 | ISO/IEC 15444-6, Information technology - JPEG 2000 image coding
system - Part 6: Compound image file format
– ITU-T Recommendation T.45 Run-length Colour Encoding
– ITU-T Recommendation T.832 | ISO/IEC 29199-2, Information technology – JPEG XR image coding
system – Image coding specification
– IEC 60559 Binary floating-point arithmetic for microprocessor systems
– IEC 61966-2-2: Multimedia systems and equipment – Colour measurement and management – Part 2-2:
Colour management – Extended RGB colourspace - scRGB
– IEEE 754: IEEE Standard for Floating-Point Arithmetic
2) Subclause A.3.10 Nonlinearity point transformation (NLT)
Extend the description of the Lnlt syntax element by defining Lnlt to be 6 in case Tnlt equals 0 or 3.
Lnlt: Length of marker segment in bytes (not including the marker). The value of this parameter is
determined by the following equation:
 
 0 Tnlt 0 or Tnlt 3

Lnlt  6  15

 Tnlt 1

11  (N  ) 
 Tnlt 2
points Tval
PTval 1, 8
 1  


 

Tval 2 PTval 9, 16
 


PTval 17, 32
 

(A-7)
Change the description of the Tnlt syntax element to:
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 1

ISO/IEC 15444-2:2004/Amd.3:2015(E)
Tnlt: Non-linearity type. Table A-44 shows the value for the Tnlt parameter.
Replace Table A-44 by the following:
STnlt usage
Value (bits) Meaning of Tnlt values
MSB LSB
0000 0000 No non-linearity transformation applied -
0000 0001 Gamma-style non-linearity transformation Table A-45
0000 0010 LUT-style non-linearity transformation Table A-46
0000 0011 Binary Complement to Sign Magnitude Conversion -
All other values reserved -
3) Subclause A.3.13 Extended Capabilities
Replace Table A-49 in Subclause A.3.13 by the following (this is defined in AMD.2 of ITU.T 801 | 15444-2):
Parameter Size(bits) Value
CAP 16 0xFF50
Lcap 16 6-70
Pcap 32 TableA-50
i
Ccap 16 Value and meaning specified in
ITU.T Rec. 800+(k-1) | ISO/IEC
th
15444-k, where the i
non-zero bit in Pcap occurs in its
th
k most-significant bit
4) Subclause K.2 Non-linear transformation specifications
Replace K.2. by the following:
This Recommendation | International Standard allows for the non-linear transformation to be stored in three different
forms. The gamma-style non-linearity form specifies the transformation through parameters to an equation, and is
specified in subclause K.2.1. The LUT-style non-linearity form specifies the transformation by specifying a set of look
up table pairs and is specified in subclause K.2.2. The Binary Complement to Sign Magnitude Conversion transformation
takes no parameters, and converts the codestream-internal sample-representation from a binary complement
representation to a sign-magnitude representation. This conversion is most suitable for representing floating point data,
see subclause O.6 for further informationand its recommended use. The transformation itself is specified in subclause
K.2.3.
5) Subclause K.2.3 Binary complement to sign-magnitude conversion transformation
Add a new subclause K.2.3.:
If Tnlt equals 3, the data is processed by a transformation that changes the representation of negative sample values. This
type of transformation is most useful for representing IEC 60559 floating point data in JPEG 2000 bitstreams. The
integer sample values reconstructed from the codestream are then first converted from a binary complement to a sign-
magnitude representation using the transformation described below.
NOTE – This transformation is considered to map integer values to integer values, keeping the bit depth and signed-ness of the
samples untouched. While not required by this Recommendation | Standard, the resulting bit-patterns are, however, typically
interpreted as IEC 60559 floating point numbers by specifying a floating point sample type in the file format. This operation is not part
of the JPEG 2000 decoding process, but is a matter of interpreting the reconstructed samples correctly. It is recommended to use the
JPX file format defined in Annex M to annotate the data for proper interpretation. Further information on how to encode floating point
samples is found in subclause O.6.
2 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
If the binary complement to sign-magnitude conversion transformation is used, the bit-depth of the input samples to this
transformation shall be equal to the bit-depth of the samples generated by the transformation, and the signed-ness of the
input samples shall be equal to the signed-ness of the output samples. That is, the BDnlt value relevant to component i
shall be equal to either BDcbd if a multi-component transformation is run (see subclause A.3.6, Table A-31), or shall be
i
equal to Ssiz (see subclause A.5.1. of ITU-T Rec. T.800 | ISO/IEC 15444-1, Table A-11) if no such transformation is
i
used.
Let Z be the input sample value of the component i to which this transformation is to be applied, b its bit depth (i.e.
i i
b =(Ssiz AND 0x7f) +1 or b =(BDcbd AND 0x7f) + 1, and Y the output of the transformation. Then the transformation
i i i i i
is defined as:
Y =Z if Z ≥ 0 or
i i i
bi-1
Y =min (−2 − Z−1, −1) if Z <0
i i i
NOTE – This is intentionally the identity transformation for unsigned components. However, readers should be aware that if the level
shifting and/or inverse decorrelation transformation of Annex G of ITU-T Rec. T.800 | ISO/IEC 15444-1 is in effect, an additional DC
offset will be added to the reconstructed samples. This offset might be undesirable if the intent is to represent floating point data. To
prevent this DC offset, use mechanisms from this Recommendation | International Standard such as the Multiple Component
Transformation (MCC and MCO markers) from Annex J, or the Variable DC Offset described in Annex B. For signed components,
bi-1 bi-1
the transformation maps -1 to -2 and -2 to -1. The motivation for this transformation is given in subclause O.6.
6) Subclause M.2.6 – Storage of a codestream within JPX
Append the following text to the end of M.2.6:
The JPX file format also allows for multiple codestreams to be encapsulated within one or more Multiple Codestream
boxes, which contains indexing information to facilitate efficient retrieval of specific codestreams of interest, by
rendering and applications.
7) Subclause M.2.8 – Support for various pixel formats
Add a new subclause M.2.8 at the end of Clause M.2:
In ITU.T 800 | ISO/IEC 15444-1, channel values consisting of reconstructed image samples or palette entries were
always interpreted as signed or unsigned integers. The JPX Recommendation | International Standard extends this by
also allowing the representation of fixed point or floating point data. To this end, it introduces the Pixel Format Box (see
M.11.7.8) which defines how the values comprised of reconstructed image data or palette entries are to be interpreted as
numerical values. The understanding in ITU-T Rec. T.800 | ISO/IEC 15444-1 is that the codestream data encodes and the
palette contains signed or unsigned integer values, but this convention no longer holds in the presence of a Pixel Format
Box. If this box is present, the integer channel values are re-interpreted in two stages: In the first stage, the integer values
reconstructed from the codestream are represented as bit-patterns encoding integers in binary two's complement notation.
In the second stage, these bit patterns are re-interpreted as either integers, IEC 60559 floating point data or fixed point
data. Only after this interpretation, the samples are considered to define colour values relative to a colourspace.
NOTE – For most computer architectures, the first conversion stage is transparent and requires no additional operation, and the second
stage is usually realized as "casting" operation to the target type.
A non-integer pixel format is specified as follows: The desired sample format is encoded in a Pixel Format box (see
subclause M.11.7.8) which is a sub-box of the Compositing Layer Header box or the JP2 Header box. The total number
of bits required to represent samples in the requested format replaces the channel depth information of integer formats.
For example, IEC 60559 single precision floating point numbers require 32 bits for their representation; hence the
channel depth will be 32. This information is either recorded in the Image Header box (see subclause M.11.5.1) if the
channel depth is identical for all channels, or in the Bits Per Component box (see subclause M.11.5.2) if the channel
depth differs across channels. Furthermore, if the channel data is created indirectly through a palette, the channel depth
i
generated by the palette lookup process is indicated in the B field of the Palette box (see subclause I.5.3.4 of ITU-T Rec.
T.800 | ISO/IEC 15444-1) which then carries the relevant information for further sample interpretation.
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 3

ISO/IEC 15444-2:2004/Amd.3:2015(E)
The information on the total number of bits is augmented by information from the Pixel Format box if it is present. In
addition to the numerical representation of the samples in the channel it also refines the format by splitting the total
number of bits of a sample into integer and fractional, or exponent and mantissa bits. For fixed point data, the Pixel
Format box indicates the number of fractional bits, i.e. the number of bits right of the (binary) point, for floating point
data it indicates the mantissa bits of the floating point format, not including any implicit (hidden) bits. The number of
integer (non-fractional) or exponent bits can then be derived from the total number of bits per sample and the fractional
or mantissa bits. Further information on floating point number encodings are found in IEC 60559.
Fixed point and floating point samples are mapped to device colours by means of the Colour Specification box (see
subclause M.11.7.2) in the same way as integer samples are mapped to device colours. For that, the Channel Definition
box (see subclause M.11.7.5) defines which channels are used to generate which device colours. This process differs for
non-integer samples from integer samples only in so far as the maximum intensity of the device colour is no longer
represented by the maximum possible integer channel value, but as the value 1.0 expressed in the corresponding fixed
point or floating point format. The handling of sample values outside of this range is implementation specific. For further
information on the mapping from channel values to device colours, read subclause M.11.7.2.
8) Subclause M.2.9 – Support for JPEG XR codestreams
Add subclause M.2.9 at the end of Clause M.2:
This Recommendation | International Standard also allows the encapsulation of codestreams of other image compression
Recommendations | Standards, such as JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2); the JPX file format can
represent all metadata encoded in the TIFF-based file format of JPEG XR in boxes defined in this Recommendation |
International Standard. A recommendation of how the JPEG XR TIFF-based container should be mapped into the JPX
file format is found in subclause O.5.
The File Type Box of an ITU.T Rec. 802 | ISO/IEC 15444-2 file containing an ITU-T Rec. T.832 | ISO/IEC 29199-2
i
compliant codestream shall have the following values in the compatibility list CL (see ITU-T Rec. T.800 | ISO/IEC
15444-1, subclause I.5.2 and subclause M.11 in this Recommendation | International Standard) if JPEG XR codestreams
are present in the file:
Table M-1: Brand Values for JPEG XR Codestreams
Value Meaning
'jxrc' JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2)
compliant bitstream is present
'jxr0' JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) sub-
baseline profile bitstream present and the file conforms
to the JPEG XR sub-baseline profile defined in M.9.2.
'jxr1' JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2)
baseline profile bitstream present and the file conforms
to the JPEG XR baseline profile defined in M.9.2.
'jxr2' JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) main
profile bitstream present and the file conforms to the
JPEG XR main profile defined in M.9.2.
'jxr3' JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-3)
advanced profile bitstream and the file conforms to the
JPEG XR advanced profile defined in M.9.2.
NOTE - Brand values ‘jxr0’ to ‘jxr3’ indicate JPEG XR profiles of this Recommendation | International Standard. The corresponding
profiles are defined in Annex M.9.2.
Relabel tables M-1 through M-24 and all references thereto to M-2 through M-25.
4 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
9) Subclause M.5.2 – Sharing header and metadata information between codestreams and
compositing layers
Replace first paragraph:
To minimize file overhead, it is useful to allow header and metadata information to be shared between codestreams and
compositing layers where that information is identical. The JPX file format provides three mechanisms to share
information: default headers, cross-references and label associations.
with the following:
To minimize file overhead, it is useful to allow header and metadata information to be shared between codestreams and
compositing layers where that information is identical. The JPX file format provides four mechanisms to share
information: default headers, compositing layer extensions, cross-references and label associations.
Relabel subclause M.5.2.3 and all references thereto as M.5.2.4
Relabel subclause M.5.2.2 and all references thereto as M.5.2.3
Insert new subclause M.2.2.2 as follows:
M.5.2.2 Compositing layer extensions
The Compositing Layer Extensions box can be used to specify a repeating pattern of compositing layer headers and
(optionally) codestream headers.
A file which contains a Compositing Layer Extensions boxes can be meaningfully interpreted by readers which do not
understand the Compositing Layer Extensions box, because all top-level Codestream Header boxes and Compositing
Layer Header boxes shall precede any Compositing Layer Extensions box and all compositing instructions found within
a Compositions box shall refer only to top-level compositing layers. The Compositing Layer Extensions box may be
used only when there are a well-defined number of top-level codestream headers and top-level compositing layers, which
means that at least one Codestream Header box and at least one Compositing Layer Header box must appear at the top-
level of the file.
A Compositing Layer Extensions box defines one or more additional compositing layers, zero or more additional
codestream headers and zero or more additional compositing instructions, to augment the information provided by top-
level Codestream Header, Compositing Layer Header and Composition boxes.
Each Compositing Layer Extensions box has an associated repetition factor Mjclx. The Compositing Layer Extensions
box implicitly defines Mjclx  Cjclx additional codestream headers and Mjclx  Ljclx additional compositing layers,
where Cjclx and Ljclx are the number of Codestream Header boxes and the number of Compositing Layer Header boxes
that are found within the Compositing Layer Extensions box. The additional codestream headers and compositing
layers are assigned consecutive indices, starting from the number of codestream headers and compositing layers defined
by all top-level Codestream Header boxes and Compositing Layer Header boxes, together with all preceding
Compositing Layer Extensions boxes. The codestreams that are associated with the additional compositing layers are
determined from the information found in each embedded Compositing Layer Header box, using a codestream index
remapping procedure that accounts for the repetition index. A similar remapping procedure is applied to the Number
List boxes which may be found within a Compositing Layer Extensions box, so that embedded metadata is correctly
associated.
The principle purpose of Compositing Layer Extensions is to facilitate the efficient description of a large number of
compositing layers that follow a simple repeating pattern. This can be particularly beneficial if the JPX file is
communicated incrementally via the tools and methods described in IS15444-9.
Compositing Layer Extensions also provide a mechanism for extending the single animation described by a
Compositions box into multiple alternate presentation threads – see subclause M.5.3.
10) Subclause M.5.3 – Composition
Replace first paragraph:
Composition data is divided into fixed options, contained in the Composition Options box (subclause M.11.10.1), and a
sequence of instructions contained in one or more Instruction Set boxes (subclause M.11.10.2) boxes. Each instruction
comprises a set of render parameters. Each instruction set has an associated repeat count which allows for the efficient
representation of long sequences of repeating instructions such as occur in full motion sequences or in slide shows which
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 5

ISO/IEC 15444-2:2004/Amd.3:2015(E)
use a repeated frame transition animation. A JPX file reader shall display a JPX file by reading and executing the
instructions in sequence order, from each instruction set in sequence order and repeated according to its repeat value. The
file is considered fully rendered either when there are no more instructions to execute, or no compositing layer is present
for the current instruction.
with:
Composition data is divided into fixed options, contained in the Composition Options box (subclause M.11.10.1), and a
sequence of instructions contained in one or more Instruction Set boxes (subclause M.11.10.2) boxes. Instructions may
be further divided into those which appear within a top-level Composition box and those which appear within
Compositing Layer Extensions box. The former constitute the primary presentation, while the latter constitute
supplementary presentation threads.
Each instruction comprises a set of render parameters. Each instruction set has an associated repeat count which allows
for the efficient representation of long sequences of repeating instructions such as occur in full motion sequences or in
slide shows which use a repeated frame transition animation. A JPX file reader shall display a JPX file by reading and
executing the instructions in sequence order, from each instruction set in sequence order and repeated according to its
repeat value. The file is considered fully rendered either when there are no more instructions to execute, or no
compositing layer is present for the current instruction.
Instructions found within the top-level Composition box are applied only to top-level compositing layers (i.e.,
compositing layers other than those defined by Compositing Layer Extensions boxes). Instructions found within a
Compositing Layer Extensions box apply only to the compositing layers defined by that box.
11) Subclause M.9.2 – Support for JPX feature set boxes
Replace the entire subclause M.9.2 by the following:
In general, a JPX reader is not required to support the entire set of features defined within this Recommendation |
International Standard. However, to promote interoperability, five profiles are defined, of which the first defines a set of
baseline features required to decode images using codestream representations conforming to ITU.T 800 | ISO/IEC
15444-1 and ITU.T 801 | ISO/IEC 15444-2 only, and four additional profiles describing images containing only
codestreams conforming to ITU.T 832 | ISO/IEC 29199-2.
The ITU.T 80x | ISO/IEC 15444-x based profile is denoted JPX Baseline in the following; Files that are written in such
a way as to allow a reader that supports only this JPX baseline set of features to properly open the file shall contain a CLi
field in the File Type box with the value ‘jpxb’ (0x6a70 7862); all JPX baseline readers are required to properly support
all files with this code in the compatibility list in the File Type box. The definition of a JPX baseline file given in Annex
M.9.2.1 through M.9.2.9, the JPEG XR profiles based on 29199-2 codestreams are defined in Annex M.9.2.10 and
following:
12) Subclause M.9.2.10 – JPEG XR Profiles
Insert the following subclauses as Annex M.9.2.10 and following:
In addition to codestreams conforming to the ITU.T 80x | 15444-x series of Recommendations | Standards, a JPX file
may also include codestreams conforming to 29199-2 (JPEG XR), and four profiles are defined in the following closely
mirroring the profiles of 29199-2. The four profiles are denoted JPEG XR Sub-baseline Profile, JPEG XR Baseline
Profile, JPEG XR Main Profile, and JPEG XR Advanced Profile. All profiles have in common that files conforming
to these profiles shall only contain codestreams conforming to 29199-2.
i
Files conforming to the JPEG XR profiles shall contain a CL field in the File Type box with the values ‘jxr0’ through
‘jxr3’, according to the profiles the corresponding 29199-2 codestreams conform to; these compatibilities are defined in
Table M-1.
13) Subclause M.9.2.11 – Compression Type
Readers conforming to one of the four JPEG XR profiles only need to support the compression type C = 11 (JPEG XR)
indicated in the Image Header Box; see Table M-20 for all compression types defined in this Recommendation |
International Standard. Support for other compression types shall not be required to display a file conforming to one of
the four JPEG XR profiles.
6 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
14) Subclause M.9.2.12 – Compositing Layers
Support for multiple compositing layers is not required to properly display the file; however, the main file may contain
multiple compositing layers, but if so, only the first one need to be rendered by an implementation conforming to the
JPEG XR profiles. Compositing layers may consist of one or two codestreams that both shall conform to 29199-2. If a
compositing layer consists of two codestreams, the two codestreams shall describe images of the same size that are
aligned pixel by pixel, and the second codestream shall consist of a single component representing the opacity of the
samples encoded in the first codestream. If a second codestream is present in a compositing layer, the first codestream
shall not include any opacity information.
15) Subclause M.9.2.13 – Colour Specification
The first composting layer shall contain at least one Color Specification Box from the following list:
 The enumerated method EnumCS value indicating either sRGB, scRGB, sRGB-grey, scRGB-grey, bi-level
black on white or bi-level white on black for the JPEG XR baseline and JPEG XR sub-baseline profiles.
 In addition to the above, the enumerated method EnumCS value indicating CMYK or the Any ICC method for
the JPEG XR main profile.
 In addition to the above, the enumerated method EnumCS value indicating YCbCr(1) through YCbCr(3) for
the JPEG XR advanced profile.
16) Subclause M.9.2.14 – Codestream Fragmentation
The codestreams representing the data of the first compositing layer of files conforming to the JPEG XR profiles shall
not be fragmented.
17) Subclause M.9.2.15 – Cross Reference Boxes
Files conforming to the JPEG XR profiles shall not use Cross Reference Boxes for replacing boxes necessary to decode
the first compositing layer.
18) Subclause M.9.2.16 – JP2 Header Box Location
The JP2 Header box shall be found in the file before the first Contiguous Codestream box, and Compositing Layer
Header box. Any information contained within the JP2 Header box shall be applied to the codestreams encoding the first
compositing layer, and as well being used as default information for all other compositing layers; the boxes within the
JP2 Header box shall not be found within the Compositing Layer Header box or the Codestream Header box associated
with the first compositing layer.
19) Subclause M.9.2.17 – Opacity
A JPEG XR profile conforming reader shall properly interpret opacity channels, through either direct mapping to a
codestream component using the Channel Definition box. Other means of indicating opacity, e.g. by the Opacity box,
need not to be supported. The use of opacity outside of compositing layers within the JPX file indicates that the decoded
image data shall be composited onto an application defined background.
20) Subclause M.9.2.18 – Rotation
A JPEG XR conforming reader shall properly interpret the ROT field of the Instruction Set box defined in Annex
M.11.10.2 and Annex M.11.10.2.1. Other instructions defined in the Instruction Set box need not to be honored for
compliance to the JPEG XR profiles.
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 7

ISO/IEC 15444-2:2004/Amd.3:2015(E)
21) Subclause M.9.2.19 – Other Data in the File
A JPEG XR profile file may contain other features or metadata, provided they do not modify the visual appearance of the
still image as viewed using a reader that supports only the JPEG XR feature set. All JPX readers should be aware of the
existence of this data, as parsing or processing this data may be required in some extended applications. Applications that
understand other data or features in the file are encouraged to support the behaviors and functions associated with that
extended data.
22) Subclause M.9.2.20 – Conformance Testing
A conformance testing procedure for the JPEG XR profiles as well as test files suitable for conformance testing are
defined in ITU.T 834 | ISO/IEC 29199-4.
23) Subclause M.11 – Defined boxes
Edit Table M-6 (now Table M-7) as follows:
 Add the Pixel Format Box as sub-box to the JP2 Header Box and the Compositing Layer Header Box and add
a reference to M.11.7.8.
 Add the Compositing Layer Extensions box as a top-level box and add a reference to subclause M.11.21.
 Add the Compositing Layer Extensions Info box as a sub-box to the Compositing Layer Extensions box and
add a reference to subclause M.11.22.
 Add the Multiple Codestream as a top-level box and add a reference to subclause M.11.23. Add a codestream
box with reference to M.11.8 and a Fragment Table box with reference to M.11.3.
 Add the Multiple Codestream Info box as sub-box to the Multiple Codestream box and add a reference to
subclause M.11.24.
 Add the Grouping box as a top-level box and add a reference to subclause M.11.25. Add a sub-box labeled
"…" to this grouping box.
 Add a top-level asoc box to Table M-6 (now Table M-7) with a reference to M.11.11, add a Decomposed XML
box as its first sub-box and add a reference to subclause M.11.2.26. Add a second asoc box with reference to
M.11.11, and add a XML header box and a reference to subclause M.11.27 as its first sub-box, and a XML box
with reference to M.11.18 as its second sub-box.
24) Table M-13 – Boxes defined within this Recommendation | International Standard
Add the following rows to the table M-13 (now M-14):
Pixel Format box 'pxfm' NO This box specifies the interpretation of
(0x7078 666d) reconstructed sample values as integer,
(M.11.7.8)
fixed point or floating point numbers.
XML box (M.11.18) 'xml\040' NO This box contains XML formatted
(0x786D 6C20) information.
Compositing Layer 'jclx' NO This box defines an extended set of
Extensions box (M.11.21) (0x6A63 6C78) compositing layers, codestream headers
8 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
and compositing instructions.
Compositing Layer 'jlxi' NO This box provides information
Extensions Info box concerning the repetition factor,
(0x6A6C7869)
(M.11.22) compositing layer indices and other
attributes of the compositing layers and
compositing instructions found within
the Compositing Layer Extensions box.
Multiple Codestream box 'j2cx' NO This box represents a concatenated
(M.11.23) (0x6A32 6378) collection of one or more contiguous
codestream boxes or fragment table
boxes.
Multiple Codestream Info box 'j2ci' NO This box contains information
(M.11.24) (0x6A32 6369) describing the Multiple Codestream box
in which it is found.
Grouping box (M.11.25) 'grp\040' NO This superbox is a container (or
(0x6772 7020) wrapper) for any number of boxes
which might otherwise be found as the
non-initial sub-box of an Association
box.
Decomposed XML box 'dxml' (0x786D 6C64) NO This box provides provides front-matter
(M.11.26) from an XML document as part of a
mechanism for decomposing a single
XML document into a hierarchical
collection of Association boxes.
XML Header box (M.11.27) 'hxml' NO This box provides an element header
(0x786D 6C68) (the opening element tag with
attributes) as part of a mechanism for
decomposing a single XML document
into a hierarchical collection of
Association boxes.
25) Subclause M.11.1 – Reader Requirements box
Add the following rows to Table M-14 (now M-15):
Value Meaning
Codestream contains a JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) compliant bitstream.
Codestream contains a Sub-baseline profile JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) compliant
bitstream.
Codestream contains a Baseline profile JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) compliant
bitstream.
Codestream contains a Main profile JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) compliant
bitstream.
Codestream contains an Advanced profile JPEG XR (ITU-T Rec. T.832 | ISO/IEC 29199-2) compliant
bitstream.
Pixel format "Fixed Point" is used.
Pixel format "Floating Point" is used.
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 9

ISO/IEC 15444-2:2004/Amd.3:2015(E)
Pixel Formats "Mantissa" or "Exponent" are used.
Compositing layer uses IEC 61966-2-2 (scRGB) enumerated colourspace
Block Coder Extensions (see AMD.4 of ITU.T 801 | ISO/IEC 15444-2)
Compositing layer uses scRGB gray scale (IEC 61966-2-2 based) enumerated colourspace
26) Subclause M.11.3–Fragment Table box
Replace the first paragraph:
A Fragment Table box specifies the location of one of the codestreams in a JPX file. A file may contain zero or more
Fragment Table boxes. For the purpose of numbering codestreams, the Fragment Table box shall be considered
equivalent to a Contiguous Codestream box. Fragment Table boxes shall be found only at the top level of the file; they
shall not be found within a superbox.
With the following:
A Fragment Table box specifies the location of one of the codestreams in a JPX file. A file may contain zero or more
Fragment Table boxes. For the purpose of numbering codestreams, the Fragment Table box shall be considered
equivalent to a Contiguous Codestream box. Fragment Table boxes shall be found only at the top level of the file or
within Multiple Codestream boxes; they shall not be found within any other superboxes.
27) Subclause M.11.5.1– Image Header box
Replace paragraph 6, the description of the BPC field of the Image Header box, by the following:
BPC: Bits per component. This parameter identifies the bit depths and signed/unsigned characteristics of the fully
decompressed components, stored as a 1-byte field as defined in Table M-21. If the components vary in bit depth
or signed/unsigned characterisics, then the value of this field shall be 255, and the superbox that contains this
Image Header box (either the JP2 Header box, a Codestream Header box or Compositing Layer Extension Box)
shall contain a Bits Per Component box defining the bit depth and signed/unsigned characteristics of each
component. If all components have the same bit depth and signed/unsigned characteristics, the BPC parameter
identifies the bit depth and signed/unsigned characteristics for all components and has the same interpretation to
i
the BPC parameters, as explained in connection with the Bits Per Component box in subclause M.11.5.2.
Add the following row to table M-19 (now M-20), the definition of the compression type field C of the Image Header box:
10 ITU-T Rec. T.45 (run length coding, used in ITU-T Rec. T.805 | ISO/IEC 15444-6)
11 JPEG XR (as defined by ITU-T Rec. T.832 | ISO/IEC 29199-2)
Replace Table M-20 (now M-21), the description of the BPC field of the Image Header box by the following:
i
Table M-22 -- BPC and BPC parameters
Values (bits) Component Sample Format and Sample Precision
MSB  LSB
x000 0000
Component bit depth = value + 1. From 1 bit deep through 38 bits deep respectively
– (counting the sign bit, if appropriate)
x010 0101
10 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
0xxx xxxx Components are unsigned
1xxx xxxx
Components are signed
1111 1111
Component bit depths vary (Bits Per Component Box only)
all other values Reserved for future use
Replace in Table M-21(now Table M-22) the row describing the C field
C 8 7
by the following:
C 8 Compression Type, see Table M-20
28) Subclause M.11.5.2 – Bits Per Component box
Replace the definition of the Bits Per Component box by the following:
The Bits Per Component box specifies the bit depth and signed/unsigned characteristics of each fully decompressed
component, using a 1-byte field for each component, as defined in Table M-20. This box is optional and is only required
in case the bit depths varies between components.
This box encodes the number of bits required to represent the component sample values reconstructed from the
codestream, and the value shall match the bits per component specification in the respective codestream format
specification. The structure of this box is identical to that defined in subclause I.5.3.2 in the JP2 file format specified in
ITU-T Rec. T.800 | ISO/IEC 15444-1.
NOTE - For codestreams conforming to ITU-T Rec. T.80x | ISO/IEC 15444-x (JPEG 2000) this is the bit depths after any inverse
multiple component transformation or reverse non-linearity transformation extension has been applied to components in the
codestream. In case an extended ITU-T Rec. T.801 | ISO/IEC 15444-2 multiple component transformation is used, the component bit
depths does NOT necessarily match the data in the SIZ marker of the codestream. For fixed point and floating point pixel formats, the
numerical interpretation of the component sample values depends not only upon the bit depth and signed/unsigned characteristics
i
identified by BPC or BPC , but also on the number of fraction bits or mantissa bits, as supplied via the Pixel Format box. The Bits Per
Component box then only specifies the total number of bits required to represent the data and whether the data is signed or unsigned.
29) Subclause M.11.6 – Codestream Header box
Replace first three paragraphs:
The Codestream Header box specifies header and metadata information specific to a particular codestream contained
within the JPX file in order to create a set of channels. All Codestream Header boxes shall be located at the top-level of
the file (not within any superbox).
Both codestreams and Codestream Header boxes are numbered separately, starting with 0, by their order in the file.
Codestream Header box i shall be applied to codestream i. There shall either be one Codestream Header box in the file
for each codestream, or there shall be zero Codestream Header boxes in the file. In the event that there are zero
ITU-T Rec. T.801 (02/2002)/Amd.3:2015(E) 11

ISO/IEC 15444-2:2004/Amd.3:2015(E)
Codestream Header boxes, then the header information for all of the codestreams shall be taken to be the default header
information contained within the JP2 Header box.
For the codestreams, the numbering shall consider both Contiguous Codestream boxes and Fragment Table boxes. For
example, if a file contains 2 Contiguous Codestream boxes, followed by a Fragment Table box, followed by another
Contiguous Codestream box, the JPX file contains 4 codestreams, where the codestreams contained directly in the first
two Contiguous Codestream boxes are numbered 0 and 1, the codestream pointed to by the Fragment Table box is
numbered 2, and the codestream contained within the last Contiguous Codestream box is numbered 3.
with the following:
The Codestream Header box specifies header and metadata information for a codestream contained within the JPX file in
order to create a set of channels. All Codestream Header boxes shall be located either at the top-level of the file (not
within any superbox) or within a Compositing Layer Extensions box (see M.11.21). All top-level Codestream Header
boxes must precede any Compositing Layer Extensions boxes within the file.
Both codestreams and codestream headers are numbered separately, starting with 0. Codestream header i provides header
information for codestream i. Each top-level Codestream Header box corresponds to exactly one codestream header,
meaning that box i specifies header information for codestream i, starting from i=0. Each Codestream Header box
found within a Compositing Layer Extensions box corresponds to Mjclx additional codestream headers (for Mjclx
additional codestreams), where Mjclx is the repetition factor associated with the Compositing Layer Extensions box.
The determination of indices for these additional codestream headers is described in subclause M.11.21.
If Codestream Header boxes appear anywhere in the file, the number of codestreams found in the file shall be the same
as the number of available codestream headers. In the event that there are no Codestream Header boxes, then the header
information for all of the codestreams shall be taken to be the default header information contained within the JP2
Header box.
For the codestreams, the numbering shall consider Contiguous Codestream boxes, Fragment Table boxes and Multiple
Codestream boxes. For example, if a file contains two Contiguous Codestream boxes, followed by a Fragment Table
box, followed by another Contiguous Codestream box and two Multiple Codestream boxes, each with two codestreams,
the JPX file contains eight codestreams, where the codestreams contained directly in the first two Contiguous
Codestream boxes are numbered 0 and 1, the codestream pointed to by the Fragment Table box is numbered 2, the
codestream contained within the last Contiguous Codestream box is numbered 3, and the codestreams contained within
the first (respectively second) Multiple Codestream box are numbered 4 and 5 (respectively 6 and 7).
30) Subclause M.11.7 – Compositing Layer Header box
Replace first paragraph:
The Compositing Layer Header box specifies header and metadata information specific to a particular compositing layer
in the JPX file. Compositing layers are numbered, starting at 0, by the order in the file of the Compositing Layer Header
boxes (box i specifies header information for compositing layer i). There shall be one Compositing Layer Header box in
the file for each layer. All Compositing Layer Header boxes shall be located at the top-level of the file (not within any
superbox).
with the following:
The Compositing Layer Header box specifies header and metadata information for a compositing layer in the JPX file.
All Compositing Layer Header boxes shall be located either at the top-level of the file (not within any superbox) or
within a Compositing Layer Extensions box (see M.11.21). All top-level Compositing Layer Header boxes must
precede any Compositing Layer Extensions boxes within the file.
Each top-level Compositing Layer Header box corresponds to exactly one compositing layer, meaning that box i
specifies header information for layer i, where layers are numbered starting from i=0. Each Compositing Layer Header
box found within a Compositing Layer Extensions box corresponds to Mjclx additional compositing layers, where Mjclx
is the repetition factor associated with the Compositing Layer Extensions box. The indexing of these additional
compositing layers is described in subclause M.11.21.
Add a new paragraph in the list of allowable sub-boxes of the compositing layer header box below the resolution box:
12 Rec. ITU-T T.801 (02/2002)/Amd.3:2015(E)

ISO/IEC 15444-2:2004/Amd.3:2015(E)
pxfm: Pixel Format Box. This box defines the interpretation of the values in a channel as either integer, floating point
or fixed point values. In the absence of this optional box, the bit patterns shall be interpreted signed or unsigned
integers whose bit depths are either defined by the Bits Per Component Box, or th
...