iraf.net

Hi.Could you tell us what procedures you use for cosmic ray removal
in CCD data?Thank you.Carol Christian

Hi Carol,I am responding to a couple of things from you, your CCDRED guide for CFHT
data and your question about cosmic ray removal. It makes me feel good that
you can recommend use of CCDRED and that it will find usage outside of NOAO.
Thank you for sending a copy of your user's guide.1-1 While I believe CCDRED is very efficient, once reductions become routine
you might compare some times with your previous methods. You can say
IRAF is efficient til you are blue in the face but if some people
don't believe it you will have to show them with their own system.
If their own system is faster though much less general then they
can choose what they want.1-1 I have updated the CCDRED guide slightly as of last week.1-8 The IRAF system command "diskspace" may be used to determine disk
space on any OS.1-8 For long tapes you might recommend reading the tapes in the background.
cl> rfits [tape] [files] [rootname] >& rfits.log&1-13 Why do you mention COMBINE? Later you end up using the CCDRED combine
tasks.1-13 In the first example you have %.im% instead of %.imh%.1-13 I'm not sure of the purpose of the example of changing an extension.1-13 You might want to use CCDHEDIT instead to provide an mapping to any
ccd type names you want. This does first require setting up the
translation file in CCDRED.1-14 Your FIXTIME script is overly complex and has a possible gotcha.
Use of IMGETS in a script will fail if the script is run as a
background job. See the SCRIPTS paper about this. Parsing out
the hours, minutes, and seconds fields should be unnecessary
since IRAF understands sexigesimal notation. in a script
all you need is exposure = 3600 * real (imgets.value) However, the following describes a better way. This is a note
I wrote to Jeannette and Doug.----------------------
We have the case where we want to convert sexigesimal strings in an image
header to seconds (CFHT is the specific example). If the CFHT time is
stored as IN-TIME = 01:30:00then the following will work cl> hedit *.imh exptime "(3600*@'in-time')" add+ # New param
or cl> hedit *.imh "in-time" "(3600*@'in-time')" # In place[The @ and ' quotes are to get around the - in the keyword name (if you ]
[can get away from keywords with "-" you should do so). ]However, if their times are stored like at NOAO as strings (which is
required by the FITS standard since sexigesimal notation is not
in the standard), i.e. IN-TIME = '01:30:00'then the problem arises that we cannot use a string in an expression.
This must be an oversight that there is no intrinsic function to convert
a string which is actually a number into a valid number. In the CL the
function "real" can convert a string to a number but in HEDIT this is an
error. Thus one would like the following (ignoring the complication of
the minus in "in-time"): cl> hedit *.imh time "(3600*time)" # Implicit coercion
or cl> hedit *.imh time "(3600*real(time))" # Explicit coercion
!!! The above does not work and is only an example !!!An easy work around is the following: cl> hedit *.imh newtime 0. add+ # Add new real param
cl> hedit *.imh newtime "(time)" # This coercion works!
cl> hedit *.imh newtime "(3600*newtime)" # Convert to secondsThis is better than Carol's script which tries to parse out the time fields.
----------------------1-15 Why does the "ssfile" parameter end up in the database directory.
The setup script can set it to "subsets" which will be the
current user's directory. The script can also copy the default
subsets file for the user.1-20 Why do you recommend averages of medians?1-20 You should probably explain the reason for the output names. These are
the names used by default in CCDPROC.1-22 There has always been some uncertainty about whether one should combine
unprocessed flats or processed flats. I tend to think there isn't
any difference and to recommend combining the raw images so that only
one flat field (per filter) is processed. Do you have an argument
for recommending preprocessing before combining or is this just
tradition?Basically very nice. We need to develop something similar except that we
have so many detectors, instruments, and applications. We are still
trying to come to grips with the best way to setup and who will do it.
However, just the vanilla usage with our LSI-SUN link seems pretty good.You will be receiving a new tape soon (Jeannette is sending it out
today). There were some bug fixes to the MK tasks which you do not
probably use. The new package also includes a single frame cosmic ray
cleanning program. I still need feedback on how it does. I've been
told the documentation is not too good so I'll have to work on it some
time. Rather than try and explain the algorithm, which is a little
complicated, check the manual page. Of course for multiple exposures
there are several algorithms, such as sigma clipping, available with
ccdred.combine. For a small number of frames, say 3, the average
sigma clipping algorithm does pretty well without throwing away too much
information. If the overhead of triple exposures is not large this might
even be a recommended observing sequence.Hope this has been of some help.Frank