March 15, 1993
D R A F T
There is a review and additional discussion on computer image conferencing systems in the journal article by P. Lemkin, Xconf: A Network-Based Image Conferencing System, Computers and Biomedical Research 26 1-27 (1993). This manual is based on an earlier draft of this paper.
Efficient collaboration within a group depends on sharing information in a timely manner. Telephone conferencing isn't adequate because 2-D information isn't communicated well verbally. Electronic mail (E-mail) or FAX is one solution but is subject to delays. Such "time-shifted" communication doesn't have the immediacy of a conference, E-mailed images require additional visualization software on the receiving end and FAX is limited in quantitative accuracy. In general, a considerable effort is required for groups of people to get together physically when they are not in the same general location. Limiting factors include wasted time and expense of traveling, and simply human inertia. The result is that collaborative groups don't get together at all or do so less often than they desire.
This paper describes an inexpensive partial solution to this problem, the Xconf program ([LemP91], [LemP93]), a simultaneous multimedia computer-conferencing system using existing national and international networks (the Internet). It may be used by collaborative groups who have access to both computer networks and the networked based X-Window System [SchR88] graphics displays. Image data can be supplied to Xconf in machine readable form. Since many inexpensive digital scanners are available, acquiring data for a conference is easy.
Computer conferencing is the "medium" for which conferees supply the "messages". As with any medium, there are limits in what types and amount of information can effectively be exchanged. We will be discussing the image conferencing problem in general and the Xconf solution in paticular indicating some of these limitations throughout the paper. The Xconf user interface is also breifly presented since the ease of interaction are key determinants of meeting our goal of passing the message without the medium getting in the way.
Computer conferencing has been used for several years in teaching and medical diagnostic imaging as groupware. Groupware is a means of carrying out a focused activity among a group ([EllC91], [KliR90]). Medical imaging typically requires expensive computer resources and special high speed networks to be usable for making exacting diagnostic decisions ([McGT91b], [PizS89], [DreP90]). Recently, many institutions have become connected by moderate-bandwidth national and long-haul international networks. One, called the Internet ([ComD88], [ComD89]), has provided the basic infrastructure required for lower resolution image conferencing.
Xconf - multimedia image conferencing system
Xconf was created to meet these goals. Although it provides less image resolution capability than that required by diagnostic medical imaging systems, it is sufficient for other problem domains. Because it doesn't need special hardware and networks, it may be used on a much wider range of existing hardware and networks without any change to existing hardware or software. Only one computer in the conference needs to run the Xconf program itself.
The motivation for Xconf came from our desire to collaborate with other groups of investigators using the GELLAB-II system ([LipL80], [LemP89a], [LemP89b]). GELLAB-II is a 2-D electrophoretic protein gel database software system using X-Window developed in our laboratory. [A 2D protein gel separates proteins in a sample by their apparent isoelectric point (similar to pH) and apparent molecular weight.] It allows one to compare individual polypeptide (protein) spots between sets of protein sample gels that may contain many thousands of different proteins. These gels are created under different experimental conditions so the goal is to find sets of proteins which correlate with these differences. Results are presented as images, graphs and tables. We built Xconf to simultaneously connect remotely located collaborators to the same 2-D gel database to investigate that database together as if they were in a small conference.
Xconf works by connecting users together to create a real-time conference which takes place simultaneously on all remote displays. Displays from different computer vendors can work together because of the portability of the X-Windows System. Interaction is tightly coupled so users are always aware of global changes to the conference session. In addition, any user may monitor subgroups of users conversations in local windows. By allowing conferees to concentrate on what they are interested in, this may help minimize distractions and avoid overloading participants with extraneous information.
Multimedia here includes conversational text, text files, grayscale Communication modalities can involve more than just images. We define or color images, movie sequences of images, pointers to objects in images, and the abstract notion of group execution of programs. Computer conferencing may take place with or without images depending on the needs of a particular conference.
X-Window System and computer conferencing
The popular MIT X-Window System provides the basis for Xconf by its client-server computing model. In X-Windows, a program called the client generates display window data. This window data is then automaticaly sent to another program called the display-server which displays it thereby "serving the client's need for a display". A display server may be an X-terminal, or a workstation (display, keyboard and mouse hardware) running the X display server program. These two programs may be run on the same or different machines called host system(s) because they are hosts for those programs. When the client and server programs are on different computers, a network is used to connect them. The X display server is started when X-Windows is started on a display, normally when a user logs onto their workstation.
In addition, the X-Window client-server mechanism permits windows created by a client program on one host system to be displayed on several X display server host systems [JonO89]. This latter capability is required to implement simultaneous conferencing systems such as Xconf. Under X-Windows, data is transparently passed from one system to another using standard TCP/IP or DECnet protocols. A client program accesses X-Windows through procedure calls to the basic X-Windows "Xlib" library or higher level "widget" toolkits. We wanted efficient simultaneous control of many displays, so Xlib rather than a toolkit was used with our initial Xconf design.
To simplify this discussion, when we mention display, participant, host or user, we are refering to a remote X-Window display server host system. The client refers to a single host system running the Xconf program and need not have a display itself. For example, Xconf could be run on a computer holding an image database. It is possible for a user to participate in multiple conferences by running several copies of Xconf with their display included in each conference. However, because of limited display screen space, memory, network bandwidth and probability of the user being confused, this isn't very desirable.
Centralized vs. decentralized conferencing
A network based conferencing system can be either centralized or decentralized [HilS86a]. Both methods have advantages and the disadvantages, and we will be discussing some of the issues throughout the rest of this paper. A major advantage of using a centralized client system such as Xconf is that no additional software is required on the remote X-Window display servers to support the client program. A disadvantage is it limits the effective bandwidth of interaction and thus the types of operations which can be performed quickly.
Network access to conferees' displays
In order to participate in a centralized conference, each user needs to allow the central Xconf client host access to their display. This is normally done using the standard X-Window System tool called xhost. However, Xconf is able to add additional user displays during a running conference and let users leave the conference at any time without disrupting the conference.
Simultaneous conference schema
because of store-and-forward computer technology (e.g. E-mail), it is possible to have non-simultaneous conferencing which is a form of time-shifted communication. Both modalities may exist in the same system. For example, BBN/Slate [BBN91] is a document design conferencing system which may be used for either simultaneous conferencing or time-shifted mailing of multimedia documents. Sun Microsystems has a product called ShowMe which lets users on a network view and annotate an image of a spreadsheet, document, or graphic. Other products include Communique from InSoft for Sun computers and FarSite from DataBeam for PCs. Many of these human factors issues are reviewed in ([EllC91],[McGT91b],[HilS86a]).
The simultaneous conference schema used in Xconf shows the same global windows to all users. All communication between users is controlled by a central client program that behaves like a switchboard. Figure 1 illustrates the centralized conference Xconf client schema which handles transactions from a set of remote host display servers. A non-centralized conferencing system might distribute computational and image storage capabilities across the network on remote display host computers. That would result in minimizing network bandwidth requirements. However, this would require more software at each collaborators computer and is beyond our primary goal of a simple system.
Examples of multiple user sessions are shown in screen dumps in Figures 2, 3 4 and 5.
A labeled layout of the windows on a user's screen is illustrated in Figure 6. Global windows include: a collective user keyboard input-window (c.f. Figure 7) where the set of current partial input lines of all users are displayed for carrying on a conversation; a scrollable session-window containing output from all users as well as from Xconf (c.f. Figures 8 and 10); and a small conference control-status icon-window (c.f. Figure 9). An optional scrollable pop-up-window with the same format as the session-window (c.f. Figure 8) may be used for local help, information, status and sub-session logging information.
When image files are specified when Xconf is started, then additional windows containing these images are downloaded into each user's display before the conference starts. These image frames may be sequentially displayed, flickered, used for movies by animating sequences of frames, or objects in thiese image pin-marked by individual users. Later, we will discuss exporting windows from any user's screen into the conference.
All of these windows except for the pop-up-window are considered global to the conference and are displayed simultaneously on all remote displays. This helps preserve a conference's cohesiveness. Each user controls their local scrollable pop-up-window that may be used for additional conference displays specific to that user and which are not visible to other users. % ==================> screen dump of FLICKER mode with 2 gels
*** Insert Figure 1, same as fig 1 of [LemP93] **** % ==================> screen dump of FLICKER mode with 2 gels *** Insert Figure 2, same as fig 2 of [LemP93] ****
Figure 2. Screen dump of a five user conference. An icon-window at the top of the screen shows the status of the conference (which is in Flicker-mode - the [F] indicates Flicker-mode and user bill is the Master user) and gives instructions for entering or leaving the conference. The current users keyboard inputs are shown in the Xconf-INPUT window (including their typographic errors!); combined session information is in the Xconf-SESSION window that has scrollbar control. Three sets of control pushbuttons: local (right column), global (top row) and mode-specific (bottom row) are available in the Xconf-SESSION window. Two 512x512 pixel image frame windows of 2D gel electrophetic gels (lymphocyte samples from a leukemia gel data base [LesE82] - acute myelocytic leukemia on the left and HL-60 cell line on the right) are shown on the bottom part of the screen. These have several colored pin mark labels inserted by different users `a' for user bill and `b' for user lola. The names in the pin labels correspond to the names in the table entries {a}, {b}, etc. in the Xconf-INPUT window. The coordinates of the pins are logged in the session window. Conversational text and operations are logged in the session window labeled by host name tag, e.g. [bill], [lola], [opus], [outland], [portnoy]. Flicker-mode allows locally aligning two images for comparison purposes by alternately displaying one and then the other while moving one relative to the other. [Note: actual grayscale screen resolution is much better than shown in this screen dumps - dithering was used when dumping the screen onto a bi-tonal laser printer.]
% ==================> screen dump of MOSAIC in MOVIE mode with 2 gels *** Insert Figure 3, same as fig 3 of [LemP93] ****
Figure 3. Screen dump of a multiuser conference in movie mode. This illustrates a navigation mosaic icon-map consisting of twelve image frames of different lymphocyte sample gels from a human leukemia gel database [LesE82]. The mosaic map helps users navigate through the set of images by seeing what images are currently available to the conference for flickering or making movies etc. The images in the database are represented by sampling images into small panels. The 512x512 pixel 2D gel images could be sampled by 2 resulting in the 256x256 size images when network hight bandwidth is not available. [Note: actual grayscale screen resolution is much better than shown in this screen dumps - dithering was used when dumping the screen onto a bi-tonal laser printer.] % ==================> screen dump of MOSAIC in 5 frame MRI heart MOVIE *** Insert Figure 4, same as fig 4 of [LemP93] ****
Figure 4 Screen dump of a three user conference using five MRI heart images graciously supplied by Steve Bacharach of NCI. These are transaxial, ECG gated, images of the heart in a subject with hypertrophic cardiomyopathy - i.e. a very thick heart muscle. They were made with a GE 1.5 Tesla Nuclear Magnetic Resonance Scanner. You can see the very thick ventricular muscle surrounding the ventricular cavity. The images span the time from end diastole (image 1) when the ventricular chamber is largest and most filled with blood, to end systole (image 5) when the blood has been pumped from the ventricular chamber and it is very small. When viewed as a movie sequence it is possible to observe the thickening of the myocardial muscle with time, and to visualize the contraction of the ventricular chamber (causing expulsion of the blood from the cavity into the aorta). The standard map image on the right shows the five images in the database. Image frames 1 and 5 are shown on the left with the pin mark labels inserted as `a' for user bill. The images were 256x256x8bit pixels. [Note: actual grayscale screen resolution is much better than shown in this screen dumps - dithering was used when dumping the screen onto a bi-tonal laser printer.]
% ==================> screen dump of MOSAIC in 18 frame molecular model MOVIE *** Insert Figure 5, same as fig 5 of [LemP93] ****
Figure 5.} Screen dump of a three user conference using eighteen view images computed for a 360 rotation of a protein crystalographic model of voltage-gated potassium channel graciously supplied by Bob Guy and Stewart Durell of LMMB/NCI. The large cylinders represent helices. The model is a tetramer. Stewart left out one of the sub-units to expose the critical pore region which is an 8 stranded antiparallel beta barrel. This is also the closed conformation of the channel. Note that lola pin marked with a `c' in image k-chan020 where she thinks the opening is and can query the other users to immediately verify her question. The standard map image on the right shows the eighteen images in the database. The images are 512x512 pixels but were sampled by 2 in order to show two views adjacent view K-chan020 and K-chan140. [Note: actual grayscale screen resolution is much better than shown in this screen dumps - dithering was used when dumping the screen onto a bi-tonal laser printer.]
Goals of collaborative conferencing
Based on our perception of simultaneous conferencing, we have set several goals for our image conferencing system. These are: (1) using X-windows because it is a standard and has multiple-display capability; (2) sharing conversational text from all participants keyboards so it is viewed simultaneously by all - making for rapid response to points or queries; (3) comparing images from a picture file database viewed by all in which "push-pin" marks can be placed in each image by all users to point to different parts of objects for discussion; (4) aligning subregions of any two image frames by interactive flickering which involves moving one image relative to the other; (5) viewing and commenting on user created movie image-sequences; (6) sharing windows generated by users' local software by exporting them to all other conference users; (7) running application programs such as database programs with all users seeing the interaction as it occurs.
An implication of goal (6) is to allow any user to import a snapshot of any window from their display to the conference which then exports it to all other conferees as a standard conferencing system image window. Because it is an image window, we can stick pins in it, flicker it or make movies with it. This capability allows us to share other software which generates X-Window graphics (eg. molecular models, image processing, or database graphics systems, etc). Because of bandwidth limitations, our conferencing design does not update it's copies every time the original window changes - only when it is directed to.
The last goal (7), is met by providing a shared Unix shell to the conference to run any Unix program under user keyboard control. This user program might result in X-Windows being displayed on the user's system which could then be selectively exported to the entire conference.
Control of the conference
Any user may control the conference by typing or moving or pressing the mouse buttons from their remote display. The default control is a "free-for-all" mode with no one in charge. Control of the conference may temporarily be restricted to one user by declaring them the Master user. Having a Master user is advantageous when teaching new users a computer conferencing system since new users can only "listen" instead of randomly pressing keys or buttons. If further control is desired, a specific user may be declared the Moderator for the duration of the conference and may grab control away from the current Master at any time. The Master can be thought of as a baton that may be passed from user to user to "have the floor".
The paradigm of Xconf operation is that any user may converse or manipulate text or images at any time. However, session control can be invoked to limit this free-for-all dialogue if one user becomes the Master. Since all users always see the same global windows, it is necessary to show which user has caused which action. All user actions are tagged in the various input, session and image windows with "name-tags" that are the host names or alternative names defined by the users.
Moderate resolution image conferencing
We developed Xconf for image conferencing with biological problem domains which require moderate image resolution, 2D electrophoretic gels. However, image conferencing is certainly not limited to these domains.
The concept of flickering images, used in Xconf for comparing two images and for making movies, was previously used in comparing 2-D protein gels with the FLICKER [LemP79] and X-Window based Xpix GELLAB-II programs. Flickering is an interactive image comparison method of aligning two images which were not aligned at the time they were scanned or generated. It is also useful for images which have non-uniform "rubber-sheet" distortion and are thus only locally alignable. Images produced by gel electrophoresis (both 1-D and 2-D for protein, RNA and DNA materials) fall into these categories as do serial section images produced by microtome methods.
A note in Science [BarM90] lists several areas in biology where movies have proven useful. These include: medical Xrays, MRI and PET images; visible light and electron microscopy. Three-dimensional shaded images may be computed or "rendered" for viewing molecular models, organ structures, etc. For a review of multimedia conferencing, see the Xconf paper [LemP93]. In the next section we discuss some of the details of using Xconf.
Xconf benchmarks with small groups
We conducted a number of tests on the usability of Xconf on wide area networks. In one test, Xconf was used over the Internet to conference 12 users at a time in conference-only mode with satisfactory (but not spectacular) response times of about 1 second. Conferees were located both in North America and in Europe. In other tests, we have used up to 18 images at varying resolutions (512, 256, 128, and 64). Depending on the detail of the structures in the different types of image material (2D gels, MRI heart images, molecular protein models) and what is going to be discussed, more or less resolution is required for the conferencing to be usable. We have concentrated on testing the system on 2D gel image data, generally in 2 person conferences, between Frederick, MD and Atlanta, GA using an Internet connection restricted by a shared 56Kb line. It was found usable -- although not blindingly fast. It has been used over the last year from time to time to augument e-Mail, and when we need to quickly converse about text or image data.
The list of initial host displays may be specified by the Xconf Unix command line switch
-displays h1,h2,...,hn
or defaulted via the Unix shell XCONFHOSTS environmental
variable, e.g.
SETENV XCONFHOSTS h1,h2,...,hn
Each X-Window System host display specification hj is
specified as a part of a list h1,h2,...,hn where each hj is of
the form `hostName:display#.screen#'.
For example, `qubie.nci.gov:0.0'. Internet addresses for the host name may alternatively be used. Eg. `129.123.10.12'. The `:display#.screen#' part of the argument is optional and defaults to `:0.0', the value needed for a host with a single display. So `qubie.nci.gov' would suffice as a host specification. If you are on a local net which knows about qubie, then you can just specify qubie. Optionally, one could also specify a user "name-tag" prefix for each hj by proceeding any display specifications with the name tag. E.g. for a tag ` dan', one would specify `dan@qubie.nci.gov'. Then the host name-tag dan is used for labeling host dependent operations rather than `qubie.nci.gov'. The name tag may be changed at any time by each user with the MYTAG pushbutton command.
The latter two modes take advantage of 8-bit or better color displays. However, images may still be viewed on black and white displays using dithering - a process visualizing different shades of gray by different patterns of black dots/unit area (as in newspaper photographs). Dithered images can also be viewed on color displays using the -dither switch option. This lets everyone (color as well as black and white displays) see the degraded resolution that results with dithered images.
If the conference-only mode is used, no images are displayed and only the terminal input and session windows are active. The default interactive flicker mode lets each host leave its pointer pin mark in each frame; flicker two frames while moving one about the other by the mouse's position. Flickering is described in [LemP79]. Movie mode allows any number of images, called movie frames, to be read in when Xconf is started and repeatedly displayed in sequence. The movie may be run forward, backward or single stepped. The movie may also be constructed from an arbitrary list of possibly repeated frames by stepping and marking them for the movie. When flickering two images or showing a movie, the rate at which images are changed can be varied. Pressing the SYNC pushbutton toggle with the middle or left button causes the frame to be displayed on each host display before proceeding to the next frame. Using the right button to turn on SYNC, does the latter but adds a 1 second slow motion delay after a frame is displayed on all hosts. The slow motion option can also be set by using the -SLOWMOTION msecDelay Unix switch option.
Typing CTRL/T or pressing the MODE pushbutton toggles between movie, flicker and conference-only interaction modes. The current mode m appears in [m] in the first line of the master window icon illustrated in Figure 9. and is a C, M or F. The cursor screen pointer is also a C, M or F letter, depending on the mode, with an arrow in the upper left hand corner.
As mentioned before, a Xconf session consists of several windows. Screen dumps of an Xconf session with several users is shown in Figure 2-5. The global layout is illustrated in Figure 6 with details futher elaborated in Figures 7, 8, and 9.
Figure 6. Screen window layout for each display conference participant. The Master icon window is always visible. Clicking on the Master icon toggle causes the Input, Session and Image windows to be de-iconisized and become visible. Clicking again iconisizes them. The Pop-up window appears when a HELP, INFO, STATUS, or SUBSESSION pushbutton command are issued. Users can scroll their Pop-up window. Only the Master user can scroll the Session window. If a user has several Pop-up windows, they can switch between them by pressing the CYCLE pushbutton. Pressing the DELPOP pushbutton deletes the currently active Pop-up window. These are the standard image positions for flicker mode. For movie mode, all images are moved to the position of image 1. The CTRL/L or STDMAP pushbutton command reset all images to the standard position.
Figure 7. Input window layout for simultaneously viewing the current input line for all conference participants. `F' is a flag indicating: `M' current Master, `A' requesting access to the Master, `I' that display is currently iconisized, or (space) indicating not requesting the Master but is still in the conference. A host letter identification `i' is associated with each host and is used with pin-marks in the image frames. All non-control key keyboard input from each user appears in their current partial input line. The text line at the bottom of the window is used for local error messages or reverse-video prompts for dialog input for an individual user. The "paste" facility is available in the input window and may be used to receive input "cut" from other X windows.
Figure 8. Scrollable windows are provided for the simultaneous SESSION and the pop-up HELP, INFO, STATUS and SUBSESSION windows. This scroll window format is used for simultaneously viewing the common session logging output in the SESSION window. In this example, the line number k: is the scroll line number. Lines that contain [host#j], i.e. lines 101, 102, 103, 107 and 108, were caused by a global operation or input from a particular user, where host#j is its host name-tag. Each time the pin mark is moved, the mark counter gets incremented and is displayed as (n), e.g. lines 102 and 103. Lines 102 and 103 are completed keyboard input text lines. A scroll bar is visible on the left and may scroll the window by clicking at the top or bottom or to some position on the scroll indicator. In the pop-up SUBSESSION windows, the current partial input line for each user is replicated at the bottom of the session window to allow users to keep their eyes on the session window while they are typing. It also lists the hosts that are active in the filter-tag-list for that local SUBSESSION window.
The titles Xconf-INPUT and Xconf-SESSION are displayed at the top of those windows respectively. There are several pushbuttons overlaying the right edge (local options) and the bottom edge (global options) of the session window. These pushbuttons will be discussed in more detail later on. The optional pop-up window appears in the lower left hand corner is invoked using either control keys or pushbuttons. It will contain either the HELP, INFO, STATUS or local SUBSESSION scrollable window and will be titled as such. You may switch between different active pop-up windows using the CTRL/B keystrokes or CYCLE pushbutton. When images are used (in flicker or movie mode) they initially appear in the lower part of the screen but may be moved around in flicker mode using the mouse buttons or MOVE pushbutton.
Typed lines from different hosts are indicated as colored tagged lines in the input window. As input lines are terminated by the user with the RETURN key, they are moved to the scrollable session window. These are then tagged in the session window by enclosing them in ` [...]' illustrated in Figure 8. Session window lines that are global Xconf messages are not prefaced by `[ host-tag]'. However, all session window lines are assigned scroll line numbers that prefix each line and are enclosed in `{...}'.
Figure 9. Master Icon window states. (a) Upon starting a new conference request on a user's display. Typing CTRL/D rejects the request. Clicking on this icon opens up the other windows and chnages the icon to (b). Clicking again, iconifies these other windows until you click again or kill the connection with a CTRL/D as well as changing the icon back to (a). The [m] indicates the conference interaction mode where C, F and M indicate CONFERENCE-ONLY, FLICKER and MOVIE modes repectively. (a') Alternatively, when starting a conference when a Xconf password is required for all users, it first prompts for the password then switches to state (a). (b) De-iconisized state when there is no Master user. (c) De-iconisized state when there is a Master user. (d) If a user is the Master or the conference is in the free-for-all state, then typing CTRL/G (bell), then a bell and this reverse-video message are sent to all users for 1 second before restoring the previous icon message.
The Master icon is used in place of all windows poping up unannounced on the screen. Each remote user may then individually decide whether they want to open this potential "junk mail" and if so - do it at their leisure. The must clicks on this Master window icon to accept the conference. Note however, that all windows are downloaded to all participant displays before the master window comes up. This is so that Xconf has window data ready to be used when the master window icon is de-iconisized. When de-iconisized, it changes to either Figure 9b or Figure 9c depending on whether there is a conference Master. Any user, in the free-for-all state or being the Master user, can type CTRL/G to get the attention of other conference members - even if they are iconisized. It rings the bell and displays Figure 9d for about 1 second for all users. During conferencing you can type, press pushbuttons, or use the mouse to control the conference from any of the conference windows.
Virtual colormap
If a particular user's display required a X-Window virtual colormap, that user will need to move the mouse into any Xconf image, master icon, input, session or pop-up window to see the grayscale images. This is because virtual colormaps are created on that display if there were not enough free colors in their standard colormaps to display grayscale images. That display's window manager is responsible for installing the virtual colormap when the user moves the mouse into any of the Xconf windows. The virtual colormap is used only if it really needed since the user must be in a Xconf window to see the images. This situation might occur for example if the user were running two copies of Xconf to that same display or running other image processing software that used a larger number of colors.
"From listening comes wisdom."
Fortune Cookie.
Session management is deciding who gets to manipulate the screen and
control the conference and in what order. There are two modes of
session control: the "Free-for-all" with no controls and the
"Master" who has solo control.When operating with a Master user, Xconf somewhat restricts information flow since non-Master users' keyboard and mouse global commands do not work. However, their local commands do work. Otherwise, there are few limitations. Initially there is no Master and everyone can interact simultaneously - like in the Tower of Babel, a cocktail party or conference meeting. The Master use can focus the conference's attention and prevent distraction as for example when some users might attempt to scroll the session window or move images.
Master timeout
To prevent one user from hogging the Master when they are not actively participating in the conference, a timeout is available which frees the Master if it is inactive for some period of time. If there is no activity by the current Master user (60 seconds is the default), then it is automatically freed. The next host, if any, in the queue requesting it gets it. This prevents inadvertent monopolization of the conference with resultant discouragement of everyone in the conference - much in line with "lets keep it moving...". The `-TIMEOUT t' Unix switch option enables timeout from inactivity after t seconds.
a) MOVIE MODE OPTIONS:
b) FLICKER MODE OPTIONS:
c) CONFERENCE-ONLY MODE OPTIONS: - NONE
a) LOCAL host commands:
b) GLOBAL conference commands (Master Only):
a) FLICKER
b) MOVIE
c) CONFERENCE-ONLY
Figure 10 Layout of pushbuttons commands is on the periphery of the session window. Global commands are located at the top horizonal row, local commands on the right vertical column. Global commands are available if you are the Master user. Local commands are always available to all users. The interactive-mode pushbuttons (on the bottom horizonal row are used) for flicker, movie or conference-only mode. These are changed when the interactive mode is changed (using the MODE pushbutton). When a button is pressed, it is shown< in reverse video. Toggle buttons, that are on, remain in reverse video until they are toggled off.
The user can rotate between their local HELP, INFO, STATUS, and SUBSESSION pop-up-window objects using the CTRL/B key command or the CYCLE pushbutton. These objects all share the same scrollable pop-up-window by and are switched cycling through them in turn. Using only one pop-up-window minimizes window proliferation and user distraction.
Finding best colors for imported windows
Xconf uses the best color map correspondence it can between the import host's color map for the imported window and the Xconf color maps for each of the other hosts. It does this by a least squares RGB color fit between the Xconf colormap and that of the imported window. In addition, to the 128 gray or pseudo colors of the grayscale image, it also may map to a fixed set of about 26 colors including red through blue as well as 8 levels of gray. Although not ideal, this guarantees that all uses will see the same colors on exported windows.
Because it is really dumping the screen area for the import host's window, any other windows overlaying parts of it will also be captured. To get around this, Xconf raises the import window while acquiring its contents. When finished dumping the data, it then lowers it since Xconf will put an image frame copy on that user's display as well and two raised windows of the same data might be confusing.
Resizing imported windows when re-exporting
In order not to overload the user's screen with a large exported window, it will be shrunk to fit into a 512x512 pixel window if any dimension is greater than 512. On the other hand, if the FULLPPX pushbutton toggle is, active it will cause subsequent exported windows to be replicated with the original size even though they may be larger than 512x512. This exported image frame is then treated like any other image frame in terms of Xconf capabilities in that it can be flickered, marked or put into a movie sequence, etc.
If the same import window is exported repeatedly, new data replaces that in the same export window frames thus avoiding a proliferation of windows.
Opening up a Unix command line shell to a conference poses a security risk both from accidental as well as malicious behavior. Several Xconf options are available to decrease this risk. Access to the conference itself may be restricted, and access to the subshell in particular may be restricted to the moderator.
The '-passwd session-password' Unix switch option can be used to force users on the various hosts to enter a Xconf session password (which they must be told in advance) in order to join the conference. The default is to not require a password.
If the `-moderator host' Unix switch option was specified, then only the Moderator user may talk to the subshell. This is useful in a teacher-student situation where the teacher wants to maintain complete control of the conference and avoid possible corruption of their files by inexperienced members of the conference. If no moderator is specified, and the Master who is using the shell is timed out because of lack of activity, then whomever next grabs the Master will have access to the subshell.
If the image file has a ".rle" file extension, it is assumed to be a Utah Raster Toolkit [URT90] image RLE file and is read as such. If the file is 24-bit RGB color, it is mapped to 8-bit grayscale using the NTSC function gray=0.35red+0.59 green+0.10blue. If the -hexcone Unix switch option was specified with RLE images, it maps each 24-bit RLE color image data pixel to a least-squares-fit 8-bit hexcone color pixel.
If the file has a ".tiff" file extension, it is assumed to be a TIFF file. If the file has a ".gif" file extension, then it is assumed to be a GIF picture file. If the file has a ".pic" file extension, then it is assumed to be a PIC picture file. If the file has a ".hdf" file extension, then it is assumed to be a single HDF picture file. HDF is the NCSA Hierarchical Data Format [NCSA89].
General input file format
For other types of raster files, the `-format headerBytes nRows nCols nBits nImages' Unix switch option may read a 8-bit picture file. The first headerBytes are skipped and nRows X nCols of raster image data are read from the file. If nImages is greater than 1, then it reads tha number of sequential images from the same file.
Multiple images in one file
The -multipleImagesfile nImages option may also be used to specify multiple images/picture file. It then defaults to -format 0 512 512 8 nImages. Alternatively, you can just use -format. This option is especially useful if one encodes a sequence of images (e.g. MRI movie sequence or molecular model at different angles) which may be considered one experiment. One could specify several movie sequences and then pick out frames from both to construct a new movie in order to compare experiments.
Image file data manipulation prior to display
A number of image preprocessing steps may be invoked after reading an image file but prior to displaying this data. The `-zoom nX xZ yZ,' Unix switch option may be used to zoom up a region by 1X to 16X times from the original image data starting at the upper left hand corner (xZ,yZ) of the original data. If -zoom and -sample are used together, the zoom is done first.
The `-sample $n$' Unix switch option may sample images so that the image frame windows displayed are $1/n$'th the size ($n$ going from 1 to 16). Smaller windows are displayed faster when flickering or showing movies since the amount of data a display needs to "bitblt" from the backing store or pixmap to the screen decreases. It is also useful to sample images if the network bandwidth is low or there are many frames in a movie.
The -scale m,b switch permits scaling of the raw picture data $g$ before displaying it using the linear transform $g'=mg+b$.
Images are read as grayscale with grayvalue 0 being white and 255 being black (our convention). The -complement Unix switch option may reverse this. This switch may be used with different types of picture files.
Each image will have its primary file name drawn in the upper left hand corner as a label if the default -labelImage switch was specified.
1 0 0 0
2 204 127 50
3 255 255 255
etc.
where pixels 1 = black, 2 = gold, 3 = white, etc.
The -graphScale Unix switch option interprets the top 10 (out of 256) gray values as red, orange yellow, green, cyan, blue, purple, white, black and is used with GELLAB-II graphScale PPX files [LemP89a].
Mapping 24-bit RGB color to 8-bit black and white
Because Xconf uses 8-bit images, 24-bit RGB color image pixels (such as might be contained in .rle files), need to be mapped to 8-bit pixels. This is done either of two ways. If the -hexcone switch is set, it does a least-squares fit of the of th 128 standard hexcone colors used by Xconf. Otherwise, it uses the NTSC RGB to B&W grayscale mapping: $g=0.35R+0.55G+0.10B$.
Colormap usage in Xconf
Xconf attempts to allocate these 128 gray values or colors as well as 26 special colors in the "standard" X-server's colormap for each display. If this isn't possible for any particular display, a virtual color map is allocated and the first nine colors of the standard colormap are copied to the virtual map so that most X-Window applications and X-Window managers are color-mapped correctly. The idea is to tolerate differences in display visual capabilities given a heterogeneous set of displays (eg. B&W, PseudoColor, GrayScale, DirectColor, etc.). Normally, the virtual colormap is installed by the remote display window manager when the cursor moved into any Xconf windows. Some window managers can't, so Xconf will install the virtual colormap when it can detect this.
Grayscale or color images are presented as dithered images on black and white displays. Dithering can be forced on color displays as well if the -dither Unix switch option was specified. The dithering technique is similar to that used in the Utah Raster Toolkit [URT90]. For images where the reduced resolution is acceptable, this will speed up network transfers since B&W bitmaps use 1/8 the data of 8-bit pixel pixmaps.
Dynamic grayscale intensity and color mapping
The COLOR pushbutton toggles between grayscale and hexcone colors if pressed with the left mouse button. If pressed and moved (i.e. dragged) with the middle or right mouse button, it dynamically changes the contrast (X) and brightness (Y) intensity mapping if in grayscale mode. In hexcone color mode, hue ($h_1$(X) and $h_2$ (Y) in $[0:1.0]$) color mapping is used. The hue mouse function maps the 128 gray levels from $g(h_2-h_1)/128+h_1$. The middle button continuously updates colormaps on all hosts as the mouse is dragged. Because this may not work well for long-haul networks, the right button continuously updates the display for the user draging the mouse, but only updates the rest of the users' display colormaps when the button is released. A (R,G,B) colortriple is computed as a function of (hue,saturation,value).
A more extensive information facility is available using the INFO pushbutton. This (LaTeX) document may be viewed on that user's display using the xdvi(1) program. The option is activated if the -xdviInfo Unix switch option was specified when starting Xconf. Pressing INFO forks a separate xdvi process controlled by the remote user's keyboard - so it is no longer controlled of Xconf. The path for this document, XconfMan.dvi is specified by your environment variable XCONF_DVI and the xdvi with the default switches in environment variable XDVI. Be patient after pressing INFO - it takes a few seconds to start up. The user controls xdvi by typing keystroke commands:
setenv XDVI '/usr/local/tex/xdvi -density 15 -s 3 -margins 10 -mgs1 1200' setenv XCONF_INFO /usr/local/bin/XconfMan.dvi
The mosaic map is treated as a special image frame number 0 that may not be flickered or used in movies. It is viewed by pressing the STDMAP pushbutton twice (pressing it once puts the image frames into their standard positions). If the -NoMapImage Unix option switch was used, then no mosaic map image is available. The default is to generate the map.
Xconf is an example of groupware for small conferences which need to discuss a moderate amount of visual data. It was designed for existing networks and workstations to reach the widest set of users. This was done at the cost of response time because of current limitations on network bandwidth and display resolution. Therefore, it is adequate for many problem domains - but not for very high resolution diagnostic medical imagery.
Xconf requires minimal user display resources: TCP/IP or DECnet network-connected X-Window display systems. Color X displays are best, but it does work with black and white. No other special hardware is required and no special conference-server programs are needed on any hosts which join a conference, so setting up a conference is very easy.
The key to maximizing utility in a conference is to transparently share and manipulate information important to the group. Simple and non-distracting control of the conference must be a primary design goal. For this we made a transferable "Master" user, Master access queue and Master control of global commands to help maintain a single theme in a conference. Alternatively, if conferees may cooperate without central control, then a free-for-all conference mode of operation allows more rapid interactive manipulation of the images. Using a telephone conference call in parallel with Xconf helps provide enough control so that a free-for-all image conference is usable.
Another main conferencing goal is simultaneity so everyone knows what everyone else is doing at all times and responses to ideas and suggestions may be given immediately. This immediacy results in higher rates of idea communication because of minimizing "turn-around" response times during brainstorming.
Specifically, everyone should see any text other users are entering or actions involving images they have taken such as pointing to objects in images. This paradigm replicates needed information on all participants displays presenting a WYSIWIS environment ("What You See Is What I See" first coined by Stefik [SteM87]). Information is divided into that which is global (seen by all users) and local (optionally called up by individual users). Users are aware of who is actively participating and who is inactive (iconisized). Common windows for user conversational input, session output and images allow all users to see this global status of the conference. Individual users may invoke local pushbutton commands to create scrollable pop-up information windows such as the subsession windows to view subsets of conference information. This lets them direct their attention to relevant subgroup activity in the conference.
Some image operations used to analyzing our 2D protein gels were added to Xconf. For example, pointing to objects in images, flickering and making movies of sets of image data frames. We generalized these direct manipulation concepts in Xconf for use with other problem domains. Although Xconf could have been intimately tied into our GELLAB-II system, the choice was made to generalize it so that conferencing could be used with any X-Window application using the subshell and the import-export window interface.
Information may be shared from several sources. Image and text files residing on the Xconf client host system may be read by the conference server. Image or window data from conferees's displays may be added to the conference at any time by exporting selected windows. The conference may also share a Unix shell running on the Xconf client host system. With the latter, it is possible for the Master user to run any application program with the results shared by all users. Because any user may become the Master, different users may take turns running the shared application to try out different data analysis ideas. An important implication is the conference may run database program analyses that resultsin images or windows. These visual results may then be exported into the conference for all to see and comment on.
The use of backing store on the remote X-Window display servers greatly improves performance. Backing store is the key to giving the near real time response required in simultaneous conferences. This is especially important when the available networks and central client system can't support the bandwidth required for updating each user's display every time an image changes. When no backing store is available however, Xconf does handle "Expose" events, but at reduced efficiency. In that case, images are updated by using pixmaps or worst case by re-transmitting windows. Without backing store or pixmaps, flickering and movies may be practically unusable.
Social issues of simultaneous conferencing
Simultaneous conferencing depends on a cooperating group being able to schedule a common block of time when the conference may be held. Because of the impromptu nature of short conferencing sessions, this social scheduling problem may be a major impediment to using this type of tool. This problem becomes more acute as the number of participants grows. Everyone is involved in other activies which are beyond the control of the conference moderator. The difficulty of conference scheduling may be alleviated to some extent by giving the participants the ability to enter a conference after it has started or to leave it before it is over.
For remotely located users, combining a Xconf session with a telephone conference call may help minimize "insecurity" in initially using computer conferencing. Verbal discussion may preceed each Xconf user image interaction to help the flow of the conference. This is especially useful for conferences involving occasional users, for larger groups of people, or conferences with complicated image data.
In summary, Xconf is a tool for sharing image and conversational text data in real time among a geographically distant group of people. It does this by providing the medium for transferring information and coordinating user interactions.
Thanks for constructive feedback on the user interface are due Rob Ashmore, Steve Bailey, Ann Barber, Stewart Durell, Adam Feigin, Jeff Garlough, Peter Greif, Andrew Grimshaw, Voitek Kasprzak, Gerald Latter, Eric Lester, Richard Levenson, Jake Maizel, George McGreggor, Mark Miller, Art Olson, Geof Orr, John Powell, Don Preuss, Pete Rogan, Tom Schneider, Mike Scott, Bruce Shapiro, Randy Smith, John Taylor, Kyle Upton, Jack Waters and others who helped test the early versions of Xconf under a variety of X Servers, window managers and systems. Thanks to Steve Bacharach for a series of MRI heart image data which were used in testing the multiple images/file option for movies, and to Stewart Durell for preparing a multiframe 360 degree movie sequence data of a protein molecular model enabling us to "walk" around the molecule. Many of their suggestions and critiques are reflected in the current design and in this paper.
Xconf [] []
Any switch may be negated by proceeding it with a `no', eg. `-noComplement". Case is ignored in the switch name. You need only type enough of each switch to make it unique compared with the other switches.
Table 5. lists the Unix command line switches. The defaults bring up the conference in a reasonable manner so that generally no switches are required other than to say who is to be in the conference. The default switch values may be overridden by startup switches in the .xconfrc file.
Examples of starting Xconf
The following examples using Unix command line switches with Xconf show many of the ways of starting the conference.
Xconf mcrew.ppx
# Display one PPX picture file on the current host if no
# XCONFHOSTS environment variable is defined.
Xconf a00661.ppx a00981.ppx
# Display two PPX picture files on the displays defined by
# the XCONFHOSTS environment variable .
Xconf
# Display two PPX picture files specified by environment
# variables XCONFONE and XTCONFWO if they exist. Get
# the display names from environment variables
# XCONFHOSTS else use the current display.
Xconf -WindowPlacement
# Same as above but prompt the user where to place the window
# on the screen.
Xconf dnaData.tiff -Displays myHost,yourHost:0.1,theirHost
# Display one TIFF picture file on some other X11 servers
# myHost:0.0, yourHost:0.1, and theirHost:0.0.
Xconf -ConfOnly -Displays myHost,yourHost:0.1,theirHost
# Do non-imaging input/session windows only conference with
# servers myHost:0.0, yourHost:0.1, and theirHost:0.0.
Xconf -ConfOnly -Displays pete@opus,mike@beav,adam@barn -Moderator pete
# Similar to above, but specify name-tags for each host.
# Let 'pete' be the Moderator.
Xconf -ConfOnly -Displays myHost,yourHost:0.1,theirHost
# Do conference session with no images using hosts myHost:0.0,
# yourHost:0.1, and theirHost:0.0.
Xconf -Movie -Displays myHost,yourHost,theirHost f1 f2 f3 f4 f5
# Show a movie of picture files f1.ppx to f5.ppx and display
# on several hosts.
Xconf -Movie -sample 3 -complement f1 f2 f3 f4 f5
# Show a movie of 1/3 sampled and complemented f1.ppx to f5.ppx
# images and display on default hosts. Reverse black<==>white.
Xconf -Movie -sample 3 -complement -Map -Labels f1 f2 f3 f4 f5
# Same as above. This creates a global map image and puts
# file name labels in all images. -Map and -Labels are defaults.
Xconf mcrew.ppx -Contrast P
# Contrast enhance the image by min/max gray value in the
# 'P'icture.
Xconf mcrew.ppx -Contrast
# Defaults to same as above.
Xconf molecule.rle -Contrast H
# Contrast enhance the image by 0.1% min/max gray value in
# 'H'istogram of picture.
Xconf molecule.rle mcrew2.ppx -Hexcone
# Display two images using the hexcone pseudo color model.
Xconf -PASSWD dingdong -Displays myHost,yourHost,theirHost
# Require users to enter Xconf password 'dingdong' before
# continuing.
Xconf -XdviInfo
# Use xdvi on the Xconf.dvi reference document rather than
# scrolling in the INFO sub-session window.
Xconf --FORMAT 0 256 256 5 heart-mri-5-256x256.dat
# Read a set of 5 256x256 pixel images from a multiple images
# file which has no (0 bytes) header.
-switch 1
. . .
-switch K
name1=
. . .
nameN=
@confList1=name1,name2,...,nameN
. . .
@confListQ=name1,name2,...,nameN
A host name-tag lets you define display hosts by their tag names instead of the display specification. For example, if .xconfrc contained an entry `daniel=roundtop.qoh.edu:0.0', then you could specify this host by `-DISPLAY daniel@' and the ` roundtop.qoh.edu:0.0' display specification would be used. This makes starting up a conference easier since you don't have to remember the host name details.
A conference list denoted by `@confList' is a shorthand for specifying a list of hosts using the `-DISPLAYS @confList' Unix switch option format. This would be equivalent to `-DISPLAYS name1,name2,...,nameN'. So the .xconfrc file can hold a database of preassigned conference names making it easier to start a conference. An example of a typical .xconfrc file is given illustrating some of the options.
# File: .xconfrc 1-11-91 # DEFAULT switches: -NoComplementImage -noDitherImages -font 6x13,a14,8x13bold -labelImage -mapImages -noPPXheader -noQuiet -sample 2 -timeout 60 -noWindowplacement -XdviInfo #name tag aliases adam=129.123.111.222:0.0 # sun 4/260 GrayScale bigBob=tweeny.nih.gov:0.0 # sun 3/386C billyBob=hazzard.oldmiss.edu:0.0 # dan=photo.uwsl.edu:0.0 # sun 3/50 eric=xyzzy.uhsmemva.gov:0.0 # jack=net.nih.gov:0.0 # sun 3/80C jim=sgi.nih.gov:0.0 # Iris 4-D littleBob=tiny.nih.gov:0.0 # B&W Vaxstation mark=red.cmu.edu:0.0 # sun 3/60 mike=june.nih.gov:0.0 # sun 3/260 peteL=trek.nih.gov:0.0 # sun 3/260 peteR=giant.hms.ps.edu:0.0 # Mac-II-MacX tomS=info.nih.gov:0.0 # sun 4/260 #Conference groups @bobs=bigBob@,littleBob@,billyBob@ @nih=bigBob@,littleBob@,jack@,jim@,mike@ @dna=peteL@,peteR@,toms@ @leukemiaConf=peteL@,eric@,mike@
/* **************************************************************** */
/* ppxfmt.h - portable picture format header specification */
/* D R A F T */
/* **************************************************************** */
/*
* Original VAX/FORTRAN design by (VRSION=3.3, 24-AUG-1987 16:28:19.22)
* John Taylor
* Argonne National Labs, Bld 202
* Argonne, Ill. 60439
*
* Converted to C struct by:
* P. Lemkin
* National Cancer Institute/FCRF, Bld 469
* Frederick Md. 21701
* Net Address: lemkin@ncifcrf.gov
*
* Revision Date: March 10, 1988 - PFL
*
* The image file header is a single block of 512 bytes [in Sparc
* big-endian byte-order], which is followed by blocks of image data.
*/
/* ============================================================== */
/* I M */
/* ============================================================== */
/* user setable parameters if the header changes */
#define PPX_VRSION 35 /* Code version 3.5 as 35 */
#define WEDGE_PPX 24 /* Max number of wedge steps if applicable*/
typedef struct ppxB24 {unsigned var : 24;} ppxB24_t; /* to make bit arrays */
typedef struct ppxB16 {unsigned var : 16;} ppxB16_t;
typedef union ppx_Node_ {
struct ppx_sHdr_ {
unsigned fversn : 16; /* Set to PPX_VRSION by program
* creating header */
unsigned filtyp : 8; /* type of file.
* = 0 for unknown.
* = 1 for raw image.
* = 2 for processed image.
* = 3 for synthetic image.
* = 4 for spot file.
* = 5 for exception list file.
* = ... 6 to 255 are free.
*/
unsigned nrows : 16; /* full image size in pixels */
unsigned ncols : 16;
char name[32]; /* name of the picture - was [16] */
char sid[12]; /* further identification -
* (sample ID) */
char vism[12]; /* visualization method */
char sdate[8]; /* date of scan */
char stime[8]; /* time of scan */
char initl[4]; /* initials of person doing scan */
char scsys[20]; /* ID of the scanning system */
char scprog[12]; /* name of scanning program */
char scpvrs[4]; /* version of scanning program */
unsigned nbands : 8; /* # of scanning bands (colors) */
unsigned bitpp : 8; /* bits per pixel (one band) */
unsigned bytpp : 8; /* bytes per pixel (one band) */
unsigned x0 : 16; /* Top Left Corner of image in cm*1024 */
unsigned y0 : 16; /* Top Left Corner of image in cm*1024 */
unsigned isptsz : 16; /* scanning spot diameter in microns*1024 */
unsigned istpx : 16; /* step sizes in microns*1024 */
unsigned istpy : 16; /* step sizes in microns*1024 */
unsigned tessl : 32; /* tesselation code bits */
unsigned domain : 8; /* 0 = optical density,
* 1 = transmittance
* 2 = gray value
* ... 3 to 255 are free. */
unsigned rix : 16; /* top left corner of region of interest
* (0,0) is U.L.H.C. */
unsigned riy : 16;
unsigned nx : 16; /* size of region of interest */
unsigned ny : 16; /* size of region of interest */
unsigned blkaln : 8; /* block alignment flag (0 = aligned) */
unsigned trnsl : 8; /* translation flag: 0 = raw, 1 = done */
unsigned nexcpt : 32; /* number of exception entries */
unsigned odmn : 16; /* Min Pixel gray (or OD*1000) value */
unsigned odmx : 16; /* Max Pixel gray (or OD*1000) value */
/* ------------ NOTE: 11-12-87 PFL new fields -------------------------- */
unsigned blackIsZeroFlag : 8; /* 1 if BLACK is gray value 0, else
* 0 if WHITE is gray value 0 */
unsigned wedgeType: 8; /* Type of step wedge if any in the image:
* 0 = none
* 1 = ND, neutral density
* 2 = CPM, counts per minute
* 3 = DPM, disintegrations per minute
* 4 to 255 = free */
unsigned nWedgeSteps : 8; /* will contain WEDGE_PPX to be set by user*/
ppxB24_t wedgeVal[WEDGE_PPX]; /* ND*1024 or CPM wedge step values*/
ppxB16_t grayCalWedge[WEDGE_PPX]; /* gray scale peaks calibration for
* corresponding stepwedge values*/
unsigned cMapFlag : 8; /* color map flag:
* 0 = no color map
* 1 = color map is the first 1024
* bytes of data after header
* where 3x256 bytes are Red,
* Green,Blue maps stored as
* sequential arrays.
* 2 = same as 1 but image data is
* true-color image consisting of
* three sequential images (R,G,B).
* 3 = same as 2 but pixels are 24-bits
* specifying 8-bits each of (R,G,B).
* 4 = color map is first 12,298 bytes
* of data after the header where
* 3x4096 (12-bit lookup table entries)
* are stored as sequential arrays.*/
unsigned imOrientation : 8; /* Image orientation bits
* where: Default 00==>011:
* 01 = left to right
* 02 = bottom to top
* 04 = right to left
* 010= top to bottom */
unsigned imEncode : 8; /* Image encoding method:
* 0 = none (just raw raster data)
* 1 = UNIX 'compress/uncompress'
* 2 = run length
* 3 = 1D modified Huffman
* 4 = 2D modified Huffman
* 5 = delta coding
* 6 = run length with delta coding
* ... 7 to 255 are free. */
unsigned startDataDict : 32; /* if non-zero, then byte # of file
* where data dictionary starts. This
* should be multiple of 512 bytes. */
unsigned endDataDict : 32; /* if non-zero, then byte # of file
* where data dictionary ends. This
* should be multiple of 512 bytes -1. */
unsigned startImageData : 32; /* if non-zero, then byte # of file
* where image data starts. This
* should be multiple of 512 bytes.*/
/* NOTE: The last bytes of this header block are used for
* certain scanner specific parameters. See the appropriate
* scanner include files for details.
* NOTE: @8-31-87: The next free byte(s) is im[294]
*/
unsigned char free[1]; /* next free byte */
} sHdr;
unsigned char im[512]; /* fill out block to 512 bytes */
} ppxHdr_t;