iraf.net

>From cooper@sn.dnet.nasa.gov Tue Mar 21 12:13:49 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: ximtoolHi Mike,
Is there some documentation available for ximtool? When I ask for
online help, my computer informs me that no help is available.
Bonnie>From fitz Tue Mar 21 12:16:28 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: ximtoolNot yet. The only thing we have so far is the "ximtool-info" file in the
ftp pub/v2103-beta directory that has some notes on usage. Some of the
rest you can figure out with experimentation. Is there something in
particular you were wondering about?-Mike>From cooper@sn.dnet.nasa.gov Tue Mar 21 12:18:39 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: ximtoolYes, I'd like to zoom in on an area, and change the appearance of the cursor
to a hairline or something, so I can see exactly which pixel I'm pointing at.
Also, is there keyboard control of the cursor? I'll download the document
that you have, anyway.
Thanks
Bonnie>From fitz Tue Mar 21 12:26:57 1995
To: cooper@sn.dnet.nasa.gov> Yes, I'd like to zoom in on an area,
Move the cursor to one corner of the region an hold down the left
mouse button. Drag it to the other corner of the region. Move the mouse
inside the box, hit the right mouse button and select 'Zoom'. The View
menubutton has an Unzoom option.> and change the appearance of the cursor to a hairline or something,
Hold down the shift key and hit the middle mouse button. The cursor
readback isn't updated during this however.> Also, is there keyboard control of the cursor?
Not at present.-Mike

>From cooper@sn.dnet.nasa.gov Thu Mar 23 12:23:06 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: FAQ #14.12Hi Mike,
I have this same problem sometimes - white letters - but I'm
not running openwindows, I'm running Xwindows.
Is there a similar workaround such as was mentioned in the
FAQ document?
Bonnie>From fitz Thu Mar 23 12:32:49 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: FAQ #14.12Bonnie,
OpenWindows is just Sun's version of the MIT X server. I just
checked and eol.jsc.nasa.gov has openwindows installed so you should be
able to use the same workaround. -Mike

>From cooper@sn.dnet.nasa.gov Fri Mar 24 15:11:10 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: trig functions.Hi Mike,
I noticed in the online help for HEDIT that it says that the trig
functions operatie in degrees rather than radians.
Is this only true inside that command?
When I did a
CL> = cos(18.35)
it returned the value 0.877795...
but the correct answer should be 0.94915 or so.
What gives?p.s. The thing yesterday didn't seem to work. I still got white
letters on a white background when I logged out.
Bonnie>From fitz Fri Mar 24 15:44:29 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: trig functions.Bonnie,
HEDIT is a compiled task that does an explicit conversion of the
angle from degrees to radians. The CL calls the cos() function directly
and assumes the argument is in radians. You'd need to do something like cl> =cos ((18.35)*(3.141592654/180.0))to get the right answer.> p.s. The thing yesterday didn't seem to work. I still got white
> letters on a white background when I logged out.
Something else to try would be the 'clear_colormap' command. Either
type this in when the screen is white or have this automatically executed
when X shuts down (e.g. have your sysadm put it at the end of the 'startx'
script).Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Tue Mar 28 12:05:19 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: wcslabMike,
Last year I was trying to learn how to use WCSLAB and getting really
wierd results. I think I understand why now.
The Clementine images, which have coordinates given in RA and Dec,
are looking back towards the earth (sort of) rather than looking
from the earth out into the sky.
I have the RA and Dec of each corner point of the image,
but I'm not sure that WCSLAB can help me get an
appropriate grid in this situation.
What would you suggest?
Bonnie>From fitz Tue Mar 28 13:19:06 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: wcslabHi Bonnie,
I can't really give you any specific recipe for this. WCSLAB uses
either the WCS information in the image header (your imported data doesn't
have any) in the standard FITS wcs keywords, or those values given in the
WCSPARS pset to WCSLAB that define the same thing. Even if these were
ground based images the WCS is defined typically as a center coordinate
with a scale/rotation and a projection type. This is discussed in the
wcspars help page some, a more detailed discussion of the wcs system in
iraf is in mwcs$MWCS.hlp (view it w/ "help mwcs$MWCS.hlp fi+"). Your images
are further complicated if you want to do a geocentric correction, but unless
you need astrometric accuracies I'm not sure this would make much of a
difference.
Looking at one of the images I see the RA/DEC keywords, as well as
a TWIST_ANGLE, in the test image I have the pixel scale keywords are blank
but this may be enough to give you the center and rotation, you may already
know the scale. You would have to convert these values to the correct
WCSPARS keyword values to get the right grid from WCSLAB. Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Tue Mar 28 15:55:49 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: wcslabMike,
Yes, I've gone through the exercise of setting the wcspars
parameters using the twist angle and the RA and Dec of the corner pixel
to try to get a grid on the image. The results so far are dismal.
Am I correct in assuming that the default Right Ascension is in
hours/minutes/seconds?
I'm getting some really wierd results.
If you like, I'll ftp a new image that has all the image header
data.
Bonnie>From fitz Tue Mar 28 16:33:31 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: wcslabBonnie,
I could fake up some numbers for the keywords here real easy but I
don't actually know what the keywords mean so it's not too useful. Also,
I'm no expert in the MWCS interface so I probably couldn't make much sense
of it anyway. My understanding is that the FITS keywords describing the
wcs (which IRAF uses) are in units of degrees (as per the FITS standard).
If you had access to a task to convert Clementine-to-FITS that preserved
the WCS you could use that do get the right information, but I'm not aware
of such a task. > Am I correct in assuming that the default Right Ascension is in
> hours/minutes/seconds?
IRAF uses decimal degrees for ra/dec, and I believe the vicar
images you have use this also. I'm sure somebody has a way to convert the
vicar headers to a proper WCS, I'm afraid I can't help w/ this.Regards, Mike

>From cooper@sn.dnet.nasa.gov Tue Mar 28 17:54:26 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: wcslabMike,
I know you said you didn't have much help to offer on this one,
but I've spent about six hours now beating my head against the
wall (not really -- just trying to get wcslab to work).
I ftp's the raw pds file lba5881z.193 to the pubs directory.
The information I've been using is:
ROT = twist_angle = 291.95
yscale = .066996
xscale = .0648
cd1_1 = (+/-) .024222
cd1_2 = (+/-) .0044884
cd2_1 = (+/-) .062139
cd2_2 = (+/-) .025042
I have been using the point for Venus in the image as a reference
point, which is RA=1h 51m 13 s or 27.75 deg
Dec = 10d 49m 56s or 10.83222 deg
Venus's crpix values were: crpix1=123 crpix2 = 92
I also know that the corners of the image are: RA (351.58,
1.27,39.74,30.17) dec (5.28, -19.56, -4.39, 20.51)
I assume that we start in the upper left corner and go clockwise around
the image to assign these values to the corners; however, the
description I have says that these values are supposed to go
from (upper left) [ line 1, sample1] to (upper right) [line 1, last
sample] to (lower left) [last line, sample1] to (lower right) [last
line, last sample]. Since this can't be right, I reversed the order
of the last two to get something that actually made sense when I tried
to draw in on a map of the heavens.
Would you please take a look at this and see if you can find what
I'm doing wrong?
Thanks
Bonnie>From cooper@sn.dnet.nasa.gov Wed Mar 29 15:48:05 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: yesterday's mailHi Mike,
I've figured out what may be part of the problem that I wrote you
about yesterday.
First, the images actually need to be flipped in the y direction
as well as the x direction. I ftp'd a gif file which correlates
with the file I sent yesterday, (193_81z.gif). I made the gif
file on my p.c. using a usgs-supplied conversion program from
a Clementine conversion package. I think it's safe to assume
that they have done the orientation correctly. I'm going to,
anyway.
Next, the reticle-point ra and dec numbers should start
with the lower left corner, then lower right, then upper
right, then, upper left. When I do that, then rotate the
image anti-clockwise by the amount in the "twist angle",
the image is then correctly oriented.I don't know if any of this will make a difference to
WCSLAB. I'm working at home today because we're having
a monster rainstorm, so I'll try again with WCSLAB
tomorrow.
Bonnie>From cooper@sn.dnet.nasa.gov Wed Mar 29 16:26:37 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: the next amazing discoveryHi Mike,
I see now that it is not possible to use Venus and Sun information
directly from the almanac. If I plot their positions
in the sky on my correctly oriented image, they don't plot
on the locations where they appear in the image.
So I can't use Venus data in WCSLAB; I must use a corner of
the image (I guess).Bonnie>From fitz Wed Mar 29 16:29:53 1995
Subject: Re: the next amazing discoveryBonnie,
I got what looks to be a reasonable WCS on the image. I recalculated
the CD matrix and used the lower-left corner of the image as the reference
pixel. Try the following in WCSPARS, be sure to set the 'usewcs' param to
wcslab so the axes are labelled correctly:PACKAGE = tv
TASK = wcspars(ctype1 = ra---tan) X axis type
(ctype2 = dec--tan) Y axis type
(crpix1 = 1.) X reference coordinate in the logical system
(crpix2 = 1.) Y reference coordinate in the logical system
(crval1 = 351.58) X reference coordinate in the world system
(crval2 = 5.28) Y reference coordinate in the world system
(cd1_1 = -0.024222) CD matrix
(cd1_2 = -0.06214) CD matrix
(cd2_1 = -0.0601) CD matrix
(cd2_2 = 0.025042) CD matrix
(log_x1 = 0.) The lower X-extent of the logical space
(log_x2 = 1.) The upper X-extent of the logical space
(log_y1 = 0.) The lower Y-extent of the logical space
(log_y2 = 1.) The upper Y-extent of the logical space
(mode = ql)Let me know if you think this is wrong or if you have any questions about how
I got the numbers.Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Thu Mar 30 09:26:36 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike,
I fixed the wcspars task with the right numbers
(thanks for correcting my math).
Now, you said to"
be sure to set the 'usewcs' param to
wcslab" but my usewcs only allows the options
yes or no.
I have it set to yes.
I have wcspars= (empty)
and wlpars= (empty)
I'm a little confused by this documentation. It says that
wcspars= should have the name of a file.
Wasn't I supposed to use the wcspars task?
And if I use the wcspars task, then what do I put in the
wcspars=
field?
My initial attempt so far has put a coordinate grid on the image,
but it goes from 0 to -70 across the bottom in what looks like
a logarithmic scale, and 21h20m to 23h20m along the left side,
like yours.
Thanks again for your help.
Bonnie>From fitz Thu Mar 30 09:30:33 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: wowBonnie,
The WCSPARS and WLPARS parameters in wcslab should be empty strings,
this means that the pset will be used to get the values, supplying a file
means you've got a file with the par values. Just set the wcspars and it
will be picked up. My comment about 'usewcs' meant is should be set to yes,
otherwise info in the 'wcspars' pset gets ignored.-Mike>From cooper@sn.dnet.nasa.gov Thu Mar 30 09:34:36 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: wowOK.
I just noticed one other thing.
My header file says the upper left corner of the image should be
ra 30.17. The cooper.gif file has the R.A. of the upper
left corner at 305. Is it possible to make the R.A. numbers
get larger instead of smaller as they move up and away
from the lower left corner?
Bonnie>From fitz Thu Mar 30 12:35:38 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: wowHi Bonnie,
I got something closer but it's still not quite right, perhaps the
scale values are wrong? What I did was use the center pixel as a reference,
the coord for that (if I understood the header is) the RA/DEC value given,
then I used a negative of the TWIST_ANGLE as the PA when computing the CD
matrix. This gives me wcspars.ctype1 = "ra---tan"
wcspars.ctype2 = "dec--tan"
wcspars.crpix1 = 162.
wcspars.crpix2 = 288.
wcspars.crval1 = 15.67
wcspars.crval2 = 0.49
wcspars.cd1_1 = -0.024222
wcspars.cd1_2 = 0.06214
wcspars.cd2_1 = 0.0601
wcspars.cd2_2 = 0.025042for the critical parameters. The coords for venus is then about 1:42 RA
and 11 degrees DEC, close but not quite and the corners seem off a bit.
I need to get on to some other things but I think if you experiment
a bit with the numbers you should get closer. Hope this helps.Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Fri Mar 31 10:24:26 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: new day, new questionHi Mike,
I'm looking for an on-line almanac that can give me the
RA and Dec of planets and stars in J2000 coordinates.
All the stuff I have around here is in 1950 coordinates.
Do you know of such a program that is public domain,
or obtainable without expense?
Thanks
Bonnie>From fitz Fri Mar 31 12:29:18 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: new day, new questionHi Bonnie,
I'm not sure about the planet ephemeris but you can pick up the SAO
catalog w/ J2000 coords from our archive in ftp/contrib/xepehem/SAO. Other
catalogues such as NGC, variable/binary, etc are available elsewhere on the
net, check the listings in ftp://seds.lpl.arizona.edu/pub/faq/astroftp.txt
(but I can't say any are J2000). You should probably also be able to find
programs for computing planet positions as well.
Hope this helps.Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Wed Apr 12 09:22:44 1995
Subject: another day, another problemMike, We are having a wierd problem with a fortran program called streak.e
The only way this program will work is if the program and the file it works
on are both in the subdirectory, /data2/potter. If we move the program to
another directory (for example, /data3/potterstr/iraf) and re-compile it
there, then run it, it goes through only about half of the interactive
input, then it writes a blank file. If we use the program in /data2/potter,
then tell it the full path name to the file we want to operate on, it goes
through all of the interactive input, but then writes a blank file.Would you please log in to our account (account name and password are the
same as I told you before), and run the streak program, and help us figure
out what the problem is?The purpose of the program is to remove the streaks from the images. The
image we've been working on is in the subdirectory /data3/potterstr/maybe66
its name is lba0013v.055 For the first question in the streak program (Input
image name) we give it this image name, or if we're trying to just get it to
run in the /data2/potter subdirectory, we give it the image name clem032 For
the output image name, we give it a name like 'test' , or something else
equally creative. For the next question, "enter start, stop rows that
define the streak area" we are using numbers like 500, 450. For "enter
width of smoothing window" we use a number like 10. Then when we display
the resulting image, we should have something similar to the image we
started with, except without the streaks.Now, as I said, this all works great if both the image and the fortran
program are in the /data2/potter subdirectory.
Any deviations from that have met with failure.
Please let us know your diagnosis.
Thanks
Bonnie >From cooper@sn.dnet.nasa.gov Wed Apr 12 09:28:56 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: one other questionHi again Mike, One thing that happened while we were trying to get the
streak.e program to work, is Drew used "mkiraf" to cause IRAF to think that
/data3/potterstr/maybe66 is the home directory. I want to un-do this, but I
don't know how. Bonnie>From cooper@sn.dnet.nasa.gov Wed Apr 12 11:10:42 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: streakI noticed something else about the streak program. When I used imcopy and
copied the image lba0013v.066 into the /data2/potter subdirectory, it didn't
work. Then I noticed that the file that does work, clem032, is 384 x 576,
whereas lba0013v.066 is 512 x 576. I've reported this problem to Drew.
Maybe it has something to do with why Streak only works on clem032 I copied
clem032 to the directory /data3/potterstr/maybe66 and although it only asked
half of the iterative questions, it nevertheless produced an un-streaked
image.Maybe we're on to something.
Bonnie>From fitz Wed Apr 12 11:28:59 1995
To: cooper@sn.dnet.nasa.govHi Bonnie,
I won't be able to get to this until later today but check the
directory permissions to be sure you can write there. If you're modifying
existing images be sure you can write to those as well. I'll try to
log in later today, right now I'm swamped.-Mike>From fitz Wed Apr 12 15:31:35 1995
To: cooper@sn.dnet.nasa.govHi Bonnie,
I finally got a free moment but can't log in because I don't
remember the machine or passwd. It's not really an IRAF problem but
I'll look at it when I get a chance if you send me the login info again.Cheers,
-Mike>From cooper@sn.dnet.nasa.gov Wed Apr 12 15:33:42 1995
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike, Yes you are right, it isn't an IRAF problem. I looked at the
fortran code and see that it is set up for the smaller size file that was
made using some other conversion program. Drew wrote the program and he's
gone for the day, and I don't want to take it upon myself to meddle with
it. So let's wait until tomorrow and see what we can work out on this end.
Thanks again. Bonnie

>From cooper@sn.dnet.nasa.gov Thu Apr 13 12:07:06 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: imstat valuesHi Mike,
We've pretty much figured out that the streak.f problem had to do
with the fortran code. But I do have another question, regarding
the imstat task.
When I called the imstat task to look at a particular image
(laa0056v.164), it gave me the values
IMAGE NPIX MEAN STDDEV MIN MAX
laa0056v.164 221184 24.62 3.976 0. 228.But the image header says that the minimum is 19. All the other numbers
are pretty close.
When I set the display paramaeters such that zscale=no,zrange=no,
z1=0 or even -20.5, and z2=255, then display the image:
I run the mouse around over the image and cannot find any pixels
smaller than 20.5.
What gives?Bonnie>From fitz Thu Apr 13 14:17:27 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: imstat valuesHi Bonnie,
> When I called the imstat task to look at a particular image
> (laa0056v.164), it gave me the values
> IMAGE NPIX MEAN STDDEV MIN MAX
> laa0056v.164 221184 24.62 3.976 0. 228.
> But the image header says that the minimum is 19. All the other numbers
> are pretty close.
It might be that the MINMAX task was run earlier and subsequent
processing has changed the pixel values. If you run "minmax update-" does
it show the same values?> When I set the display paramaeters such that zscale=no,
> zrange=no, z1=0 or even -20.5, and z2=255, then display the image:
> I run the mouse around over the image and cannot find any pixels
> smaller than 20.5. What gives?
Here you've still got the 'ztrans' parameter set so whichever values
you put between z1/z2 those are still being mapped to the 200 displayed
graylevels. By default this is a linear transformation but the readout
values on the display server are only approximations to the real pixel
values based on that transformation, you would have to use something like
IMEXAMINE to print the actual values.
Does this answer your question?Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Fri Apr 14 13:12:47 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: scriptsHi Mike,
I am trying to write a script that will just read certain pieces of
the Clementine image header.
This is what I've written that doesn't work:list = "bontest2"
while (fscan (list, s1) != EOF){
print (s1)
print imhead (s1) | grep GAIN_MODE_ID
imhead (s1) | grep EXPOSURE_DURATION
imhead (s1) | grep FOCAL_PLANE_TEMPERATURE
imhead (s1) | grep OFFSET_MODE_ID
key = substr (command, 1,1)
}
#gflushSo far, all I can get it to print out is the image name.
When I put these commands in a terminal script, they work.
What am I doing wrong?
Bonnie>From fitz Sat Apr 15 19:52:03 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: scriptsHi Bonnie,
The first thing I'd check is that you've got the 'long' parameter
set so that the user header keywords actually get printed. The second
thing is that the print imhead (s1) ....statement is incorrect and is probably stopping the script. You can use
grep but the iraf MATCH command will also work, for instance imhead (s1,long+) | match ("GAIN_MODE_ID","")It also depends how you run this script, if what you sent is the whole thing
then to declare it as a task it should be written as a procedure script.
Let me know if you continue to have problems.Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Mon Apr 17 08:40:04 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: scriptsHi Mike,
Thank you so much. I had seen the MATCH command in the RDPDS3 script
that you wrote, but I didn't understand how to use it correctly.
The script is working very well now. There is only one more thing
(at the moment) that it isn't doing to suit me.Here is the script as it is now written:begin
bool answer
int junk
list = "bontest2"
while (fscan (list, s1) != EOF){
print (imhead (s1,long+) | match ("FOCAL_PLANE_TEMPERATURE","")
imhead (s1,loong+) | match ("GAIN_MODE_ID","")
imhead (s1,long+) | match ("EXPOSURE_DURATION","")
imhead (s1,long+) | match (imhead (s1,long+) | match
("OFFSET_MODE_ID","")
imhead (s1,long+) | match ("MIINIMUM","")
junk=scan (answer)
}
gflush
endI want it to pause after each iteration until I press a key, so I'll
have time to look at the numbers and use them. The junk=scan(answer)
should have done that, I thought, but the script doesn't pause until
it's done every file in the directory.
What's Up?
Do I need to declare it as a task in order for that part to work?
Bonnie>From fitz Mon Apr 17 09:27:02 1995
To: cooper@sn.dnet.nasa.govHi Bonnie,
I think the error may be in the lineprint (imhead (s1,long+) | match ("FOCAL_PLANE_TEMPERATURE","")You should get rid of the 'print ('. In a short (procedure) script using
the scan to pause workes for me, I don't think it matters if it's declared
as a task.Cheers,
-Mike>From cooper@sn.dnet.nasa.gov Mon Apr 17 11:11:49 1995
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike,
I don't have the word print at the front of that line.
Did it have it that way in the e-mail I sent you previously?
What I THOUGHT I had was:begin
bool answer
int junk
list = "bontest2"
while (fscan (list, s1) != EOF){
print (imhead (s1,long+) | match ("OFFSET_MODE_ID","")
imhead (s1,long+) | match ("MINIMUM","")
junk=scan (answer)
}
gflush
endBonnie>From fitz Mon Apr 17 11:14:55 1995
To: cooper@sn.dnet.nasa.govHi Bonnie,
This is different than the script you sent this morning, but the
line I'm referring to iswhile (fscan (list, s1) != EOF){
print (imhead (s1,long+) | match ("OFFSET_MODE_ID","")
^^^^^^^-Mike>From cooper@sn.dnet.nasa.gov Mon Apr 17 11:18:52 1995
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike, OK, I understand. I had actually already corrected that so that
the word print no longer appears in front of the word imhead; and you are
right; the script didn't work at all when that happened. The one I sent you
this morning is the revision of that previous one, and I guess the one I
sent you just a few moments ago is the further-revised one, with the word
match replacing the word grep. However, when I run the new version, it
briefly gives the error message "illegal parser state" then takes off
running, never pausing again until it reaches the end of the files in the
list.Bonnie>From fitz Mon Apr 17 11:24:20 1995
To: cooper@sn.dnet.nasa.gov The 'illegal parser state' is probably because you are running this
using e.g. "cl < foo". You can do this if you get rid of the 'begin/end'
lines or else just turn it into a task by declaring a procedure name and
using
cl> task $foo = foo.clthe '$' is necessary since there are no parameters.-Mike

>From cooper@sn.dnet.nasa.gov Wed Apr 19 16:22:10 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: script problemHi Mike,
I'm having an interesting problem with this little script:list = "darkcount.066"
while (fscan (list, s1,x,s2) != EOF){
display (s1, 1)
imarith ("s1", "-", "x", "s2")
}
gflushIt will display the image, but it won't do the imarith operation.
It gives me the error message:z1=0. z2=255.
s1 is not an image or a numberIs that weird?
Bonnie>From fitz Wed Apr 19 16:24:23 1995
To: cooper@sn.dnet.nasa.govNot at all. Since everything except the minus sign is a script variable
you don't need to quote it, if the image name was really "s1" then you
would have to quote it. Try imarith (s1,"-",x,s2)
-Mike>From cooper@sn.dnet.nasa.gov Wed Apr 19 16:26:27 1995
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike,
I changed it to 'imarith (s1, "-", x, s2)' but it's still doing the same thing.
Bonnie>From cooper@sn.dnet.nasa.gov Wed Apr 19 16:29:27 1995
To: "fitz@noao.edu"@east.dnet.nasa.govHi Mike,
Now I just took out the spaces in the imarith line and it seems to be working,
so THANKS. What a smart guy.
Bonnie>From fitz Wed Apr 19 16:31:51 1995
To: cooper@sn.dnet.nasa.govBonnie, The spaces shouldn't matter, I think it was probably something else
that was fixed when you went back to edit the file (e.g. you didn't write
out the change originally). Anyway, glad it's working. -Mike

>From cooper@sn.dnet.nasa.gov Thu Apr 20 13:56:10 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: displaying images in FortranHi Mike,
How do I write a line in my fortran program to display an iraf image?
I looked through the IMFORT section of the manual, but didn't see
anything that looked like it would do that.
Bonnie>From fitz Thu Apr 20 14:02:55 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: displaying images in FortranHi Bonnie,
You can't do it (it's non-trivial even for SPP programs). Somebody
else asked about this just yesterday so I'll append that message in case
it helps.Cheers,
-Mike[Exchange with Phil Fischer yesterday deleted]

>From cooper@sn.dnet.nasa.gov Tue Apr 25 12:00:45 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: sn5hpHi Mike,
I followed the instructions in you e-mail message about how to add
a printer to the graphcap and termcap files.
I am getting an error when I go into IMPLOT
and issue the command
:.snapHe responds, "No GIO kernel specified for graphics device (sn5hp).
Did I do something wrong, or is there something else that I need to do?Bonnie>From fitz Tue Apr 25 12:08:24 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: sn5hpBonnie,
Be sure you set your 'stdplot' iraf environment variable to 'sn5hp'
(it appears you have), and that after editing the graphcap file you issued
a "gflush" command (if you didn't log out in the meantime) to reinitialize
the graphics system. If you're using a personal graphcap the gflush is
also required, do a "show graphcap" to be sure you're using the one you
think you are. The message more likely means there was an error in the
graphcap, it should readsn5hp| :tc=usn5hp:usn5hp|UNIX generic interface to printer 'sn5hp':\
s#0.269:ys#0.210:ar#0.781:\
D=apl,tmp$sgk,!{ sgidispatch sgi2uapl $F -l$(XO) -w$(XW) -b$(YO) \
-h$(YW) -p$(PW) | lpr -Psn5hp; rm $F; }&:tc=sgi_apl:
^^^^^^^^^^^^Make sure that last part is there since it's the link to the kernel definition.
Also be sure the '\' escapes for the newlines are all in place. If that's
not it send me the graphcap entry.-Mike

>From cooper@sn.dnet.nasa.gov Tue Apr 25 12:15:31 1995
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: sn5hpHi Mike,
I had one mistake in the line, so now it ought to work...however, I didn't
know that the / was for a new line, and there's one line that didn't fit.On my screen, it looks like this:
usn5hp|UNIX generic interface to printer 'sn5hp':\
s#0.269:ys#0.210:ar#0.781:\
D=apl,tmp$sgk,!{ sgidispatch sgi2uapl $F -l$(XO) -w$(XW)
-b$(YO) \
-h$(YW) -p$(PW) | lpr -Psn5hp; rm $F; }&:tc=sgi_apl:Do I need to add another \ at the end of the D line?
Bonnie>From fitz Tue Apr 25 12:17:03 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: sn5hpYup, one at the end of each line except the last. You can probably just
join those two lines and it will work.

>From cooper@sn.dnet.nasa.gov Wed Apr 26 10:54:08 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: pixel file sizesMike,
When I first used RDPDS3 to convert the PDS files to IRAF files,
the pixel files were all 590848 bytes.After I did imarith to subtract out the dark current, the pixel files
became 885760 bytes.After I used the fortran program to remove the streaking, the pixel files
all became 917504 bytes.What is happening here? I'm not sure what kind of information
I now need to supply to Adobe Photoshop in order to convert the
pixel files to use them in Photoshop.Bonnie>From fitz Wed Apr 26 11:45:47 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: pixel file sizesHi Bonnie,
The .pix files contain a 1024 byte header and usually some padding
to increase I/O efficiency. When the image is first read in the data
are written as short (2-byte) integers and stored in a 512x576 physical
dimension. When you ran IMARITH the pixel type was changed to real (4-bytes)
and the storage was changed to the actual 384x576 dimension. I'm not sure
what your streak program did, probably kept the real pixels and wrote them
back out with padding.> I'm not sure what kind of information I now need to supply to Adobe
> Photoshop in order to convert the pixel files to use them in Photoshop. You almost certainly don't want to feed it the .pix file unless you
can specify where the pixels are and any padding available. The EXPORT
task can write out a raw binary file with no padding, or some other format
that Photoshop can read (but not TIFF). To write a raw file use cl> export image binfil raw header- outtype=""The binary file will be the same datatype as the image.Cheers,
-Mike

>From cooper@sn.dnet.nasa.gov Wed Apr 26 12:15:04 1995
From: cooper@sn.dnet.nasa.gov
To: "fitz@noao.edu"@east.dnet.nasa.gov
Subject: Re: pixel file sizesHi Mike, That sounds like a good plan. However, when I type in the command,
I get the error message ERROR: task `export' not foundI got into the "dataio" package, which is where I thought I needed
to be, so now I have a da> prompt, but I still get the same error
message.What might the problem be?
Bonnie>From fitz Wed Apr 26 12:23:13 1995
To: cooper@sn.dnet.nasa.gov
Subject: Re: pixel file sizesBonnie,
EXPORT is part of the CLEMENTINE package I put together for you (at
least I think I left it available). Check the clementine.cl file to see
if I commented it out. CLEMENTINE is a custom version of the IMCNV package
you can get from our archive /iraf/extern directory that contains just
IMPORT/EXPORT, if you can't find EXPORT there you could either install
IMCNV or send me the login info again and I'll set it up.-Mike