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)

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
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).
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.
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.
@ 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 I
...