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. One other note is that performing a morphological closure on the ones will remove any small gaps left by thresholding while preserving the diamond shape. Marshall On Mon, Jun 26, 2017 at 05:54:44PM -0400, Brian Schott wrote: > In my webcam playing-card image recognizer, I am trying to set a threshold > that depends on the amount of ambient lighting on the playing cards. If the > threshold is set well than I can better distinguish between the card suits > and pips. The threshold is a number between 0 and 255 and my experience has > seen it between 100 and 180. But I have no algorithm to get a best value, > only an eyeballed acceptable value. > > My idea is to present the webcam with any card with the diamond suit and to > search for a threshold value that produces the best diamond (during the > setup period of the app usage, and then to leave the threshold value alone > later). > > The image is always inside a boolean array of shape 30 26. The center of > the array always is inside the diamond image but that's about the only > known fact, because the image can be off-center slightly and even tilted > slightly and the size of the diamond in the image is unknown. If the > threshold is set too high the boolean image is all 1s, if the threshold is > set too low, the boolean image is all 0s. (The diamond suit is easiest to > use because of its relatively regular shape on almost any card deck.) > > The two examples below are meant to show a dirty diamond and a very clean > diamond. The clean example has no holes of 0s internal to the external > perimeter of the diamond. I cannot guarantee that every image can be > captured with a perfectly clean diamond, so I would sort of like to find > the threshold that produces the diamond with the greatest number of > contiguous 1's, sort of. I feel as if there is likely to be a gradual > increase in the number of contiguous 1's in the sweetspot range of the > threshold value, but I'm not sure of this. > > I am open to other ideas for accomplishing this thresholding, btw. But > mostly I am looking for J code ideas. > > You may be able to copy and paste each example from this email. I suppose I > could > > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000100000000000 > 00000000000001110000000000 > 00000000000001110000000000 > 00000000000011111000000000 > 00000000000111111100000000 > 00000000000111101100000000 > 00000000001111111110000000 > 00000000011111111100000000 > 00000000111111111111100000 > 00000001111111111111010000 > 00000011111111111111010000 > 00000101111111111110011100 > 00001111011110110101011100 > 00000111111111111111110000 > 00000011110011100101100000 > 00000001111111111101100000 > 00000001111111110100000000 > 00000000011111110110000000 > 00000000010101010000000000 > 00000000000010110000000000 > 00000000000110111000000000 > 00000000000110110000000000 > 00000000000010100000000000 > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000000000000000 > > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000000000000000 > 00000000000000100000000000 > 00000000000001110000000000 > 00000000000001111000000000 > 00000000000011111000000000 > 00000000000111111100000000 > 00000000001111111100000000 > 00000000011111111111000000 > 00000000011111111111000000 > 00000001111111111111100000 > 00000001111111111111110000 > 00000011111111111111111100 > 00000111111111111111111100 > 00001111111111111111111100 > 00001111111111111111111000 > 00000111111111111111110000 > 00000011111111111111100000 > 00000001111111111111000000 > 00000000111111111110000000 > 00000000011111111100000000 > 00000000001111111100000000 > 00000000000111111000000000 > 00000000000111110000000000 > 00000000000011110000000000 > 00000000000011100000000000 > 00000000000001000000000000 > 00000000000001000000000000 > 00000000000000000000000000 > > > Thanks, > > > -- > (B=) <-----my sig > Brian Schott > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
