Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Fundamentals

Displaydatas

The main task of the Viewer tool is to produce visual representations of AIPS++ data. Presently, the data itself may be an AIPS++ Image stored on disk, or a Glish array, while the visual representation can be a false color image (hereafter a "raster"), or a contour map (hereafter a "contour"). One of the two fundamental tools that the Viewer tool is built upon is the Viewerdisplaydata tool. This tool combines a data source and a representation method into a single unit which can be passed around the various tools which are managed by a single Viewer tool.

A Viewerdisplaydata tool is completely self-contained, and has "state". Its state consists of various attributes, some of which will not change during the lifetime of the Viewerdisplaydata tool, and many others which probably will. Examples of unchangeable state include the dimensionality of the Image or Glish array, and the type of visual representation requested: a raster or a contour. Examples of changeable state include the many attributes which describe how the data should be translated into the requested represetation, such as the "colormap" (see below) to use for a raster, or the contour levels to use for a contour Viewerdisplaydata tool. The changeable state of a Viewerdisplaydata tool can be modified from the command-line or in a graphical user interface. Many Viewerdisplaydata tools can be created and managed by a single Viewer tool.

Displaypanels

The Viewerdisplaypanel tool provides one ore more "canvas(es)" on which one or more Viewerdisplaydata tools can draw themselves, and is the second fundamental tool upon which the Viewer tool is built. This tool provides facilities for Viewerdisplaydata tools to register and unregister themselves, that is, to join and leave the list of Viewerdisplaydata tools that will get asked to draw themselves whenever the canvas is redrawn. Furthermore, it provides a "controlbox" of operations which can be applied to the canvas, for example, zooming (magnifying) the display. Finally, each Viewerdisplaypanel tool has two "managers" associated with it: a Viewercanvasmanager tool which provides the facility to modify some of the canvas-specific settings (for example, background color, margin widths, and the number of panels), and a Viewercanvasprintmanager tool which can be used to generate PostScript and X11 Pixmap output from the contents of the Viewerdisplaypanel tool. Many Viewerdisplaypanel tools can be created and managed by a single Viewer tool.

Options

One of the most important concepts of the Viewer tool is the way states and attributes are set. tools like Viewerdisplaydata tool and Viewerdisplaypanel tool have functions getoptions and setoptions to control these ``options''. For example, the state of a Viewerdisplaydata tool is held in an option record. The documentation of each tool summarizes it's options which can be controlled by the user.

Let's say you have made a Viewerdisplaydata tool as a raster and you want to know the options on this displaydata, you would to something like this:

dd := dv.loaddata('myfantasticimage','raster');
opts := dd.getoptions();
print field_names(opts);

These options are usually context dependent, i.e. an option record for a ``raster'' Viewerdisplaydata tool is different from a ``contour'' Viewerdisplaydata tool option record.

Colormaps

The display of rasters requires that the pixel values in a data source be mapped to colors selected from a pre-defined set of colors, or a "colormap." The Viewer tool provides colormaps via the Viewercolormapmanager tool, and there is one and only one Viewercolormapmanager tool per Viewer tool. Sixteen unique colormaps are available. Whilst generation of new colormaps by the user or Glish programmer is not available yet, the existing colormaps can be modified in several ways by directly using the Viewercolormapmanager tool, or its graphical user interface. The usual "slope-shift" colormap fiddling is provided, together with "contrast-brightness" fiddling. Both of these are also available from the controlbox of Viewerdisplaypanel tools. Further capabilities (available via only the Viewercolormapmanager tool) include the independent inversion of the red, green and blue components of the colors in the colormap.

Viewer tool colormaps are entities which can be used by on many Viewerdisplaypanel tools concurrently, and which share color resources when possible. They automatically resize themselves to use as many colors as they can, based both on the number of colors that the various Viewerdisplaypanel tools are set up to use, and on the number (and weightings) of other Viewer tool colormaps that are in use. For this reason, when multiple Viewerdisplaypanel tools are in use, registering or unregistering a raster-type Viewerdisplaydata tool on one Viewerdisplaypanel tool may well cause other Viewerdisplaypanel tools to refresh, as more or less colors become available for other colormaps in use. The programmer can reduce the resulting ``flickering'' by ``holding'' and ``releasing'' the Viewer tools that are in use. The user can control the number of colors that the various Viewerdisplaypanel tools are setup to use, and can modify the Viewer tool colormaps themselves, by fiddling and inverting components.

Advanced note: The Viewer tool inserts a software layer above the hardware colormap of the screen in use. This is so that the user can choose to have as many colors as possible for the Viewerdisplaypanel tools, knowing they will get color flashing, or instead to use the system colormap, which invariably will limit the number of colors that are used by the Viewer tool, but will prevent color flashing. Indeed, for a single Viewer tool, multiple Viewerdisplaypanel tools can be used: some of these may use "private" colormaps, and others may use the system colormap.

Once a Viewerdisplaypanel tool is on the screen, you cannot change whether it is using the system colormap or a private colormap. You can, however, change the number of colors it is actually making use of in its colormap. This can be useful in two ways: firstly, sometimes rasters look better if you use fewer colors and sometimes look better with more colors: so with this feature, you can dynamically reduce or increase the "smoothness" (in colorspace) of raster images. Secondly, let's say we made a Viewerdisplaypanel tool and asked it to use the system colormap: that is, we were happy to have fewer colors so that we could avoid color flashing. Sometime later, we start up a (non-AIPS++) image viewing program on the same screen, and because the system colormap is nearly over-subscribed, partly by the Viewerdisplaypanel tool, this external program decides to use a private colormap. This might not be satisfactory, so you can actually close that program, reduce the number of colors being used by your Viewerdisplaypanel tool (via a graphical user interface perhaps), and then re-start the external program. You did not have to close the Viewerdisplaypanel tool to accomplish this!

While a single Viewer tool can have many Viewerdisplaypanel tools operating, it only ever has one Viewercolormapmanager tool, whose colormaps are shared by all the Viewerdisplaypanel tools. Viewerdisplaypanel tools which are using the system X colormap (ie. that aren't causing color flashing) actually all share one contiguous section of the system X colormap. Whatever Viewer tool colormaps are needed are placed in this block of color cells, usually uniformly distributed. For example, suppose I have two Viewerdisplaypanel tools on screen, both using the same 80 cells of the system X colormap. If they both have raster Viewerdisplaydata tools registered for display, each of which has its own (different) Viewer tool colormap (say one is using "Rainbow 4" and the other "Hot Metal 2"), then each of the Viewer tool colormaps will get 40 cells each. The "Rainbow 4" colormap can be fiddled and inverted to your hearts content without ever affecting the raster drawn with the "Hot Metal 2" colormap. If I close one of the Viewerdisplaypanel tools, the other one will notice this, and stretch the colormap it is using back out to fill the 80 cells. Conversely, if I open another Viewerdisplaypanel tool using the system X colormap, and display yet another raster using yet another Viewer tool colormap, the three required colormaps will be packed into the 80 cells (having lengths 27, 27 and 26).

Let's say, however, that with the two system X colormap Viewerdisplaypanel tools still open, I make a third Viewerdisplaypanel tool, but ask that it use a private colormap. I'm going to get color flashing, but I'm also going to get way more than 80 colors: I'll probably get around 250 on an 8-bit system, and around 1000 on a 10-bit system. If I go and register a third raster Viewerdisplaydata tool in this Viewerdisplaypanel tool, and ask it to use a different Viewer tool colormap, eg. "Greyscale 1", then the two existing Viewerdisplaypanel tools are not affected, and the "Greyscale 1" colormap will fill the 250 (or more) colors available in the third Viewerdisplaypanel tool. But this "Greyscale 1" colormap can be mapped into more than one X colormap! So if I choose this colormap to be used for one of the first two Viewerdisplaydata tools, then it will replace, say, "Rainbow 4", in the 80 cells of the system X colormap we are using, but it will remain occupying 250 cells in the private colormap Viewerdisplaypanel tool. Yet they are the same Viewer tool colormap, so modifying the "Greyscale 1" colormap in any way, either via the Viewercolormapmanager tool, its graphical user interface, or a Viewerdisplaypanel tool controlbox, will cause equivalent changes in the display of both rasters that are being drawn with "Greyscale 1".