PREPARING DATA FOR THE FIRST TIME: Our system runs on standard FITS images. So the first thing to check is whether images are FITS images. The main non-FITS files we get are IRAF images. Right now, we read IRAF images then write out fits images in IDL To read IRAF file called "d001.imh" ; irafrd,im,hd,'d001' To write out FITS file called "d001.fts" ; writefits,'d001.fts',im,hd or (SEE BELOW "Integer vs Floating") integerfits,'d001.fts',im,hd The simplest way of checking the header is "more" (unix command) This works on both FITS files and IRAF Header(*.imh) To get a brief summary of headers use whichiswaht.pro (IDL routine); whichiswhat,file='new.list',output='new.out',form='kpno' This will read headers of files in new.list and using kpno format, shows ra, dec, epoch, exposure, date-obs, filter, etc., on screen and into an output file. BSCALE, BZERO and BITPIX keywords in FITS header In IDL, FITS images are read (readfits.pro) as floating numbers. But the FITS files on disk may not be floating numbers. They can be long integers (= 32 bit integers) or most likely integers (= short integers = 16 bit integers) FITS header must have an entry called BITPIX indicating the data format. BITPIX = 16 >>> 16 bit integer BITPIX = 32 >>> 32 bit integer BITPIX = -32 >>> 32 bit floating Also there are BSCALE and BZERO. They are used in this simple formula; real DATA = (FITS DATA on disk) * float(BSCALE) + float(BZERO) Note, that real DATA becomes floating even for integer FITS DATA on disk EXAMPLE: in FITS file on disk BITPIX = 16 BSCALE = 2.3 BZERO = 1320.26 first pixel = -590 second pixel = 31007 read into MEMORY in IDL first pixel = (-590*2.3) + 1320.26 = -36.7400 second pixel = (31007*2.3) + 1320.26 = 72636.4 Then the header is changed to prevent doulbe application of BSCALE or BZERO ; BITPIX = (-32) BSCALE = 1.0 BZERO = 0.0 IRREGULARITIES: Even for the fits files, we have some irregularities. Signed integer vs. Unsigned integer: (Only for 16 bit integer) IDL has only Signed integer going from -32768 (=2^15) to +32767 Some misconversion from the telescope causes integers to range from 0 to 65535 (=2^16-1). This causes no problem for values from 0 to +32767 but +32768 becomes -32768, +32769 becomes -32767, .... , and 65535 becomes 0. Graphically one can see this with dark saturations. This can be fixed by one IDL command image = temporary(image) + (2^15) AS LONG AS IMAGE IS 16 BIT INTEGER! To overwrite an integer FITS file for good, use (in IDL) signintfits,'d001.fts' Or if you are scared to overwrite the original file, use signintfits,'d001.fts', output='fixed_d001.fts' NOTE : signintfits.pro set the BZERO to +32768 to prevent negative pixels. Integer vs Floating (or any other non 16 bit integer) : Due to limited flexibilty of our super flat generating routine, We need to use 16 bit integer FITS files there. Also, from the view point of disk spaces, we like to have short integers. To convert floating Raw image file which spans less than 65536 and actual integer value ( ex. [15.0, 199.0, ...] not [15.237, 199.7773, ...]) to 16 bit integers, do these 1 : image = readfits('$dsk5/d001.fts',hd) 2 : integerfits,'$dsk5/d001.fts',image,hd or integerfits,'$dsk5/integer_d001.fts',image,hd (2 : depending on whether one wants to overwrite or not) Missing crutial informations in the header : Some images are sent to us with partial header or header with wrong values or header with strange units. Although some of them can be coped later with our database, sometimes it's better to correct the header and rewrite the FITS file. To add or change an header entry, use sxaddpar.pro EXAMPLE) 1 : image = exactfits('$dsk5/d001.fts',hd) 2 : sxaddpar,ha,'date-obs', '29/04/95' 3 : writefits,'$dsk5/d001.fts',image, hd Here, exactfits reads the file but does not apply BSCALE or BZERO mentioned above. So when one does writefits, the orignal data is written out exactly the same without any change other than DATE-OBS header entry.