ISO/IEC 12087-1:1995

INTERNATIONAL ISO/IEC
STANDARD 12087-1
First edition
1995-04-15
Information technology - Computer
graphics and image processing - Image
Processing and Interchange (IPI) -
Functional specification -
Part 1:
Common architecture for imaging
Technologies de I’information - Infographie et traitemen t de I’image -
Traitemen t de I’image et khange (/PI) - Spkification fonctionnelle -
Partie 1: Architecture commune pour I’image
Reference number
ISOAEC 120874 :1995 (E)
Contents
1 Scope. 1
2 NormativeReferences . . . . . . . . . . . . .,OO.ee.ee . . . . . . . . . o . .*.
....................................
3 Definitions and abbreviations
........................................................
Definitions
3.1
...................................................... 5
Abbreviations
3.2
............................................. 5
3.3 Diagrammatic Conventions
.........................................
4 The IPI architecture
................................................
4.1 IPI imaging architecture
..............................................
4.1.1 IPI imaging model
...................................... 8
4.1.2 IPI Operator processing model
...................................................
4.2 IPI basic data types
......................................... 10
4.2.1 IPI elementary data types
.......................................... 10
4.2.2 IPI compound data types
.................................................. 11
4.3 IPI imagedata types
............................... 11
4.3.1 IPI derived elementary image data types
................................
4.3.2 IPI derived compound image data types
........................................
4.3.3 IPI derived image attributes
......................................... 14
4.4 IPI derived non-image data types.
................................ 14
IPI derived image annotation data types
4.4.1
.......................... 14
IPI derived image-related non-image data types
4.4.2
........................................ 16
5 IPI-PIKS architecture
............................................... 16
IPI-PIKS imaging model
5.1
.................................... 16
5.1.1 IPI-PIKS neighbourhood control
.......................................... 17
5.1.2 IPI-PIKS image control
............................................... 17
5.2 IPI-PIKS System control
.......................................... 17
5.2.1 Data Object management
......................................... 18
5.2.2 Operational synchronicity
............................................... 18
5.2.3 Element chaining
.............................................. 18
5.2.4 Error management
............................................... 18
5.3 IPI-PIKS basic data types
..................................... 18
5.3.1 IPI-PIKS elementary data types
..................................... 19
5.3.2 IPI-PIKS compound data types
.................................... 22
5.4 IPI-PIKS derived image data descriptions
....................................... 22
5.4.1 IPI-PIKS derived data types.
................................. 22
5.4.2 IPI-PIKS compound image data types
.............................................. 23
5.4.3 Composite images
....................................
5.4.4 IPI-PIKS image Object attributes
.................................. 26
5.5 IPI-PIKS derived non-image data structures
................................................ 34
5.6 IPI-PIKS data pragmata
o ISO/IEC 1995
All rights reserved. Unless otherwise specified, 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 l Case postale 56 l CH-121 1 Geneve 20 l Switzerland
Printed in Switzerland
ii
@ ISO/IEC ISOAEC 1208791:1995 (E)
6 IPI-IIF-specific architecture
.....................................
6.1 IPI-IIF imaging model
.................................................
6.2 IPI-IIF basic data types .
6.3 IPI-IIF derived data types .
...................................
6.3.1 IPI-IIFderivedimagedatatypes.
IPI-IIF image attributes
6.3.2 .
IPI-IIF derived non-image data types
6.3.3 .
IPI-IIF image annotation data types .
6.3.3.1
6.3.3.2 IPI-IIF image-related non-image data types .
7 Relationship between IPI-PIKS and IPI-IIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Conformance .
8.1 Conformance of functionality .
8.2 Conformance of accuracy and precision .
8.3 Extensions
.........................................................
8.4 Conformance profiles
.................................................
8.4.1 Types of Profile
................................................
8.4.2 Application Profile registration .
8.4.3 Profiles defined by IPI .
Annexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A Structured image data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B Structurecodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C The representation of colour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
D Language-Independent Data Types .
.............................................................. 56
D.l Bit
D.2 Boolean .
D.3 Character .
D.4 Complex .
D.5 Enumerated
........................................................
D.6 Null .
D.7 Integer .
D.8 Real .
D.9 State .
D.lOArray .
D.llChoice .
D.12List .
......................................................... 64
D.13Pointer.
D.14Range .
D.15Record .
.............................................................. 66
D.16Set
D.17 Character String
.....................................................
............................................................
D.18Table
E Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
. . .
ISOAEC 12087~kl995 (E)
@ ISO/IEC
List of figures
Relationship of the Parts of ISO/IEC 12087 .
Diagrammaticconventions.~.~
....................... 6
Interfaces between application program, IPI-PIKS, and IPI-IIF . . . . . . . o . . . . . . . . . . . . . .
Fundamental Operator processing model . 9
The Operator model used by IPI-PIKS .
Relationship Between a Physical Volume and IPI-PIKS Horizontal, Vertical, and Depth
Coordinates .
7 Aggregation of Image References into a List .
8 Colour Systems and Representations Used by IPI . . . . . . . . . . . . . 0 . e e . 0 + n n . + . o + . . . 50

@ ISO/IEC ISOAEC 12087~1:1995 (E)
List of tables
Codes for the externally-visible representations of IPI-PIKS-specific data types 21
..........
Dimensions of an IPI-PIKS Data Object
..................................... 22
IPI-IIF profiles that correspond to IPI-PIKS profiles
............................ 44
IPI-PIKS profiles that correspond to IPI-IIF profiles 45
............................
XY 2 tristimulus values for the white Points of common illuminance 5 1
.................
Supported types of colour representation, and their attributes
....................... 53
............
Standardizedparameterisationsofcolours.~.*.~.~ 53
Parameter values for the standardized colour representations (non-normative) . 54
Mappings Between Colours and Image Channels 55
..............................

ISOAEC 12087~1:1995 (E) @ ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the Inter-
national 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. 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-1 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information techn&gy, Subcommittee SC 24,
Computer graphics and image processing.
ISO/IEC 12087 consists of the following Parts, under the general title Information
technology - Computer graphics and image processing - Image processing and
interchange (IPI) - Functional specification:
- Part 1: Common architecture for imaging
- Part 2: Programmerk imaging kerne1 System application Programme
interface
- Part 3: Image Interchange Facility (HF}
Annexes A to D form an integral part of this part of ISO/IEC 12087. Annex E is
for information only.
@ ISO/IEC
ISO/IEC 1208701:1995 (E)
Introduction
The processing of images is a requirement of many application areas of information processing. Early work
in these areas led to the development of many application program interfaces and a large number of image
representations for interchange. The purpose of ISO/IEC 12087 is to provide an application program interface
and an image interchange representation in Order to increase the portability of application Software.
ISO/IEC 12087 provides an architectural model for the representation and manipulation of images in a digital
form. Based on this model, it defines an application program interface and an image interchange format. It is
applicable to all application areas that involve the processing, manipulation, or transfer of image data.
ISO/IEC 12087 includes notes and exemplary material. Such material is non-normative: it is included solely
to aid understanding and does not form part of ISO/IEC 12087.
ISO/IEC 12087 initially comprises three Parts:
1 Common axchitecture for imaging, which describes the common architectural material on which the
entire Standard is based;
2 Programmeris imaging kerne1 System application program in terface, which defines processing opera-
tions to be carried out on image data;
3 Image In terchange Facili ty (IIF), which defines how images may be interchanged between application
programs.
Information may be interchanged between the application program, Programmer’s Imaging Kerne1 System
(IPI-PIKS), and Image Interchange Facility (IPI-IIF) (see figure ). Data paths between all three components
are standardized in ISO/IEC 12087, as indicated by the solid lines; however, it is also permitted that imple-
mentations may use private, implementation-dependent data paths, shown by dashed lines; such data paths
are outside the scope of ISO/IEC 12087.
There are a great many types of application that involve the use of images. The Computer Graphits Reference
Model [ISO 110721 identifies six main function classes (see figure 0.1):
image analysis - transformation of digital images to image and non-image data; this encompasses basic func-
tions such as histogram generation, mean value determination, image classification, etc., but does not
include image understanding using artificial intelligente techniques.
image interpretation -
the process of inferring symbolic Scene descriptions from image data.
image presentation - transformati .on of image data to a form suitable for an observ ‘er; e.g., via Video monitors,
Printers, film recorders, etc.
image processing - transformation of digital images to digital images; e.g., grey value contrast enhancement,
edge detection, etc.
image sensing - transformation of real-world information to digital images; e.g., via cameras, Optical scan-
ners, etc.
image Synthesis - transformation of non-image data to image data; this encompasses functions such as the
rendering of lines, creation of test images, Simulation of Sensor functions, letters of graphical text and
Symbols, etc.
vii
ISO/1 EC 120874 : 1995 (E) @ ISO/IEC
Application Program
-----m-w--------
IIF
PIKS
standardized data flow
----B-m
implementation-dependent data flow
Figure O.l- Data flow between the application program, IPI-PIKS, and IPI-IIF
As figure indicates, all these function classes involve the manipulation of a digital image; some function
classes also require information that is related to the data contained in the digital image but is itself non-image
in nature. This image-related information is essential to many of the common operations performed on digital
images and is therefore also described by ISO/IEC 12087.
ISO/IEC 12087 is also concerned with image interchange, the interchange of digital images among imaging
applications; this serves for the communication of image data and related non-image data among imaging
applications.
The term ‘digital image’ used in [ISO 110721 is synonymous with the term ‘image’ as used in ISO/IEC 12087.
It is important to realize the distinction between ‘image’ (or ‘digital image’) as used in ISO/IEC 12087 and
the term ‘image’ as it may be used colloquially: in ISO/IEC 12087, ‘image’ (or ‘digital image’) refers to a
particular representation of image data within a Computer System. An image may not be viewed directly. To
view an image, an explicit presentation step is involved, as figure indicates. Image data that are in a form
suitable for viewing by an observer are termed ‘presentable’ image data in ISO/IEC 12087.
NOTE 1 Some application areas, which might loosely be termed “image understanding,” utilize data derived from an
image by means of some analysis; such applications are therefore omitted from this ISO/IEC 12087. However,
ISO/IEC 12087 may be used by such applications.
This part of ISO/IEC 12087 fulfills the following purposes:
a) It provides an overview of ISO/IEC 12087;
b) It defines a Common Architecture for Imaging, an abstract architectural model for the representation
. . .
Vlll
ISOAEC 12087913995 (E)
@ ISOLIEC
Interpretation
Andvciq
Digital
Digital
Real
Cencino
World
-l
Presentation
_i
observer
Classes of operations on images
Figure 0.2 -
ix
ISOIIEC 120874 3995 (E) @ ISOAEC
and processing of image data. The purpose of this model is to define a common set of data types and a
common image representation for use with all other parts of ISO/IEC 12087 and to provide a standard-
ized framework upon which future imaging Standards may be built, allowing simplified conversion of
existing applications to the new Standard.
It defines rules to which conforming implernentations shall adhere and the mechanism by which con-
C>
formante is achieved.
INTERNATIONAL STANDARD @ISO/IEC ISO/IEC 12087~1:1995 (E)
Information technology - Computer graphics
and image processing - Image Processing and
Interchange (IPI) - Functional specification -
Part 1:
Common architecture for imaging
1 Scope
ISO/IEC 12087 is concerned with the manipulation, processing, and interchange of all types of digital images.
The main purpose of this part is to define a generic, unifying imaging architecture to which other Parts of
ISO/IEC 12087 conform. This part of ISO/IEC 12087 also defines those “specializations” or “delineations”
of the generic imaging architecture that are required to support IPI-PIKS and IPI-IIF.
The relationship of the different Parts of ISO/IEC 12087 is shown in figure 1. This part of ISO/IEC 12087
describes material that applies throughout ISO/IEC 12087, including topics such as data types available for
use in image data and image-related data, and a model for the processing of digital images by Operators. These
topics are presented in a general form, since it is intended that subsequent imaging Standards will conform to
the same architectural model.
Derived from this general description are more constrained descriptions of the Same topics. The principal
reason for this process of delineation is to restritt the range of data representations for IPI-PIKS and IPI-IIF,
while simultaneously ensuring that IPI-IIF is capable of interchanging both IPI-PIKS data objects and objects
that cannot be represented or manipulated within IPI-PIKS.
ISO/IEC 12087 permits multiple Application Program Interface (API)s to be developed, each of which must be
ISOAEC 120870kl995 (E)
@ ISOAEC
Generic Architecture (Part 1)
IPI-PIKS-Specific IPI-IIF-Specific
Architecture Architecture
L
1 r-----
Figure l- Relationship of the Parts of ISO/IEC 12087
based on specific delineations of the imaging model described herein. Esch API will be specified in a separate
part of ISO/IEC 12087. Any subsequent APIS developed as part of ISO/IEC 12087 must conform to the com-
mon architecture described in this document, and must be extensions of the APIS described in ISO/IEC 12087-
2 and ISO/IEC 12087-3.
ISO/IEC 12087 is intended for use in a wide variety of environments where digital images are handled.
NOTE 2 Application areas that are addressed by Image Processing and Interchange (IPI) include: image manipulation;
image enhancement; image analysis; and image transport. Application areas that are not addressed by IPI include:
Computer graphics; image understanding; multimedia; device control; and window Systems.
ISO/IEC 12087 is intended to conform with other International Standards developed to handle digital
Such Standards include the JPEG [ISO/IEC 10918-1:1994], and MPEG [ISO/IEC 11172-1:1993]
images.
compression Standards, Open Systems Interconnect [ISOLIEC 8824: 19901, and Office Document Architec-
ture [ISO/IEC 86131. Those aspects of ISO/IEC 12087 that are concerned with the acquisition and display of
digital images conform with the Computer Graphits Reference Model [ISO 110721. Furthermore, annex B of
[ISO 110721 describes how imaging fits within the general framework of that model. ISO/IEC 12087-3 uses
Abstract Syntax Notation 1 [ISO/IEC 8824: 19901 in the definition of the image interchange format.
ISO/IEC 12087 camplies directly with all Standards listed in clause 2.

@ ISOAEC ISO/IEC 12087~1:1995 (E)
2 Normative References
The following Standards contain provisions which, through reference in this text, constitute provisions of this
part of the IPI Standard. At the time of publication, the editions indicated were valid. All Standards are subject
to revision, and Parties to agreements based on ISO/IEC 12087 are encouraged to investigate the possibility of
applying the most recent editions of the Standards listed below. Members of IEC and ISO maintain registers
of currently valid International Standards.
ISOIIEC 646: 199 1, Information technology, ISO 7-bit coded Character set for information interchange.
ISOIIEC 8613: 1989, Information processing - Text and ofJice Systems - Oflce Document Architecture
(ODA) and interchange format.
ISO/IEC 8824: 1990, Information technology - Open Systems Interconnection - Specjfication of Abstract
Syntax Notation One ASN. 1.
ISOIIEC 8825: 1990, Information technology - Open Systems Interconnection - Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN. 1).
ISO/IEC 9973: 1994, Information technology, Computer graphics and image processing - Procedures for
registration of graphical items.
ISOIIEC 109 18- 1: 1994, Information technology - Digital compression and coding of continuous-tone still
images: Requirements and guidelines.
ISOIIEC 11072: 1992, Information technology - Computer graphics - Computer Graphits Reference
Model.
ISO/IEC 11172- 1: 1993, Information technology - Coding of moving pictures and associated audr’o for
digital storage media up to about 1,5 Mbit/s - Part 1: Systems.
CIE: 193 1, Proceedings of the eighth Session, Cambridge, England, 1931. Bureau Centrale de la CIE, Paris.
CIE: 1970, International Lighting Vocabulary. CIE publication no. 17, third edition, Bureau Centrale de la
CIE.
CIE: 1976, CIE recommendations on uniform colour space, colour differente equations, psychomatic colour
terms. Supplement no. 2 to CIE publication 15, Bureau Centrale de la CIE, Paris.
CCIR: 1990a, Report 476-1, Colorimetrjc Standards in colour television. Recommendations of the CCIR
1990, Annex to Volume XI - Part 1 - Broadcasting Service (Television), CCIR, Geneva.
Recommendation of the CCIR 1990,
CCIR: 1990b, Report 624-4, Characterization of television Systems.
Annex to Volume XI - Part 1 - Broadcasting Service (Television), CCIR, Geneva.
CCIR: 199Oc, Recommendation 709, Basic Parameter values of the HDTV Standard for the Studio and for
international Programme exchange. Recommendations of the CCIR 1990, Volume XI - Part 1 - Broadcasting
Service (Television), CCIR, Geneva.
EBU: 1975, EBU Standard for chromaticity tolerantes for Studio monitors. Tech. 3213-E, Brussels.
DeMarsh: 1974, Colotimetric Standards in U. S. color television. A report by the subcommittee on Systems
colorimetry of the SMPTE television committee. L. E. DeMarsh, Journal of the Society of Motion Picture
and Television Engineers, vol. 83.
NTSC: 1954, NTSC Signal specifications. Proceedings of the IRE, January 1954.
@ ISOIIEC
ISOAEC 120870IA995 (E)
3 Definitions and abbreviations
3.1 Definitions
For the purpose of ISO/IEC 12087, the following definitions apply.
3.1.1 digital image: Synonymous with image.
3.1.2 element: A collective noun used to describe mechanism, Operator, tool, and Utility.
3.1.3 image: A data structure that contains Pixels and image-related data.
3.1.4 image data: Digital values corresponding to Pixels.
3.1.5 image-related data: Information that provides context for the interpretation of an image.
3.1.6 mechanism: A Software element that performs control and management tasks.
3.1.7 Operator: A softwar-e element that performs manipulation of an image or set of images. Permitted
Operator types are image-to-image, image-to-non-image, and non-image-to-non-image.
- in which case they are said to be high-level Operators - or may
NOTE 3 Operators may be based upon other Operators
not, in which case they are said to be primitive. All classes of IPI-PIKS Operators, tools, and Utilities may be invoked
from an application program, but only Operators and Utilities interface directly to the underlying System.
3.1.8 primitive Operator: One of a small set of low-level Operators that is fundamental to image processing.
3.1.9 Pixel: An abbreviation for the term ‘picture element.’
NOTE 4 In some application areas, the term ‘Pixel’ commonly refers to 2D images only, with separate terms (e.g., ‘voxel’)
being used to describe an element of a higher-dimensional image. In this Standard, the Single term ‘Pixel’ is used to
refer an element of an image of any dimensionality.
3.1.10 picture element: A digital representation of one or more quantities at a particular location within an
Image. A picture element may have an associated physical metric, size, or interval.
3.1.11 tool: A softwar-e element that creates
data objects to be used Operators. Examples of tools are test
bY
generation and the generation of math
image .ematical functions
3.1.12 Utility: A Software element performs
that basic image manipulation operations (e.g., image import,
access, and memory management).
ISOAEC 12087~1:1995 (E)
@ ISO/IEC
3.2 Abbreviations
API Application Program Interface
CA1 Common Architecture for Imaging
CCIR Comite Consultatif International des Radiocommunications
CG1 Computer Graphits Interface
CGM Computer Graphits Metafile
CIE Commission Internationale d’Eclairage
CMY Cyan, Magenta, Yellow (colour model)
Cyan, Magenta, Yellow, Black (colour model)
CMYK
EBU European Broadcasting Union
GKS Graphical Kerne1 System
JPEG Joint Photographit Experts Group
IHS Intensity, Hue, Saturation (colour representation)
Image Interchange Facility
IIF
Motion Picture Experts Group
MPEG
Nuclear Magnetit Resonance
NMR
NTSC National Television Standards Committee
ODA Office Document Architecture
ODIF Office Document Interchange Format
PET Positron Emission Tomography
PHIGS Programmer’s Hierarchical Interactive Graphits System
PIKS Programmer’s Imaging Kerne1 System
RGB Red, Green, Blue (colour representation)
ROI region of interest (defined in clause 4.4.2)
SMPTE Society of Motion Picture and Television Engineers
3.3 Diagrammatic Conventions
Diagrams are used throughout ISO/IEC 12087 to support textual descriptions. The graphical items that com-
Prise these diagrams have a consistent meaning, as shown in figure 2, unless indicated to the contrary.

ISOAEC 12087~1:1995 (E)
@ ISO/IEC
API
function
data flow
---------e-w
->
control flow
data structure
file
B
Figure 2 -
Diagrammatic conventions
@ ISOKIEC ISOAEC 12087~IA995 (E)
4 The IPI architecture
4.1 IPI imaging architecture
with several types of data falling in the general categories of
In general, imaging Systems deal image data . and
non-Image data, all of which are normally related to physical phenomena. Examples of these are:
categories
grey-scale images, bi-tonal images, colour images,
image data - multichannel satellite data, image
sequences, sequences of stereo pair images, etc.;
non-image data - look-up tables, histograms, text, graphics, regions of interest, etc.;
real world information - continuous physical variables such as light intensity and wavelength, pressure, tem-
perature, continuous Chemical variables, etc.
For the purpose of ISO/IEC 12087, three categories of data types are defined:
basic data types - these are the data types that must be supported by the System upon which ISO/IEC 12087 is
implemented; the category includes both ‘elementary’ data types (e.g., Boolean, integer) and ‘derived’
(structured) data types (e.g., array, record).
these are derived data types that represent image data for the purposes of processing and
image data types -
interchange.
non-image data types - these are derived data types that represent image-related, but non-image, data
(e.g., region of interest).
if
These data are defined i n general terms in this clause . Note that ; data types are regarded as identical
types
they are of identi cal structure with respect to the categories defined in this clause.
4.1.1 IPI imaging model
Figure 3 Shows the relationship between the parts of an IPI implementation. In particular,
- IPI-PIKS and IPI-IIF are self-contained Parts of ISO/IEC 12087, and may be used either independently
or in conjunction by an application program;
- an application program may apply imaging functions via IPI-PIKS;
- an application program may import and export images directly via IPI-IIF;
- any interpretation of data types other than those of the three abovementioned categories must be per-
formed by the application program;
- an application program controls how and to what extent IPI-PIKS and IPI-IIF are used;
- an application program may use other Standards for information processing (e.g., GKS, CGI, PHIGS)
or for data interchange (e.g., CGM, ODA/ODIF);
ISOAEC 12087~ld995 (E) @ ISOAEC
APPLICATION
DOMAIN
----------------
I
0 \
I
I
PARSE
PARSE IPJ-PIKS
‘, GENERATE
: data
GENERATE
I
1 I
IPI-IIF
I
IPI-PIKS domain IPI-IIF domain
data flow according to ASN. 1 specification within IIF
-------
implementation-dependent internal data flow
Figure 3 - Interfaces between application program, IPI-PIKS, and IPI-IIF
- an application program may perform user interaction as well as the display and presentation of images
to the User;
- an application program is responsible for the consistent use of different Standards.
Note that the parsing and generation of an IPI-IIF data stream is capable of being performed both within IPI-
IIF itself, or in IPI-PIKS when importing or exporting images from an IPI-IIF data stream. The parsing and
generation capability within IPI-PIKS is a subset of that available in IPI-IIF. See clause 7 for further details.
4.1.2 IPI Operator processing model
The fundamental Operator model for IPI contains three elements, which are summarized in figure 4. Note that
this model does not apply to IPI-PIKS Tools, Utilities, and Mechanisms. The three elements are:
an Operator -
which performs one of three possible conversions:
- Source image data to destination image data;

@ ISO/IEC ISOAEC 12087013995 (E)
Neighbourhood
Control
Operator
Image
Control
Figure 4 I - Fundamental Operator processing model
- Source image data to destination non-image data;
- Source non-image data to destination non-image data.
image control element - which selects Source image Pixels to be processed, controls processi ng Options,
and selects which processed Source Pixels are to be recorded in the destination image.
a neighbourhood control element - a means of describing a region around a Pixel, not bound to any one Pixel,
that identifies Source image Pixels to be processed and selects processing Options, subject to the image
control.
The image control and neighbourhood control elements serve distinct purposes. Image control is used to identify
NOTE 5
that region of the image within which processing will occur: it is necessarily bound to the image. An example of this
is the region of interest, discussed in this clause and elsewhere. However, neighbourhood control is used to specify
a small region which is not bound to the image; an example of this is an impulse response array used by convolution
Operators.
4.2 IPI basic data types
For the purpose of ISO/IEC 12087, two categories of basic data types exist: elementary data types and com-
pound data types. Compound data types are constructed from elementary data types via construction mech-
anisms (see clause 4.2.2). Other data types, such as image data types and non-image data types, shall refer to
basic data types.
ISOAEC 1208791:1995 (E) @ ISO/IEC
The basic data types directly comply with [ 11, which defines both simple and structured data types by the
properties that they exhibit. Detailed information regarding the definitions of the basic data types and the
basic operations that are supported are defined in [ 11. Data types that are required by IPI but not defined in
[l] are fully defined below.
The lists of basic operations for the data types defined below are not intended to define strictly minimal and
complete sets of operations in a mathematical sense, but rather indicate important basic operations that are
necessary to cover practical applications. All the operations listed below are not necessarily available in IPI-
PIKS; they are included to limit any future APIS.
4.2.1 IPI elementary data types
The elementar-y data types supported by IPI are as follows:
bit
Boolean
Character according to [ISO/IEC 646: 199 l]
complex number
enumerated
null
integer number
real number
These types are defined in annex 8.4.3. Esch of these generic elementary data types may be delineated into
one or more specific data types elsewhere in ISO/IEC 12087, which should then be treated as separate data
types.
4.2.2 IPI compound data types
A compound data type is a data type that is constructed by one of the following mechanisms, also defined in
annex 8.4.3, from basic data types:
N1 x l l l x N, array
Character string
choice
list
pointer
range
record
set
table
Images are comprised of a number of Pixels. The Pixel values of an image must be constructed from the
basic data types listed in clause 4.2. The construction mechanisms used to combine Pixels into images are
the compound data types described in this clause. Similarly, all image-related and non-image data described
by ISO/IEC 12087 are constructed from the same elementary data types via the same construction mechan-
isms. Consequently, all these ‘structured’ or ‘constructed’ data types are referred to as derived data types for
@ ISO/IEC ISOAEC 12087=1:1995(E)
the purposes of ISO/IEC 12087.
4.3 IPI image data types
This clause considers the nature of the image data types that are represented and manipulated by
ISO/IEC 12087. All these data types are derived from the elementary data types of clause 4.2.1 using the
construction mechanisms described in clause 4.2.2. Two categories of image data type may be derived by this
method:
elemen .tary image data or fundamental image data type in which the Pixel values are of an el .ement-
tYPe -
data type or a compound data type whose elements are themselves of basic data
typei
UY
compound image data - in which the construction mechanisms of clause 4.2.2 are used to combine
tYPe
images, which themselves be either elementary or compound.
maY
Both these categories are considered below.
4.3.1 IPI derived elementary image data types
An elementary image data type describes an image that is built from Pixels whose values are referenced to a
Single spatial Position. An elementary image may be constructed from elementary data types using any of the
compound data types of described earlier in this clause.
Note that IPI-PIKS is capable of representing and processing only particular categories of elementary image
data types internally, although its compound image aggregation facility (clause 54.3) permits the application
program to represent a wider range of structures.
4.3.2 IPI derived compound image data types
The central idea behind compound images in ISO/IEC 12087 is to provide structured access to large sets of
related images. Heterogeneous image and non-image data collections tan be combined into structures of arbit-
rary complexity. Pixel values may also be of arbitrary complexity: they could be elementary data types for
storing scalar amplitude information; but they could also be compound data types for associating more com-
prehensive and structured information with every Pixel. Indeed, the compound image data types deliberately
provide more than one way for structuring the same amount of data to optimally meet the demands of the
application. Multi-spectral images, for example, depending on the access mechanisms needed by the applic-
ation or the properties of the Sensors, could be represented as:
- an elementary image whose Pixel values are 1D arrays of integers representing the intensities of the
respective channels;
- a1Darrayof elementary images whose Pixel values are integers representing the intensities in one of
the frequency channels, if regularly-spaced frequency channels have to be accessed at random;
- a list of elementary images whose Pixel values are integers representing the intensities in one of the
frequency channels, if irregularly spaced frequency channels have to be accessed sequentially;
@ ISO/IEC
ISOAEC 12087~1:1995 (E)
- a record of elementary images whose Pixel values are integers representing the intensities in one of the
frequency channels, if the frequency channels are of different spatial resolutions or have to be accessed
by name.
In fact, a complete hierarchy of constructs tan be achieved:
- individual Pixels;
n-dimensional arrays of Pixels;
- 1,2,3,. . .)
- images comprising arrays of Pixels and additional information;
- compound images of arbitrary complexity comprising different image and non-image data types.
A compound image data type is a data type constructed by one of the following construction mechanisms from
image data types:
(NI x l .0 x N,) image array - an array of images of identical image data type that tan be accessed indi-
vidually by their indices (ii , . . . , in). Example operations: equal relation, setting and retrieving of
individual components with random access. Examples of image arrays are identically-structured, local
high-resolution images of regularly-spaced test Patterns for the inspection of printed circuit boards or
integrated circuits, regular spatio-temporal sequences of Slice images through a beating heart, etc.
image list - an ordered image set. Individual images tan be accessed only via successor/predecessor rela-
tions. Example operations: equal relation, is-empty, get-head, get-tail, append, tut, get-successor, get-
predecessor, iterate-through-list. Examples of the data type are collections of related images that tan be
ordered according to their spatial, temporal, or frequency relation, e.g. Stacks of Computerized Tomo-
graphy or Magnetit Resonance images through a tumour in a human body, time sequences of a mov-
ing heart or moving objects in industrial Scenes, images obtained at different wavelengths or energies,
e.g. multi-spectral images, scattered X-ray images, spectroscopic sequences in Magnetit Resonance
Imaging, etc.
image record - a collection of individually-named image data types and optional non-image data types. The
record components may be of different type and are accessed via their names. Example operations:
equal relation, append-component, remove-component, set-component, get-component. Examples of
situations in which image records would prove useful include collections of images of an Object that has
been imaged with different Sensors at different spatial, temporal, or frequency resolutions, e.g. images
of increasing spatial resolution that form an image pyramid, medical images of the same Patient, etc.
image set - a collection of images of identical image data type. The images cannot be accessed individu-
ally. It is possible only to check whether or not an image belongs to a set. Example operations: equal
and subset relations, is-element-of, define-set-of, is-empty, apply-to-all-elements; set operations com-
plement, Union, intersection. Examples of image sets are sets of template images representing a certain
class of objects, e.g. automobile parts, textures etc., that are only used to check whether or not an image
belongs to the class.
Note that image arrays, lists, and sets are analogous to compound data types but that image records are not,
since they may contain both Pixel and non-Pixel data. The operations that may be performed on these com-
pound data types conform with those described in [ 11.
@ ISOAEC
ISOAEC 12087~1:1995 (E)
4.3.3 IPI derived image attributes
Image attributes carry information on how to correctly interpret the associated image data; they arc inher-
ently bound to images. Hence, image attributes are relevant to both IPI-PIKS and IPI-IIF. Image attributes
may be attached either to elementary images (clause 4.3.1) or to compound images (clause 4.3.2). Attributes
that are not attached to Pixel rasters but to higher-level structures of compound images are effective for all
lower level components (i.e., the inheritance of attributes is hierarchical). However, it is possible to overwrite
inherited attributes via their basic operations. Example operations for image attributes are: equal relation,
attach-attribute, remove-attribute, set-attribute, get-attribute.
This clause describes image attributes in a purely textual and behavioural manner; for details on the content
and data types of image attributes supported by IPI-PIKS and IPI-IIF, see clause 5.4.4 and clause 6.3.2.
channel attribute - Many types of images tan be thought of as being comprised of several ‘channels’ of data.
The channel attribute provides information about the Sensor models underlying these channels that is
necessary for the analysis of channel information, e.g. the number of bits used for quantizing the original
Sensor Signals, sensitivity and noise characteristics of the Sensors, spectral behaviour of the Sensors, etc.
For example, a medical application might combine an MR and a PET data set into a Single IPI image;
the channel attribute would then be used to identify the MR and PET channels and to describe the char-
acteristics of the two devices that captured them. Similarly, colour images are generally digitized into
three separate channels, the first representing the red Pixels, the second the green Pixels and the third
the blue Pixels, and the channel attribute could be used to describe this.
colour attribute - Since colour images form such an important class to the human observer, it is essential that
sufficient information is carried with a colour image for it to be reproduced accurately. Hence, a colour
attribute is associated with colour images. Note that a colour image has a Single colour description,
but a separate channel description for each channel. This colour description encompasses all entities
dealing with the mixing of amplitude values of multiple channels in Order to achieve accurate colour
reproduction; this may consist of the colour representation involved (see annex 8.4.3), test colours for
regions of the image, etc.
control attribute - The purpose of a control attribute is to convey information that may be needed for sub-
sequent processing or presentation of an image. This may include, for example, the match-Point and
the identifier of a region of interest associated with an IPI-PIKS image.
free-form attribute - The internal structure and Syntax of the free-form description attribute is not spe-
cified within ISO/IEC 12087. It is application-dependent, and is provided to allow application-specific
descriptive information to be attached to the Pixel data of an image. It is left to the application to decide
on the actual way of storing and manipulating this information. No IPI-PIKS functionality is provided
to manipulate the content of the free-form description; any processing of this description must be per-
formed entirely by the application program.
One example for a free-form description which is defined in detail by an application-specific Standard
is the header information as defined by the ACR-NEMA Standard for medical applications. It provides
specific formats for describing the nature of the image, orientation
...