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

上传人:李朗 文档编号:436076 上传时间:2018-11-14 格式:PDF 页数:81 大小:3.38MB
下载 相关 举报
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_第1页
第1页 / 共81页
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_第2页
第2页 / 共81页
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_第3页
第3页 / 共81页
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_第4页
第4页 / 共81页
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_第5页
第5页 / 共81页
亲,该文档总共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

展开阅读全文
相关资源
  • ANSI Z97 1-2009 American National Standard for Safety Glazing Materials used in Buildings - Safety Performance Specifications and Methods of Test《建筑物中窗用玻璃材料安全性用.pdfANSI Z97 1-2009 American National Standard for Safety Glazing Materials used in Buildings - Safety Performance Specifications and Methods of Test《建筑物中窗用玻璃材料安全性用.pdf
  • ANSI Z97 1 ERTA-2010 Re ANSI Z97 1 - 2009 Errata《修订版 美国国家标准学会Z97 1-2009标准的勘误表》.pdfANSI Z97 1 ERTA-2010 Re ANSI Z97 1 - 2009 Errata《修订版 美国国家标准学会Z97 1-2009标准的勘误表》.pdf
  • ANSI Z21 40 2a-1997 Gas-Fired Work Activated Air-Conditioning and Heat Pump Appliances (Same as CGA 2 92a)《燃气、工作激活空气调节和热泵器具(同 CGA 2 92a)》.pdfANSI Z21 40 2a-1997 Gas-Fired Work Activated Air-Conditioning and Heat Pump Appliances (Same as CGA 2 92a)《燃气、工作激活空气调节和热泵器具(同 CGA 2 92a)》.pdf
  • ANSI Z124 9-2004 American National Standard for Plastic Urinal Fixtures《塑料小便器用美国国家标准》.pdfANSI Z124 9-2004 American National Standard for Plastic Urinal Fixtures《塑料小便器用美国国家标准》.pdf
  • ANSI Z124 4-2006 American National Standard for Plastic Water Closet Bowls and Tanks《塑料抽水马桶和水箱用美国国家标准》.pdfANSI Z124 4-2006 American National Standard for Plastic Water Closet Bowls and Tanks《塑料抽水马桶和水箱用美国国家标准》.pdf
  • ANSI Z124 3-2005 American National Standard for Plastic Lavatories《塑料洗脸盆用美国国家标准》.pdfANSI Z124 3-2005 American National Standard for Plastic Lavatories《塑料洗脸盆用美国国家标准》.pdf
  • ANSI T1 659-1996 Telecommunications - Mobility Management Application Protocol (MMAP) RCF-RACF Operations《电信 可移动管理应用协议(MMAP) RCF-RACF操作》.pdfANSI T1 659-1996 Telecommunications - Mobility Management Application Protocol (MMAP) RCF-RACF Operations《电信 可移动管理应用协议(MMAP) RCF-RACF操作》.pdf
  • ANSI T1 651-1996 Telecommunications – Mobility Management Application Protocol (MMAP)《电信 可移动性管理应用协议》.pdfANSI T1 651-1996 Telecommunications – Mobility Management Application Protocol (MMAP)《电信 可移动性管理应用协议》.pdf
  • ANSI T1 609-1999 Interworking between the ISDN User-Network Interface Protocol and the Signalling System Number 7 ISDN User Part《电信 ISDN用户间网络接口协议和7号信令系统ISDN用户部分.pdfANSI T1 609-1999 Interworking between the ISDN User-Network Interface Protocol and the Signalling System Number 7 ISDN User Part《电信 ISDN用户间网络接口协议和7号信令系统ISDN用户部分.pdf
  • ANSI T1 605-1991 Integrated Services Digital Network (ISDN) - Basic Access Interface for S and T Reference Points (Layer 1 Specification)《综合服务数字网络(ISDN) S和T基准点的.pdfANSI T1 605-1991 Integrated Services Digital Network (ISDN) - Basic Access Interface for S and T Reference Points (Layer 1 Specification)《综合服务数字网络(ISDN) S和T基准点的.pdf
  • 猜你喜欢
    相关搜索

    当前位置:首页 > 标准规范 > 国际标准 > ANSI

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1