ISO/IEC 12087-3:1995

INTERNATIONAL ISO/IEC
STANDARD
12087-3
First edition
1995-02-15
Information technology - Computer
graphics and image processing - Image
Processing and Interchange (IPI) -
Functional specification -
Part 3:
Image Interchange Facility (HF)
Technologies de I’information - Infographie et traitement de I’image -
- Spkcifica tion fonctionnelle -
Traitement de I’image et behange (/PI)
Partie 3: Accessoires pour I’khange d’images (HF)
J
Reference number
ISO/1 EC 12087-3: 1995(E)
ISO/IEC 12087-3: 1995(E)
Contents
iv
Foreword .
V
...............................................................................................................................................
Introduction
. . 1
Scope .
...........................................................................................................................
Normative references
...............................................................................................................
Definitions and abbreviations
.................................................................................................................................
3.1 Defini tions
3.2 Abbreviations .
.......................................................................................................................
The IPI-IIF architecture
.................................................................... 6
4.1 The IPI-IIF Data Format and the IPI-IIF Gateway
..............................................................
4.2 Interworking between IPI-IIF Gateway and IPI-PIKS
...........................................................................................................
5 The IIF data format (IIF-DF)
..................................................................................................
5.1 Basic features of the IIF-DF
..................................................................... 9
S.l.1 Objects that are expressed in the IIF-DF
.............................................................................................................
51.2 Syntax notation
..........................................................................................
5.1.3 Encoding of Syntax entities
.......................................
51.4 Rules that are not formally expressed within the IIF Syntax
...............................................................................................
5.2 Structure of the IIF-DF Syntax
5.2.1 Overall structure .
...........................................................................................................
5.2.2 Image structures
5.2.3 Placement of Pixel fields .
...............................................................................................
5.2.4 Encoding of Pixel fields
.......................................................... 14
5.2.5 Attributes, annotations, and image-related data
.................................................................................................
5.3 Syntax entities of the IIF-DF
5.3.1 Entities for the description of the entire IIF-DF .
..........................................................................
5.3.2 Entities for the description of images
................................
5.3.3 Entities for the description of the representation of Pixel values
........................................................ 59
5.3.4 Entities for the description of image-related data
............................................................ 79
5.3.5 Entities for the description of image attributes
5.3.6 Entities for the description of image annotations .
......................................................... 114
5.3.7 Entities for the description of basic data objects
0 ISO/IEC 1995
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronie,
or mechanical, including photocopying and microfilm, without Permission in writing from the publisher.
ISO/IEC Copyright Office 0 Case Postale 56 0 CH- 12 11 Geneve 20 0 Switzerland
Printed in Switzerland
ii
ISO/IEC 12087=3:1995(E)
6 IPI-HF Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Standardized profiles for the IIF-DF
...................................................................................
6.1.1 Full PIKS Profile of the IIF-DF
6.1.2 Foundation Profile of the IIF-DF .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Registered profiles for the IIF-DF
....................................................................................
6.2.1 Application-specific semantics
6.2.2 Constraining methods .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Extension methods
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 IPI-IIF Gateway functionality
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Basic categories of IPI-IIF Gateway functions
7.1 .l Gateway control and error handling .
...................................................................................
7.1.2 Import and export functionality
7.1.3 Parse and generate functionality .
..............................................................................
7.1.4 Data structure access functionality
...................................................................
7.1.5 Data structure manipulation functionality
7.1.6 Compression and decompression functionality .
..............................................................................
7.1.7 Application-oriented functionality
7.2 IPI-IIF gateway-intemal tables .
....................................................................................
7.3 Survey of IPI-IIF Gateway functions
.................................................................... 139
7.4 IPI-IIF Gateway functionality by manual pages
............................................................................................
7.5 PIKS-IIF interworking protocol
Annexes
................................................. 194
A List of IIF-DF Syntax entities and component names (normative)
.......................................................
B List of IPI-IIF Gateway function-caused errors (informative)
................................................................... 210
C Typical IIF image interchange scenario (informative)
.....................................................................................
D Examples of IIF-DF images (informative)
D.l Simple binary image .
..........................................................................
D.2 Colour image with colourimetric attributes
...........................................................................................................................
D.3 Tiled image
..............................................
E Example program for the use of the IPI-IIF Gateway (informative)
............................................................................................
F IIF-DF Syntax diagrams (informative)
...................................................................................................................................
G Bibliography
. . .
ISO/IEC 12087-3: 1995(E)
Foreword
ISO (the International Organization for S tandardization) and IEC (the International Electrotechnical
Commission) forrn 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,
govemmental and non-govemmental, in liaison with ISO and IEC, also take part in the work.
In the field of international technology, ISO and IEC have established a joint technical committee, ISO/IEC
JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national
bodies for voting. Publication as an International Standard requires approval by at least 75 % of the
national bodies casting a vote.
International Standard ISO/IEC 12087-3 was prepared by the Joint Technical Committee ISO/IEC JTC 1,
Information technology.
ISOIIEC 12087 initially consists of three Parts, under the general title Information technology -
- Image Processing and Interchange (IPI) - Functional
Computer graphics and image processing
specification:
Part I: Common architecture for imaging
- Part 2: Programmer’s imaging kernel System application program interface
- Part 3: Image Interchange Facility (IIF)
Annex A forms an integral part of this part of ISO/IEC 12087. Annexes B to G are for information only.
iv
ISO/IEC 12087=3:1995(E)
Introduction
ISO/IEC 12087-1 establishes the conceptual and architectural framework for ISO/IEC 12087. 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 IPI-IIF.
ISO/IEC 12087-2 establishes the specification of the Programmer’s Imaging Kerne1 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 could 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 could become part of application-oriented OS1
communications protocols.
Within the IIF data format (IIF-DF), compressed images may be specified and interchanged. For this
purpose, the following Standards are referenced:
- CCITT Rets. T.4 and T.6 (Facsimile)
- ISO/IEC 11544 (JBIG)
- ISO/IEC 10918 (JPEG)
- ISO/IEC 11172 (MPEG-1)
Image data streams that conform to the encoded representation of compressed image data specified by
these Standards may be included in the IIF-DF. For instance, a time series image tan be represented as an
array of time slices, each of which is encoded according to the JPEG Standard. Furthermore, the IIF-DF
allows images to be represented through the combination of compressed Parts with uncompressed parts. It
is also possible to use multiple compression methods within a Single IIF-DF-conformant image. For
instance, a colour image tan be represented as tiled images whereby some tiles are encoded according to
the lossy mode of the JPEG Standard and others according to the lossless mode. For detailed information
conceming compressed data streams and compression/decompression functionality, refer to 5.3.3 and
7.1.6, respectively.
There are various possibilities for interaction and data exchange between the IPI-PIKS domain and the IPI-
IIF domain. Both domains are controlled by the application via application program interfaces (APIS). For
a detailed description of the interworking between the IPI-PIKS and the IPI-IIF refer to clause 4 (the IPI-
IIF architecture) and clause 7 (the IPI-IIF Gateway functionality). For a description of the relation between
the types of objects that may be interchanged by means of the IPI-IIF and those types of objects that may
be processed by the IPI-PIKS, refer to clause 6 (the profiles for the IIF data format). Refer also to ISO/IEC
12087- 1.
ISO/IEC 12087-3: 1995(E)
vi
INTERNATIONAL STANDARD 0 ISO/IEC ISO/IEC 12087=3:1995(E)
Information technology - Computer graphics and image
processing - Image Processing and Interchange (IPI) -
Functional specification -
Part 3:
Image Interchange Facility (IIF)
1 Scope
This part of ISO/IEC 12087 facilitates the interchange of digital images. For this purpose, conceptual,
architectural, and functional definitions of the Image Interchange Facility (IPI-IIF) are established.
ISO/IEC 12087-3 consists of two major Parts, the:
a) IIF data format (IIF-DF) definition (by means of a formal Syntax, described according to the
Abstract Syntax Notation One (ASN. 1) -- refer to clause 5), and the
b) IIF Gateway definition (by means of a manual page description of the functionality of an
Application Program Interface (API) -- refer to clause 7).
An IPI-IIF-conformant implementation has to fulfill the functionality specification of the IIF Gateway, as
outlined in clause 7. Besides the IIF Gateway, there may be information processing Systems (Software such
as parsers, generators, etc.) which read and/or write the IIF-DF.
The IPI-IIF is based on the definitions described in ISO/IEC 12087-1, the “Common Architecture for
Imaging”. The IPI-IIF, as a whole, may be characterized briefly as follows:
By means of the IIF data format and Gateway, image data objects and image-related data objects
C>
are transported to and from application environments.
By means of the full PIKS Profile of the IPI-IIF data format (i.e., a formst for data interchange
d)
between IPI-IIF and IPI-PIKS), image data objects and image-related data objects are imported to
and exported from the Programmer’s Imaging Kerne1 System (IPI-PIKS), defined in ISO/IEC
12087-2.
The IPI-IIF facilitates the storage of image data objects and image-related data objects in a variety
e)
of pre-defined storage modalities, including different periodicity organizations, such as pixel-
interleaving or band-interleaving.
This part of ISO/IEC 12087 defines Syntax of image data (and image-related data) streams. The
fl
encoding of IIF data types is defined in ISO/IEC 12089. See also 5.3.3.
The IPI-IIF supports a concept of standardized conforrnance profiles. Initially, three conformance
g)
profiles are defined within ISO/IEC 12087.
An IIF data stream may be stored in devices such as file Systems. An IIF data stream may be
h)
interchanged and communicated in data networks (e.g., LANs and WANs) or in other data
communication facilities. All low-level data storage and transfer is delegated, for instance, to the
operating System of the target hardware.
The IIF Gateway performs compression and decompression of image data objects using
standardized compression and decompression techniques. These techniques are referenced in this
part of ISO/IEC 12087. See 1.4.5 and 5.3.3 and 7.5 for further definition.

ISO/IEC 12087-3: 1995(E)
j) The IIF Gateway is accessible via an API to perform image interchange functions. See clause 7 for
a definition of IIF Gateway functionality.
Reference shall be made to this part of ISO/IEC 12087, and its definitions shall be employed, whenever
images are interchanged, according to the IPI-IIF, among different imaging applications environments or
among imaging devices. The IPI-IIF is applicable to seenarios requiring the interchange of digital images,
as outlined in Annex C.
The use of the IIF data format as a superset of the functionality of most of the existing image interchange
formats solves the Problem of application-independent syntactical and semantical interpretation and
understanding of image data.
The IPI-IIF is applicable to image interchange in and among different application domains. The following
application areas have been considered:
Medical imaging
Remote sensing
Publishing
Industrial Vision
Computer graphics arts
Computer animation
Scientific visualization
Mission planning
Document processing
Outdoor Scene Surveillance
The limiting of the IPI-IIF scope to certain application domains is a matter of profiling. This is treated in
clause 6.
NOTE - Whether an image interchange format may also be regarded as a device format, depends on the (local)
processing power of the device itself. Thus a conceptually “high-level” format which has become an industrial
Standard page description language for desktop electronie publishing, tan be regarded as a device format. The IPI-
IIF may well be considered a device format if, for instance, there is an IPI-IIF-compatible Printer which is able to
receive, process, and hardcopy an image according to the IPI-IIF. In the same sense, it is reasonable to design IPI-
IIF-compatible image sources, e.g. IPI-IIF Camera Systems.
ISOAEC 12087-3:1995(E)
2 Normative references
The following Standards contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 12087. At the time of publication, the editions indicated were valid. All Standards are
subject to revision, and Parties to agreements based on this part of ISO/IEC 12087 are encouraged to
investigate the possibility of applying the most recent editions of the Standards indicated below. Members
of IEC and ISO maintain registers of currently valid International Standards.
ISO 2022: 1986, Information processing - ISO 7-bit and B-bit coded Character sets - Code extension
techniques.
ISO/IEC 8613: 1994, Information processing Systems - Text and ofice Systems - Open Document
Architecture (ODA) and Interchange Format (ODIF).
ISO/IEC 8632: 1992, Information processing systems - Computer graphics - Metafile for the storage and
transfer of picture description information.
ISO/IEC 8824: 1990, Information technology - Open Systems Interconnection - SpeciJication of Abstract
Syntax Notation One (ASN.1).
ISO/IEC 8825: 1990, Information technology - Open Systems Interconnection - Specijication of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
ISO/IEC 8879: 1986, Information processing Systems - Text and ofice Systems - Standard Generalized
Markup Language (SGML).
ISOIIEC 9069: 1988, Information processing Systems - SGML support facilities - SGML Document
Interchange Format (SDIF).
Framework and taxonomy of International
ISO/IEC TR 1 OOOO- 1: 1990, Information technology -
Standardized Profiles - Part 1: Framework.
Framework and taxonomy of International
ISOIIEC TR 10000-2: 1994, Information technology -
Standardized Profiles - Part 2: Principles and taxonomy for OSI Profiles.
Distribu ted o@ce application
ISO/IEC 1003 1- 1: 1991, Information technology - Text and ofice Systems -
model- Part 1: General model.
ISO/IEC 1003 l-2: 1991, Information technology - Text and ofice Systems - Distributed ofice application
model- Part 2: Distinguished Object reference and associated procedures.
ISO/IEC IO9 18- 1: 1994, Information technology - Digital compression and coding of continuous- tone still
Part 1: Requirements and guidelines.
images -
ISO/IEC 10918-2: To be published., Information technology - Digital compression and coding of
continuous-tone still images - Part 2: Compliance testing.

ISO/IEC 12087-3: 1995(E)
Coding of moving pictures and associated audio for
ISO/IEC 11172-1: 1993, Information technology -
digital storage media up to about 1,5 Mbitls - Part 1: Systems.
Coding of moving pictures and associated audio for
ISOLEC 11172-2: 1993, Information technology -
digital storage media up to about 1,5 Mbitls - Part 2: Video.
Coding of moving pictures and associated audio for
ISO/IEC 11172-3: 1993, Information technology -
digital storage media up to about 1,5 Mbitls - Part 3: Audio.
Coded representation of picture and audio information -
ISO/IEC 11544: 1993, Information technology -
Progressive bi-level image compression.
Computer graphics and image processing - Image
ISO/IEC 12087- 1: 1995, Information technology -
- Part 1: Common architecture for imaging.
Processing and Interchange (IPI) - Functional speciflcation
‘), Information technology - Computer graphics and image processing - Encoding for
ISO/IEC 12089:-
the Image Processing and Interchange Standard (IPI) - Encoding for the Image Interchange Facility (IIF).
CCITT Rec. G.7 11(1984), Coding of analogue Signals by pulse code modulation.
CCITT Rec. G.721(1984), 32 Kbitls Adaptive Differential Pulse Code Modulation (ADPCM).
CCITT Rec. T.4( 1988), Standardization of Group 3 Facsimile Apparatus for Document Transmission.
CCITT Rec. T.6( 1988), Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile
Apparatus.
CCITT Rec. T.30( 1988), Procedures for Document Facsimile Transmission in the General Switched
Telephone Network.
NOTES
All normative references which are common to Parts 1 to 3 of ISO/IEC 12087 are included in ISO/IEC
12087- 1. In ISO/IEC 12087-3, only the IIF-specific references are listed.
2 References to documents which are neither ISO/IEC Standards nor CCITT Recommendations are given in
Annex G.
3 Some ISO Standards are technically aligned with CCITT Recommendations, in particular the ASN.1
Standard (ISO Standards 8824/8825 and CCITT Rets. X.208/X.209). The differentes between the International
Standard definitions and the CCITT definitions are quite small, and should not affect interoperability between
implernentations written against either document. Within this part of ISO/IEC 12087, the ISO Standards are
referenced whenever possible.
1) To be published.
ISO/IEC 12087-3: 1995(E)
3 Definitions and Abbreviations
3.1. Definitions
For the purpose of this part of ISO/IEC 12087, the definitions given in ISO/IEC 12087-1 apply.
3.2. Abbreviations
Application Program Interface
API
Abstract Syntax Notation One
ASN. 1
BER Basic Encoding Rules
Comite Consultatif International Telegraphique et Telephonique
CCITT
CGM Computer Graphits Metafile
Discrete Cosine Transform
DCT
DOAM Distributed Office Application Model
Distinguished Object Reference
DOR
FOD Interchange Format and Representation Profile of Office Documents
FTAM File Transfer, Access and Management
Image Interchange Facility - Data Format
IIF-DF
IPI Image Processing and Interchange
IPI - Common Architecture for Imaging
IPI-CA1
IPI-IIF IPI - Image Interchange Facility
IPI-PIKS IPI - Programmer’s Imaging Kerne1 System
Joint Bi-level Image Experts Group
JBIG
JPEG Joint Photographit Experts Group
LAN Local Area Network
Message Handling System
MHS
MOTIS Message-Oriented Text Interchange Systems
MPEG Moving Pictures Experts Group
Open Document Architecture
ODA
Open Systems Interconnection
OS1
Packed Encoding Rules
PER
SGML Document Interchange Format
SDIF
Standard Generalized Markup Language
SGML
Wide Area Network
WAN
ISO/IEC 12087-3: 1995(E)
4 The IPI-IIF Architecture
4.1 The IPI-IIF Data Format and the IPI-IIF Gateway
As outlined in clause 1, the IPI-IIF consists of the specification of a data format and the specification of
functionality. The data format is called Image Interchange Facility Data Format (IIF-DF). It is described in
clause 5. Clause 6 describes conformance profiles for the IIF-DF.
The functional component of the IPI-IIF is called IPI-IIF Gateway. It is described in clause 7. The IPI-IIF
Gateway functions are called by an application program via a specific API (Application Program
Interface). Concerning data interchange, it provides functionality for
the import of image data to and export of image data from application, as well as
a>
b) the import of image data to and export of image data from the IPI-PIKS.
Part of the IPI-IIF Gateway functionality deals with the differing complexity of the IPI-IIF data types
(clause 6 of ISO/IEC 12087- 1) and the IPI-PIKS data types (clause 5 of ISO/IEC 12087- 1). The IPI-IIF
data types are defined according to the (generic) IPI data types that are introduced in clause 4 and form a
superset of the IPI-PIKS data types. The IPI-IIF data types support compound and heterogeneous image
structures of arbitrary hierarchical organization whereas the IPI-PIKS data types support five-dimensional
images with limited heterogeneity. The IPI-IIF Gateway provides a general mechanism - called
attachdetach functionality - to combine simpler IIF structures into more complex ones, and extract simpler
structures from more complex ones. Hence, this functionality represents the interface between the IPI-IIF
data types (that are interchangeable by means of the IPI-IIF) and the IPI-PIKS data types (that tan be
processed by the IPI-PIKS, but also interchanged by the IPI-IIF).
The IPI-IIF Gateway function classes are:
c) Gateway control functionality: These functions are used to open and close the IPI-IIF Gateway, to
inquire about its Status, and to handle errors.
Import and export functionality: These functions allow for the import and export of image and
d)
image-related data to and from the IPI-IIF Gateway via the application program.
) Parse and generate functionality: These functions allow for the translation between IPI-IIF data
streams (according to the IPI-IIF data format) and IPI-IIF gateway-intemal data structures that are
accessible and manipulable via IPI-IIF Gateway functions of category f) and g), respectively.
) Data structure access functionality: These functions allow for the access of parsed image data
structures. This includes tree traverse, inquiry, put value, and get value functions.
Data structure manipulation functionality: These functions allow for the manipulation of image
g)
structures. Create, delete, attach, and detach functions are provided.
Compression and decompression functi .onality: Functions are provided for the compression and
h)
decompression of Pixel fields according to the Standards listed in section 1.4.3.
i) Application-oriented functionality: This category encompasses functions which perform at the
same time multiple functional Steps according to categories c) to h). Seen from the application,
these functions are located on a higher (and thus more application-oriented) level.
The specification of the functions is given in clause 7.
ISO/IEC 12087-3: 1995(E)
4.2 Interworking between IPI-IIF Gateway and IPI-PIKS
The interworking (i.e. data flow and function calls) of the IIF Gateway and the IPI-PIKS for image data
interchange is depicted in Figure 1. The diagram Shows three domains, called the “application domain,” the
“IIF Gateway domain,” and the “IPI-PIKS domain.” These “domains” indicate whether a certain function or
data structure is part of the IPI-PIKS, the IIF Gateway, or the application program, respectively. The
arrows between (squeezed) Ovals indicate the data flow. Possible interworking situations include:
a) The imaging application program uses only an IIF Gateway, but no IPI-PIKS: The application
program may import and export image data which is interchanged using the IIF data stream. On
the other hand, the application program has the capability to process image data by means of
application-private imaging functions.
b) The imaging application program uses a non-IIF-capable IPI-PIKS and no IIF Gateway: In this
case, the IPI-PIKS conformance profiles defined in ISO/IEC 12087-2 describe the import and
export functionality of the IPI-PIKS.
c) The imaging application program uses an IIF-capable IPI-PIKS and no IIF Gateway: In this case,
the standardized import and export functions of the IPI-PIKS, if called by the application program,
produce image data according to the full PIKS Profile or the foundation Profile of the IPI-IIF data
format. The application program will be able to read data streams that conform to the Profile of the
IPI-IIF data format. The application program, as well as the import and export function of the IPI-
PIKS implementation, will have a parser and a generator for the IPI-IIF data format.
d) The imaging application program uses both an IPI-IIF Gateway and an IPI-PIKS: The
import/export, parse/generate and data structure access and manipulation functions work
according to a) and b), above. Further details are provided by the manual pages for these function
descriptions (see clause 7).
Besides, it is possible that the application program does not use the standardized import and export
functions, but explicitly (“manually”) controls the interworking of the IPI-IIF Gateway and the IPI-PIKS by
using only the import and export functions of the IPI-IIF Gateway and the IPI-PIKS Utility functions. In
this case, image data is transferred by the get-Pixel and put-Pixel functions from the IPI-PIKS to the
application domain, and vice versa.
If both the IPI-IIF Gateway and the IPI-PIKS are developed and supplied as one Software unit, the IPI-IIF
Gateway and IPI-PIKS APIS may be linked together. In this case, the intemal interworking between the
IPI-IIF Gateway and the IPI-PIKS may be designed to be more efficient. In either case, private, non-
standardized image data input and output may take place as shown by the dashed arrows in Figure 1. It is
up to the application program to manage the reading and writing of private image file formats and convert
the data into the IPI-IIF data forrnat. See also 7.1.2 for the specification of low-level data exchange
mechanisms of the IPI-IIF Gateway.
The IPI-PIKS functions relevant for the interworking of the IPI-PIKS with the IPI-IIF Gateway (defined in
ISOIIEC 12087-2) are:
e) input Object: data transfer from the IPI-IIF Gateway to the IPI-PIKS.
-
output-Object: data transfer from the IPI-PIKS to the IPI-IIF Gateway.
f3
The IPI-PIKS tan write and read image data streams only by means of the above-mentioned
input object/output Object functions. However, an application program may feed data to and from the IPI-
- -
PIKS with other Utility functions, such as get Pixel, put Pixel, and import/export. For further details, see
- -
ISO/IEC 12087-2.
application domain
private
readlwrite
imaae
implementation
(obje&*** / kbjects”’
\objects* , 1, \format** J
image
manipulation
PIKS elements compressl
decompress
PIKS domain HF gateway domain
standardized
*: within physical memory of PIKS
l *. non-standardized
. according to ASN.l specification
***: within physical memory of IIF gateway

ISO/IEC 12087-3: 1995(E)
of the BandRecord entity, the DataPlacement entity is called subentity.
NOTE - Only those constructed ASN.l data types for which a sequential Order is defined are used within ISO/IEC
12087. Thus the IIF Syntax always describes an unambiguously ordered data stream. However, concerning the
placement and periodicity organization of Pixel fields, the IIF-DF provides a maximum degree of flexibility.
S.l.3 Encoding of Syntax entities
The encoding of IIF Syntax entities is defined in ISO/IEC 12089.
NOTES
1 The encoding of IIF Syntax entities as defined in ISOAEC 12089 employs the Basic Encoding Rules for
ASN.l (BER), that are defined in ISO/IEC 8825. The encoding of a large Pixel data field according to the BER
tan produce considerable space and processing time overhead when every Pixel is expressed as an elementary
ASN.l data entity, consisting of a “tag” and a “length” field that precedes the “value” field. For this reason,
ISO/IEC 12089 provides some methods on how to encode fields of Pixel values as Single entities in terms of
ASN. 1. This refers to the ExternaZZyDe~nedDataUnit entity.
2 The BER provide a definite form and an indefinite form for the encoding of sequences of entities. Both are
indicated by the keyword “SEQUENCE OF.” In the definite form the number of content octets is given at the
beginning of the sequence. In the indefinite form the number of content octets shall be calculated by parsing the
whole sequence until the end-of-sequence token. Within the IIF-DF Syntax, for some “SEQUENCE OF”
constructs, a “number-of-.” component is provided. It specifies the number of entities (e.g., Pixel values) that are
present in the following sequence. This allows implernentations to make use of the number of entities in advance
(e.g., for memory allocation), regardless of what encoding method has been Chosen.
S.l.4 Rules that are not formally expressed within the IIF Syntax
There are rules and constraints within 5.3 that are needed in addition to the IIF Syntax to define a proper
IIF-DF. These rules and constraints are given by an accompanying text. They need to be checked within the
Parse and generate functions of the IPI-IIF Gateway, as illustrated in Figure 2.
IIF Gateway
IIF Gateway
,
f f
Parser &
Parser & ASN. 1 ASN. 1
- -
Constraint Checker
Constraint Checker Protocol Decoder Protocol Decoder
\
\ ,
Application 2
Application 1
Figure 2 - IIF-DF parser and constraint checker within the IPI-IIF Gateway
NOTE - The IIF Syntax is expressed using formal ASN.l notation, but not all rules or constraints that determine
the desired “correctness” of an IIF-DF-conformant data stream tan be expressed in terms of this Syntax. For
example, there is no way to define a Syntax that prevents the production of Pixel arrays that contain more or fewer
Pixels than defined in the array’s type definition. This deficiency, which is a result of the tontext-free grammar, is
only one example. Other examples of constraints that need to be defined “on top” of the IIF Syntax result from the
desire for maximum flexibility in Pixel data placement. In general, the number of constraints that need to be
defined in addition to the Syntax is a result of the tradeoff between flexibility and formal elegante. Furthermore,
one may distinguish between various levels of constraints. Those constraints that determine, for instance, the
completeness of Pixel fields, are of a different nature as compared to constraints that deal with inconsistent colour
attributes.
ISO/IEC 12087-3: 1995(E)
5.2 Structure of the IIF-DF Syntax
This clause gives an overview of the structure of the IIF-DF Syntax. The reader may study the following
description of major IIF-DF Syntax entities in conjunction with the three example images provided in
Annex D and the IIF-DF Syntax diagrams provided in Annex F.
5.2.1 Overall structure
The FuZZDataFormat entity is the top-most entity of the IIF-DF Syntax tree. All other entities branch from
there. There are two types of information contained in the FuZZDataFormat entity. First, there is
information identifying the data as conforming to a particular Version, conformance level, and application
Profile of the IIF. This information is contained in the FormatDescriptor, Version, and Profile entities.
There is also a place to store some application-specific header information in the ContentsHeader entity.
Second, there is the data content.
NOTE - Compound Syntax entities may consist of an arbitrarily deep tree of sub-entities. Thus the term
“something is contained (or stored) in a given Syntax entity” does not imply that the information is contained in the
named entity directly. It rather means that it is contained in either the entity or one of its subentities.
The data stored in the ContentsBody element tan be images, image-related data, attributes, annotations, or
basic data objects, as defined in ISO/IEC 120874. The Overall structure of the IIF-DF Syntax is shown in
Figure 3.
NOTE - Figure 3 does not represent a complete Syntax diagram. It is an abstract view of the IIF-DF Syntax. Many
details are left out. The solid boxes and arrows represent one possible instance of a Syntax tree. The dashed boxes
and arrows indicate potential alternatives according to the choices provided by the respective Syntax entities. For
an exact description of the IIF-DF Syntax, refer to 5.3.
:
Tl
.
=:- . z =
.
==--
-5
: --==-s-- :
-.
: -. --__---___ :
-. --w_ ----__ :
-. --s_
--w_
-.
:
-.
:
: .
i l
/ yImage ~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1
: :
.
:
: :
:
:
.
:
:
i i
:
! format identification, i title, owner, i description of the Felds of Pixel values; represented further images or other optional
image structure within one or more data units
: Version, Profile ! time, etc. data (e.g., attributes, annotations)
:
: :
________-_________._--.------.-----------.
Figure 3 - Overall structure of the IIF-DF Syntax.
ISOiIEC 12087-3: 1995(E)
5.2.2 Image structures
Images are stored in the Image entity and are Split into structural information and data, called image-
structure and image-data, respectively. As specified in the ImageStructure entity, an image tan be either a
compound image (such as arrays, records, lists or sets of other images) or a fundamental image. A
fundamental image is an n-dimensional array of Pixels which may consist of one or more bands. Images
tan have attributes and annotations associated with them.
The CompoundImageArray entity is used to specify an n-dimensional array of images; component images
are accessed via an n-dimensional index. All the images stored in an array must have identical structures
(including attributes, annotations, and image related data). The CompoundZmageRecord entity is used to
specify a record of images. The components are accessed via associated names, called component-
identifiers. In contrast to arrays of images, the components are not required to have identical image
structures. The CompoundZmageList entity is used to specify a list of images of identical structure which
are accessed via their Position in the list. The CompoundImageSet entity is used to specify a set of images
of identical structure. The Syntax of the ZmageStructure entity is recursive, i.e., the array elements, record
components etc. are again of ImageStructure type.
The FundamentaZImageStructure entity specifies the structure and sequential organization of an n-dimen-
sional multiband array of Pixels, along with associated image-related data, such as look-up tables,
histograms, etc. It and its sub-entities provide enough flexibility to specify a wide range of Pixel periodicity
arrangements (e.g. Pixel interleaved, band interleaved, tiled images, etc.). This is specified primarily by the
BandRecord and MetricArray entities as described below.
The BandRecord entity is used to specify Pixel arrays on a band-by-band basis; this entity is used to specify
a band-interleaved image. The MetricArray entity is used to specify arrays of Pixels or tiles. Pixels tan be
represented as a collection of bands in the PixeZStructure entity. Thus, Pixel-interleaved images are
specified using a MetricArray of PixelStructures. The Syntax of the MetricArray and BandRecord entities
allow for arbitrary recursions. Thus, tiled images may be specified by constructing an array of arrays using
the MetricArray entity for both hierarchical levels. Band-interleaved tiles are specified by a MetricArray
containing BandRecords. Pixel-interleaved tiles are specified by a MetricArray containing MetricArrays.
The recursive organization within the FundamentalImageStructure entity is illustrated in Annex F.
Entities specifying the structure of arrays in the IIF, such as MetricArrays and CompoundImageArrays,
contain components specifying the number of dimensions of the array, the size of the array along each
dimension, and a unique identifier for every dimension. The Serialization entity which is also part of every
array description, indicates which axis varies fastest, second fastest, and so on within the sequence of Pixel
values.
The various hierarchical levels of an image structure described by the IIF-DF Syntax are shown in Figure 4.
NOTE - Figure 4 does not represent a complete Syntax diagram. It is an abstract view of the IIF-DF Syntax. Many
details are left out. The solid boxes and arrows represent one possible instance of a Syntax tree. The dashed boxes
and arrows indicate potential alternatives according to the choices provided by the respective Syntax entities. For
an exact description of the HF-DF Syntax, refer to 5.3.
ISO/IEC 12087-3: 1995(E)
---_
---
‘JI
*-----------------
l
[ ImagcAnnotation ;
----,,,,,w,--,-m-J
ImagcStructurc
N-- -* ----____
2-w_
-.
cHC
-0. -- --__ -. --__ ---___ ---__
---_ ---_
c-
-0 -. -. --N_ --w_
---_
CH --v_ ---_
-.
--__
#CC -5 ---_
---_
-N
#* --w_
---_
.- r -. --s_
--s_
--
-a ---_
LyO --sh
--Q
,-------------;----------
,------------ ----- . ~----------------- ,-----------------
l
I I l
i 1 mageAnnotat ion : ___.____._______--.----.-
i CompoundImagcStructurc I i ImagcRclatcdData : i ImagcAttributc :
-------------,---,,-----J
-------------,,,-d ----m--,---------J -----------------J
_
(SJ /ccordCom ponq
lcvel of
fundamental
Figure 4 - Representation of image structures within the IIF-DF Syntax.

ISOLIEC 12087-3: 1995(E)
5.2.3 Placement of Pixel fields
As described above, the image-structure component of the Image entity and its subentities only contain
information describing the image structure. The associated fields of Pixel values are stored in the image-
data component. Various modes of data placement and various Pixel field encodings are permitted. The
“atomic portion” of Pixel data (a set of data that is always stored as one unit) is called a ReferencedUnit
(see Figure 3).
The DataPZacement entity associated with each of the image structure entities is used to indicate whether
the Pixel values associated with the image structure are stored together in a Single entity, called
Referencedhit, or whether they are distributed into multiple entities. There are three cases that must be
delineated.
The data associated with the structure is divided into multiple ReferencedUnit entities.
a>
The data associated with the structure is completely contained
...