ISO/IEC 12087-5:2025
(Main)Information technology — Image processing and interchange (IPI) functional specification — Part 5: Basic image interchange format (BIIF)
Information technology — Image processing and interchange (IPI) functional specification — Part 5: Basic image interchange format (BIIF)
This document establishes the specification of the Basic image interchange format (BIIF). This document provides a foundation for interoperability in the interchange of imagery and imagery-related data among applications. It also provides a detailed description of the overall structure of the format, as well as specification of the valid data and format for all fields defined with BIIF. Annex C contains a Model Profile of BIIF in tables to assist in profile development. The scope and field of application of this document includes the capability to perpetuate a proven interchange capability in support of commercial and government imagery, Programmer’s Imaging Kernel System (PIKS) data, and other imagery technology domains in that priority order. This document provides a data format container for image, symbol, and text, along with a mechanism for including image-related support data. This document: — provides a means whereby diverse applications can share imagery and associated information; — allows an application to exchange comprehensive information to users with diverse needs or capabilities, allowing each user to select only those data items that correspond to their needs and capabilities; — minimizes preprocessing and postprocessing of data; — minimizes formatting overhead, particularly for those applications exchanging only a small amount of data and for bandwidth-limited systems; — provides a mechanism (Transportable File Structure, TFS) to interchange PIKS image and image-related objects; — provides extensibility to accommodate future data, including objects.
Technologies de l’information — Spécification fonctionnelle pour le traitement de l’image et l’échange (IPI) — Partie 5: Format d’échange de l’image de base (BIIF)
General Information
Relations
Standards Content (Sample)
International
Standard
ISO/IEC 12087-5
Second edition
Information technology — Image
2025-08
processing and interchange (IPI)
functional specification —
Part 5:
Basic image interchange format (BIIF)
Technologies de l’information — Spécification fonctionnelle pour
le traitement de l’image et l’échange (IPI) —
Partie 5: Format d’échange de l’image de base (BIIF)
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions .2
3.2 Abbreviated terms .6
4 Basic image interchange format (BIIF) specification. 7
4.1 Format overview .7
4.1.1 Description .8
4.1.2 Interoperability/exchange .10
4.1.3 Fields .10
4.1.4 Logical structure of pixel storage . 12
4.1.5 Common coordinate system . 13
4.1.6 Display and attachment levels.14
4.2 Format .17
4.2.1 Data recording formats .17
4.2.2 Encoding .17
4.2.3 Header .18
4.2.4 Image segment . 25
4.2.5 Image data field format . 35
4.2.6 Symbol segment . 44
4.2.7 Text information segment .47
4.2.8 Data extensions . 48
5 Conformance profiles and extensions .55
5.1 BIIF profiles . 55
5.2 BIIF profile specific header/subheader dependencies pro forma . 56
5.3 Complexity level pro forma . 56
5.4 Implementation support requirements . 56
5.4.1 General support requirements . 56
5.4.2 Producing and interpreting BIIF files .57
5.5 Defined extensions .57
5.6 BIIF profile registration .57
Annex A (normative) Transportable file structure .58
Annex B (normative) Vector quantization .77
Annex C (normative) Profiling BIIF .86
Annex D (informative) Implementation considerations and product configurations .114
Annex E (informative) Examples of BIIF Profiles .129
Bibliography .143
© ISO/IEC 2025 – 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 24, Computer graphics, image processing and environmental data representation.
This second edition cancels and replaces the first edition (ISO/IEC 12087-5:1998), which has been
technically revised. It also incorporates the Technical Corrigenda ISO/IEC 12087-5:1998/Cor. 1:2001, and
ISO/IEC 12087-5:1998/Cor. 2:2002.
The main changes are as follows:
— updated foreword and introduction;
— updated normative references;
— changed the IMODE field value definition from “PVV” to “PVU” so that the IMODE field value range may
be extended by a BIIF profile;
— updated the Open Skies Digital Data Exchange Format (OSDDEF) BIIF Profile definition to match the
current definition used by the Treaty on Open Skies and the Open Skies Consultative Commission (OSCC).
A list of all parts in the ISO/IEC 12087 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2025 – All rights reserved
iv
Introduction
ISO/IEC 12087-1 establishes the conceptual and architectural framework for the ISO/IEC 12087 series. In
particular, it defines the types of all image data objects, image-related data objects, and attributes that may
be interchanged by means of the Image processing and interchange – Image interchange facility (IPI-IIF).
ISO/IEC 12087-2 establishes the specification of the Programmer’s Imaging Kernel System (IPI-PIKS).
ISO/IEC 12087-3 provides a data format specification and an application program interface specification.
The IIF data format may be used for image data interchange in open, heterogeneous environments. It may
also serve as a local file format for imaging applications, especially in conjunction with ISO/IEC 12087-2.
In future, the IIF data format may be used by telecommunication standards. Examples are future versions
of File Transfer, Access, and Management (FTAM), ISO/IEC 8571; the Message Oriented Text Interchange
Systems (MOTIS), ISO/IEC 10021 [also known as Message Handling System (MHS), CCITT Recommendation
X.400]. Thus, the IIF data format can become part of the application-oriented OSI communications protocols.
ISO/IEC 12088-4 provides the application program interface language binding for the C programming
language. The Image processing and interchange (IPI) functional specification, ISO/IEC 12087, upon which
this binding is based, first emerged as an International Standard in 1994. The functional description
of ISO/IEC 12087 is specified in a language independent manner and needs to be embedded in language
dependent layers (language bindings) for use with particular programming languages.
ISO/IEC 12089 defines the encoding rules that apply to representations of IPI-IIF image data. Due to the
fact that the syntax of the IPI-IIF data format definition, from ISO/IEC 12087-3, is expressed using Abstract
Syntax Notation One (ASN.1), ISO/IEC 12089 makes use of the Basic Encoding Rules (BER) for ASN.1.
Furthermore, ISO/IEC 12089 provides a rationale (in Clause 4) for the introduction of new encoding rules, in
addition to those defined by the BER, that provide support for heterogeneous pixel types within the context
of the IPI-IIF data format definition.
This document establishes the specification of the Basic image interchange format (BIIF) part of the IPI
functional specification. This document conforms to the architectural and data object specifications
of ISO/IEC 12087-1, the Common architecture for imaging. BIIF supports a profiling scheme that is a
combination of the approaches taken for ISO/IEC 12087-2 (PIKS), ISO/IEC 10918 (JPEG), ISO/IEC 8632
(CGM), and ISO/IEC 9973.
When the extensibility of this document, or the inherent constraints of the structured format of BIIF, do not
meet the needs of a more complex application, then concepts and features of ISO/IEC 12087-3 (IIF) can be
considered as a more appropriate method of image interchange. For example, the ability to support complex
combinations of heterogeneous pixel types, self-defining pixel structures, or abstract structures can be done
with IIF.
© ISO/IEC 2025 – All rights reserved
v
International Standard ISO/IEC 12087-5:2025(en)
Information technology — Image processing and interchange
(IPI) functional specification —
Part 5:
Basic image interchange format (BIIF)
1 Scope
This document establishes the specification of the Basic image interchange format (BIIF). This document
provides a foundation for interoperability in the interchange of imagery and imagery-related data among
applications. It also provides a detailed description of the overall structure of the format, as well as
specification of the valid data and format for all fields defined with BIIF. Annex C contains a Model Profile of
BIIF in tables to assist in profile development.
The scope and field of application of this document includes the capability to perpetuate a proven interchange
capability in support of commercial and government imagery, Programmer’s Imaging Kernel System (PIKS)
data, and other imagery technology domains in that priority order.
This document provides a data format container for image, symbol, and text, along with a mechanism for
including image-related support data.
This document:
— provides a means whereby diverse applications can share imagery and associated information;
— allows an application to exchange comprehensive information to users with diverse needs or capabilities,
allowing each user to select only those data items that correspond to their needs and capabilities;
— minimizes preprocessing and postprocessing of data;
— minimizes formatting overhead, particularly for those applications exchanging only a small amount of
data and for bandwidth-limited systems;
— provides a mechanism (Transportable File Structure, TFS) to interchange PIKS image and image-related
objects;
— provides extensibility to accommodate future data, including objects.
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.
1)
ISO 8601:2004 , Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO/IEC 8632 (all parts), Information technology — Computer graphics — Metafile for the storage and transfer
of picture description information
1) Withdrawn and replaced by ISO 8601-1:2019 and ISO 8601-2:2019.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 9973, Information technology — Computer graphics, image processing and environmental data
representation — Procedures for registration of items
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 10918-1, Information technology — Digital compression and coding of continuous-tone still images:
Requirements and guidelines
ISO/IEC 10918-3, Information technology — Digital compression and coding of continuous-tone still images:
Extensions
ITU-T T.4, (1993:03)/Amd.2:1995, Standardization of Group 3 Facsimile apparatus for document transmission
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions 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
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
attachment level
field value of a segment that indicates the display level of the segment to which it is attached
3.1.2
band
two-dimensional array of pixel sample values that comprise an image
Note 1 to entry: For the basic use of BIIF, the band values are homogeneous data types for each band. In the case of
monochrome or indexed colour images (single 2-dimensional array of pixel values with possible look-up-tables), the
image array consists of one band. In the case of RGB images (three 2-dimensional arrays of pixel values; 8 bits each of
Red, Green, and Blue values for each pixel), the image consists of three bands. When images need to be represented
using bands with heterogeneous array structure or data types (e.g. two bands with integer data type and one band
with a real data type), the image representation may be defined using a PIKS object in a TFS Data Extension Segment
(DES). The TFS PIKS object defines the data structure of the values in the image data field of the image segment.
3.1.3
basic character set
BCS
subset of the ISO/IEC 10646 character set that is represented by the UTF-8 form and used in headers and
subheaders
3.1.4
basic character set-alphanumeric
BCS-A
subset of the BCS having a range of allowable characters consisting of space through tilde (single octets with
values ranging from 20 to 7E) from the Basic Latin Collection
3.1.5
basic character set-numeric
BCS-N
subset of the BCS that consists of the digits ‘0’ through ‘9’, ‘plus sign’, ‘minus sign’, ‘decimal point’, and ‘slash’
© ISO/IEC 2025 – All rights reserved
3.1.6
basic multilingual plane
BMP
character encodings from the first 65,536 code points (Plane 0) of the ISO/IEC 10646 (or Unicode) standard
Note 1 to entry: The BMP (Plane 0) includes characters in general use in alphabetic, syllabic, and ideographic scripts
together with various symbols and digits; see ISO/IEC 10646.
3.1.7
block
tile
rectangular array of pixel values that is a subset of an image
Note 1 to entry: An image consists of the union of one or more non-overlapping adjacent blocks.
3.1.8
byte
sequence of eight bits (i.e., octet)
3.1.9
common coordinate system
two-dimensional coordinate space that is used in common for determining the placement and orientation
of displayable data types within a specific BIIF file and among correlated BIIF files that comprise an
integrated product
3.1.10
conditional field
data field whose existence depends on the value(s) of the designated required field(s) preceding it
3.1.11
coordinated universal time
UTC
time scale maintained by the Bureau international des poids et mesures (BIPM) (International Bureau of
Weights and Measures) that forms the basis of a coordinated dissemination of standard frequencies and
time signals
Note 1 to entry: UTC is equivalent to the mean solar time at the prime meridian at Greenwich, England.
3.1.12
data extension segment
DES
BIIF segment-based construct for metadata extension
Note 1 to entry: The DES structure is discussed in Subclause 4.2.8.2.
3.1.13
displayable data
information that can be exhibited in visual form
3.1.14
display level
field value of a segment that denotes the order in which the segments (images and symbols) are “stacked”
Note 1 to entry: The display level order is independent of the segment sequence order in the file.
3.1.15
field
logically primitive item of data
Note 1 to entry: Sometimes referred to as an attribute.
© ISO/IEC 2025 – All rights reserved
3.1.16
image
digital file consisting of an array of picture elements (pixels) with one or more digital code values per pixel
that represent a colour or tonal value
Note 1 to entry: A digital image can represent a natural scene or any kind of object.
3.1.17
international standardized profile
ISP
internationally agreed-to, harmonized document that identifies a standard or group of standards together
with options and parameters necessary to accomplish a function or set of functions
3.1.18
look-up table
LUT
collection of values used for translating image samples from one value to another
Note 1 to entry: The current sample value is used as an index into the look-up table(s); therefore, the number of entries
in each look-up table for a single bit per pixel image would contain two entries, and each look-up table for an 8-bit per
pixel image would contain 256 entries. Multiple look-up tables allow for the translation of a scalar pixel value to an
n-dimensional vector pixel value.
3.1.19
octet
sequence of 8 bits
3.1.20
pad pixel
pixel with sample values that have no significant meaning to the image
Note 1 to entry: Pad pixels are used with uncompressed block images when either the number of pixel rows in an
image is not an integer multiple of the desired number of vertical image blocks, or when the number of pixel columns
in an image is not and integer multiple of the desired number of horizontal image blocks. Pad pixels may or may not be
used with compressed block images depending upon the nature of the compression being used.
3.1.21
pad pixel mask
data structure that identifies recorded/transmitted image blocks that contain pad pixels
Note 1 to entry: The pad pixel mask allows applications to identify image blocks that require special interpretation
due to pad pixel content.
3.1.22
pixel
picture element
3.1.23
profile
instance of a pro forma that contains a set of one or more base standards, and where applicable, the
identification of chosen classes, subsets, options, and parameters of those base standards, necessary for
accomplishing a particular function
Note 1 to entry: BIIF Profiles are used for specific communities such as the Treaty on Open Skies community.
3.1.24
profile variant field
field within this basic standard that is allowed to be defined by a BIIF profile for its structure and intent
(content)
Note 1 to entry: An element or an attribute that is allowed to differ between BIIF profiles.
© ISO/IEC 2025 – All rights reserved
3.1.25
required field
data field that shall be present and filled with valid data or default data
3.1.26
reserved extension segment
RES
reserved BIIF segment-based construct for metadata extension
Note 1 to entry: The RES construct is reserved for data types that need to be placed at or near the end of the file. The
RES structure is discussed in Subclause 4.2.8.4.
3.1.27
sample
element in the image array that comprises an attribute of the image
Note 1 to entry: In BIIF, a sample (pixel vector value) is indexed according to the row and column of the array where it
appears.
3.1.28
synthetic aperture radar image
SAR image
image obtained from a synthetic aperture radar system
3.1.29
SARIQ
radio hologram (initial phase information) from a synthetic aperture radar system
3.1.30
segment
instance of a standardized data type structure that is contained in a BIIF file
Note 1 to entry: A segment is comprised of a subheader and associated data (e.g., an image subheader together with
image data comprises an image segment).
3.1.31
symbol
pictorial element that may be aligned with a point in or adjacent to an image to provide graphical markings
and/or textual labels
3.1.32
symbol text
annotation text
text placed on or adjacent to an image as a graphic symbol to provide a textual overlay to the image
3.1.33
tagged record extension
field-based data structure storing additional attributes about standard data segments that are not contained
in the standard header or subheader fields
3.1.34
transportable file structure
TFS
data extension element used for configuration, data request, commands, and PIKS object data to be stored in
hierarchical order with metadata associated at each level
Note 1 to entry: Transportable File Structures are defined and demonstrated in Annex A.
© ISO/IEC 2025 – All rights reserved
3.1.35
transport profile
member of the TFS Transport that contains PIKS data or other image-related object data
Note 1 to entry: Each Transport Profile contains metadata and security about the objects it contains. TFS Profiles
provide interoperability by specifying constraints on the TFS.
3.1.36
transparent pixel
pixel whose sample values shall be interpreted for display such that the pixel does not obscure the display of
any underlying pixel
3.1.37
YCbCr
technique for specifying colour images where Y = brightness of signal, Cb = chrominance (blue), and Cr =
chrominance (red)
3.2 Abbreviated terms
AL attachment level
ASN.1 Abstract Syntax Notation One
BCS basic character set
BCS-A basic character set – alphanumeric
BCS-N basic character set – numeric
BER Basic Encoding Rules
BIIF basic image interchange format
BMP basic multilingual plane
C conditional
CCS common coordinate system
CGM Computer Graphics Metafile
CS character string
DES data extension segment
DL display level
JPEG Joint Photographic Experts Group
LSB least significant bit
LUT look-up table
MSB most significant bit
NBPC number of blocks per column
NBPR number of blocks per row
PIKS Programmer’s Imaging Kernel System
© ISO/IEC 2025 – All rights reserved
PIKS1 PIKS foundation profile
PIKS2 PIKS technical profile
PIKS3 PIKS scientific profile
PIKS4 PIKS full profile
PVTYPE pixel value type
RES reserved extension segment
RGB red, green, blue
TFS transportable file structure
TRE tagged record extension
UCS universal multi-octet coded character set
UCS-2 UCS two octet form
UCS-4 UCS four octet form
UTC Coordinated Universal Time
UTF-1 UCS transformation format 1
UTF-8 UCS transformation format 8
YCbCr Y-brightness of signal, Cb-chrominance (blue), Cr-chrominance (red)
4 Basic image interchange format (BIIF) specification
4.1 Format overview
Imagery applications use multiple types of systems for the exchange, storage, and processing of images
and associated imagery data. The format used in one application is likely to be incompatible with formats
used in other applications. Since each application may use a unique, internal data representation, a common
format for interchange of information across applications is needed for interoperability of systems within
and across applications. This clause defines the basic image interchange format (BIIF) specification to
provide a common basis for storage and interchange of images and associated data among existing and
future applications. BIIF supports interoperability by providing a data format for shared imagery and an
interchange format for images and associated imagery data.
In BIIF, data interchange between disparate systems is potentially enabled by a translation process. Using
BIIF, each system has to be compliant with only one external format that will be used for communication
with all other participating systems. When BIIF is not used as a system’s native internal format, each system
will translate between the system’s internal representation for imagery and the BIIF format. A system from
which data is to be transferred has a translation module that accepts information structured according to
the system’s internal representation for images and related imagery data and assembles this information
into BIIF format. The receiving system will reformat BIIF data, converting it into one or more files structured
as required by the internal representation of the receiving system. Each receiving system can translate
selectively and permanently store only those portions of data in the received BIIF file that are of interest.
A system may transmit all of its data, even though some of the receiving systems may be unable to process
certain elements of the data. The functional architecture of this translation process is shown in Figure 1.
In the diagram, the terms “Native Mode” refer to imagery and imagery-related data represented in a way
potentially unique to the sending or receiving system, respectively.
© ISO/IEC 2025 – All rights reserved
Flexibility and extensibility of the use of BIIF are provided through the use of a constrained set of conditional
variable length fields and extension constructs. Imagery, together with Programmer’s Imaging Kernel
System (PIKS) objects, can easily be formatted into BIIF. This approach provides the proven capability to
implement general purpose BIIF readers (applications) that can present the basic imagery and annotations
of any BIIF compliant product file created within the constraints of a given profile of BIIF. Although more
robust approaches exist to allow ‘self-defining’ data structures, these approaches significantly increase the
complexity for implementing general purpose readers (applications) capable of meaningful interpretation
of file constructs created by a wide variety of diversely developed generators. More simplistic imagery file
formats also exist. They are often focused at just portraying a simple digital image and are often too limited
in feature sets to meet the needs of somewhat more sophisticated, but still basic imagery applications. BIIF
provides a basic capability that bridges the gap between simplistic digital image formats and the extremely
sophisticated, self-defining, but potentially complex formats. As such, BIIF has some inherent bounds and
limitations, but remains very capable as a basic imagery format capable of satisfying a broad range of
imagery applications.
Although few in number, certain aspects of this format reflect the legacy formats it is based on. For example,
pixel coordinate indexing as described in subclause 4.1.4.2.
BIIF supports extensibility [through the use of its data extension segment (DES) and reserved extension
segment (RES)] which empowers new applications while maintaining backward compatibility. Newly
defined data can be linked via a DES/RES and utilized by a new application or ignored by a legacy system.
This will ensure backward compatibility to older systems while incorporating new technology.
Figure 1 — Translation process
4.1.1 Description
The following subclauses provide the descriptions of BIIF data format fields, standard data types, extensions,
Transportable File Structure (TFS) elements, and complexity levels, as used in the specification of the BIIF
file format.
4.1.1.1 Format fields
BIIF format structure consists of a combination of both fixed octet length fields and variable octet length
fields. In its most basic application, the use of variable length fields is minimized to deal with the basic issues
of the variable number and size of images and the variable number and size of image annotations that may
appear in a BIIF file. The format contains header, subheader, and data fields. BIIF header and subheader fields
© ISO/IEC 2025 – All rights reserved
are octet aligned. The file header carries information about the identification, security, structure, content,
size of the file as a whole, and size of the data segments within the file. A data segment structure is defined
for each kind of data supported by the format. Each data segment in the file has a subheader containing
information that describes characteristics of the data segment and an associated data field that contains the
actual data. BIIF encoding is discussed in subclause 4.2.3.
4.1.1.2 Standard data types
A BIIF file supports inclusion of three standard types of data in a single file: image, symbol, and text. It
is possible to include zero, one, or multiple data segments of each standard data type in a single file (for
example: several images, but no symbols). Standard data types shall be placed in the file in the following
order: all image data segments (images), followed by all symbol data segments (symbols including symbol
text), followed by all text segments (documents or text). Additional kinds of data may be included in a BIIF
file by use of Data Extension Segments (DES) (see subclause 4.2.8), such as the Transportable File Structure
(TFS Annex A), and Reserved Extension Segments (RES) (see subclause 4.2.8.4). A data segment of a standard
data type is called a standard data segment. A data segment of a type defined in a DES or RES is called an
extension data segment. The order of these major file components is illustrated in Figure 2.
Figure 2 — Structure
4.1.1.3 Extensions
Flexibility to add support for kinds of data and data characteristics not explicitly defined in this document is
provided within the format. This is accomplished by providing for one or two fields in each header/subheader
containing "tagged record extensions" and by use of DESs and RESs. The tagged records extensions (TREs)
in the header/subheaders may contain additional characteristics about the corresponding data segment,
while the extension segments are intended primarily to provide a vehicle for adding support for new
kinds of data. The identifier (tag name) for the tagged records, and extension segment identifiers, will be
coordinated centrally in accordance with this document to avoid conflicting use. In some cases, tagged
record and extension formats will be configuration managed to control changes to data formats affecting a
broad BIIF user base.
All implementations of BIIF should handle the receipt of unknown extension types by at least recognizing they
are unknown extension types and ignoring them. This is accomplished through the octet count mechanism
of the extension identifier plus length field approach for bounding separate content types in the format. The
octet length offsets allow an interpret implementation to skip past unknown extensions and interpret the
known meaningful content elements of the BIIF file. This concept is basic to BIIF interpretation; a reader can
always identify octet count offsets and move on to other elements of the file. A quality implementation will
have the provision to alert the user of unknown entities that are skipped over to ensure the user does not
infer from the presentation of the file that all file contents have been fully interpreted and made available
for use by the user.
The BIIF file header and each standard data segment subheader have designated expandable fields to
allow for the optional inclusion of extension data (tagged record extensions). The inclusion of extension
© ISO/IEC 2025 – All rights reserved
data provides the ability to add data/information about the standard data segment (metadata) that is not
contained in the basic fields of the headers and subheaders. The additional data is contained within one
or more BIIF tagged record extensions that are placed in the appropriate field (user defined data field or
extended data field) of the standard data segment subheader for which the metadata applies. When Tagged
Record Extensions have application across multiple data segments in the file, or otherwise apply to the
entire BIIF file in general, they are placed in the appropriate file header extension fields.
Exemplary use of tagged record extensions:
— data about people, buildings, places, landmarks, equipment, or other objects that may appear in the image;
— data to allow correlation of information among multiple images and annotations within a BIIF file;
— data about the equipment settings used to obtain the digital image, x-ray, etc.;
— data to allow geopositioning of items in the image or measurement of distances of items in the imagery.
4.1.1.4 Transportable file structure (TFS)
The Transportable File Structure (TFS) Data Extension Element allows for the transport of the Programmer’s
Imaging Kernel System (PIKS) object data and other image related data. The TFS is a simple metafile that
allows for both relational and hierarchical structures of image-related data to be stored in BIIF. Each TFS
contains one or more Transports. The Transports allow for the grouping of image-related data for a specific
reason. For example, the Transport could contain all the required information about a medical patient to
include imagery, PIKS objects for the imagery, and a complete medical history of the patient. In the case
of remote sensing, the Transport can contain area of interests, specific locations, and explanations of
features on the image. Each Transport contains one or more Profiles which contain PIKS object data or other
image-related object data. TFS object data either contains data for the object or provides an unambiguous
reference to the data. Profiles are related together when they occur at the same level in the metafile. For
example, when a Transport contains an image Profile and several PIKS object Profiles, it is implied that the
PIKS objects are related to the image. A Profile can also be nested within a Profile to represent complex
hierarchical structures. Each TFS, Transport, and Profile contains metadata about itself and its contents,
security about the data, and an index into the next levels for quick access. Although the TFS can be used
to describe complex data structures about the image, PIKS data objects relating to an image can be simply
expressed using one Transport and one Profile. The Transportable File Structure is completely described in
Annex A. Example uses of TFS are given in Annex E.
4.1.1.5 Complexity levels
The BIIF uses the concept of complexity levels to allow definitions of a set of nested features and constraints
to exist within a user domain served by a specific profile of BIIF. It allows a user application to quickly
identify the degree of complexity of the number and combinations of BIIF features used in any specific BIIF
file within this given BIIF profile. For example, the BIIF Model Profile in Annex C allows a file marked at
complexity level 01 to have one image segment and no symbol segments, text segments, or data extension
segments. A Model BIIF profile file marked at complexity level 02 may have up to 20 image segments, 100
symbol segments, 10 text segments and 20 data extension segments.
4.1.2 Interoperability/exchange
Within a BIIF Profile, the term interoperability is used to express the ability of two or more imagery users
within the same community of interest operating in a heterogeneous computing environment, to accurately
create and/or recognize BIIF file structure as prescribed in this document, and meaningfully exchange the
information contained in it. This document also promotes a higher degree of interoperability among two or
more diverse communities of interest through the selection of a common set of functionalities captured in
specific BIIF profiles and implementation agreements.
4.1.3 Fields
The following subclauses describe general requirements related to data validity, the representation of date
and time expressions, and the representation of text-based information within BIIF files.
© ISO/IEC 2025 – All rights reserved
4.1.3.1 Valid data
All header and subheader fields contained in the BIIF file shall contain valid data (that is, data in accordance
with the restrictions specified for the contents of the field in this document or as constrained by an applicable
BIIF profile definition; Annex C) or the specified default value.
4.1.3.2 Date and time expressions
The representation of date and time shall be of the form CCYYMMDDhhmmss in accordance with the
provisions of ISO 8601:2004 for expressing combined date and time of day representations with the century
designator. All dates and times shall be expressed in Coordinated Universal Time (UTC).
The associated meaning of the CCYYMMDDhhmmss representation is:
— [CC] represents the digits used in the thousands and hundreds components of the time element “year”.
The range of ‘CC’ is ‘00’ through ‘99’;
— [YY] represents the digits used in the tens and units components of the time element “year”. The range
of ‘YY’ is ‘00’ through ‘99’;
— [MM] represents the digits used in the time element “month”. The range of ‘MM’ is ‘01’ through ‘12’;
— [DD] represents the digits used in the time element “day”. The range of ‘DD’ is ‘01’ through ‘31’;
— [hh] represents the digits used in the time element “hour”. The range of ‘hh’ is ‘00’ through ‘23’;
— [mm] represents the digits used in the time element “minute”. The range of ‘mm’ is ‘00’ through ‘59’;
— [ss] represents the digits used in the time element “second”. The range of ‘ss’ is ‘00’ through ‘59’.
4.1.3.3 Representation of textual information in fields
BIIF uses two different categories (BCS, UCS) of textual data character representations. Each category has
a set of constraints for use within header and subheader fields. UTF 8 is used in selected header fields. BCS
(BCS-A and BCS-N) and UCS (UTF 8) character representation are allowed in header and sub-header fields.
BCS and UCS character codes are allowed for use in the data fields of text segments (see subclauses 4.1.3.3.1
to 4.1.3.3.5).
4.1.3.3.1 Basic character set
The Basic Character Set (BCS) is used when populating header and subheader fields of BIIF. The
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...