ISO/IEC 19794-5:2011/Amd 2:2015

INTERNATIONAL ISO/IEC
STANDARD 19794-5
Second edition
2011-11-01
AMENDMENT 2
2015-11-15
Information technology — Biometric
data interchange formats —
Part 5:
Face image data
AMENDMENT 2: XML encoding and
clarification of defects
Technologies de l’information — Formats d’échange de données
biométriques —
Partie 5: Données d’image de la face
AMENDEMENT 2: Codage XML et précisions concernant les défauts
Reference number
ISO/IEC 19794-5:2011/Amd.2:2015(E)
©
ISO/IEC 2015
ISO/IEC 19794-5:2011/Amd.2: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 19794-5:2011/Amd.2: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.
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).
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. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT), see the following URL: Foreword — Supplementary information.
Amendment 2 to ISO/IEC 19794–5:2011 was prepared by ISO/IEC JTC 1, Information Technology,
Subcommittee SC 37, Biometrics.
© ISO/IEC 2015 – All rights reserved iii

ISO/IEC 19794-5:2011/Amd.2:2015(E)
Information technology — Biometric data interchange
formats —
Part 5:
Face image data
AMENDMENT 2: XML encoding and clarification of defects
Page 1, Conformance
Insert the following text as second paragraph:
An XML document conforms to this part of ISO/IEC 19794 if it satisfies the format requirements with
respect to its structure, with respect to relations among its fields, and with respect to relations between
its fields and the underlying input that are specified within Annex F of this part of ISO/IEC 19794.

Page 2, Normative references
Add the following URL as the last item in Clause 3:
XML Schema: http://www.w3.org/XML/Schema.html

Page v, ISO/IEC 19794–5:2011/Amd 1:2014, Introduction
Add the following paragraph after the last paragraph:
Additionally, this part of the ISO/IEC standard supports both binary and XML encoding, to support
a spectrum of user requirement. With XML, this part will meet the requirements of modern IT
architectures. With binary encoding this part will also be able to be used in bandwidth or storage
constrained environments. Annex F specifies the schema that XML encoded face image records must
conform to, and Annex G provides an example of a valid XML encoded face image record.

Page 6, ISO/IEC 19794–5:2011/Amd 1:2014, Annex A
Replace Table A.1 with the following (this new Table A.1 may extend over multiple pages):
ISO/IEC 19794-5:2011/Amd.2:2015(E)

2 © ISO 2015 – All rights reserved
Table A.1 — Normative requirements
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-1 5.1 The ISO/IEC 19794–5:2011 BDIR format specified in this part of 3C O-1 Y Y Y Y Y
ISO/IEC 19794 is a format to store face representations within a
biometric data record.
R-2 5.1 Each BDIR shall pertain to a single subject. 3C O-1 Y Y Y Y Y
R-3 5.1 Each BDIR shall contain at least one or more 2D image and zero or 3C M Y Y Y Y Y
more geometric representations (range images, 3D point maps, 3D
vertex representations) of a human face.
R-4 5.1 2D image data will be encoded using JPEG, JPEG2000 or PNG. 3C O-1 Y Y Y Y Y
R-5 5.1 With the exception of the Format Identifier and the Version Num- 3C O-1 Y Y Y Y N
ber for the standard, which are null-terminated ASCII character
strings, all data is represented in binary format.
R-6 5.1 There are no record separators or field tags; fields are parsed by 3C O-1 Y Y Y Y N
byte count.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-7 5.1 The organization of the record format is as follows. 3C O-1 Y Y Y Y N
—  A fixed-length (17 byte) General Header containing infor-
mation about the overall record, including the number of facial
images represented and the overall record length in bytes.
—  A Representation block for each facial representation. This
data consists of a Representation Header and the Representation
Data.
The Representation Header consists of
—  a fixed length (19 bytes) common elements defined in ISO/
IEC 19794–1:2011,
—  multiple (including none) fixed length (5 byte) Quality blocks
describing the quality of the representation,
—  a fixed length (17 byte) Facial Information block describing
discernable characteristics of the subject such as gender,
—  multiple (including none) fixed length (8 byte) Landmark
Point blocks describing Landmark Points in a facial image,
—  a fixed length (11 byte) Image Information block describ-
ing digital properties of the image such as Face Image Type and
dimensions such as width and height.
The Representation Data consists of
—  Image data consisting of a JPEG, JPEG2000 or PNG encoded
data block,
—  for Face Image Types containing 3D information, a 3D Infor-
mation block (95 byte) describing properties of this data,
—  for Face Image Types containing 3D information, the 3D Data
block describing the 3D shape of the face.
R-8 5.1 Multiple 2D/3D representations of the same biometric data subject 3C O-1 Y Y Y Y Y
can be described in a single record. This is accomplished by includ-
ing multiple representation blocks after the General Header block.
R-9 5.1 Representation blocks containing 2D data can be stored together 3C O-1 Y Y Y Y Y
with Representation blocks also containing 3D data.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

4 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-10 5.2.1 Within the record format and all well-defined data blocks therein, 1 M Y Y Y Y N
all multibyte quantities are stored in Big-Endian format.
R-11 5.2.2 All numeric values are fixed-length unsigned integer quantities, 3C O-1 Y Y Y Y Y
unless otherwise specified.
R-12 5.2.3 The conversion of a numeric value to integer is given by rounding 3C O-1 Y Y Y Y Y
down if the fractional portion is less than 0,5 and rounding up if
the fractional value is greater than or equal to 0,5.
R-13 5.2.4 The following fields are mandatory, but the value of the field can 3C O-1 Y Y Y Y N
indicate that the field is unspecified: Capture Device Technolo-
gy Identifier, Capture Device Vendor Identifier, Capture Device
Type Identifier, Gender, Eye Colour, Hair Colour, Subject Height,
Property, Expression, Pose Angle, Pose Angle Uncertainty, Image
Colour Space, 3D Capture Device Technology Identifier, 3D Capture
Device Vendor Identifier, 3D Capture Device Type Identifier, 3D
to 2D Image Temporal Synchronicity, 3D to 2D Texture Temporal
Synchronicity, 3D Acquisition Time, 2D Texture Acquisition Time,
Texture Map Type, and Texture Map Spectrum.
R-14 5.2.5 A field value labelled by the identifier “Unknown” shall be used to 3C O-1 Y Y Y Y Y
denote that the information encoded by the field cannot be deter-
mined by examination of the face image.
R-15 5.3.1 The General Header block consists of seven fields: Format Identifi- 3C O-1 Y Y Y Y N
er, Version Number, Length of Record, Number of Representations,
Capture Device Vendor Identifier, Capture Device Type Identifier
and the Temporal Semantics field as shown in Table 2.
R-16 5.3.2 The format identifier shall be recorded in four bytes. 1 M Y Y Y Y N
R-17 5.3.2 The format identifier shall consist of three characters “FAC” fol- 1 M Y Y Y Y N
lowed by a zero byte as a NULL string terminator.
R-18 5.3.3 The number for the version of ISO/IEC 19794–5:2011 used for 1 M Y Y Y Y N
constructing the BDIR shall be placed in four bytes.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-19 5.3.3 This version number shall consist of three ASCII numerals fol- 1 M Y Y Y Y N
lowed by a zero byte as a NULL string terminator.
The first and second character will represent the major version
number and the third character will represent the minor revision
number. The Version Number of ISO/IEC 19794–5:2011 shall be
30333000 ; “030” – Version 3, Revision 0.
HEX
R-20 5.3.4 The length (in bytes) of the entire BDIR shall be recorded in four 1 M Y Y Y Y N
bytes.
R-21 5.3.4 This count shall be the total length of the BDIR including the gen- 2 M Y Y Y Y N
eral record header and one or more representation records.
R-22 5.3.5 The total number of representation records contained in the BDIR 1, 2 M Y Y Y Y N
shall be recorded in two bytes.
R-23 5.3.5 A minimum of one representation is required. 1 M Y Y Y Y Y
R-24 5.3.6 Certification Flag 1 M Y Y Y Y N
The value shall be 00 .
HEX
R-25 5.3.7 Temporal Semantics 1 M Y Y Y Y N
This two byte (2 byte) field shall be assigned according to Table 3.
R-26 5.3.7 This supports storage of multiple representations: from a single 3C O-1 Y Y Y Y N
session (e.g. from a photo shoot); from distinct sessions (e.g. from
cash dispenser transactions); and from a temporal sequence (e.g. a
video sequence of equally time-spaced representations).
R-27 5.4.1 The Representation Header 3C O-1 Y Y Y Y N
Structure
The Representation Header is intended to describe discrete prop-
erties of the individual discernable from the image, one is included
for each facial representation included in the record.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

6 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-28 5.4.1 The Representation Header consists of the Representation Length, 3C O-1 Y Y Y Y N
the Capture Date and Time, the Capture Device Technology Iden-
tifier, the Capture Device Vendor Identifier. These are followed by
the Number of Quality Blocks field and the related number of Qual-
ity blocks. Finally the Representation Header contains the Facial
Information block, the optional multiple Landmark Point blocks,
and the Image Information block.
R-29 5.4.2 Representation Length 1, 2 M Y Y Y Y N
The (4 byte) Representation Length field denotes the length in
bytes of the representation including the representation header
fields.
R-30 5.4.2 The minimum value of the Representation Length is 51 bytes, con- 1 M Y Y Y Y N
sisting of a minimum 47 bytes for the Representation Header plus
the size of the Representation Data, i.e. minimum 4 bytes for the
Length of Image Data Block field assuming 0 bytes for the variable
data.
R-31 5.4.3 Capture Date and Time 3C O-1 Y Y Y Y Y
The capture date and time field shall indicate when the capture of
this representation started in Coordinated Universal Time (UTC).
R-32 5.4.3 The capture date and time field shall consist of 9 bytes. 1 M Y Y Y Y N
R-33 5.4.3 Its value shall be encoded in the form given in ISO/IEC 19794–1. 1 M Y Y Y Y N
R-34 5.4.4 Capture Device Technology Identifier 1 M Y Y Y Y N
Capture device technology Identifier shall be encoded in one byte.
R-35 5.4.4 This field shall indicate the class of device technology used to 3C O-1 Y Y Y Y Y
acquire the captured biometric sample.
R-36 5.4.4 Many different types of capture devices work in the visible spec- 3C O-1 Y Y Y Y N
trum or in near infrared (NIR). To indicate that the capture device
operates in NIR the highest bit in the Capture Device Technology
Identifier field shall be set to 1.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
3)
R-37 5.4.4 See the following table for the enumerated list of possible values. 1 M Y Y Y Y Y
1)
R-38 5.4.5 Capture Device Vendor Identifier 1 M Y Y Y Y Y
The (2 byte) Capture Device Vendor Identifier shall identify the bi-
ometric organisation that owns the product that created the BDIR.
R-39 5.4.5 The capture device algorithm vendor identifier shall be encoded 3C O-1 Y Y Y Y N
in two bytes carrying a CBEFF biometric organization identifier
(registered by IBIA or other approved registration authority).
R-40 5.4.5 A value of all zeros shall indicate that the capture device vendor is 1 M Y Y Y Y N
unreported.
1)
R-41 5.4.6 Capture Device Type Identifier 1 M Y Y Y Y Y
The (2 byte) Capture Device Type Identifier shall identify the
product type that created the BDIR.
R-42 5.4.6 It shall be assigned by the registered product owner or other ap- 3C M Y Y Y Y Y
proved registration authority.
R-43 5.4.6 A value of all zeros shall indicate that the capture device type is 1 M Y Y Y Y N
unreported.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

8 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-44 5.4.6 If the capture device vendor identifier is 0000 , then also the 2 M Y Y Y Y N
HEX
capture device type identifier shall be 0000
HEX
R-45 5.4.7 Number of Quality Blocks 2 M Y Y Y Y N
This field is followed by the number of 5 byte Quality blocks re-
flected by its value.
R-46 5.4.7 A value of zero (0) means that no attempt was made to assign a 2 M Y Y Y Y N
quality score. In this case, no Quality blocks are present.
2)
R-47 5.4.8 Quality Score 1, 3C M Y Y Y Y Y
The (1 byte) Quality Score, as defined in ISO/IEC 29794–1, shall
be a quantitative expression of the predicted verification perfor-
mance of the biometric sample.
R-48 5.4.8 Valid values for Quality Score are integers between 0 and 100, 1 M Y Y Y Y Y
where higher values indicate better quality.
R-49 5.4.8 A value of 255 is to handle a special case. 1 M Y Y Y Y N
R-50 5.4.8 An entry of 255 shall indicate a failed attempt to calculate a quali- 3C O-1 Y Y Y Y N
ty score.
2)
R-51 5.4.9 Quality Algorithm Vendor Identifier 1 M Y Y Y Y Y
To enable the recipient of the quality score to differentiate
between quality scores generated by different algorithms, the
provider of quality scores shall be uniquely identified by this two-
byte field.
R-52 5.4.9 This is registered with the IBIA or other approved registration 3C O-1 Y Y Y Y Y
authority.
2)
R-53 5.4.10 Quality Algorithm Identifier 1 M Y Y Y Y Y
The (2 byte) Quality Algorithm Identifier specifies an integer
product code assigned by the vendor of the quality algorithm.
R-54 5.4.10 It indicates which of the vendor’s algorithms (and version) was 1 M Y Y Y Y Y
used in the calculation of the quality score and should be within
the range 1 to 65 535.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
2)
R-55 5.4.10 Table A.2 summarizes the quality field. All values are fixed-length 1, 3C M Y Y Y Y N
unsigned integer quantities represented in Big-Endian format.
R-56 5.5.1 The Facial Information Block 3C O-1 Y Y Y Y N
Structure
The Facial Information Block consists of the Number of Landmark
Points, the Gender, the Eye Colour, the Hair Colour, the Subject
Height, the Property Mask, the Expression Mask, the Pose Angle,
and the Pose Angle Uncertainty fields.
R-57 5.5.2 Number of Landmark Points 1, 2 M Y Y Y Y N
The (2 byte) Number of Landmark Points field shall be the number
of Landmark Point blocks that follow the Facial Information block.
1)3)
R-58 5.5.3 Gender 1, 3C M Y Y Y Y Y
The (1 byte) Gender field shall represent the gender of the subject
according to the following table.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

10 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
1)3)
R-59 5.5.4 Eye Colour 1, 3C M Y Y Y Y Y
The (1 byte) Eye Colour field shall represent the colour of irises of
the eyes according to the following table.
R-60 5.5.4 If the eyes are different colours, then the right eye colour is to be 3C O-1 Y Y Y Y Y
encoded.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
1)3)
R-61 5.5.5 Hair Colour 1, 3C M Y Y Y Y Y
The (1 byte) Hair Colour field shall represent the colour of the hair
according to the following table.
3)
R-62 5.5.6 Subject Height 1, 3C M Y Y Y Y Y
The (1 byte) Subject Height field shall represent the height of the
subject according to the following table.
R-63 5.5.7 Property Mask 1 M Y Y Y Y N
The (3 byte) Property Mask is a bit mask of 3 bytes and each bit of
the mask position listed in Table 10 shall be set to 1 if the corre-
sponding property is present, and set to 0 if absent.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

12 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-64 5.5.7 The mask position starts from 0 at the lowest bit. 1 M Y Y Y Y N
R-65 5.5.7 The lowest bit set to 0 shall indicate that properties are not speci- 3C O-1 Y Y Y Y N
fied (and all bits shall be zero);
R-66 5.5.7 The lowest bit set to 1 shall indicate that all listed properties have 1 M Y Y Y Y N
been considered and that a zero value of any property bit indicates
an absence of that property.
R-67 5.5.7 All reserved bits shall be zero. 1 M Y Y Y Y N
R-68 5.5.7 A “Pupil or iris not visible” flag set to “1” shall indicate non-compli- 2 M Y Y N
ance with the Frontal, Full Frontal, and Token image types.
R-69 5.5.8 Expression 1, 3C M Y Y Y Y N
The (2 byte) Expression Mask is a bit mask of 2 bytes and each bit
of the mask position listed in Table 11 shall be set to 1 if the corre-
sponding expression is present, and set to 0 if absent.
R-70 5.5.8 The mask position starts from 0 at the lowest bit. 1 M Y Y Y Y N
R-71 5.5.8 The lowest bit set to 0 shall indicate that properties are not speci- 1 M Y Y Y Y N
fied (and all bits shall be zero);
R-72 5.5.8 The lowest bit set to 1 shall indicate that all listed properties have 1 M Y Y Y Y N
been considered and that a zero value of any property bit indicates
an absence of that expression.
R-73 5.5.8 All reserved bits shall be zero. 1 M Y Y Y Y N
1)
R-74 5.5.9 Pose Angle 3C O-1 Y Y Y Y Y
The (3 multibyte) Pose Angle field (B , B , B ) shall represent the
y P R
estimate or measure pose of the subject in the image.
R-75 5.5.9 Each byte in the field respectively represents pose angles of yaw, 3C O-1 Y Y Y Y Y
pitch and roll in that order.
R-76 5.5.9 The angles are defined relative to the frontal pose of the subject, 3C O-1 Y Y Y Y Y
which has angles (0,0,0) as shown in Figure 5. The frontal pose is
defined by the Frankfurt Horizon FH (see Annex E) as the xz plane
and the vertical symmetry plane as the yz plane with the z axis
oriented in the direction of the face sight.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-77 5.5.9 As order of the successive rotation around the different axes does 3C O-1 Y Y Y Y Y
matter, the encoded rotation angle shall correspond to an order of
execution starting from the frontal view. This order shall be given
by Roll (about the front axis), then Pitch (about the horizontal axis)
and finally Yaw (about the vertical axis). The (first executed) Roll
transformation will therefore always be in the image (x,y) plane.
R-78 5.5.9 From the point of view of executing a transformation from the ob- 3C O-1 Y Y Y Y Y
served view to a frontal view, the transformation order will there-
fore be Yaw, Pitch, and then Roll. Note however that the encoded
angle is from the frontal view to the observed view.
R-79 5.5.9.1 Pose Angle — Yaw 3C O-1 Y Y Y Y Y
The yaw angle Y is the rotation in degrees about the y-axis (verti-
cal axis) shown in Figure 5.
R-80 5.5.9.1 Frontal poses have a yaw angle of 0 degrees. 3C O-1 Y Y Y Y Y
R-81 5.5.9.1 Positive angles represent faces looking to their left (a coun- 3C O-1 Y Y Y Y Y
ter-clockwise rotation around the y-axis).
R-82 5.5.9.1 The encoded value, B , shall be stored in 1 byte with values 0 to 1 M Y Y Y Y Y
Y
180 computed from a real-valued yaw angle estimate, -180 ≤ Y <
180, as follows:
If 180 ≥ Y ≥ 0 then B = Y/2+1. The remainder is discarded.
Y
If -180 ≤ Y< 0 then B = 181+Y/2. The remainder is discarded.
Y
The maximum value of B is 180. If the pose angle is not specified,
Y
the value of B shall be 0.
Y
R-83 5.5.9.2 Pose Angle — Pitch 3C O-1 Y Y Y Y Y
The pitch angle P is the rotation in degrees about the x-axis (hori-
zontal axis) shown in Figure 5.
R-84 5.5.9.2 Frontal poses have a pitch angle of 0 degrees. 3C O-1 Y Y Y Y Y
R-85 5.5.9.2 Positive angles represent faces looking down (a counter-clockwise 3C O-1 Y Y Y Y Y
rotation around the x-axis).
ISO/IEC 19794-5:2011/Amd.2:2015(E)

14 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-86 5.5.9.2 The encoded value, B , shall be stored in 1 byte with values 0 to 1 M Y Y Y Y Y
P
180 computed from a real-valued pitch angle estimate, -180 ≤ P <
180, as follows:
If 180 ≥ P ≥ 0 then B = P/2+1. The remainder is discarded.
P
If -180 ≤ P< 0 then B = 181+P/2. The remainder is discarded.
P
The maximum value of B is 180. If the pitch angle is not specified,
P
the value of B shall be 0.
P
R-87 5.5.9.3 Pose Angle — Roll 3C O-1 Y Y Y Y Y
The roll angle R is the rotation in degrees about the z-axis (the
horizontal axis from front to back) shown in Figure 5. Frontal
poses have a roll angle of 0 degrees.
R-88 5.5.9.3 Positive angles represent faces tilted toward their right shoulder 3C O-1 Y Y Y Y Y
(counter-clockwise rotation around the z-axis).
R-89 5.5.9.3 A roll angle of 0 degrees denotes that the left and right eye centres 3C O-1 Y Y Y Y Y
have identical Y coordinates.
R-90 5.5.9.3 The encoded value, B , shall be stored in 1 byte with values 0 to 1 M Y Y Y Y Y
R
180 computed from a real-valued roll angle estimate, -180 ≤ R <
180, as follows:
If 180 ≥ R ≥ 0 then B = R/2+1. The remainder is discarded.
R
If -180 ≤ R< 0 then B = 181+R/2. The remainder is discarded.
R
The maximum value of B is 180. If the roll angle is not specified,
R
the value of B shall be 0.
R
R-91 5.5.10 Pose Angle Uncertainty 3C O-1 Y Y Y Y N
The (3 multibyte) Pose Angle Uncertainty (U , U , U ) repre-
Y P R
sents the expected degree of uncertainty of the pose angle yaw,
pitch, and roll. Each byte in the field respectively represents the
uncertainty of yaw, pitch and roll in that order. The uncertainty is
allowed to represent experimental uncertainty specified by each
vendor.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-92 5.5.10 The encoding of Pose Angle Uncertainty is given by three bytes 1 M Y Y Y Y Y
(U , U , U ) where each byte U in the field (k=Y,P,R) represents
Y P R K
1 degree of uncertainty with minimum and maximum values of 1
and 181 where U =(uncertainty+1).
K
R-93 5.5.10 The more uncertain, the value of the uncertainty U shall become 3C O-1 Y Y Y Y Y
K
larger.
R-94 5.5.10 If the uncertainty is not specified, then the values of U , U and U 1 M Y Y Y Y Y
Y P R
shall be set to zero (0).
1)
R-95 5.6.1 The Landmark Point Block 2 M Y Y Y Y Y
Structure
The optional (8 byte) Landmark Point block specifies the type,
code and position of a Landmark Point in the facial image.
R-96 5.6.1 The number of Landmark Point blocks shall be specified in the 2 M Y Y Y Y N
Number of Landmark Points field of the Facial Information block.
1)
R-97 5.6.2 Landmark Point Type 1 M Y Y Y Y Y
The (1 byte) Landmark Point Type field represents the type of the
Landmark Point stored in the Landmark Point block.
3)
R-98 5.6.2 This field shall be set to 01 to denote that landmark point is an 1 M Y Y Y Y Y
HEX
MPEG-4 Feature Point as given in ISO/IEC 14496–2:2004, Annex C
and is represented by the 2D image coordinates.
3)
R-99 5.6.2 The field shall be set to 02 to denote that the landmark point 1 M Y Y Y Y Y
HEX
is an Anthropometric 2D landmark and is represented by the 2D
image coordinates.
3)
R-100 5.6.2 Finally, the field shall be set to 03 to denote that the Landmark 1 M Y Y Y Y Y
HEX
Point is an anthropometric 3D landmark and is represented by its
3D coordinates.
R-101 5.6.2 All other field values are reserved by SC 37 for future definition of 1 M Y Y Y Y Y
Landmark Point Types.
R-102 5.6.3 Landmark Point Code 1 M Y Y Y Y Y
The (1 byte) Landmark Point Code field shall specify the Land-
mark Point that is stored in the Landmark Point block.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

16 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-103 5.6.3 For the Landmark Point Type 01 the codes of the Landmark 3C O-1 Y Y Y Y Y
HEX
Points in 5.6.4, taken from ISO/IEC 14496–2:2004, Annex C and de-
fined as MPEG-4 Feature Points, or the additional eye and nostril
Landmark Points in 5.6.5 shall be stored in this block.
R-104 5.6.3 If the Landmark Point Type is 02 or 03 , i.e. anthropometric 3C O-1 Y Y Y Y Y
HEX HEX
2D landmark or anthropometric 3D landmark, the codes of the
Landmark Points defined in 5.6.6 shall be stored in this block.
R-105 5.6.3 The horizontal and vertical positions of Landmark Points are 3C O-1 Y Y Y Y Y
either texture image coordinates or in the Cartesian coordinate
system (see 5.10.2.2).
R-106 5.6.4 MPEG-4 Landmark Points 3C O-1 Y Y Y Y Y
The normative Figure 7 denotes the Landmark Point codes as-
sociated with Feature Points as given in ISO/IEC 14496–2:2004,
Annex C. Each Landmark Point Code is represented by a notation
A.B using a major (A) and a minor (B) value. The encoding of the
Landmark Point Code is given by the (1 byte) value of A*16 + B.
R-107 5.6.5 Eye and nostril centre Landmark Points 3C O-1 Y Y Y Y Y
The eye centre Landmark Points 12.1 (left) and 12.2 (right) are
defined to be the horizontal and vertical midpoints of the eye
corners (3.7, 3.11) and (3.8, 3.12) respectively. The left nostril
centre Landmark Point 12.3 is defined to be the midpoint of the
nose Landmark Points (9.1, 9.15) in the horizontal direction and
(9.3, 9.15) in the vertical direction. Similarly, the right nostril
centre Landmark Point 12.4 is defined to be the midpoint of the
nose Landmark Points (9.2, 9.15) in the horizontal direction and
(9.3, 9.15) in the vertical direction. Both the eye centre and nostril
centre Landmark Points are shown in Figure 8 and values given in
Table 14.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-108 5.6.6 Anthropometric Landmarks 3C O-1 Y Y Y Y Y
Anthropometric landmarks extend the MPEG-4 feature model
with new points that are used in forensics and anthropology for
person identification via two facial images or image and skull over
a long time. They also allow specification of points that are in use
[10]
by criminal experts and anthropologists . Figure 9 and Table 15
show the definition of the anthropometric landmarks. The set of
points represents the craniofacial landmark points of the head and
face. The latter are used in forensics for “Face to face” and “Skull
to face” identification. Some of these points have MPEG 4 counter-
parts, others not.
The anthropometric landmark code has the format: A.B. A speci-
fies the global landmark of the face to which this landmark belongs
such as nose, mouth, etc. B specifies the particular point. In case a
Landmark Point has two symmetrical entities (left and right) the
right entity always has a greater and even minor code value.
Hence, all Landmark Points from the left part of the face have odd
minor codes, and from the right part — even minor codes. Both
A and B are in the range from 1 to 15. Hence, the code A*16 + B is
written to the 1 byte Landmark Point Code field.
R-109 5.6.7 Anthropometric 3D landmark 3C O-1 Y Y Y Y Y
The error of an anthropometric 3D landmark point location should
be no greater than 3 mm. The point shall withstand from the
nearest point on the surface no further than 3 mm. The point on
the surface is a vertex, or a point on an edge, or a point on a face of
the surface.
R-110 5.6.8 Z coordinate 2 M Y Y Y Y Y
This field is not used if the Landmark Point Type is equal to MPEG-
4 feature or anthropometric 2D landmark.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

18 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-111 5.6.8 In case the Landmark Point Type equals anthropometric 3D land- 3C O-1 Y Y Y Y Y
mark this field along with the horizontal and vertical positions
denotes the coordinates of the landmark point in the 3D Cartesian
coordinate system. The metric coordinates of 3D landmarks shall
be obtained by multiplying the X, Y, and Z coordinates by a fixed
scale of 0,02 mm. Note, that the Landmark Point Type field codes
the type of the Landmark Point and determines the interpretation
of the Z coordinate.
1)
R-112 5.7.1 The Image Information Block 3C O-1 Y Y Y Y Y
Data Structure
The (11 byte) Image Information block is intended to describe
digital properties of the facial image, one is included for each facial
image included in the record.
R-113 5.7.1 One Representation data block shall follow this block. 3C O-1 Y Y Y Y Y

ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
3)
R-114 5.7.2 Face Image Type 1 M Y Y Y Y Y
The Face Image Type field shall represent the type of the facial
image stored in the Image Information block and, if applicable, the
3D Data block according to the following table.
Note that all Frontal Image Types are either Full Frontal, Token
Frontal, Post-processed Frontal or one of the respective 3D Full
Frontal or Token Frontal Image Types.

ISO/IEC 19794-5:2011/Amd.2:2015(E)

20 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
1)3)
R-115 5.7.3 Image Data Type 1 O-1 Y Y Y Y Y
The (1 byte) Image Data Type field denotes the encoding type of
the Image Data block. Either JPEG (ISO/IEC 10918–1 and ITU-T
[18]
Rec. T.81 ) or JPEG2000 (ISO/IEC 15444–1) or PNG (ISO/
IEC 15948:2003) shall be specified as given in in the following
table.
3)
R-116 5.7.3 For lossless compression PNG or JPEG2000 lossless shall be used. 3C O-1 Y Y Y Y Y
3)
R-117 5.7.3 For lossless representation of images using more than 8 bits per 3C O-1 Y Y Y Y Y
channel PNG or JPEG2000 lossless shall be used.
R-118 5.7.3 For lossy representation of images using more than 8 bits per 3C O-1 Y Y Y Y Y
channel JPEG2000 shall be used.
3)
R-119 5.7.3 See the following table for the list of possible image data type 1 M Y Y Y Y Y
values.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-120 5.7.4 Width 1, 2 M Y Y Y Y Y
The (2 byte) Width field shall specify the number of pixels in the
horizontal direction.
R-121 5.7.5 Height 1, 2 M Y Y Y Y Y
The (2 byte) Height field shall specify the number of pixels in the
vertical direction.
1)3)
R-122 5.7.6 Spatial Sampling Rate Level 1 M Y Y Y Y Y
For specific application domains different minimal spatial sam-
pling rates of the interchange data may be required. For example
using higher spatial sampling rate images allow for specific human
as well as machine inspection methods that depend on the analysis
of very small details. The (1 byte) Spatial Sampling Rate Level field
(see following table) provides information on the number of pixels
in the image across the width of the head. (The Width of Head (CC)
is defined in Figure 14)
NOTE   Interocular distance in pixels will be approximately half
of the head widths.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

22 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-123 5.7.7 Post-acquisition Processing 3C O-1 Y Y Y Y Y
While the alteration of face image data is discouraged, there are
cases when no alternative may exist.
—  Legacy database of frontal face images shall be rotated to full
frontal prior to biometric comparison.
—  From a frontal image artificial non-frontal facial images at
predetermined non-frontal poses are automatically generated
(multi-view images) using an implicit head model or similar. These
images can be beneficial during the comparison process or a
manual review process as they show a more similar pose than the
original frontal image.
—  A single image is to be age progressed and used for verification
of a passport holder.
—  A short video stream is super-resolved to a single face image
for comparison against a watchlist.
R-124 5.7.7 The (2 byte) Post-acquisition Processing bit field allows the speci- 1 M Y Y Y Y N
fication of the kind of post processing that has been applied to the
original captured image.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
3)
R-125 5.7.7 Each bit of the mask position listed in the following table shall be 1 M Y Y Y Y Y
set to 1 if the corresponding processing has been applied, and set
to 0 if not.
R-126 5.7.7 The mask position starts from 0 at the lowest bit. 1 M Y Y Y Y N
R-127 5.7.7 All bits set to zero indicate that no post-acquisition processing has 1, 3C M Y Y Y Y N
been applied at all.
R-128 5.7.7 All reserved bits shall be zero. 1 M Y Y Y Y N

ISO/IEC 19794-5:2011/Amd.2:2015(E)

24 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-129 5.7.7 On the one hand a captured image typically needs some post-pro- 2 M Y Y Y
cessing so that the resulting representation conforms to the claus-
es of this part of ISO/IEC 19794, especially for the frontal image
type. On the other hand these processing steps should be minimal
and not distort the characteristics of the original image. The right
column in Table 19 clearly states, what post-acquisition processes
can be applied without having to store the resulting representa-
tion in the post-processed image type as defined in Clause 10.
1)
R-130 5.7.8 Cross Reference 1 M Y Y
The (1 byte) Cross Reference Data Type field denotes inter-de-
pendencies when multiple representations are stored in the inter-
change record.
This is of particular interest in the case post-processing has been
used (see Clause 10).
R-131 5.7.8 Then representations that are of type Post-processed shall code 2 M Y Y
the ordinal number of the representation that they have been de-
rived from, in the Cross Reference Field. Example: There are four
representations in the overall record. The second representation
has been postprocessed and resulted in the fourth representation.
Then, the fourth representation shall have Cross Reference set to
2, all other Records shall have set Cross Reference to 0.
R-132 5.7.8 The first representation of the interchange format has the code 1 M Y N
01 .
HEX
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
1)3)
R-133 5.7.9 Image Colour Space 2 M Y Y Y Y Y
The (1 byte) Image Colour Space field indicates the colour space
used in the encoded Image Information block according to the val-
ues in the following table. The values of 80 -FF are vendor
HEX HEX
specific. Application developers may obtain the values for these
codes from the vendor.
R-134 5.8 The Representation Data block 3C O-1 Y Y Y Y N
The Representation Data consists of the Image Data Block, the 3D
Information Block and the 3D data Block.
R-135 5.9.1 The Image Data Block 3C O-1 Y Y Y Y N
Data structure
The (variable byte) Image Data block shall consist of two fields as
shown in Table A.3.
R-136 5.9.2 Image Data Length 1, 2 M Y Y Y Y N
This four byte field shall indicate the length of the image data in
bytes.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

26 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-137 5.9.3 Image data 2 M Y Y Y Y Y
This variable length field shall contain the image data encoded by
the JPEG or JPEG2000 or PNG standards
R-138 5.10 The 3D Information Block 3C O-1 Y Y Y N
The 3D Information block consists of the following fields and sub-
blocks:
The Length of 3D Data Representation, the Coordinate System
Type, the Texture Projection Matrix, Scale, Offset, the 3D Rep-
resentation Type, the 3D Supplemental Data, a field reserved for
future use, the 3D Capture Device Technology Identifier, the 3D
Capture Device Vendor Identifier, the 3D Capture Device Type
Identifier, the 3D to 2D Image Temporal Synchronicity, the 3D to
2D-Texture Temporal Synchronicity, the 3D Acquisition Time, the
2D-Texture Acquisition Time, the Texture Map Type and finally the
Texture Map Spectrum.
R-139 5.10.1 Length of 3D Data Representation 1, 2 M Y Y Y N
This (4 byte) field codes the length of the 3D Information and 3D
Data block including the optional fields and blocks, if they are
present.
R-140 5.10.2.1 Coordinate System Type 3C O-1 Y Y Y Y
General
All representations support a Cartesian coordinate system.
The range data representation additionally supports a cylindrical
coordinate system.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
R-141 5.10.2.1 The (1 byte) Coordinate System Type field specifies the coordinate 1 M Y Y Y N
system of the 3D data by using the following values.
R-142 5.10.2.2 In the Cartesian coordinate system the point of origin of the sen- 3C O-1 Y Y Y Y
sor data typically is used as the point of origin of the coordinate
system.
The transformation from Cartesian coordinates to metric Carte-
sian coordinates is derived as follows:
X = x × ScaleX + OffsetX
Y = y × ScaleY + OffsetY
Z = z × ScaleZ + OffsetZ
R-143 5.10.2.2 A strong relation between anthropometric landmarks and the 3C O-1 Y Y Y Y
coordinate system is still established by
—  the anatomical alignment requirements of the corresponding
2D image, and
—  the alignment between the 3D range data and the correspond-
ing 2D image after applying the Texture Projection Matrix.
R-144 5.10.2.3 The Cylindrical Coordinate System 3C O-1 Y Y Y Y
A point in the Cylindrical Coordinate System is given by (α, h, r).
R-145 5.10.2.3 The angle α and the h-axis are defined in a way that they form a 3C O-1 Y Y Y Y
clockwise coordinate system.
ISO/IEC 19794-5:2011/Amd.2:2015(E)

28 © ISO 2015 – All rights reserved
Table A.1 (continued)
Subformat
Ref. in
Req. XML IUT Supported Test
applicability
main Requirements summary Level Status
ID support support range results
body
B F T P
...