scikit-image July 2014

scikit-image@python.org

13 participants
39 discussions

by Emmanuelle Gouillart

Hi FranÃ¯Â¿Â½ois, that's an excellent question, and not a troll :-). Opencv is a very powerful library, but it focuses primarily on computer vision (feature detection and extraction, classification, ...), as opposed to image processing in general (with other tasks such as denoising, segmentation, ...). The other big difference is that skimage builds on numpy ndarrays, and uses the full power of the numpy API (including of course the basic facilities for processing arrays as images that come with numpy), as well as some of scipy functions (you could have added scipy.ndimage to your list -- a few functions in skimage are wrappers around scipy.ndimage, that exist for the sake of completeneness). One important consequence is that algorithms working for 3-d or even n-d images can be easily implemented in 3-d/n-d in skimage, whereas opencv is restricted to 2-D images (as far as I know). Thanks to the use of numpy arrays, the API of skimage is also quite pleasant for a numpy user, more than the API of opencv. A related difference is that skimage is written in python and cython, whereas opencv is a C++ library. The two libraries attract a different crowd of developers, and a Python/Cython toolkit based on numpy arrays is easier to develop and maintain inside the Scientific Python ecosystem. I'm sure that other devs/users will have things to add to this discussion! Cheers, Emmanuelle On Thu, Dec 27, 2012 at 02:06:08PM -0800, FranÃ¯Â¿Â½ois wrote: > Hi users and devs, > It came to my knowledge that another python library (based on C++ and C > codes) for image processing exists too : opencv > I understand that numpy intregrates some basic features and we need some > advanced features but I have the feeling that skimages is redoundant with > opencv in some ways. > What's the position of skimage about that? (Don't read this question as a > troll but like a real question). > I mean that similar features exist in both. Would not be possible to > reuse/integrate opencv or merge? what's the reason for keeping them apart? > My observation is there is 4 libraries to manipulate images: > * PIL > * numpy > * skimages > * opencv > That's a lot. > Cheers,

5 years, 4 months

Analyse images

by Raphael Okoye

hi all, I want to analyze these images. See links below. The background and the crystals have the same color thus, making it difficult to segment. And since the background and crystals have the same color, it is difficult to simply subtract the background. Please, I need ideas on how to proceed with this analysis. Thanks. Raphael. https://drive.google.com/file/d/0B6nj1d7RmQ7TRmNwZzI1ajdhbFk/edit?usp=shari… https://drive.google.com/file/d/0B6nj1d7RmQ7TUUNpNEl4VzlWOEE/edit?usp=shari… https://drive.google.com/file/d/0B6nj1d7RmQ7TcHpoNjM0ZFhSZ1U/edit?usp=shari…

7 years, 5 months

Re: adding ability to import and export PIL image objects from memory

by Adam F

On Friday, July 25, 2014 10:53:15 AM UTC-7, Stefan van der Walt wrote: > > Sure, I'll have a look. > Thanks Stéfan! cheers adam

7 years, 6 months

adding ability to import and export PIL image objects from memory

by Adam F

Hi, I'm a first-time contributor to scikit-image. Me and my team ran into a problem yesterday - we want to import and export PIL images into scikit-image without reading or writing from disk. The current version of pil_plugin.py doesn't have APIs for this. I refactored the plugin a bit to add APIs for importing and exporting PIL images directly. Here's the pull request: https://github.com/scikit-image/scikit-image/pull/1083 I'm not sure who to ask - but will someone review this pull request and let me know if there are problems with it? Or if it could be improved? cheers adam -- Adam Feuer Seattle, WA, USA

7 years, 6 months

nd2 support

by jim＠rybarski.com

I'm looking for something that can directly read .nd2 files (an undocumented Nikon format that seems to be similar to multipage TIFFs). I've found this: https://pythonhosted.org/SLOTH/_modules/sloth/read_nd2.html which sorta works, though I'd like to clean it up and get it working in scikit-image. But before I dive into that, I'd like to know: 1) Is there a better implementation somewhere, or does anyone have experience parsing .nd2 files? 2) Since the format can contain hierarchical and multidimensional image sets, would this require a new kind of abstraction for the io module? To give a concrete example, the microscope data I'm working with contains 16 fields of view from different xy-positions on the sample slide, and in each field of view there are three images for each time index (different fluorescence filters). So while it would make sense to use io.MultiImage for any given combination of field-of-view and filter, it wouldn't make sense to do so for the entire nd2 file. I'm thinking perhaps there could be some kind of intermediary object that allows you to drill down through the hierarchy and at the end it returns a MultiImage object, or something like that. I'd appreciate any suggestions and I'd love to hear what everyone thinks. Thanks!

7 years, 6 months

Clarification on Transform classes description

by Eduardo Henrique Arnold

Hi. I have been trying to use the *ProjectiveTransform* class to fix perspective deformation and it took me a while to realize the *estimate* method uses (x, y) coordinates and that was the source of my unexpected results. Even though the vector is described in the class description, I think it should either explicitly define the form of coordinates or use the default convention for images (y, x). I appreciate your attention, Eduardo.

7 years, 6 months

Re: Question: Placement of channels as the last axis - is this a sensible memory layout?

by Patrick Snape

Hi Juan, Thanks for getting back to my lengthy post! I assumed that it was convention. As you said, we originally followed this scheme when we moved from Matlab and have only recently realised that it makes complete sense for Matlab to have that format, but not for us. It's also true that packages such as PIL return images in that format (presumably to maintain consistency with file formats, as you mentioned). I agree that it makes more sense from a notational perspective, however, channels first allows you to do really nice things like: for channel in image: channel[i, j] which I like a lot. My follow up was merely going to be more of a comment that a question to be honest. I just wanted to make sure I wasn't missing a trick somewhere whereby all my woes could be fixed via some magic I had failed to see. In our package, we implement a lot of image alignment methodologies and thus computations like the gradient etc are more important to us than treating channels as related features. We are very interested in algorithms like HOG, DSIFT, LBP that treat all the channels separately, so I'm seriously considering flipping our image type to get the performance boost. It's just that I also dislike the idea of losing our current simple compatibility with scikit-image! I will think hard on it. Thanks again for the reply! On Wednesday, 16 July 2014 23:17:02 UTC+1, Juan Nunez-Iglesias wrote: > > Hey Patrick, > > Good question! And one that I've thought about repeatedly. In my own work > I usually "unwrap" the channels as the first step of my analysis, for the > reasons you've outlined. > > All these conventions were in place when I got into image analysis so I > can't comment on the history, but I can offer a few hypotheses: > > 0. Image storage formats group the channels together by default (e.g. > TIFF). > 1. Matlab uses this convention, where it actually makes computational > sense since they use column-major array storage. > 2. It makes sense from a notational perspective: image[i, j] -> color. > 3. It actually is useful for certain functions, such as SLIC, in which all > the channels are considered together. > > I'm guessing you are also interested in a follow-up question, namely, is > this ever likely to change, to which I would say, probably not, as the > convention is too embedded in the collective consciousness. In applications > where each channel requires separate processing, storing the channels as > separate grayscale files might make sense as a workaround. > > Juan. > > > > On Wed, Jul 16, 2014 at 11:18 AM, Patrick Snape <patric...(a)gmail.com > <javascript:>> wrote: > >> Hi, >> >> I'm one of the maintainers of a project that has some overlap with >> scikit-image. Recently, I've been working on optimising some of our slower >> code paths, and I came across an interesting result. In our package, we >> order our image data in the same way as in scikit-image: >> >> image.shape = [height, width, channels] >> >> Given that cPython runs on top of C, this means that the normal memory >> layout is generally row-major. Therefore, in the C-contiguous layout of the >> above memory pattern, it means that the rightmost channel indexes fastest. >> For example, when iterating over a vectorised image (stolen shamelessly >> from Wikipedia): >> >> int A[2, 3, 4] = np.array([[[1,2,3,4], [5,6,7,8], [9,10,11,12]], [[13,14,15,16}, [17,18,19,20], [21,22,23,24]]) >> >> >> >> We walk that memory: >> >> >> >> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 >> >> >> >> Practically, this means that we can most efficiently walk along the channels. >> >> >> However! In my experience, especially with 2D images, you usually store most of your relationships across the image and leave the channels as independent of one another. A simple example of this, and the one I was considering, is calculating the gradient of a multi-channel image (so a 3 channel RGB image will return a 6-channel image that represents the x and y gradient over each channel R, G and B). >> >> >> Now, by calculating the gradient on a [height, width, channels] image, I have to jump a lot further in memory to find my neighbours, because I'm also skipping over channels. This is actually very inefficient, and in my testing (implementing the gradient method in cython) this actually causes a huge bottleneck. For example, the more channels you have, the closer in performance my code comes to Numpy's pure Python gradient implementation. This is because both pieces of code are being hurt by having to work 'against' the memory layout. >> >> >> A practical example of this can be seen here: http://nbviewer.ipython.org/gist/patricksnape/7b31c14c7103c2995956 >> >> >> As mentioned, I have some code I've been working on that implements the gradient directly in Cython and uses OpenMP to parallelize the gradient over the channels, which is *significantly* faster for the channels first case. >> >> >> So, my question is: *why did you choose to place the channels on the last axis rather than the first?* >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image...(a)googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > >

7 years, 6 months

Re: Make Pillow a requirement

by Jonathan Helmus

The original reason for suggesting making Pillow a requirements is that during the SciPy conference sprints Juan and I found that the unit tests were failing when only the modules required for scikit-image were installed. I think parts of this should be fixed by Pull Request #1060 [1] which will make the matplotlib related tests skippable. This was compounded by the fact that the version of Pillow Continuum's provides for windows is broken, and the version of QT they link matplotlib to has some issues. Let me do some additional testing and see if this is still an issue, if it is I'll open a GitHub issue. If anyone is interested there is an MIT licensed pure Python PNG reader at: https://github.com/drj11/pypng. Cheers, - Jonathan Helmus [1] https://github.com/scikit-image/scikit-image/pull/1060 On 07/16/2014 05:25 PM, Juan Nunez-Iglesias wrote: > @stefanv, despite the possibility of getting imread included in > Anaconda, I would argue that it's better to go with the most widely > supported package by default. Will you also campaign to have it > included in Canopy, NeuroDebian, Python(x,y), etc.? > > @jjhelmus and I also looked into grabbing BSD-licensed, pure Python > readers for TIFF, PNG, and JPEG, and including them in our code, to > fall back on when none of the plugins are available. As I recall we > found a candidate for PNG but I don't remember continuing on the > search for a JPEG reader... > > Patrick, thanks for the input! Hopefully the Pillow package will be > updated in Anaconda soon! I would not be happy shipping a release with > a vaguely-supported workaround as a dependency. > > > On Wed, Jul 16, 2014 at 10:36 AM, Patrick Snape > <patricksnape(a)gmail.com <mailto:patricksnape@gmail.com>> wrote: > > There is currently a bug in the Anaconda repositories whereby > Anaconda ship, by default, a package they call 'imaging'. This > seems to be some custom version of Pillow, as it still namespaces > the PIL Image class. Pillow, on the other hand, is incorrectly > linked against the libraries that Anaconda ships on Windows, and > so lots of things will fail. I've opened this bug here: > > https://github.com/ContinuumIO/anaconda-issues/issues/30#issuecomment-42466… > > I've resolved this at the moment by requiring the `imaging` > package instead of `pillow` within my conda build script (for a > project I maintain). > > > On Friday, 11 July 2014 17:31:39 UTC+1, Juan Nunez-Iglesias wrote: > > Hey Stefan, > > Pillow is in conda, imread is not. My experimentation over the > last 15 minutes suggests that it will be much more of a > challenge to install imread than pillow. (I'm also not sure > whether imread supports Python 3 and that's why things are > failing.) > > I also just saw @jjhelmus's email so maybe PIL should throw > its hat into the ring... > > > On Fri, Jul 11, 2014 at 10:44 AM, StÃ©fan van der Walt > <ste...(a)sun.ac.za> wrote: > > Hi Juan > > > On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias > <jni....(a)gmail.com> wrote: > > Cheap solution: make Pillow a requirement. > > My suggestion last time was to make 'imread' a > requirement--what do you think? > > StÃ©fan > > -- > You received this message because you are subscribed to > the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails > from it, send an email to scikit-image...(a)googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to scikit-image+unsubscribe(a)googlegroups.com > <mailto:scikit-image+unsubscribe@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to scikit-image+unsubscribe(a)googlegroups.com > <mailto:scikit-image+unsubscribe@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout.

7 years, 6 months

Re: Make Pillow a requirement

by Patrick Snape

There is currently a bug in the Anaconda repositories whereby Anaconda ship, by default, a package they call 'imaging'. This seems to be some custom version of Pillow, as it still namespaces the PIL Image class. Pillow, on the other hand, is incorrectly linked against the libraries that Anaconda ships on Windows, and so lots of things will fail. I've opened this bug here: https://github.com/ContinuumIO/anaconda-issues/issues/30#issuecomment-42466… I've resolved this at the moment by requiring the `imaging` package instead of `pillow` within my conda build script (for a project I maintain). On Friday, 11 July 2014 17:31:39 UTC+1, Juan Nunez-Iglesias wrote: > > Hey Stefan, > > Pillow is in conda, imread is not. My experimentation over the last 15 > minutes suggests that it will be much more of a challenge to install imread > than pillow. (I'm also not sure whether imread supports Python 3 and that's > why things are failing.) > > I also just saw @jjhelmus's email so maybe PIL should throw its hat into > the ring... > > > On Fri, Jul 11, 2014 at 10:44 AM, Stéfan van der Walt <ste...(a)sun.ac.za > <javascript:>> wrote: > >> Hi Juan >> >> On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni....(a)gmail.com >> <javascript:>> wrote: >> > Cheap solution: make Pillow a requirement. >> >> My suggestion last time was to make 'imread' a requirement--what do you >> think? >> >> Stéfan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image...(a)googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > >

7 years, 6 months

Question: Placement of channels as the last axis - is this a sensible memory layout?

by Patrick Snape

Hi, I'm one of the maintainers of a project that has some overlap with scikit-image. Recently, I've been working on optimising some of our slower code paths, and I came across an interesting result. In our package, we order our image data in the same way as in scikit-image: image.shape = [height, width, channels] Given that cPython runs on top of C, this means that the normal memory layout is generally row-major. Therefore, in the C-contiguous layout of the above memory pattern, it means that the rightmost channel indexes fastest. For example, when iterating over a vectorised image (stolen shamelessly from Wikipedia): int A[2, 3, 4] = np.array([[[1,2,3,4], [5,6,7,8], [9,10,11,12]], [[13,14,15,16}, [17,18,19,20], [21,22,23,24]]) We walk that memory: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Practically, this means that we can most efficiently walk along the channels. However! In my experience, especially with 2D images, you usually store most of your relationships across the image and leave the channels as independent of one another. A simple example of this, and the one I was considering, is calculating the gradient of a multi-channel image (so a 3 channel RGB image will return a 6-channel image that represents the x and y gradient over each channel R, G and B). Now, by calculating the gradient on a [height, width, channels] image, I have to jump a lot further in memory to find my neighbours, because I'm also skipping over channels. This is actually very inefficient, and in my testing (implementing the gradient method in cython) this actually causes a huge bottleneck. For example, the more channels you have, the closer in performance my code comes to Numpy's pure Python gradient implementation. This is because both pieces of code are being hurt by having to work 'against' the memory layout. A practical example of this can be seen here: http://nbviewer.ipython.org/gist/patricksnape/7b31c14c7103c2995956 As mentioned, I have some code I've been working on that implements the gradient directly in Cython and uses OpenMP to parallelize the gradient over the channels, which is *significantly* faster for the channels first case. So, my question is: *why did you choose to place the channels on the last axis rather than the first?*

7 years, 6 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

scikit-image July 2014