Bitmap and Vector Graphic Output

The IDLgrClipboard and IDLgrPrinter destination objects allow objects in a scene, viewgroup, or view to be output as vector or bitmap graphics. Which output is suitable depends upon the contents of the scene being sent to the output destination object. Understanding the difference between bitmap and vector graphics will help clarify why there is a difference in how the final output is displayed, and how the output can be edited.

Bitmap Graphics

Bitmaps are a collection of bits that describe the individual pixels within an image. Each pixel is a specific color, and the matrix of these pixels compose the image. In bitmap graphics, the contents of a view, viewgroup. or scene are captured as an image and are drawn with pixels in the bitmap. They can be edited only by altering individual pixels. The following figure shows the individual pixels that are visible when a small segment of an image is greatly enlarged.

IDLgrClipboard bitmap graphic output can be edited by any pixel-based paint program. In IDL, bitmap graphics can be stored as Bitmap (BMP) or PostScript (EPS) files under Windows, and as PostScript files under UNIX. Characteristically, bitmaps are large files, and image quality degrades when the image is substantially enlarged or reduced.

Vector Graphics

Vector graphics are described by simple graphic primitives. In the following figure, the vector output of the plot, shown on the left, is composed of multiple individual line segments that are defined mathematically. The IDLgrText objects are rendered as text primitives. All these primitives can be edited in vector graphic files. For example, in the following figure the final line segments in the plot have been repositioned in the right-hand image.

IDLgrClipboard vector graphic output can be edited by an object-based graphical editor. In IDL, vector graphics can be stored as Enhanced MetaFile (EMF) or Encapsulated PostScript (EPS) files under Windows, and as Encapsulated PostScript (EPS) files under UNIX.

The main advantages of vector graphics are excellent scalability, and the ability to easily edit text and graphic features of the objects in the display. The graphic quality is maintained regardless of whether the graphic size is increased or decreased. The capabilities of the graphic editor determines what can be successfully edited. Simple lines and horizontal text can be easily edited in an EMF file inserted into a Microsoft Word document. However, more sophisticated graphic editors provide support for editing intricate graphic features and non-horizontal text. See Text Rendering in Vector Graphics for more information. Vector graphics file sizes are generally smaller compared to bitmap graphics.

Guidelines for Choosing Bitmap or Vector Graphics

Advanced 3-D graphics rendering system output does not always map perfectly to a 2-D vector graphics system. The vector output is an approximation of what is displayed on the screen. How closely the vector output matches what is displayed depends upon the scene contents. Vector output may differ dramatically from bitmap output, and may also differ between the vector file formats (Encapsulated PostScript, Xprinter, and Enhanced MetaFile).

In general, scenes containing multiple, intersecting surfaces with various shading, transparency and lighting definitions are displayed with greater accuracy in a bitmap format than a vector format. However, simple 2-D plots are perfectly suited to vector output. Views containing the following items should not be output to vector graphic files:

Controlling What is Displayed in Vector Graphics

Several factors beyond the differences between bitmap and vector graphics (described in the previous section) affect a vector graphics file in terms of content and the ability to edit text. Keywords provide control over factors such as object sorting, polygon shading, and text rendering when using the Draw method of the IDLgrClipboard or IDLgrPrinter destination objects. See the following sections for more information:

Smooth Shading in Vector Graphics

The IDLgrClipboard Draw method supports the VECT_SHADING keyword, which affects the appearance of the surfaces and polygons when the VECTOR and POSTSCRIPT keywords have also been set. When SHADING=1 (Gouraud shading) for IDLgrSurface or IDLgrPolygon, use this keyword to control the rendering quality. Set the VECT_SHADING keyword to one of the following:

Text Rendering in Vector Graphics

Text can be easily edited in vector graphic files when the text is output as text primitives. In bitmap files, text glyphs cannot be edited except by modifying individual pixels. In a vector graphic file, IDLgrText objects are rendered as graphic primitives that can be edited. The IDLgrClipboard or IDLgrPrinter VECT_TEXT_RENDER_METHOD keyword controls whether text appears as filled triangles or text primitives when the VECTOR keyword is also set. Set the VECT_TEXT_RENDER_METHOD keyword to one of the following:

Setting VECT_TEXT_RENDER_METHOD=0 creates a vector graphics file with text rendered as primitives. The text associated with the graphic can be scaled, transformed or repositioned when edited in an object-oriented graphics application.

An Enhanced MetaFile (EMF) inserted into a Microsoft Word document can be edited. However, not all versions of Microsoft Word support advanced 3-D graphic primitives such as those associated with obliquely or vertically aligned text. Choosing to edit a file with non-horizontally aligned text may result in the text being flattened into two dimensions. Typically, each letter becomes its own string and alignment is altered. To edit non-horizontal text and preserve the original quality, create an Encapsulated PostScript (EPS) file that can be modified in a more sophisticated object-oriented image editing program.

Setting VECT_TEXT_RENDER_METHOD=1 creates text that is rendered as filled triangles. Elements of the plot in the following figure are composed of line segments that can be edited, but the text characters cannot be individually edited. The triangles composing the letters of the text object are visible in the right-hand image.

Primitive Object Sorting in Vector Graphics

The IDLgrPrinter and IDLgrClipboard Draw methods support the VECT_SORTING keyword, which affects the appearance of the output when the VECTOR keyword has also been set. Use this keyword to simulate the depth buffer in Object Graphics in the output vector graphics file. Set the VECT_SORTING keyword to one of the following:

The following figure shows the results of changing the VECT_SORTING keyword. When sorting is disabled (VECT_SORTING=0) as in the left image, the first object added to the model is drawn first in the display and in the destination device. In the code used to create the left image, the text is added to the model before the surface. Therefore it appears behind the surface in the vector graphics file. When the order is reversed, the text is drawn on top of the surface. When sorting is enabled (VECT_SORTING=1) as in the right image, primitive objects are sorted according to their depth in the view. Most distant objects are drawn first. When two objects have the same average depth, the object added to the model first is drawn first and will appear behind subsequent objects.

Note
Vector output does not support depth test functions. Vector output resolves Z (depth) ties by using the DEPTH_TEST_FUNCTION default LESS depth test.

There are two instances in which the above sorting model is not applicable:

See the following sections for details.

Sorting Issues with Transparent Views

When a window contains multiple views, the objects in each view are sorted as a separate group. This simulates the default clear operation that IDL performs when drawing each view to a destination, clearing the depth buffer and repainting the view with the view color. Depending upon the ordering and transparency of the views, the vector output might not match what is displayed, regardless of the value of VECT_SORTING. Consider objects in a transparent view that are positioned behind an object in a non-transparent view. In the display, objects in the transparent view are occluded by the object that appears closer to the viewer. However, in the vector output, the objects in the transparent view interact with and are visible in the output. This occurs because IDL does not clear the depth buffer or repaint the view when it is transparent.

In the simple example shown in the following figure, the IDLgrText object is added to a transparent view and is positioned behind the surface. The view associated with the IDLgrSurface is not transparent. The view containing the surface and the transparent view containing the text are added to an IDLgrViewgroup and displayed in the window. The left image shows the vector file output, and the right image shows the bitmap file output. In the vector output, all of the text is visible because the views are sorted independently. This behavior occurs because the transparent view containing the text is added to the viewgroup after the view containing the surface. If the view containing the text is added first, then only the surface (whose view is not transparent) is drawn.

Transparent Images

When IDL draws a semi-transparent image with vector output, it must draw it completely opaque, as it does with other primitives. Therefore, if you use image layers, where one image is semi-transparent in order to let you see another image drawn before it, the output will not be correct with vector output since the semi-transparent image will be drawn opaquely, completely hiding the image drawn before it. You should use bitmap output to get the desired results because semi-transparent rendering is not available with vector output.

Note
As described in Guidelines for Choosing Bitmap or Vector Graphics, all transparent objects (not just image objects) are rendered opaque in vector output.

Sorting Issues Among Image and Non-Image Objects

On a display device, IDLgrImage objects are drawn as "pixel primitives," which means that they do not update the depth buffer when they are written to the screen and also are not tested against the depth buffer to determine if they should be drawn or not by default. In such a case, images are rendered at Z=0 in viewing coordinates. This means:

Note
This is true unless you specifically enable depth testing (see "DEPTH_TEST_DISABLE" (IDL Reference Guide) for details). When depth testing is enabled, images behave just like any other 3-D object that supports depth buffer controls.

For these reasons, IDL applications often place image objects in the graphics tree so that they render first, unless the application wishes to make use of the behaviors described in the above two points. IDL emulates this behavior with vector graphics when VECT_SORTING is on as follows:

These steps assure consistency between bitmap and vector output for overlapping image and non-image primitives. However, some sorting differences may occur between non-image primitives that overlap each other but do not overlap images. For example, consider two non-image primitives drawn on the screen so that they do not overlap an image, and one of these primitives is positioned in the graphics tree before (drawn before) the image, and the other is positioned in the graphics tree after (drawn after) the image. These two primitives are not sorted with respect to each other and are always drawn so that the second primitive is drawn after the first, regardless of their relative depth in the scene. If these primitives overlap, the result may not be correct if the first primitive is closer to the viewer than the second. Again, in this case, consider using bitmap output for more accurate output.