each_channel decorator

Tony Yu tsyu80 at gmail.com
Wed Oct 17 21:48:17 EDT 2012


On Wed, Oct 17, 2012 at 4:37 PM, Stéfan van der Walt <stefan at sun.ac.za>wrote:

> On Wed, Oct 17, 2012 at 7:39 AM, Schönberger Johannes
> <hannesschoenberger at gmail.com> wrote:
> > Sounds good. Do you have a paper or any reliable source about this? Just
> interested in this...
>
> The question is, should we make this a decorator, or simply provide it
> as utility functions?  I'm wondering, because now we already have two
> different ways of handling color images: split them up, RGB, or
> convert them to LAB and apply the filter to LAB.  How do we expose
> both of these sensible alternatives to the user?
>
> We can have a *default*, so that all single-channel filters are done
> on the luminance layer, but then combine that with utility functions.
> E.g.
>
> @luminance_filter
> def gray_filter(image, ...):
>     ...
>
> gray_filter(color_image, params) --> convert to LAB, filter on L, convert
> back
> filter_layers(color_image, gray_filter, params) -> filter each layer
> separately and combine
>
> Alternatively, skip the decorators completely, and just provide two
> utility functions: filter_layers and filter_luminance.
>


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)

Here, `ab` would be some dummy value if the input image is already gray.
This is actually a bit cryptic in order to prevent special-casing for RGB
images.  Otherwise, you'd have to add some conditionals as well. And don't
even know how the layer-by-layer approach would work as a utility function.

Basically, that's all to say that I think a decorator makes a lot more
sense in this case. In fact, you can handle the different behaviors
(layer-by-layer vs lightness channel) by either introducing a parameter to
decorator or the wrapped filter (or both---the decorator parameter would
set the default, which you could override at runtime). Here's a mock up
adding a parameter to the filter:

    https://gist.github.com/3909400

The edge filter example is a bit strange: if you filter by lightness (Oops,
I called it "luminance" in the example), then you get weird results.

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20121017/cf60d5cf/attachment.html>


More information about the scikit-image mailing list