Boebert.NSP@hi-multics@sri-unix.UUCP (09/09/83)
I am currently working on a proposal for a system which produces graphics output. The output is to be the results of scientific calculations--curves in 2- and 3-space, and surfaces. We wish to make the system as device-independent as possible. We are adopting the obvious strategy of carrying pictures in some standard format and then writing device-specific drivers. Does anyone know of an existing or de facto standard for the storage of such pictoral information? Is there a graphics chip that dominates the market to an extent that its repetiore is the effective standard? Any and all ideas welcome. Earl
brucec@tekecs.UUCP (Bruce Cohen) (09/26/83)
Ah, yes, graphic standards. At the moment the only standard for the storage of pictorial information is IGES (ANSI Y14 something or other) which has to do with the form of data for interchange of CAD information. I don't think that that's what you are talking about though. There is a standard for graphics software interface, called GKS. It is currently an ISO (international) standard, and an American version is about to become a standard. Unfortunately, it is intended to be a subroutine package interface, so that's not what you need either. ANSI is working on something called the Virtual Device Metafile (VDM), which is an interchange standard for graphic (pictorial) data. It is intended to support GKS, as a storage and communication medium for images defined using GKS. The standard contains a binary encoding, useful for files and parallel interfaces, and a character encoding, useful for transmission over communications channels (such as uucp). VDM is now being voted on to see whether it is ready to go out for public review, so unless disaster befalls it, it should be standard by sometime early next year. Regrettably, GKS and VDM are two-dimensional graphics interfaces, intended largely for plotting and drawing applications rather than solids or surface modeling. SIGGRAPH Core is an interface which includes 3D, but is not really a standard (the thirty or so implementations available are all mutually incompatible in some way or other), and the metafile proposal for it leaves something to be desired. For what its worth, here are sources for information on these standards: Core - "Status Report of the Graphic Standards Planning Committee" published as Vol. 13, #3 of Computer Graphics by ACM SIGGRAPH GKS and VDM - Barry Shepherd Vice Chair, ANSI X3H3 Committee on Computer Graphics IBM Corp. 445/050-2 Highway 52 and NW 37th Street Rochester, MN 55901 phone (507) 286-5543 As for the question on de facto standard chips: take my advice and DON'T. There is one VLSI graphics controller available now (the NEC 7220, aka Intel 82720), but it's not just brain-damaged, it's quadreplegic. I have served as software consultant to two graphic controller hardware projects in the last year, and in both cases, after analyzing the kinds of graphics to be done, and doing estimates of the performance of software to replace the 7220, I advised that the designers dump the chip and use the software instead. The software turns out to be faster for any really useful graphics. I know of at least three other chips which will be on the market in the near future, and at least five much more powerful ones being worked on. None of these chips looks much like any of the others, so don't look to them for some sort of interface standard. Even if you have to roll your own interface standard, you're better off having one which reflects the graphics you have to draw rather than the drawing the hardware is good at. Bruce Cohen UUCP: ...!teklabs!tekecs!brucec CSNET: tekecs!brucec@tektronix ARPA: tekecs!brucec.tektronix@rand-relay
rld@pyuxnn.UUCP (09/28/83)
Please pardon my ignorance, but isn't the AT&T-blessed NAPLPS
a "standard" for data representation of graphics images
(and called a "protocol" by some, but since its only one-way I wouldn't.)?
>>>>> Bob Duncanson, AT&T Bell Laboratories, eagle!pyuxnn!rld <<<<<brucec@tekecs.UUCP (Bruce Cohen) (10/01/83)
I would not call NAPLPS a *graphic* standard. Rather it is an image or picture communication standard. The difference is not trivial. Graphic standards or would-be standards to date have been attempts to provide a standard method of describing an abstract set of objects in an abstract graphic coordinate space, using some fairly universal set of primitive operations like line, curve, etc. These abstractions were deliberately as device-independent as the designers of the standard could make them. Thus GKS or Core can be displayed on plotters, directed beam tubes, DVSTs, or raster displays. Also, the standards try to deal with the sorts of abstractions that the application programs running on them use. Thus you can deal with relatively ideal lines of (near) zero thickness, etc. Editing graphics is easy, in general. To take out a line from a graphic object, remove the description of the line from the list of graphic primitives in the object. NAPLPS is a device-dependent drawing protocol kludged onto the standard techniques for transmitting character-coded alphanumeric and terminal control information. The resultant pictures are inherently raster oriented, are described in a pixel space, rather than a device-independent coordinate space, and suffer from the same sorts of side-effects as terminal control codes (relationship to the cursor, scrolling, protected text areas, etc.) Editing is highly complicated by the admixture of characters and graphics, by the complicated parsing required to determine the meaning of a given character, and by the side-effects. My point is not that NAPLPS is a bad standard (though I have some reservations about parts of it), but that it was not designed for use as a standard interface to graphic utilities, or as a standard description language for building and editing images. Rather, it was designed for the efficient transmission of already created pictures. The typical operation of a videotex system, which is what NAPLPS was developed for, is to fetch a data stream representing a picture from a database, and send it to a terminal. Bruce Cohen UUCP: ...!teklabs!tekecs!brucec CSNET: tekecs!brucec@tektronix ARPA: tekecs!brucec.tektronix@rand-relay