Mailman 3 February 2012 - scikit-image

Re: Documentation sprint over the weekend
by Stéfan van der Walt 04 Feb '12

04 Feb '12

On Thu, Feb 2, 2012 at 7:07 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I should have a little bit of free time to work on the docs this weekend. > Any specific goals? I think we should try and complete the following sections: - Introduction (installation -- link to existing docs, overview and how we fit in on top of scipy, our goals, what we provide) - Reading and displaying images (io module, display, fancy=True, using matplotlib, etc.) - Data-types and the pipeline (dtype conversion, how to ensure your output is in the right format, all functions accept any input but returns preferred dtype output--user should call img_as_*) - Getting help (reference guide, examples gallery, maybe image processing specific websites similar to metaoptimize.com/qa ) And some tutorials are always welcome--although I think the gallery now largely fulfills that role. Did I miss anything important? We also need a man-page for skivi (the image viewer). I've uploaded a template: https://github.com/scikits-image/scikits-image/blob/debian/debian/skivi.1 > One thing I'd like to see is a package docstring listing all subpackages (+ > 1-sentence descriptions of those subpackages; e.g. type `np?` in ipython); > and then each subpackage would have it's own docstring listing of functions > (e.g. type `numpy.linalg?` in ipython). I guess this is separate from the > user guide, but it's still really valuable for learning the package. Yes, good point! > While we're talking about release 0.5, I think we should try to clean out a > number of pull requests. Some of them should be quick: > > PR 99: Rewrite dtype._convert function Merged (by me). > PR 105: ENH: Allow choice between 4 and 8 neighbor mode. Merged (by Tony). > PR 95: debian/control updates to reflect name space transition Rejected (mainly adding the author's name, but very few changes). I updated the control file to be up to date in the meantime. > PR 107: Add rescale_intensity function with test and example. I'm keen to merge this; we're just waiting for the rest of the list to comment on the matplotlib 1.0 dependency. Cheers Stéfan

1 0

Re: Dependency versions
by Stéfan van der Walt 03 Feb '12

03 Feb '12

Hi Tony On Fri, Feb 3, 2012 at 7:40 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I'd like to start a discussion on how to handle versions of dependencies. > The current docs suggest that we require Numpy 1.4, but at some point we'd > probably want to increment this. In fact, I forgot that the dtype._convert > pull request (PR #99) uses the function `promote_types` from numpy 1.6. (We > need to either bump up the numpy version now or add a compatibility > function.) I think it is reasonable if the latest release of skimage relies on the latest stable release of numpy and matplotlib. > In addition, we should add a minimum (optional) version of Matplotlib for > use in examples (this has come up in a few PRs already). I recommend that we bump NumPy to 1.6 and Matplotlib to 1.0 (release 2011-01-03). The "subplots" functionality in 1.0 is really, really handy. > I run most of my scientific software from github, so I have no problem with > running the bleeding edge, but this is certainly more difficult for others. > How do other packages increment versions of dependencies? True; but I think that, if you're running old versions of numpy and scipy, running an older version of skimage should be fine. If you need the latest, then it is reasonable to upgrade those packages as well. Backward compatibility comes at a cost, unfortunately! Regards Stéfan

1 0

Fixing image loading in Python: imread
by Luis Pedro Coelho 03 Feb '12

03 Feb '12

Hi, I finally got a bit fed up with the state of reading & writing images in Python/numpy and started a new project: imread https://github.com/luispedro/imread I want it to be simple: No image processing at all, just getting the bytes out of image files and into image files. This way it has a better chance of being very stable and getting into linux distros and stuff like that. Once it matures a bit, I will use it in mahotas and I will submit a patch to scikits.learn. It currently has two functions imread : filename -> numpy array : reads a file imsave: filename & numpy array : writes a file I can imaging adding another pair to read&write to an in-memory buffer and perhaps a way to guess fileformats and retrieve metadata. But, again, there will be exactly zero image processing functions. That's for other packages to worry about. It only supports PNG at the moment (using libpng) and JPEG (through libjpeg). It needs better error checking, of course. It should be boring and solid. With TIFF, I will call it "1.0" as it will cover most use cases. What do you guys think? -- Luis Pedro Coelho | University of Lisbon | http://luispedro.org Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUu YXNjIg0KQ29udGVudC1EZXNjcmlwdGlvbjogVGhpcyBpcyBhIGRpZ2l0YWxseSBzaWduZWQgbWVz c2FnZSBwYXJ0Lg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQpWZXJzaW9uOiBHbnVQ RyB2MS40LjExIChHTlUvTGludXgpCgppRVlFQUJFQ0FBWUZBazhzRkcwQUNna1FFUTFzbU9kZ3Z2 STZQUUNlUFR6Mnd5Zk5UeGo4RnhSUHAzQUJJOTVUCnJIOEFuMm5ubGJkcDFZK3ArUXhuVVVxL205 MGF0aXhOCj1kSlF5Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

2 1

Dependency versions
by Tony Yu 03 Feb '12

03 Feb '12

Hi everyone, I'd like to start a discussion on how to handle versions of dependencies. The current docs suggest that we require Numpy 1.4<http://scikits-image.org/docs/dev/install.html>, but at some point we'd probably want to increment this. In fact, I forgot that the dtype._convert pull request (PR #99) uses the function `promote_types` from numpy 1.6. (We need to either bump up the numpy version now or add a compatibility function.) In addition, we should add a minimum (optional) version of Matplotlib for use in examples (this has come up in a few PRs already). I run most of my scientific software from github, so I have no problem with running the bleeding edge, but this is certainly more difficult for others. How do other packages increment versions of dependencies? Best, -Tony

1 0

Re: Getting Mahotas on Windows to run
by Stéfan van der Walt 02 Feb '12

02 Feb '12

Hi Thomas Welcome to the scikits-image mailing list. On Thu, Feb 2, 2012 at 12:54 PM, thomash <thomas.haslwanter(a)gmail.com> wrote: > I am fairly new to image processing in Python, and have a bugger of a > time getting Mahotas to run on my Windows machine. (Win7, 32bit, > Python 2.7). The best place to ask Mahotas questions would be on the PythonVision mailing list, where Luis is active: http://groups.google.com/group/pythonvision > My main problem seems to be related to freeimage, and I am wondering > if any of you got it running under Windows? You can also use FreeImage via scikits-image, so please try that as well and let us know: http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits.image The code snippet you need is: import skimage.io as sio sio.use('freeimage') img = sio.imread('/path/to/image.jpg') sio.imshow(img) Regards Stéfan

1 0

Getting Mahotas on Windows to run
by thomash 02 Feb '12

02 Feb '12

Hi, I am fairly new to image processing in Python, and have a bugger of a time getting Mahotas to run on my Windows machine. (Win7, 32bit, Python 2.7). In addition to installing Mahotas, I copied the "FreeImage.dll" to "C: \Python27\DLLs", the "FreeImage.h" to "C:\Python27\include", and "FreeImage.lib" to "C:\Python27\libs". My main problem seems to be related to freeimage, and I am wondering if any of you got it running under Windows? My error message: In [5]: from mahotas import freeimage ------------------------------------------------------------ Traceback (most recent call last): File "<ipython console>", line 1, in <module> File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\__init__.py", line 77, in <module> from .freeimage import imread, imsave File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\freeimage.py", line 148, in <module> _FI = _register_api(_FI, _API) File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\freeimage.py", line 102, in _register_api func = getattr(lib, f) File "C:\Python27\lib\ctypes\__init__.py", line 366, in __getattr__ func = self.__getitem__(name) File "C:\Python27\lib\ctypes\__init__.py", line 371, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: function 'FreeImage_CloseMultiBitmap' not found Any hints? Thanks, Thomas

1 0

Re: Documentation sprint over the weekend
by Tony Yu 02 Feb '12

02 Feb '12

2012/2/2 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi all, > > For release 0.5 I'd like to have a good User Guide available for skimage. > I'm going to start writing it this weekend, so if you have some spare > cycles to contribute, that'd be much appreciated! > > Also, have a look at the updated web front page <http://skimage.org>(thanks, Tony!). > > Regards > Stéfan > Hmm, I'm not sure I really deserve the credit for the front page, but thanks! I should have a little bit of free time to work on the docs this weekend. Any specific goals? One thing I'd like to see is a package docstring listing all subpackages (+ 1-sentence descriptions of those subpackages; e.g. type `np?` in ipython); and then each subpackage would have it's own docstring listing of functions (e.g. type `numpy.linalg?` in ipython). I guess this is separate from the user guide, but it's still really valuable for learning the package. While we're talking about release 0.5, I think we should try to clean out a number of pull requests. Some of them should be quick: PR 99 <https://github.com/scikits-image/scikits-image/pull/99>: Rewrite dtype._convert function There is a comment at the end of this PR suggesting we clip when converting int to uint, but maybe we should just merge this PR and add the clipping change as a new PR. In fact, if there are no objections by tomorrow, I'm just going to merge the PR as is. (No promises that I'll submit a PR for the clipping change.) PR 105 <https://github.com/scikits-image/scikits-image/pull/105>: ENH: Allow choice between 4 and 8 neighbor mode. I was waiting for a response to a few suggested changes, but they are relatively minor, so this could be merged as is. PR 95 <https://github.com/scikits-image/scikits-image/pull/95>: debian/control updates to reflect name space transition This seems like a really simple change, but since I don't really use/know-anything-about Debian, I'm hesitant to be the one to merge. PR 107 <https://github.com/scikits-image/scikits-image/pull/107>: Add rescale_intensity function with test and example. Stefan: you mentioned you wanted to send a PR to this branch. If it was an involved change, we should hold off until a later date. I'm not so certain about the others. Cheers, -Tony

1 0

Documentation sprint over the weekend
by Stéfan van der Walt 02 Feb '12

02 Feb '12

Hi all, For release 0.5 I'd like to have a good User Guide available for skimage. I'm going to start writing it this weekend, so if you have some spare cycles to contribute, that'd be much appreciated! Also, have a look at the updated web front page <http://skimage.org>(thanks, Tony!). Regards Stéfan

1 0

Feature Extraction
by Jérôme Kieffer 01 Feb '12

01 Feb '12

Hi, I wonder if you know "IPOL": http://www.ipol.im They publish articles on image processing, featuring implementations (in C/C++). I made bindings for their SIFT and SURF feature extractions & image alignment (only 2 img for now). My cython code could be released under BSD if you wish ... but beside this I don't know the license of (all) the original C++ code: "The implementation of IPOL algorithms is distributed under a free software license, usually GPL, AGPL, LGPL or BSD." It also includes Eigen: Eigen is Free Software. It is licensed under the LGPL3+. As an alternative license choice, Eigen is also licensed under the GPL2+. So LGPL3 seems to be the most permissive license achievable :-/ If it does not make sense for skimage ... I will release it elsewhere but it can interest some of yours. Cheers, -- Jérôme Kieffer <google(a)terre-adelie.org> the code is here: https://github.com/kif/surf/tree/master/features

2 1

FreeImage manitenance
by Zachary Pincus 01 Feb '12

01 Feb '12

Hi all, Apropos of the recent discussion about and troubles with diagnosing FreeImage library loading problems on 64-bit windows, I have tried to enhance the library-loading code: https://github.com/scikits-image/scikits-image/pull/117 And speaking of FreeImage and 64-bit-ness, https://github.com/scikits-image/scikits-image/pull/112 fixes some problems in 64-bit image loading, and also clarifies how to deal with 64-bit pointers and the ctypes interface. Finally, https://github.com/scikits-image/scikits-image/pull/113 builds on the changes in PR 112 to expose basic image metadata reading in a 64-bit-safe manner. Comments welcome. Zach

2 1