AAOGlimpse recent changes
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 probaby close enough that I can release the source without feeling too embarassed (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 exacly 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.)