Mailman 3 October 2011 - scikit-image

Re: Pull request: morphology fix
by Ralf Gommers 20 Oct '11

20 Oct '11

2011/10/19 Stéfan van der Walt <stefan(a)sun.ac.za> > On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > I'm definitely in favor of not requiring specific input dtypes. > > Unfortunately, I believe a lot of extensions assume uint8 (at least those > in > > the cmorph.pyx do). Since img_as_uint casts values to uint16, should > these > > functions be written to use uint16? Also, are there ways to write fast > > Cython extensions without specifying dtypes? > > Unfortunately, I don't know of any way to write type-agnostic code > with Cython (it is very high on my wish-list). I've even considered > whether we should use C++ to template code, and then simply wrap that > in Cython. > > Does anyone here have experience with such approaches? > > scipy.interpolate has Cython code with simple Mako templating, look at interpnd.pyx and generate_interpnd.py. If it's flexible enough for your needs then it'll be a lot more pleasant than using C++. Cheers, Ralf

1 0

Re: Pull request: morphology fix
by Andreas Mueller 19 Oct '11

19 Oct '11

On 10/19/2011 12:50 AM, StÃ¯Â¿Â½fan van der Walt wrote: > On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu<tsyu80(a)gmail.com> wrote: >> I'm definitely in favor of not requiring specific input dtypes. >> Unfortunately, I believe a lot of extensions assume uint8 (at least those in >> the cmorph.pyx do). Since img_as_uint casts values to uint16, should these >> functions be written to use uint16? Also, are there ways to write fast >> Cython extensions without specifying dtypes? > Unfortunately, I don't know of any way to write type-agnostic code > with Cython (it is very high on my wish-list). I've even considered > whether we should use C++ to template code, and then simply wrap that > in Cython. > > Does anyone here have experience with such approaches? At my lab we have a heavily templated C++ library that we exposed to Python with Boost::Python. That takes care of all overloading and is pretty convenient. Using pyublas one simply gets a ublas matrix of the type of the numpy array. I have not much experience with Cython so I don't know how interfacing the C++ with Cython would work... Cheers, Andy

1 0

Re: A bit of history and the bilateral filter
by Andreas Mueller 19 Oct '11

19 Oct '11

Am 14.10.2011 10:53, schrieb StÃ¯Â¿Â½fan van der Walt: > On Thu, Oct 13, 2011 at 8:06 PM, Tony Yu<tsyu80(a)gmail.com> wrote: >> Just for reference, there's also an implementation of the bilateral filter >> in cellprofiler: >> >> https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/cellprofiler… >> >> I haven't really looked into either of these, so I'm in no way suggesting >> that one is better than the other. > The implementation I referred to is just a naÃ¯Â¿Â½ve version, without any > optimisation; I know it can be done more efficiently. We should > benchmark the two, at least. > > Cheers > StÃ¯Â¿Â½fan If any one wants to dig in to bilateral filtering, maybe they are also interested in non-local means. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.9157&rep=rep1&…> It is a somewhat generalized version that is quite near the state of the art and would also be pretty cool to have :) Cheers, Andy

3 3

Re: Pull request: morphology fix
by Stéfan van der Walt 19 Oct '11

19 Oct '11

On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > I'm definitely in favor of not requiring specific input dtypes. > Unfortunately, I believe a lot of extensions assume uint8 (at least those in > the cmorph.pyx do). Since img_as_uint casts values to uint16, should these > functions be written to use uint16? Also, are there ways to write fast > Cython extensions without specifying dtypes? Unfortunately, I don't know of any way to write type-agnostic code with Cython (it is very high on my wish-list). I've even considered whether we should use C++ to template code, and then simply wrap that in Cython. Does anyone here have experience with such approaches? As for this specific problem, I think it's best to use uint16 or float as computation types where possible. Regards Stéfan

1 0

Re: Skeletonization
by Emmanuelle Gouillart 19 Oct '11

19 Oct '11

On Tue, Oct 18, 2011 at 12:20:54PM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > Hi Neil > On Fri, Oct 14, 2011 at 11:46 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > > As you can see, the results are very different. Once again, there are > > situations where both are useful. The former keeps an indication of > > size, while the latter keeps only topology. > I propose that we merge yours as "skeletonize" and the CellProfiler > version as "medial_axis" if, in fact, that is the algorithm they > implement. Yes, their algorithm computes the medial axis (as the ridges of the distance transform). I'm currently working on refactoring their algorithm. As for Neil's version, we're not far from merging, there are just a few minor changes to be done! Cheers, Emmanuelle

1 0

Re: Pull request: morphology fix
by Tony Yu 19 Oct '11

19 Oct '11

2011/10/18 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi Tony > > On Sat, Oct 15, 2011 at 1:58 AM, Tony Yu <tsyu80(a)gmail.com> wrote:> > The open/close operations aren't that bad: they just shift features. > But, > > when calling white/black tophat operations, the shifting can lead to > > over/underflow of pixels. I've attached examples of the lena image after > > calling white tophat, both before and after the fix. The underflow should > be > > apparent in the first image. > > Thanks for investigating and fixing this subtle bug. Talking about > data-types, we should gradually move towards using the data type > helper utilities, and thereby avoid possible over and underflow > issues. > I'm definitely in favor of not requiring specific input dtypes. Unfortunately, I believe a lot of extensions assume uint8 (at least those in the cmorph.pyx do). Since img_as_uint casts values to uint16, should these functions be written to use uint16? Also, are there ways to write fast Cython extensions without specifying dtypes? Best, -Tony

1 0

Re: Renaming / 0.4 timeline
by Emmanuelle Gouillart 19 Oct '11

19 Oct '11

On Tue, Oct 18, 2011 at 12:27:00PM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > Hi all, > Here's a proposed timeline for the renaming and release process: > Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress > made against the current repo > Sun Oct 23rd : Rename the repository, update documentation, test > Mon Oct 24th to Fri Oct 21st : Apply bugfixes, add features, etc. do you mean: to Fri Oct 28th? > required for 0.4, including polishing the Debian package > Oct 22-23 : Release v0.4 28-29 ?

2 1

Renaming / 0.4 timeline
by Stéfan van der Walt 19 Oct '11

19 Oct '11

Hi all, Here's a proposed timeline for the renaming and release process: Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress made against the current repo Sun Oct 23rd : Rename the repository, update documentation, test Mon Oct 24th to Fri Oct 21st : Apply bugfixes, add features, etc. required for 0.4, including polishing the Debian package Oct 22-23 : Release v0.4 How does that sound? Regards Stéfan

1 0

Re: Skeletonization
by Stéfan van der Walt 19 Oct '11

19 Oct '11

Hi Neil On Fri, Oct 14, 2011 at 11:46 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > As you can see, the results are very different. Once again, there are > situations where both are useful. The former keeps an indication of > size, while the latter keeps only topology. I propose that we merge yours as "skeletonize" and the CellProfiler version as "medial_axis" if, in fact, that is the algorithm they implement. Regards Stéfan

1 0

Re: Pull request: morphology fix
by Stéfan van der Walt 19 Oct '11

19 Oct '11

Hi Tony On Sat, Oct 15, 2011 at 1:58 AM, Tony Yu <tsyu80(a)gmail.com> wrote:> The open/close operations aren't that bad: they just shift features. But, > when calling white/black tophat operations, the shifting can lead to > over/underflow of pixels. I've attached examples of the lena image after > calling white tophat, both before and after the fix. The underflow should be > apparent in the first image. Thanks for investigating and fixing this subtle bug. Talking about data-types, we should gradually move towards using the data type helper utilities, and thereby avoid possible over and underflow issues. Regards Stéfan

1 0