Type definition, scoping, and logical views for image interchange facility

Adds a lot of new clauses and subclauses and replaces the wording of some clauses and subclauses of ISO/IEC 12087 3:1995.

Définition de type, domaine d'application et vues logiques pour les accessoires pour l'échange d'images (IIF)

General Information

Publication Date
Current Stage
6060 - International Standard published
Completion Date
Ref Project


Buy Standard

ISO/IEC 12087-3:1995/Amd 1:1996 - Type definition, scoping, and logical views for image interchange facility
English language
78 pages
sale 15% off
sale 15% off

Standards Content (sample)

STANDARD 12087-3
First edition
1995-02-I 5
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)
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
---------------------- Page: 2 ----------------------
ISOLIEC 12087-3:1995/Amd.l:1996(E)
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. 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,

---------------------- Page: 3 ----------------------
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). 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). 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

---------------------- Page: 4 ----------------------
0 ISO/IEC ISO/IEC 12087-3: 1995/Amd.l: 1996(E) 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. 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


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. 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 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
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)
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
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
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
---------------------- Page: 8 ----------------------
ISO/IEC 12087-3:1995/Amd.l:1996(E)
5.3.9 Entities for the description of segment types **)
IIF syntax entity No. 904
IIF syntax entity No. 905 ImageStructureDefn
IIF syntax entity No. 906
IIF syntax entity No. 907 ImageA ttributeDefn
IIF syntax entity No. 908
IIF syntax entity No. 909 BasicDataObjectDefn
IIF syntax entity No. 910 SegmentTypesDefn
IIF syntax entity No. 911
IIF syntax entity No. 912 A ttributeoccurence
IIF syntax entity No. 9 13
IIF syntax entity No. 914 OccurenceDefn
IIF syntax entity No. 915 RepeatElement
IIF syntax entity No. 9 16
5.3.10 Entities for the description of reference mechanism **)
IIF syntax entity No. 917
IIF syntax entity No. 918 ImageStructureLabeI
IIF syntax entity No. 919
IIF syntax entity No. 920 ImageA ttributekbel
IIF syntax entity No. 921
IIF syntax entity No. 922 BasicDataTJTpeLabel
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
IIF syntax entity No. 930
IIF syntax entity No. 931 SegmentTypeRef
IIF syntax entity No. 932
IIF syntax entity No. 933 ExternalRefIndex
IIF syntax entity No. 934
---------------------- Page: 9 ----------------------
ISO/IEC 12087-3:1995/Amd.l:1996(E)
Replace the syntax entity 004 by the following:
IIF syntax entity No. 004

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.
Profile ::= CHOICE
-- No. 722
application-profile IA5String,
profile-definition SegmentTypeRef -- No. 931

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)
IIF syntax entity No. 005 ContentsHeader

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
ContentsHeader ::= SEQUENCE
[0] CharacterString OPTIONAL, -- No. 006
[1] CharacterString OPTIONAL, -- No. 006
date-and-time [2] GeneralizedTime OPTIONAL, -- No. 724
message [3] CharacterString OPTIONAL, -- No. 006
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

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.
---------------------- Page: 11 ----------------------
ISO/IEC 12087.3:1995/Amd.l:1996(E)
IIF syntax entity No. 008 Contents
IIF syntax entity No. 009 ContentsElement
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
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.


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
---------------------- Page: 12 ----------------------
ISO/IEC 12087-3:1995/Amd.l: 1996(E)
IIF syntax entity No. 010

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


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.

ContentsBody ::= CHOICE
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

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.