Index: trunk/psphot/doc/psphot.txt
===================================================================
--- trunk/psphot/doc/psphot.txt	(revision 4114)
+++ trunk/psphot/doc/psphot.txt	(revision 4115)
@@ -1,144 +1,5 @@
 
-2005.04.12 : Notes on psphot
+psphot is a stand-alone program which implements the Pan-STARRS IPP
+object detection and analysis functions for using with individual
+images.  
 
-- psPeak, psSource, etc: should be pmPeak, pmSource, etc
-- pmCullPeaks: should be pmCullImagePeaks
-
-- does pmSourceMoments need an image argument?
-
-- psLibInit / p_psTimeInit
-
-  we should not have to know about astronomy time concepts (ie, have a
-  timeConfig file) in order to use the time functions for basic work.
-  This means having a PS_TIME_UNIX which just works with the UNIX
-  clock and avoids all initialization issues.
-
-- psImageStats is much too slow for basic median
-  - this function does a complete sort on all pixel values.  we need
-  to use the histogram method (spec a different type of median)
-
-- psImageStats, ROBUST_MEDIAN fails
-- there are errors in psVectorStats for ROBUST MEAN, STDEV (& median?)
-  * this is ill-defined.  revise the ADD: too sensitive to the
-  binning, smoothing scales 
-
-- pmFindImagePeaks is not finding any peaks:
-  typo in interior row section: see bug 359
-  after this fix: PASS
-
-* p_psGetRowVectorFromImage : PASS
-* psGetRowVectorFromImage : PASS 
-- both have about the same time (~15 us +/- 5us) for 2048 pix on alala
-
-* pmFindVectorPeaks : PASS (returned row data in data.U32)
-
-- # include <string.h> : needed in psMetadata.c
-
-* MyListAddPeak / pmPeakAlloc are inconsistent wrt col,row vs x,y
-
-- why does psMetadataItemAllocV allocate a string of length
-  MAX_STRING_LENGTH for the comment, then use strncpy?
-
-  should be:
-
-    // set metadata item comment
-    if (comment == NULL) {
-        // Per SDRS, null isn't allowed, must use "" instead
-        metadataItem->comment = psStringCopy ("");
-    } else {
-        metadataItem->comment = psStringCopy (comment);
-    }
-
-psMetadataAdd -> psMetadataAddItem is all confused:
- - we end up with two psMetadataItemAlloc calls, when only one should
-   be used
- - psMetadataItemAlloc was doing the wrong thing if the incoming data
-   was NULL
- - I think the logic in this block is wrong as well.  
-
- * I fixed this in psMetadata.c
-
-2005.04.14 : 
-
- - psImageStats is still much too slow
-
- - pmObjects : changed to using psArray to carry peaks / sources,
-   rather than psList
-
- - added function pmPeaksSubset to replace pmCullPeaks
-
- - pmSourceLocalSky: added min/max fncs to force subimage to stay in
-   image
-
- - Sx, Sy can go negative: have forced limit to 0,0
-
- - pmSourceRoughClass: implemented sigmaX, sigmaY search for stellar
-   clump (uses pmComparePeakDescend)
-
-   - the search ignores the 0,0 pixel
-
-   - pmSourceRoughClass uses all detected peaks.  allow an exclusion
-     for peak > max, peak < min?
-
-   - need to push clump stats on the metadata
-
-   - the source classes are assigned so they are mutually exclusive 
-
-   - change PS_SOURCE_OTHER to STAR? 
-
- - pmSourceSetPixelCircle:
-
-   - name should be pmSourceSetPixelsCircle (geometry could be an
-     option...)
-
-   - I cleaned the defined region to match the convensions of
-     pmSourceLocalSky
-
-   - truncate and force subimage to lie on image
-
-   - CheckRadius2 seems like an inefficient coding
-
-   - valid pixels have mask value of 1 (inverse of other funcs)
-
- - pmSourceFitModel:
-
-   - num iterations is much too large
-
-   - 
-
-mrq:
-
- - allocate alpha, beta arrays
- - mrq2dcof (pars, alpha, beta)
- - make guess pars', alpha', beta'
- - mrq2dcof (pars', alpha', beta')
- - if (chisq < old chisq), keep new guess
-
-
-2005.04.19:
-
-- psMinimizeLMChi2 has some serious problems.  I re-wrote it starting
-  from the mrqmin example in ohana.   after a variety little bugs, it
-  seems to work quite well.  the program 'modeltest.c' runs two
-  different gaussians through psMinimizeLMChi2, and gets the right
-  answer quite quickly.  The first pass at the implementation had a
-  variety of problems.  to avoid any worry about errors in the
-  psMatrix code, I implemented psGaussJordan, basing the code on the
-  elixir gaussj.c code.  this worked fine, and let me find the errors
-  elsewhere in the code. the LUD version now works just the same as
-  the GaussJ version.
-
-
-2005.04.21
-
-- psMinimizeLMChi2 does an excellent job now in most cases.  I am able
-  to run pmSourceFitModel on the PSF stars quite well.  I added in the
-  (nearly) correct errors (actually, just using sqrt(N), limiting to
-  N>=1).  I see one problem object, which is quite faint, and does not
-  converge well: I get very large values for x,y, Sx, Sy, etc.  I need
-  to think about constraining these fits from running way off scale.
-
-  fit:   0.123879 sec for 277 stars (gauss)
-  fit:   0.155940 sec for 277 stars (pgauss) (!)
-  fit:   0.153292 sec for 277 stars
-  (0.5 msec per star)