On Fri, Oct 19, 2012 at 4:35 PM, Stéfan van der Walt <stefan@sun.ac.za>wrote:

On Wed, Oct 17, 2012 at 6:48 PM, Tony Yu <tsyu80@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