Roadmap to 0.4

[Stéfan van der Walt]

Hi all,

Emmanuelle mentioned that it would be useful to have a list of PRs and their
priorities for the next release.  Also read on for design decisions, and
other minor tasks.

*PRs almost ready to merge:
*
- https://github.com/scikits-image/scikits-image/pull/65
 Add medial axis skeletonization.  Neil Yager's skeletonization code has
already been merged, and this is the version from cellprofiler.

*PRs requiring minor refactoring / cleanup:
*
- https://github.com/scikits-image/scikits-image/pull/13
 Template matching.  Needs to be modified to use existing integral_image,
and the example needs to be converted to the right format.

- https://github.com/scikits-image/scikits-image/pull/61
 Fix for correctly converting alpha-layered images to gray.  It's a minor
fix, but this PR does it in the wrong place.

*PRs requiring more work:*

- https://github.com/scikits-image/scikits-image/pull/41
 Structural similarity indices.  Would be great to have, but PR comments
need to be addressed.

- https://github.com/scikits-image/scikits-image/pull/16
 Fast convolution using SSE2 instructions.  This is a proof of concept done
by Pieter Holtzhausen for GSoC.  It needs to be updated to use zeros outside
image boundaries.  We also need benchmarks, and to remove opencv
dependencies in the tests.

*Other remaining tasks:*
*
*
- Update Debian license info (I never finished this)
- Write a man-page for "scivi"
- While our Debian package should probably be "python-scikits-image", the
scikit-learn guys already called theirs "sklearn", so the Debian package
needs to be updated to this convention
- Update Cython build script to generate hashes of .pyx files so that we
don't always re-generate Cython, even on clean builds
- Write examples and docs (especially narrative docs)!

*Design Decisions:
*
- Support for multiple computation back-ends

Pieter Holtzhausen has a PR in the queue for this after his GSoC.  The idea
is to provide a way for users to write code that make use of alternative
computation backends, e.g. OpenCL, but without requiring the scikits-image
developers to pick up that burden.  For example, you could do:

use_backend('opencl')
import skimage as ski
ski.do_some_stuff()
ski.do_some_more_stuff()

The user would provide the OpenCL implementation, but can easily fall back
to pure scikits-image by removing the first line.

The question here is: are we all agreed that this is a good idea?  It
increases the package flexibility a lot, at the cost of some code complexity
(hopefully mostly hidden from the user).


Allright, I think that's about it.  We have another week to include new
changes before 0.4, so feel free to file new pull requests until then.

Thanks, all!

Stéfan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111023/18b13cba/attachment.html>