#802 closed defect (fixed)
pmFindVectorPeaks fails to identify two adjacent equal values as a peak
| Reported by: | Owned by: | eugene | |
|---|---|---|---|
| Priority: | highest | Milestone: | |
| Component: | objects | Version: | 0.10.0 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
The routine pmFindVectorPeaks fails to identify a sequence of values such as
10 8 20 64 229 229 6 10
as it requires that the peak pixel be strictly > (not >=) both of its neighbours. This
also means that pmFindImagePeaks fails on an image such as
(gdb) pspatch7 image 10 10
7 8 9 10 11 12 13
13 0 0 7 8 10 11 11
12 0 2 12 15 10 11 12
11 1 9 11 80 225 23 10
10 8 20 64 229 229 6 10
9 14 42 75 84 32 4 2
8 14 47 56 35 16 5 1
7 11 15 20 12 4 0 0
A fix is simple (require that the peak exceed the pixel to its left, but >= the one on
the right) but this isn't obviously good enough; it means that the left side of plateaus
is identified. I haven't looked in detail pmFindImagePeaks to see if other peak patterns
also give rise to problems. I've checked in this fix as pmPeaks.c rev 1.7
This example comes from pmSourcePSFClump where equal-valued pairs of pixels are
not improbable (1% in the data I was running).
Change History (2)
comment:1 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 17 years ago
this was fixed by rhl in r8422 (messed up the formatting in the previous entry.

this was fixed by rhl in #r8422