Signal Processing - March 2016 - 121

gamma applied to the base and extension
layers respectively. U B has the objective
to linearize the base layer, while W B
intends to better distribute values closer
to zero in the extension layer. The scalar
v is an exposure parameter that scales
the luminance of the output image to
optimize the split between base and
extension layers.
Profile C also employs a sum to
merge base and extension images, but
here U C not only approximates an
inverse gamma transformation, but
implements a global inverse tone-mapping procedure that approximates the
(possibly local) tone-mapping operator
(TMO) that was used to create the LDR
image. The extension layer is encoded in
the logarithmic domain directly, avoiding
an additional transformation. Finally, log
and exp are substituted by piecewise linear approximations that are implicitly
defined by reinterpreting the bit-pattern
of the half-logarithmic IEEE representation of floating-point numbers as integers. It is then easily seen that this simple
"casting" between number formats
implements two functions } log and
} exp that behave approximately like
their precise mathematical counterparts,
though they provide the additional
advantage of being exactly invertible.
The reconstruction algorithm for profile
C can then be written:
t C (CB (x, y))
I (x, y) = } exp (U
+ RE (x, y) - 2 15 (1, 1, 1) T ), (3)
t C (x) = } log (U C (x)), in which
where U
U C is the global inverse tone-mapping
approximation. 2 15 is an offset shift to
make the extension image symmetric
around zero. The code stream never specifies U C directly, but rather includes a
t C in the form of a
representation of U
lookup-table, allowing to skip the timeconsuming computation of the logarithm.

Lossless coding
An important feature of profile C is that it
allows implementations operating entirely with integers until the very last step,
where the exponential generates floatingpoint output. All of these operations,
including the exponential mapping, are

exactly invertible. Part 8 of JPEG XT
defines now on this basis a lossless coding engine by fully specifying the DCT
in the base layer, and by bypassing the
DCT entirely in the extension layer. The
reader may now verify that the entire
operation chain has, indeed, an exact
inverse as the coding residual the decoder
requires for a given DCT and a given
base image is exactly predictable by the
encoder, and, hence, can be computed
ahead to generate exactly the required
sample values.

Transport
Residual coding and refinement coding
create additional code streams that need
to be incorporated into the legacy JPEG
syntax such that current decoders are
able to see only the legacy LDR image
and skip over the extension layers. A
JPEG XT code stream may thus contain
up to three side channels for image information: 1) a refinement code stream, 2) a
residual code stream, and 3) a residualrefinement code stream. Accounting for
the potential presence of an opacity layer,
as defined in Part 9 of the standard, up to
four additional code streams may be further included: 1) an alpha channel, 2) a
residual alpha channel, 3) an alpha channel refinement, and 4) a residual alpha
channel refinement. This information is
added to the metadata that configures the
postprocessing chain of the decoder.
The legacy JPEG syntax already
includes a generic extension mechanism
by using so-called application-specific
(APP) markers JPEG XT reserves one of
them. However, APP markers do not
carry the data directly. Instead, their payload consists of so-called boxes that yield
a better and cleaner structure of its contents. Boxes are not new to JPEG XT;
they were previously introduced by the
Moving Picture Experts Group (MPEG)
and JPEG 2000. The payload data of a
box is prefixed by a type and a size such
that decoders unaware of a specific box
type may simply ignore it. In summary,
the JPEG XT file format is a JPEG code
stream with APP markers whose contents, when reassembled at the decoder,
make up a single box, or a superbox containing multiple other boxes (Figure 3).
This is necessary because the capacity of
IEEE Signal Processing Magazine

March 2016

a single APP marker is limited to
64 Kbytes, whereas a box may be larger
and span across several APP markers.
Instructions describing how to assemble
markers into boxes is included in the first
bytes of the marker data itself. Legacy
decoders will simply skip over the markers, and will also ignore all boxes and
their data.
The payload data of the boxes
includes the metadata defining the postprocessor in the decoder or the entropycoded data of refinement and residual
code streams. The decoder picks out the
data it requires for its operation based on
the type signaled in the header of the box.

Testing and performances
The challenge of testing backward-compatible HDR compression is that the
compression performance does not
depend only on a single quality control
parameter, but also on the quality settings
for the base layer and on the choice of
the TMO, which produces this layer.
Therefore, the performance of JPEG XT
needs to be evaluated using a comprehensive set of varying parameters and on
a data set that covers a large set of standard's use cases.
The JPEG committee has carried out
a large number of experiments, using
both subjective and objective methodologies, to asses the capability of the JPEG
XT. A set of 12 objective quality metrics
were tested on 106 HDR images (resolutions range from full HD to 4K) covering
a high range of scenes typically captured
in HDR images, including indoor, outdoor scenes, architecture, landscapes,
portraits, frames from HDR video, and
computer-generated images. All images
were carefully selected by experts in
HDR imaging from these publicly available data sets: Fairchild's HDR Photographic Survey [8] and EPFL's data set of
HDR images [9].
Since a TMO can be freely selected
for encoding and its selection is not part
of JPEG XT specifications, we tested five
different commonly used operators: 1) a
simple gamma-based operator gamma,
2) a global logarithmic TMO [4]
drago03, 3) a global version of the photographic operator [10] reihard02, 4) an
operator optimized for encoding [11]
121

Table of Contents for the Digital Edition of Signal Processing - March 2016