iraf.net

The following DECstation 3100/IRAF sites received information about
retrieving SAOimage and the readme file.

Billy Cooke Univ. of Florida
Steve Danford UNC
Gitta Domik CASA
Doug Gies Georgia State
Roberto Merighi Bologna
Earl O'Neil KPNO
Pat Seitzer ST

I'd like to get a copy of the beta release of SAOimage to run on our
Suns (3/260, 4/60 and 4/330) at the MIT Center for Space Research. Please
let me know how I can do so. Thanks.

I just read about the beta release of SAOimage in the latest IRAF
Newsletter (#8). We are in the process of converting from Suntools
to X for our windowing system, so we are interested in obtaining
SAOimage for use with our IRAF installation.We'll need full source; we're running Sun 3's and 4's (sparcstations).
(The sun 3's are still running OS 3.5; can SAOimage be recompiled for
this?)Please send distribution information. FTP is preferred, if it's
available; otherwise 1/2" tape is OK.Thanks,George C. Kaplan Internet: gckaplan@sag4.ssl.berkeley.edu
Center for EUV Astrophysics UUCP: ...!ucbvax!sag4.ssl!gckaplan
University of California (415) 643-8610
Berkeley, CA 94720

George,
You can retrieve the saoimage archive from tucana (192.31.165.1) via
anonftp (give your last name as the password). cd to the iraf subdirectory
(~ftp/iraf), and get readme.saoimage (text), and saoimage.tar.Z (binary).
I don't think anyone has tried building saoimage under SunOS 3.x, but chances
are it will work. I presume you're using MIT X11; apparently saoimage will
not run under the early X11/NeWS releases some people seem to have.
Also, the Makefile/irafinstall stuff hasn't been tested on a Sun, but it
should work. There is a makefile.sun that is guaranteed to work that doesn't
do the iraf part of the installation. You might want to use makefile.sun
anyway, because you probably have all the iraf installation files already
in place (/usr/local/lib/imtoolrc, /dev/imt1*) except for the global unix
symbolic link pointing to the saoimage executable; saoimage is treated the
same as imtool from within IRAF (stdimage = imtool).Steve Rooke (iraf@noao.edu)

Mark, SAOimage runs under MIT X11 but not under all versions of X11/NeWS.
And although the program was developed on a Sun, the Makefile
used for installation is untested on a Sun. We're interested in
knowing how your installation goes, so please contact us with
questions or problems.You can retrieve the SAOimage archive from node tucana (192.31.165.1)
with anonymour ftp, using your last name as the password. You'll want
to get two files from the iraf subdirectory of the ftp login directory:-rw-r--r-- 1 iraf 6312 Dec 27 13:47 /tmp3/ftp/iraf/readme.saoimage
-rw-r--r-- 1 iraf 632231 Dec 27 13:46 /tmp3/ftp/iraf/saoimage.tar.ZNote that saoimage.tar.Z is a compressed, binary file. Installation
instructions are in the textfile readme.saoimage.Suzanne Jacoby
sjacoby@noao.edu
5355::sjacoby or noao::sjacoby
(602-325-9364)
(602-323-4160 IRAF HOTLINE with an answering machine)

Mark, I've passed your V2.8 request onto Jeannette Barnes. She'll get in
touch with you if she needs further information. You can contact her directly
at jbarnes@noao.edu. Suzanne

I would very much appreciate receiving the code and documentation
for SAOimage, the version of IMTOOL running under X-Windows.
Note that I plan to use it for FIGARO, not for IRAF. Let me
know if this is a problem for you or anyone at SAO.
Thanks.Judy Cohen

Hi Judy, No problem using SAOimage with FIGARO instead of IRAF. The
software is available with anonymous ftp from tucana.tuc.noao.edu
(192.31.165.1). You'll need to get the following two files from the iraf
subdirectory of the ftp login directory. Note that saoimage.tar.Z is a
compressed, binary file. Installation instructions are in readme.saoimage.-rw-r--r-- 1 iraf 6312 Dec 27 13:47 /tmp3/ftp/iraf/readme.saoimage
-rw-r--r-- 1 iraf 632231 Dec 27 13:46 /tmp3/ftp/iraf/saoimage.tar.ZSAOimage can load image data from binary and FITS files, and via a datastream
protocol using named pipes (fifo's). IRAF uses fifo's for two-way
communications with the image server (identical in imtool & saoimage), but at
present the interface is best documented by examining the source code
(iraf*.c). This is basically the old IIS protocol with some extensions.
Note that additional information on the protocol is available in imtool.c on
a sun/iraf system in $iraf/unix/sun. The file "irafinstall" in the saoimage
directory demonstrates creating the fifo's and installing a copy of imtoolrc
where it is needed by saoimage at runtime.Let us know if you have problems or questions.Suzanne Jacoby
sjacoby@noao.edu
5355::sjacoby or noao::sjacoby
(602-325-9364)
(602-323-4160 IRAF HOTLINE with an answering machine)

Steve Rook:

Bradford, We haven't tried out Open Look or the new x11/news server yet, so our
only experience of X on Suns was with MIT X11, abominably slow. SAOimage
on DECstations is impressively fast; is it impressively slow on a microvax II
under Ultrix 3.x/DECwindows, though considerably faster than it was under X10.
So both the improved X server under DECwindows and the raw power of the
DECstation contribute to the great performance. Hopefully the improved
X server on a Sun3 will help, but still you're running a huge system (X11)
on a pitiful 3 MIPS machine... it helps to have *more than* 8 Mb memory,
like 12 or preferably 16 Mb, because X is a memory hog. Note that we will shortly begin working on porting IMTOOL & GTERM to X11.
IMTOOL itself will be evolving, and we expect this to be a preferable
environment for most IRAF users to SAOimage, which may be preferable to the
ROSAT Xray people. Since you are concerned about user interfaces, you ought
to get familiar with both IMTOOL and SAOimage. To get SAOimage, login to
192.31.165.1 as anonymous, enter your last name as password, cd iraf, binary,
get saoimage.tar.Z; get readme.saoimage. The instructions should be complete.
There is a minor problem with the colormap for Suns with NeWS, but there is
a workaround; mail included at end.> P.S. has anyone programming for IRAF considered the GBT approach (long
> live hexagons!)? No. I asked Doug Tody about it once, but he felt the advantages of
rectangular addressing (e.g. sequential line-oriented disk image storage
order) outweighed the hierarchical addressing advantages of GBT. At least
in optical astronomy we do very little with point/line/area world coordinate
addressing; it's almost all pure pixel stuff, which is certainly easily
handled with rectangular addressing. Perhaps it would be more appropriate
for planetary stuff, mapping riverbeds etc., or doing feature extraction.
Funny, I had another query from an old friend this week about GBT addressing.Cheers, Steve[ first message just for background; workaround follows ]Date: Thu, 4 Jan 90 21:03:48 EST
From: mvh@cfa241.harvard.edu (Mike VanHilst)
To: rooke@carina
Subject: Re: saoimage/NeWS/O.L. mail from vla
Cc: tcornwel@nrao.eduSteve,>> Bob Payne gave me your instructions on acquiring saoimage which I have
>> installed on my sparcstation. Everything went just fine in the
>> make, but I see from the documentation that saoimage will not work
>> with NeWS. We are running Openwindows here using the postscript window
>> manager (pswm) and the xnews server. IsFrom fitz Tue Aug 7 11:44:33 1990
Date: Tue, 7 Aug 90 11:44:29 MST
From: fitz (Mike Fitzpatrick)
Message-Id: <9008071844.AA28952@tucana.noao>
To: RPS346@maine.maine.edu
Subject: Re: RV installation
Cc: sitesScooter,
I neglected to say in my last message that it will be necessary to
remove the library compiled thus far (rv$src/libpkg.a and rv$src/x_rv.o)
and recompile from scratch after setting IRAFARCH and FLOAT_OPTION to
avoid the same errors.
-Mike).The ICCCM protocol describes how the color map switching should
be done. All applications, scientific and publishing, should be
able to ask for, and, if necessary, create the color map they want.
It is not difficult to implement. But it only works for ICCCM
compliant window managers, which, until recently, was a small
minority. Otherwise, all bets are off.Personally, unless one is doing desk-top publishing, I see no
good reason to use the NeWS window manager. It makes all your
scientific applications go "technicolor" on you, which I find
disconcerting. I like to be able to see the image, view any
graphs and read from text windows all at the same time.ICCCM compliance is appearing in most new window manager releases.
I will be adding the necesary code at some point. This should solve
the Convex problem as well. Meanwhile, there's always the "-p 1"
switch. (In Beta form, there was a way to run the Sun server without
pswm and with the MIT default color map. I don't know if that is
still the case). MikeDate: Mon, 8 Jan 90 08:13:22 MST
From: rooke (Steve Rooke)
Message-Id: <9001081513.AA29766@tucana.noao>
To: sites
Subject: xnews/colormap mailDate: Fri, 5 Jan 90 08:37:00 MST
To: mvh@cfa241.harvard.edu
Subject: Re: saoimage/NeWS/O.L. mail from vla
Cc: rooke@carina
Thanks for your message concerning Saoimage and xnews. Meanwhile we have
found that xnews can be forced to allow a pseudocolor color map by setting
USE_MIT_VISUALS=1 before starting it up. Saoimage then runs with the expected
behaviour. Thanks, Tim Cornwell

HIWhere are the coordinate files created when one uses the cursor
command in SAOimage? Also what are the frame buffer names?
These files do not appear anywhere I expect, but the coordinates
are repeated in my X console window.
I assume SAOimage still only stares, and does not blink.Thankscarol c

Hi Carol -Have you found the on-line manual pages for SAOimage? Check in
saoimage.doc. There is quite a bit of info on the capabilities of
SAOimage there.If you are marking positions within SAOimage then you must save the
coordinates with the "write" option in the "region" (?) menu (I do
not have SAOimage running in front of me so I am winging it!). At that
time you give it a path name and filename. I do not think anything is
saved unless you do it explicitely. (See the manual pages "region.txt".)One can also mark coordinates using the IRAF task "rimcursor" and simply
redirecting the output, ie rimcursor > coords.I am not sure what you are asking about the "frame buffer names"?
That may be something you are prompted for if you are running standalone
which I have never done. You may want to search through the manual pages
for help on that question or check with Mike VanHilst at CfA.If you are using SAOimage with IRAF then you display a frame with the
tv.display task and no matter what "frame number" you enter in this
task it always displays in the same frame.SAOimage does have a blink mode - you must save the frames to be blinked
with a mouse key and the "blink" option - see the on-line manual pages
for details (blinking.txt).Hope this helps a bit. Jeannette Barnes
NOAO/IRAF

Hi, I thought I should tell you that I got a copy of SAOimage (off Tucana,
I was getting the rv package and it was just sitting there .... :-).
I'm running it on a VAXstation running VMS and DECwindows, and so far,
so good. I have had to do some modification on the bitmap to postscript
routine to get it to work with my apple laserwriters. Are you (or anyone
else) interested in knowning of modifications I make or problems I run
into? I'm new at what to do with "beta releases." By the way, I'm
very impressed, and (don't tell Nigel) it almost looks better than uisdisp. - Tony Ferro, ASU computer guy.

Tony,
Thanks for letting us know, we like to keep track. The interaction
of saoimage with iraf part of the vms/saoimage distribution is temporary
-- did you modify zfiogd etc. as in the vms installation? We haven't
tested that here, it was developed at stsci and hasn't been integrated
back into iraf yet (you can run saoimage standalone or with iraf 2.8 tasks
using mailboxes for communication). Yes, please communicate any changes you make, bugs & fixes etc., to
Mike VanHilst at CfA, the author (mvh%cfa241@harvard.harvard.edu), with
a copy to me for reference.Steve (rooke@noao.edu)

Hi Mike,In addition to being an IRAF programmer here at NOAO, I maintain a
package called FOCAS. It was written many years ago to use an IIS
image display. Some of that experience may be come through in some of
the ways IRAF talks with the IIS protocol since I did some early work
on it. Anyway, with the advent of IMTOOL as a more common image
display I modified FOCAS to talk to IMTOOL. This was relatively easy
since IMTOOL uses the IIS protocol also. Recently there has been some
interest in FOCAS on machines other than Sun; i.e the Decstation. So I
am trying things out with SAOimage. I have found an error (?) or at
least something which conflicts with the IIS protocol in the file
irafimtool.c. I don't know why it is done this way but the problem is
that a call to the FEEDBACK subunit: case FEEDBACK:
/* The IIS feedback unit is used to clear the screen */
bzero(buffer.filebuf, buffer.filebuf_sz);
if( buffer.filebuf != (char *)buffer.shortbuf )
bzero((char *)buffer.shortbuf, buffer.shortbuf_sz * sizeof(short));
map_dispbox();
disp_dispbox();
/* clear the panbox */
bzero((char *)buffer.panbuf, buffer.panbuf_sz * sizeof(short));
map_panbox();
disp_panbox();
#ifdef IRAF25
#ifdef OLDMODE
mark_clock = 1;
#endif
#endif
/* this must be a new start, so reset everything just in case we haven't */
imtool_newimage(0);
#ifdef IRAF25
#ifdef OLDMODE
/* throw in a little gimic, a clock to note packets */
inc_dial_counter(1, packet_ref);
#endif
#endif
break;calls imtool_newimage:/*
* Procedure: imtool_newimage
* Purpose: Reset buffer sizes, coordinate systems and parameters as
* needed.
*/
void imtool_newimage ( is_wcs )
int is_wcs;
{
int fbconfig;
int cols, rows;
int get_fbconfig(), update_wcs();
void set_disptran(), combine_transform(), set_edges(), set_dispoff();
void adjust_cursor_coords(), set_magnifier(), disp_subpiece(), set_tdisp();
void set_imtool_scale(), imtool_reinit();
static int get_frame_no(); /* set size and frame */
if( is_wcs )
fbconfig = (imhead.t & 077) + 1;
else
fbconfig = (imhead.tid & IMT_FBCONFIG) + 1;The last statement shows that if the FEEDBACK subunit is used to erase
the framebuffer, the fast way to do it with an IIS, then the frame buffer
configuration is keying off the transfer ID. However, for an IIS the
transfer ID contains needed stuff. In my program what happens is that
anytime I erase the screen I lose the frame buffer configuration I want.
I modified my code to pass the configuration in the tid when talking
to IMTOOL/SAOIMAGE but it seems you are doing something which is not
part of the defined protocol.By the way, it looks like SAOIMAGE will be useful with FOCAS except that
FOCAS likes to use several frame buffers, such as when comparing
object catalogs from several bands, which is not supported by SAOimage.
I guess this is a plug for multiple frame buffers as they are really
used in astronomical applications.Yours,
Frank Valdes

Hi Mike,Sorry I was was so wordy with my last message; it was the end of the
day. Your confusion is, of course, due to the lack of a defined
interface protocol which we will have someday! It is also due to the
hardware specifics of the IIS protocol; i.e. things like subunits. The
IIS protocol is defined but not many people are likely to have the
required documentation. Anyway there are extensions for capabilities
not in IIS and IIS commands which could be sent a server which are
meaningless. The main server extension is for WCS. Basically,
anything having to to with the framebuffer configuration must come with
the WCS subunit (something not in IIS). Thus, the only way to make a
WCS/framebuffer change in the server should be when the WCS subunit is
seen. You may be confused about erase because in IMTOOL when a frame
configuration change is made the simplest thing to do was probably to
initialize to a clear frame buffer. Note it could just as well have
been to transfer the current data into the larger or smaller
framebuffer. Logically a frame buffer change is DIFFERENT than an
erase request. A frame buffer change may occur only once or even not
at all during a session but an erase request should be a common,
simple, and fast command. The erase command is less than obvious
because in the IIS is implemented using the FEEDBACK subunit, a frame
rate repeat op on each pixel effect. It would be more obvious if there
was an ERASE subunit command. For the server the FEEBACK subunit is
simply an erase request. The frame to which the command/subunit
applies is generally passed in the z register (the IIS becomes more
complicated because there are graphics channels and bitplanes which can
be independently addressed). For a one frame buffer server it makes
sense to simply ignore the frame number (z register). I would prefer
this to a noop since a program written for several (hardwired in code)
frame buffers, like FOCAS, may still be useful with one frame buffer.
The transfer ID contains I/O info about data packing, read/write, etc.
and does not contain data such as frame configuration, which is what
caused my problem; my IIS derived code was sending stuff about I/O with
the FEEDBACK command which was being interpreted as a frame
configuration change. I hope these comments help.As I'm sure you have been told, SAOimage is a good program and an
important addition to software for the astronomical (and broader)
community. Your adaptation to IRAF, despite the kludgy nature of the
prototype interface, is very much appreciated.Yours,
Frank