iraf.net

>From pso@topcat.as.utexas.edu Wed Aug 9 14:38:32 2000
Date: Wed, 9 Aug 2000 16:38:29 -0500 (CDT)
From: P Samuel Odoms <pso@topcat.as.utexas.edu>
To: valdes@noao.edu
Subject: 8 amplifier mosaic images, etc.Dear Sir,We at McDonald Observatory will be changing our new detector software
to save the data in a 3D Fits or HHH type file. To help us make sure
we are doing it correctly so that it will match everyone else doing
this, we were wondering if you could make an example image file or two
available that was taken with your 8 amplifier mosaic detector. We
would also appreciate it if you could email your detcap entry for your
mosaic detector to pso@topcat.as.utexas.edu. Thank you for your time.Yours truly,Sam Odoms (pso@topcat.as.utexas.edu)
>From valdes Thu Aug 24 12:21:23 2000
Date: Thu, 24 Aug 2000 12:21:22 -0700 (MST)
From: Frank Valdes <valdes>
To: pso@topcat.as.utexas.edu
Subject: Re: 8 amplifier mosaic images, etc.Hello Sam,Our mosaic data format consists of multiextension FITS files (MEF)
where the primary header contains global keywords and no image data,
and each extension contains data from an amplifier. This format is
becoming generally accepted for mosaic and multiamplifier data. The
only other type of format used for multiamplifier data from a single
CCD packs the separate readouts into parts of a 2D image along with the
overscans and indexed keywords. ESO and CTIO use this for some data.
The ESO mosaic, the CFHT mosaic, as well as ours and other
observatories are using the MEF format and most are using the IRAF
MSCRED package for data reductions. No one is using 3D FITS that I'm
aware of. The HHH type of file is a precursor to multiextension FITS.We have a fair amount of documentation you can look at. A starting
point ishttp://iraf.noao.edu/projects/ccdmosaic/The "Mosaic data structures" discusses the format in some detail. The
SPIE paper "The NOAO Mosaic Data Handling System" is a good discussion of
both format and system.You ask about detcap. Our mosaic is not controled by an ICE system but
by an Arcon controller system developed at CTIO. While it also uses
IRAF for a user interface it is not structured in a simple way such as ICE
and is probably not relevant to your needs. What might be relevant and
has some of the same philosophy as ICE is the separation of the data
acquisition to produce a data stream feed to a process called the
"data capture agent". The DCA is the piece that builds the output data
format. It is based on a portable software message bus. It is possible
for others to use some of this software by implementing their own data
field and using the message bus/DCA and other components of the Mosaic
Data Handling System.If you want more information write to iraf@noao.edu or contact Doug
Tody who is the architect of the MDHS. My role has been in data formats
and data reductions.Cheers,
Frank Valdes

[FYI - followup to McDonald]---
>From tody@tucana.tuc.noao.edu Thu Aug 24 13:07:23 2000
Date: Thu, 24 Aug 2000 12:57:32 -0700 (MST)
From: Doug Tody <tody@tucana.tuc.noao.edu>
To: pso@topcat.as.utexas.edu
Subject: Re: 8 amplifier mosaic images, etc.Hi Sam,> We at McDonald Observatory will be changing our new detector software
> to save the data in a 3D Fits or HHH type file. To help us make sure
> we are doing it correctly so that it will match everyone else doing
> this, we were wondering if you could make an example image file or two
> available that was taken with your 8 amplifier mosaic detector. We
> would also appreciate it if you could email your detcap entry for your
> mosaic detector to pso@topcat.as.utexas.edu. Thank you for your time.I don't know much about your acquisition software there and how practical
this would be, but as Frank says if you are interested in the MEF data format
we use for our new instruments, you might be interested in the data capture
software as well. This consists of several components linked by a message
bus; it is easy to interface to an existing detector control system, and
of course it interfaces well with IRAF.If you want to take a look at this the SPIE paper of several years ago is
a good reference. The software itself (most of it anyway) is at ftp:://new-tucana.tuc.noao.edu/pub/mosaic/software/000822000822 is the Aug 22 2000 release, from a couple of days ago (we are just
coming out of summer shutdown here.Briefly, it goes like this: (detector control system) (IRAF)
| |
(picfeed) (DCA GUI) (Mosaic RTD)-----+
| | |
| | |
------------+-----------------+------------+-------------
| <--- message bus --->
|
(DCA) <-- (KTM)
|
|
[FITS MEF imagefile]Synopsis: picfeed Feeds pixel and header data packets from the detector
controller subsystem (system dependent) onto the
message bus in real time. DCA Data Capture Agent. Writes the FITS MEF file directly
via virtual memory (mapped file) in real time as the
data is received from the picture feed component,
descrambling, flipping, byte swapping, etc. the data
in the process. DCA GUI GUI for controlling the DCA, RTD, postprocessing,
archive interface, etc. Also shows the status of
the readout as it progresses. KTM Keyword translation module. A Tcl script called by
the DCA to translate header information from the
controller into the form required in the MEF image.
Tcl C extensions are used for things like FITS
keyword manipulation. Mosaic RTD Real time display. Displays the Mosaic in real time
as data is read out. (This is actually just Ximtool,
with some special software to drive it to display a
mosaic). IRAF Interfaces directly to the FITS MEF images, and to
the RTD for Mosaic image display.All of these components essentially stand alone, although they are normally
linked together as shown, via the message bus. Although the software supports
Mosaics, it can also be used for single frame CCD readout. We run this on
a range of different systems here.To interface this to a new system, one needs to replace/modify the picfeed
component, and write one KTM module for each instrument. - Doug