Suggestions for better pictures

Topics covered:
Shadowing: The primary purpose of shadowing is to convey a feeling of depth in the rendered image. This can be particularly effective when there are a relatively small number of elements in the scene, or when there is a grouping of foreground objects which cast shadows onto a separate grouping of background objects. However if there are a large number of elements in the scene, e.g. a ribbon and arrow representation of a large molecular assembly, the use of shadows may actually complicate the visual impact and make the image less satisfactory. In this case you may wish to try rendering the image both with and without shadows, or you might experiment with the location of the primary light source (the SOURCE parameter in the 12th header record input to render). Finally, you can de-emphasize the shadows by increasing the secondary (straight-on) light source contribution parameter.

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:

# # Use molscript to generate a Raster3D input file # molscript -r < image.mol > image.r3d # # Render image once to check that it's what we want # render -tiff mono.tiff < image.r3d # # Render it again, this time as a stereo pair # Note: the output file is always called stereo.tiff # stereo3d image.r3d display stereo.tiff Creating your own colour descriptions: The Raster3D distribution contains a number of pre-defined colouring schemes (e.g. the shapely.colours file, cpk.colours, and mycolors.pdb). If you choose to modify these, or create your own, then you should be aware that render works internally with the square root of the specified colour values (yes it's a very strange concept!). To convert a normal RGB colour triple into a Raster3D color specification it is therefore necessary to square each component. For example, to specify a half-intensity yellow you would square the components of the pure RGB triplet (0.5, 0.5, 0.0) to yield (0.25, 0.25, 0.0) in the COLOUR record input to render. The Raster3D output option to Molscript performs this conversion automatically, so you should not have to alter the colour specifications to switch between PostScript and Raster3D modes.

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

O> write_form .gs_real omatrix.dat Heap> Format: <cr> followed by a shell command o2mol < omatrix.dat > o2mol.out The file o2mol.out will now contain instructions for reproducing the O viewpoint in Molscript. Also, the 3x3 matrix which o2mol gives as ``for coordinate transforms'' is in the correct form to use directly as a Raster3D matrix if you aren't processing with Molscript first.

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.

TMAT (4x4 matrix) in Raster3D header
Transpose of 3x3 Molscript matrix
a11 a12 a13 0.
a21 a22 a23 0.
a31 a32 a33 0.
Translation components Scale
T1 T2 T3 S
NB: The value of S (scaling) comes from the "window" parameter in Molscript. The column values above it are always zero.


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:

  1. Calculate the required number of pixels in your Raster3D image. For example, if you want to end up with a figure that is 4" by 3" when printed on a 300 dpi (dots-per-inch) PostScript printer, then your raster image must be 1200x900 pixels. Edit the values of NTX,NTY,NPX,NPY and ISCHEME in the header records accordingly and run your image description through the Raster3D render program. This will be easiest if you set ISCHEME to 1 or 4. In that case you need to choose values such that NTX*NPX=1200 and NTY*NPY=900 (for our hypothetical 4"by3" figure).
  2. Confirm that the rendered image is the correct size; 1200x900 in this case. The ImageMagick utility identify will do this for you.
  3. Convert the rendered image to a PostScript file using the ImageMagick convert utility. You must explicitly specify Here is a suitable command for this example: convert -density 300 -geometry 1200x900 -page 1200x900 image.tiff image.ps
  4. Send the converted image to your PostScript printer. If it does not come out the size you expected, then probably the printer has a different resolution than you thought. You will have to go back to the beginning and try again.

Back to top Raster3D homepage
Ethan A Merritt / merritt@u.washington.edu / Biomolecular Structure Center at UW