AGOCG logo
Graphics Multimedia VR Visualisation Contents
Training Reports Workshops Briefings Index
This report is also available as an Acrobat file.
Back Next

Thinking About Graphical Data

It is useful to commence a discussion of file formats with some conceptual models which put a framework on the ideas being presented. Too often we compare file formats as if they are the same, when they are in fact very different. Files composed of image data, for example a satellite image, consist of very different information from a picture of a car engine which might require a fine level of detail for display. This may be different again from an artist's sketch of a car design for an advertising campaign.

 

The Computer Graphics Reference Model (CGRM) which has been developed to describe data which may have a graphical representation is a good place to start. This model gives a basis for comparing the different file formats. It is clear that these file formats do not follow the model and many cover several potentially different conceptual ideas. However, by looking at the CGRM the role, or roles, for these, and other, file formats become clearer.

Computer Graphics Reference Model

The CGRM recognises five different environments for computer graphics: Construction; Virtual; Viewing; Logical; Realization. Most of the information that is generated by an application and is to be rendered, will have progressed through a number of specific transformations and attribute bindings in order to produce a displayable image. The data moves forward through the stages from the Construction to the Realization environment. At each stage, the graphical information, or composition, can be stored as a metafile of information. the diagram below shows the environments and the names of the related compositions which can be stored.

Environments and Compositions in the Computer Graphics Reference Model

The CGRM recognises that data can flow between the different environments. The process of data moving up from a higher to a lower environment is known as "absorption" and the process of data moving from a lower to a higher environment through input of graphical data, for example through digitization, is known as "emanation".

 

Here we are concerned with file formats and as such we will look at the nature of a typical data capture metafile from each of the environments in the CGRM.

Construction Environment

This is the environment that interfaces to the application. The application data to be displayed is prepared as a "model" from which specific graphics scenes may be produced.

 

The data stored at this level generally relates to the application and is not readily transferred between dissimilar applications. Examples include CAE interchange, such as STEP and IGES, the PHIGS archive file and the Image Interchange Facility if it is associated with application information.

Virtual Environment

In this environment, a "scene" of the model to be projected is produced from a set of virtual output primitives. As the geometry of these virtual primitives is completely defined, scenes are necessarily geometrically complete.

 

Within GKS:1985, for example, the production of primitives in Normalized Device Coordinate (NDC) space with attributes bound corresponds to the virtual environment. The Workstation Independent Segment Store (WISS) in GKS is a segment store to which all workstations have access.

Viewing Environment

In this environment a specific view of the scene is taken and the "picture" to be presented is projected. Output primitives in the viewing environment may have a lower geometric dimensionality than in the virtual environment, for example a 3D picture produced by a PHIGS application may be stored as a 2D Computer Graphics Metafile. The Computer Graphics Metafile (CGM) is an example of storage at the viewing environment. GKS:1994 allows the NDC Picture to be stored as a CGM at this level in the pipeline. VRML version 1.0 provides a 3D scene which is also probably at this level. VRML 2.0 moves the format up the pipeline.

Logical Environment

In this environment, the picture is rendered as a graphical image ready for presentation. Associated with each graphical output primitive is a set of properties to be ultimately realized by the rendering. All the attributes are bound to the primitive at this stage but the image itself is not actually rendered. For example, if we consider an output file destined for portrayal on a plotter, although we have defined the conceptual pen to be used the actual colour of the pen and the line thickness have not been resolved; everything is logically bound but the relevant device tables have been looked up. Examples of storage at the logical environment include TIFF, GIF and PNG

Realization Environment

In this environment, the graphical image is presented as a conceptual display for subsequent output to a specific device. This device need not directly correspond to the physical display. At this level all of the attributes (e.g. colours) are tightly bound. The storage at this environment is known as the "lexeme store". Examples of storage at the physical environment and files of compressed image data using perhaps the JPEG and MPEG techniques.

 

 

CGRM gives us the basis for thinking more clearly about file formats and to describe more accurately particular formats. It is important to know what we can achieve with particular file formats.

Formats, Transfer and Processing

There is a tendency to only be concerned with simplicity of interpretation and to be less concerned with the file size or with the amount of information which is being exchanged. This has resulted in the graphics on the WWW being lowest common denominator raster graphics. What we see is what we get, but we might actually want more than this and have the ability to modify the graphics and to interact with it.

 

The selection of formats for exchange is a balance between a number of factors including:

 

• file size

• processing required to interpret the information

• information in the file

 

The early history of the WWW has seen a predominance of raster formats being used, mainly either GIF or JPEG files.

 

It seems likely that this will change as the requirement for exchange of graphical information (and not just "pretty pictures") becomes a more major requirement.