Hi Tony. As I said, I think it is a great idea to collect the utility functions. I'm undecided on whether it is a good idea to separate them from the user utility functions. To the candidates I'd like to add the union find that I reused in my segmentation PR. Cheers, Andy On 08/17/2012 03:06 AM, Tony Yu wrote:

In PR #239 <https://github.com/scikits-image/scikits-image/pull/239#issuecomment-7792726>, Johannes suggested a new `utils` module or subpackage, which I think this is a great idea.

We currently have the `util` package, but I'm inclined to suggest a new subpackage (not named `utils` to avoid confusion). It would be nice to separate functions that would be useful to consumers of image processing functions (e.g., the dtype conversion routines in `util`) from functions that are useful to developers of image processing functions (e.g., the `shape` module in the `util` package, which has `view_as_blocks` and `view_as_windows`). I wouldn't be surprised if people think this is an arbitrary (or false) distinction.

Regardless of whether there should be a new subpackage (or if it should be put in `util`), there are a number of candidate functions that come to mind:

- rank order (`filter` package) - heap (`graph` package) - heap_* (`morphology` package) (*.pxi files?) - integral images (`transform` package). (The transform package does make sense for this, but keep in mind that this is used in other packages, e.g., `match_template` in the `feature` package.)

There are probably a number of others that I'm missing.

In the past, there have been discussions of dependency versions and adding compatibility functions so that we can support older versions of numpy, matplotlib, etc. A utility package would be good for those sorts of things.

-Tony