ISO/IEC 12087-3:1995/Amd 1:1996

INTERNATIONAL ISO/IEC
STANDARD 12087-3
First edition
1995-02-I 5
AMENDMENT 1
1996-l 2-l 5
Information technology - Computer
graphics and image processing - Image
Processing and Interchange (IPI) -
Functional specification -
Part 3:
Image Interchange Facility (IIF)
AMENDMENT 1: Type definition, scoping, and
logical views for image interchange facility
de I ‘in formation de I’image -
Technologies - lnfographie et traitemen t
Traitemen t et kchange de /‘image (/PI) - Spkification fon ctionnelle -
Partie 3: Accessoires pour /‘&change d/images (I/F)
AMENDEMENT 7: Definition de type, domaine d’application et vues logiques pour
/es accessoires pour I’khange d’images (IF)
Reference number
[SO/I EC 12087-3: 1995/Amd. 1: 1996(E)

---------------------- Page: 1 ----------------------
ISO/IEC 12087-3: 199YAmd.l: 1996(E)
Foreword
IS0 (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 IS0 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.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 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.
Amendment 1 to International Standard ISO/IEC 12087-3:1995 was prepared by
Joint Technical Committee ISO/IEC JTC 1, Information technology, Sub-
committee 24, Computer graphics and image processing.
@ ISO/IEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical. including
photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
ISOLIEC 12087-3:1995/Amd.l:1996(E)
0 ISO/IEC
Type definition, scoping, and logical views for image interchange facilty
5 The IIF data format (IIF-DF)
. . . . . . . . .
5.1 Basic features of the IIF-DF
Add the following new subclause:
5.1.5 Segment Structure of IIF Data Stream
The content of an IIF data stream consists of zero or more segments, hierarchically structuring the data in a tree
like manner. Considering ASN.1 constructs as an alphabet, IPI Part3 (IIF) can be seen as a grammar which
combines elements of this alphabet to build entities carrying image processing specific semantics as defined in
IPI Part 1 and Part 2. In addition to the straightforward usage of these entities, an application may select one,
two or more of them, group them together, and associate some additional or new semantics with such a set.
Segments provide the mechanisms to make that grouping persistent. Each IIF segment has three parts.
The first part, called prolog (entity number 901), serves as the definition space for attributes that apply to the
second part, called body (entity number 010). The prolog provides also facilities to associate a segment with a
unique name and user defined label. These can be used as handles while processing the IIF data stream. The
pr-olog may also contain a reference to a segment type definition in order to constrain the structure of segment to
conform that definition.
The Do@ of a segment contains all IPI-CA1 data types required to interchange image and image related data as
well as types necessary for the application specific structuring of these data.
The third part of a segment, called epilog (entity 902), is provided for syntactical and processing reasons. It
specifies a mark-up denoting the boundary of a segment, and it may contain useful IIF profile dependent or
application specific information to facilitate random access to an IIF data stream residing in the memory buffer
or on a file.
The main objectives which are addressed by the introduction of segmentation into IIF can be summarised as
follows below.
5.1.5.1 Attribute Inheritance and Management
Each segment may contain a collection of image related data (entity number 301), image attributes (entity
number 401), image annotations (entity number 501) and basic data types (entity number 602) referred to as
“segment attributes” (entity number 903). These attributes are inherited by the child segments i.e. by segments
nested in the given segment. A child segment may in turn specify an attribute which has a higher precedence
than the inherited one and so modify it. In this sense, every segment carries a set of attributes, which are either
specified in that segment or inherited from the parent segment. These attributes are considered as default
attributes of the given segment and apply to the content specified in the body of a segment, unless they are
overwritten by newly specifying them immediate in the body of a segment (refer to syntax entity No. 008,
ContentsBody).

---------------------- Page: 3 ----------------------
0 ISO/IEC
ISO/IEC 12087-3:1995/Amd.l:1996(E)
The definition of an attribute allows to specify the type of an attribute and the value of an attribute. The type of
an attribute is specified as a hierarchy of context sensitive ASN.1 tags referring to the grammar of IIF data
stream. The value of an attribute is specified according to definitions provided in IPI-CAI. Explicit management
scheme for instantiation of attributes is outlined by the segment type definition facility (see clause below on
constraints on topology and attributes of a segment). This scheme defines the rules of presence and propagation
for each attribute specified in the definition of a segment type (via construct Segl~zentStr-l~ctllre of‘
SegnzentTypeDefiz entity number 910). The presence and propagation rule for an attribute is a combination of
predicates which shall be applied to the concerned attribute by an application processing the content of a segment
(AttributeOccurrence entity number 9 12).
5.1.5.2 Constraints on Topology and Attributes of a Segment
Any segment may be constrained to have a specific topology and a prescribed set of segment attributes
associated with this topology. This is achieved by declaring the segment to be of a given “segment type”.
The constraints on topology of a segment structure are defined in terms of a nested combination of orderings
(sequence, set, choice) and occurrences (one or more required or optional items). A set of attributes can be
with every item of the segments’ structure. Thus, the
associated, in the way provided in this specification,
segment type is defined by the specification of constrains on its topology and by the specification of its attributes.
A segment which is constrained to be of a given type must possess the topology and attributes as prescribed in
the definition of that type. Note however, that for the attributes specified in a definition of segment type, the
value of an attribute, and any part of the definition of an attribute type can remain undefined. See in that. context
data-required construct in several entities, e.g. IndexND (entity number 308), CompoundDataType (entity
number 603) etc. An undefined type and value specification can be completed, without the violation of a segment
type, by an application using the segment of a such type. Therefore, in an IIF data stream the segments adhering
to the same type can have not only different content, different values of attributes, but also their attributes can
differ in some parts of its type definition. Such segments may constitute thereby hierarchy of classes of segment
types. Note also that an application can associate with given segment type, or with given class of segment types,
specific methods how to process the content of such segments (see the construct user-label in SegmentProlog
entity number 901, and similar construct in SegmentTypeDefn entity number 9 IO).
5.1.5.3 Symbolic References
each of which is associated with an identifier. The
Each segment may contain a collection of definitions,
constructs which can be defined in such a way (with help of the NamedItems entity, entity number 904) are
image related data, image attributes, image annotations, basic data types, image structures and segment types. In
contrast to segment attributes, these constructs do not apply to the content specified in the body of a segment, and
are not directly inherited by the child segments. Instead, they are used as targets for references in other segments
which may need the same constructs: such segments will rather make a symbolic reference to an appropriate
definition than duplicate the same definitions in their headers or bodies.
Reference mechanism is implemented within the name and address space associated with the segments. This
space consists of segment identifiers unique in given context. By definition, such a context can be for example a
specific IIF data stream, or a referenced external data repository. Note that by merging together IIF data streams,
or different external data repositories, the uniqueness of identifiers must be preserved. The technique
recommended to achieve this goal is to use the addressing scheme as specified in ISO/IEC 10031, Distributed
Office Application Model (DOAM), Part 2: Distinguished Object Reference (DOR) to generate segment
identifiers.

---------------------- Page: 4 ----------------------
0 ISO/IEC ISO/IEC 12087-3: 1995/Amd.l: 1996(E)
5.1.5.4 Logical Views of Image Data
Instead of physically supplying the image data in its content, a segment may use there symbolic references into
the image structure describing some physical data set. Since the image structure fully corresponds to the image
data, such references into image structure are equivalent to (i.e. can be resolved to result in) references into
image data. A logical view of a remote data set is a segment which has symbolic references into parts of image
data supplied elsewhere. The referencing mechanism is implemented through the naming of image structures
within the name and address space as described above in clause on symbolic references. See also in this context
the definition of the IIF syntax entity, Referencehit (entity number 201 ).
As long as the reference path is a-cyclic, the targets of references may themselves be symbolic references,
resulting in a mechanism for logical reordering of physical image data. It is obvious that the logical views
required by the application can not go beyond the granularity implied by the physical data set, i.e., the atomic
elements a logical view consists of can not be smaller than referable elements of the referenced structure. This
implies, that some application may need to restructure the physical data set collected by another application in
order to offer a more detailed granularity required by its own semantics.
5.1.5.5 Information Integration Support
An IIF data stream may need to integrate other data. These could be modelled as another IIF data stream, as a
of ASN.1 tokens following
f-rat or structured stream rules of a grammar other then IIF, as an arbitrary octet
string, or as any other stream of bits. Structuring facilities and mechanisms associated with these facilities allow
to differentiate preci sely between all three cases providing well defined rules how to access the data in the best
way.
External reference mechanism allows that a repository of information can reside outside the IIF data stream. The
ASN.1 object identification scheme is used to provide necessary information about the syntax of referenced data.
The so called EntityHandle (entity number 917) offers a flexible mechanism to choose between different kind of
pointers to the data structured according to IIF grammar and to the data encoded according to any ASN. 1 or even
non-ASN.1 grammar. The syntax of this pointer has well defined semantics within IIF grammar but it is also
flexible enough to point into other repositories (e.g. Common Object Request Broker specified by X/Open and
Object Management Group). The possibility to type segments introduced by SegmentTypeDefn entity provides a
facility to bind given application specific processing methods to required parts of the IIF data stream.
5.1.5.6 Access Support
While stored in a file or buffered in the memory of a computer, an IIF data stream usually represents large
amount of sequential organised data. Therefore random access to an arbitrary chosen part of these data is,
somehow, not trivial problem in terms of time and consumed resources. It can be, however, significantly
facilitated by the “a priori” knowledge of generic logical structure for given IIF data stream. Such a generic
structure will consist of a hierarchy of segment types definitions, and it can be provided as a type guide in
ContentsHeader entity, or as an explicit profile definition in ProfiZe entity.
Based on possible unique application specific semantics which can be associated with the elements of logical
structure, the logical structure will help application to navigate in an IIF data stream. Otherwise, while mapped to
a file or to a buffer, the logical structure can directly enable paging mechanism of specific implementation
platform as the random access tool for an IIF data stream. The definition of such mapping, however, is outside
the scope of this IPI-IIF. Considered to be application dependent, it can be implemented through furthei
specification of access-information component of ContentsHeader entity and access-optimizer component of
SegmentEpilog entity.

---------------------- Page: 5 ----------------------
@ ISO/IEC
ISO/IEC 12087-3:1995/Amd.l:1996(E)
Replace 5.3 by the following. The syntax entities marked with *) are extended in an upward
compatible way, The syntax entities marked with **) are new,
5.3 Syntax entities of the IIF-DF
font. All syntax rules are preceeded by a semantics
In the following, ASN. 1 code is indicated by courier
statement. Some rules are succeeded by constraints statements. The rules are ordered in prefix form, with the
exceptions of 1) attributes are described after the non-image data types,
2) segment-related entities (53.8 and 5.3.9),
3) reference mechanism entities (5.3.10).
The syntax rules, as well as the related semantics and constraints, are divided into the following subclauses:
5.3.1 Entities for the description of the entire IIF-DF
IIFDataFormat
IIF module declaration
IIF syntax entity No. 001 FuZZDataFormat
IIF syntax entity No. 002 FormatDescriptor
IIF syntax entity No. 003 Version
IIF syntax entity No. 004 Pro$Ze*)
IIF syntax entity No. 005 ContentsHeader*)
IIF syntax entity No. 006 CharacterString
IIF syntax entity No. 007 SpecialCharacterString
IIF syntax entity No. 008 Contents
IIF syntax entity No. 009 ContentsElement*)
IIF syntax entity No. 010 ContentsBody*)
.
5.3.2 Entities for the description of images
IIF syntax entity No. 101 Image
IIF syntax entity No. 102 ImageStructure*)
IIF syntax entity No. 103 CompoundImageStructure
IIF syntax entity No. 104 CompoundImageArray
IIF syntax entity No. 105 Dimensionality
IIF syntax entity No. 106 DimensionDescription
IIF syntax entity No. 107 Identifier
IIF syntax entity No. 108 Serialization
IIF syntax entity No. 109 DataPlacement
IIF syntax entity No. 110 CompoundImageRecord
IIF syntax entity No. 111 RecordComponent
IIF syntax entity No. 112 CompoundImageList
IIF syntax entity No. 113 CompoundImageSet
IIF syntax entity No. 114 FundamentalImageStructure
IIF syntax entity No. 115 BandRecord
IIF syntax entity No. 116 BandRecordComponent
IIF syntax entity No. 117 MetricArray
IIF syntax entity No. 118 MetricArrayElement
IIF syntax entity No. 119 PixelStructure
IIF syntax entity No. 120 ElementaryPixelStructure
IIF syntax entity No. 121 PixelBandRecord
IIF syntax entity No. 122 PixelBandRecordComponent

---------------------- Page: 6 ----------------------
ISOLIEC 12087-3:1995/Amd.l:1996(E)
0 ISO/IEC
5.3.3 Entities for the description of the representation of pixel values
IIF syntax entity No. 201 Referenced&tit*)
IIF syntax entity No. 202 DataUnit*
IIF syntax entity No. 203 SubdividedDataUnit
IIF syntax entity No. 204 SingleDataUnit
IIF syntax entity No. 205 BuiltinEncodedDataUnit
IIF syntax entity No. 206 BuiltinValue
IIF syntax entity No. 207 ComplexValue
IIF syntax entity No. 208 ExternallyDefinedDataUnit
IIF syntax entity No. 209 CompressedDataUnit
IIF syntax entity No. 210 RegisteredDataUnit
IIF syntax entity No. 211 ExternalReference*)
IIF syntax entity No. 212 ExternaZAddress
Entities for the description of image-related data
5.3.4
IIF syntax entity No. 301 ImageRelatedData *)
IIF syntax entity No. 302 Histogram*)
IIF syntax entity No. 303 PartitionClass
IIF syntax entity No. 304 LookUpTable*)
IIF syntax entity No. 305 RegionOfInterest*)
IIF syntax entity No. 306 BooleanArray
-
IIF syntax entity No. 307 Ellipse
IIF syntax entity No. 308 IntervalND
IIF syntax entity No. 309 IntervalID
IIF syntax entity No. 310 CoordinateND
IIF syntax entity No. 311 SetOfCoordinates
IIF syntax entity No. 3 12 NeighbourhoodArray*)
IIF syntax entity No. 3 13 IndexND
IIF syntax entity No. 314 StaticArray
IIF syntax entity No. 3 15 FeatureList*)
IIF syntax entity No. 3 16 CoordinateAndFeature
IIF syntax entity No. 3 17 ValueBoundsCollection
IIF syntax entity No. 3 18 TransformationMatrix
IIF syntax entity No. 3 19 PixelRecord
IIF syntax entity No. 320 PixelRecordComponent
IIF syntax entity No. 321 Tuple
Entities for the description of image attributes
5.3.5
IIF syntax entity No. 401 ImageAttribute*)
IIF syntax entity No. 402 MetricDescription*)
IIF syntax entity No. 403 DimensionMapping
IIF syntax entity No. 404 MeasurementUnit
IIF syntax entity No. 405 DeltaVector
IIF syntax entity No. 406 MetricTransformation
IIF syntax entity No. 407 Domain
IIF syntax entity No. 408 ChannelCharacteristics*)
IIF syntax entity No. 409 CompandorDescription
IIF syntax entity No. 4 10 ColourRepresentation*)

---------------------- Page: 7 ----------------------
ISO/IEC 12087-3: 1995/Amd.l: 1996(E) 0 ISO/IEC
IIF syntax entity No. 411 StandardizedSpace
IIF syntax entity No. 412 CIEXYZSpace
IIF syntax entity No. 413 CIEYkySpace
IIF syntax entity No. 414 CIEUVWSpace
IIF syntax entity No. 415 CIEYuvSpace
IIF syntax entity No. 416 CIELabSpace
IIF syntax entity No. 417 CIELuvSpace
IIF syntax entity No. 418 CIEXYZCoordinate
IIF syntax entity No. 4 19 LinearRGBSpace
IIF syntax entity No. 420 GammaRGBSpace
IIF syntax entity No. 421 YIQColourSpace
IIF syntax entity No. 422 YUVColourSpace
IIF syntax entity No. 423 YCbCrColourSpace
IIF syntax entity No. 424 NonStandardizedSpace
IIF syntax entitv No. 425 NonStandardizedRGB
IIF syntax entit; No. 426 NonStandardizedIHS
IIF syntax entity No. 427 Primaries
IIF syntax entity No. 428 CIExyCoordinate
IIF syntax entity No. 429 NonStandardizedCMY
IIF syntax entity No. 430 NonStandardizedCM YK
IIF syntax entity No. 43 1 NonStandardizedNBarzd
IIF syntax entity No. 432 ColourBand
IIF syntax entity No. 433 TestColow
IIF syntax entity No. 434 PIKSControl
5.3.6 Entities for the description of image annotations
IIF syntax entity No. 501 ImageAnnotation*)
IIF syntax entity No. 502 Location
5.3.7 Entities for the description of basic data objects
IIF syntax entity No. 601 BasicDataObject
IIF syntax entity No. 602 BasicDataTlTpe*)
IIF syntax entity No. 603 CompoundDataT~~pe*)
IIF syntax entity No. 604 BasicArray
IIF syntax entity No. 605 BasicRecord
IIF syntax entity No. 606 BasicRecordComponerlt
IIF syntax entity No. 607 BasicList
IIF syntax entity No. 608 BasicSet
IIF syntax entity No. 609 ElementaryDataT~~pe *)
5.3.8 Entities for the description of segmentation facility **>
IIF syntax entity No. 901 Segmen tProlog
IIF syntax entity No. 902 SegmentEpilog
IIF syntax entity No. 903 SegmentA ttributes
6

---------------------- Page: 8 ----------------------
ISO/IEC 12087-3:1995/Amd.l:1996(E)
0 ISO/IEC
5.3.9 Entities for the description of segment types **)
NamedItems
IIF syntax entity No. 904
IIF syntax entity No. 905 ImageStructureDefn
ImageRelatedDataDefn
IIF syntax entity No. 906
IIF syntax entity No. 907 ImageA ttributeDefn
ImageAnnotationDefn
IIF syntax entity No. 908
IIF syntax entity No. 909 BasicDataObjectDefn
IIF syntax entity No. 910 SegmentTypesDefn
ExpressionElement
IIF syntax entity No. 911
IIF syntax entity No. 912 A ttributeoccurence
StructureDefn
IIF syntax entity No. 9 13
IIF syntax entity No. 914 OccurenceDefn
IIF syntax entity No. 915 RepeatElement
StructureElement
IIF syntax entity No. 9 16
5.3.10 Entities for the description of reference mechanism **)
EntityHandle
IIF syntax entity No. 917
IIF syntax entity No. 918 ImageStructureLabeI
ImageRelatedDataLabel
IIF syntax entity No. 919
IIF syntax entity No. 920 ImageA ttributekbel
ImageAnnotationLabel
IIF syntax entity No. 921
IIF syntax entity No. 922 BasicDataTJTpeLabel
SegmentLabel
IIF syntax entity No. 923
IIF syntax entity No. 924 SegmentTypeLabel
IIF syntax entity No. 925 Label
IIF syntax entity No. 926 ImageStructureRef
IIF syntax entity No. 927 ImageRelatedDataRef
IIF syntax entity No. 928 ImageA ttributeRef
IIF syntax entity No. 929 ImageAnnotationRef
BasicDataTJjpeRef
IIF syntax entity No. 930
IIF syntax entity No. 931 SegmentTypeRef
SegmentRef
IIF syntax entity No. 932
IIF syntax entity No. 933 ExternalRefIndex
ImageDataRef
IIF syntax entity No. 934

---------------------- Page: 9 ----------------------
0 ISO/IEC
ISO/IEC 12087-3:1995/Amd.l:1996(E)
Replace the syntax entity 004 by the following:
Profile
IIF syntax entity No. 004
Semantics
The PI-ofiZe entity stands for the description of profiles, specifying that the IIF-DF is restricted to a certain subset.
One of the following predefined conformance profiles may be chosen: full profile, fidU PKS profile, and
foundation profile.
For a definition of these profiles refer to clause 6. Additional application profiles are subject to registration as
defined in 6.2. While application-profile constraints the conformance-profile by “linguistic” means, assuming
that specific name is known to the IIF Gateway, or to the application, the same is achieved by profile-definition,
pointing to the formal definition how data types shall be used in the current IIF data stream, or simply, giving a
“generic example” of what is allowed inside the conformance-profile. The profile-definition can be therefor
considered as generic logical structure of a given IIF data stream. Both application-profile and profile-definition
may constrain the range implied by conformance-profile, but never extend it.
Syntax
Profile ::= CHOICE
{
-- No. 722
application-profile IA5String,
profile-definition SegmentTypeRef -- No. 931
1
Constraints
For the Profile entity, only the values ‘Ifull profile”, ‘lfull PIKS profile”, and ‘youndation projile” and values
which have been internationally registered are permitted. Refer to 6.2. A generic logical structure can be either
defined with help of the profile-definition component referencing directly to an external data repository
containing definition of segment type that models the structure of an IIF data stream, or this definition shall be
taken from type-guide component in ContentsHeader entity

---------------------- Page: 10 ----------------------
ISO/IEC 12087-3: 199YAmd.l: 1996(E)
0 ISOIIEC
IIF syntax entity No. 005 ContentsHeader
Semantics
The ContentsHeuder entity provides some common information about the contents of the IIF data stream. No
further semantics are defined for the convention of the title, owner, date-and-time, and message components.
Also, no semantics are defined for the application-data component which can be represented using any ASN.1
tY Pe.
The externaLreferences component describes the sources of data which are outside of the current IIF data
stream. The access-information component provides additional information which will facilitate random access
to the content of the current IIF data stream. It points to the specification of an external file in the list of external
references. The type-guide component is a pointer to an external data repository from which the default attributes
are inherited and from which type definitions can be referenced.
NOTE - Information fields, such as “processing platform” or “acquisition process” are regarded as too application-
specific to be included in this header as a separate entity. This kind of information can either be put into the message
field as readable text or handled as an image annotation or image attribute (using either one of the built-in fields or a
freeform field).
EXAMPLE - The application-data component (as well as any other component that is typed with the ASN. 1
type ANY) could be structured by an application in the following way:
.
ApplicationData . -= . SET OF
SEQUENCE
[0] IMPLICIT INTEGER,
tag
value [l] IMPLICIT OCTET STRING
Syntax
ContentsHeader ::= SEQUENCE
C
[0] CharacterString OPTIONAL, -- No. 006
title
[1] CharacterString OPTIONAL, -- No. 006
owner
date-and-time [2] GeneralizedTime OPTIONAL, -- No. 724
message [3] CharacterString OPTIONAL, -- No. 006
ANY OPTIONAL,
application-data WI
external-references [5] IMPLICIT SEQUENCE OF
ExternalReference OPTIONAL, -- No. 211
access-information [6] IMPLICIT ExternalRefIndex OPTIONAL, -- No. 927
type-guide [7] IMPLICIT ExternalReference OPTIONAL -- No. 211
Constraints
The type-guide component shall be present if profile-definition component in Profile entity does not specify an
external data repository. In specification of EntityHandle in the type-guide component the segment-handle option
should be applied.
9

---------------------- Page: 11 ----------------------
0 ISO/TEC
ISO/IEC 12087.3:1995/Amd.l:1996(E)
IIF syntax entity No. 008 Contents
and
IIF syntax entity No. 009 ContentsElement
Semantics
The Contents entity consists of a sequence of ContentsElement entities.
The ContentsEZetnent entity provides a sequence of prolog, ho& and epilog components. Such a sequence is
called a segment.
s differentiated from the surrounding content by a change in pr ,ocessing
Image segments conten t that i
group
nd to it the appl ication specific semantics.
charac teristics. A ication may bi
n aPP1
The pr-olog component is used to store the attributes that apply to the body of this segment and can be inherited
in nested segments. In addition the prolag components contains type definitions which can be used in the name
space of the current segment or referenced by other segments.
The body component contains all IPI-CA1 data types required to interchange image and image related data as
well as types necessary to assure application specific structuring of these data.
which
The epilog component provides a mark-up of the segment boundary may contain useful information to
facilitate random access to the IIF data stream residing in the memory buffer or on a file.
.
Contents . . l = SEQUENCE OF ContentsElement
ContentsElement ::= SEQUENCE
-- No. 901
prolog [0] IMPLICIT SegmentProlog OPTIONAL,
-- No. 010
body [l] IMPLICIT SEQUENCE OF ContentsBody,
[2] IMPLICIT SegmentEpilog OPTIONAL -- No. 902
epilog
>
Constraints
None.
10

---------------------- Page: 12 ----------------------
ISO/IEC 12087-3:1995/Amd.l: 1996(E)
0 ISO/IEC
ContentsBody
IIF syntax entity No. 010
Semantics
The CorztentsBo& entity stands for the description of iconic and non-iconic data. The following components may
be selected:
- the image component contains image structure information and associated pixel data;
- the image-related data component contains data that conform to one of the image-related data types as
defined in ISO/IEC 12087- 1.
- the image-attributes component contains data that conform to one of the attribute types as defined in
ISOIIEC 12087- 1.
- the image-annotations component contains data that conform to one of the attribute types as defined in
ISO/IEC 12087- 1.
- the basic-data-component contains data that are structured according to a basic data type as defined in
ISOIIEC 12087- 1.
- the contents-element provides a recursion because its subentities refer back to the ContentsBody entity.
According to the constraint given below, this recursion is prohibited. The only reason for incorporating
the contents-element component into the syntax is to prepare the introduction of a hierarchical type
definition and validity space concept that may be given in a separate Ammendment to this International
Standard.
Image annotations and image-related data are provided in two ways: bound to images, using the corresponding
subentities within the Image entity, or separate from images using the ContentsBody entity as stated above. The
latter way allows for the exchange of non-iconic parameters from and to the IPI-PIKS without any image data.
Syntax
ContentsBody ::= CHOICE
1
image -- No. 101
VI Image,
image-related-data [l] ImageRelatedData, -- No. 301
image-attribute [2] ImageAttribute, -- No. 401
image-annotation [3] ImageAnnotation, -- No. 501
basic-data-object [4] BasicDataObject, -- No. 601
contents-element [5] ContentsElement -- No. 009
1
Constraints
None.

----------
...