IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Ignore:
Timestamp:
Jun 4, 2005, 5:22:13 PM (21 years ago)
Author:
eugene
Message:

running sources in brightness order, using a mask

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/psphot/doc/psphot.txt

    r4114 r4115  
    11
    2 2005.04.12 : Notes on psphot
     2psphot is a stand-alone program which implements the Pan-STARRS IPP
     3object detection and analysis functions for using with individual
     4images. 
    35
    4 - psPeak, psSource, etc: should be pmPeak, pmSource, etc
    5 - pmCullPeaks: should be pmCullImagePeaks
    6 
    7 - does pmSourceMoments need an image argument?
    8 
    9 - psLibInit / p_psTimeInit
    10 
    11   we should not have to know about astronomy time concepts (ie, have a
    12   timeConfig file) in order to use the time functions for basic work.
    13   This means having a PS_TIME_UNIX which just works with the UNIX
    14   clock and avoids all initialization issues.
    15 
    16 - psImageStats is much too slow for basic median
    17   - this function does a complete sort on all pixel values.  we need
    18   to use the histogram method (spec a different type of median)
    19 
    20 - psImageStats, ROBUST_MEDIAN fails
    21 - there are errors in psVectorStats for ROBUST MEAN, STDEV (& median?)
    22   * this is ill-defined.  revise the ADD: too sensitive to the
    23   binning, smoothing scales
    24 
    25 - pmFindImagePeaks is not finding any peaks:
    26   typo in interior row section: see bug 359
    27   after this fix: PASS
    28 
    29 * p_psGetRowVectorFromImage : PASS
    30 * psGetRowVectorFromImage : PASS
    31 - both have about the same time (~15 us +/- 5us) for 2048 pix on alala
    32 
    33 * pmFindVectorPeaks : PASS (returned row data in data.U32)
    34 
    35 - # include <string.h> : needed in psMetadata.c
    36 
    37 * MyListAddPeak / pmPeakAlloc are inconsistent wrt col,row vs x,y
    38 
    39 - why does psMetadataItemAllocV allocate a string of length
    40   MAX_STRING_LENGTH for the comment, then use strncpy?
    41 
    42   should be:
    43 
    44     // set metadata item comment
    45     if (comment == NULL) {
    46         // Per SDRS, null isn't allowed, must use "" instead
    47         metadataItem->comment = psStringCopy ("");
    48     } else {
    49         metadataItem->comment = psStringCopy (comment);
    50     }
    51 
    52 psMetadataAdd -> psMetadataAddItem is all confused:
    53  - we end up with two psMetadataItemAlloc calls, when only one should
    54    be used
    55  - psMetadataItemAlloc was doing the wrong thing if the incoming data
    56    was NULL
    57  - I think the logic in this block is wrong as well. 
    58 
    59  * I fixed this in psMetadata.c
    60 
    61 2005.04.14 :
    62 
    63  - psImageStats is still much too slow
    64 
    65  - pmObjects : changed to using psArray to carry peaks / sources,
    66    rather than psList
    67 
    68  - added function pmPeaksSubset to replace pmCullPeaks
    69 
    70  - pmSourceLocalSky: added min/max fncs to force subimage to stay in
    71    image
    72 
    73  - Sx, Sy can go negative: have forced limit to 0,0
    74 
    75  - pmSourceRoughClass: implemented sigmaX, sigmaY search for stellar
    76    clump (uses pmComparePeakDescend)
    77 
    78    - the search ignores the 0,0 pixel
    79 
    80    - pmSourceRoughClass uses all detected peaks.  allow an exclusion
    81      for peak > max, peak < min?
    82 
    83    - need to push clump stats on the metadata
    84 
    85    - the source classes are assigned so they are mutually exclusive
    86 
    87    - change PS_SOURCE_OTHER to STAR?
    88 
    89  - pmSourceSetPixelCircle:
    90 
    91    - name should be pmSourceSetPixelsCircle (geometry could be an
    92      option...)
    93 
    94    - I cleaned the defined region to match the convensions of
    95      pmSourceLocalSky
    96 
    97    - truncate and force subimage to lie on image
    98 
    99    - CheckRadius2 seems like an inefficient coding
    100 
    101    - valid pixels have mask value of 1 (inverse of other funcs)
    102 
    103  - pmSourceFitModel:
    104 
    105    - num iterations is much too large
    106 
    107    -
    108 
    109 mrq:
    110 
    111  - allocate alpha, beta arrays
    112  - mrq2dcof (pars, alpha, beta)
    113  - make guess pars', alpha', beta'
    114  - mrq2dcof (pars', alpha', beta')
    115  - if (chisq < old chisq), keep new guess
    116 
    117 
    118 2005.04.19:
    119 
    120 - psMinimizeLMChi2 has some serious problems.  I re-wrote it starting
    121   from the mrqmin example in ohana.   after a variety little bugs, it
    122   seems to work quite well.  the program 'modeltest.c' runs two
    123   different gaussians through psMinimizeLMChi2, and gets the right
    124   answer quite quickly.  The first pass at the implementation had a
    125   variety of problems.  to avoid any worry about errors in the
    126   psMatrix code, I implemented psGaussJordan, basing the code on the
    127   elixir gaussj.c code.  this worked fine, and let me find the errors
    128   elsewhere in the code. the LUD version now works just the same as
    129   the GaussJ version.
    130 
    131 
    132 2005.04.21
    133 
    134 - psMinimizeLMChi2 does an excellent job now in most cases.  I am able
    135   to run pmSourceFitModel on the PSF stars quite well.  I added in the
    136   (nearly) correct errors (actually, just using sqrt(N), limiting to
    137   N>=1).  I see one problem object, which is quite faint, and does not
    138   converge well: I get very large values for x,y, Sx, Sy, etc.  I need
    139   to think about constraining these fits from running way off scale.
    140 
    141   fit:   0.123879 sec for 277 stars (gauss)
    142   fit:   0.155940 sec for 277 stars (pgauss) (!)
    143   fit:   0.153292 sec for 277 stars
    144   (0.5 msec per star)
Note: See TracChangeset for help on using the changeset viewer.