ANSI INCITS ISO IEC 12087-3 AMD 1-1996 Information Technology - Computer Graphics and Image Processing - Image Processing and Interchange (IPI) - Functional Specification - Part 3 .pdf

《ANSI INCITS ISO IEC 12087-3 AMD 1-1996 Information Technology - Computer Graphics and Image Processing - Image Processing and Interchange (IPI) - Functional Specification - Part 3 .pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS ISO IEC 12087-3 AMD 1-1996 Information Technology - Computer Graphics and Image Processing - Image Processing and Interchange (IPI) - Functional Specification - Part 3 .pdf（81页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL STANDARD ISO/IEC 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, scopi

2、ng, and logical views for image interchange facility Technologies de /information - lnfographie et traitement de /image - Traitement et Bchange de /image l/P/j - Spkcification fonctionnelle - Partie 3: Accessoires pour Ikhange dimages (IIF) AMENDEMENT 1: DBfinition de type, domaine dappkation et vue

3、s loglques pour les accessoires pour lkchange dimages (IIF) Reference number ISO/IEC 12087.3:1995/Amd.l :I 996(E) Adopted by INCITS (InterNational Committee for Information Technology Standards) as an American National Standard. Date of ANSI Approval: 8/31/01 Published by American National Standards

4、 Institute, 25 West 43rd Street, New York, New York 10036 Copyright 2002 by Information Technology Industry Council (ITI). All rights reserved. These materials are subject to copyright claims of International Standardization Organization (ISO), International Electrotechnical Commission (IEC), Americ

5、an National Standards Institute (ANSI), and Information Technology Industry Council (ITI). Not for resale. No part of this publication may be reproduced in any form, including an electronic retrieval system, without the prior written permission of ITI. All requests pertaining to this standard should

6、 be submitted to ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in the United States of America ISO/IEC 12087-3:1995/Amd.l:1996(E) Foreword IS0 (the International Organization for Standardization) and IEC (the Inter- national Electrotechnical Commission) form the specialized system for world

7、wide 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

8、 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 ad

9、opted 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

10、 ISO/IEC JTC 1, Information technology, Sub- committee 24, Computer graphics and image processing. 0 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 a

11、nd 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 0 ISO/IEC ISO/lEC 12087-3:1995/Amd.l:1996(E) Type definition, scoping, and logical views for image interchange facilty 5 The IIF data

12、 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, I

13、PI 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 I and Part 2. In addition to the straightforward usage of these entities, an application may select one, two or more of them, group t

14、hem 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 pro/q (entity number 9Ol), serves as the definition space for attributes that apply to the second p

15、art, 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 /og may also contain a reference to a segment type definition in order to constrain the s

16、tructure of segment to conform that definition. The body 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 pr

17、ovided 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 objecti

18、ves which arc 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 numbe

19、r 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 inherite

20、d 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, u

21、nless they are overwritten by newly specifying them immediate in the body of a segment (refer to syntax entity No. 008, ContentsBody). ISO/IEC 12087-3:1995/Amd.l:1996(E) 0 ISO/IEC The definition of an attribute allows to specify the type of an attribute and the value of an attribute. The type ol an

22、attribute is specified as a hierarchy of context sensitive ASN.l 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 definitio

23、n 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 SeR,nerztSt,-lcctllre 01 SegmentTypeDefn entity number 910). The presence an

24、d 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 912). 5.1.5.2 Constraints on Topology and Attributes of a Segment Any segment may be constrain

25、ed to have a specific topology and a prescribed set of segment attributes associated with this topology. This is achieved by declarin, u 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

26、, set, choice) and occurrences (one or more required or optional items). A set of attributes can be associated, in the way provided in this specification, with every item of the segments structure. Thus. the segment type is defined by the specification of constrains on its topology and by the specif

27、ication 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 defin

28、ition 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 appl

29、ication 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 hiera

30、rchy 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 90 I, and similar construct in Segmen

31、tTypeDefn entity number 9 10). 5.1.5.3 Symbolic References Each segment may contain a collection of definitions, each of which is associated with an identifier. The constructs which can be defined in such a way (with help of the Numedftems entity, entity number 904) are image related data, image att

32、ributes, 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

33、 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. T

34、his 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 identif

35、iers must be preserved. The technique recommended to achieve this goal is to use the addressing scheme as specified in ISO/IEC 1003 I, Distributed Office Application Model (DOAM), Part 2: Distinguished Object Reference (DOR) to generate segment identifiers. 2 0 ISO/IEC ISO/IEC 12087-3: 1995/Amd.l: 1

36、996(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

37、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 with

38、in 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, resultin

39、g 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

40、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

41、 data. These could be modelled as another IIF data stream, as a flat or structured stream of ASN.1 tokens following 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 differe

42、ntiate precisely 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

43、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 p

44、ointer 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

45、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 chos

46、en 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 defi

47、nitions, and it can be provided as a type guide in ContentsHeader entity, or as an explicit profile definition in Profile 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 nav

48、igate 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-II

49、F. Considered to be application dependent, it can be implemented through further specification of access-information component of ContentsHeader entity and access-optimizer component of SegmentEpilog entity. 3 ISO/IEC 12087-3:1995/Amd.l:1996(E) 0 ISO/IEC 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 In the following, ASN.1 code is indicated by courier font. All syntax rules are prececded by a semantics statement. Some rules are succeeded by