ISO/IEC 21794-5:2024

International
Standard
ISO/IEC 21794-5
First edition
Information technology —
2024-11
Plenoptic image coding system
(JPEG Pleno) —
Part 5:
Holography
Technologies de l'information — Système de codage d'images
plénoptiques (JPEG Pleno) —
Partie 5: Holographie
Reference number
© ISO/IEC 2024
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 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 2
4.1 Symbols .2
4.2 Abbreviated terms .3
5 Conventions . 4
5.1 Naming conventions for numerical values .4
5.2 Operators .4
5.2.1 Arithmetic operators .4
5.2.2 Logical operators .5
5.2.3 Relational operators .5
5.2.4 Precedence order of operators .5
5.2.5 Mathematical functions .6
6 Representation of digital holograms . 6
6.1 Digital holograms and their signal properties .6
6.2 Functional overview of the decoding process .8
6.3 Encoder requirements .9
6.4 Decoder requirements .9
Annex A (normative) JPEG Pleno Holography superbox . 10
Annex B (normative) JPEG Pleno Holography codestream syntax .16
Annex C (normative) Non-binary lossy coding .25
Annex D (normative) Binary lossless coding . .33
Annex E (normative) Hologram tiling .37
Annex F (normative) Light propagation models .44
Annex G (normative) Short-time Fourier transform . 47
Annex H (normative) Quantization .49
Annex I (normative) Arithmetic coding .53
Annex J (informative) Rate-distortion optimization .57
Bibliography .65

© ISO/IEC 2024 – 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.
A list of all parts in the ISO/IEC 21794 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 2024 – All rights reserved
iv
Introduction
This document is part of a series of standards for a system known as JPEG Pleno and defines JPEG Pleno
Holography. It specifies a codec mechanism for holographic modalities and associated codestream syntax
and file format elements. JPEG Pleno Holography allows for efficient compression of holograms for a wide
range of applications such as holographic microscopy, tomography, interferometry, printing and display
and their associated hologram types. Key functionalities include support for both lossy and lossless coding,
scalability, random access, and integration within the system architecture of the JPEG Pleno framework.

© ISO/IEC 2024 – All rights reserved
v
International Standard ISO/IEC 21794-5:2024(en)
Information technology — Plenoptic image coding system
(JPEG Pleno) —
Part 5:
Holography
1 Scope
This document defines the syntax and an accompanying decompression process that is capable of
representing binary and continuous-tone holograms while supporting one or multiple color/spectral
components. The supported compression mechanisms are lossless for binary holograms and lossy for
continuous-tone holograms. Additional information on the encoding tools is provided as well. The document
also defines extensions to the JPEG Pleno File Format and associated metadata descriptors specific to
holographic modalities.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 21794-1:2020, Information technology — Plenoptic image coding system (JPEG Pleno) — Part 1:
Framework
ISO/IEC 21794-2:2021, Information technology — Plenoptic image coding system (JPEG Pleno) — Part 2: Light
field coding
ISO/IEC 21794-3, Information technology — Plenoptic image coding system (JPEG Pleno) — Part 3:
Conformance testing
ISO/IEC 21794-4, Information technology — Plenoptic image coding system (JPEG Pleno) — Part 4: Reference
software
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 21794-1, ISO/IEC 21794-2,
ISO/IEC 21794-3, ISO/IEC 21794-4 and the following 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/ ui
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
holography
technique based on coherent light allowing for the recording and reconstruction of a wavefront, thereby
encoding three-dimensional information about objects
Note 1 to entry: This has many applications, including 3D display technology, microscopy, tomography, interferometry,
telecommunications, data storage, and non-destructive testing.

© ISO/IEC 2024 – All rights reserved
3.2
hologram
two-dimensional representation of the complex-valued coherent wavefield of light encoding an interference
pattern describing the amplitude and phase of the scalar wavefield
Note 1 to entry: This pattern may be encoded directly in the spatial domain or indirectly using optical transformations
such as Fourier-transforming lens systems, magnification, or modulation.
3.3
digital hologram
one or more two-dimensional arrays of coefficients representing the sampled coherent wavefield of light
3.4
tile
a spatial segment of a digital hologram, each coded independently
3.5
window block
unit of a series of 2D windows over the propagated hologram’s input coefficients, corresponding to 2D
contiguous subsets of input coefficients and serving as input for the STFT
3.6
transform block
coefficient set resulting from applying a transform to a tile
3.7
code block
input coefficient set of the arithmetic coding within a transform block, where each code block is
independently arithmetically encoded
3.8
quantization block
unit of quantization within a code block
3.9
transform size
4-tuple of positive integers, describing the number of elements along each dimension of the entire set of
coefficients after applying the transform step, which is represented by a 4D array
3.10
source hologram
uncompressed input hologram
3.11
decoded hologram
output decompressed hologram decoded back into raw hologram samples
4 Symbols and abbreviated terms
4.1 Symbols
H Digital hologram
th
λ The wavelength of the i colour channel at which the hologram was recorded or generated
i
⊙ Hadamard product
−1
Forward and reverse two-dimensional Fourier transform
 , 
© ISO/IEC 2024 – All rights reserved
−1
Forward and reverse two-dimensional FFTSHIFT operator. This operation rearranges
S , S
Fourier transform coefficients by shifting the zero-frequency component to the centre of
the array, matching its conventional mathematical representation.
th
H I monochrome component of the digital hologram H; Corresponds to λ .
i I
p Hologram pixel pitch sampled on a square lattice
d Distance parameter for propagation operator
x, y Symbols for the first and second spatial dimensions
ff,
Symbols for the first and second frequency dimensions
xy
NT
Number of tiles
NCB
Number of code blocks per tile
NQB
Number of quantization blocks per tile
XThoc , YThoc
Tile x and y dimensions
XTcodY,, Tcod
Power of 2 exponents of the four-dimensional transform block dimensions
UTcodV, Tcod
XCBcod ,, YCBcod
Power of 2 exponents of the four-dimensional code block dimensions
UCBcod , VCBcod
XQBcod ,, YQBcod
Power of 2 exponents of the four-dimensional quantization block dimensions
UQBcod , VQBcod
−1
Mid-rise quantizer and dequantizer
Q, Q
Λ , Λ
Lagrangian multipliers for systems 1 and 2, respectively
4.2 Abbreviated terms
2D Two-dimensional
4D Four-dimensional
CB Code block
CBP Code block payload
DFT Discrete Fourier transform
FFTSHIFT Fourier transform coefficient shifting operator
L2 Euclidean norm
MRQ Mid-rise quantizer
MRDQ Mid-rise dequantizer
QB Quantization block
QBP Quantization block payload
RDO Rate-distortion optimization

© ISO/IEC 2024 – All rights reserved
SNR Signal-to-noise ratio
STFT Short-time Fourier transform
TB Transform block
5 Conventions
5.1 Naming conventions for numerical values
Integer numbers are expressed as bit patterns, hexadecimal values, or decimal numbers. Bit patterns and
hexadecimal values have both a numerical value and an associated length in bits.
Hexadecimal notation, indicated by prefixing the hexadecimal number with "0x", may be used instead of
binary notation to denote a bit pattern having a length that is an integer multiple of 4. For example, 0x41
represents an eight-bit pattern with only its second most significant bit and its least significant bit equal
to 1. Numerical values that are specified under a "Code" heading in tables that are referred to as "code tables"
are bit pattern values (specified as a string of digits equal to 0 or 1 in which the left-most bit is considered
the most significant bit). Other numerical values not prefixed by "0x" are decimal values. When used in
expressions, a hexadecimal value is interpreted as having a value equal to the value of the corresponding bit
pattern evaluated as a binary representation of an unsigned integer (i.e. as the value of the number formed
by prefixing the bit pattern with a sign bit equal to 0 and interpreting the result as a two's complement
representation of an integer value). For example, the hexadecimal value 0xF is equivalent to the 4-bit pattern
'1111' and is interpreted in expressions as being equal to the decimal number 15.
5.2 Operators
NOTE Many of the operators in this document are similar to those in the C programming language.
5.2.1 Arithmetic operators
+ Addition
− subtraction (as a binary operator) or negation (as a unary prefix operator)
× Multiplication
/ division without truncation or rounding
s
<< left shift; x< s
>> right shift; x>>s is defined as ⎿x/2 ⏌
++ increment with 1
-- decrement with 1
umod Unsigned modulo operator; x umod a is the unique value y between 0 and a–1
for which y+Na = x with a suitable integer N
& bitwise AND operator; compares each bit of the first operand to the corresponding bit of
the second operand
If both bits are 1, the corresponding result bit is set to 1. Otherwise, the corresponding result
bit is set to 0.
© ISO/IEC 2024 – All rights reserved
^ bitwise XOR operator; compares each bit of the first operand to the corresponding bit of the
second operand
If both bits are equal, the corresponding result bit is set to 0. Otherwise, the corresponding
result bit is set to 1.
5.2.2 Logical operators
|| logical OR
&& logical AND
! logical NOT
5.2.3 Relational operators
> greater than
>= greater than or equal to
< less than
<= less than or equal to
== equal to
!= not equal to
5.2.4 Precedence order of operators
Operators are listed in descending order of precedence. If several operators appear in the same line,
they have equal precedence. When several operators of equal precedence appear at the same level in an
expression, evaluation proceeds according to the associativity of the operator, either from right to left or
from left to right.
Operators Type of operation Associativity
() Expression left to right
[] indexing of arrays left to right
++, -- increment, decrement left to right
!, – logical not, unary negation
×, / multiplication, division left to right
umod unsigned modulo (remainder) left to right
+, − addition and subtraction left to right
& bitwise AND left to right
^ bitwise XOR left to right
&& logical AND left to right
|| logical OR left to right
<<, >> left shift and right shift left to right

© ISO/IEC 2024 – All rights reserved
< , >, <=, >= Relational left to right
5.2.5 Mathematical functions
|x| absolute value, is –x for x < 0, otherwise x
sign(x) sign of x, zero if x is zero, +1 if x is positive, -1 if x is negative
clamp(x,min,max) clamps x to the range [min,max]: returns min if x < min, max if x > max or oth-
erwise x
⎾x⏋ ceiling of x; returns the smallest integer that is greater than or equal to x
⎿x⏌ floor of x; returns the largest integer that is less than or equal to x
⎿x⏋ rounding of x to the nearest integer, equivalent to
6 Representation of digital holograms
6.1 Digital holograms and their signal properties
Like conventional images, holograms can be optically recorded, computer-generated, or some hybrid
thereof. A classic holographic recording setup utilizes interferometry, where a coherent, monochromatic
light beam is split into a reference beam and an object beam. Only the object beam will illuminate the sample
to be imaged, after which both beams are recombined, forming an interference pattern (cf. Figure 1). This
pattern encodes the complex-valued amplitudes of the object wavefront, thus describing both the wavefront
amplitude and phase. Alternatively, one can utilize numerical diffraction simulations in virtual objects and
scenes to compute the hologram pattern, called computer-generated holography. Although this approach
is not limited by the physics of an optical setup, such as geometrical constraints or optical component
nonidealities, it tends to require significant computational resources to calculate.
Key
1 laser
2 beam expander
3 beam splitter
4 mirror
5 reference beam
6 object beam
7 sample
8 image sensor
Figure 1 — Simplified diagram of a holographic recording setup, in case of a transparent sample,
with corresponding legend.
© ISO/IEC 2024 – All rights reserved
However, holography is often confused with other display techniques that do not involve interference. Many
systems that claim to be "holographic" consist of various projection systems that display flat images in mid-
air, using, for example, semi-transparent screens. These "false holograms" are produced by technologies
such as Pepper's ghost illusion (or its modern variants), lenticular printing, and volumetric displays. These
technologies are not addressed in this standard.
Holograms and discrete light fields (hereupon just called "light fields") are closely related, as both
representations encode spatial and angular information. A full-parallax light field can be represented by a 4D
array of rectilinear samples with two spatial and two angular dimensions, as specified in ISO/IEC 21794-2.
Because of the discrete sampling, light fields will have a discretized motion parallax and limited depth cues,
but they will have fewer samples than a hologram to cover the same spatio-angular range and work with
incoherent light. In contrast, holograms can account for all human visual cues, including continuous motion
parallax and exact eye-focusing cues.
In holography, frequency components correspond to plane waves whose propagation angle is proportional
to the frequency magnitude. Thus, one can characterize the relationship to light fields by looking at phase
space, jointly representing space and frequency data using, e.g., a spectrogram. (cf. Figure 2). This matches
closely with the spatio-angular phase space of 4D light fields.
This relationship was the primary rationale for utilizing the short-time Fourier transform for hologram
compression in this specification. The size of the transform window will dictate the trade-off between
spatial and angular resolution.
a) 3D scene with numbered (coloured) objects, creat- b) corresponding spatio-frequency phase diagram,
ing a hologram in the x-y plane, analyzing the signal with matching numbered (coloured) footprints in
along the dashed horizontal line phase space
Key
X space
v frequency
Figure 2 — Relationship between objects in 3D space and the phase space representation.
The hologram sample values are represented by discretized two-dimensional arrays of coefficients. These
coefficients may encode the complex-valued amplitudes in whole or in part, for example, by only encoding
the phase, the real part, or the amplitude of the complex coefficients. Moreover, the hologram coefficients
may have different levels of precision, ranging from floating-point numbers down to 1 bit per pixel, denoted
as "binary holograms."
© ISO/IEC 2024 – All rights reserved
A hologram consists of one or more arrays with the same dimensions, denoted "channels," representing
different colour components. Every channel may have different wavelengths and pixel pitches.
6.2 Functional overview of the decoding process
This document specifies the JPEG Pleno Holography superbox and the JPEG Pleno Holography decoding
algorithm. These are detailed in the annexes; the status of Annexes A to I is normative, while the status of
Annex J is informative. The generic JPEG Pleno Holography superbox syntax is specified in Annex A.
The overall architecture of JPEG Pleno Holography (Figure 3) provides the flexibility to configure the
encoding and decoding system depending on the requirements of the addressed use case.
Figure 3 — General JPEG Pleno Holography decoder architecture
As can be seen in Figure 3, each annex provides information about the individual components of the codec
architecture. Annex A provides a description of the JPEG Pleno Holography superbox and its composing
boxes. The codestream syntax issued in this specification is specified in Annex B. Subsequently, Annex E
describes the tiling mechanism issued to handle potentially large binary and non-binary holograms.
The annexes specific to the encoding/decoding of non-binary holograms are:
— Annex C gives a general overview of the non-binary lossy coding pipeline
— To enable the propagation of the hologram to a more suitable plane for compression Annex F specifies
several supported propagation models.

© ISO/IEC 2024 – All rights reserved
— Annex G specifies the short-time Fourier transform (STFT).
— Quantization mechanisms are specified in Annex H.
— Annex I describes the context-based arithmetic codec.
— Finally, Annex J illustrates how rate-distortion optimization can be implemented.
The module specific to the encoding and decoding of binary holograms is described in Annex D, particularly
focused on the Bayesian context-based arithmetic (de)coding mechanism.
6.3 Encoder requirements
An encoding process converts source hologram data to coded hologram data.
To conform with this document, an encoder shall conform with the file format syntax and codestream
format syntax specified, respectively, in Annex A and Annex B for the encoding process(es) embodied by the
encoder.
6.4 Decoder requirements
A decoding process converts coded hologram data to decoded hologram data. The resulting data may or may
not be perfectly reconstructed depending on whether the lossless coding mode was used. Annex E through
Annex I describe and specify the decoding process.
A decoder is an embodiment of the decoding process. To conform to this document, a decoder shall convert
all, or specific parts of, any coded hologram data that conform to the file format syntax and codestream
syntax specified, respectively, in Annex A and Annex B to a decoded hologram.

© ISO/IEC 2024 – All rights reserved
Annex A
(normative)
JPEG Pleno Holography superbox
A.1 General
This annex specifies the use of the JPEG Pleno Holography superbox, which is designed to contain compressed
holographic data and associated metadata. The listed boxes shall comply with their definitions as specified
in ISO/IEC 21794-1 and ISO/IEC 21794-2.
This document may redefine the binary structure of some boxes defined as part of the ISO/IEC 15444-1 or
ISO/IEC 15444-2 file formats. For those boxes, the definition found in this document shall be used for all JPL
files (cf. ISO/IEC 21794-1:2020, Annex A).
A.2 Organization of the JPEG Pleno Holography superbox
Figure A.1 shows the hierarchical organization of the JPEG Pleno Holography superbox contained by a JPL
file. This illustration does not specify nor imply a specific order to these boxes. The file will often contain
several boxes of a particular box type. Each box's meaning depends on the placement and order of that
particular box within the file. This superbox comprises the JPEG Pleno Holography Header box containing
parameterization information about the hologram, such as size and wavelength parameters.

© ISO/IEC 2024 – All rights reserved
Figure A.1 — Hierarchical organization of a JPEG Pleno Holography superbox
Table A.1 lists all boxes defined as part of this document. Boxes defined as part of the ISO/IEC 15444-1 or
ISO/IEC 15444-2 file formats are not listed. A box that is listed in Table A.1 as “Required” shall exist within
all conforming JPL files. For the placement and restrictions on each box, see the relevant section defining
that box.
The IPR, XML, UUID and UUID boxes introduced in ISO/IEC 15444-1:2024, Annex A can be signalled, as well
at the level of the JPEG Pleno Holography box, to carry hologram-specific metadata.
A.3 Defined boxes
A.3.1 Overview
The boxes in Table A.1 shall properly be interpreted by all conforming readers. Each box conforms to the
standard structure defined in ISO/IEC 21794-1:2020, Annex A. The following clauses define the value of the
DBox field. It is assumed that the LBox, TBox, and XLBox fields exist for each box in the file as defined in
ISO/IEC 21794-1:2020, Annex A.

© ISO/IEC 2024 – All rights reserved
Table A.1 — Defined boxes
Box name Type Superbox Required? Comments
JPEG Pleno Holography ‘jpho’ Yes Yes This box contains a series of boxes that contain
box the encoded hologram, its parameterization
(0x6A70 6C66)
and associated metadata. (Defined in ISO/IEC
21794-1:2020, Annex A)
JPEG Pleno Holography 'jphh' Yes Yes This box contains generic information about the
Header box file, such as the number of components, bits per
(0x6A70 6C6C)
component and colour space.
Hologram Header box ‘hhdr’ No Yes This box contains fixed length generic infor-
mation about the hologram, such as hologram
(0x6C6C 6472)
dimensions, number of components, codec and
bits per component.
A.3.2 JPEG Pleno Holography Header box
A.3.2.1 General
Within a JPEG Pleno Holography superbox, there shall be one and only one JPEG Pleno Hologram Header
box. The JPEG Pleno Holography Header box contains generic information about the hologram, such as the
hologram size, number of components, and bits per component. This box is a superbox.
The JPEG Pleno Holography Header box may be located anywhere within the JPEG Pleno Holography superbox
but should be before the enclosed Contiguous Codestream box containing the hologram codestream.
The JPEG Pleno Holography Header box type shall be 'jphh' (0x6A70 6C6C).
This box contains several boxes. Other boxes may be defined in other documents and may be ignored by
conforming readers. Those boxes contained within the JPEG Pleno Holography Header box that are defined
within this document are shown in Figure A.2:
— The Hologram Header box specifies information about the hologram size, bit depth, and the number of
components. This box shall be the first box in the JPEG Pleno Holography Header box and is specified in
subclause A.3.2.2.
— The Bits Per Component box specifies the bit depth of the components in the file in cases where the bit
depth is not constant across all components. Its structure shall be as specified in ISO/IEC 15444-1.
— The Colour Specification boxes specify the colour space of the decompressed image. Their structures
shall be as specified in ISO/IEC 15444-2. There shall be at least one Colour Specification box within the
JPEG Pleno Header box. Using multiple Colour Specification boxes gives a decoder multiple optimization
or compatibility options for colour processing. These boxes may be found anywhere in the JPEG Pleno
Holography Header box, provided they come after the Holography Header box. All Colour Specification
boxes shall be contiguous within the JPEG Pleno Holography Header box.
— The Channel Definition box defines the channels in the image. Its structure shall be as specified in
ISO/IEC 15444-1. This box may be found anywhere in the JPEG Pleno Holography Header box, provided
that it comes after the Hologram Header box.

© ISO/IEC 2024 – All rights reserved
Key
hhdr Hologram Header box
bppc Bits Per Component box
i
colr Colour Specification boxes
cdef Channel Definition box
Figure A.2 — Organization of the contents of a JPEG Pleno Holography Header box
A.3.2.2 Hologram Header box
A.3.2.2.1 General
This box contains fixed-length generic information about the hologram field, such as hologram dimensions,
number of components, codec, and bits per component. The contents of the JPEG Pleno Holography Header
box shall start with a Hologram Header box. Instances of this box in other places in the file shall be ignored.
The length of the Hologram Header box shall be 24 bytes, including the box length and type fields. Much of the
information within the Hologram Header box is redundant, with information stored in the codestream itself.
All references to "the codestream" in the descriptions of fields in this Hologram Header box apply to the
codestream found in the first Contiguous Codestream box embedded in the current JPEG Pleno Holography
superbox. Files containing contradictory information between the Hologram Header box and the first
codestream are not conforming. However, readers may attempt to read these files by using the values within
the codestream.
The type of the Hologram Header box shall be ‘hhdr’ (0x6C6C 6472) and the contents of the box shall have
the format shown in Table A.3:
— Width (Xhoc): The value of this parameter indicates the width of the sample grid. This field is stored as
a 4-byte big-endian unsigned integer.
— Height (Yhoc): The value of this parameter indicates the height of the sample grid. This field is stored as
a 4-byte big-endian unsigned integer.
— Number of components (NC): This parameter specifies the number of components in the codestream
and is stored as a 2-byte big-endian unsigned integer. The value of this field shall be equal to the value of
the NC field in the HOC marker in the codestream (as defined in subclause B.5.3). If no Channel Definition
Box is available, the order of the components for colour images is R-G-B-Aux or Y-U-V-Aux.
— Type (Thoc): The value of this parameter indicates the hologram type. This field is stored as a 1-byte
big-endian unsigned integer. Legal values for this field are 0 if the hologram is real-valued (includes
amplitude-only), 1 if the hologram is complex-valued in Cartesian coordinates (real-imaginary), 2 if the
hologram is phase-only and 3 if the hologram is complex-valued in polar coordinates (amplitude-phase).
All other values are reserved for ISO/IEC use.
— Data type (DThoc): The value of this parameter indicates the hologram data type. This 8-bit field is
configured as ‘00TT00GG’, where every symbol denotes a different bit. TT=00 for signed integer values,
TT=01 for unsigned integer values, TT=10 for floating-point, and TT=11 for packed binary. In the case of
3+GG
floating-point values, the maximum exponent value equals 2 , where “GG” represents a 2-bit unsigned
integer. All other values are reserved for ISO/IEC use (Table A.4).
— BPC: This parameter specifies the bit depth of the components in the codestream, minus 1, and is stored
as a 1-byte field (Table A.5). The low 7 bits of the value indicate the bit depth of the components. The high-
bit indicates whether the components are signed or unsigned. If the high-bit is 1, then the components
contain signed values. If the high-bit is 0, then the components contain unsigned values. If the components

© ISO/IEC 2024 – All rights reserved
vary in bit depth or sign, or both, then the value of this field shall be 255, and the Hologram Header box
shall also contain a Bits Per Component box defining the bit depth of each component (as defined in
subclause A.3.2.2.1).
— C: This parameter specifies the coding algorithm used to compress the hologram data. It is encoded as a
1-byte unsigned integer. It the value is 0, the ISO/IEC 21794-5 codec is used. All other values are reserved
for ISO/IEC use.
— UnkC: This field specifies if the actual colour space of the hologram data in the codestream is known.
This field is encoded as a 1-byte unsigned integer. Legal values for this field are 0 if the colour space of the
hologram is known and correctly specified in the Colour Space Specification boxes within the file or 1 if
the colour space of the hologram is not known. A value of 1 will be used in cases such as the transcoding
of legacy holograms where the actual colour space of the image data is not known. In these cases, while
the colour space interpretation methods specified in the file may not accurately reproduce the hologram
with respect to an original, the hologram should be treated as if the methods do accurately reproduce
the hologram. Values other than 0 and 1 are reserved for ISO/IEC use.
— IPR: This parameter indicates whether this JPL file contains intellectual property rights information
related to the holographic content. If the value of this field is 0, this file does not contain rights information,
and thus the file does not contain an IPR box. If the value is 1, then the file does contain rights information
and thus does contain an IPR box as defined in ISO/IEC 15444-1. Other values are reserved for ISO/IEC use.
Table A.3 — Format of the contents of the Hologram Header box
Field name Size (bits) Value
WIDTH 32 1 to (2 – 1)
HEIGHT 32 1 to (2 – 1)
Type 32 0
Data Type 32 See Table A.4
NC 16 1 to 16 384
BPC 8 See Table A.5
UnkC 8 0 to 1
IPR 8 0 to 1
Table A.4 — Data Type values
Values (bits)
Component sample precision
MSB LSB
x000 0000 Component bit depth = value + 1. From 1 bit deep to 38 bits
to deep respectively (counting the sign bit, if appropriate).
x010 0101
0xxx xxxx Components are unsigned values.
1xxx xxxx Components are signed values.
1111 1111 Components vary in bit depth.
All other values reserved for ISO/IEC use.

© ISO/IEC 2024 – All rights reserved
Table A.5 — BPC values
Values (bits)
Component sample precision
MSB LSB
00xx0000 8-bit datatype values
00xx0001 16-bit datatype values
00xx0010 32-bit datatype values
00xx0011 64-bit datatype values
000000xx Signed integer datatype values
000100xx Unsigned integer datatype values
001000xx Floating-point datatype values
001100xx Packed binary datatype values
All other values reserved for ISO/IEC use.

© ISO/IEC 2024 – All rights reserved
Annex B
(normative)
JPEG Pleno Holography codestream syntax
B.1 General
This section specifies the marker and marker segment syntax and semantics defined by this document.
These markers and marker segments provide codestream information for this document. Further, this
subclause provides a marker and marker segment syntax that is designed to be used in future specifications
that include this document as a normative reference.
This document does not include a definition of conformance. The parameter values of the syntax described
in this annex are not intended to portray the capabilities required to be compliant.
B.2 Markers, marker segments, and headers
This document uses markers and marker segments to delimit and signal the characteristics of the source
image and codestream. This set of markers and marker segments is the minimal information needed to
achieve the features of this document and is not a file format.
The main header is a collection of markers and marker segments. The main header is found at the beginning
of the codestream.
Every marker is 4 bytes long, using the “0xFFFFFFXX” pattern, where the last marker byte, “XX,” defines the
type of marker segment and can have any value in the range 0x01 to 0xFE.
A marker segment includes a marker and associated parameters, called marker segment parameters. When
a marker segment that is not specified in the document appears in a codestream, the decoder shall discard
the marker segment.
The proposed codec does not put any direct restrictions on the payload byte structure of the arithmetic
encoder. This maximizes flexibility and reduces average file sizes compared to, for example, ISO/IEC 15444-1
(JPEG 2000), which forbids the signalling of 0xFF bytes, thereby reducing average compression efficiency.
Figure B.1 — Marker segment manipulation.
Rarely, sequences of 3 or more subsequent 0xFF bytes may be signalled in the payload. To avoid the signalling
of spurious marker segments, an “escape sequence system” is introduced, as shown in the state machine
diagram illustrated in Figure B.1. To achieve this, the marker bytes 0x00 and 0xFF are reserved, and may
not be used as part of the 4-byte marker segment code.
Whenever 3 consecutive 0xFF bytes are encountered in the payload, the state machine will check for
escape bytes (state “≥3 #FF” in the diagram above). Any extra 0xFF bytes will be decoded as payload while

© ISO/IEC 2024 – All rights reserved
remaining in that same state. If the escape byte 0x00 is encountered, that 0x00 byte is skipped and will not
be considered part of the payload; the state machine then resets to its initial state “0 #FF”. If, however, any
other byte in the range 0x01-0xFE is encountered after at least 3 subsequent 0xFF bytes, the pattern will be
recognized as a 4-byte marker segment code.
Aside from avoiding spurious marker code signalling, it also allows for the efficient signalling of long 0xFF
sequences without additional coding cost, not requiring an extra 0x00 byte after every three 0xFF bytes.
Each marker segment is described in terms of its function, usage, and length. The function describes the
information contained in the marker segment. The usage describes this marker segment's logical location
and frequency in the codestream. The length describes which parameters determine the length of the
marker segment.
The marker segments are designated by the three-letter code of the marker associated with the marker
segment. The parameter symbols have capital letter designations followed by the marker's symbol in lower-
case letters. The remaining clauses in this annex describe the structure and meaning of each parameter in
every marker segment.
Every marker segment begins with a 32-bit marker code represented with the symbol MAR. Some marker
segments have an adaptive size, given by a size of the length parameter SLmar (Table B.1), followed by a
“length of marker segment” parameter. These are detailed in Table B.2. This SLmar marker is not mandatory
for every marker segment; only HOC, TPM, and CPM require SLmar.
After the list is a table that either describes the allowed parameter values or references other tables that
describe these values. Tables for individual parameters are provided to describe any parameter without a
simple numerical
...