Mailman 3 October 2012 - scikit-image

Re: each_channel decorator
by Stéfan van der Walt Oct. 21, 2012

Oct. 21, 2012

On Sat, Oct 20, 2012 at 5:36 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > Updated @adapt_rgb: https://gist.github.com/3909400 > I'm inclined to move away from the "one decorator to rule them all" > approach, and use separate @rgb_channel_filter (or @each_channel, or > whatever), @lightness_filter, etc. This should help to preserve to docstring: http://docs.python.org/library/functools.html#functools.wraps Stéfan

1 0

Re: each_channel decorator
by Schönberger Johannes Oct. 20, 2012

Oct. 20, 2012

Hm, I get the feeling that this decorator gets too complex and "magic"… Is this really a standard use case? If someone really wants to apply a filter to the luminance channel of an image, why not let them use ***2lab function? Johannes Schönberger Am 19.10.2012 um 23:40 schrieb Stéfan van der Walt <stefan(a)sun.ac.za>: > On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >> I agree that documenting the extra filter parameter could be problematic. I >> guess that the decorator could inject that into the filter's docstring, but >> that's probably too magical. We could make it a hidden parameter and provide >> utility functions that just change the default behavior. > > I'd prefer for the parameter to be visible and documented for each > function that chooses to use it. I think we should just make > application to each individual layer the default, since that's the > most obvious generalization to RGB. > > Stéfan > > -- > >

2 1

Re: each_channel decorator
by Stéfan van der Walt Oct. 19, 2012

Oct. 19, 2012

On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > I agree that documenting the extra filter parameter could be problematic. I > guess that the decorator could inject that into the filter's docstring, but > that's probably too magical. We could make it a hidden parameter and provide > utility functions that just change the default behavior. I'd prefer for the parameter to be visible and documented for each function that chooses to use it. I think we should just make application to each individual layer the default, since that's the most obvious generalization to RGB. Stéfan

1 0

Re: each_channel decorator
by Tony Yu Oct. 19, 2012

Oct. 19, 2012

On Fri, Oct 19, 2012 at 4:35 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Oct 17, 2012 at 6:48 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > I'm not really sure how a utility function would work. Wouldn't you need > to > > provide at least 2 utility functions when converting to LAB: > > > > image, ab = prepare_rgb(image) > > # ... code to generate `filtered_image` from `image` > > filtered_image = finalize_rgb(filtered_image, ab) > > A utility function would simply take an image and apply the specified > filter to all its layers (which are pre-and post-converted in some > way), e.g. > > apply_to_rgb(image, filter) > > > Basically, that's all to say that I think a decorator makes a lot more > sense > > in this case. > > But it does mean introducing a flag. I'm debating which is clearer > and more explicit: > > apply_to_luminance(image, filter) > > vs > > filter(image, rgb_behavior='luminance') > > (with the caveat that rgb_behavior has to be documented in each and > every filter function--and that we have to figure out a way of > preserving signatures and docstrings with decorators) > > Stéfan > Oh, I see: Utility functions for users to apply a grayscale filter to their color image. I was thinking of utility functions that allows us to add RGB-handling to scikit-image functions (so that it just works without the user needing to think about it). Personally, I'd prefer RGB images to just work. For most filters, there's probably a preferred way to handle an RGB image (e.g, Lightness channel, RGB layers, grayscale), and that would just be the default (I guess the *preferred* way may not always be obvious). I agree that documenting the extra filter parameter could be problematic. I guess that the decorator could inject that into the filter's docstring, but that's probably too magical. We could make it a hidden parameter and provide utility functions that just change the default behavior. -Tony

1 0

Re: each_channel decorator
by Stéfan van der Walt Oct. 19, 2012

Oct. 19, 2012

On Fri, Oct 19, 2012 at 2:17 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > This is awesome! We need a good stock image that we can include in the > package, so that this example can be included in the docs. OK, so whoever wants to join the scikit-image team next has to prove their dedication by spreading a packet of brightly colored M&M's on a lightly colored, wooden textured surface, photograph it, and release the photo into the public domain :-) Bonus marks if you can arrange them exactly like the ones in Steve's photo! Stéfan

1 0

Re: each_channel decorator
by Tony Yu Oct. 19, 2012

Oct. 19, 2012

On Fri, Oct 19, 2012 at 4:24 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Oct 17, 2012 at 6:08 PM, Steven Silvester > <steven.silvester(a)gmail.com> wrote: > > No paper off the top of my head. I got the idea from a Matlab blog: > > http://blogs.mathworks.com/steve/2010/12/23/two-dimensional-histograms/ > > Neat! > > Here's an implementation in Python: > > > https://github.com/stefanv/scikit-image-demos/blob/master/mm_color_select.py This is awesome! We need a good stock image that we can include in the package, so that this example can be included in the docs. > Tony, what do you think about a painting / mask selection tool for the > visualization toolbox? > Yeah, this has been on my Todo list for a very long time. Unfortunately, it may have to stay there for at least another month or so. :/ Stéfan > > -- > > >

1 0

Re: each_channel decorator
by Stéfan van der Walt Oct. 19, 2012

Oct. 19, 2012

On Wed, Oct 17, 2012 at 6:48 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > I'm not really sure how a utility function would work. Wouldn't you need to > provide at least 2 utility functions when converting to LAB: > > image, ab = prepare_rgb(image) > # ... code to generate `filtered_image` from `image` > filtered_image = finalize_rgb(filtered_image, ab) A utility function would simply take an image and apply the specified filter to all its layers (which are pre-and post-converted in some way), e.g. apply_to_rgb(image, filter) > Basically, that's all to say that I think a decorator makes a lot more sense > in this case. But it does mean introducing a flag. I'm debating which is clearer and more explicit: apply_to_luminance(image, filter) vs filter(image, rgb_behavior='luminance') (with the caveat that rgb_behavior has to be documented in each and every filter function--and that we have to figure out a way of preserving signatures and docstrings with decorators) Stéfan

1 0

Re: each_channel decorator
by Steven Silvester Oct. 19, 2012

Oct. 19, 2012

No paper off the top of my head. I got the idea from a Matlab blog: http://blogs.mathworks.com/steve/2010/12/23/two-dimensional-histograms/ Empirically, when I applied an equalization to the lena image on each RGB channel, the result was a distorted image (color-wise). Applying the LAB method shed the original image of the soft focus the photographer had used, and presented a harsher lighting that showed more detail, while preserving the colors.

2 2

Re: Python for image processing on Wikipedia
by Johannes Schönberger Oct. 18, 2012

Oct. 18, 2012

> I think a better ideas is to mark the article for deletion (and I've > done so), as it's meaningless (any of those algorithms could be coded > in python, matlab, or mathematica), it doesn't list arguably more > popular image processing tools (e.g., ImageJ, OpenCV), and the list > seems arbitrarily constructed. Far better would be to add links from > each of the algorithms' pages to the software that implements that > particular algorithm. I totally agree here.

1 0

Python for image processing on Wikipedia
by Luis Pedro Coelho Oct. 18, 2012

Oct. 18, 2012

While looking for something else, I ran across this: http://en.wikipedia.org/wiki/Comparison_of_image_processing_software and added the Python column. I think some of the "No"s could be turned into "Yes"s, except that I don't know all about all Python packages. * I don't even understand what some of the headings are supposed to mean and I work in computer vision research as they seem incredibly generic. For example, "Image validate", "Image adjustment", ... Best, -- Luis Pedro Coelho | Institute for Molecular Medicine | http://luispedro.org

3 2