Mailman 3 December 2011 - scikit-image

Video io, 'get' not working with OpenCv
by robbert 18 Dec '11

18 Dec '11

Hi All, I've wrote a little test program to a extract a frame of a video file (for processing), but I can't get it work. The video file is a compressed avi file, and can be played by the camshift.py demo of OpenCv. So I think the OpenCv bindings for python are installed correctly. import skimage from skimage.io import Video vid = Video('c:\\test.avi') frame0 = vid.get() However the above test program gives the following error: Traceback (most recent call last): File "C:\prog\skimage-test.py", line 8, in <module> frame0 = vid.get() File "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", line 279, in get return self.video.get() File "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", line 54, in get cv.Copy(img, img_mat) TypeError: CvArr argument 'dst' must be IplImage, CvMat or CvMatND. Use fromarray() to convert numpy arrays to CvMat or cvMatND I used the following versions of the software Python 2.6.4 Numpy 1.6.1 Scipy 0.9.0 skimage 0.4.2 OpenCv 2.3.1 (Rev: 4557) PyQt 4.6.2 WinXp Sp3 Am I doing something wrong? Or is there just a specific version of OpenCv required? Note that OpenCv isn't on the (optional) requirements list. I also tried to install the alternative backend, gstreamer+python bindings, but under windows this seems to be troublesome. kind regards, Robbert

3 3

Re: morphology.label() bug?
by karoyakani 18 Dec '11

18 Dec '11

On Dec 17, 3:27 am, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > On Sat, Dec 17, 2011 at 3:13 AM, Emmanuelle Gouillart > > <emmanuelle.gouill...(a)nsup.org> wrote: > >> > a = np.array([ > >> > [0,1,1,0,0,0], > >> > [0,1,1,0,1,0], > >> > [0,0,0,1,1,1], > >> > [0,0,0,0,1,0]]) > > >> This is the correct output, since the zero is not connected to any > >> other region. In fact, ndimage labels it incorrectly as: > > >> array([[0, 1, 1, 0, 0, 0], > >> [0, 1, 1, 0, 1, 0], > >> [0, 0, 0, 1, 1, 1], > >> [0, 0, 0, 0, 1, 0]]) > > > Well, this is not incorrect, since ndimage.label only labels connected > > components of the foreground (True pixels). > > Right, so zero is a magical value. I guess it's pretty easy to get > the same out of our implementation by simply masking out all > uninteresting values, and calling "unique" to get the remaining > labels? It's very useful and common that we assume Background:="0"-value pixels. ndimage and matlab do so. I don't know why skimage doesn't. Regarding connectedness, both matlab and ndimage have options of 8- connect and 4-connect. Meantime skimage has only 8-connect. Why don't we add 4-connect as an option? Regarding number of labeled regions (not counting the background regions), again matlab and ndimage compute and return it. Why don't we add it to the skimage, as it would be very useful to users? I suspect the reason why the skimage doesn't is because it currently has a vague notion on the background regions, isn't it? Regards, TJ

1 0

Re: morphology.label() bug?
by Emmanuelle Gouillart 17 Dec '11

17 Dec '11

> > a = np.array([ > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,1,1,0,0,0], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,1,1,0,1,0], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,0,0,1,1,1], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,0,0,0,1,0]]) > This is the correct output, since the zero is not connected to any > other region. In fact, ndimage labels it incorrectly as: > array([[0, 1, 1, 0, 0, 0], > [0, 1, 1, 0, 1, 0], > [0, 0, 0, 1, 1, 1], > [0, 0, 0, 0, 1, 0]]) Well, this is not incorrect, since ndimage.label only labels connected components of the foreground (True pixels). Emmanuelle

2 1

morphology.label() bug?
by karoyakani 17 Dec '11

17 Dec '11

Hi Group, lable() of my skimage 0.4.2 generates a wierd label value "2" at the bottom-right corner. a = np.array([ [0,1,1,0,0,0], [0,1,1,0,1,0], [0,0,0,1,1,1], [0,0,0,0,1,0]]) from skimage import morphology morphology.label(a) Out[]: array([ [0, 1, 1, 0, 0, 0], [0, 1, 1, 0, 1, 0], [0, 0, 0, 1, 1, 1], [0, 0, 0, 0, 1, 2]]) Is this a bug or a feature? Documentation virtually tells nothing and no example. In comparison, scipy.ndimage.label() looks behaving better in this testcase. It also allows an optional arg of 4-connected and 8-connected se and it outputs the number of labels. So I would say it appears more matured and useful to me. I may be too new and know too little about the current status and the roadmap in a big picture. Regards, TJ

2 1

Add exposure module
by Tony Yu 16 Dec '11

16 Dec '11

As suggested in the feature requests for 0.5<http://groups.google.com/group/scikits-image/msg/ddda01a609f41fd5>, I just added an exposure module<https://github.com/scikits-image/scikits-image/pull/103>with histogram equalization based on code by Jan Erik Solem<http://www.janeriksolem.net/2009/06/histogram-equalization-with-python-and.…>(with the author's permission). Anyway, please look over the pull request. It's probably a lot more complicated than it needs to (especially given the terse code that it was derived from). I took some pains to return an image of the same type as the input, and I added a histogram function which tries to figure out the correct binning for image intensities (there's probably an established way of doing this that I'm missing). Enjoy! Cheers! -Tony

1 0

Travel
by Stéfan van der Walt 14 Dec '11

14 Dec '11

Hi all, I'll be traveling to South Africa over the next few days, so until I arrive I won't have a good internet connection. If any issues arise, please ping Emmanuelle or Tony. I look forward to an inbox full of PRs upon arrival :) Cheers Stéfan

1 0

Re: skeletonize question
by Zachary Pincus 13 Dec '11

13 Dec '11

> Your wrapper is read-only, right? Any sense on how much work to make > it able to write some of these formats, as well? Nope, read-write, with basic handling for multipage files (read-write also), though I've only tested this with TIFFs. FreeImage supports a ton of image formats (read and write), all of which should work via the wrappers I wrote: http://freeimage.sourceforge.net/features.html Moreover, the library supports read/write for most of the exotic pixel types supported by some file formats. See the appendix of the documentation PDF for a full list of filetypes/pixel-types supported: http://freeimage.sourceforge.net/documentation.html Of specific interest for scientific imaging, pretty much every numpy dtype can be read/written in TIFF format, including signed/unsigned ints (8/16/32) and floats (32/64), and even complex too, for what that's worth. PNGs support greyscale/RGB/RGBA for uint8/16, and JPEGs support greyscale/RGB uint8. Filetype-specific compression options are selectable via IO flags. There's also rudimentary support in my wrappers for reading strings from image metadata (which I use for getting the info out of OME-TIFF files). This could easily be beefed up. Overall, FreeImage is a decent little library, with a reasonably clean API. I tried to keep the ctypes wrappers as simple and thin as possible: https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plug… There's a lot more functionality of FreeImage than is currently exposed, but this is a pretty good start. Zach On Dec 13, 2011, at 10:45 AM, Thouis (Ray) Jones wrote: > On Tue, Dec 13, 2011 at 16:09, Zachary Pincus <zachary.pincus(a)yale.edu> wrote: >> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote: >>> Having fought this fight far too many times, I'm beginning to think >>> there's a need for a simple, small, and fast python module wrapping >>> libtiff, libpng, and libjpeg and talking to numpy. This would handle >>> 90% or more of everyone's needs and would hopefully be simpler to >>> install and use than PIL (and would have a faster development cycle). >> >> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg? > > This is probably good enough. I admit we never tried this option with > CellProfiler. > > Your wrapper is read-only, right? Any sense on how much work to make > it able to write some of these formats, as well? > > Ray

3 3

Re: skeletonize question
by Zachary Pincus 13 Dec '11

13 Dec '11

On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote: > 2011/12/13 Stéfan van der Walt <stefan(a)sun.ac.za>: >> I am glad you showed me this example, because it also pointed out a >> problem with paletted image reading in PIL. I'm seriously considering >> just making matplotlib our default backend (except that they also have >> a PNG reading bug in older versions where images are flipped upside >> down!). > > Having fought this fight far too many times, I'm beginning to think > there's a need for a simple, small, and fast python module wrapping > libtiff, libpng, and libjpeg and talking to numpy. This would handle > 90% or more of everyone's needs and would hopefully be simpler to > install and use than PIL (and would have a faster development cycle). > > Ray Jones That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg? There are win32 DLLs available for FreeImage, but no pre-built binaries for OS X, and I don't know if many/any/all linux distros provide packages for FreeImage. Does anyone know this? Similarly, I'm not sure what the licensing issues would be for providing pre-built FreeImage libraries -- FreeImage is GPL (v2), not LGPL, and so I don't actually know whether that means pre-build FreeImage libs can be distributed with skimage or not. Zach

2 1

Re: skeletonize question
by Thouis (Ray) Jones 13 Dec '11

13 Dec '11

2011/12/13 Stéfan van der Walt <stefan(a)sun.ac.za>: > I am glad you showed me this example, because it also pointed out a > problem with paletted image reading in PIL. I'm seriously considering > just making matplotlib our default backend (except that they also have > a PNG reading bug in older versions where images are flipped upside > down!). Having fought this fight far too many times, I'm beginning to think there's a need for a simple, small, and fast python module wrapping libtiff, libpng, and libjpeg and talking to numpy. This would handle 90% or more of everyone's needs and would hopefully be simpler to install and use than PIL (and would have a faster development cycle). Ray Jones

1 0

Re: skeletonize question
by Tony Yu 13 Dec '11

13 Dec '11

2011/12/12 Stéfan van der Walt <stefan(a)sun.ac.za> > On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > > Strange: when I open "circles.png" using the matplotlib backend, I get a > > float32 array (with the white pixels equal to 0.00392157). With the PIL > > backend, I get a bool array (before your recent bug fix) or uint8 (after > the > > fix). Are you not having the same issue with matplotlib? > > While the bool type is fine (it's a black and white image), the pixel > order was completely messed up; try to display it! > Wow, when you said the pixel order was messed up, I thought you meant that it was just transposed, but it *really* is screwed up. > > In mpl, I see the same thing you do. It is because matplotlib assumes > that all images with depth < 8 is 8-bit, and therefore returns 1/255 > instead of 1. Filed here: > > https://github.com/matplotlib/matplotlib/pull/623 > Good, I thought it was just me. > > Cheers > Stéfan >

1 0