Sorry about the very long delay on this, but I finally committed Mike's convolve function and tests as revision 1796.
Nirav On Fri, Oct 17, 2008 at 10:25 PM, Michael George <mdgeo...@cs.cornell.edu>wrote: > Here are the files. It turns out the actual convolution is much simpler > than the one I sent out before, since I learned about the bitmask_draw > method and just use that internally. It might be slightly slower, but it's > more likely to be correct. > > As I was coding it up, I realized I'm still not completely happy with the > interface. Which of the following two possibilities do people prefer? > > == Option 1 == > Mask.convolve(othermask, outputmask = None, offset = (0,0)): return Mask > > Returns a mask with the (i-offset[0],j-offset[1]) bit set if shifting > othermask > so that it's lower right corner pixel is at (i,j) would cause it to overlap > with self. > > If outputmask is not None, then the output is drawn onto outputmask and > outputmask is returned. Otherwise a mask of size self.get_size() + > othermask.get_size() - (1,1) is created. > > == Option 2 == > Mask.convolve(othermask, outputmask, offset = (0,0)): return Mask > Sets the ((i, j) - offset) bit of outputmask if overlap(self, othermask, > (i,j)) is true. Returns outputmask. > > Mask.convolve(othermask): return Mask > Creates a mask just big enough to hold the convolution of self and other, > and shifts the output so that it fits in the mask. Equivalent to > self.convolve(other, Mask(self.get_size() + othermask.get_size() - (1,1)), > othermask.get_size() - (1,1)) > > ==== > > The difference between the two is how the offset is treated. Both return > the same result in the single-argument case, but Option 1 explains the > multi-argument variant in terms of the single-argument variant, whereas > Option 2 explains the single-argument variant in terms of the multi-argument > invariant. I think Option 2 is simpler to explain/understand (the > lower-right corner of Option 1 just screams "off-by-one"). Option 1 is > slightly more flexible, because you can call it with 2 arguments, although I > don't think there would be any reason to do that (except that the unit tests > do that). Option 1 is implemented in this tarball, although it would be > trivial to switch it to option 2 (and the code might even be > infinitestimally nicer). > > It's splitting hairs I know, but I figure the hairs should be split before > the API becomes public. > > --Mike > > > Nirav Patel wrote: > >> You can use the diff command to generate patches, but if its easier >> for you, you can just upload or email the files you changed. >> >> Nirav >> >> > >
