iraf.net

Hello.
I am a graduate student of University of Rochester. My computer has
Redhat Linux 6.2. I was just wondering if I can install PC-IRAF in my
computer. Could you give me a reply? Thank yoy very much.Regards,
Jeong-Hoon Yang

On Sat, 10 Jun 2000, Jeong-Hoon Yang wrote:> Hello.
> I am a graduate student of University of Rochester. My computer has
> Redhat Linux 6.2. I was just wondering if I can install PC-IRAF in my
> computer. Could you give me a reply? Thank yoy very much.
> Hello,Sure -- you can use our RedHat 6.1 distribution located in: ftp://iraf.noao.edu/iraf/v211/PCIXYou'll want to pick up all the files in as.pcix.gen, ib.rhux.x86, and
nb.rhux.x86, as well as the installation guide pciraf.ps.gz (or
pciraf.pdf).Let us know if you have any other questions.Regards,Matt Cheselka
NOAO/IRAF

Hello.
I am a first year graduate student of University of Rochester. My computer
has Redhat Linux "6.2" system. I was just wondering if I can install
PC-IRAF in my computer. Could you give me a reply? Thank you very much.Regards,
Jeong-Hoon Yang
jyang@pas.rochester.edu

Hi,On Mon, 19 Jun 2000, Jeong-Hoon Yang wrote:> Hello.
> I am a first year graduate student of University of Rochester. My computer
> has Redhat Linux "6.2" system. I was just wondering if I can install
> PC-IRAF in my computer. Could you give me a reply? Thank you very much.Yes, you can use our RH6.1 distribution files at ftp://iraf.noao.edu/iraf/v211/PCIX.Grab all the files in as.pcix.gen, ib.rhux.x86, and nb.rhux.x86. You'll
also want to grab and read the installation guide pciraf.ps.gz (or
pciraf.pdf). Make sure to xfer all this stuff in binary mode. Let us know if you run into any trouble along the way...Cheers,Matt Cheselka
NOAO/IRAF

Dear master:
I'm a chinese. I'm not well in English, But I'm intrested in your web site. And I want to learn sth from your web site, as emailnetworklanguges of computer...
Thanks
YOURS Jingwei Huang

On Fri, 23 Jun 2000, huangjingwei wrote:> Dear master: I'm a chinese. I'm not well in English, But I'm intrested
> in your web site. And I want to learn sth from your web site, as
> email\network\languges of computer... Thanks YOURS Jingwei Huang
> Hello,IRAF is an astronomical image reduction and analysis facility developed at
the National Optical Astronomy Observatories in Tucson, Arizona, USA.
Feel free to browse our website and let us know if you have any specific
questions. If you are new to computers, programming, email, etc., my best
suggestion would be to just start doing it and learn as you go. There are
many good resources both on the internet and in books.Regards,Matt Cheselka
NOAO/IRAF

Hello,I am attempting to reduce some data from the WIYN minimosaic. I am
running into a problem as I am trying to make a good pixel mask as a
multiextension FITS file.I copied one of my images into a file called gpm1.fits, then used
imreplace to set all the pixels to 1.PACKAGE = imutil
TASK = imreplaceimages = gpm1[1],gpm1[2],gpm1[3],gpm1[4] Images to be edited
value = 1. Replacement pixel value
(imagina= 0.) Imaginary component for complex
(lower = INDEF) Lower limit of replacement window
(upper = INDEF) Upper limit of replacement window
(radius = 0.) Replacement radius
(mode = ql)And I then did an imstat on all the extensions to make sure it worked.cl> imstat gpm1[1],gpm1[2],gpm1[3],gpm1[4]
# IMAGE NPIX MEAN STDDEV MIN MAX
gpm1[1] 4194304 1. 0. 1. 1.
gpm1[2] 4194304 1. 0. 1. 1.
gpm1[3] 4194304 1. 0. 1. 1.
gpm1[4] 4194304 1. 0. 1. 1.At this point I began to use imreplace to create the "bad" columns of
the detector.cl> imreplace gpm1[1][198:201,3466:4097]
Replacement pixel value (1.): 0
cl> imreplace gpm1[1][212:216,680:4097]
Replacement pixel value (0.):
cl> imreplace gpm1[1][317:320,1106:4097]
Replacement pixel value (0.):
cl> imreplace gpm1[1][441:445,1450:4097]
Replacement pixel value (0.):
ms> imreplace gpm1[2][876:883,2386:4097]
Replacement pixel value (0.):
ERROR: Unsupported image pixel datatypeDoing an imstat now gives:cl> imstat gpm1[1],gpm1[2],gpm1[3],gpm1[4]
# IMAGE NPIX MEAN STDDEV MIN MAX
gpm1[1] 4194304 0.9893 0.1028 0. 1.
ERROR: integer divide by zeroAlso, in the header of gpm1[3], there are thirty-three lines of:
"????????????????????????????????" right in the middle of the header.I have tried to do the command line imreplace in different orders, but
it does not make a difference. If I change gpm1[2] first, then
gpm1[3] is no longer usable.I would appreciate it a lot if you could help me out by letting me
know what the problem is, and if there is something I can do to fix
it. Thank you for your time.Andrew Glenn----- End forwarded message -----

While I am attemping to reproduce this problem I wonder if I can get a copy
of the headers for this image or maybe I can grab the image from your
site or else you could put it in iraf.noao.edu/pub.If you have the external package 'fitsutil', to obtain a listing of
the header:cl> fisutil
fi> fxheader gpm[1] long+ > hd.txt
fi> fxheader gpm[2] long+ >> hd.txt
same for [3] and [4].Could you send me hd.txt?Thanks
Nelson Zarate>
> Hello,
>
> I am attempting to reduce some data from the WIYN minimosaic. I am
> running into a problem as I am trying to make a good pixel mask as a
> multiextension FITS file.
>
> I copied one of my images into a file called gpm1.fits, then used
> imreplace to set all the pixels to 1.
>
> PACKAGE = imutil
> TASK = imreplace
>
> images = gpm1[1],gpm1[2],gpm1[3],gpm1[4] Images to be edited
> value = 1. Replacement pixel value
> (imagina= 0.) Imaginary component for complex
> (lower = INDEF) Lower limit of replacement window
> (upper = INDEF) Upper limit of replacement window
> (radius = 0.) Replacement radius
> (mode = ql)
>
> And I then did an imstat on all the extensions to make sure it worked.
>
> cl> imstat gpm1[1],gpm1[2],gpm1[3],gpm1[4]
> # IMAGE NPIX MEAN STDDEV MIN MAX
> gpm1[1] 4194304 1. 0. 1. 1.
> gpm1[2] 4194304 1. 0. 1. 1.
> gpm1[3] 4194304 1. 0. 1. 1.
> gpm1[4] 4194304 1. 0. 1. 1.
>
> At this point I began to use imreplace to create the "bad" columns of
> the detector.
>
> cl> imreplace gpm1[1][198:201,3466:4097]
> Replacement pixel value (1.): 0
> cl> imreplace gpm1[1][212:216,680:4097]
> Replacement pixel value (0.):
> cl> imreplace gpm1[1][317:320,1106:4097]
> Replacement pixel value (0.):
> cl> imreplace gpm1[1][441:445,1450:4097]
> Replacement pixel value (0.):
> ms> imreplace gpm1[2][876:883,2386:4097]
> Replacement pixel value (0.):
> ERROR: Unsupported image pixel datatype
>
> Doing an imstat now gives:
>
> cl> imstat gpm1[1],gpm1[2],gpm1[3],gpm1[4]
> # IMAGE NPIX MEAN STDDEV MIN MAX
> gpm1[1] 4194304 0.9893 0.1028 0. 1.
> ERROR: integer divide by zero
>
> Also, in the header of gpm1[3], there are thirty-three lines of:
> "????????????????????????????????" right in the middle of the header.
>
> I have tried to do the command line imreplace in different orders, but
> it does not make a difference. If I change gpm1[2] first, then
> gpm1[3] is no longer usable.
>
> I would appreciate it a lot if you could help me out by letting me
> know what the problem is, and if there is something I can do to fix
> it. Thank you for your time.
>
> Andrew Glenn
>
> ----- End forwarded message -----
>

I can see the problem. The imheader output says:gpm1[1][1024,4096][real]: CL1604 R
No bad pixels, min=0., max=0. (old)
Line storage mode, physdim [1024,4096], length of user area 8343 s.u.
Created Wed 15:48:36 05-Jul-2000, Last modified Wed 15:48:34 05-Jul-2000
....i.e. NAXIS2=4096, but you were using:cl> imreplace gpm1[1][198:201,3466:4097]
Replacement pixel value (1.): 0
cl> imreplace gpm1[1][212:216,680:4097]
Replacement pixel value (0.):
cl> imreplace gpm1[1][317:320,1106:4097]
....this way you were silently overwriting the header for extension [2].
Please repite the above but only upto 4096 and maybe this time it will be
OK. Unfortunally IMIO does not check for out of bound references for
axis > 1.Cheers
Nelson

Hello,I am working with WIYN minimosaic images and attempting to use the
task mscimage to make single images from the multiextension fits
files.I have used this task on the exposures from my run on March 3, 2000,
and it works fine. My problem is that I cannot reproduce the same
results on exposures from a previous run on Feb 7, 2000 (using the
exact same parameters). The resulting images from the February run
are too large (5108X4097 vs. 4152X4106) and the images themselves are
not being created correctly.My first question is whether there has been a change in the mscred or
image creation software between those two dates. If not, I can ftp
the images over so you can look at them yourself.Thank you for your time,Andrew Glenn

>From valdes Tue Jul 11 08:26:40 2000
From: glenn@astro.wisc.edu (Andrew Glenn)
Subject: question
Date: 10 Jul 2000 13:46:43 -0700Hello,I am working with WIYN minimosaic images and attempting to use the
task mscimage to make single images from the multiextension fits
files.I have used this task on the exposures from my run on March 3, 2000,
and it works fine. My problem is that I cannot reproduce the same
results on exposures from a previous run on Feb 7, 2000 (using the
exact same parameters). The resulting images from the February run
are too large (5108X4097 vs. 4152X4106) and the images themselves are
not being created correctly.My first question is whether there has been a change in the mscred or
image creation software between those two dates. If not, I can ftp
the images over so you can look at them yourself.Thank you for your time,Andrew Glenn>From valdes Tue Jul 11 08:36:20 2000
Date: Tue, 11 Jul 2000 08:36:20 -0700 (MST)
From: Frank Valdes <valdes>
To: glenn@astro.wisc.edu
Subject: Re: questionHello Andrew,You have encountered at problem with the image headers that was fixed
between the two runs. Below is a description of how to fix the problem.Cheers,
Frank Valdes
For WIYN MiniMosaic taken prior to February 24, 2000 there was an error
in the world coordinate system (WCS) written to the image header.
Specifically the CRPIX1 keywords in extensions 2 and 4, also called im2
and im4, are off by 960 pixels.The effect of this error is that coordinates reported from the header
WCS in those pieces will be off relative to the other two pieces. It
is relative because one might zero the coordinates on a star in any
extension and then stars relative to that zero will be correct but
stars in the alternate pair of extension will be off. Overplotting
USNO stars would show this behavior. The other more obvious symptom is
that after doing MSCIMAGE the single image will show a funny pattern
with a large gap between the two halfs of each pair of amplifiers from
the same CCD. Since the amplifiers come from the same CCD obviously
there should be no gap.The absolute values of CRPIX1 depend on whether the data is raw data
or trimmed data. For raw data the values for the four extensions
the CRPIX1 values should be:ms> msccmd "hselect $input $I,crpix1 yes" zero.400
zero.400[im1] 2076.49674826985
zero.400[im2] 1116.49674826985
zero.400[im3] -23.1135562820506
zero.400[im4] -983.113556282051while for trimmed data (using CCDPROC with the default trimming)ms> msccmd "hselect $input $I,crpix1 yes" test1
test1[im1] 2076.49674826985
test1[im2] 1052.49674826985
test1[im3] -23.1135562820506
test1[im4] -1047.11355628205but in both cases the errors in im2 and im4 will be 960 pixels.
TO FIX THE ERROR:There are two methods. The first is to add 960 to the CRPIX1 keywords
for the two extensions. This works for both raw and trimmed data. ms> hedit <image>[im2] crpix1 '(crpix1+960)'
ms> hedit <image>[im4] crpix1 '(crpix1+960)'where <image> is the FITS file name with or without the ".fits" extension.
Note that you can also use a template of the form *.fits[im2] to apply to
all files with a .fits extension.The second method is to reset all the WCS keywords with the command ms> mscsetwcs <images> mscdb$noao/kpno/wiyn/wcs/rcheb11.dat

This requires you have a current copy of the mscdb$ NOAO mosaics database
(ftp://iraf.noao.edu/iraf/extern/mscdb.tar.Z).
>From glenn@yuenglng.astro.wisc.edu Tue Jul 11 11:18:08 2000
Date: Tue, 11 Jul 2000 13:18:05 -0500
From: Andrew Glenn <glenn@astro.wisc.edu>
To: Frank Valdes <valdes@noao.edu>
Subject: Re: question
Thank you; that problem has had me ripping my hair out for the last
few days.Thanks again,Andrew Glenn

Hello,I am reducing WIYN minimo data and am running into a slight problem
while using mscimage. The problem is that using the mscimage task on
two exposures (taken right after another) does not result in two
output images of the same size; i.e., one has more pixels than the
other. This would not be a problem except that tasks like imarith
require images of the same dimensions.I was wondering if this is the "normal" way for the mscimage task to
work, or if I am doing something incorrectly. If it is normal, what
is the best way to fix this without having to resort to re-trimming
all my images down to the same size.I have included a short log of my reduction below along with the
headers of the two files, hopefully it will be useful.Thank you for your time.Andrew Glenn---Check to make sure everything's the same to start:im> imstat mar81_0[1],mar81_0[2],mar81_0[3],mar81_0[4],mar82_0[1],mar82_0[2],mar82_0[3],mar82_0[4]
# IMAGE NPIX MEAN STDDEV MIN MAX
mar81_0[1] 4194304 216.9 338.9 -18.49 58256.
mar81_0[2] 4194304 217.7 340.2 -20.19 62335.
mar81_0[3] 4194304 210.3 313.5 -152.4 71795.
mar81_0[4] 4194304 216.2 722.6 -4188. 90291.
mar82_0[1] 4194304 210.8 343. -19.61 58435.
mar82_0[2] 4194304 207.7 134.7 -188.6 38904.
mar82_0[3] 4194304 208.6 487.4 -19.33 71825.
mar82_0[4] 4194304 211.1 737.2 -4195. 98313.Ok, every strip has the same # of pixels.Now mscimage; create mos81 and mos82:PACKAGE = mscred
TASK = mscimageinput = mar81_0,mar82_0 List of input mosaic exposures
output = mos81,mos82 List of output images
(referen= ) Reference image
(pixmask= no) Create pixel mask?
(verbose= )_.verbose) Verbose output? # Resampling parmeters
(blank = 0.) Blank value
(interpo= linear) Interpolant for data
(minterp= linear) Interpolant for mask
(fluxcon= no) Preserve flux per unit area?
(ntrim = 7) Edge trim in each extension
(nxblock= 2048) X dimension of working block size in pixels
(nyblock= 1024) Y dimension of working block size in pixels # Geometric mapping parameters
(interac= no) Fit mapping interactively?
(nx = 10) Number of x grid points
(ny = 20) Number of y grid points
(fitgeom= general) Fitting geometry
(xxorder= 4) Order of x fit in x
(xyorder= 4) Order of x fit in y
(xxterms= half) X fit cross terms type
(yxorder= 4) Order of y fit in x
(yyorder= 4) Order of y fit in y
(yxterms= half) Y fit cross terms type
(fd_in = )
(fd_out = )
(fd_ext = )
(fd_coor= )
(mode = ql)Using `mar81_0' for the WCS reference
Creating empty output mosaic mos81 ...
Mapping mar81_0[im1] to mos81 ...
Mapping mar81_0[im2] to mos81 ...
Mapping mar81_0[im3] to mos81 ...
Mapping mar81_0[im4] to mos81 ...
Creating empty output mosaic mos82 ...
Mapping mar82_0[im1] to mos82 ...
Mapping mar82_0[im2] to mos82 ...
Mapping mar82_0[im3] to mos82 ...
Mapping mar82_0[im4] to mos82 ...im> imstat mos81,mos82
# IMAGE NPIX MEAN STDDEV MIN MAX
mos81 17048112 209.5 458. -4153. 89616.
mos82 17043960 204. 472.2 -775.2 78603.Two different sized images.

How do I set up my login.cl so when I start IRAF,
it doesn't clear my screen and print up
the welcome stuff.thanks,
-pete challis
pchallis@cfa.harvard.edu

Hi Pete,
All you need to do is create a file called ".hushiraf" in the same
directory as your login.cl.Cheers,
Mike Fitzpatrick

Hi Glenn,First of all I think I you have the problem described below.I see you are correctly doing MSCIMAGE on the two images at the same
time with the "reference" parameter set to "". This means they are
put on the same pixel grid on the sky except for a possible integer shift.
This task does NOT put the images to an output that is aligned in pixel
space (i.e. they do not necessarily display aligned nor can you do
imarith). The reason for this is for a dithered set of exposures there
will not be wasted space around the edges. However I am not sure if
there is the requirement that they come out the same size if the reference
coordinate system is the same. There is no explicit requirement that
the resampled images come out to exactly the same size. It could be
different due to details of the WCS calibration trough MSCCMATCH or
MSCZERO.I am in a rush to get home to leave on vacation (through the 25th) so I
can't be more thorough in looking at your headers and trying some
tests. So I leave you with the comments that you have the WCS error
and that it is possible that the images may not come out to the same
size nor be aligned so that you can use imarith.Cheers,
Frank Valdes
For WIYN MiniMosaic taken prior to February 24, 2000 there was an error
in the world coordinate system (WCS) written to the image header.
Specifically the CRPIX1 keywords in extensions 2 and 4, also called im2
and im4, are off by 960 pixels.The effect of this error is that coordinates reported from the header
WCS in those pieces will be off relative to the other two pieces. It
is relative because one might zero the coordinates on a star in any
extension and then stars relative to that zero will be correct but
stars in the alternate pair of extension will be off. Overplotting
USNO stars would show this behavior. The other more obvious symptom is
that after doing MSCIMAGE the single image will show a funny pattern
with a large gap between the two halfs of each pair of amplifiers from
the same CCD. Since the amplifiers come from the same CCD obviously
there should be no gap.The absolute values of CRPIX1 depend on whether the data is raw data
or trimmed data. For raw data the values for the four extensions
the CRPIX1 values should be:ms> msccmd "hselect $input $I,crpix1 yes" zero.400
zero.400[im1] 2076.49674826985
zero.400[im2] 1116.49674826985
zero.400[im3] -23.1135562820506
zero.400[im4] -983.113556282051while for trimmed data (using CCDPROC with the default trimming)ms> msccmd "hselect $input $I,crpix1 yes" test1
test1[im1] 2076.49674826985
test1[im2] 1052.49674826985
test1[im3] -23.1135562820506
test1[im4] -1047.11355628205but in both cases the errors in im2 and im4 will be 960 pixels.
TO FIX THE ERROR:There are two methods. The first is to add 960 to the CRPIX1 keywords
for the two extensions. This works for both raw and trimmed data. ms> hedit <image>[im2] crpix1 '(crpix1+960)'
ms> hedit <image>[im4] crpix1 '(crpix1+960)'where <image> is the FITS file name with or without the ".fits" extension.
Note that you can also use a template of the form *.fits[im2] to apply to
all files with a .fits extension.The second method is to reset all the WCS keywords with the command ms> mscsetwcs <images> mscdb$noao/kpno/wiyn/wcs/rcheb11.dat

This requires you have a current copy of the mscdb$ NOAO mosaics database
(ftp://iraf.noao.edu/iraf/extern/mscdb.tar.Z).