Index: branches/ipp-magic-v0/Ohana/src/imregister/doc/Change.log
===================================================================
--- branches/elixir/Ohana/src/imregister/doc/Change.log	(revision 2487)
+++ 	(revision )
@@ -1,8 +1,0 @@
-
-imregister-3.0 represents a completely new organization of these
-programs, with the twin goals of making the FITS table handling more
-cleanly encapsulated and of easing the addition of a mysql database
-engine in place of the FITS tables.  As programs from imregister-1.0
-are adapted to match this structure, they will be moved into the
-imregister-3.0 directory.  
-
Index: branches/ipp-magic-v0/Ohana/src/imregister/doc/ChangeLog.txt
===================================================================
--- branches/ipp-magic-v0/Ohana/src/imregister/doc/ChangeLog.txt	(revision 21062)
+++ branches/ipp-magic-v0/Ohana/src/imregister/doc/ChangeLog.txt	(revision 21062)
@@ -0,0 +1,34 @@
+
+- imregister-1-5 : 2006.08.23
+  * converted to gfits APIs (forces libfits 1.6)
+
+- imregister-1-4:
+  * dropped IMAGE_CATALOG from config
+  * fixed imageID if not in header
+  * changed mkdirhier to updated version (libohana 1.7)
+
+- imregister-1-3:
+  * modifications to use the new DVO load functions (libdvo-1-0)
+  * minor changes to use new libohana (v1.5) / libfits (v1.4)
+
+- imregister-1-2:
+  * substantial changes to use autocoded tables
+  * reorgainzation of db I/F code to use fits_db functions
+
+- imregister-1-1:
+  * I made a lot of very minor changes to cleanup the FITS database
+  * interactions.  These should not have any impact on behavior.
+
+- imregister-1-0:
+  * I've added the newest versions of imregister to the CVS tree with the
+  * base tag imregister-1-0 (should have used imregister-3-0? still
+  * learning about revision control).  
+
+comment from before importing to CVS:
+  imregister-3.0 represents a completely new organization of these
+  programs, with the twin goals of making the FITS table handling more
+  cleanly encapsulated and of easing the addition of a mysql database
+  engine in place of the FITS tables.  As programs from imregister-1.0
+  are adapted to match this structure, they will be moved into the
+  imregister-3.0 directory.  
+
Index: branches/ipp-magic-v0/Ohana/src/imregister/doc/autocode.txt
===================================================================
--- branches/ipp-magic-v0/Ohana/src/imregister/doc/autocode.txt	(revision 21062)
+++ branches/ipp-magic-v0/Ohana/src/imregister/doc/autocode.txt	(revision 21062)
@@ -0,0 +1,20 @@
+
+I have been working to convert these functions to use libautocode to
+generate the table I/O APIs automatically.  A single table defines the
+layout of the table as well as the C structure.  A perl script uses a
+template to generate code to perform the byte swaping, to construct
+the table and add data or extract data from the table.
+
+I discovered that 'photreg' was mis-coded in Fread: it was not
+swapping the entry for refcode.  I have put in a 'rawshort' method to
+handle this for now, but it is fragile: it will only work on
+big-endian machines.  The tables need to be updated and the entry
+returned to short.  This can be done with the existing convert
+operations.
+
+as of 2005/03/30, I have converted the spsearch, photsearch functions,
+but I have not completely tested them.
+
+I am having some errors in the table creation: some lines are dropping
+the leading ' in the wrong place.  
+
Index: branches/ipp-magic-v0/Ohana/src/imregister/doc/spdb.txt
===================================================================
--- branches/elixir/Ohana/src/imregister/doc/spdb.txt	(revision 2487)
+++ branches/ipp-magic-v0/Ohana/src/imregister/doc/spdb.txt	(revision 21062)
@@ -56,3 +56,23 @@
   - single FITS file
   - how to store discontiguous spectra? (MEF?)
-  - 
+
+
+-------------------------------------------
+
+spectra examples in hand:
+
+Keck I / HiRes : 
+     - single IRAF FITS spectra
+     - BANDIDn gives def of slice (spectrum, sigma, background, raw)
+     - WATn_001 gives units (Angstroms)     
+     - wavelength = (x-CRPIX1+1) * CD1_1 + CRVAL1
+     * how do we know the orientation?
+
+Keck I / ESI : 
+     - MEF spectra (yso/keck)
+       - spload-mef converts to a single 
+
+-----
+
+database interactions vs autocode FITS tables
+
Index: branches/ipp-magic-v0/Ohana/src/imregister/doc/spdb2.txt
===================================================================
--- branches/ipp-magic-v0/Ohana/src/imregister/doc/spdb2.txt	(revision 21062)
+++ branches/ipp-magic-v0/Ohana/src/imregister/doc/spdb2.txt	(revision 21062)
@@ -0,0 +1,58 @@
+
+metadata to extract:
+
+typedef struct {
+  char filename[64];
+  char pathname[128];
+  char instrument[32];
+  char telescope[32];
+  char objname[64];
+  char extname[64];
+
+  float ra, dec;
+  float exptime;
+  float airmass;
+
+  float W0, W1, dW;
+  int Nspec;				/* number of spectra associated with entry */
+
+  char mode;			/* PHU, MEF, EXT */
+  char state;			/* image state: raw, flx, etc */
+  char flag;			/* image status flags */
+  char junk[9];
+
+  unsigned long int obstime;
+  unsigned long int regtime;
+} Spectrum;
+
+
+FITS Keywords for metadata
+
+case 1:
+NAXIS  = 1
+NAXIS1 = Nw
+
+case 2:
+NAXIS  = 2
+NAXIS1 = Nw
+NAXIS2 = 1
+
+case 3:
+NAXIS  = 2
+NAXIS1 = 1
+NAXIS2 = Nw
+
+case 4:
+NAXIS  = 2
+NAXIS1 = Nw
+NAXIS2 = n   (flux, dflux, etc)
+
+case 5:
+NAXIS  = 3
+NAXIS1 = Nw
+NAXIS2 = 1
+NAXIS3 = n   (flux, dflux, etc)
+
+0         1         2         3         4         5         6         7         8
+012345678901234567890123456789012345678901234567890123456789012345678901234567890
+/data/elixir2/datdir/megacam/03Am02/taurus/L1551/VLT/spectra/2002.04.01