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@sun.ac.za>:
On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu <tsyu80@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
--
On Sat, Oct 20, 2012 at 2:13 AM, Schönberger Johannes < hannesschoenberger@gmail.com> wrote:
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
"Hidden" and "magic" may have been the wrong wording. Providing decorators allows filter writers to provide a default RGB behavior. There doesn't really need to be an `rgb_behavior` parameter at all (i.e. no user-settable parameter). Regardless of what the filter writer decides, the user can adapt the grayscale filter however he or she wants---either with utility functions or explicitly with, e.g., rgb2lab. My main hesitation with utility functions is that they make argument passing a bit ugly. On the other hand, I think doing it explicitly is quite involved (e.g. LAB: 1. convert to LAB, 2. grab the channel, 3. rescale values, 4. filter, 5. rescale values, 6. replace channel, 7. convert to RGB). After playing around with this a bit more, I agree that defaulting to filtering each layer of RGB images is the way to go (in most cases). -Tony 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.
Am 19.10.2012 um 23:40 schrieb Stéfan van der Walt <stefan@sun.ac.za>:
I agree that documenting the extra filter parameter could be
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
On Fri, Oct 19, 2012 at 2:31 PM, Tony Yu <tsyu80@gmail.com> wrote: problematic. I 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
--
--
participants (2)
-
Schönberger Johannes -
Tony Yu