Re: Greyscale reconstruction and merging CellProfiler code
Hey Tony On Sat, Aug 6, 2011 at 3:04 PM, Tony Yu <tsyu80@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/c081f18d9e.... 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
participants (1)
-
Stéfan van der Walt