Mailman 3 October 2012 - scikit-image

Re: Python for image processing on Wikipedia
by Luis Pedro Coelho 19 Oct '12

19 Oct '12

Fair enough. It is a pretty bad article as it is. Luis On Thursday, October 18, 2012 12:57:52 PM Thouis Jones wrote: > 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. > > Ray Jones -- Luis Pedro Coelho | Institute for Molecular Medicine | http://luispedro.org

1 0

Re: Python for image processing on Wikipedia
by Otto Fajardo 19 Oct '12

19 Oct '12

oh, I'm sorry! only now I read that opencv was already included! ... but ... for example Hough line detection, it says No in python, but I think it's in opencv (maybe I am wrong again?) http://opencv.willowgarage.com/documentation/python/imgproc_feature_detecti… By the way, another interesting library, that maybe not many people is aware of, is pink. It's opensource. It has tons of functions originally written in C, and they are now wrapping it for python. It is not numpy-friendly (apparently they want to change this now), and it's difficult to compile. But maybe interesting to take a look: http://www.esiee.fr/~coupriem/Pink/doc/html/index.html https://www.pinkhq.com/homepage/ 2012/10/18 Otto Fajardo <otto.fajardob(a)gmail.com> > Some items in python could be turned into "yes" if you take into account > opencv for python: > > http://opencv.willowgarage.com/documentation/python/index.html > http://docs.opencv.org/index.html > > > > 2012/10/18 Luis Pedro Coelho <luis(a)luispedro.org> > >> 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 >> >> -- >> >> >> >

1 0

Re: each_channel decorator
by Steven Silvester 18 Oct '12

18 Oct '12

Tony, How about a third option, computing on each channel in LAB space? elif rgb_behavior == 'lab': lab = color.rgb2lab(image) c_new = [image_filter(c) for c in np.rollaxis(lab, -1)] out = np.rollaxis(np.array(c_new), 0, 3) out = color.lab2rgb(out) I tried this with "edges", and it produced a pretty interesting image. On Wednesday, October 17, 2012 8:48:58 PM UTC-5, Tony S Yu wrote: > > > > On Wed, Oct 17, 2012 at 4:37 PM, Stéfan van der Walt <ste...(a)sun.ac.za<javascript:> > > wrote: > >> On Wed, Oct 17, 2012 at 7:39 AM, Schönberger Johannes >> <hannessch...(a)gmail.com <javascript:>> 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 > > > >

2 1

Re: each_channel decorator
by Tony Yu 18 Oct '12

18 Oct '12

On Wed, Oct 17, 2012 at 4:37 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Oct 17, 2012 at 7:39 AM, Schönberger Johannes > <hannesschoenberger(a)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

1 0

Re: Cython fused types
by Luis Pedro Coelho 18 Oct '12

18 Oct '12

Caveat: I no nothing about fused types in Cython. In mahotas, I use C++ templates to achieve a similar effect. I don't however, do all combinations. For example erode(image, structuring_element) will convert structuring_element to the type of image. This way only one instance for type is generated (also, structuring_element is guaranteed to be PyArray_CARRAY). structuring_element is often really small, so the time cost is negligable. Similarly, operations on labeled objects [for example, labeled_sum, which gives you the same of pixel values inside each region] require int32 labels, which is what ``label`` returns, but can have anything on the image side (again, only one per type, not an explosion). I think that the size of resulting binaries is quite reasonable as it is most often only an inner loop that gets replicated 6 times or so. My initial variants did generate all combinations and it rapidly became very large (a few MB for morphological functions, for example). My two euro-cent, Luis PS: support for multiple types without a performance cost was one of the original reasons why I rejected Cython in favour of C++ (the other was that, when I started mahotas, Cython was still Pyrex and still a major pain for users to install). On Friday, October 12, 2012 11:05:54 PM UTC+1, Stefan van der Walt wrote: > > On Fri, Oct 12, 2012 at 10:38 AM, Johannes Schönberger > <hannessch...(a)gmail.com <javascript:>> wrote: > > Are those binaries really that huge? I just tested this locally and the > > binaries were larger, but imho not too big. The question is who actually > > cares about a few extra KB disk space taken by a binary? > > In SciPy, we were looking at huge files, much longer compilation > times, increased memory use, etc. Maybe you can compare these factors > and see how it goes? I don't know if it can be avoided, on principle, > since you basically have to generate separate functions for each type > combination, which makes things explode combinatorially. > > Stéfan >

2 1

Re: each_channel decorator
by Schönberger Johannes 18 Oct '12

18 Oct '12

Now I understand. Thank you! > I would suggest the following instead: > Convert to LAB > Perform transform on lightness channel > Convert back to RGB Sounds good. Do you have a paper or any reliable source about this? Just interested in this... Johannes Schönberger Am 17.10.2012 um 02:41 schrieb Stéfan van der Walt <stefan(a)sun.ac.za>: > On Tue, Oct 16, 2012 at 4:59 PM, Steven Silvester > <steven.silvester(a)gmail.com> wrote: >> I would suggest the following instead: >> Convert to LAB >> Perform transform on lightness channel >> Convert back to RGB > > That seems like a sound approach to me. Tony, Andreas? > >> Because, red, green, and blue are not really independent "channels" to the human eye. I used this method on the adapthist pull request when handling RGB images. > > By the way, thanks for that PR--now that 0.7.2 is out the door, I reviewed it. > > Stéfan > > -- > >

2 1

Re: each_channel decorator
by Steven Silvester 17 Oct '12

17 Oct '12

I would suggest the following instead: Convert to LAB Perform transform on lightness channel Convert back to RGB Because, red, green, and blue are not really independent "channels" to the human eye. I used this method on the adapthist pull request when handling RGB images.

3 2

Re: each_channel decorator
by Schönberger Johannes 17 Oct '12

17 Oct '12

OK, so it is basically just a decorator which calls color.rgb2gray and passes the converted image to the function? Johannes Schönberger Am 16.10.2012 um 20:42 schrieb Stéfan van der Walt <stefan(a)sun.ac.za>: > On Tue, Oct 16, 2012 at 7:13 AM, Schönberger Johannes > <hannesschoenberger(a)gmail.com> wrote: >> Sorry, but I do not understand what this decorator does. Could you provide a short example? > > @each_channel > def some_gray_level_filter(): > return gray_image > > image = data.something() > gray_image = color.rgb2gray(image) > > some_gray_level_filter(gray_image) > some_gray_level_filter(image) <-- this works too > > -- > >

2 1

Re: each_channel decorator
by Schönberger Johannes 17 Oct '12

17 Oct '12

No problem @Tony. Sorry, but I do not understand what this decorator does. Could you provide a short example? Johannes Schönberger Am 16.10.2012 um 05:30 schrieb Tony Yu <tsyu80(a)gmail.com>: > After my failed @grayscale decorator suggestion (sorry again Johannes for all the unnecessary work this caused you), I was thinking it might be nice to add an @each_channel decorator. The basic idea is that the decorator would check if the input image is RGB, and applies the grayscale function to each channel of an RGB image. > > Cheers, > -Tony > > -- > >

2 1

Re: each_channel decorator
by Stéfan van der Walt 16 Oct '12

16 Oct '12

On Mon, Oct 15, 2012 at 8:30 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > After my failed @grayscale decorator suggestion (sorry again Johannes for > all the unnecessary work this caused you), I was thinking it might be nice > to add an @each_channel decorator. The basic idea is that the decorator > would check if the input image is RGB, and applies the grayscale function to > each channel of an RGB image. Now, here we have a winner :) Stéfan

1 0