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)
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