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,
or by the -size command line option to render.
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 each rendered picture
before sending it for printing.
Making your pictures modular
So long as you stick to a consistent coordinate system, you can build up
a complex Raster3D scene from bits and pieces created by various
different tools and programs. For example, you could create a scene that
is defined by a viewpoint selected interactively in Xfit, and that
contains a protein molecule drawn by Molscript, a molecular surface
drawn by GRASP, and a "floor" or bounding box from the Raster3D library
of pre-described objects. This scene can conveniently be described to
the render program by using file indirection in the input stream, which
might look something like this:
# # Header records written from inside Xfit @viewpoint.r3d # # Molscript V2.0 output file @secondary-structure.r3d # # Make the molecular surface (from GRASP via ungrasp) # transparent by using a material definition # from the Raster3D library $R3D_LIB @transparent.r3d @surface.r3d @end_material.r3d # # Add a few extra goodies @red.r3d @floor.r3dThis makes it very easy to experiment with your composition without having to edit huge input files. You could, for example, change the color of the floor by substituting the library file blue.r3d for the file red.r3d. Or you could render the same scene from a different viewpoint by changing the view matrix in viewpoint.r3d. Even better, you could select from a number of pre-defined views described by header records in files view1.r3d, view2.r3d, view2.r3d, and so on just by making viewpoint.r3d be a symbolic link to the particular view you want to render. That way you needn't edit any input files at all to shift the scene. This approach is particularly useful for producing animation.
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.
EYEPOS = 4 means that the
distance from the camera to the center of the object is four times the width of
the field of view.
Generally the sense of depth conveyed by the rendered image is
slightly increased by positioning the virtual camera reasonably close to the
object.
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, then 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
All Raster3D objects emitted by a Molscript run are
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 the stereo3d
script to produce a 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
Duncan McRee's XtalView program ( http://www.scripps.edu/pub/dem-web/index.html) can create Raster3D input files or images directly from the current screen view, including atoms, bonds, view objects, electron density, etc. Many Raster3D rendering options can be varied using control widgets in the Xfit pop-up plotting menus. Xfit can also be used simply to create a set of Raster3D header records describing the current view.
Another interactive tool you might be interested in is the VMD program from the Theoretical Biophysics group at the University of Illinois. 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.
Coordinate systems: 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?
This used to be a pain to do. Now there is an easy answer: get Molscript version 2.
The old, laborious, procedure may still be informative as an example of
mixing PostScript and Raster3D, however. 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: