iraf.net

Hello (Steve?....Suzanne?):Is it possible to have more than one SAOimage process running on a machine
at the same time? My problem is that I have more than one user using their
local machines as a X-terminals, rlogging into the "fast" machine and starting
a "cl" session and an SAOimage with the display variable set to their local
machine. The first person that does this has no problem displaying things
on their SAOimage, however, subsequent users are unable to display a thing
even though an SAOimage window appears on their local machine. Any ideas? Thanks for your time.Bob (thomas@naic.edu)

Hello Bob, Right, there is contention for the single set of fifo pipes if
more than one user per CPU attempts to run SAOimage. This was discussed
in IRAF Newsletter #11, April 1991, "Setting up Multiple Fifo Pipes for
SAOimage". The solution is for each user to have a private set of fifo
pipes as described in the article. You can retrieve a copy of the newsletter
from our network archive if you can't locate a hardcopy.Suzanne

Would you have any insight on a problem I
am having with saoimage, or actually someone else
here is having the problem. We have a Decstation,
running Ultrix and Motif. We have a fits image,
bitpix=-32, simple=T. If I use rfits in IRAF and then
display the IRAF image using saoimage, all is fine.
However, if I try to display this particular fits
image with directly with saoimage, the display fails,
saoimage thinks the data values range from e-32 to e32
and the image does not appear at all to be what it should
appear to be. There seems to be a problem with saoimage
when it reads 32 bit fits files directly from the disk.
I feel confident that there is nothing wrong with the
fits file in question since I can read it with rfits
and display the corresponding IRAF file with saoimage.
I have tried to use the -dfits switch and the -bswap
switches, to no avail. Also I have tried using
saoimage -skip 2880 -r4 fits_file, and this also fails?
Is there a documented problem with saoimage displaying
32 bit fits files on dec machines?Thanks, Robert

Some expereimentation here seems to
indicate that saoimage which comes
with the iraf expects FITS images
which have real numbers to have
vax floating point format, not the
iee floating point format which I believe
is the FITS standard and is the standard
for the mips processor on decstations.
Do you know if this is the case, and if so
wouldn't this really be a bug? Is there
a version of saoimage which adheres more
strictly to the FITS standard?Thanks, Robert

Hi Robert,
I can duplicate the problem you report on our DECstation here. Your
second message pretty much nails down the problem: It's not so much that
SAOimage is expecting vax floating point, rather, it will not convert the
numbers it reads from the image (IEEE in this case) to the native format
for the machine. This is mentioned in the "-fits" option description in
the SAOimage man page.
This isn't really a bug as much as it is an oversight, it should
be fixed (along with many other things). However, SAOimage will soon be
replaced by our own X display server and so this change will probably be
pretty low priority. In the meantime you could read the images into
IRAF format, or even write a small program using the ftoi(3) routine to
convert the FITS files (or make the hack to SAOimage yourself). If this
is really a problem for you let me know and I'll try to make the fix
sooner.Regards,
Mike Fitzpatrick

Hello Les -SAOimage was distributed with the VMS/IRAF V2.9 release. Look in the
[iraf.vms.x11] directory. There you will find the executables for SAOimage
and for XTERM (the VT102 and Tektronix 4014 emulator for the X window
system).A newer version of SAOimage can be found in our network archive. % ftp iraf.noao.edu (140.252.1.1)
ftp> log in as anonymous
ftp> use your username as the password
ftp> cd iraf.old
ftp> get readme.saoimage
ftp> exitIf you have further questions or any problems please let us know (send
mail directly to iraf@noao.edu).Please note that VMS/IRAF Version 2.10 is now in testing - I would expect
this new release to be available by the end of the year.Jeannette Barnes
NOAO/IRAF

Hi Terry,
Jeannette passed your message on to site support. The error messages
indicate that you don't have X11 installed on your system (or it's improperly
installed). It appears that the directory /usr/include/X11 (and presumably
/usr/lib/X11) are missing. On our system X is configured as follows:pisces> ls -l /usr/include/X11
1 lrwxrwxrwx 1 root 18 Jul 8 16:34 /usr/include/X11 -> ../x11/include/X11which means that X is really in /usr/x11. If you'd rather not mess with
installing X again I've put the saoimage executable in our ~ftp/pub directory
(on machine 140.252.1.1) named "saoimage.sparc" (be sure to transfer it in
binary mode and reset the permissions so it's executable before you install
it. Let me know if you have any other questions.Regards,
Mike Fitzpatrick

Dear IRAF HOTLINE: Here are a few preliminary questions that I have concerning SAOimage.
I downloaded the file SAOIMAGE.BCK via ftp from iraf.noao.edu, and extracted
the files.
1) The files contained in the subdirectories [.BTNLIB], [.DEFS],
[.DOC], [.HFILES], [.PANEL], and [.VMS] are missing. Where can I get
these files?
2) When I run the file SAOIMAGE.EXE extracted from SAOIMAGE.BCK,
the following error results:
%DCL-W-ACTIMAGE, error activating image DECW$TRANSPORT_COMMON
-CLI-E-IMGNAME, image file DKA0:[SYS0.SYSCOMMON.][SYSLIB]
DECW$TRANSPORT_COMMON.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
It would be nice to be able to relink this executable, but the necessary
files are missing.
3) When the copy of SAOimage provided on the IRAF tape is launched, the
message "Could not open font: 6x13" is displayed.
4) If the etc and new buttons are clicked, the message "Could not
open font: 9x15" is displayed.
5) When the command -gd <width>x<height> is given, values greater than
512x512 are ignored. Sincerely, Donald H. Gudehus

Donald, Retrieve the saoimage.tar.Z file (not saoimage.bck) from the iraf.old
subdirectory in our network archive. The saoimage.bck file was created for
a particular user without a C compiler; I believe it was built under VMS 5.5
but don't really know the details. The readme.saoimage and saoimage.tar.Z
files are the standard way to get saoimage from NOAO. Running this newer
version of SAOimage should clear up the other problems mentioned in your mail.Suzanne

Donald, > In your archive I notice saoimage.v106.tar.z and saoimage.v107.tar.z. Is
> v107 the later and preferred one to retrieve? Also, what program do
> I use to extract the files and VMS directories from this archive?Version 1.07 of SAOimage is more recent but not much different from v1.06.
>From ~ftp/NOTES: iraf.old/saoimage.v107.tar.Z +
Added V1.07 of SAOimage. This contains only minor revisions needed
by the COLOR package. (10/14/92 MJF)I'd suggest getting v1.07 in case you ever want to install the COLOR external
package.You need to uncompress and then read (with rtar) the saoimage.tar.Z file as
described in readme.saoimage. You've already used the VMS uncompress utility;
the IRAF RTAR task can be run from the softools package or from DCL.Suzanne

Dear IRAF hotline: I transferred the file SAOIMAGE.V107_TAR_Z from you archive and
decompressed it with UNCOMPRESS. I next used the RTAR program to extract
the files. During this operation the following errors were reported.cannot create file `doc.txt/blinking.txt'
-rw-r--r-- 0 359 12 13783 May 8 02:54 1992 doc.txt/cmdline.txt
cannot create file `doc.txt/cmdline.txt'
-rw-r--r-- 0 359 12 2282 May 8 02:54 1992 doc.txt/color.code
cannot create file `doc.txt/color.code'
-rw-r--r-- 0 359 12 12174 May 8 02:54 1992 doc.txt/color.txt
cannot create file `doc.txt/color.txt'
-rw-r--r-- 0 359 12 10225 May 8 02:54 1992 doc.txt/cursor.txt
cannot create file `doc.txt/cursor.txt'
-rw-r--r-- 0 359 12 2576 May 8 02:54 1992 doc.txt/hardcopy.txt
cannot create file `doc.txt/hardcopy.txt'
-rw-r--r-- 0 359 12 5781 May 8 02:54 1992 doc.txt/keyboard.txt
cannot create file `doc.txt/keyboard.txt'
-rw-r--r-- 0 359 12 5300 May 8 02:54 1992 doc.txt/mouse.txt
cannot create file `doc.txt/mouse.txt'
-rw-r--r-- 0 359 12 2437 May 8 02:54 1992 doc.txt/pan.txt
cannot create file `doc.txt/pan.txt'
-rw-r--r-- 0 359 12 6310 May 8 02:54 1992 doc.txt/region.txt
cannot create file `doc.txt/region.txt'
-rw-r--r-- 0 359 12 22727 May 8 02:54 1992 doc.txt/saoimage.man
cannot create file `doc.txt/saoimage.man'
-rw-r--r-- 0 359 12 10051 May 8 02:54 1992 doc.txt/scale.txt
cannot create file `doc.txt/scale.txt'
-rw-
cannot create file `doc.txt/manual.aux'
-rw-r--r-- 0 359 12 92249 May 8 02:54 1992 doc.txt/manual.tex
cannot create file `doc.txt/manual.tex'
-rw-r--r-- 0 359 12 3783 May 8 02:54 1992 doc.txt/manual.toc
cannot create file `doc.txt/manual.toc'
-rw-r--r-- 0 359 12 1498 May 8 02:54 1992 doc.txt/manual.log
cannot create file `doc.txt/manual.log'I then attempted to build the SAOIMAGE program by using the MAKE.COM file.
After several minutes the program reported that the library
LIBBTN.OLB was in an illegal format. A DIRECTORY/FULL on this file indicates
that it is the record format is Stream_LF rather than a fixed length record. Please help. Donald Gudehus

Donald, You can ignore the error messages about not being able to create
files in the doc.txt directory. This directory (which wasn't included
in the v1.06 archive) maps to an illegal VMS name and results in the
error messages. The text files in the directory are useful however and
you can pick them up separately from the iraf.old archive directory. Get
saodoc.tar.Z. I'm told the problem with libbin.olb has been seen before and the
solution is to delete and restart the make.com. It will be built correctly
the second time. I'm not convinced of this, since saoimage.tar.Z is a
source archive and libbin.olb was not part of the distribution. Looking
around a V1.06 SAOimage directory on our VMS machine, I don't even see a
libbin.olb, only libsao.olb. Is libbin.olb in a subdirectory? If just
deleting the library and restarting make doesn't fix the problem, let me
know and I'll have to look into this further.Suzanne

Dear IRAF hotline,In regard to my previous inquiry about SAOimage, I successfully linked
by creating a new library, putting the object files in it, and retrying
the build command with the LINK option. However, even with
SAOIMAGE.V107, I still get error messages:
1) When SAOimage is launched, the message "Could not open font:
6x13" is displayed.
2) If the etc and new buttons are clicked, the message "Could not
open font: 9x15" is displayed. Sincerely, Donald H. Gudehus

Hello Donald, The fonts mentioned (6x13 and 9x15) are not "universal" X fonts and
do not come standard with DECwindows. SAOimage tries to use them (for reasons
not known to me), complains and then substitutes. We see the same messages
here. Since the missing fonts have absolutely no bearing on the functionality
of SAOimage, we've never tried to move them into DECwindows and get rid of the
error messages.Suzanne

Hi Mike,
Jeannette passed your questions on to me. > A. What is new in v1.07? My memory is fuzzy, but it seems to me that
> v1.06 is the most recent version that I haveV1.07 is only a minor modification of V1.06 to allow more colortable entries
required by the COLOR external package. We've recently uncovered some small
bugs but there aren't any plans I'm aware of to do any major work on SAOimage.> B. Do you have somebody there who worries about the bugs in saoimage?I guess most of these get routed to me. If you do any work or would like
something changed then let me know and I'll incorporate it in our version
for later release.> C. Is there an IRAF task which actually reads the colormap save file?
> If so, can I have more details? (There was an IRAF mail item about
> problems in IRAF when the colormap file contains negative values.
> - or was that a problem in saoimage?)Unless PROS does something with the save file I don't think anything else
currently uses it. The COLOR package I mentioned writes a colormap to be
read by saoimage. I think the negative colormap value mail was also re-
lated to the COLOR package but I can't find it now and haven't gotten a
reported bug that should be fixed. It may have been one of the mods that
was in 1.07 but I can't say for sure. We certainly have plans for an SAOimage replacement but I'm not sure
what the timeline is right now. A first cut at it will probably happen
fairly soon as part of our X11 support package but if things begin to drag
on we can certainly make some changes to SAOimage in the interim. I don't
think we can spend too much time on it but there shouldn't be any problem
getting bug fixes out.Cheers,
Mike Fitzpatrick

Dear IRAF's,I need the SAOimage v. 1.07 to run "color". I have ftp'ed
the version on iraf.tuc.noao.edu, but cannot "make install" it.
I get complaints like:---
Building btnlib/libbtn.a...
cd btnlib; make CFLAGS="-c -g -DDEBUG -DSUN -DPSCRIPT" CC=cc
make: Fatal error: Don't know how to make target `/usr/include/X11/Xlib.h'
Current working directory /b/usr/iraf/saoimage/btnlib
*** Error code 1
make: Fatal error: Command failed for target `btnlib/libbtn.a'
---which probably is due to the fact, that we run OpenWindows(3) and
not X11. I expect, that you have had the problem before, and that
there is an easy workaround. I would be happy for a slightly extensive explanation, because I
have had the problem before with i.e. xspec from gsfc, and have not
yet found a solution (we do run xspec, but not ximage).Otherwise - do you know where to get X11 - it could be considered an
alternative to OW3 here, although OW3 is the only windows program supported
by SUN.Thanks very much in advance,
best wishes
Allan

Hi Mike,Mike F. looks after SAOimage as he said. I can add a couple of
comments however. As Mike said V1.07 has just a couple of minor
changes to increase the maximum color table space to 256. This was
needed to allow one to specify all the colors directly. This is used
by the COLOR package to display a 24-to-8 bit dithered image.The problem with negative colormap entries was in a COLOR package task
that produces a color map FOR SAOimage as it behaved on a VMS machine.
The need to specify a range up to the full length of a short integer
requires some care which showed up when run on VMS. The connection to
SAOimage was that it correctly reported the error when attempting to
load such a color map.By chance I have recently been reviewing a document on IGI, the STSDAS
interactive graphics interpreter. They have added some support for
raster display. It mentions that input to it can include a color map
in the same form as SAOimage produces; i.e. it will use a color map
produced by SAOimage. This is the only program I am aware of that uses
the colormap save file.Cheers,
Frank Valdes