From efomalon@cv3.cv.nrao.edu Thu Dec 12 08:00:36 2002 Date: Tue, 26 Mar 2002 22:27:20 -0500 From: Ed Fomalont To: Steven T. Myers , rmarson@cv3.cv.nrao.edu Cc: cbrogan@cv3.cv.nrao.edu, jhibbard@cv3.cv.nrao.edu, julvesta@cv3.cv.nrao.edu, wbrisken@cv3.cv.nrao.edu, lincoln@play.harvard.edu Subject: Revised viewer notes from March 25 meeting Hi all, Thanks for your comments. Alot of fuzziness and some misconceptions were removed from the draft (I hope). Ralph sent me an email which I have added at the end, and have included some of his suggestions. I should send this to the rest of the NAUG (I think I'll wait til after the NAUG meeting to send it to the aips++ group) before 10 am (MT), so any last comments have to come in before then. Anyway, you'll have a second chance during the meeting. Ed Specific comments on the changes are: -- The first section is now titled "Viewer Look and Feel" as suggested by a few of you. Infrastructure gobble-de-gook was removed. It's still may be more positive sounding than John would like, but... -- For the Viewer execution speed, I took John's suggested rewrite. I did talk with David King about the recent execution speed increases. It seems to be a combination of many things and not one breakthrough. -- For the specific load and display specifications, I displayed a 6k x 6x image in aips and aips++ for comparison. It took 0.5 s in aips and 7 seconds in aips++. Now, this comparison may not be the best, but I concluded that the speed of 30 Mpixels/sec (half of the aips rate) should be the goal. Does this sound more reasonable, Walter? Anyway, using this rate, I determined the numbers for the various situations, except for the sequential loading which is got to have more overhead opening many files. -- There are now 10 suggested improvements after adding some already in the hopper. -- Ralph thinks there is a way of saving some of the viewer actions for later use, but it is obscure and not complete. -- I hope section 5, dealing with multiple images is okay. -- The double clicking section 6 suggestion comes from Ralph. While I have gotten used to the double clicking, there are some relatively strong technical reasons why it should be replaced. -- Number 7 through 10 were on Joe's list. ----------------------------------------------------------------------- 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 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 arein 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, the loading and display of data at 30 Mpixel/s (excluding the loading of viewer code and other overhead), which are obtainable in other packages, is suggested. This is about a factor of 10 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. 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. 4. 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. 5. 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. 6. 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. 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. ---------------------------------------------------------------------- Ralph's email. Hi Ed, My comments fall into two categories. First I'll respond to your summary, then I'll move on to the issue I would have liked to have brought up yesterday. > a. Loading a 4kx4k image in xxx sec. > b. Loading a cube of 128 512x512 images in xxx sec. We should tigten this up, defining what "loading" means. I suggest it means the time taken to display an image as a pseudo color raster in a new window begining the timing at the point at which the image name is specified. This should not include the time take to load the viewer code. We should have a short script that defines this precisely and I can write this script. Someone else should provide the sample images. > c. Browsing over the data in b in xxx sec. Similarly what does browsing mean? Does it mean the time take to run through all planes using the movie capability or the time taken for the viewer to display the next plane or an arbitrary plane when they press the relevant button (multiply this time by 128). I would argue the latter is a more useful number but it is harder to quantify. The problem with the timing the movie is that the viewer does some processing the first time is goes through an image and subsequent passes through the image are much faster. You should also define which axes you are viewing as this has some implications for performance. > b. Implementing a set of useful 'hot-buttons': Many of the viewer > functions and adjustments require several 'clicks' and a wait of > several seconds for gui's to appear before they can be implemented. > We suggest that the most 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 deciding which functions 'deserve' hot keys. Hot keys are fine but as we have all seen with observe different keyboards can lead to all sorts of problems. This implies that this capability should be user programmable > c. More functions tied directly to the viewer: The tool button in the > viewer should also include the higher level analysis tools such as > imagefitter and imageprofile (and interactivemask?). At present these > tools bring up their own viewers even if a viewer already contains the > image with the appropriate display. I'm not sure I agree with this. Image analysis & fitting are not always applicable. For example msplot uses the viewer but you should not be able to fit gaussians to the interference. > d. Documentation and storing of viewer actions: The suggestions > under this heading are: > > 1) Placing all viewer actions in the log so they can be > repeated if necessary > 2) Implementing user-specified defaults (egs plot border, character > size, viewer size) somewhere. We don't know how and where. In the adjust panel there is some of this capability. It allows you to save and restore the configuration of the adjust panel (which controls things like axes labeling). The problems are: * You need to load the image first and then load its display parameters. This should all be possible in one step. * The contrast and brightness are not in the adjust panel and hence cannot be saved and restored. Thats all for comments on your summary, now onto my specific beef which is double clicking. I do not like double clicking both from a user interface perspective and from a technical perspective. I'll start with the technical criticism. Double-clicking is not a builtin event in X-windows, as are things like key-presses, mouse motion or mouse press & release events. So aips++ works out if the user has double clicked by detecting a mouse press event, starting a timer and then if the same mouse button is pressed again before the timer runs out it sends a double click event. The problems with this are: * double clicking can be impossible if you are working on a heavily loaded machine or displaying on a slower or heavily loaded network link. Ed tells me he has observed this phenonomon. * A single click event cannot be recognised until the double-click timeout has expired. This leads to slower interactive performance. It is quite possible that these reasons contribute to my observation that I know of no other image display packages that use double clicking. And this is at least partly why I find double clicking non-intuitive. In the longer term I would recommend that double clicking be removed (for the performance reasons in point two above). In the short term I would recommend that a new stratagy be defined that relies solely on single clicking and other X11 intrinsic events. This would address point one above. This stratagy should become the default as soon as it works reliably. An example of what I am talking about is zooming. To zoom into a region at the moment you define a rectangle region and then double click in the box. I would replace this with defining a rectangle and then pressing a "zoom" button. A "zoom" hotkey as suggested by others could also be used to do the same thing. I recognise that this is a significant interface change but I argue that the technical problems with double clicking will continue to degrade the robustness of aips++. I also recognise that all viewer capabilities that use double-clicking need to be considered by the NAUG so that we can come up with a credible alternative. I must say I also do not like having different mouse buttons attached to different functions. But I can live with this as I just use the left mouse button for everything. Cheers Ralph