NAUG MEETING (Testers only)

             WED. Mar 27  13:15 (MT)
                          15:15 (ET)
               **** TODAY ******

           Usual Video Conference Setup


                      AGENDA

1.  Report from the testers:

    Recent successes and new problems

2.  Anything else?

3.  Review of Viewer Group Suggestions before sending it
    out to the aips++ group

    
================================================================================
Summary of March 25 Viewer Group Meeting:

Attendees:  Walter Brisken, Crystal Brogan, Ed Fomalont, 
            Lincoln Greenhill, John Hibbard (CV), Steve Myers
            Ralph Marson (off-line)

     The goal of the meeting on March 25 was the preparation of a
preliminary report for the NAUG concerning aips++ viewer improvements.
In consultation with the aips++ group, we suggest a possible
time-scale for further NAUG/aips++ viewer interaction as:

a.  March 25:  preliminary meeting 
b.  March 27:  NAUG discussion and refinement of suggestions
c.  Written report to the aips++ group before the Apr 11 
    NAUG/aips++ meeting 
d.  Iteration with aips++ group over next few months.  This can and
    should include demonstrations of the desired functionality using
    other packages.
e.  Organize an aips++ viewer workshop in Socorro end of
    May after aips++ global meeting

    The suggested recommendations coming out of the March 25
meeting are as follows:

1.  Viewer Look and Feel:  

    The group is generally satisfied with the present viewer look and
feel.  As with most image-display software, there is a steep learning
curve to use its full flexibility and the placement of some functions
is not intuitive and more is cumbersome that need be.  Documentation,
documentation, documentation.  The viewer contains some unique
applications, and has a greater potential to link sophisticated
display with image analysis of many kinds.
    
2. Viewer Execution Speed:

    The viewer is very slow in accessing and displaying images and
modifying the display properties, compared to most other display
packages which are in use (IDL, DS9, Karma, saoimage).  While the
aips++ viewer incorporates powerful analysis tools that are largely
absent from other display packages, visualization is inherently an
interactive process, so it is critical that aips++ be competitive with
other existing tools in this regard.

    The aips++ group has increased the speed of many of the viewer
functions, but much more is needed.  These improvements have been
obtained in a variety of ways - migrating code from glish to c++, more
efficient refreshing cycles.  The bottom line is---do whatever has to
be done to bring the viewer up to speed.

    As an approximate goal, we suggest that the loading and display of
data (using a Dual/Xcon 1.7 GHz cpu) with the aips++ viewer equal that
for aips and other packages, which is about 30 Mpixel/s.  This is
about a factor of 5 faster than the present loading and display of
images.

   a.  Loading and displaying a 4kx4k image in 0.5 sec
   b.  Loading and displaying images up to 16k x 16k in 10 sec
   c.  Loading and begin display of a cube of 128 512x512 images in 1 sec
   d.  Sequential loading and displaying N 512x512 images in 0.05 sec each
   e.  Continuous and seamless display of slices along the 3rd dimension
       as the user moves the curver around the 2-d display

3.  User/viewer interaction improvements:

   We list below what we believe are the more important user/viewer
interaction improvements that the aips++ group should consider.  Some
have already been written up as defects and enhancements, but we wish
to emphasize their priority.

1.  Slide bar to move through a data cube: The present simple stepping
through a data cube is too limiting.  We recommend the use of a slide
bar to control the speed and direction of the display of images in a
data cube.  This will require the enhanced speed of the viewer to
be effective.

2.  Implementing a set of useful 'hot-keys': Many of the viewer
functions and adjustments require several 'clicks' and a wait of a few
seconds for gui's to appear before their functions can be implemented.
We suggest that some selected common adjustments and functions
should be also implemented by a single stroke of a 'hot' keyboard
character.  If the aips++ group can implement such hot keys, the NAUG
would be happy to participate in discussing which functions 'deserve'
hot keys, including additional functionality which is not yet present
in the viewer.  Should these keys be user programmable?  Different
keyboard formats can be a problem.

3.  Double-Clicking: We believe that the double-clicking to activate
some aips++ viewer functions be reconsidered.  Two technical reasons
are: on a heavily loaded machine or running the viewer remotely,
double clicking may not be possible since aips++ uses a well-definied
maximum time between clicks (experienced when running aips++ in
Socorro remotely from Charlottesville); and a single click event can
not be recognized until the double-click time-out has expired, leading
to slower interactive performance.  Besides being non-intuitive
(although we are getting used to it), no other image display packages
that we know of use it.

     Other more common strategies are available.  For example, to zoom
into a region at the moment you define a rectangle region and then
double click in the box.  This could be replaced by defining a
rectangle and then pressing a "zoom" button or a "zoom' hotkey.  This
is, clearly, a significant interface change and must be considered
carefully, as well as the alternative.  A major question is the degree
of degradation of the robustness of aips++ caused by the double
clicking strategy.

    Thus, double-clicking and hot-keys are related to the user
interaction with the viewer and probably should be considered
together.

4.  More functions tied directly to the viewer: The tool button in the
viewer should also include the higher level analysis tools such as:
imagefitter; imageprofile; interactivemask.  At present these tools
bring up their own viewers even if a viewer already contains the image
with the appropriate display.  Other functions, such as creating a new
image from a subset displayed on the viewer, could be incorporated in
the tool button.

5.  Storing viewer actions for later use: Some of this ability may
be presently possible, but needs documentation.

     1) Storing all viewer actions somewhere so they can be
        replicated when revisiting the viewer a second time.
     2) Implementing user-specified viewer defaults (egs plot border,
        character size, viewer size) somewhere, perhaps the .aipsrc file.

6.  The ability to display multiple images simultaneously in different
windows or "panes" in the same viewer that are not overlayed and have
not been assembled into a cube: For example, the display of several
spectral line cubes, each of a different molecular line, needs alot of
versatility.  One might want to overlay their spectra in one display
while having their images displayed in separate windows.

7.  Position-slice applications:  These are currently being developed
by the aips++ group and we consider it in the high priority group.

8.  MSPLOT migration into the viewer:  Although msplot had matured into
a good tool for data editing, we support its incorporation into the viewer.

9.  Viewer blinking of images:  Currently being worked on and eagerly
waited for.

10.  Viewer annotation: Enhancements in viewer annotation will lead to
publishable plots and images which need littoe or no further
additions.  It is already on the 'todo' list for the aips++ group.

----------------------------------------------------------------------