Hopefully running the functions on the initial image of intensities
rather than a thresholded image will help explain somewhat. My
explanation was a bit rushed as I wrote it before work, but I can
continue to clarify if you run into problems.
The issue with a global minimum is a well-known problem in image
segmentation. A segmentation should have a small boundary, but using
only this condition will fail: the optimal segmentation would be to
classify the whole image as either figure or background! Typically it is
resolved either by labelling some sections of the image and requiring
that they be placed in the foreground or background, or by penalizing
trivial segmentations somehow. I suggested adding a quadratic cost to
the threshold scores in order to penalize thresholds that are too close
to 0 or 255. For the array you've shown, you can get away with a pretty
low one:
c {~ (i.<./) (*:0.05*128-~{."1 c) + {:"1 c
120 2
gives a reasonable value of 120.
Marshall
On Tue, Jun 27, 2017 at 01:26:08PM -0400, Brian Schott wrote:
> Marshall,
>
> I am having some difficulty getting my head around your comments involving
> interval lists. I am still processing your ideas because I don't see how to
> put them into a strategy that deals with my diamonds.
>
> On the other hand, one of your comments regarding "Just picking the minimum
> won't work,... " has really thrown me for a little loop even in the
> strategy Raul suggested using contigmd. So I wonder if I am missing the
> point of much of your comments and you are way ahead of my thinking, to
> thinking about the lack of a meaningful global minimum and needing the
> local minimum in the middle.
>
> For example in one of my lighting situations I got the following results
> where the first column is the sampled thresholds and the second column is
> the corresponding lengths of nubbed and flattened contigmd results.
> Presumably in this example the threshold of about 118 would work well. But
> I am still working on better ways to select the sample thresholds and how
> to automate the selection of the best result.
>
> On the other hand, I need to better understand your ideas involving
> interval lists, so I am going to think about that for now, too.
>
> Thanks very much,
>
> 90 2
> 95 7
> 100 29
> 102 30
> 104 31
> 106 19
> 108 10
> 110 4
> 112 3
> 114 3
> 116 2
> 118 2
> 120 2
> 122 3
> 124 4
> 126 11
> 128 23
> 130 28
> 132 33
> 134 43
> 136 46
> 138 57
> 145 23
> 150 2
>
>
>
> On Tue, Jun 27, 2017 at 4:20 AM, Marshall Lochbaum <[email protected]>
> wrote:
>
> > A common strategy that may work for you is just to ignore the spacial
> > data and perform some sort of clustering (like k-means, with k=2) on the
> > intensities. Then classify pixels according to which cluster they fall
> > in.
> >
> > An approach that does use this data, and which I expect would be much
> > slower but somewhat more accurate, would be to use the realization that
> > a threshold that maximizes the number of contiguous 1's minimizes the
> > number of adjacent pixels which are separated by the threshold (that is,
> > adjacent 0-1 pairs). To minimize this number, we need to collect all
> > pairs of adjacent pixels, then turn consider these pairs as intervals
> > and compute for each possible threshold the number of these intervals
> > which contain it.
> >
> > I don't have any particularly clever ways to find pairs of adjacent
> > pixels. For the strictest form of adjacency, with no diagonals, the verb
> > ((}. ,.&, }:) , (}."1 ,.&, }:"1)) will get them all. Each pair should
> > then be sorted, to put them in a standard interval form.
> >
> > An efficient way to turn a list of intervals into a list of
> > number-of-intervals-containing uses an obverse of monad (I.), which I am
> > increasingly coming to believe is a major feature missing from J. To
> > wit:
> >
> > x =. 4 7 2 4 1 7 8
> > (10$0) (#/.~@])`(~.@])`[}"1 x
> > 0 1 1 0 2 0 0 2 1 0
> > I. (10$0) (#/.~@])`(~.@])`[}"1 x
> > 1 2 4 4 7 7 8
> > (/:~x) -: I. (10$0) (#/.~@])`(~.@])`[}"1 x
> > 1
> >
> > The verb ((#/.~@])`(~.@])`[}) with an appropriate left argument is an
> > left inverse to I. ignoring trailing zeros, and a right inverse to I.
> > ignoring ordering. It counts, for each number in (i.n) where n is the
> > length of the left argument, how many elements on the right are equal to
> > it. To get our interval count, we just take this count for the starts of
> > intervals, subtract the counts for ends of intervals, and do a running
> > sum:
> >
> > ]a =. /:~"1 ]10 2?@$10 NB. intervals obtained from image
> > 3 4
> > 5 9
> > 5 7
> > 0 6
> > 0 5
> > 3 6
> > 3 6
> > 1 7
> > 2 9
> > 1 4
> > +/\ -/ (10$0) (#/.~@])`(~.@])`[}"1 |:a
> > 2 4 5 8 6 7 4 2 2 0
> >
> > The above example for n=10 has counts increasing then falling, but if
> > the values in the image are clustered like yours are, then they should
> > dip in the middle. Just picking the minimum won't work, because
> > a threshold of 0 or 256 trivially maximizes contiguous 0's or 1's.
> > However, it should be possibly to either penalize values at the edges
> > (say, by adding a multiple of (*:128-~i.256) or select a local minimum
> > near the middle to obtain a threshold.
> >
> > [snip
> > ]
> >
> >
> > Marshall
> >
> > --
> (B=)
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
