Greyscale reconstruction and merging CellProfiler code

[Stéfan van der Walt]

Hey Tony

On Sat, Aug 6, 2011 at 3:04 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'm still interested in getting greyscale reconstruction into scikits.image.
> To that end, I've updated my branch with a tutorial demonstrating peak
> detection using reconstruction
> (https://github.com/tonysyu/scikits.image/tree/reconstruction), with

Thanks!  I'm very interested to have a look, but I see that one of the
data files (.png) is missing.  Could you add that as well?

> A couple of random notes:
> * This branch adds the ipython_directive (and ipython_console_hightlighting)
> sphinx extension, because it allows you to show code examples with text
> in-between (and still be able to access variables from previous blocks).

No problem.  I saw another pretty cool trick that the IPython and
PyMVPA guys use: they write tutorials as .py files, that are then
parsed to produce an rst file.  I'm not sure what the best way is to
do this, but their approach does have the advantage that tutorials are
simply .py files, ready for distribution, and that we can provide a
template that is super easy to modify (we really need to encourage
more people to use, test, complain and write about this package).

What do you think: what's the best way to do tutorials?

> These extensions require the latest ipython (i.e. 0.11).
> * morphology.greyscale_white_top_hat has issues with underflow because
> there's a subtraction in the algorithm and it requires uint8 images (I
> think). A similar issue came up in this
> thread: http://groups.google.com/group/scikits-image/browse_thread/thread/c081f18d9e089e6e?pli=1.
> But I guess, that applied specifically to functions using ndimage.convolve.

We should fix any such problems where we can.  I should write up the
proposed guidelines for usage of different image dtypes, but it comes
down to interpreting the different types in a set way (uint8->[0,255],
int8->[-127,127], etc.), providing the necessary utility functions,
and allowing functions to specify what type of input they allow.
Output can be whatever the functions can compute most efficiently, as
long as it is well documented.  Users can also then call a utility
function such as img_as_uint8 to convert to the specified format.

> * the morphology names seem a bit clunky to work with. For example, white
> top hat is called with "morphology.greyscale_white_top_hat". The greyscale
> routines are already isolated to morphology.grey, so maybe
> morphology/__init__.py can just call "import grey" (instead of "from grey
> import *") and then the "greyscale_" prefix can be removed from the
> functions?

Why don't we just shorten those names to morphology.grey_tophat etc.?

Looking forward to reading your tutorial!

Regards
Stéfan