Displaying images with the same scaling

If like me you often want to produce a plot containing several images all scaled to the same limits, you may be interested in a new feature in KAPPA:DISPLAY that simplifies this. Setting the MODE parameter to "Current" will now re-use the scaling limits that were used on the previous invocation of display.  No need to copy and paste the limits any more... As an example:

% gdclear
% picdef mode=array xpic=3 ypic=1 prefix=pic
% display map1 mode=per percentiles=\[2,98\]
% picsel pic2
% display map2 mode=cur

% picsel pic3
% display map3 mode=cur

will display map1.sdf on the left with 2% of pixels set to pure black and 2% set to pure white. It will then display map2.sdf in the center and map3.sdf on the right, using the same scaling that was used with map1.sdf.

Getting hard-copy graphics from Starlink apps

Most of you will already know that the Starlink KAPPA package provides many tools for producing useful graphical output (linplot, display, contour, etc.), and for dividing up the plotting space into "pictures", each of which can hold a separate plot (picdef, picsel, etc.). Multiple plots can be stacked on top of each other, so for instance it is possible to overlay a contour plot on an image, or to overlay multiple line-plots. However, how easy it is to do this depends on the graphics device you are using.  Using "xwindows" is straight-forward, but relies on taking screen-shots for hardcopy, which for some purposes is not good enough. Using PostScript devices produces high quality hard-copy, but is awkward because each KAPPA command produces a separate PostScript file. The user then needs to combine all the individual PostScript files into a single PostScript file.

The current development Starlink system introduces some new features that make using PostScript much easier. If you use kappa:gdnames to list all available graphics devices, you will see some new entries:

% kappa % gdnames The following graphics devices are available. The first column holds the GNS names, and the second the equivalent PGPLOT names (in parentheses). Either form can be used... png (/PNG) Portable Network Graphics file ... ... aps_p (/AVPS) Accumulating EPS, monochrome, portrait aps_l (/APS) Accumulating EPS, monochrome, landscape apscol_p (/AVCPS) Accumulating EPS, color, portrait apscol_l (/ACPS) Accumulating EPS, color, landscape ... ...

These new "accumulating" devices produce a single Encapsulated PostScript file (pgplot.ps by default) by accumulating the PostScript output automatically from subsequent Starlink graphics commands - no need for you to merge them all together yourself into one file. For example:

% gdset /acps % okular pgplot.ps & % gdclear % picdef mode=array xpic=2 ypic=1 prefix=pic nooutline % display $KAPPA_DIR/m31 \           style="'colour=black,width=2,colour(ticks,border)=green'" \           mode=perc percentiles=\[2,98\] % contour $KAPPA_DIR/m31 style="'colour=red'" noclear mode=free \           heights=\[9000,11000,13000\] % picsel pic2 % linplot $KAPPA_DIR/m31'(,169)' \           style="'colour=black,width=2,colour(curve)=red'" % linplot $KAPPA_DIR/m31'(,180)' style="'+colour=blue'" noclear

produces a single PostScript file (pgplot.ps) containing the following two pictures:

But what is that "okular pgplot.ps &" command in there? Okular (see http://okular.kde.org/) is a PDF and PostScript viewer supplied with the KDE desktop in Fedora, etc. It automatically re-draw the display if the contents of the displayed file changes on disk. Combined this with these accumulating Postscript devices provides a scheme that is similar to the use of a traditional persistent X-window device, in that the display is automatically updated after each graphics operation completes. If you do not use KDE, your OS may provide an alternative PostScript viewer.

To use these new features, you will need to rsync /stardev from Hilo.

Fixing instabilities in the WVM

The JCMT's Water Vapour Monitor (WVM) was taken off the telescope between the 20130326 and 20130408 to improve instabilities with its performance. The WVM is now back on the telescope as of 20130409 and initial results are looking good.

Tau estimates during this time have been taken from the CSO's WVM. The CSO values are used by the map maker automatically when reducing SCUBA-2 data. If you have any concerns or questions regarding data collected during this time please contact your Friend of Project. Your Friend of Project can be identified using the following link:

http://www.jach.hawaii.edu/JCMT/allocations/