Mailman 3 November 2010 - scikit-image

anyone worked with copperhead?
by Chris Colbert Nov. 18, 2010

Nov. 18, 2010

http://code.google.com/p/copperhead/ because holy shit this looks awesome!

3 2

RFR: IO cleanup
by Stéfan van der Walt Nov. 9, 2010

Nov. 9, 2010

Hi all, At the SciPy sprint (ages ago), Chris suggested that we clean up the image loading API. The following changes simplify `imread` by removing the `dtype` argument. This allows for simpler plugins. Because `as_grey` is such a commonly used parameter, it is left in place, but now works differently: after the image is loaded, the (new) rgb2grey is simply performed on it. Please have a look at https://github.com/stefanv/scikits.image/compare/master...io_cleanup Regards Stéfan

4 20

RFR: Image-collection reader
by Stéfan van der Walt Nov. 9, 2010

Nov. 9, 2010

Please review the proposed plugin hook for an Image Collection reader: https://github.com/stefanv/scikits.image/compare/master...imagecollection Having a way to easily load and manipulate a whole collection of images would be great! Think for example, of how easily SciVi could become a usable image (gallery) viewer. Regards Stéfan

5 9

OpenCL modules
by Stéfan van der Walt Nov. 5, 2010

Nov. 5, 2010

Hi all, How do you feel about the inclusion of OpenCL-based algorithms in the scikit? Should we perhaps introduce a new module, such as scikits.image.gpu, which includes some common image processing kernels? Of course, I have no interest in re-writing PyOpenCL from scratch; that would become an optional dependency. Regards Stéfan

4 3

Re: contributing C/Cython code to the scikit
by Stéfan van der Walt Nov. 2, 2010

Nov. 2, 2010

Hi Mael On Tue, Sep 21, 2010 at 11:10 AM, mael <mael.primet(a)gmail.com> wrote: > I will try to gradually improve my python code style, have you > specifics you have seen in my code that were out of the way? I think mostly spacing issues; but those are well described in the PEP. > I removed opencv on my laptop because this wouldn't build (I'll try to > figure out why) No problem; just make sure that those changes don't get committed to your repo! > for the data types, the discussion is very interesting, > most of the algorithms could be adapted for different data-types by > some preprocessor-like translation, > however, this might create some problems (floating point comparison > etc). Plus, our feeling with the previous > library we were using (Megawave) was that it was better not to provide > an algorithm for each and every possible datatype, > as it forced the end-user to ponder whether the algorithm he was > trying to use was suited to his case etc. > But I concur that writing float (possibly float and doubles) and > integer (int and unsigned char?) arrays should be > made as easy as possible. Our thought was that two types may be manageable, but while we could always generalise to support more types, it's very hard to go back -- so I'm happy that we're taking a conservative approach here. > btw we're also interested in coding some powerful visualization > function. I guess we'd rather not clutter the scikit with dependencies > to pyQt or other libraries. > How would you go about doing something like this? Use some library > like chaco? Write from scratch a PyQt viewer? You'll be glad to discover that we already have a Qt visualisation plugin! Different "imshow" implementations are available, depending on what is available on your system. Try this: import scikits.image.io as sio print sio.plugins() sio.use_plugin('qt') imshow(...) It should pop up a qt viewer. You may also do imshow(..., fancy=True) for a display with tuning widgets (only supported on Qt currently). > I'm not really that good a coder, so I'd be happy to have you guys > refactor some of my code and tell me the best way to go about it, > particularly to avoid > copying arrays over and over. We want to have simple contiguous arrays > though, because we don't want to bother with complex array iteration > in our C code. You'll probably find that, especially for large images, it is often quicker to do a single copy (to get contiguous data) and then perform your operation. Good coding comes with practise, and we're all still learning, so you're in good company. > Is the way I'm doing it (that was given to us by Emmanuelle) the > proper way of getting our arrays as contiguous C arrays or are there > some more efficient > and/or elegant way to do this? The clearest way is probably `numpy.ascontiguousarray`. Regards Stéfan

5 37