There is much of interest in this issue! Please note all the offers in the Graphics Coordinator's report - software, training materials, and reports. There has been much interest in the recent articles on activities in Scientific Visualisation. Further developments are in process in this area - please see the report on the recent AGOCG Workshop on Scientific Visualisation - this is in the section on Reports from Meetings. Also the theme of CG International 91 to be held at MIT, 26-28 June 1991, is on Visualisation of Physical Phenomena.
This month we have a Correspondence section devoted to X - compulsory reading for all X enthusiasts! Thanks, Chris, for writing yet a further contribution. For those interested in X-server software on PCs and Macintosh, please see the report from Brian Negus in the news from the Workstations Working Party. In the section on Graphics Standards we have an article from Bob Hopgood on the revision of GKS which is currently in progress. Any further contributions in the area of Graphics Standards would be welcome for future issues.
We have articles on PC graphics add-ons. and also on the challenges created by different versions of PostScript! Thank you to our contributors.
Articles on further graphics topics are invited for future issues. Please send your contributions to me.
In this issue Bob McGonigle starts a new section on Graphics around the Country. The purpose of this section is to provide coverage of what is going on in graphics in academia and research establishments. Bob begins this section north of the border! However, in future issues we would like to see your establishment featured - please read Bob's Introduction and send him your contributions!
The Workstations Working Party has been investigating X server software for IBM-compatible PCs and Macintosh for some time now. This software allows a personal computer, connected to an Ethernet network, to act as an X Window terminal. CHEST negotiations with a short list of suppliers have now begun in earnest and it is expected that a deal could be in place very soon indeed.
The initial CHEST offer is likely to include software for both DOS and MS Windows based PCs. Software for the Macintosh is still under review. As a rough guide, the DOS products perform adequately on a 286 with 640K and an additional 1 Mbyte of memory. The Windows products, of course, work better in a more generous configuration like any other MS Windows application.
Details will be published on the NISS Bulletin Board and elsewhere when available.
I am using this Newsletter as an opportunity to let you know about the various graphics deals that have been negotiated recently. It also contains details of the Technical Reports and Training Materials produced by AGOCG.
We are always reviewing the work that is supported by AGOCG and also work that I do. Please let me know if you have any ideas for things which could be done. Recently I have been working on the organisation of the Visualisation Workshop (see article in this Newsletter), setting up the PC Graphics deal with the IGWP and CHEST and sorting out the various reports and training materials that are advertised in here. I am also collecting information on scanners and if you would like the details when they are gathered together please mail me a postal address.
A course on computer graphics for postgraduate students is an item which has been mentioned before. A meeting has now been held to discuss this and there seems to be support in principle to the idea from the research councils. I am drafting a proposal as to the content, timing and length of such a course. We see this as being a three or four day event with participants from a range of disciplines looking at techniques, good practice and state-of-the-art issues. I would like to hear from people supervising or supporting students with input to the planning of the course. What should be in there? When should it be held? I look forward to hearing from you.
There are now a number of deals for CGM products. These include Metacheck and Metaview (for checking and viewing metafiles); Metapict and GraphPorter (for import and export of CGMs to and from the Apple Macintosh); LUT-CGM (a Fortran subroutine library for interfacing to CGM at the device driver level); RAL-CGM for conversion and translation of CGMs (see February's Graphics Newsletter).
Alan Francis of Page Description is going to provide some initial CGM support for these products and for the CGM in general via the Newcastle Mailbase chest-cgm. Alan can also be contacted directly at ralcgm@rl.ib. Any answers provided by Alan will be input to the mailbase. Details of using the Newcastle mailbase have been included in previous newsletters.
We will be taking delivery of a PC version of GKS. This is from System Simulation Ltd and is the subject of a CHEST site licence deal. It will run on any MS-DOS machine. The GKS-PC is a level 2c implementation and supports a range of graphics boards (CGA, VGA, EGA and Hercules). It outputs CGMs. The initial implementation will support the Prospera Fortran compiler; this will be followed by releases for the Ryan McFarland and Microsoft compilers. The software is written in C and may be accessed via the Fortran standard language binding or from the C language. The site licence cost in the first year will not exceed £300 and the cost for years two to five will be £600. CHEST contacts will be sent full details when it is available.
At the time of writing the final touches are being put on an agreement between Computer Associates and CHEST for the purchase of the CricketGraph software. This is a data presentation package used primarily for displaying 2D data in a variety of ways. It is available for the IBM PC and the Apple Macintosh. The deal will also include Cricket Presents for sites taking up the deal. The cost for a site licence is being negotiated between Computer Associates and CHEST and will be announced at a future date.
The following Technical Reports are available.
1. The Relationship Between CGI and X, DB Arnold and G J Reynolds
2. Colour Printer Evaluation, R L Middleton. This is the report of the AGOCG commissioned evaluation which resulted in the current deal with Sintrom for the QMS printer.
3. PC Graphics Evaluation, IUSC Graphics Working Party. This is the report of an evaluation of presentation graphics packages for PCs which gives details of the capabilities and ease of use of a wide range of packages.
4. Use of Colour in Computer Graphics, F R A Hopgood. This discusses the good use of colour in computer graphics and suggests some rules to follow. It is accompanied by a copy of the Tektronix~ booklet Picture Perfect.
5. Graphics Operational Requirement. This has been drafted by AGOCG as the basis for a graphics section in operational requirements. It follows the CCTA guidelines and is suitable for direct insertion in ORs. It has been submitted to the CCTA.
6. Evaluation of CGM Generator and Interpreter Software, A H Francis. This report looks at CGMs generated by a range of graphics packages and considers the range of CGMs which can be taken into packages.
To order these send your request giving the number(s) of the report(s) you wish to have and your postal address to me.
The Graphics Standards Training Materials are designed to give the basis for a short course on:
In all cases the sets include:
Ordering the lecturer pack means that you get the OHPs, notes, single sided master for the introductory guide and two made up copies of the guide. The guides may be ordered separately as can the guide masters for in-house copying. These are available at no cost.
The Uniras Training Materials master set and individual booklets are still available. The master set provides you with the basis for courses and user documentation and is excellent value at £50.
For an order form for the training materials please send me your postal address.
This has certainly generated lots of interest in the community. I think that the evaluation has given a good basis for people to make a decision as to what to buy and what parameters to look at. Roy Middleton from Edinburgh who carried out the initial evaluation for AGOCG has looked at some more printers; contact him for more details (r.middleton@uk.ac.ed). Copies of the original report can be obtained from me if you send your postal address.
The rate of exchange has affected the pricing and this is now in the CHEST contract. The price will change with the rate of exchange. Full details are available from CHEST and they have been sent to all their contacts. The contract also allows for upgrades to the PostScript chip which can be made on site or back at QMS.
Just to remind you, the deal includes the following:
The deals also include maintenance on an 8-hour-onsite basis until July 1994. We feel that this gives you a guaranteed working purchase which will not cost you anything to maintain for over three years.
The current price is £6899 for the A4 model and £11950 for the A3 model (based on an exchange rate of $1.94 to £1) plus VAT.
For more details please contact your CHEST representative.
Sintrom (who are the dealers for the QMS) can be contacted on email as:sintrom@uk.ac.swurcc.
Chris Cartledge's recent article on X in Issues 14 and 15 generated a lot of interest. Here is more for X enthusiasts!
Dear Rae, I welcome Chris Cartledge's article on X; it is interesting to read a description written from a graphics programmer's point of view. But, having used X from the systems side, I would like to make a few comments.
An X server is a process which controls a bit-mapped graphics display, and displays graphics sent to it by other processes called clients. Client processes mayor may not run on the same machine as the server; if they do not, the X protocol is layered on top of a mutually understood network protocol. X is therefore NOT a terminal protocol, at least not as I understand the term. Terminals are treated by a processor as character based devices.
Although the X window protocol was designed for use in a distributed system using high-speed local-area networks, it makes no assumption about how machines transport the data. Yes, you can transport X protocol over serial lines, but only if both ends of the link understand a serial line network protocol such as TCP/IP via SLIP on which X can be layered. 19.2Kbaud seems terribly optimistic; one X terminal manufacturer recommends not less than 38.4Kbaud, even for the most basic monochrome application. Colour over serial lines? Forget it. X is designed for the high speed networks now and in the near future which can cope with data in high bandwidth bursts. Terminal protocols are designed for serial lines, and how many sites are installing dozens of new serial lines in their buildings rather than Thin Wire or Twisted Pair Ethernet? (Any readers whose sites are installing serial lines wholesale might like to reconsider their networking strategy before replying.)
If a machine runs only an X server process, then the combination is generally referred to as an X terminal. The words 'terminal' and 'server' are unambiguous; the former includes the latter. Dedicated X terminals are now common peripherals, but PCs and Macs can also run X server software, effectively becoming X terminals while doing so. Of course, X terminals can only display the graphics of a client process on another machine; multiprocessing workstations normally run clients and a server concurrently.
Although it is true that xterm and its derivatives are the commonest text to X translators at the moment, xterm is not a fundamental part of X. There are other ways of dealing with text I/O and interfacing with an operating system. Chris mentioned IXI's X.Desktop; IXI also have a text to X translator called X.Deskterm. There are also many other products which avoid emulating a glass terminal, the most complex way to perform text I/O.
Window managers merely give the user some control over the behaviour of a display. They ONL Y communicate with clients via the server, and only ADVISE a client to change its behaviour; uncooperative clients can (and do) ignore them. They definitely neither multiplex I/O between multiple clients nor implement cut and paste between windows; the server does all that. You can kill a window manager process while several other clients are running and cut/paste between them at will. What you lose is the ability to move them around or iconify them.
ICCCM is the Inter-Client Communication Conventions Manual; it advises on client interaction in areas other than hardware sharing; in particular how application clients should interact with a window manager, and how clients use the cut/paste buffer. Virtually all applications now written use the Xt toolkit with a widget set like OSF/Motif, which also handles ICCCM behaviour. There is usually no reason to bypass the toolkit (it is hard work), so while an application's look and feel are ultimately under the application programmer's control, they normally depend on the toolkit.
UIL is part of the OSF/Motif package, but I do not recommend it as a high-level interface generator. It is almost as difficult to learn as toolkit programming, the source code almost as long, and it is (within our experience) less powerful. Its real value is as a standard format for interface definitions generated from different graphical interface builders.
A very important part of the X protocol is extensibility; there is a mechanism for allowing extra functionality to be added without requiring a new protocol, which also provides for negotiation so that client and server use the same extensions. Chris mentioned 3D PRIGS graphics (PEX), but there are also Video (VEX), PostScript (PSEX), and Synchronisation (work it out) extensions either available or planned by various companies.
Finally, the European X User Group (EXUG) have a strong academic membership, and are contactable at exug@unipalm.co.uk; one of the perks of membership is a mailing list for enquiries which is a very useful source of information. Anyone who has criticisms of X's graphics functionality may find that joining EXUG is a good first step in finding a solution.
Chris Cartledge responds:
Dear Editor,
Peter Lister corrects my description of the way a window manager works which was wrong, for which I apologise. His description is correct. The window manager is a client of the server. It communicates with other clients only via the server using the X protocol. Clients should react correctly, but may not. It is the server that acts as the multiplexor/demultiplexor.
Peter also makes some useful clarifications, however I would like to differ on some points.
The X protocol primarily connects applications to displays with keyboard and mouse. Thus terminal protocol accurately describes its major functionality. That X requires more than a straight serial connection seems irrelevant (particularly to users); so does VT (Virtual Terminal), for example. Peter's description of the X protocol is more about how X is implemented than about its functionality and his restriction of terminal protocols to character based devices hardly corresponds with my experience. It is twenty-two years since I programmed the 4006, a green screen storage tube Tektronix graphics display that pre-dated the 4010. We always called that a terminal.
Peter correctly notes the difference between an X server and a terminal. Strictly the server is the process that handles the display. An X terminal is a display - keyboard, pointer and screen(s) - running a server process.
Xterm or similar is a fundamental part of the X system in allowing existing unmodified text applications to run in an X window.
I fail to see how my joining a user group will help with the problems of interactive computer graphics and X, which are real and have been noted not only by myself. I am concerned about the confusion that exists in many people's minds over the different requirements of traditional computer graphics applications (and now typesetting with others), and those of graphical user interfaces. For many years we built unsatisfactory graphical user interfaces with systems designed for computer graphics. We are now getting inadequate support for computer graphics from systems designed for graphical user interfaces and windowing.
By interactive graphics, I particularly refer to those applications where there is direct interaction over the picture (drafting for example). Real computer graphics (as opposed to image) applications display geometric primitives specified by points (often only in two dimensions) stored at high resolution as floating point numbers. X knows only about pixels, perhaps 1000 by 1000 points, so to zoom a picture, or to handle damage caused by deleting a line or two requires a lot of work by the application and a lot of communication. In this respect X is hardly minimising the use of available bandwidth and is genuinely a step backwards from old technology graphics terminals.
Further, because X output is tied to pixels, the quality of copy output is limited, leading to the low quality material typically published. Any application wanting high quality output must run in a multi-device environment: X and PostScript or X and CGM, say. Those with device independent GKS or (heaven forbid it) GINO-F or GHOST applications would be advised to look for an X driver rather than to mistakenly convert their code wholesale!
Finally, I do not share the enthusiasm of Peter for extensions. It is true that the application should ask about the availability of an extension before using it. If it is not available then the application may take what action it will. It may simply run slower doing more work locally or may (commonly in the case of some extensions) decide not to run at all. The latter action would appear to nullify, from the user's point of view, any advantage of a common underlying protocol.
There has been a dearth of information about X, but I understand that the situation is about to be improved by a good introductory book by Niall Mansfield of EXUG.
GKS became an international standard in 1985. As with all international standards, it is necessary to review them after seven years and decide whether they are still appropriate or need updating. The review of GKS started over a year ago and it has been gathering pace with the aim of producing a revised standard by 1993. Ken Brodlie is the leader of the project and Bob Hopgood and David Duce from RAL are the editors of the new document. The UK through the BSI are one of the main groups active in the work.
Initially, the major problem was to decide the scope of the revision which could either be a minor change (as David Barron said of the 1966 FORTRAN standard a compilation of all the bugs) or a real attempt to update it with respect to modem ideas and hardware. Over the last year the focus has moved more towards the latter.
A major concern has been compatibility with the current GKS. At one extreme, the view is that all GKS programs should continue to run even if they exploit errors in the current standard. At the other extreme, the emphasis is on producing a 2D graphics standard of real value irrespective of compatibility. The current work is somewhere in the middle. With the current GKS, implementations can vary quite widely in functionality due to places where the standard allows implementations to be different. The view is that the new GKS should be allowed a similar amount of freedom in terms of being incompatible.
Graphical output in the current GKS flows down a pipe from the application to the device having attributes bound on the way. Although there are places in the document where the Normalised Device Coordinate picture is described, the concept of a current picture is rather vague in GKS. Consequently, picture capture in a Computer Graphics Metafile is ill-defined and tends to be done using a pseudo-workstation. The revised GKS has started with the aim of making the NDC picture well defined and a much stronger concept. The new document tends to describe how functions change the NDC picture whereas the old document tended to describe what flowed down the pipe. Changes to the NDC picture cause changes to occur on the workstation's display so, in some sense, this change in style could have been just that but that is not the case.
The next area tackled was segment store. The GKS segment storage facility is just a collection of primitives with a few operator-related attributes. Names could be associated with primitives via the pick identifier. The new GKS tries to extend the concept of names associated with primitives along the lines that first appeared in PHIGS. Each primitive can have a set of names associated with it. Segment store is replaced by Picture Part Store where the parts are collections of primitives, like segments. The new GKS allows the contents of picture parts to be added to the NDC picture dependent on a selection criterion on the name set associated with each primitive. This allows partial copies of picture parts into the NDC picture. A selection criterion also decides which primitives in the NDC picture will appear on a particular workstation (a more sophisticated version of PHIGS filters).
Work over the last six months has been to ensure compatibility with existing GKS while building on the new concepts. Segment store can be described in terms of picture part store where the segment name is just part of the name set associated with a primitive. Functions in the new GKS will be provided to allow existing users to work in terms of segments if they so desire.
A recent meeting in Bonn spent a great deal of time resolving a number of inconsistencies with existing GKS that were causing concern to the German DIN and Austrian delegates. One of the outcomes from this was to allow picture parts to be created from a selection on the NDC picture. This solved an inconsistency between the old and new GKS in how segments were created but also provided some interesting new functionality in the area of interactive picture composition.
The output from the Bonn meeting will be a Committee Draft (new terminology for what used to be called a Draft Proposal) document. This is the first rung on the standards ladder. It should be available in June and, if accepted internationally, will be the basis for the new standard which it is hoped will be completed by 1993. For people interested in more details, an article by Ken Brodlie et al is appearing in the CAD Journal later this year.
One aim of the new document is to remove many of the implementation dependencies and to make the document more formal. David Duce has been concentrating on this area with a strong emphasis on getting the data types precise. This has resulted in a more compact document. The 245 page 1985 document has been reduced to a 100 page document describing a system with increased functionality. The new GKS is even environmentally friendly!
An idea for all of those with one of these new colour printer things. I expect that most sites print a header page for a user's laser printing job and the like, but what do you do for colour prints when it costs 3Op-40p just for the colour header?
At Loughborough we have decided to produce a header page, but on our mono laser printer. This takes the cost down to about 3p for the banner which is negligible.
In the colour printer driver all you have to do is send a small PostScript program as a normal print job to the laser printer, clearly marked as a header for the colour printer, and with the user's id on it so they can pick it up. We also add a reduced copy of the user's picture on the header page for easy identification.
Recently, AGOCG expressed interest in starting a list of PC and workstations graphics add-ons. A brief survey was conducted by staff at RAL, which showed that due to a limited number of products, the workstations list would be of very little use. The abundance of PC products, on the other hand, seemed to indicate that having just a list is not enough. This article will summarise the information on PC add-ons in the hope of gathering comments which will give AGOCG some idea of what are the real needs in this area.
The term is not clearly defined. For the purposes of the survey, it has been taken to mean graphics boards. Amongst those, three categories were identified:
Two products were looked at here: Matrox's Illuminator-16 and Integrex's VideoCel/PC. Both have multi-standard input/output capability (RGB, NTSC, PAL, S-Video), multiple frame buffer, and live video display features.
Real-time video special effects are available through software utilities provided as standard with Illuminator-16 and as an option with VideoCel/PC.
Both boards occupy a single PC slot, but Illuminator is targeted at PC ATs and PS/2s, while VideoCel/pC covers the XT/AT range. The PC AT version of Illuminator-16 costs £1360 (NTSC) or £1900 (PAL with the additional 2 megabytes of memory).
All prices are quoted at their October 1990 levels and exclude VAT and delivery
The PS/2 versions are 15% dearer. VideoCel/PC starts at £899 and goes up to £1299, depending on the amount of the on-board memory installed.
A wide range of products was in evidence in this category. At the lower end of the spectrum, all manufacturers offer a general purpose board, designed to turn a PC into a low-cost graphics workstation. At the other end are the highly specialised boards, aiming to either optimise the performance of the more commonly used CAD and DTP packages, or provide a comprehensive environment for the applications developer. Boards from three manufacturers are detailed below.
Omnicomp manufacture and market graphics display systems for OEMs and system integrators. Their product range is tailored accordingly. It consists of the following boards:
Artist Graphics offer graphics controllers for PC, PS/2 and Macintosh computers. They will also build boards to order. There are four AT-bus models in their XJ Series:
Matrox's MG series consists of four boards, each offering display control and display list processing. The boards are based on the Texas Instruments 320C25 processor and use the Western Digital 8514/A chip set as their graphics engines. MG-104, the basic model, has a resolution of 1024 × 768 and can display up to 16 colours simultaneously. MG0128, the top model in the series, has a resolution of 1280 × 1024 and can display up to 256 colours. Prices: MG-104 is £1295, MG-108 is £144, MG-l24 is £1895, and MG-128 is £2295 (all PC AT versions. PS/2 versions are generally 15% dearer).
PC board manufacturers appear to be competing not only with the workstation market, but with superworkstation market as well. The Silicon Graphics Iris seems to be their target to beat. Two manufacturers had products in this category.
Their Reality PC board is a 3D supercomputer and image generator for PC/ATs. It combines geometry processing and colour rendering within a single board format. Based on either two or four Intel i860 processors, and equipped with 4 or 16 megabytes of DRAM, Reality PC has a 1024 × 1024 × 24 frame buffer with 4 overlay planes. A documented PRIGS compatible library, written in C, is also provided. It is down-loaded to the board during the power-up and contains custom PRIGS extensions such as algorithms for collision detection, height above terrain etc. Price: £12,000 (2 processors 4 megabytes) and £16,000 (4 processors and 16 megabytes).
The Matrox EG3-1280, to be released in the first quarter of 1991, is a high resolution 3D graphics subsystem for 386 and 486-based Extended Industry Standard Architecture bus machines. It is a 2-slot 2-board set, aimed at OEMs who wish to develop 3D graphics workstations. EG3-1280 is built round Matrox's proprietary graphics engine and the TMS320C30 32-bit Digital Signal Processor. It provides 1280 × 1024 × 24 display resolution operating at 60 HZ non-interlaced refresh rate. Optional support for up to 85 Hz vertical refresh and 1600 x× 1280 display resolution is also available. PEX and Scalable X Command Interface (SXCI) come as standard. Price is yet to be announced.
Of the three categories outlined, Graphics Display Controllers seem to offer rich benefits, at a reasonable price, to a wide range of users. It is thought, however, that they are not sufficiently used by the academic community. Frame grabbers are expected to increase their presence sharply, and so this category too deserves a further investigation. Workstations and PC manufacturers trying to get a share of each others markets, Graphics Subsystems are in the state of a flux and are believed to be outside our immediate interest.
Or are they? Please direct your comments to either Anne Mumford or the author.
Twenty-nine experts from UK academia, research establishments, and industry joined in a Workshop on Scientific Visualisation. The objectives were to review progress in this area, evaluate current developments, and make recommendations to AGOCG and the Computer Board concerning any initiatives for the UK to consider. The following areas of Scientific Visualisation were considered: Framework, Techniques, Data Facilities, Human-Computer Interface, Applications and Products. Material in each of these areas was put together and will form part of the overall report.
The Workshop output will consist of a management report; an Introductory Guide to Visualisation, which is to be made widely available in the UK academic and research community by AGOCG; Reference Guide; Video.
The purpose of the separate Introductory Guide is to explain in simple terms what Scientific Visualisation is and what it can do, and give illustrations and explanations of the technical terms in a way the non-specialist can understand. It is intended for the general reader in a department or Computer Centre, as well as the scientific specialist, and provides a general outline of the benefits and possibilities of Scientific Visualisation.
The next Newsletter will outline availability of all these materials, once the printing schedules are known. The Workshop was supported by the Computer Board and Eurographics UK. We were also pleased to welcome Todd Elvins, a Visualisation programmer, from the San Diego Supercomputer Center.
We thank all those who contributed to the Workshop in its organisation (Anne Mumford, and the organising group) and activities. The contributions from a wide range of research and support environments led to very useful exchanges on many aspects in the field.
In January 1991 there was a joint Workshop on the subject of Graphics and Networking. This was sponsored by SIGGRAPH and SIGGCOM and held in Boulder, Colorado. The Workshop was jointly chaired by Bob Haber and Ralph Droms. The major area of discussion centred round the needs of Scientific Visualisation applications working in a distributed network environment. The major area of concern at the current time relates to the provision of suitable networking solutions for Scientific Visualisation. The challenges presented in the search for a suitable paradigm for offering suitable facilities were appreciated. The massive amounts of data; the need for high speed interaction; the need to distribute applications across different systems; the need to balance the advantages of network and data standards with the special requirements of a particular application, system and hardware/software configuration are all subjects which need to be faced. A number of the speakers also noted the visualisation of networks as an interesting application area. There is to be a follow-up session held at SIGGRAPH 91 and a further joint workshop is being considered.
This event was organised by an ad hoc group containing representatives from universities, research establishments and industry throughout Europe. Around 80 delegates attended, from a wide range of European countries including France, Germany, Italy, Portugal and Sweden. Unusually for a conference held in the UK, the British contingent was far from being the largest. There was a small exhibition including several companies selling user interface design environments with direct manipulation front ends to simplify the construction of X widgets.
Two half-day tutorials (an introduction to the X window system, and an overview of the Inter Client Communication Conventions Manual) preceded the main conference. Keynote speakers at the Conference were Dave Rosenthal of Sun Microsystems, and Glenn Widener of Tektronix. Twenty-four papers were presented, originating from a range of European and North American sources. Copies of the proceedings are available from CEP Consultants, 26/28 Albany Street, Edinburgh EHI1 3QH.
It is planned to run a similar conference with a wider theme covering other window systems for workstations and PC's, in London in November 1991. Sponsorship by Eurographics is under discussion. Anyone wishing to assist in the organisation is welcome to contact the author.
This is a new section in this new-look newsletter. It is intended to give space to those working in education and research to write on topical subjects related to their site. This is a good chance for publicity for your institution, which will perhaps help you attract support and finance. Contributions to Bob_McGonigle@uk.ac.edinburgh.
By accepting the invitation to edit this section, I was obliged to present the first article. I have been fortunate in being able to assemble it partly from a recent edition of our house journal, Edinburgh IT Forum (details from F.R.Allen@uk.ac.edinburgh). I have chosen an article from Medical Physics by Martin Connell because it illustrates the high-end of graphics using parallel processing, perhaps an area of specialised research. The other article, by way of contrast, deals with the work of the Meteorology department, and describes the variety of software that is necessary to use because of the diverse range of facility required.
It was most remarkable to me that I had to write this article at all. The subject was obvious enough, but I could find no recent article in our local Edinburgh journals to use as a base. This is because X windows is now part of our everyday working, and the days of consideration of whether it is the correct path to follow are long gone. Indeed, we now assume that packages come with an X interface as standard, but are sometimes surprised, and annoyed, to find that it is only in development.
The advantages of a window system that exists across many computer platforms, and is actively being promoted by third-party software suppliers are obvious. X is available on our central Unix and VMS services and within the majority of user departments (on our central Unix platform, we estimate that around 25% of access is through X). Numbers are difficult to estimate but X is used on about 90% of workstations. We also have dedicated X servers in the form of about 50 X terminals, and some PCs and Macs running emulators. The workstations are gominately from Sun, the X terminals from NCD (monochrome) or Tektronix (colour), and the PCs mostly use Xview from Unipalm.
Uses within departments are diverse. For instance, X and Unix are inseparable tools within the Computer Science department where X is run on 150+ X displays, to provide facilities for research, teaching and project work. In Meteorology, there are also the same trends where use is made of visualisation packages like PV-Wave, NCAR graphics and Uniras. We have also been developing X applications within the Computing Service. The communications group has developed an application that allows display of the current status of the network. The graphics and Unix teams have developed an application to provide an operator interface to our queue control mechanism. The graphics team has developed a GKS workstation to X.
An observer from outside Edinburgh may well question why there has been this whole-hearted uptake of X. The attractions of a window system and the resultant benefits are well understood. For those operating on a Unix platform, there are additional benefits of the public domain software, like xds described below or xfig (an X based monochrome drawing package). Coupled with all these attractions, the observer would also see that X performs well as the network needs have been given careful consideration. User departments, such as Computer Science, have been careful to design their internal network to be robust and to have enough bandwidth.
The Computing Service has worked hard to establish the University wide network, EdLan. This is an infrastructure network providing a spine comprising conventional thin/thick wire ethernet and fibre-optic connections. It is divided by routers into sub-networks, which control and manage network traffic, to minimise cross network traffic. The careful design of the various infrastructure and departmental networks has been a major factor in the success of X within Edinburgh.
The use of powerful workstations has changed the nature of scientific computing in the last few years by placing considerable computing power on the desktop and improving the working environment through graphical interfaces. Totally new research practises have developed as a result among which 'data visualisation' is one of the most significant. This term is usually used to describe the ability to examine interactively massive quantities of data, such as that produced by numerical models of the atmosphere or global observation programs using satellites. Commercial packages with superb facilities are now available which enormously reduce the effort in progressing from raw data, through analysis to scientific results.
The Meteorology department is involved in several key research projects in environmental science which depend heavily on visualisation. These include:
The Meteorology Department at Edinburgh University carries out most of its computing on a departmental network of Sun SPARCstations, PCs and a DEC MicroVax. The PCs use X terminal emulation to ensure that they may use the same software as the Sun workstations. These machines share a distributed file system. Software for data visualisation already used includes:
Data visualisation software is very memory intensive. This is partly because it is used to analyse large data sets but also because the internal graphics formats used are, inevitably, very large. As a result the performance of the departmental computing environment suffers through two mechanisms:
We are proposing to rectify the deficiencies described above by two specific enhancements to the network.
CT and MRI scanners produce multi-slice data which may be difficult to interpret.
Volumetric rendering is a technique in which the multi-slice image data is converted to voxels with an assigned opacity and colour. (A voxel is the 3D equivalent of a pixel and represents the volume of one element of a 3D array). The image is generated by casting rays from a viewpoint through the 3D array of voxels and summing by a transparency formula the opacities and colours along the path of the ray. Surface highlighting can be added by calculating reflections from a simulated light source and objects can be intersected by a cutting plane to show the raw 3D image data.
The main disadvantage of this method has been the time required for rendering. Because each ray calculation is independent of another, the technique is well suited for parallel computers and has been implemented on the Edinburgh University Meiko Computing Surface.
Packages now available for volumetric rendering include Sunvision(Sun) and Analyse(Mayo Clinic) for Sun computers, Voxelview (Vital Images) for Silicon Graphics computers and AVS (Stardent, DEC, Silicon Graphics). Public domain 3D display software includes XDS (zaphod.ncsa.uiuc.edu) and apE (oscsuna.osc.edu). Further details about volumetric rendering in medicine can be found in March 1990 issue of IEEE Computer Graphics.
Perhaps the biggest problem facing users of PostScript devices is that of working out why the job submitted to the printer, or whatever, produces no output. This becomes especially irksome when a file that worked on one printer does nothing on another. With the take-up of the Colour PostScript printer deal, it was requested that I share with the community some of my experience as a PostScript developer in debugging PostScript.
The standard behaviour of the PostScript interpreter, on detecting an error, is to cease processing the job and to ignore (flush) all further input until the end of job character (Control D, #4) is received. The interpreter will send an error message and a Control C (#3) character out on the serial port, if configured to use it, which may be used by controlling software to abort sending the rest of the job.
This action is not over helpful, especially since relatively little printer driver software expects any printer to answer back! There is, however, a means of modifying the behaviour of the PostScript error handler such that it will print information about the error, together with any preceding error free marks made, on the page in error and then to output that page. This revised error handler is published in the book PostScript Language Program Design (the Green book) and is also available, albeit in a slightly modified form, by FTP from York.
This file may be downloaded to a PostScript printer at power on time and will remain in effect until power off. There are comments at the head of the file to describe how to modify the file for your printer, in terms of the printer security password.
There is one error condition that even this revised behaviour will not reliably handle - that is the error VMerror. This indicates that the printer has run out of user (writeable) memory. Typically this occurs during image manipulations, but excessive use of string type objects, in PostScript, can lead to this condition. The PostScript program will probably need restructuring to avoid the error (or more memory installed on the printer ...).
There is a PostScript program, DISTILLERY, which will track the behaviour of a PostScript program and advise on its construction. This is of most use to those writing software to generate PostScript. I believe Distillery to be in the public domain but I am checking the status of this, and of several other tools of which I have or have knowledge. I am willing to put such tools as I am legally permitted, and which I am willing to recommend(!), onto our distribution area, as above. Perhaps the editor will permit me a little more space at a later date to offer more details.
Identifying what PostScript sees as an error is, of course, only the beginning. The next step is to understand the error message in order to make the required correction(s)! The error handler, described above, will dump the current user stack, arranged vertically down the page, topmost item on the stack at the top.
These are the errors that have been seen most commonly at York, together with a brief indication of what needs fixing (error message followed by possible cause):
There are, obviously, many more potential error scenarios but my experience suggests that those listed above are the most common. Good luck.
