Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1367
News FAQ
Search Home


next up previous
Up: AIPS++ Note 172: Infrastructure Graphics Previous: Being Prepared for New Developments in Computer Graphics

Subsections


Example: an Image Display Component

This component - a work in progress - is primarily intended for the interactive display of AIPS++ Image class objects5. It may be called from the glish command line, from any process on the glish bus, or from a C++ program.

The C++ constructor for this component is many times overloaded, reflecting these different contexts in which it will be used:

  // for use in a non-X program
  ImageDisplay (const Image<T>& image);
  ImageDisplay (const String& imageFilename);
  ImageDisplay (const String& FITSfilename);
  ImageDisplay (const Array<T> array);

  // for use in a possibly complex X program
  ImageDisplay (const Image<T>& image, Widget parent);
  ImageDisplay (const String& imageFilename, Widget parent);
  ImageDisplay (const String& FITSfilename, Widget parent);
  ImageDisplay (const Array<T> array, Widget parent);

  // for use in an AIPS++ WindowManagingApp program
  // (WindowManagingApp is a class which provides a central, 
  // scrolling menu of all of the current windows, and a file 
  // selection widget for opening  new windows.)
  ImageDisplay (const Image<T>& image, WindowManagingApp& app);
  ImageDisplay (const String& imageFilename,  WindowManagingApp& app);
  ImageDisplay (const String& FITSfilename,  WindowManagingApp& app);
  ImageDisplay (const Array<T> array, WindowManagingApp& app);

ImageDisplay operations: once the display is opened, and the image is on view, there are a number of things that the user might wish to do. These may be initiated from the graphical user interface, from the glish command line, or as the result of glish events that come from another glish client.6

Here are several scenarios in which the ImageDisplay will be used:

Scenario One

An astronomer-programmer is experimenting with a new algorithm, writing application code at a fairly high level of abstraction, and wants to see a plane of his image at every step in the algorithm. By constructing an ImageDisplay from either an AIPS++ array

  ImageDisplay  view1 (array);  // coordinate information not important

or from an Image

  ImageDisplay  view2 (image);  // coordinate information included

he would get a window displaying the image, with appropriate controls, with no more effort than the single lines of source code shown above. The controls would include (for example) a colormap manipulator, intensity and position readouts (which change as the mouse pointer is moved across the image), and a close button.

Scenario Two

An astronomer wishes to examine a spectral cube. Working from the glish command line, the 0th moment of the cube can be displayed with these simple glish commands:

  image := readImage (``cube'');
  moment0 := calculateMoment (0,image);
  displayImage (moment0);

Upon examining the moment map, the astronomer decides he's interested in a particular spectrum. There are two ways to get the pixel information back to glish; both methods cause an ``ImagePixel'' event to be sent from the ImageDisplay component back to glish. The first approach is for the astronomer to invoke a ``Select Pixel'' menu option available on the graphical user interface of the ImageDisplay component. The second technique is to send a ``SelectPixel'' event from glish to the ImageDisplay component. Both approaches have the same result: the ImageDisplay slips into a special mode, the cursor changes (for instance, from an arrow to a cross-hair); the special mode ends only when the user clicks on the pixel of interest. The ImageDisplay component then sends a glish ``ImagePixel'' event back to the glish CLI, which will then extract the appropriate z vector from the spectral cube, and send that vector (with coordinate information) off to another component for display.

Scenario Three

There will no doubt be a demand for an integrated GUI image application, capable of displaying many images each in their own window, and with a master control panel for opening new windows, and controlling those which are already open (see the WindowManagingApp briefly described above). Our strategy is to expose all of the manipulations provided by a component as member functions in the components public interface. Thus zooming, pixel selection, and colormap manipulation will be available as function calls. These function calls can be invoked through buttons and other widgets in the window of the component, and can also be invoked via glish events. It should be clear that a complex, integrated GUI application for image display and manipulation can be created by wiring together a number of components of different type, each making some calls to the public member functions of the others. To illustrate: our integrated application could make selective use of a TableEditor component to examine and modify keywords stored in the image; the application could run an x-y plotter component to display the sequence of values in one particular array keyword; a spectrum could be plotted (as in scenario two, above) when a pixel is selected in the image; a subimage of interest could be marked, for further exploration, or for masking, using the interactive drawing capabilities of the ImageDisplay component.


next up previous
Up: AIPS++ Note 172: Infrastructure Graphics Previous: Being Prepared for New Developments in Computer Graphics
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-03-28