AAOGlimpse recent changes
The program now supports multiple concurrent images, rather
than just a main image and a secondary image. This turned out to
be quite a significant change, mainly because of the need to
provide a number of new features in the GUI to support more than
two images at a time.
A new keyword display strip can be used to display the value of
a selected FITS keyword.
AAOGlimpse has also gained the ability to produce a 'true'
colour image from three separate coloured images (usually red,
green and blue, although the facility is more flexible than
A new, more or less experimental, option for displaying 3D data
using dots for each pixel to provide a sort of simple
transparency is now provided.
3D data cubes now have a Z-axis drawn as well as the X-Y axes
provided to date.
And there are a couple of bug fixes.
Multiple concurrent images:
- In principle, any number of images can be loaded at once. Images are loaded into what can be thought of as slots, each given integer an number. '1' is the main image, and '2' the secondary image. The 'Open' option in the 'file' menu opens the specified file as image 1, and the 'Open secondary' option opens it as image 2. The new 'Open new' option in the 'file' menu opens the specified file using the lowest image number currently not in use. The new 'Close' option closes the currently displayed image, making its number available for re-use. The image number is now displayed in the title of the display window along with the file name. So 'Open' and 'Open secondary' work as they always did, but 'Open new' and 'Close' allow any number of images to be handled concurrently. 'Close' isn't needed in order to open new images in existing slots, which simply replace existing ones (which are closed automatically), but can be used to close down any that are no longer needed.
- The new 'Images' menu contains a list of the various images currently open. Selecting any of these causes it to be displayed. This is a convenient way of seeing which images are loaded at any one time, but it isn't the fastest way of switching the display between them; the numeric keys and the arrow keys are much quicker, as described below.
- Displaying multiple images at the same time (the way the '3' key could be used to display the main and secondary image superimposed) becomes more complex with more than just a main and secondary image being supported, but I think it works reasonably smoothly.
- The way the numeric keys work has been modified to support images numbered in the range 1..9, so '1' displays the main image and '2' displays the secondary image, as before. However, '3' through '9' now display images with the corresponding numbers. So normally, the keys '1' through '9' can be used to display single images with the corresponding numbers. To display multiple images simultaneously, the concept of 'tagged' images has been introduced. The new 'file' menu option 'Tag current display' toggles the 'tag' setting for the currently displayed image. Pressing the '0' key displays all currently tagged images in superposition. So you can use 'Open new' twice in succession to open two new images, tag them both, and press '0' to see them superimposed.
- Potentially even more usefully, the left and right arrow keys now cycle through the various images. This is certainly the simplest way of looking at a set of images.
(Note: To maintain some backwards compatibility, as a special case, if there is no image numbered 3, the '3' key will display the main and secondary images together, as before.)
- The most general way to open multiple images is through the
new 'openNth' socket command, which takes both a file
name and an image slot number. Image numbers do not need to be
used in sequence, and it is quite possible to use 'openNth'
to have only images numbered, say, 5 and 8 open. Or even -5
and -6. The numbers are really being used as labels, rather
than as index values. The new 'openNew' socket command
has the same effect as the 'Open New' menu item,
opening in the next available image slot.
- The 'displayImages' socket command now supports any combination of images, and can also be used to get multiple images displayed simultaneously. Note, it will accept any integer, even -ve ones. (At present, a limitation of the implementation means that 0 is taken as signalling the end of the list, so you can use 'openNth' to read in an image and give it number zero, but the only way to return to it once you display some other image is using the right and left arrow keys, since displayImages can't be used to display image zero, and the '0' key displays the tagged images, not image zero.)
- The 'windows' menu now has a 'show keyword strip' item. This toggles the display of the new keyword display strip. The strip also has a 'hide' button that can be used to hide it.
- The strip has a selection button that has a drop-down menu of all the FITS keywords provided in the header of the current image. When one is selected, its value and associated comment is displayed in the strip.
- The drop-down menu is updated automatically when a new image is displayed - for example, by opening a new image, or by cycling through the set of currently loaded images. The value displayed also changes when a new image is displayed. So as you cycle through a set of images, the strip shows the new value for each image.
- At present, only one FITS keyword can be selected for display at a time. (I'm considering supporting multiple keyword strips.)
'True' colour images:
- The 'lut' socket command now treats the names 'red', 'green' and 'blue' as special cases, setting up a 'gray' scale but just using the specified colour.
- The new socket command 'newFromThreeColours' combines three images in such a way that the resulting image has data values that are the sum of the data in each image, and fixed colour values that are the sum of the colours of each of the images as currently displayed. (So the final colours can be manipulated by changing the scaling used to display any of the component images.)
- (The combination of 'openNth', 'newFromThreeColours' and the changes to 'lut' allow one to open three images, colour one red, one green and one blue, and then combine them. If they were images taken through appropriate colour filters, this would give a true colour image. This was in fact the original reason for adding support for more than two images. A typical command sequence might be:
glimpse setDefaultPath `pwd`
glimpse openNth red_image.fits 2, lut red
glimpse openNth green_image.fits 3, lut green
glimpse openNth blue_image.fits 4, lut blue
glimpse newFromThreeColours 2 3 4
newFromThreeColours takes an optional 4th argument, the number of the resulting image, which defaults to 1, ie the result becomes the new main image. In practice, the scales for the images will probably need to be set to control the contribution of each image to the final colours.)
3D data - dots and axes
- There is now the option of displaying using dots of a specified size rather than cubes or quads. This is being used to see if this offers any advantages for displaying 3D data. The "Surface by cubes" item in the 'file' menu has been replaced by a more general "Surface by" item that leads to a sub-menu with "Quads", "Cubes" and "Dots" as options. At the moment, when dots are used the default dot size is 2 display pixels, and this can only be changed through an undocumented 'set' command.
- There is a new 'surfaceBy' socket command, which takes a string that can be one of 'dots', 'quads' or 'cubes' (case-insensitive).
- When a 3D data cube is being displayed, the axes now include a Z-axis drawn in the YZ plane. This can be moved in the same gimmicky way as the 'normal' axes drawn in the XY plane, but this has needed a small change to the way the '+' and '-' keys work. The unshifted versions of these keys move the XY axis plane, while the shifted versions move the YZ axis plane. Previously only the XY axis plane was drawn and so was the only one to move, but you could use either the shifted or unshifted versions of the keys to move it - most people would only use the unshifted versions, and that still has the same effect. (Detailed caveat: the unshifted versions of these keys are '-' and '=' and the shifted versions are '_' and '+', and those are the actual characters the program is testing for. This sounds awkward, but works fairly naturally, so long as you have a keyboard where '_' and '-' are the same key and '+' and '=' are the same key. This is not true of all keyboards, but it seems to be true of most - even including the Dvorak, although it doesn't seem to have them next to each other, which spoils things slightly.)
- Bug fix in gaussian fitting code. In some circumstances
really noisy data could generate an access error that crashed
the program. (This didn't seem to happen until I changed to a
different compiler on OS X - it seems to depend on how the
compiler handles a divide by zero and the resulting nan value
for the line center estimate. I couldn't reproduce this when
running the OS X 1.5 release. Sanity checks have now been
added to the fitting code.)
- Bug fix in the data access code. A mistake in the tidying-up code was sometimes causing a crash as the program closed down.
Internal and experimental things
- The new 'set' socket command sets the value of a
named parameter. This is useful for adding quick features of
an experimental nature to the code. A piece of code buried a
long way down can get the value of such a parameter and modify
the way it works accordingly. This provides a way of changing
such values easily from the command line and experimenting
with their effect. If a feature proves useful, a proper user
interface can be implemented to allow it to be specified and
the housekeeping added to deliver this through the various
layers of code. (The code has no way of knowing this value has
been changed, so just giving a 'set' command will not
itself usually induce a change in the display; the new 'redisplay'
command can handle that.) This should never be needed in a
production release of the code.
- The new 'redisplay' socket command forces a complete redisplay of the data, including a regeneration of all the graphics. This should never be needed in normal use, but is useful during testing to force a new parameter set using the 'set' command to take effect.
Although this has clearly always been the
case, it was only in testing this version that it was realised
that it is possible to use the various 'open' socket commands
('open', 'openSecondary' and the new 'openNth' and 'openNew') to
open images in FITS files that are not the first image in the
file. The cfitsio library supports the syntax 'filename[n]'
where 'n' is the number of the image in the FITS file. The main
image is number 0, so 'myfile.fits' and 'myfile.fits' will
both have the same effect. (Strictly, the numbers refer to HDUs
or Header Data Units, and these can be extensions of various
types, not all of which are images.) Note that cfitsio is very
strict about enforcing the FITS format, and there are files
around that are supposedly FITS files with multiple images that
do not conform and which cfitsio (and hence AAOGlimpse) will noy
read. In testing, the original file used was rejected because
all extensions contained the keyword SIMPLE=T, which is in fact
forbidden in extension headers.
This version provides a few new features, such as a center-of-gravity estimate for the data in the selected area and some new socket commands. It also has a number of relatively minor changes to the way some aspects of the interface operate, all intended to make the program just that bit easier to use. And, of course, a couple of bug fixes.
- An option has been added for displaying the center of gravity of data in the selected area. A COG check box has been added to the selected area control strip, If this COG check box is checked, the COG position is displayed at the top right of the main display window, and the cross-hairs in the selected area show the position of the center of gravity instead of just the center of the selected area. The COG algorithm is relatively crude, particularly in the way it deals with any background slope the data might have.
- The socket commands 'Enable' and 'Disable' now accept 'XYLogPlots' as an option. This can be used to set the face-on plots of the selected area to a log scale. (At the moment, that's the only way to control this - a menu option should really be added.) They also now accept 'plotsCollapsedInX' and 'plotsCollapsedInY' as options.
- The selectPixels socket command now applies to all currently displayed images, not just the first.
- A new socket command SetDefaultPath directory allows a directory to be set as the default directory when files are opened. This applies to files specified in the "open" and "openSecondary" socket commands.
- The Navigation/Zoom area can now be resized by dragging the separator between it and the main display.
- The 'graph through planes' option is now controlled from the 'Plots' menu, since it is a plotting option. The check box in the selected area control strip that used to control this has been removed.
- Clearing a selected area now also clears any plots based on the data it includes - so plots collapsed in Y or X, or plots through planes, are cleared. This makes command-delete a convenient way of clearing such plots without actually needing to disable the plotting; if a new area is selected, any enabled plot appears automatically based on the newly selected area.
- The default data range used for data histograms is now the display scale range, not the extreme data range - this works much better for images with mainly low valued pixels but a smattering of very large values - CCD images with cosmic rays, for example.
- Some minor changes to the way the entry boxes in the control strips work. Editing a value in an entry box now changes the background to a light grey to indicate that this value has been changed but not yet applied. When the value is applied, usually by pressing 'return' while in the entry box, the background reverts to the default white. Some entry boxes - such as the set of highlit area entry boxes or the min and max scale boxes - are linked, and pressing return in any of them applies the values in all the linked boxes. (The only functional change here is to the handling of the background colour, to make it clear which values have been applied and which have not.)
- Pressing 'return' in an entry box in the control strips now moves focus to the main display window. I have had a lot of irritation from making a change in a scale entry box and then using the '1', '2' or '3' keys to switch between displaying the main or secondary images or both. Previously, the entry box would retain focus and the numeric key would end up in the entry box instead of having the intended effect. The new scheme gets around this, but may mean having to click on an entry box before making a second change - for example, when experimenting to find a suitable scale value. There may be a better way of handling this; I'm open to suggestions.
- Switching between displayed images (using the '1','2' and '3' keys, for example) now updates the selected area parameters properly in the GUI. (I'm not sure if this was a long-standing bug, or something that broke with the introduction of the navigation windows.)
- A single click in the AAOGlimpse window (for example, to bring it to the front) no longer has the annoying side-effect of clearing any selected area.
- On OS X, the program assumes the presence of a couple of
specific font files, both in /Library/Fonts: "Times New
Roman.ttf" and "Arial Bold.ttf". If either of these were
missing, text would not be displayed properly in the graphics
window. Worse, if "Arial Bold.ttf" was missing for any
reason, the program would crash after reading in the first
data file. The crash has now been fixed, and a workaround has
been introduced where the program falls back on the standard
Qt fonts if these other fonts are missing. The main limitation
now is that if the Times font is missing, the program can no
longer display the sweeping "AAO Glimpse" text that appears if
you leave the startup screen running for more than 15 seconds.
Most people will probably not notice. A similar issue affected
the Linux version, although there the program would try a
number of possible font files before failing. The Windows
version only uses Qt fonts - and has never displayed the
sweeping message in the startup screen.
Version 1.4 introduces two new windows to help simplify
navigation around the data being displayed, adds a facility for
fitting Gaussian profiles to plotted iines, allows AAOGlimpse to
be run automatically by double clicking on FITS files, allows
the data values in the selected area to be written out to a text
file, and also - finally - introduces support for printing.
There is a new menu item used to control opacity effects in
The changes introduced in version 1.3 made it rather easier to navigate around an image. Nonetheless, in practice it became obvious that zooming in on one part of an image, then zooming out to locate another part and zooming in on it, was still not as easy as it ought to be. In fact, it became obvious why programs such as Skycat and DS9 have two extra windows along with the main display window, one showing a zoomed display of the portion of the image under the mouse, and one showing the area currently displayed in the main window in the overall context of the whole image.
So with version 1.4, AAOGlimpse now provides similar capabilities:
- The Windows menu now has a 'Show navigation and zoom
windows' item. When this is selected, the main window
rearranges itself to show two small windows to the right of
the large main window. The top of these is the 'zoom' window,
the bottom is the 'navigation' window. Deselecting this option
will revert to the single main window.
- Initially, the zoom window shows a highly zoomed in view of the area around the mouse. (This is true whether the mouse is in the main window or the navigation window.) The display in the zoom window will always follow the mouse (although it is disabled when the display is being zoomed or panned, because that's both confusing and a load on the system).
- Initially, the navigation window shows the whole of the data being displayed, but on top it shows a white 'coverage' box that shows the area being displayed in the main window. As the main window is zoomed in or out, the coverage box grows and shrinks.
- Both of the zoom and navigation windows are display windows in their own right, and you can zoom in and out of them using the scroll wheel (or two fingers on the trackpad). They show the same data as the main window, and their orientations are locked to that of the main window. The windows work no matter what the orientation of the data (they work in 3D as well as 2D). A reset (command-R, or the Reset orientation item in the file menu) will set them back to their default orientations and zoom settings.
- The zoom window is always set to display using cubes - this looks more natural when a display is highly zoomed - and is unaffected by the 'Surface by cubes' menu option.
- Dragging the coverage box in the navigation window will have the effect of panning the display in the main window.
- If the data is face on, the data readout shown in the top left of the main window will reflect the position of the mouse in any of the three windows.
- There is a new keyboard combination, command-X. (This is a shortcut for the new 'zoom follows mouse' item in the file menu, but it is expected that it will mainly be the keyboard combination that gets used.) Toggling off 'zoom follows mouse' stops the center of the zoom window from tracking the position of the mouse in the other windows. This is useful for cases such as the following: you have the mouse on an interesting feature in the main window, and are looking at it in detail in the zoom window. However, the feature is too large, and you would like to zoom out the zoom window a little so it shows more of the feature. You can change the number of pixels shown in the zoom window by moving the mouse over to it and using the scroll wheel (or trackpad). However, when you move the mouse over to the zoom window, the feature disappears from it, because the mouse has moved and the zoom window now reflects the new position. What you have to do is position the mouse over the feature of interest in the main window, then hit command-X to disable the mouse tracking. Now, as you move over to the zoom window, the feature will stay centered in it and you can adjust the zoom with the scroll wheel as you like. Then you can toggle mouse tracking back on with command-X. It's much easier to do than to describe.
- (You don't need to know this, but the main, zoom, and navigation windows are actually showing completely independent renderings of the data being displayed. The main reason for doing this is so that each can have its own sampling of the data, and, for example, to allow the zoom window to surface using cubes independently of the other windows. So they are individual displays of the same data, and this is what makes it easy to allow them to be, for example, zoomed independently. There is a fairly intricate coupling between them, used to keep the orientations the same and to enable the interactions between them.)
The 'face-on' plots at the bottom of the main screen now include a facility for fitting single Gaussian profiles to emission lines in the plot. If the mouse is over a feature that can be fitted reasonably sensibly to such a profile, the profile is superimposed in a highlit colour over the data, and the fitted full-width at half maximum and line center at displayed in the readout at top left of the main screen. There is not much control over the details of the fit; the algorithm looks for the strongest line close to the mouse position, and so may not always choose the line you have in mind. The range over which it looks is fixed (I'm thinking about nice ways to be able to control it) but it is limited to the range of data being displayed, so zooming in on the line you want may help. Menu options allow a 'top-hat' profile to be fitted if the data looks as if that would be more appropriate.
There are two new menu options in the 'Plots' menu:
- "Enable line profile fitting" is selected by default. If
this is selected, AAOGlimpse will automatically try to fit a
profile of the selected type (Gaussian or Top-hat) to any data
under the mouse in a 'face-on' plot. If it is not selected,
profile fitting is disabled.
- "Fit Gaussian profiles" is selected by default. If selected,
AAOGlimpse attempts to fit Gaussian profiles to the plotted
data. If not selected, it attempts to fit Top-hat profiles.
Normally, the plots at the bottom of the main window controlled
by the 'Plots' menu make use of an opacity effect to make them
stand out against the background of the main image. If the
cursor is within the plot window, the plot background is opaque,
if outside it is semi-transparent. Some machines (in particular
a rather old Windows XP laptop in use at AAO) do not seem to
support this effect properly, with the result that the plots
become almost impossible to distinguish. There is now a new item
in the 'Plots' menu called 'Enable opaque effect'. This is
selected by default and gives the usual behaviour. If
unselected, the plots are drawn without any background of their
own, with the image showing through undimmed. This allows the
plots to be seen on machines that do not support the feature
properly, and some users may find they prefer not have have the
opaque effect anyway, even on machines where it does work.
(Eventually, this and other items should go in a 'Preferences'
Listing the data in the selected pixels:
A new menu item in the File menu, "List selected area..." will
cause AAOGlimpse to write a text file listing the data values of
all the pixels in the selected area. A dialogue box is put up to
allow the user to specify the name of the output text file.
There is - at long last! - now a 'Print' item in the File menu. Selecting this puts up a print dialogue which will print a copy of what is being displayed in the main window. You get an exact copy of what is in the main window, including any plots at the bottom of the screen. The effect is like a screenshot of the main window. (Note that as currently implemented, it really is a screenshot of the main window, and so has the same resolution as does the main window. In principle, it is possible to regenerate the display first at higher resolution, but that is something for a later release, perhaps.)
Double-clicking on FITS files:
It is possible on both Windows and OS X to specify AAOGlimpse as the program to be run when double-clicking on a file with a specified extension. On Linux it can be run with a filename as a command line argument. AAOGlimpse now supports being run in this way. You can set it as the default program to be run to open ".fits" or ".fts" files (or even ".jpg" or ".jpeg" files, if you really want it as your default photo viewer), and double-clicking on such a file will load AAOGlimpse and get it to automatically open the selected file.
Note: The behaviour is slightly different between Windows and OS X if AAOGlimpse is already running when such a file is selected. Windows will run a new copy of AAOGlimpse to open the file, OS X will get the existing copy of AAOGlimpse to open the new file. At present, dragging a file into the AAOGlimpse window does not open it (it does nothing at all).
- The MousePosition socket command introduced in version 1.3 has been dropped. It was only ever intended as a diagnostic test that was useful until the 'center on mouse' feature was working.
- The plots of the cuts through the selected area no longer are drawn an unexpectedly large distance from the selected area when the display is zoomed in a long way.
- The boundary box showing the selected pixels is now drawn
around the perimeter of the selected pixels rather than
through the centers of the boundary pixels. This makes it
rather clearer which pixels have been selected, particularly
when displaying using cubes.
The introduction of the zoom and navigation windows meant supporting multiple OpenGL windows in AAOGlimpse for the first time, and some significant internal changes have been needed, including the introduction of a whole new 'display coordinator' layer to handle interactions between the windows. The documentation still needs to catch up.
Pixel sampling now supports both 'min' and 'extreme' options as
well as 'sparse', 'mean' and 'max'. At present these can only be
changed through the socket interface, using the SetSamplingMode
command. 'Min' simply picks the minimum value from the range of
possible data values (and so emphasises negative spikes, for
example). 'Extreme' picks the value from the range of possible
data values that is furthest from the mean. This will be either
the maximum or the minimum value, and so emphasises both positive
and negative spikes in the data. 'Extreme' is the slowest of the
options currently provided, and 'sparse' is the fastest - this may
be noticeable on big images.
There is a new menu item in the File menu called 'Center on mouse'. This is tied to the command-C keyboard short-cut. It re-centers the display so that whatever was underneath the mouse cursor position is now at the center of the display. This is always going to be used with the key combination, because, of course, you have to move the mouse to select the menu item; but the menu item serves as a reminder that the facility exists.
- It was possible to cause a crash by choosing to display data
statistics and then moving the selected area entirely outside
the valid data range. This is now trapped. The statistics box
now only appears when there are valid statistics to report -
it disappears if the selected area moves completely outside
the displayed data. If stats are enabled with an area already
selected, they are now displayed immediately (and not just
when the selected area is moved!).
- The data range values reported in the scale control strip have been faulty since version 0.86. Only negative minimum values and positive maximum values were being reported correctly. Now fixed. Amazingly, this took this long to spot.
- The command-A keyboard short-cut had been used for both 'Animate' and 'Autoscale'. Since 'Autoscale' is quite useful and 'Animate' is only a bit of eye candy, the short-cut is now only used for 'Autoscale'. Animation can still be controlled using the File menu - but it no longer shows as having a defined short-cut.
- There are two new socket commands, CenterOnMouse and
MousePosition. CenterOnMouse does just the same
as the file menu item of the same name, and MousePosition
allows the position of the mouse to be changed in terms of an
X and Y pixel position within the OpenGL display window. These
were introduced to allow testing of some of the new code, and
are probably not going to be generally useful - they may be
deprecated at some point.
A number of changes aimed at making the graphs plotted at the bottom of the display (sometimes called the 'face-on' graphs, because they don't rotate with the main image display) more useful. The graphs themselves are more flexible, able to be resized and with control over the scales in both axes, and can now be used to display cuts through the data.
- The height of the area used for these graphs can now be modified. If the mouse is placed near the top of the graph, the top changes colour to yellow, and can be dragged up and down the screen.
- The scroll wheel can still be used to zoom in on a specific portion of the plot, but if the shift key is held down during the scroll, the vertical scale of the plot is now changed. Dragging a point of the plot can now pan it both in X and Y. This makes it possible to zoom and pan in both axes of the plot.
- If the mouse is in the area of one of these graphs, the
cursor readout in the top left of the main display shows the X
and Y graph coordinates for the point under the cursor.
- There is now a 'Plots' menu which applies to these graphs. It can be used to select the type of plot, which can be one of:
- Data histogram. A histogram of the data in the selected area (or the whole image if no area is selected). This option was available in earlier versions, but was previously selected using an item int the File menu.
- Selected area collapsed in Y. The plot is of the summed data in the selected area, collapsed in the 'Y' direction (when the display is in the default orientation). The data plotted is the same as that shown in the X-direction when 'cuts through data' are enabled in the selection area control panel, but because it can be zoomed and panned - and because it produces a more conventional plot - this is often much more useful.
- Selected area collapsed in X. This plots the other of the graphs displayed by the 'cuts through data' option in the selection area control panel.
- The other type of plot displayed in this way - the graph through the planes of a cube - is still selected using the selected area control panel. This should really be moved to the Plots menu.
- The Plots menu also has an 'autoscale' item. Selecting this resets the scale of the plotted data so that it shows the full data range for the data. (If the plot has been zoomed in, so only a subset of the data is being displayed, 'autoscale' does not change that. It is easy enough to scroll back to display all the data. It is harder to use the interactive scale zoom and pan (with the shift key down) to set to display the full range of the data, which is why 'autoscale' is often useful.
One minor bug fix: The sigma filter code in the spike removal
algorithm was miscalculating the mean value. This had little
effect on the way it was being used in AAOGlimpse, but showed up
when the code was 'borrowed' for another application.
The main change with version 1.1 is that it has now been built for Windows, and the release now includes a Windows executable.
There are very few functional changes and bug fixes:
- There is now a "Display Statistics" item in the File menu.
This causes the mean and standard deviation of the data in the
selected area to be displayed at the top right of the main
window. Note that there has to be a selected area for this
display to be meaningful - it doesn't default to the whole
image, although perhaps it should.
- In version 1.0, if the console window had been displayed, closing first the console window and then clicking the close box on the main window left the program running but with no windows and no menu showing in the menu bar. This has now been fixed.
- Now that the highlit area controls have moved to a control strip that is part of the main window, having them appear the first time an area is selected was causing an irritating (to me) jump in the display as the area was drawn. Having both control strips visible at startup looked cluttered, so the current compromise is that now neither control strip is visible at startup, but both appear as soon as the first file is opened. There may be better ways of doing this.
- The data histogram is now continually recalculated as you zoom in and out and pan the data histogram plot. Before if the data for an image was mainly concentrated in a small data range, but there were some few points at quite different values (eg noise or cosmic ray spikes), the fixed number of histogram bins used was spread over that large data range, with low resolution in the main area of interest. Zooming in on that area simply zoomed in on just a few resolution elements, and didn't help. Now, at the expense of recomputing the data histogram on any change in the display, zooming in really does show the distribution in increasing detail.
- The code will now build with or without the FTGL OpenGL 3D text library. This can be installed on Windows, but it looked a complex business (I may be wrong there) and Qt provides support for almost all of the simple things I used FTGL for. The exception is the way the words "AAO Glimpse" start to sweep around the display if no file is opened for ten seconds after the program starts. I miss this effect, which I can watch for ages, but it's hard to argue that it's essential. At present, FTGL is used on OS X and Linux, but not on Windows. A new "TextHandler" sub-system handles text and deals with the presence or absence of FTGL as needed.
- A single Qt .pro file controls building on all platforms. The whole source release for AAOGlimpse now consists only of this .pro file and a small set of .cpp, .c and .h files (oh, and one icon for OS X). The Xcode project that used to be included can now be generated from the .pro file using Qt's 'qmake' utility.
- A very few functions (such as determining the amount of available physical memory) required different code for the different platforms. All of this has been collected in a couple of specific system dependent files (GlimpseSysdep.h/.cpp).
- The Visual C++ 2010 compiler is very fussy and generated a number of warnings, particularly where I had been a bit cavalier with conversions between double and single precision floating point values. As a result, all such code has been reviewed, and now should build with no warnings on any of the platforms - at least, with the compilers I've been using.
A sudden jump to version 1.0. This is finally the long-awaited portable version of AAOGlimpse, now released for Linux and for OS X. (A Windows release is perfectly feasible, and is being investigated, but isn't included yet.)
Version 1.0 has very few changes to the system-independent
code, apart from a couple of bug fixes and some changes to the
interface connected with the location of font files. Until now
the only version of the system-dependent code available was one
written in Objective-C++ for OS X. The big change in version 1.0
is that there is now a version of the system-dependent code
written, not for one specific system, but for Qt.
Qt is an application development framework that allows code
written for it to be built and run on a number of different
systems, including Windows, OS X and Linux. This means that this
new version of the "system-dependent" code can in principle be
built on any of these systems. Strictly speaking, I suppose this
layer is now 'framework-dependent' rather than
The system-dependent code implements most of the GUI aspects of
AAOGlimpse, including the various menus and the widgets used to
control the display scale options and the highlit area. In
earlier versions these had not had much effort devoted to making
them work nicely, partly because any such effort was going to
have to be redone for each implementation of this code. This is
no longer the case with the Qt-based version, and so a little
more effort has gone into producing a more integrated GUI:
- The highlit area control panel and the display scale control
panel have now become control strips that appear at the top of
the main window. These can be hidden (going back to the
relatively plain main window of previous versions) and made
visible again using new window menu options.
- Full-screen mode now works much more conveniently, as all the menu options now appear when the mouse moves to the top of the screen (under OS X) or are always visible at the top of the main AAOGlimpse menu (under Linux).
A quick bug fix release when it was realized that 0.86 had
introduced a bug that meant that zooming in on an image could
subsequently prevent display of parts of the image that had been
outside the zoomed area. This should be fixed in 0.87.
Some tidying up of the way 3D data cubes - particularly large ones - are handled.
- A background thread is now used to read in data. This means
that the remaining planes of a large data cube continue to be
read in while the first planes are being displayed. Things can
be a bit slow while large data files are being read, even if
they're being read in the background, but there are no longer
the long delays when you move to a new subset of the data and
have to wait for it to be read in; usually it's there already
waiting for you. As the data is read in, a red line in the
graph through the planes (if enabled) shows the planes still
to be read, and this will shorten and disappear as the file is
- Contours are now only drawn for the top plane when multiple
planes of data cube are being displayed, and they are now
drawn properly - rather than for the wrong plane and in the
- There is now a 'single plane mode' for 3D data, switched in
using a new 'Display single planes' option in the 'File' menu.
In this mode, only one plane of the current cube is displayed
at a time. Until now, if you want to fly through the planes,
just showing one at a time, you have had to do this with the
cube face on. Now, you do the following: home in on a region
of interest in the cube using the limit lines shown in the
graph through the planes; then select single plane mode; then
rotate the plane to get the full 3D effect; then fly through
the planes by dragging the (now) single limit line. As you
drag the limit line through the planes (or use the up and down
arrows), the single plane at that position is displayed in 3D
- with contours, if enabled, or wires, or whatever.
Previously, it took some quite dexterous work with the
controls to see a single plane at a time in 3D, and it can be
- Fixed a bug where rotating the selected area would cause a
crash when displaying a data cube that would not fit in
- The 'show graph through planes' check box is now cleared properly when the graph is no longer visible, and the graph is cleared properly when a new file is read in.
A number of changes all directed at the question: 'Can this program be used on really large files?'. (That is, ones that are larger than the physical memory available - I was experimenting with a 25GByte data cube on my 8GB laptop.) It now does so much better than it used to, and some of the changes make working with less ambitious large images faster too. Most of these changes are purely internal, except for the way the 'show graph through planes' option works with files that won't fit in physical memory, and even that change is quite subtle. Bottom line - the program has been tested and is usable with a 25GByte data cube, and should be able to go much larger.
- There is no longer a pause when a new file is read in as the
code applies the default data scaling to the array. The
scaling now happens on the fly as the display surfaces are
constructed. Because not all pixels in the image are
displayed, most of the time, especially for large images, this
is usually much faster. (There is still a noticeable pause
when a really big data file is opened, as the available memory
is filled up and the code determines the data range - filling
the available physical memory with data and checking its range
is going to take time! Be a little patient - and I have some
ideas about how to speed this up.)
- A significant review of the data access code with a view to seeing how well AAOGlimpse can handle really large files. In these conditions, the code now prevents virtual memory thrashing by restricting access at any one time to a contiguous set of planes of the cube that will fit comfortably in physical memory. In effect, at any one time you get to work with a sub-cube that the machine can handle. In the plot through the Z-planes (which is the main way of controlling which part of the data you're working on), data outside the currently available subset of planes isn't shown. If you drag one of the limits bars outside that current area, you change the limits of the current area; if the data wasn't already read in, it will be, and the display limit you're dragging changes as you'd expect. However, the other display limit will probably be dragged along with it, as the 'window' of currently accessible planes slides along the cube. This needs a bit more work, but it does make it possible to work with huge data sets. You can only work on a section at a time, but it is fairly easy to move that selected section around through the whole of the data.
- The limit on the size of data files that can be handled is set by the amount of virtual memory available. If the program can allocate an array for the data, it can read it in. The OS X developer pages appear to claim the limit is 18 exabytes (!) but in practice it will be limited by the amount of disk space available for the virtual memory files. Apple's page on virtual memory is here.
- There are now a couple of 'tuning' commands available through the socket interface that control some performance aspects. SetMaxDisplayedPixels controls the maximum number of pixels AAOGlimpse will use when creating the display surfaces. SetSamplingMode controls the way AAOGlimpse deals with those pixels. Selecting more pixels makes the display more accurate, but also makes it slower. In 'sparse' sampling mode, it simply samples up to the maximum number of pixels, ignoring those between those sampled. In 'max' sampling mode, it looks at all pixels in the data being represented by each pixel it actually displays, and uses the maximum data value in those pixels. 'Sparse' sampling is faster, but risks missing spikes in the data which you may be interested in. The default is 'max' sampling of up to a million pixels. Note that in all modes, you can always see the individual data pixels when you zoom in enough.
- AAOGlimpse is now being developed under Lion (OS X 10.7) using XCode 4. This should make no difference to users; it has been tested on both Leopard (OS X 10.5) and Snow Leopard (OS X 10.6) as well as Lion.
The main AAOGlimpse web page now has a table of contents and
should be a bit easier to move around in.
Added support for drawing more 'traditional' 2D graphs of data in the lower part of the screen. These can be used to display plots of things such as a histogram of data values. The plots can be zoomed and panned interactively, and can be used to delineate ranges of data. Interacting with these plots can be control some details of how the main data is displayed. If the mouse is moved over the graph its background goes opaque to show that it is now the active part of the screen, and the scroll wheel now controls zooming in on the data plotted just under the mouse. Enabling axes (usually using command-G) will add an X-axis to the graph, and dragging with the left mouse button down will pan a zoomed graph in X, following the mouse. Limit lines in the graph (drawn in orange) can provide additional information, and can be picked up with the mouse and dragged to affect the display of the main data. How the limit lines work depends on the type of plot being displayed.
Two types of such plots have been implemented:
- Plots of the summed data for each plane of a data cube (within the high-lit area) versus plane coordinates (this only works if a data cube is being displayed). These are switched in using the new "Show graph through planes" option in the Selected Area Control panel. In this case the limit lines in the graph show the range of planes in the cube currently being displayed, and dragging the lines changes this range.
- Plots of the histogram of the data in the main data array. These are controlled by the new Data Histogram option in the File menu. If an area of the main data has been high-lit, then it is the data in this selected area that is histogrammed, otherwise all the data is used. The limit lines in the plot now match the low and high displayed data limits, and dragging these will change these directly. This is a rather nice interactive way to set these display limits.
The File menu now has a 'Data histogram' menu option, as mentioned above.
The Scale Control panel now has a 'Show graph through planes' check box, also as mentioned above.
A number of small changes, mainly to improve the facilities available through the socket interface, to make it easier to generate reproducible effects for use in presentations. Some of these socket commands were introduced earlier on a tentative basis, but have now been documented properly in the section on the socket interface. Look in there for the full list - there are too many new ones to list here.
Implemented a fix to the surface generation code that has the efect of reducing the a number of times the displayed surface is regenerated when zooming in and out. This makes zooming somewhat smoother.
Dragging with the mouse down in the highlit area no longer changes the orientation of the display if the mouse is moved quickly enough that it escapes the highlit area before it gets redrawn. (This was a rather irritating bug.)
Continues (and pretty much completes) the re-working of the code to reduce the system-dependent part to as thin a layer as possible. The text drawing code has all been completely revised, and no longer uses the Apple-specific GLString code. Instead, the FTGL font library is now used for all text output. The result is not quite as pretty as that from the original Apple code, but the difference is hard to spot and could be improved further by the use of textures instead of pixmap fonts if anyone felt the improvement was worth the effort. At the same time, quite a bit of work has gone into commenting the code properly, and while this is not yet completely satisfactory, it is probably close enough that I can release the source without feeling too embarrassed (but it needs a bit of housekeeping to sort out which files are actually needed for the release).
Some slight text-related changes as a result:
- The help text box no longer appears in the center of the display when the program starts up. It was no longer particularly helpful, really.
- The rather esoteric information box that used to appear at bottom left of the screen has also gone.
- The program name and version number is now displayed at startup. (Leave it ten seconds and it gets replaced by a sweep of the characters 'AAOGlimpse' around the screen. This was put in to test the font code, but I decided I liked it.)
- The string describing the coordinates and data of the pixel under the mouse now disappears when the mouse is moved outside the bounds of the image.
- The camera position string has a different format and is now the only text affected by the command-I (show info) option.
- The presentation of the coordinate and data info and the camera format is slightly different, but you have to look quite closely to see it. (The font is different, the background is solid black instead of opaque, and the corners of the bounding box are no longer so elegantly rounded.)
- At last, if there is an error opening a file, error text appears in red describing the error (not with much useful detail, but at least you can see there was an error).
- Command-C no longer produces a detailed list of the system's
OpenGL capabilities (technically interesting, but not really
needed, and very system-specific).
- The panning algorithm has been fixed so that the image moves nicely with the cursor at all magnifications.
- The commands used in the socket interface are all now
A serious restructuring of the higher levels of the code to split them into a large system-independent part (the DisplaySupervisor code) and a much smaller system-dependent part. This is a necessary precursor to ports to systems other than Mac OS X. However, at present, there is only an implementation of the system-dependent layer for OS X.
Version 0.75 should be functionally the same as 0.7, except that:
- The new code makes very little distinction between the main and the secondary data, except that one is loaded in response to the 'Open' menu item and the other in response to the 'Open secondary' menu item. Previously, there were a number of operations that only worked properly if the main data was being displayed, but now these should work on either data set. If you select an area using the cursor while the secondary data is displayed, for example, this now works, and you can have separate selected areas for the two data sets. The low clipping setting operates independently for the two displays. (Internally, the code has been written to allow for multiple data sets, not just a main and a secondary, but the user interface makes no use of this. Yet.)
- The bug where the display broke up while the window was being resized and then redrew properly only when the mouse was released has been fixed.
- There will probably have been bugs introduced inadvertently by the restructuring that haven't been spotted yet, but if I knew what they were I'd have fixed them. Let me know - ks at aao.gov.au - if you spot any.
And there were a couple of new features added:
- A limited full-screen mode is now supported. It is entered using the 'command-command-F' key combination and exited from using the escape key. In full-screen mode the user interface is limited, as the menus are not available, and so new images cannot be loaded. Only key commands or commands read from the socket interface are accepted.
- A new socket command, 'animateTo' allows quite precise control over changes to the way the displayed data is viewed. It specifies a new orientation, central position, zoom factor and the time over which the program should move to this new view. The view of the data will change smoothly from its current parameters to the new parameters over the specified time. It isn't an easy command to use - you need to understand the viewing parameters - but it can give some nice (and easily reproducible) effects, particularly for demos or presentations.
Much improved handling of large data sets:
A significant reworking of the internal code that handles the calculation of WCS values in order to speed up the opening of large data cubes and to reduce the amount of memory used to hold the coordinate values. Instead of holding X,Y and Z coordinate values for every single pixel in the data (which meant that the memory used for coordinates was three times that used for the data itself) the code now runs a quick pass through the WCS coordinates to see how they change and only allocates the minimum amount of memory needed. For example, if the X and Y values are the same for every plane of 3D data, only a single 2D array is needed to hold the X and Y values. If the Z values are the same across each plane, a 1D array will be enough to hold them. The downside is that the code to access the coordinate values as the data is surfaced is now more complex than the simple 3D array look-up it used to be, as it has to check how the coordinates are being stored. But this is a worthwhile trade-off - the new code is still much faster than calculating the coordinate values on the fly.
Added the option of surfacing by 'cubes':
By defaut, AAOGlimpse produces its display surfaces by drawing quadrilaterals between the centers of groups of four pixels. This means that the number of surface elements generated for an image is equal to the number of pixels in the image (strictly slightly less, because of the way the edge pixels are handled). It would be more 'traditional' (is that the right word?) to have drawn individual cuboids for each pixel, but this involves generating three times as many surfaces. However, particularly for images with very few pixels in one or more dimensions - a set of a small number of spectra, for example - the cuboid surfaces do seem to look better, and this has now been added as an option. It is a slower option, however, particularly when there are large number of pixels involved, because not only are there more surfaces to be generated, but the calculations for the vertices are more complex.
User interface changes:
- A 'surface by cubes' option has been added to the 'File' menu. This toggles on and off the option of surfacing using cuboids rather than single quadrilaterals. (It should be 'cuboids', but that didn't look right.)
- A 'square pixels' check box has been added to the scaling control panel. This affects the scaling of the display when there are far more pixels in either the X or Y dimension of the data than in the other. The default is to make the pixels square, maintaining the aspect ratio of the image. However, for data sets such as sets of spectra it makes more sense to stretch the smaller dimension so that the whole surface is square. (It would be nice to be able stretch the display in a continuously variable way, and this may be added later.)
- When the main image was 3D and the secondary image was 2D, the second would not display properly even if the two had the same XY coordinate range. Now fixed.
- Data and coordinate values that are very large or small are
now displayed using exponential notation - some test data had
been showing a display range of 0.00 to 0.00 just because the
numbers were much smaller than I had allowed for.
(The main delay now in the handling of large data sets comes from the time taken to scale the data for display, and this is under investigation.)
Implementation of a 'plug-out' scheme for running utility tasks from AAOGlimpse:
On startup, AAOGlimpse looks for a 'Glimpse' sub-directory of the user's home directory. Any executable file in there with a '.glimpse' extension is treated as a 'plug-out' program that can be run from AAOGlimpse. An item for each such file will be added to the new 'Plug-outs' menu and can be run by selecting that menu item. Any program at all can be run in this way - shell scripts, python programs, etc. The idea is that any such program will use the socket interface to interact with AAOGlimpse to get the required effect.
More revisions to the highlit area selection code:
- The highlit display can now be shrunk down to a line, in which case the cursor controls operate slightly differently but allow it to be rotated and expanded and translated.
- The plot display code has been revised and sped up. It no longer has the sampling effect where the signal gets noisy at 45 degree values for the rotation.
- The selected area control panel now allows the highlit area parameters to be changed as well as displayed.
- The first time a highlit area is selected with the mouse, the control panel is automatically displayed. (Really, just to show the user that it exists; from then on they can hide it if they want, and get it back using the window menu when needed.)
- Feedback has been improved for the scale GUI - the data max and min scale values are now updated in the GUI when the percentile value changes.
- For large data sets the percentile scale calculation uses random sampling to estimate the data range. The random number generator is now initialised with the same seed each time, so the same percentile value will always return exactly the same estimated range for the same data.
- The 'snap to face on' algorithm has been improved. It now works for all faces of the data, and will snap to the closest of 24 possible orientations (6 faces for the 3D data, each with four possible orientations - up, down, right and left).
- The 'shift-f' key combination now returns to the previous data rotation setting following a 'snap to face on' and so can be used as an 'undo' for the 'snap' operation. (This was added for debugging purposes and may not remain as a feature.) There is also a new socket command, 'worldRotation?' but this is definitely only intended for debugging purposes.
- Display is now much, much, faster when a 3D data set is
displayed exactly face-on in the XY direction - ie when
looking directly at either the first of last of the data
planes (the code no longer generates surfaces for the planes
that cannot be seen). This makes the operation of the up and
down arrow keys much faster when 'flying' through the planes
of a data set - so long as you have it face on.
- The operation of the shift key with the up and down arrows has been reversed - the most common use is to remove or add to the high numbered planes (the ones displayed by default) and this no longer needs the shift key. The shift key now causes the up and down arrows to operate on the other end of the data cube - the low numbered planes.
- The position readout is now updated when the up and down
arrow keys are used to fly through a set of planes, so the
plane number (the Z value) updates properly as the planes
A large amount of internal re-working of the code that allows you to select an area with the mouse. A lot of the work for this release was intended to support one particular application: we wanted to be able to read in images from an optical test setup and interactively try to select the ellipse that best fitted the peak in the image. Because these images were most conveniently available as JPEG files, the ability to read JPEG images was added. Because we needed to be able to draw an ellipse around a feature in an image and expand and rotate it interactively until it matched, the whole of the code that allowed an area of the image to be selected using the mouse was re-worked. Adding the ability to read JPEG images led to the introduction of a number of experimental features for playing with these, although not all of them are likely to remain in the production code. All in all:
- The 'open' file menu command will now allow files with .jpg or .JPG extensions to be opened.
- There is now a 'show selected area panel' option in the Window menu which brings up a control panel for the hightlit area.
- The highlit area can now be moved, expanded and contracted, and rotated using the mouse.
- The highlit area display can now optinally display the enclosed ellipse and cross-hairs.
- The selected pixels can now be dislayed independently of the highlit area.
- The plots through the highlit area now include data from all planes of the image, not just the top surface plane.
- The highlit area is now drawn just by shift-dragging. Shift-click-dragging was too awkward to coordinate.
- Left-click dragging when in the highlit area now adjusts the highlit area. It does not tilt the surface - I kept tilting the display away from the 'face-on' position when all I wanted to do was move the highlit area.
- The spike filter code has been parameterised so it can remove larger features - such as foreground stars in galaxy images - but at the moment the only way to invoke it with other than the default parameters is through the socket interface, using the new 'sigmaFilter' command.
- The socket commands 'subtractFromData', 'invalidateBelow'
and 'invertData' have been added. These have been used to do
some experimental manipulation of JPEG images, and may not
remain in later versions.
Added drawEllipse socket command.
An earlier change had led to cut plots being drawn with too thick a line as an unwanted side effect. Now reverts properly to thin lines.
It's no longer so critical to press the shift key before clicking the mouse in order to start a selection. You can now press the shift key after clicking the mouse, so long as the mouse hasn't actually moved. This makes starting a selection rather easier.
The selectPixels socket command no longer ignores the z values. Values set to zero (not a valid pixel number, as they start from 1) are treated as unspecified.
Internally: Code for drawing the collapsed data plots has been reorganised and simplified, ready for a substantial review of how the selection code itself operates.
A number of bug fixes, most showing up in testing with DSS images.
- Contours are now calculated using the full 2D coordinate data, rather than carelessly assuming that all rows had the same set of X-values and all columns had the dame set of Y-values. In particular, this was affecting DSS images.
- Minor improvements to the axes: extraneous out-of-range grid lines no longer appear; grid now covers full extent of data when pixels are not aligned with the coordinate axes.
- Fixed a bug causing an occasional crash when the selected range exceeded that of the data.
- The way coordinates are scaled has been changed with the aim of improving the way the program handles data where the pixels are at an angle to the coordinate axes, such as in some DSS images. A side effect is that all axes now have coordinates increasing in the left to right or bottom to top directions, if necessary inverting the pixel order.
- 'Create new from subset' was not always able to display the newly created subset. This bug was due to it not calculating the correct number of axes for the data, but only showed up as a result of the recent changes to limit the number of displayed surface elements.
- The calculation of which pixels are visible in an image (ie allowing for zoom and panning so that only those actually visible need to be included in the displayed surfaces) now handles the case where there are two images visible with quite different coordinates. (Previously, a gap would suddenly appear between what should be overlapping DSS images as you zoomed in on them.)
- When two images are displayed together (the '3' option) colour and scale selections now apply to both.
- One minor bug fix. Version 0.5 had a coding error in the new, faster, WCS code that caused occasional crashes when releasing workspace after opening a file. This should now be fixed.
Basically, faster, more flexible when working wth two images, and with more control over how data cubes are displayed.
- The program is now much faster when displaying large images or data cubes. It now only displays up to a maximum number of surface polygons, rather than one for every pixel in the data. If all of a large image or cube is being displayed, the program selects a subset of pixel values for display - it takes the largest pixel value out of all the pixels that could be used for a point, which means that spikes in data show up and don't fall between the cracks. (In time, I'll provide other options, but this seemed the best for the moment.) As you zoom in, the program starts to use all the data in the visible area. There are occasional pauses as it recalculates which pixels to use, but generally these are unnoticeable. (And much better than the slow running as it tried to display everything.)
- The ability to limit the display to the selected area can make things run faster as well. (See below.)
- Calculation of WCS coordinates is now much faster when a file is opened.
- The surfaces menu item has been added. (This is mainly to make it easy to display the contours from one image and the surface from another - you disable the surfaces in the one and enable its contours, do the reverse for the other and display them both together.)
- The scale panel now displays correctly the settings for the currently displayed image when a main and secondary image are being displayed. As you switch from one image to the other, the scale panel now shows the right data (when both are displayed it shows the data for the main image only).
- The surfaces, axes, contours, and wires menu items now apply separately to each of the main and secondary image, so you can disable the main image surface, for exmaple, by making sure it is the one displayed (use the '1' key) and unticking the surface menu item. And the ticks on them change as you switch between the main and secondary images - although it should be obvious what's being displayed!) (You can enable axes for both images, if you really want to, and the rather gimmicky use of '+' and '-' to move the axes up and down works on each separately, so you can get two vertically displaced axes shown. I can't think why you'd want to do that.)
- The way two images can be displayed has been revised. The '4' option for displaying the contours of one and the surface of the other has been dropped now that the menu items and the scale panel can be used to get the same - and other - effects more flexibly. You can get all the possible combinations of contours, wires, surfaces (yes, and axes) by setting up what's displayed for each image individually, using '1' and '2' and then display the combination using '3'.
- The command-F combination (or 'snap to face on' menu item) now work for the front, left, right and back faces of a data cube, and the cursor can be used to select an area from any of these faces. This finally provides a way of selecting a range of planes for display (without needing to use the socket interface). The top and bottom faces have to handled slightly differently and I will add that soon. The plot of data as you select an area (the horizontal and vertical summed cross-sections that you see) don't appear for the side faces. (I'm not quite sure just what to display there.) Note that when you display a side face many planes don't show up - you get a 'beating' effect with the display pixels, and this can look odd. Turning 'wires' on will outline each plane, but if you have a lot of planes all you get is a solid red rectangle!
- You can now clip the display at the selected limits using the 'Display only selected data' File menu option. You can revert to displaying the whole of the data using the 'Display all data' menu option. The less data is displayed, the faster the program runs. This is particularly useful for 3D data, where it can be used to select a range of planes for display. (The readout of cursor position and data under the cursor still works for the undisplayed data, by the way, so you can still see a changing readout when outside the displayed image so long as you're still within the whole of the data. I'm not sure if that's useful or not.)
- The up and down arrows now can be used to 'peel-off' planes from the front and back of a data cube. Hold a arrow key down and you get a 'fly-through' effect, with the top (or bottom) plane constantly changing. The shift key controls whether the top or bottom plane is peeled. It helps to select a subset of the planes first, because this makes the fly-through faster.
- The code is slowly being re-organised so that the system-dependent (in this case, Mac OSX dependent) code is concentrated in one small module. But it isn't there yet. There is one new socket command 'setWorldRotation', but this is purely for diagnostics and is far too esoteric to document here. (It changes the orientation of the displayed surfaces.)