Tailoring your image to the output device: The quality of pictures generated by Raster3D is ultimately limited by the output device. Although you will probably compose and preview your figures on a workstation screen, you will probably want to re-render the final version with a larger number of pixels before sending it to a film recorder or high performance color printer. For example, a typical film recorder can produce slides with a resolution of roughly 4000x3000 pixels (much larger than can be displayed on a workstation screen). The number of pixels in your rendered image is controlled by the parameters (NTX,NTY) and (NPX,NPY) in the 2nd and 3rd header records input to the render program. If you need to convert your image to PostScript so that you can send it to a PostScript printer (the only time you should ever convert to PostScript!) then read the section on PostScript conversion below. You should also be aware that color balance and particularly the appropriate ``gamma correction'' varies from one device to another. Raster3D itself applies no gamma correction; if you need one you will have to apply it to the generated image files afterwards. This is a standard image processing procedure, and may be a selectable print option for your output device. If you will be using a particular output device regularly, it is worth an initial round of experimentation to determine the best gamma value for future runs. The appropriate gamma correction can then be applied to the each rendered picture before sending it for printing.
Side-by-side figures and stereo pairs: The EYEPOS parameter input to the render program specifies a viewing distance for the resulting image. You may think of this as equivalent to the distance between a camera and the object being photographed. Generally the sense of depth conveyed by the rendered image is slightly increased by positioning the virtual camera reasonably close to the object; the default recommended value for EYEPOS is 4, which means that distance from the camera to the center of the object is four times the width of the field of view. However, if you are composing a figure containing two or more similar objects which are next to each other, e.g. a comparison of two variants of the same protein structure, the resulting parallax may be more of a hindrance than a help. Since the virtual camera is centered it will ``see'' the right hand object slightly from the left, and the left hand object slightly from the right. This results in different effective viewpoints for paired objects which would otherwise be identical. To overcome this effect you may wish to set EYEPOS to 0.0, which disables all perspective and parallax. The same considerations apply for the production of stereo pairs.
Stereo pairs and Molscript: Unfortunately Molscript does not pass any information about area, page layout, or even aspect ratio, on to the Raster3D input file. This means that all objects emitted by a Molscript run are simply placed into a single scene description. That is, the pairs of ``plot'' and ``end plot'' statements in a Molscript input file have no effect in Raster3D mode. Therefore a Molscript file which describes a stereo pair as two separate plots will not work correctly when fed through to render. You should instead use Molscript to produce a single [mono] scene description for Raster3D, and run it through render twice to produce the two images making up a stereo pair. New in Version 2.3: There is now a shell script in the Raster3D distribution called stereo3d that will do this for you automatically. It will take any input file for render and use it to create a side-by-side stereo pair. Here is an example:
Composing figures in other programs: Suppose you are already working in some interactive graphics program, FRODO for instance, and wish to reproduce the current viewpoint/orientation for a Raster3D picture. If the program will dump the current view matrix then you will probably be able to use it as a view matrix for Raster3D also. However many programs (including FRODO and Molscript) dump a matrix which is the transpose of the matrix used by Raster3D.
Users of Alwyn Jones' program O should obtain a copy of the program o2mol from the O ftp site. Once you have composed your view in O you can convert to a Molscript/Raster3D viewpoint description by dumping the O datablock named .GS_REAL
Another interactive tool you might be interested in is the VMD program from the Theoretical Biophysics group at the University of Illinois. This is a new package for the graphical display and visualization of biomolecular systems, available to the structural biology research community free of charge. VMD provides a wide variety of methods for interactively rendering and coloring a molecule, and can generate a Raster3D input file which will very nearly duplicate the view composed on your workstation screen. A more complete description of VMD is available via the VMD WWW home page. The software itself is available via anonymous ftp from ftp://ftp.ks.uiuc.edu/pub/mdscope/vmd.
Building up a figure from Molscript and other files: When Molscript runs it normalizes the coordinates of objects in the figure so that they are described by an identity transformation matrix. The 3x3 matrix printed out by Molscript to the terminal is the transpose of that needed by Raster3D programs. Swap the entries about the diagonal from upper left to lower right before copying it into the TMAT header records for render or normal3d.
To normalize other Raster3D input files describing objects still in the original PDB coordinate space (so that they can be merged with your Molscript output), replace the four TMAT records in the header with a new matrix built as below and then feed the resulting file through normal3d.
Transpose of 3x3 Molscript matrix | |||
---|---|---|---|
a11 | a12 | a13 | 0. |
a21 | a22 | a23 | 0. |
a31 | a32 | a33 | 0. |
Translation components | Scale | ||
T1 | T2 | T3 | S |
How can I keep the Molscript labels in my Raster3D picture?
Yes, it is possible to keep the labels from a Molscript picture when
you convert it to Raster3D. I don't recommend this procedure, but here is a
summary of how to do it if you really want to.
Black & White figures: It is possible to use a general image processing program (e.g. ImageMagick) to convert a color figure to a monochrome figure. In general a straight conversion will produce an image which is much too dark. In order to improve the result you can try breaking the conversion up into several steps: first convert from full 24-bit color to a smaller number of colors (say 256), next apply a substantial gamma correction (e.g. gamma 2.0) to lighten the image, and finally convert the color image to monochrome being sure to select a dithering option if it is available. Some experimentation with this process can produce acceptable, although not ideal, monochrome images suitable for printing on a standard laser printer. You may have to repeat the color reduction and gamma correction steps before finally converting to monochrome. Better results can be obtained by using the auxiliary program avs2ps as a filter. This utility will convert any AVS-format image, including the default output stream from render, directly into a dithered black & white PostScript image. As of this writing the avs2ps program is included with the Raster3D distribution.
Conversion to PostScript: Do not convert your raster image to PostScript unless you really, really have to. This should only happen if you want to send the image to a printer that understands nothing but PostScript. The raster image consists of a certain number of pixels on X and on Y, and the size of each dot depends entirely on the physical resolution of the device the image is displayed on. To produce a Raster3D figure of a given size on a PostScript printer, you must know the physical resolution of the printer. A true PostScript figure would be scalable and device-independent; this will not be true for a raster image forced into a PostScript file. Here are the required steps: