Mailman 3 September 2014 - scikit-image

Re: Image class
by François Boulogne Sept. 2, 2014

Sept. 2, 2014

> Do we have some use cases for this? When it comes to API design, it > always helps to have some concrete examples. It sounds like, at the > moment, we may have spacing and masks? Just a comment. I'm discovering trackpy (an excellent particle tracking library, at least for my usage) and they developed pims to load image stacks. I believe the use case can be useful for the discussion. Here is an example: http://nbviewer.ipython.org/github/soft-matter/pims/blob/master/examples/lo… They use skimage behind the scene. :) https://github.com/soft-matter Best, -- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

2 1

Image class
by Juan Nunez-Iglesias Sept. 1, 2014

Sept. 1, 2014

Hi everyone, I generally love scikit-image’s approach of a numpy array is identically an image, with no added cruft. Having a subclass can be problematic, as we saw with the various bugs caused by things like: ```python >>> im[0, 0] Image([255], dtype=np.uint8) ``` However, watching the below talk from Image.jl’s Tim Holy, I was reminded of the importance of metadata in a lot of image processing: https://www.youtube.com/watch?v=FA-1B_amwt8 (Incidentally, the talk is worth watching, especially towards the end when he talks about performance tricks.) Someone (I forget who, sorry!) told me that they’d solved the slicing/scalars problem in a different numpy wrapper, so that might be feasible if we went back to having a light numpy array subclass, which could have a simple metadata attribute in the form of a dict with arbitrary keys (with some prescriptions, such as “spacing” for the resolution, same as we have prescribed ranges for specific image data types). Alternatively, we might want to have a unified “metadata” dictionary format that would unwrap nicely into our preferred kwarg format, e.g. if we did `slic(image, **metadata)` it would just work. Just a couple of ideas. There may be other solutions, but my main point is that we might want to unify our metadata handling, rather than letting the user always worry about it. Thanks for listening! =) Juan. — Sent from Mailbox

4 3

Re: Image class
by Thomas Caswell Sept. 1, 2014

Sept. 1, 2014

You can get around some of the issues with slicing out scalars by being careful with how some of the function are overloaded (and an outstanding bug in numpy https://github.com/numpy/numpy/pull/4619). An example of this is https://github.com/soft-matter/pims/blob/master/pims/frame.py The light-weight numpy wrapper is a convenient thing for handling I/O I think that having a preferred set of kwargs and up-packing into functions is a better course for libraries as it is (more) agnostic to how the users want to deal with their data. Having to do >> slic(image_subclass, **image_subclass.md) is less annoying than having to do >> tmp_image = SkImg_ndsbuclass(my_data, my_meta_data) >> slic(tmp_image) Tom On Mon, Sep 1, 2014 at 3:23 PM, Matthew Brett <matthew.brett(a)gmail.com> wrote: > Hi, > > On Mon, Sep 1, 2014 at 2:45 AM, Guillaume Gay > <guillaume(a)mitotic-machine.org> wrote: >> Hi all >> >> +1 on metadata handling, it is surely of prime importance. >> >> Maybe this is far too domain specific, but I would suggest relying on >> OME.XML tags as keys for the metadata dic (or the subset of it that concerns >> images). The whole schema can be found here: >> http://www.openmicroscopy.org/Schemas/OME/2011-06/ome.xsd >> >> Those tags are used in the ome.tiff format, and are recognized by lots of >> tools, of which by C. Gohlke's tifffile.py is used as io in skimage... >> >> Of course that doesn't have the out of the box advantage of being able to >> call func(image, **metadata). >> >> One last advantage is providing an easy route to persistence via the >> ome.tiff image format. >> >> Best, >> >> Guillaume >> >> >> Le 01/09/2014 08:03, Juan Nunez-Iglesias a écrit : >> >> Hi everyone, >> >> I generally love scikit-image’s approach of a numpy array is identically an >> image, with no added cruft. Having a subclass can be problematic, as we saw >> with the various bugs caused by things like: >> >> ```python >>>>> im[0, 0] >> Image([255], dtype=np.uint8) >> ``` >> >> However, watching the below talk from Image.jl’s Tim Holy, I was reminded of >> the importance of metadata in a lot of image processing: >> >> https://www.youtube.com/watch?v=FA-1B_amwt8 >> >> (Incidentally, the talk is worth watching, especially towards the end when >> he talks about performance tricks.) >> >> Someone (I forget who, sorry!) told me that they’d solved the >> slicing/scalars problem in a different numpy wrapper, so that might be >> feasible if we went back to having a light numpy array subclass, which could >> have a simple metadata attribute in the form of a dict with arbitrary keys >> (with some prescriptions, such as “spacing” for the resolution, same as we >> have prescribed ranges for specific image data types). >> >> Alternatively, we might want to have a unified “metadata” dictionary format >> that would unwrap nicely into our preferred kwarg format, e.g. if we did >> `slic(image, **metadata)` it would just work. >> >> Just a couple of ideas. There may be other solutions, but my main point is >> that we might want to unify our metadata handling, rather than letting the >> user always worry about it. >> >> Thanks for listening! =) >> >> Juan. > > We run into this a lot in brain imaging too. It made me think of some > work that Fernando Perez and Mike Trumpis were doing on attaching data > to axes: > > https://github.com/fperez/datarray > > Cheers, > > Matthew > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell(a)gmail.com

1 0

Re: IPython (Jupyter) widgets: An image convolution demo
by Stéfan van der Walt Sept. 1, 2014

Sept. 1, 2014

Hey, Tony This is an awesome demo! Apologies, I broke the link in your blog to your tutorial on GitHub by reorganizing things a bit. For extracting the window, you can perhaps also look at the window extraction functions in skimage.util. Stéfan

1 0

IPython (Jupyter) widgets: An image convolution demo
by Tony Yu Sept. 1, 2014

Sept. 1, 2014

I've been meaning to write up a post on an IPython widget I created for the scikit-image tutorial at SciPy 2014. I had hoped to do it before EuroSciPy, but, alas, that was not meant to be. (BTW, it looks like the EuroSciPy sprint was *really* productive.) In any case, I finally followed through on it: http://tonysyu.github.io/ipython-jupyter-widgets-an-image-convolution-demo.… I hope it'll be useful to some of you! -Tony

1 0