From jni.soma at gmail.com Mon Sep 1 02:03:39 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Sun, 31 Aug 2014 23:03:39 -0700 (PDT) Subject: Image class Message-ID: <1409551418462.6276fcd8@Nodemailer> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Sep 1 01:19:52 2014 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 1 Sep 2014 00:19:52 -0500 Subject: IPython (Jupyter) widgets: An image convolution demo Message-ID: 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.html#.VAQBJf9Ea7o.gmail I hope it'll be useful to some of you! -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at mitotic-machine.org Mon Sep 1 02:45:06 2014 From: guillaume at mitotic-machine.org (Guillaume Gay) Date: Mon, 01 Sep 2014 08:45:06 +0200 Subject: Image class In-Reply-To: <1409551418462.6276fcd8@Nodemailer> References: <1409551418462.6276fcd8@Nodemailer> Message-ID: <540415F2.5010501@mitotic-machine.org> 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. > ? > Sent from Mailbox > -- > 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 at googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Sep 1 04:08:55 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Mon, 1 Sep 2014 09:08:55 +0100 Subject: IPython (Jupyter) widgets: An image convolution demo In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Sep 1 15:23:10 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 1 Sep 2014 15:23:10 -0400 Subject: Image class In-Reply-To: <540415F2.5010501@mitotic-machine.org> References: <1409551418462.6276fcd8@Nodemailer> <540415F2.5010501@mitotic-machine.org> Message-ID: Hi, On Mon, Sep 1, 2014 at 2:45 AM, Guillaume Gay 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 From tcaswell at gmail.com Mon Sep 1 16:42:12 2014 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 1 Sep 2014 16:42:12 -0400 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <540415F2.5010501@mitotic-machine.org> Message-ID: 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 wrote: > Hi, > > On Mon, Sep 1, 2014 at 2:45 AM, Guillaume Gay > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell at gmail.com From fboulogne at sciunto.org Mon Sep 1 20:59:59 2014 From: fboulogne at sciunto.org (=?UTF-8?B?RnJhbsOnb2lzIEJvdWxvZ25l?=) Date: Mon, 01 Sep 2014 20:59:59 -0400 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> Message-ID: <5405168F.30602@sciunto.org> > 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/loading%20video%20frames.ipynb They use skimage behind the scene. :) https://github.com/soft-matter Best, -- Fran?ois Boulogne. http://www.sciunto.org GPG: 32D5F22F From tsyu80 at gmail.com Mon Sep 1 22:16:30 2014 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 1 Sep 2014 21:16:30 -0500 Subject: Image class In-Reply-To: <5405168F.30602@sciunto.org> References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: On Mon, Sep 1, 2014 at 7:59 PM, Fran?ois Boulogne wrote: > > > 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/loading%20video%20frames.ipynb > They use skimage behind the scene. :) > > https://github.com/soft-matter > > Best, > Oh, that reminds me: I spoke with Dan Allan at the SciPy conference about integrating pims image-stacks in to what's currently `io.ImageCollection`. It sounded like a good idea, but I didn't really follow up on the idea. -T -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Sep 1 19:08:56 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Tue, 2 Sep 2014 00:08:56 +0100 Subject: Image class In-Reply-To: <1409551418462.6276fcd8@Nodemailer> References: <1409551418462.6276fcd8@Nodemailer> Message-ID: Hi Juan On Mon, Sep 1, 2014 at 7:03 AM, Juan Nunez-Iglesias wrote: > 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). Please find out how, then we can fix up the io.Image class! > 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. 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? St?fan From stefan at sun.ac.za Tue Sep 2 05:54:46 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Tue, 2 Sep 2014 10:54:46 +0100 Subject: String formatting style Message-ID: Hi all What are your opinions on http://legacy.python.org/dev/peps/pep-3101/ I see this is used in some PRs, and I'm not convinced of its readability. St?fan From stefan at sun.ac.za Tue Sep 2 06:00:17 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Tue, 2 Sep 2014 11:00:17 +0100 Subject: Travis builds are all failing Message-ID: Hi, everyone If you have time, please have a look at what is going on with Travis-CI--currently failing on all builds. Thanks St?fan From steven.silvester at gmail.com Tue Sep 2 19:41:02 2014 From: steven.silvester at gmail.com (Steven Silvester) Date: Tue, 2 Sep 2014 16:41:02 -0700 (PDT) Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: I would add that metadata about the instrument used to capture the image, such as exposure time, would be useful. From steven.silvester at gmail.com Tue Sep 2 19:55:15 2014 From: steven.silvester at gmail.com (Steven Silvester) Date: Tue, 2 Sep 2014 16:55:15 -0700 (PDT) Subject: Travis builds are all failing In-Reply-To: References: Message-ID: <5030b698-efb6-4f10-b269-5368a34ea563@googlegroups.com> St?fan, Looking through several the failing builds, a lot of them are suffering from not having the latest changes to `travis.yml`, causing the failure on Python 3.2. The other ones look like WIP failures. -Steve On Tuesday, September 2, 2014 5:00:39 AM UTC-5, Stefan van der Walt wrote: > > Hi, everyone > > If you have time, please have a look at what is going on with > Travis-CI--currently failing on all builds. > > Thanks > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmichael.aye at gmail.com Tue Sep 2 20:09:06 2014 From: kmichael.aye at gmail.com (Michael Aye) Date: Tue, 2 Sep 2014 17:09:06 -0700 (PDT) Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: <5de994ec-52b7-45ce-ab30-533cb9d9b9a9@googlegroups.com> Another implementation that already has solved the meta-data problem together with storage of affine transformation data is the OSGEO project and its GDAL raster library dataset. In general, I don't recommend trying to compete with GDAL, as it's by far the most far reaching raster reader I am aware of. ;) Michael On Tuesday, September 2, 2014 4:54:13 PM UTC-7, Thomas Caswell wrote: > > It is worth having a look at the discussion of meta data in the itk > software guide (http://www.itk.org/ItkSoftwareGuide.pdf , in > particular 4.1.4) for the importance of meta-data. > > Tom > > On Tue, Sep 2, 2014 at 7:41 PM, Steven Silvester > > wrote: > > I would add that metadata about the instrument used to capture the > image, such as exposure time, would be useful. > > > > -- > > 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... at googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Thomas Caswell > tcas... at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmichael.aye at gmail.com Tue Sep 2 20:20:40 2014 From: kmichael.aye at gmail.com (Michael Aye) Date: Tue, 2 Sep 2014 17:20:40 -0700 (PDT) Subject: String formatting style In-Reply-To: References: Message-ID: It's part of the Python tutorial for many years and common standard I'd say. It's basic use might be cumbersome at first, but its power is great. Things like "My name is {0[name]}".format(dict(name='Fred')) or "My name is {0.name}".format(open('out.txt', 'w')) lets you template-control strings in very elaborate manners. The most minimalistic way btw is: "My first name is {} and my last name is {}".format(firstname, lastname) Michael On Tuesday, September 2, 2014 7:36:44 AM UTC-7, Juan Nunez-Iglesias wrote: > > I'm not convinced either, but it seems to be what the whole community is > moving to (I saw many instances of it at PyCon-AU), so we might as well get > with the program! > > On Tuesday, September 2, 2014, St?fan van der Walt > wrote: > >> Hi all >> >> What are your opinions on >> >> http://legacy.python.org/dev/peps/pep-3101/ >> >> I see this is used in some PRs, and I'm not convinced of its readability. >> >> 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+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Tue Sep 2 22:16:21 2014 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Tue, 2 Sep 2014 19:16:21 -0700 (PDT) Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> I see this a little differently, looking at it from the viewpoint of a scientific user/new contributor. One of the biggest reasons scikit-image has been able to grow so well, so rapidly, is because the bar for entry is low for new contributors. We operate as close to the data as possible. People using Python understand NumPy arrays. This is inherently familiar to those with backgrounds like Matlab, which is likely one of, if not the, largest population we serve. We want these people to be able to contribute without massive bars to entry. If we used a custom wrapper class, even a light one, I for one would likely never have contributed to this package in the first place. Because, in order to understand what was even being fed in, I would have to dig up that wrapper, figure out what it actually contains, where my data is in it, think about how to react given different inputs, and so on. This is a tremendously daunting mental task. In short, moving to a new scheme would be, in my humble opinion, a disaster. Imagine having to explain the metadata structure of the hypothetical scikit-image construct to everyone at every SciPy Sprint, every time, before they could work with the codebase. Imagine users who want to know what the code is doing inspecting our source, seeing methods called which aren't standard NumPy methods, wondering what is going on, and having to dig through several other unclearly linked files in our repo to figure that out - if they even get that far. Many have tried to solve the image metadata/tagging problem with few real successes; either it ends up too extensible (no 1:1 mapping of tag to meaning, too much info) or too restrictive (whoops, no 3D or new modality). A perfect system gets devised at first, then edge cases become apparent, followed by workarounds, then someone comes up with a new system that includes everything to date, the API breaks to support it, repeat with new cases... if nothing else, this is a massive support headache. >From the big-picture view, *we need to decide what we are, and what we want to become*. To date, scikit-image is a powerful library of tools. We don't purport to hold users' hands through the process of implementation, and we never have. Sometimes the tools are a bit rough around the edges, and they aren't always as easy to use as they could be. But, in return, they end up exposing the maximum amount of functionality to end users. At the risk of a very stretched metaphor, the current state is a bit like Linux. Moving to towing around loads of metadata just so we can have complex, custom, branching paths behind every algorithm depending on what happens to be fed in - that's hand holding time. That's the Apple/OSX method. Yes, our package may gain a broader userbase and certain features in examples, etc. might be more elegant. But real world uses which don't follow the examples will be impeded, and more importantly we *will* alienate future potential contributors. I, for one, do not fancy implementing or maintaining the latter model. I fear for the future of the package even if we did implement it cleanly. There are aspects of the package where *limited use* of a custom wrapper would likely be reasonable, such as certain more public facing areas e.g. the Viewer, but I see these as the exception rather than the rule. My opinions on this issue are strong, but I recognize I'm only one voice. The most important thing we need to reach consensus on is the path forward, as noted above in bold. Up until now it's been rather clear, but wrapping NumPy ndarrays would start us down a very different road, one on which I fear we could easily lose our way. Josh On Tuesday, September 2, 2014 3:52:34 PM UTC+1, Juan Nunez-Iglesias wrote: > > Cool, looks like there's lots of discussion to be had about this, but all > positive ? I had expected more pushback, for some reason! =) > > @stefanv: > > Do we have some use cases for this? > > Spacing and masks, as you mentioned. > > Spatial resolutions, so we can deal with images acquired at different > resolutions, e.g. registering light and electron microscopy images of the > same sample. Also, as in Tim's talk, to allow drawing of scale bars on > displayed images. > > Image orientation and absolute coordinates, which help with registration > and montaging. > > Image acquisition date, which could be important e.g. to generate time > series. > > That's just off the top of my head, I'm sure there's more! > > @stefanv @tacaswell @tonysyu > > Please find out how, then we can fix up the io.Image class! > > Tom's link > to the solution in PIMS reminds me that it was indeed Dan who pointed out > that they'd solved the scalar issue. > > @glyg > > I would suggest relying on OME.XML > > I think that might be a little too heavy for our uses, but I might be > wrong. Either way, it's probably possible to have a compatibility layer > between XML and whatever use cases we want to follow. (e.g. Automatically > reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" > tag.) > > Juan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Tue Sep 2 22:26:21 2014 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Tue, 2 Sep 2014 19:26:21 -0700 (PDT) Subject: Travis builds are all failing In-Reply-To: <5030b698-efb6-4f10-b269-5368a34ea563@googlegroups.com> References: <5030b698-efb6-4f10-b269-5368a34ea563@googlegroups.com> Message-ID: <8e8d5612-e926-40cb-a206-732ab7caae33@googlegroups.com> The root of the issue is Matplotlib >= 1.4 no longer supports Python 3.2. But instead of actually detecting Python 3.2 and terminating the install, setup continues until the check for optional pyqt4 dependency enters a subprocess and never returns. I filed an issue with Matplotlib at the end of our EuroSciPy sprint recommending an assume-fail timeout for such subprocess; hopefully this becomes more graceful in the future: https://github.com/matplotlib/matplotlib/issues/3444 In the meantime, we can work around it either by running extra Qt tests on another Python version (which would slow Travis down; we used 3.2 for this because of the apt-get binaries for its system Python 3.2) or force pip to install Matplotlib version 1.3.1 for the Python 3.2 build. Josh On Wednesday, September 3, 2014 12:55:15 AM UTC+1, Steven Silvester wrote: > > St?fan, > > Looking through several the failing builds, a lot of them are suffering > from not having the latest changes to `travis.yml`, causing the failure on > Python 3.2. The other ones look like WIP failures. > > -Steve > > > On Tuesday, September 2, 2014 5:00:39 AM UTC-5, Stefan van der Walt wrote: >> >> Hi, everyone >> >> If you have time, please have a look at what is going on with >> Travis-CI--currently failing on all builds. >> >> Thanks >> St?fan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue Sep 2 19:54:13 2014 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 2 Sep 2014 19:54:13 -0400 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: It is worth having a look at the discussion of meta data in the itk software guide (http://www.itk.org/ItkSoftwareGuide.pdf , in particular 4.1.4) for the importance of meta-data. Tom On Tue, Sep 2, 2014 at 7:41 PM, Steven Silvester wrote: > I would add that metadata about the instrument used to capture the image, such as exposure time, would be useful. > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell at gmail.com From emmanuelle.gouillart at nsup.org Tue Sep 2 14:22:20 2014 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Tue, 2 Sep 2014 20:22:20 +0200 Subject: scribbling tool (eg for labeling markers) Message-ID: <20140902182220.GA16077@phare.normalesup.org> Hello, during the Euroscipy sprints, St??fan and Josh mentioned that they frequently use homebrewed scripts in order to scribble on an image and retrieve the coordinates of scribbled pixels, e.g. in order to determine some markers for image segmentation. St??fan or Josh, would you mind sharing snippets of code showing how this can be done? Thanks! Emmanuelle From steven.silvester at gmail.com Tue Sep 2 23:01:38 2014 From: steven.silvester at gmail.com (Steven Silvester) Date: Tue, 2 Sep 2014 22:01:38 -0500 Subject: Travis builds are all failing In-Reply-To: <3964891E-528E-4151-85A0-4146CA944B22@demuc.de> References: <5030b698-efb6-4f10-b269-5368a34ea563@googlegroups.com> <8e8d5612-e926-40cb-a206-732ab7caae33@googlegroups.com> <3964891E-528E-4151-85A0-4146CA944B22@demuc.de> Message-ID: JD, the PR that Johannes is referring to installs matplotlib 1.3.1 explicitly on Python 3.2. https://github.com/scikit-image/scikit-image/pull/1128 - Steve On Tue, Sep 2, 2014 at 9:56 PM, Johannes Sch ?nberger wrote: > Imo, I already merged a PR from Steven yesterday, which fixes this. Other > PRs just need a rebase. > > Johannes Sch ?nberger > > On Sep 2, 2014, at 10:26 PM, Josh Warner > wrote: > > > The root of the issue is Matplotlib >= 1.4 no longer supports Python > 3.2. But instead of actually detecting Python 3.2 and terminating the > install, setup continues until the check for optional pyqt4 dependency > enters a subprocess and never returns. > > > > I filed an issue with Matplotlib at the end of our EuroSciPy sprint > recommending an assume-fail timeout for such subprocess; hopefully this > becomes more graceful in the future: > https://github.com/matplotlib/matplotlib/issues/3444 > > > > In the meantime, we can work around it either by running extra Qt tests > on another Python version (which would slow Travis down; we used 3.2 for > this because of the apt-get binaries for its system Python 3.2) or force > pip to install Matplotlib version 1.3.1 for the Python 3.2 build. > > > > Josh > > > > On Wednesday, September 3, 2014 12:55:15 AM UTC+1, Steven Silvester > wrote: > > St?fan, > > > > Looking through several the failing builds, a lot of them are suffering > from not having the latest changes to `travis.yml`, causing the failure on > Python 3.2. The other ones look like WIP failures. > > > > -Steve > > > > > > On Tuesday, September 2, 2014 5:00:39 AM UTC-5, Stefan van der Walt > wrote: > > Hi, everyone > > > > If you have time, please have a look at what is going on with > > Travis-CI--currently failing on all builds. > > > > Thanks > > 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+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "scikit-image" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/scikit-image/DwrGYSfBL4s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Tue Sep 2 22:56:03 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Tue, 2 Sep 2014 22:56:03 -0400 Subject: Image class In-Reply-To: <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: I have not chimed in yet, but I can recall a discussion about the same topic a while ago. As back then, I agree with Josh, who has given some very good reasons. In addition, I would like to question the usefulness of the tightly coupled metadata in general. > 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. Honestly, I do not understand. This is already possible now? Otherwise, I agree, that it is more convenient to write `slic(image)` than `slic(image, spacing_x=metadata[?spacing_x?],?)`, where `image.metadata` is automatically mapped to kwargs. However, this requires the metadata to be standardized and homogeneous. And, at least to my experience - metadata is the one thing that is guaranteed to cause trouble, because it is not consistent. So, what happens when `spacing_x` is not called `spacing_x` but `spacingx`? ?! Either the user actually realizes that, or the ?magic?, that maps the metadata to the `slic` parameters: warns the user, silently ignores, fails, etc. All this sounds complicated and intransparent to me. I think of other use cases, where attaching the metadata directly with the image instead of having a separate dict, brings any benefit. In contrast, skimage is typically used in conjunction with other libraries, which do not know about our wrapper class. So, whenever you call a function from another library, you loose the metadata. To make it short, I am a strong proponent of making the specification of function parameters explicit, i.e. `slic(image, spacing_x=metadata[?spacing_x?], spacing_y=metadata[?spacingy?])` or `slic(image, **metadata)` which is already possible with all skimage functions. Johannes Sch?nberger On Sep 2, 2014, at 10:16 PM, Josh Warner wrote: > I see this a little differently, looking at it from the viewpoint of a scientific user/new contributor. > > One of the biggest reasons scikit-image has been able to grow so well, so rapidly, is because the bar for entry is low for new contributors. We operate as close to the data as possible. People using Python understand NumPy arrays. This is inherently familiar to those with backgrounds like Matlab, which is likely one of, if not the, largest population we serve. We want these people to be able to contribute without massive bars to entry. > > If we used a custom wrapper class, even a light one, I for one would likely never have contributed to this package in the first place. Because, in order to understand what was even being fed in, I would have to dig up that wrapper, figure out what it actually contains, where my data is in it, think about how to react given different inputs, and so on. This is a tremendously daunting mental task. > > In short, moving to a new scheme would be, in my humble opinion, a disaster. Imagine having to explain the metadata structure of the hypothetical scikit-image construct to everyone at every SciPy Sprint, every time, before they could work with the codebase. Imagine users who want to know what the code is doing inspecting our source, seeing methods called which aren't standard NumPy methods, wondering what is going on, and having to dig through several other unclearly linked files in our repo to figure that out - if they even get that far. Many have tried to solve the image metadata/tagging problem with few real successes; either it ends up too extensible (no 1:1 mapping of tag to meaning, too much info) or too restrictive (whoops, no 3D or new modality). A perfect system gets devised at first, then edge cases become apparent, followed by workarounds, then someone comes up with a new system that includes everything to date, the API breaks to support it, repeat with new cases... if nothing else, this is a massive support headache. > > From the big-picture view, we need to decide what we are, and what we want to become. To date, scikit-image is a powerful library of tools. We don't purport to hold users' hands through the process of implementation, and we never have. Sometimes the tools are a bit rough around the edges, and they aren't always as easy to use as they could be. But, in return, they end up exposing the maximum amount of functionality to end users. At the risk of a very stretched metaphor, the current state is a bit like Linux. > > Moving to towing around loads of metadata just so we can have complex, custom, branching paths behind every algorithm depending on what happens to be fed in - that's hand holding time. That's the Apple/OSX method. Yes, our package may gain a broader userbase and certain features in examples, etc. might be more elegant. But real world uses which don't follow the examples will be impeded, and more importantly we will alienate future potential contributors. > > I, for one, do not fancy implementing or maintaining the latter model. I fear for the future of the package even if we did implement it cleanly. There are aspects of the package where limited use of a custom wrapper would likely be reasonable, such as certain more public facing areas e.g. the Viewer, but I see these as the exception rather than the rule. > > My opinions on this issue are strong, but I recognize I'm only one voice. The most important thing we need to reach consensus on is the path forward, as noted above in bold. Up until now it's been rather clear, but wrapping NumPy ndarrays would start us down a very different road, one on which I fear we could easily lose our way. > > Josh > > On Tuesday, September 2, 2014 3:52:34 PM UTC+1, Juan Nunez-Iglesias wrote: > Cool, looks like there's lots of discussion to be had about this, but all positive ? I had expected more pushback, for some reason! =) > > @stefanv: > > Do we have some use cases for this? > > Spacing and masks, as you mentioned. > > Spatial resolutions, so we can deal with images acquired at different resolutions, e.g. registering light and electron microscopy images of the same sample. Also, as in Tim's talk, to allow drawing of scale bars on displayed images. > > Image orientation and absolute coordinates, which help with registration and montaging. > > Image acquisition date, which could be important e.g. to generate time series. > > That's just off the top of my head, I'm sure there's more! > > @stefanv @tacaswell @tonysyu > > Please find out how, then we can fix up the io.Image class! > > Tom's link to the solution in PIMS reminds me that it was indeed Dan who pointed out that they'd solved the scalar issue. > > @glyg > > I would suggest relying on OME.XML > > I think that might be a little too heavy for our uses, but I might be wrong. Either way, it's probably possible to have a compatibility layer between XML and whatever use cases we want to follow. (e.g. Automatically reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" tag.) > > Juan. > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Tue Sep 2 22:56:59 2014 From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=0F=F6nberger?=) Date: Tue, 2 Sep 2014 22:56:59 -0400 Subject: Travis builds are all failing In-Reply-To: <8e8d5612-e926-40cb-a206-732ab7caae33@googlegroups.com> References: <5030b698-efb6-4f10-b269-5368a34ea563@googlegroups.com> <8e8d5612-e926-40cb-a206-732ab7caae33@googlegroups.com> Message-ID: <3964891E-528E-4151-85A0-4146CA944B22@demuc.de> Imo, I already merged a PR from Steven yesterday, which fixes this. Other PRs just need a rebase. Johannes Sch?nberger On Sep 2, 2014, at 10:26 PM, Josh Warner wrote: > The root of the issue is Matplotlib >= 1.4 no longer supports Python 3.2. But instead of actually detecting Python 3.2 and terminating the install, setup continues until the check for optional pyqt4 dependency enters a subprocess and never returns. > > I filed an issue with Matplotlib at the end of our EuroSciPy sprint recommending an assume-fail timeout for such subprocess; hopefully this becomes more graceful in the future: https://github.com/matplotlib/matplotlib/issues/3444 > > In the meantime, we can work around it either by running extra Qt tests on another Python version (which would slow Travis down; we used 3.2 for this because of the apt-get binaries for its system Python 3.2) or force pip to install Matplotlib version 1.3.1 for the Python 3.2 build. > > Josh > > On Wednesday, September 3, 2014 12:55:15 AM UTC+1, Steven Silvester wrote: > St?fan, > > Looking through several the failing builds, a lot of them are suffering from not having the latest changes to `travis.yml`, causing the failure on Python 3.2. The other ones look like WIP failures. > > -Steve > > > On Tuesday, September 2, 2014 5:00:39 AM UTC-5, Stefan van der Walt wrote: > Hi, everyone > > If you have time, please have a look at what is going on with > Travis-CI--currently failing on all builds. > > Thanks > 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+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Tue Sep 2 23:01:56 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Tue, 2 Sep 2014 23:01:56 -0400 Subject: String formatting style In-Reply-To: References: Message-ID: I am actually happy with the new way (although, I am still using the old % operator mostly?). Johannes Sch?nberger On Sep 2, 2014, at 8:20 PM, Michael Aye wrote: > It's part of the Python tutorial for many years and common standard I'd say. > It's basic use might be cumbersome at first, but its power is great. > > Things like "My name is {0[name]}".format(dict(name='Fred')) > or > "My name is {0.name}".format(open('out.txt', 'w')) > lets you template-control strings in very elaborate manners. > The most minimalistic way btw is: > > "My first name is {} and my last name is {}".format(firstname, lastname) > > Michael > > On Tuesday, September 2, 2014 7:36:44 AM UTC-7, Juan Nunez-Iglesias wrote: > I'm not convinced either, but it seems to be what the whole community is moving to (I saw many instances of it at PyCon-AU), so we might as well get with the program! > > On Tuesday, September 2, 2014, St?fan van der Walt wrote: > Hi all > > What are your opinions on > > http://legacy.python.org/dev/peps/pep-3101/ > > I see this is used in some PRs, and I'm not convinced of its readability. > > 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+unsubscribe at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jni.soma at gmail.com Tue Sep 2 10:36:43 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 3 Sep 2014 00:36:43 +1000 Subject: String formatting style In-Reply-To: References: Message-ID: I'm not convinced either, but it seems to be what the whole community is moving to (I saw many instances of it at PyCon-AU), so we might as well get with the program! On Tuesday, September 2, 2014, St?fan van der Walt wrote: > Hi all > > What are your opinions on > > http://legacy.python.org/dev/peps/pep-3101/ > > I see this is used in some PRs, and I'm not convinced of its readability. > > 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+unsubscribe at googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Tue Sep 2 10:52:12 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 3 Sep 2014 00:52:12 +1000 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> Message-ID: Cool, looks like there's lots of discussion to be had about this, but all positive -- I had expected more pushback, for some reason! =) @stefanv: > Do we have some use cases for this? Spacing and masks, as you mentioned. Spatial resolutions, so we can deal with images acquired at different resolutions, e.g. registering light and electron microscopy images of the same sample. Also, as in Tim's talk, to allow drawing of scale bars on displayed images. Image orientation and absolute coordinates, which help with registration and montaging. Image acquisition date, which could be important e.g. to generate time series. That's just off the top of my head, I'm sure there's more! @stefanv @tacaswell @tonysyu > Please find out how, then we can fix up the io.Image class! Tom's link to the solution in PIMS reminds me that it was indeed Dan who pointed out that they'd solved the scalar issue. @glyg > I would suggest relying on OME.XML I think that might be a little too heavy for our uses, but I might be wrong. Either way, it's probably possible to have a compatibility layer between XML and whatever use cases we want to follow. (e.g. Automatically reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" tag.) Juan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Wed Sep 3 06:47:14 2014 From: deil.christoph at googlemail.com (Christoph) Date: Wed, 3 Sep 2014 03:47:14 -0700 (PDT) Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: Hi, I agree with Josh and Johannes, I think an `Image` class that contains metadata and mask is a bad idea for `scikit-image`. For what it?s worth, in the Astropy project [0] we are currently struggling with the same question. We currently do have an `NDData` class [1] in the Astropy core that has an optional `meta` dict and a `mask` (plus some other properties). But in the context of implementing an image utility function sub-package for Astropy [2] we noticed (see [3] and [4]) that it?s very difficult to implement image utility functions for `NDData` objects (at least that?s my interpretation ? others will probably disagree). The problem is that writing image processing functions becomes very complicated, because if images can (probably optionally) have metadata parameters or a mask, then *every function in scikit-image* should handle them correctly. But what ?correctly? means depends on the application ? quickly run into the problem that the semantics of how simple operations like e.g. `block_reduce` should handle the `mask` will be unclear ? it?s better to leave this up to the user. Plus there?s the problem that an API change like this would cause a lot of work and pain for current scikit-image users and developers. So my suggestion would be to leave the Image class (i.e. metadata and mask handling) to packages that use scikit-image and not try to implement a generic solution in scikit-image. If you don?t I think the grim future of scikit-image that Josh described is realistic. Cheers, Christoph [0] http://www.astropy.org/ [1] http://astropy.readthedocs.org/en/latest/nddata/index.html [2] http://imageutils.readthedocs.org/en/latest/imageutils/index.html [3] https://github.com/astropy/imageutils/issues/13 [4] https://github.com/astropy/astropy/pull/2855 On Wednesday, September 3, 2014 4:56:08 AM UTC+2, Johannes Sch?nberger wrote: > > I have not chimed in yet, but I can recall a discussion about the same > topic a while ago. As back then, I agree with Josh, who has given some very > good reasons. In addition, I would like to question the usefulness of the > tightly coupled metadata in general. > > > 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. > > Honestly, I do not understand. This is already possible now? > > Otherwise, I agree, that it is more convenient to write `slic(image)` than > `slic(image, spacing_x=metadata[?spacing_x?],?)`, where `image.metadata` is > automatically mapped to kwargs. However, this requires the metadata to be > standardized and homogeneous. And, at least to my experience - metadata is > the one thing that is guaranteed to cause trouble, because it is not > consistent. So, what happens when `spacing_x` is not called `spacing_x` but > `spacingx`? ?! Either the user actually realizes that, or the ?magic?, that > maps the metadata to the `slic` parameters: warns the user, silently > ignores, fails, etc. All this sounds complicated and intransparent to me. > > I think of other use cases, where attaching the metadata directly with the > image instead of having a separate dict, brings any benefit. In contrast, > skimage is typically used in conjunction with other libraries, which do not > know about our wrapper class. So, whenever you call a function from another > library, you loose the metadata. > > To make it short, I am a strong proponent of making the specification of > function parameters explicit, i.e. > > `slic(image, spacing_x=metadata[?spacing_x?], > spacing_y=metadata[?spacingy?])` > > or > > `slic(image, **metadata)` > > which is already possible with all skimage functions. > > Johannes Sch?nberger > > On Sep 2, 2014, at 10:16 PM, Josh Warner > wrote: > > > I see this a little differently, looking at it from the viewpoint of a > scientific user/new contributor. > > > > One of the biggest reasons scikit-image has been able to grow so well, > so rapidly, is because the bar for entry is low for new contributors. We > operate as close to the data as possible. People using Python understand > NumPy arrays. This is inherently familiar to those with backgrounds like > Matlab, which is likely one of, if not the, largest population we serve. We > want these people to be able to contribute without massive bars to entry. > > > > If we used a custom wrapper class, even a light one, I for one would > likely never have contributed to this package in the first place. Because, > in order to understand what was even being fed in, I would have to dig up > that wrapper, figure out what it actually contains, where my data is in it, > think about how to react given different inputs, and so on. This is a > tremendously daunting mental task. > > > > In short, moving to a new scheme would be, in my humble opinion, a > disaster. Imagine having to explain the metadata structure of the > hypothetical scikit-image construct to everyone at every SciPy Sprint, > every time, before they could work with the codebase. Imagine users who > want to know what the code is doing inspecting our source, seeing methods > called which aren't standard NumPy methods, wondering what is going on, and > having to dig through several other unclearly linked files in our repo to > figure that out - if they even get that far. Many have tried to solve the > image metadata/tagging problem with few real successes; either it ends up > too extensible (no 1:1 mapping of tag to meaning, too much info) or too > restrictive (whoops, no 3D or new modality). A perfect system gets devised > at first, then edge cases become apparent, followed by workarounds, then > someone comes up with a new system that includes everything to date, the > API breaks to support it, repeat with new cases... if nothing else, this is > a massive support headache. > > > > From the big-picture view, we need to decide what we are, and what we > want to become. To date, scikit-image is a powerful library of tools. We > don't purport to hold users' hands through the process of implementation, > and we never have. Sometimes the tools are a bit rough around the edges, > and they aren't always as easy to use as they could be. But, in return, > they end up exposing the maximum amount of functionality to end users. At > the risk of a very stretched metaphor, the current state is a bit like > Linux. > > > > Moving to towing around loads of metadata just so we can have complex, > custom, branching paths behind every algorithm depending on what happens to > be fed in - that's hand holding time. That's the Apple/OSX method. Yes, our > package may gain a broader userbase and certain features in examples, etc. > might be more elegant. But real world uses which don't follow the examples > will be impeded, and more importantly we will alienate future potential > contributors. > > > > I, for one, do not fancy implementing or maintaining the latter model. I > fear for the future of the package even if we did implement it cleanly. > There are aspects of the package where limited use of a custom wrapper > would likely be reasonable, such as certain more public facing areas e.g. > the Viewer, but I see these as the exception rather than the rule. > > > > My opinions on this issue are strong, but I recognize I'm only one > voice. The most important thing we need to reach consensus on is the path > forward, as noted above in bold. Up until now it's been rather clear, but > wrapping NumPy ndarrays would start us down a very different road, one on > which I fear we could easily lose our way. > > > > Josh > > > > On Tuesday, September 2, 2014 3:52:34 PM UTC+1, Juan Nunez-Iglesias > wrote: > > Cool, looks like there's lots of discussion to be had about this, but > all positive ? I had expected more pushback, for some reason! =) > > > > @stefanv: > > > Do we have some use cases for this? > > > > Spacing and masks, as you mentioned. > > > > Spatial resolutions, so we can deal with images acquired at different > resolutions, e.g. registering light and electron microscopy images of the > same sample. Also, as in Tim's talk, to allow drawing of scale bars on > displayed images. > > > > Image orientation and absolute coordinates, which help with registration > and montaging. > > > > Image acquisition date, which could be important e.g. to generate time > series. > > > > That's just off the top of my head, I'm sure there's more! > > > > @stefanv @tacaswell @tonysyu > > > Please find out how, then we can fix up the io.Image class! > > > > Tom's link to the solution in PIMS reminds me that it was indeed Dan who > pointed out that they'd solved the scalar issue. > > > > @glyg > > > I would suggest relying on OME.XML > > > > I think that might be a little too heavy for our uses, but I might be > wrong. Either way, it's probably possible to have a compatibility layer > between XML and whatever use cases we want to follow. (e.g. Automatically > reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" > tag.) > > > > Juan. > > > > -- > > 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... at googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Sep 3 05:57:35 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Wed, 3 Sep 2014 10:57:35 +0100 Subject: String formatting style In-Reply-To: References: Message-ID: On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye wrote: > It's part of the Python tutorial for many years and common standard I'd say. > It's basic use might be cumbersome at first, but its power is great. > > Things like "My name is {0[name]}".format(dict(name='Fred')) With great power comes great responsibility! I find the above very close to unreadable. Compare to: "My name is %s" % name or "My name is %(name)s" % {'name': 'Fred'} St?fan From Deil.Christoph at gmail.com Wed Sep 3 05:51:39 2014 From: Deil.Christoph at gmail.com (Christoph Deil) Date: Wed, 3 Sep 2014 11:51:39 +0200 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: Hi, I agree with Josh and Johannes, I think an `Image` class that contains metadata and mask is a bad idea for `scikit-image`. For what it?s worth, in the Astropy project [0] we are currently struggling with the same question. We currently do have an `NDData` class [1] in the Astropy core that has an optional `meta` dict and a `mask` (plus some other properties). But in the context of implementing an image utility function sub-package for Astropy [2] we noticed (see [3] and [4]) that it?s very difficult to implement image utility functions for `NDData` objects (at least that?s my interpretation ? others will probably disagree). The problem is that writing image processing functions becomes very complicated, because if images can (probably optionally) have metadata parameters or a mask, then *every function in scikit-image* should handle them correctly. But what ?correctly? means depends on the application ? quickly run into the problem that the semantics of how simple operations like e.g. `block_reduce` should handle the `mask` will be unclear ? it?s better to leave this up to the user. Plus there?s the problem that an API change like this would cause a lot of work and pain for current scikit-image users and developers. So my suggestion would be to leave the Image class (i.e. metadata and mask handling) to packages that use scikit-image and not try to implement a generic solution in scikit-image. If you don?t I think the grim future of scikit-image that Josh described is realistic. Cheers, Christoph [0] http://www.astropy.org/ [1] http://astropy.readthedocs.org/en/latest/nddata/index.html [2] http://imageutils.readthedocs.org/en/latest/imageutils/index.html [3] https://github.com/astropy/imageutils/issues/13 [4] https://github.com/astropy/astropy/pull/2855 On 03 Sep 2014, at 04:56, Johannes Sch?nberger wrote: > I have not chimed in yet, but I can recall a discussion about the same topic a while ago. As back then, I agree with Josh, who has given some very good reasons. In addition, I would like to question the usefulness of the tightly coupled metadata in general. > >> 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. > > Honestly, I do not understand. This is already possible now? > > Otherwise, I agree, that it is more convenient to write `slic(image)` than `slic(image, spacing_x=metadata["spacing_x"],...)`, where `image.metadata` is automatically mapped to kwargs. However, this requires the metadata to be standardized and homogeneous. And, at least to my experience - metadata is the one thing that is guaranteed to cause trouble, because it is not consistent. So, what happens when `spacing_x` is not called `spacing_x` but `spacingx`... ?! Either the user actually realizes that, or the "magic", that maps the metadata to the `slic` parameters: warns the user, silently ignores, fails, etc. All this sounds complicated and intransparent to me. > > I think of other use cases, where attaching the metadata directly with the image instead of having a separate dict, brings any benefit. In contrast, skimage is typically used in conjunction with other libraries, which do not know about our wrapper class. So, whenever you call a function from another library, you loose the metadata. > > To make it short, I am a strong proponent of making the specification of function parameters explicit, i.e. > > `slic(image, spacing_x=metadata["spacing_x"], spacing_y=metadata["spacingy"])` > > or > > `slic(image, **metadata)` > > which is already possible with all skimage functions. > > Johannes Sch ?nberger > > On Sep 2, 2014, at 10:16 PM, Josh Warner wrote: > >> I see this a little differently, looking at it from the viewpoint of a scientific user/new contributor. >> >> One of the biggest reasons scikit-image has been able to grow so well, so rapidly, is because the bar for entry is low for new contributors. We operate as close to the data as possible. People using Python understand NumPy arrays. This is inherently familiar to those with backgrounds like Matlab, which is likely one of, if not the, largest population we serve. We want these people to be able to contribute without massive bars to entry. >> >> If we used a custom wrapper class, even a light one, I for one would likely never have contributed to this package in the first place. Because, in order to understand what was even being fed in, I would have to dig up that wrapper, figure out what it actually contains, where my data is in it, think about how to react given different inputs, and so on. This is a tremendously daunting mental task. >> >> In short, moving to a new scheme would be, in my humble opinion, a disaster. Imagine having to explain the metadata structure of the hypothetical scikit-image construct to everyone at every SciPy Sprint, every time, before they could work with the codebase. Imagine users who want to know what the code is doing inspecting our source, seeing methods called which aren't standard NumPy methods, wondering what is going on, and having to dig through several other unclearly linked files in our repo to figure that out - if they even get that far. Many have tried to solve the image metadata/tagging problem with few real successes; either it ends up too extensible (no 1:1 mapping of tag to meaning, too much info) or too restrictive (whoops, no 3D or new modality). A perfect system gets devised at first, then edge cases become apparent, followed by workarounds, then someone comes up with a new system that includes everything to date, the API breaks to support it, repeat with new cases... if nothing else, this is a massive support headache. >> >> From the big-picture view, we need to decide what we are, and what we want to become. To date, scikit-image is a powerful library of tools. We don't purport to hold users' hands through the process of implementation, and we never have. Sometimes the tools are a bit rough around the edges, and they aren't always as easy to use as they could be. But, in return, they end up exposing the maximum amount of functionality to end users. At the risk of a very stretched metaphor, the current state is a bit like Linux. >> >> Moving to towing around loads of metadata just so we can have complex, custom, branching paths behind every algorithm depending on what happens to be fed in - that's hand holding time. That's the Apple/OSX method. Yes, our package may gain a broader userbase and certain features in examples, etc. might be more elegant. But real world uses which don't follow the examples will be impeded, and more importantly we will alienate future potential contributors. >> >> I, for one, do not fancy implementing or maintaining the latter model. I fear for the future of the package even if we did implement it cleanly. There are aspects of the package where limited use of a custom wrapper would likely be reasonable, such as certain more public facing areas e.g. the Viewer, but I see these as the exception rather than the rule. >> >> My opinions on this issue are strong, but I recognize I'm only one voice. The most important thing we need to reach consensus on is the path forward, as noted above in bold. Up until now it's been rather clear, but wrapping NumPy ndarrays would start us down a very different road, one on which I fear we could easily lose our way. >> >> Josh >> >> On Tuesday, September 2, 2014 3:52:34 PM UTC+1, Juan Nunez-Iglesias wrote: >> Cool, looks like there's lots of discussion to be had about this, but all positive -- I had expected more pushback, for some reason! =) >> >> @stefanv: >>> Do we have some use cases for this? >> >> Spacing and masks, as you mentioned. >> >> Spatial resolutions, so we can deal with images acquired at different resolutions, e.g. registering light and electron microscopy images of the same sample. Also, as in Tim's talk, to allow drawing of scale bars on displayed images. >> >> Image orientation and absolute coordinates, which help with registration and montaging. >> >> Image acquisition date, which could be important e.g. to generate time series. >> >> That's just off the top of my head, I'm sure there's more! >> >> @stefanv @tacaswell @tonysyu >>> Please find out how, then we can fix up the io.Image class! >> >> Tom's link to the solution in PIMS reminds me that it was indeed Dan who pointed out that they'd solved the scalar issue. >> >> @glyg >>> I would suggest relying on OME.XML >> >> I think that might be a little too heavy for our uses, but I might be wrong. Either way, it's probably possible to have a compatibility layer between XML and whatever use cases we want to follow. (e.g. Automatically reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" tag.) >> >> Juan. >> >> -- >> 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 at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Sep 3 06:55:37 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Wed, 3 Sep 2014 11:55:37 +0100 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: On Wed, Sep 3, 2014 at 3:56 AM, Johannes Sch ?nberger wrote: > `slic(image, spacing_x=metadata["spacing_x"], spacing_y=metadata["spacing_y"])` This would be my preferred way of doing things too. "Explicit is better than implicit." St?fan From jsch at demuc.de Wed Sep 3 20:47:27 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 3 Sep 2014 20:47:27 -0400 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: > Johannes, slic(image, **metadata) won't work if the metadata dictionary contains keys that are not found in the function signature, which would be in basically all real-world scenarios. In order to support this syntax, we would need to append a **kwargs to the end of every function that supports metadata. > > Additionally, what I was suggesting would also require writing up a metadata specification and ensuring that all our kwargs are consistently named with that spec. We've made some efforts in the past to do so (spacing), but nothing comprehensive. As mentioned, when metadata does not match your expected naming scheme, you are screwed anyways? From jni.soma at gmail.com Wed Sep 3 20:38:27 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Thu, 4 Sep 2014 10:38:27 +1000 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: Well, the nays came out! =) Josh, you were as eloquent as ever, and have convinced me. =) I think the right model is indeed having scikit-image close(ish) to the metal, while higher-level libraries use scikit-image to handle metadata correctly *within their domain*. We have seen Guillaume suggest OME, while Michael suggested GDAL. These are two metadata implementations that are *probably incompatible* and *both* close de-facto standards within their domain. (The DICOM standard discussed in ITK's docs, linked by Thomas, is yet another implementation/domain.) Our library is extremely multidisciplinary in nature (for example, St?fan just tweeted about someone using skimage to remove camera motion from NFL broadcasts ), so we would somehow have to span all of these domains, which each have their own metadata requirements. Indeed, this would be crazy. I'll address a few of the other comments that I think are still relevant: Johannes, slic(image, **metadata) won't work if the metadata dictionary contains keys that are not found in the function signature, which would be in basically all real-world scenarios. In order to support this syntax, we would need to append a **kwargs to the end of every function that supports metadata. Additionally, what I was suggesting would also require writing up a metadata specification and ensuring that all our kwargs are consistently named with that spec. We've made some efforts in the past to do so (spacing), but nothing comprehensive. I'm not sure this is a good thing to do. (**kwargs, unifying function signatures seems like a no-brainer.) >From my point of view, the nays have it, and we can close this discussion, but others feel free to chime in. Thanks everyone! Juan. On Wed, Sep 3, 2014 at 7:51 PM, Christoph Deil wrote: > Hi, > > I agree with Josh and Johannes, I think an `Image` class that contains > metadata and mask is a bad idea for `scikit-image`. > > For what it's worth, in the Astropy project [0] we are currently > struggling with the same question. > We currently do have an `NDData` class [1] in the Astropy core that has an > optional `meta` dict and a `mask` (plus some other properties). > But in the context of implementing an image utility function sub-package > for Astropy [2] we noticed (see [3] and [4]) that it's very difficult to > implement image utility functions for `NDData` objects (at least that's my > interpretation ... others will probably disagree). > > The problem is that writing image processing functions becomes very > complicated, because if images can (probably optionally) have metadata > parameters or a mask, then *every function in scikit-image* should handle > them correctly. > But what "correctly" means depends on the application ... quickly run into > the problem that the semantics of how simple operations like e.g. > `block_reduce` should handle the `mask` will be unclear ... it's better to > leave this up to the user. > Plus there's the problem that an API change like this would cause a lot of > work and pain for current scikit-image users and developers. > > So my suggestion would be to leave the Image class (i.e. metadata and mask > handling) to packages that use scikit-image and not try to implement a > generic solution in scikit-image. > If you don't I think the grim future of scikit-image that Josh described > is realistic. > > Cheers, > Christoph > > [0] http://www.astropy.org/ > [1] http://astropy.readthedocs.org/en/latest/nddata/index.html > [2] http://imageutils.readthedocs.org/en/latest/imageutils/index.html > [3] https://github.com/astropy/imageutils/issues/13 > [4] https://github.com/astropy/astropy/pull/2855 > > > > On 03 Sep 2014, at 04:56, Johannes Sch ?nberger wrote: > > I have not chimed in yet, but I can recall a discussion about the same > topic a while ago. As back then, I agree with Josh, who has given some very > good reasons. In addition, I would like to question the usefulness of the > tightly coupled metadata in general. > > 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. > > > Honestly, I do not understand. This is already possible now? > > Otherwise, I agree, that it is more convenient to write `slic(image)` than > `slic(image, spacing_x=metadata["spacing_x"],...)`, where `image.metadata` > is automatically mapped to kwargs. However, this requires the metadata to > be standardized and homogeneous. And, at least to my experience - metadata > is the one thing that is guaranteed to cause trouble, because it is not > consistent. So, what happens when `spacing_x` is not called `spacing_x` but > `spacingx`... ?! Either the user actually realizes that, or the "magic", > that maps the metadata to the `slic` parameters: warns the user, silently > ignores, fails, etc. All this sounds complicated and intransparent to me. > > I think of other use cases, where attaching the metadata directly with the > image instead of having a separate dict, brings any benefit. In contrast, > skimage is typically used in conjunction with other libraries, which do not > know about our wrapper class. So, whenever you call a function from another > library, you loose the metadata. > > To make it short, I am a strong proponent of making the specification of > function parameters explicit, i.e. > > `slic(image, spacing_x=metadata["spacing_x"], > spacing_y=metadata["spacingy"])` > > or > > `slic(image, **metadata)` > > which is already possible with all skimage functions. > > Johannes Sch ?nberger > > On Sep 2, 2014, at 10:16 PM, Josh Warner > wrote: > > I see this a little differently, looking at it from the viewpoint of a > scientific user/new contributor. > > One of the biggest reasons scikit-image has been able to grow so well, so > rapidly, is because the bar for entry is low for new contributors. We > operate as close to the data as possible. People using Python understand > NumPy arrays. This is inherently familiar to those with backgrounds like > Matlab, which is likely one of, if not the, largest population we serve. We > want these people to be able to contribute without massive bars to entry. > > If we used a custom wrapper class, even a light one, I for one would > likely never have contributed to this package in the first place. Because, > in order to understand what was even being fed in, I would have to dig up > that wrapper, figure out what it actually contains, where my data is in it, > think about how to react given different inputs, and so on. This is a > tremendously daunting mental task. > > In short, moving to a new scheme would be, in my humble opinion, a > disaster. Imagine having to explain the metadata structure of the > hypothetical scikit-image construct to everyone at every SciPy Sprint, > every time, before they could work with the codebase. Imagine users who > want to know what the code is doing inspecting our source, seeing methods > called which aren't standard NumPy methods, wondering what is going on, and > having to dig through several other unclearly linked files in our repo to > figure that out - if they even get that far. Many have tried to solve the > image metadata/tagging problem with few real successes; either it ends up > too extensible (no 1:1 mapping of tag to meaning, too much info) or too > restrictive (whoops, no 3D or new modality). A perfect system gets devised > at first, then edge cases become apparent, followed by workarounds, then > someone comes up with a new system that includes everything to date, the > API breaks to support it, repeat with new cases... if nothing else, this is > a massive support headache. > > From the big-picture view, we need to decide what we are, and what we want > to become. To date, scikit-image is a powerful library of tools. We don't > purport to hold users' hands through the process of implementation, and we > never have. Sometimes the tools are a bit rough around the edges, and they > aren't always as easy to use as they could be. But, in return, they end up > exposing the maximum amount of functionality to end users. At the risk of a > very stretched metaphor, the current state is a bit like Linux. > > Moving to towing around loads of metadata just so we can have complex, > custom, branching paths behind every algorithm depending on what happens to > be fed in - that's hand holding time. That's the Apple/OSX method. Yes, our > package may gain a broader userbase and certain features in examples, etc. > might be more elegant. But real world uses which don't follow the examples > will be impeded, and more importantly we will alienate future potential > contributors. > > I, for one, do not fancy implementing or maintaining the latter model. I > fear for the future of the package even if we did implement it cleanly. > There are aspects of the package where limited use of a custom wrapper > would likely be reasonable, such as certain more public facing areas e.g. > the Viewer, but I see these as the exception rather than the rule. > > My opinions on this issue are strong, but I recognize I'm only one voice. > The most important thing we need to reach consensus on is the path forward, > as noted above in bold. Up until now it's been rather clear, but wrapping > NumPy ndarrays would start us down a very different road, one on which I > fear we could easily lose our way. > > Josh > > On Tuesday, September 2, 2014 3:52:34 PM UTC+1, Juan Nunez-Iglesias wrote: > Cool, looks like there's lots of discussion to be had about this, but all > positive -- I had expected more pushback, for some reason! =) > > @stefanv: > > Do we have some use cases for this? > > > Spacing and masks, as you mentioned. > > Spatial resolutions, so we can deal with images acquired at different > resolutions, e.g. registering light and electron microscopy images of the > same sample. Also, as in Tim's talk, to allow drawing of scale bars on > displayed images. > > Image orientation and absolute coordinates, which help with registration > and montaging. > > Image acquisition date, which could be important e.g. to generate time > series. > > That's just off the top of my head, I'm sure there's more! > > @stefanv @tacaswell @tonysyu > > Please find out how, then we can fix up the io.Image class! > > > Tom's link to the solution in PIMS reminds me that it was indeed Dan who > pointed out that they'd solved the scalar issue. > > @glyg > > I would suggest relying on OME.XML > > > I think that might be a little too heavy for our uses, but I might be > wrong. Either way, it's probably possible to have a compatibility layer > between XML and whatever use cases we want to follow. (e.g. Automatically > reading out "PhysicalSizeX/Y/Z" tags and converting those to a "spacing" > tag.) > > Juan. > > -- > 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 at 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 at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed Sep 3 20:53:25 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Thu, 4 Sep 2014 10:53:25 +1000 Subject: Image class In-Reply-To: References: <1409551418462.6276fcd8@Nodemailer> <5405168F.30602@sciunto.org> <9bc793ca-9620-4cfa-b221-12394f7adb58@googlegroups.com> Message-ID: On Thu, Sep 4, 2014 at 10:47 AM, Johannes Sch ?nberger wrote: > > As mentioned, when metadata does not match your expected naming scheme, > you are screwed anyways... > Yes, but it's friendlier to ask users to definitely have a compatible metadata tag than it is to ask them to throw out all other tags. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Sep 4 17:49:27 2014 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 4 Sep 2014 17:49:27 -0400 Subject: scribbling tool (eg for labeling markers) In-Reply-To: References: <20140902182220.GA16077@phare.normalesup.org> <20140904210111.GD16179@phare.normalesup.org> Message-ID: If you are doing this with matplotlib, can you actually push the tools back upstream? Tom (a mpl dev) On Thu, Sep 4, 2014 at 5:36 PM, St?fan van der Walt wrote: > On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart > wrote: >> Answering my own question: I had forgotten that the viewer examples >> include such kind of example, inside watershed_demo.py. Thanks Tony >> for the example! > > I think this is an important enough use-case to make it a utility > function--feel free to add an issue! > > 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+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell at gmail.com From steven.silvester at gmail.com Thu Sep 4 21:28:20 2014 From: steven.silvester at gmail.com (Steven Silvester) Date: Thu, 4 Sep 2014 18:28:20 -0700 (PDT) Subject: scribbling tool (eg for labeling markers) In-Reply-To: References: <20140902182220.GA16077@phare.normalesup.org> <20140904210111.GD16179@phare.normalesup.org> Message-ID: Thomas, How about the broader discussion of incorporating the tools in https://github.com/blink1073/image_inspector into mpl (ideally as a replacement or alternative for some of the existing tools)? If I combine that with paint tool and we get those pushed into mpl proper, then we can just use them as-is for skimage. Should I open an mpl issue to discuss? - Steve On Thursday, September 4, 2014 4:49:28 PM UTC-5, Thomas Caswell wrote: > > If you are doing this with matplotlib, can you actually push the tools > back upstream? > > Tom (a mpl dev) > > On Thu, Sep 4, 2014 at 5:36 PM, St?fan van der Walt > wrote: > > On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart > > > wrote: > >> Answering my own question: I had forgotten that the viewer examples > >> include such kind of example, inside watershed_demo.py. Thanks Tony > >> for the example! > > > > I think this is an important enough use-case to make it a utility > > function--feel free to add an issue! > > > > 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... at googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Thomas Caswell > tcas... at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Sep 4 17:36:39 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Thu, 4 Sep 2014 22:36:39 +0100 Subject: scribbling tool (eg for labeling markers) In-Reply-To: <20140904210111.GD16179@phare.normalesup.org> References: <20140902182220.GA16077@phare.normalesup.org> <20140904210111.GD16179@phare.normalesup.org> Message-ID: On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart wrote: > Answering my own question: I had forgotten that the viewer examples > include such kind of example, inside watershed_demo.py. Thanks Tony > for the example! I think this is an important enough use-case to make it a utility function--feel free to add an issue! St?fan From emmanuelle.gouillart at nsup.org Thu Sep 4 17:01:11 2014 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Thu, 4 Sep 2014 23:01:11 +0200 Subject: scribbling tool (eg for labeling markers) In-Reply-To: <20140902182220.GA16077@phare.normalesup.org> References: <20140902182220.GA16077@phare.normalesup.org> Message-ID: <20140904210111.GD16179@phare.normalesup.org> Answering my own question: I had forgotten that the viewer examples include such kind of example, inside watershed_demo.py. Thanks Tony for the example! Cheers, Emmanuelle On Tue, Sep 02, 2014 at 08:22:20PM +0200, Emmanuelle Gouillart wrote: > Hello, > during the Euroscipy sprints, St??fan and Josh mentioned that they > frequently use homebrewed scripts in order to scribble on an image and > retrieve the coordinates of scribbled pixels, e.g. in order to determine > some markers for image segmentation. St??fan or Josh, would you mind > sharing snippets of code showing how this can be done? > Thanks! > Emmanuelle From tcaswell at gmail.com Thu Sep 4 23:41:28 2014 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 4 Sep 2014 23:41:28 -0400 Subject: scribbling tool (eg for labeling markers) In-Reply-To: References: <20140902182220.GA16077@phare.normalesup.org> <20140904210111.GD16179@phare.normalesup.org> Message-ID: Steven, I would love to get to as much of that functionality into mpl proper as possible. Please open an issue / make a MEP for this. Unfortunately I have not had a chance to take a close look at image_inspector yet and I am a tad concerned about the potential for re-invented wheels between yours tools and the existing widgets (and to be fair, I only have a cursory understanding of those widgets). I agree all the functionality should be in mpl (or as much as we can shove down through our gui frame work independent filter), but don't want to get pinned down to committing to specific implementation details. Another option might be to put all of these tools in a sibling repo to mpl under the mpl organization. I have cc'd the mpl-dev list. Tom On Thu, Sep 4, 2014 at 9:28 PM, Steven Silvester wrote: > Thomas, > > How about the broader discussion of incorporating the tools in > https://github.com/blink1073/image_inspector into mpl (ideally as a > replacement or alternative for some of the existing tools)? If I combine > that with paint tool and we get those pushed into mpl proper, then we can > just use them as-is for skimage. Should I open an mpl issue to discuss? > > - Steve > > On Thursday, September 4, 2014 4:49:28 PM UTC-5, Thomas Caswell wrote: >> >> If you are doing this with matplotlib, can you actually push the tools >> back upstream? >> >> Tom (a mpl dev) >> >> On Thu, Sep 4, 2014 at 5:36 PM, St?fan van der Walt >> wrote: >> > On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart >> > wrote: >> >> Answering my own question: I had forgotten that the viewer examples >> >> include such kind of example, inside watershed_demo.py. Thanks Tony >> >> for the example! >> > >> > I think this is an important enough use-case to make it a utility >> > function--feel free to add an issue! >> > >> > 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... at googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Thomas Caswell >> tcas... at gmail.com > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell at gmail.com From maik.riechert at arcor.de Wed Sep 10 05:35:29 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 02:35:29 -0700 (PDT) Subject: Areas of contours Message-ID: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> Hi, I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? Thanks Maik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed Sep 10 05:43:57 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 10 Sep 2014 02:43:57 -0700 (PDT) Subject: Areas of contours In-Reply-To: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> References: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> Message-ID: <1410342236945.25daffa9@Nodemailer> Hey Maik, Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. If that doesn?t help, if you have an example image with code it might be easier to translate your workflow. Note that we don?t attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. Juan. ? Sent from Mailbox On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: > Hi, > I'm currently switching from OpenCV to scikit-image and came to a point > where I miss a certain feature. > In OpenCV I used findContours() and then contourArea() to calculate the > area of each contour. I couldn't find this in scikit-image. If I didn't > miss it somewhere, could that be added as a new function? > Thanks > Maik > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Wed Sep 10 08:28:36 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 05:28:36 -0700 (PDT) Subject: Areas of contours In-Reply-To: <1410342236945.25daffa9@Nodemailer> References: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> <1410342236945.25daffa9@Nodemailer> Message-ID: <104cb454-38a9-4dc1-91ad-3e05288e20a0@googlegroups.com> My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: def polygonArea(poly): """ Return area of an unclosed polygon. :see: https://stackoverflow.com/a/451482 :param poly: (n,2)-array """ # we need a plain list for the following operations if isinstance(poly, np.ndarray): poly = poly.tolist() segments = zip(poly, poly[1:] + [poly[0]]) return 0.5 * abs(sum(x0*y1 - x1*y0 for ((x0, y0), (x1, y1)) in segments)) Before using that function I un-close the returned contours. Cheers Maik Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: > > Hey Maik, > > Can you be a bit more specific? The pipeline may need to be a bit > different, but this seems doable. In particular, regionprops(image)[i].area > will return the area of all binary-labeled regions. > > If that doesn?t help, if you have an example image with code it might be > easier to translate your workflow. > > Note that we don?t attempt to offer feature parity with OpenCV, which has > a lot of hard computer vision algorithms that we lack. But this in > particular should be doable. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert > wrote: > >> Hi, >> >> I'm currently switching from OpenCV to scikit-image and came to a point >> where I miss a certain feature. >> >> In OpenCV I used findContours() and then contourArea() to calculate the >> area of each contour. I couldn't find this in scikit-image. If I didn't >> miss it somewhere, could that be added as a new function? >> >> Thanks >> Maik >> >> -- >> 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... at googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed Sep 10 09:04:25 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 10 Sep 2014 06:04:25 -0700 (PDT) Subject: Areas of contours In-Reply-To: <104cb454-38a9-4dc1-91ad-3e05288e20a0@googlegroups.com> References: <104cb454-38a9-4dc1-91ad-3e05288e20a0@googlegroups.com> Message-ID: <1410354264866.a0b2541b@Nodemailer> Hey Maik, But what about: 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. 3) get props = skimage.regionprops(im) to get the properties of each blob 4) you can then find the argmax of [p.area for p in props] 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property Would this work? It all depends on your purposes, and I?m also not sure which would be most efficient. Juan. ? Sent from Mailbox On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: > My goal is to determine the biggest contour that covers 1's in the binary > image and return it, therefore I thought I first use find_contours and then > calculate the area of each contour to get the right one. I'm not sure if > regionprops helps me here. In the meantime I adapted a function from > stackoverflow: > def polygonArea(poly): > """ > Return area of an unclosed polygon. > > :see: https://stackoverflow.com/a/451482 > :param poly: (n,2)-array > """ > # we need a plain list for the following operations > if isinstance(poly, np.ndarray): > poly = poly.tolist() > segments = zip(poly, poly[1:] + [poly[0]]) > return 0.5 * abs(sum(x0*y1 - x1*y0 > for ((x0, y0), (x1, y1)) in segments)) > Before using that function I un-close the returned contours. > Cheers > Maik > Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: >> >> Hey Maik, >> >> Can you be a bit more specific? The pipeline may need to be a bit >> different, but this seems doable. In particular, regionprops(image)[i].area >> will return the area of all binary-labeled regions. >> >> If that doesn?t help, if you have an example image with code it might be >> easier to translate your workflow. >> >> Note that we don?t attempt to offer feature parity with OpenCV, which has >> a lot of hard computer vision algorithms that we lack. But this in >> particular should be doable. >> >> Juan. >> ? >> Sent from Mailbox >> >> >> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert > > wrote: >> >>> Hi, >>> >>> I'm currently switching from OpenCV to scikit-image and came to a point >>> where I miss a certain feature. >>> >>> In OpenCV I used findContours() and then contourArea() to calculate the >>> area of each contour. I couldn't find this in scikit-image. If I didn't >>> miss it somewhere, could that be added as a new function? >>> >>> Thanks >>> Maik >>> >>> -- >>> 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Wed Sep 10 09:19:57 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 06:19:57 -0700 (PDT) Subject: Areas of contours In-Reply-To: <1410354264866.a0b2541b@Nodemailer> References: <104cb454-38a9-4dc1-91ad-3e05288e20a0@googlegroups.com> <1410354264866.a0b2541b@Nodemailer> Message-ID: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> Hi Juan, how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. Cheers Maik Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: > > Hey Maik, > > But what about: > > 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute > the full area from a contour > 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the > image. > 3) get props = skimage.regionprops(im) to get the properties of each blob > 4) you can then find the argmax of [p.area for p in props] > 5) you can then compute the contour of just that object, and offset the > coordinates using the .bbox property > > Would this work? It all depends on your purposes, and I?m also not sure > which would be most efficient. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert > wrote: > >> My goal is to determine the biggest contour that covers 1's in the binary >> image and return it, therefore I thought I first use find_contours and then >> calculate the area of each contour to get the right one. I'm not sure if >> regionprops helps me here. In the meantime I adapted a function from >> stackoverflow: >> >> def polygonArea(poly): >> """ >> Return area of an unclosed polygon. >> >> :see: https://stackoverflow.com/a/451482 >> :param poly: (n,2)-array >> """ >> # we need a plain list for the following operations >> if isinstance(poly, np.ndarray): >> poly = poly.tolist() >> segments = zip(poly, poly[1:] + [poly[0]]) >> return 0.5 * abs(sum(x0*y1 - x1*y0 >> for ((x0, y0), (x1, y1)) in segments)) >> >> Before using that function I un-close the returned contours. >> >> Cheers >> Maik >> >> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan >> Nunez-Iglesias: >>> >>> Hey Maik, >>> >>> Can you be a bit more specific? The pipeline may need to be a bit >>> different, but this seems doable. In particular, regionprops(image)[i].area >>> will return the area of all binary-labeled regions. >>> >>> If that doesn?t help, if you have an example image with code it might be >>> easier to translate your workflow. >>> >>> Note that we don?t attempt to offer feature parity with OpenCV, which >>> has a lot of hard computer vision algorithms that we lack. But this in >>> particular should be doable. >>> >>> Juan. >>> ? >>> Sent from Mailbox >>> >>> >>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert >>> wrote: >>> >>>> Hi, >>>> >>>> I'm currently switching from OpenCV to scikit-image and came to a point >>>> where I miss a certain feature. >>>> >>>> In OpenCV I used findContours() and then contourArea() to calculate the >>>> area of each contour. I couldn't find this in scikit-image. If I didn't >>>> miss it somewhere, could that be added as a new function? >>>> >>>> Thanks >>>> Maik >>>> >>>> -- >>>> 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... at 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... at googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Wed Sep 10 09:26:41 2014 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Wed, 10 Sep 2014 06:26:41 -0700 (PDT) Subject: Areas of contours In-Reply-To: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> Message-ID: <1410355600605.958bd498@Nodemailer> p.image contains an image of just that one region, within bbox. Note that regionprops have lazy evaluation, so the code mentioned above should be reasonably fast ? possibly faster than evaluating contours for the whole image first. Also note that unless you port it to Cython, your area function on the contours will be pretty slow. ? Sent from Mailbox On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert wrote: > Hi Juan, > how would I do step 5? Even if I know the bounding box it could still be > that parts of other regions are in the box, right? > I'm not sure if all that would be a bit too slow if it worked. My images > are 4000x3000 and I guess there's a noticeable performance advantage of > doing all further calculations just on the contours instead of the image > itself. > Cheers > Maik > Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: >> >> Hey Maik, >> >> But what about: >> >> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute >> the full area from a contour >> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the >> image. >> 3) get props = skimage.regionprops(im) to get the properties of each blob >> 4) you can then find the argmax of [p.area for p in props] >> 5) you can then compute the contour of just that object, and offset the >> coordinates using the .bbox property >> >> Would this work? It all depends on your purposes, and I?m also not sure >> which would be most efficient. >> >> Juan. >> ? >> Sent from Mailbox >> >> >> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert > > wrote: >> >>> My goal is to determine the biggest contour that covers 1's in the binary >>> image and return it, therefore I thought I first use find_contours and then >>> calculate the area of each contour to get the right one. I'm not sure if >>> regionprops helps me here. In the meantime I adapted a function from >>> stackoverflow: >>> >>> def polygonArea(poly): >>> """ >>> Return area of an unclosed polygon. >>> >>> :see: https://stackoverflow.com/a/451482 >>> :param poly: (n,2)-array >>> """ >>> # we need a plain list for the following operations >>> if isinstance(poly, np.ndarray): >>> poly = poly.tolist() >>> segments = zip(poly, poly[1:] + [poly[0]]) >>> return 0.5 * abs(sum(x0*y1 - x1*y0 >>> for ((x0, y0), (x1, y1)) in segments)) >>> >>> Before using that function I un-close the returned contours. >>> >>> Cheers >>> Maik >>> >>> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan >>> Nunez-Iglesias: >>>> >>>> Hey Maik, >>>> >>>> Can you be a bit more specific? The pipeline may need to be a bit >>>> different, but this seems doable. In particular, regionprops(image)[i].area >>>> will return the area of all binary-labeled regions. >>>> >>>> If that doesn?t help, if you have an example image with code it might be >>>> easier to translate your workflow. >>>> >>>> Note that we don?t attempt to offer feature parity with OpenCV, which >>>> has a lot of hard computer vision algorithms that we lack. But this in >>>> particular should be doable. >>>> >>>> Juan. >>>> ? >>>> Sent from Mailbox >>>> >>>> >>>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm currently switching from OpenCV to scikit-image and came to a point >>>>> where I miss a certain feature. >>>>> >>>>> In OpenCV I used findContours() and then contourArea() to calculate the >>>>> area of each contour. I couldn't find this in scikit-image. If I didn't >>>>> miss it somewhere, could that be added as a new function? >>>>> >>>>> Thanks >>>>> Maik >>>>> >>>>> -- >>>>> 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... at 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Wed Sep 10 10:05:12 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 07:05:12 -0700 (PDT) Subject: Areas of contours In-Reply-To: <1410355600605.958bd498@Nodemailer> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> Message-ID: I just did a test on a 3000x3000 image comparing both approaches. Note that I have very few (one to three) contours where there is one big that is typically 50-70% of the whole image. My contour-only way takes 0.13secs, the other one that you suggested takes 4secs where 95% of the time is spent on accessing the area property of a single region prop. Why is that so slow? Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan Nunez-Iglesias: > > p.image contains an image of just that one region, within bbox. Note that > regionprops have lazy evaluation, so the code mentioned above should be > reasonably fast ? possibly faster than evaluating contours for the whole > image first. Also note that unless you port it to Cython, your area > function on the contours will be pretty slow. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert > wrote: > >> Hi Juan, >> >> how would I do step 5? Even if I know the bounding box it could still be >> that parts of other regions are in the box, right? >> >> I'm not sure if all that would be a bit too slow if it worked. My images >> are 4000x3000 and I guess there's a noticeable performance advantage of >> doing all further calculations just on the contours instead of the image >> itself. >> >> Cheers >> Maik >> >> Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan >> Nunez-Iglesias: >>> >>> Hey Maik, >>> >>> But what about: >>> >>> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects >>> constitute the full area from a contour >>> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in >>> the image. >>> 3) get props = skimage.regionprops(im) to get the properties of each blob >>> 4) you can then find the argmax of [p.area for p in props] >>> 5) you can then compute the contour of just that object, and offset the >>> coordinates using the .bbox property >>> >>> Would this work? It all depends on your purposes, and I?m also not sure >>> which would be most efficient. >>> >>> Juan. >>> ? >>> Sent from Mailbox >>> >>> >>> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert >>> wrote: >>> >>>> My goal is to determine the biggest contour that covers 1's in the >>>> binary image and return it, therefore I thought I first use find_contours >>>> and then calculate the area of each contour to get the right one. I'm not >>>> sure if regionprops helps me here. In the meantime I adapted a function >>>> from stackoverflow: >>>> >>>> def polygonArea(poly): >>>> """ >>>> Return area of an unclosed polygon. >>>> >>>> :see: https://stackoverflow.com/a/451482 >>>> :param poly: (n,2)-array >>>> """ >>>> # we need a plain list for the following operations >>>> if isinstance(poly, np.ndarray): >>>> poly = poly.tolist() >>>> segments = zip(poly, poly[1:] + [poly[0]]) >>>> return 0.5 * abs(sum(x0*y1 - x1*y0 >>>> for ((x0, y0), (x1, y1)) in segments)) >>>> >>>> Before using that function I un-close the returned contours. >>>> >>>> Cheers >>>> Maik >>>> >>>> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan >>>> Nunez-Iglesias: >>>>> >>>>> Hey Maik, >>>>> >>>>> Can you be a bit more specific? The pipeline may need to be a bit >>>>> different, but this seems doable. In particular, regionprops(image)[i].area >>>>> will return the area of all binary-labeled regions. >>>>> >>>>> If that doesn?t help, if you have an example image with code it might >>>>> be easier to translate your workflow. >>>>> >>>>> Note that we don?t attempt to offer feature parity with OpenCV, which >>>>> has a lot of hard computer vision algorithms that we lack. But this in >>>>> particular should be doable. >>>>> >>>>> Juan. >>>>> ? >>>>> Sent from Mailbox >>>>> >>>>> >>>>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm currently switching from OpenCV to scikit-image and came to a >>>>>> point where I miss a certain feature. >>>>>> >>>>>> In OpenCV I used findContours() and then contourArea() to calculate >>>>>> the area of each contour. I couldn't find this in scikit-image. If I didn't >>>>>> miss it somewhere, could that be added as a new function? >>>>>> >>>>>> Thanks >>>>>> Maik >>>>>> >>>>>> -- >>>>>> 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... at 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... at 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... at googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Wed Sep 10 10:27:29 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 07:27:29 -0700 (PDT) Subject: Areas of contours In-Reply-To: <6D951C4A-3273-47BA-838F-E31D7984F2D3@demuc.de> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> <460C7EBE-C3C2-4742-A64A-2738121587A0@demuc.de> <6D951C4A-3273-47BA-838F-E31D7984F2D3@demuc.de> Message-ID: <32dcb59b-b8fd-42dc-93b3-72a6efa6ffc1@googlegroups.com> If you still want to see the code, here it is: https://gist.github.com/neothemachine/64c70e6916eccf70464d You can directly run it and see some execution times. Am Mittwoch, 10. September 2014 16:19:01 UTC+2 schrieb Johannes Sch?nberger: > > Sorry for the spam, but I just found your code for calculating the area. > > region props does not use the polygonal chain for calculating the area, > but uses moments. So the bigger your blob is, the more time it takes to > calculate the moments, and vice versa. > > Johannes Sch?nberger > > On Sep 10, 2014, at 10:08 AM, Johannes Sch?nberger > wrote: > > > Forget what I said, that's certainly not the area, but can you show some > code for that, please? > > > > Johannes Sch ?nberger > > > > On Sep 10, 2014, at 10:07 AM, Johannes Sch ?nberger > wrote: > > > >> How do you calculate the are in case of the 0.13 seconds? Just the sum > of the True pixels? > >> > >> Johannes Sch ?nberger > >> > >> On Sep 10, 2014, at 10:05 AM, Maik Riechert > wrote: > >> > >>> I just did a test on a 3000x3000 image comparing both approaches. Note > that I have very few (one to three) contours where there is one big that is > typically 50-70% of the whole image. My contour-only way takes 0.13secs, > the other one that you suggested takes 4secs where 95% of the time is spent > on accessing the area property of a single region prop. Why is that so > slow? > >>> > >>> Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan > Nunez-Iglesias: > >>> p.image contains an image of just that one region, within bbox. Note > that regionprops have lazy evaluation, so the code mentioned above should > be reasonably fast -- possibly faster than evaluating contours for the > whole image first. Also note that unless you port it to Cython, your area > function on the contours will be pretty slow. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert > wrote: > >>> > >>> Hi Juan, > >>> > >>> how would I do step 5? Even if I know the bounding box it could still > be that parts of other regions are in the box, right? > >>> > >>> I'm not sure if all that would be a bit too slow if it worked. My > images are 4000x3000 and I guess there's a noticeable performance advantage > of doing all further calculations just on the contours instead of the image > itself. > >>> > >>> Cheers > >>> Maik > >>> > >>> Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan > Nunez-Iglesias: > >>> Hey Maik, > >>> > >>> But what about: > >>> > >>> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects > constitute the full area from a contour > >>> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in > the image. > >>> 3) get props = skimage.regionprops(im) to get the properties of each > blob > >>> 4) you can then find the argmax of [p.area for p in props] > >>> 5) you can then compute the contour of just that object, and offset > the coordinates using the .bbox property > >>> > >>> Would this work? It all depends on your purposes, and I'm also not > sure which would be most efficient. > >>> > >>> Juan. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert > wrote: > >>> > >>> My goal is to determine the biggest contour that covers 1's in the > binary image and return it, therefore I thought I first use find_contours > and then calculate the area of each contour to get the right one. I'm not > sure if regionprops helps me here. In the meantime I adapted a function > from stackoverflow: > >>> > >>> def polygonArea(poly): > >>> """ > >>> Return area of an unclosed polygon. > >>> > >>> :see: https://stackoverflow.com/a/451482 > >>> :param poly: (n,2)-array > >>> """ > >>> # we need a plain list for the following operations > >>> if isinstance(poly, np.ndarray): > >>> poly = poly.tolist() > >>> segments = zip(poly, poly[1:] + [poly[0]]) > >>> return 0.5 * abs(sum(x0*y1 - x1*y0 > >>> for ((x0, y0), (x1, y1)) in segments)) > >>> > >>> Before using that function I un-close the returned contours. > >>> > >>> Cheers > >>> Maik > >>> > >>> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan > Nunez-Iglesias: > >>> Hey Maik, > >>> > >>> Can you be a bit more specific? The pipeline may need to be a bit > different, but this seems doable. In particular, regionprops(image)[i].area > will return the area of all binary-labeled regions. > >>> > >>> If that doesn't help, if you have an example image with code it might > be easier to translate your workflow. > >>> > >>> Note that we don't attempt to offer feature parity with OpenCV, which > has a lot of hard computer vision algorithms that we lack. But this in > particular should be doable. > >>> > >>> Juan. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert > wrote: > >>> > >>> Hi, > >>> > >>> I'm currently switching from OpenCV to scikit-image and came to a > point where I miss a certain feature. > >>> > >>> In OpenCV I used findContours() and then contourArea() to calculate > the area of each contour. I couldn't find this in scikit-image. If I didn't > miss it somewhere, could that be added as a new function? > >>> > >>> Thanks > >>> Maik > >>> > >>> -- > >>> 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... at 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... at 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... at 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... at 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... at googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Wed Sep 10 11:06:54 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Wed, 10 Sep 2014 08:06:54 -0700 (PDT) Subject: Generic image coordinate transformation using a matrix Message-ID: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> Hi, When I want to undistort photographs I use the lensfunpy library (https://pypi.python.org/pypi/lensfunpy) which provides me with a coordinates array of shape (h,w,2), that is for each input pixel it provides the undistorted pixel location. When using OpenCV I can do undistortedImage = cv2.remap(image, undistCoords, None, cv2.INTER_LANCZOS4). I saw that there is the skimage.transform.warp function but I'm not sure how or if I can use that in my case. I would be glad for some directions. Thanks Maik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Wed Sep 10 09:24:39 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 09:24:39 -0400 Subject: Areas of contours In-Reply-To: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> References: <104cb454-38a9-4dc1-91ad-3e05288e20a0@googlegroups.com> <1410354264866.a0b2541b@Nodemailer> <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> Message-ID: Hi Maik, region props let's you also get the image of the separated region (separated meaning, only containing pixels where label == i) through `prop.image` or `prop.filled_image`. Hope it helps. Johannes Sch?nberger On Sep 10, 2014, at 9:19 AM, Maik Riechert wrote: > Hi Juan, > > how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? > > I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. > > Cheers > Maik > > Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: > Hey Maik, > > But what about: > > 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour > 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. > 3) get props = skimage.regionprops(im) to get the properties of each blob > 4) you can then find the argmax of [p.area for p in props] > 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property > > Would this work? It all depends on your purposes, and I?m also not sure which would be most efficient. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: > > My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: > > def polygonArea(poly): > """ > Return area of an unclosed polygon. > > :see: https://stackoverflow.com/a/451482 > :param poly: (n,2)-array > """ > # we need a plain list for the following operations > if isinstance(poly, np.ndarray): > poly = poly.tolist() > segments = zip(poly, poly[1:] + [poly[0]]) > return 0.5 * abs(sum(x0*y1 - x1*y0 > for ((x0, y0), (x1, y1)) in segments)) > > Before using that function I un-close the returned contours. > > Cheers > Maik > > Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: > Hey Maik, > > Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. > > If that doesn?t help, if you have an example image with code it might be easier to translate your workflow. > > Note that we don?t attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: > > Hi, > > I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. > > In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? > > Thanks > Maik > > -- > 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... at 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Wed Sep 10 10:07:26 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 10:07:26 -0400 Subject: Areas of contours In-Reply-To: References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> Message-ID: <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> How do you calculate the are in case of the 0.13 seconds? Just the sum of the True pixels? Johannes Sch?nberger On Sep 10, 2014, at 10:05 AM, Maik Riechert wrote: > I just did a test on a 3000x3000 image comparing both approaches. Note that I have very few (one to three) contours where there is one big that is typically 50-70% of the whole image. My contour-only way takes 0.13secs, the other one that you suggested takes 4secs where 95% of the time is spent on accessing the area property of a single region prop. Why is that so slow? > > Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan Nunez-Iglesias: > p.image contains an image of just that one region, within bbox. Note that regionprops have lazy evaluation, so the code mentioned above should be reasonably fast ? possibly faster than evaluating contours for the whole image first. Also note that unless you port it to Cython, your area function on the contours will be pretty slow. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert wrote: > > Hi Juan, > > how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? > > I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. > > Cheers > Maik > > Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: > Hey Maik, > > But what about: > > 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour > 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. > 3) get props = skimage.regionprops(im) to get the properties of each blob > 4) you can then find the argmax of [p.area for p in props] > 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property > > Would this work? It all depends on your purposes, and I?m also not sure which would be most efficient. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: > > My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: > > def polygonArea(poly): > """ > Return area of an unclosed polygon. > > :see: https://stackoverflow.com/a/451482 > :param poly: (n,2)-array > """ > # we need a plain list for the following operations > if isinstance(poly, np.ndarray): > poly = poly.tolist() > segments = zip(poly, poly[1:] + [poly[0]]) > return 0.5 * abs(sum(x0*y1 - x1*y0 > for ((x0, y0), (x1, y1)) in segments)) > > Before using that function I un-close the returned contours. > > Cheers > Maik > > Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: > Hey Maik, > > Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. > > If that doesn?t help, if you have an example image with code it might be easier to translate your workflow. > > Note that we don?t attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. > > Juan. > ? > Sent from Mailbox > > > On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: > > Hi, > > I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. > > In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? > > Thanks > Maik > > -- > 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... at 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... at 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Wed Sep 10 10:08:30 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 10:08:30 -0400 Subject: Areas of contours In-Reply-To: <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> Message-ID: <460C7EBE-C3C2-4742-A64A-2738121587A0@demuc.de> Forget what I said, that?s certainly not the area, but can you show some code for that, please? Johannes Sch?nberger On Sep 10, 2014, at 10:07 AM, Johannes Sch?nberger wrote: > How do you calculate the are in case of the 0.13 seconds? Just the sum of the True pixels? > > Johannes Sch?nberger > > On Sep 10, 2014, at 10:05 AM, Maik Riechert wrote: > >> I just did a test on a 3000x3000 image comparing both approaches. Note that I have very few (one to three) contours where there is one big that is typically 50-70% of the whole image. My contour-only way takes 0.13secs, the other one that you suggested takes 4secs where 95% of the time is spent on accessing the area property of a single region prop. Why is that so slow? >> >> Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan Nunez-Iglesias: >> p.image contains an image of just that one region, within bbox. Note that regionprops have lazy evaluation, so the code mentioned above should be reasonably fast ? possibly faster than evaluating contours for the whole image first. Also note that unless you port it to Cython, your area function on the contours will be pretty slow. >> ? >> Sent from Mailbox >> >> >> On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert wrote: >> >> Hi Juan, >> >> how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? >> >> I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. >> >> Cheers >> Maik >> >> Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: >> Hey Maik, >> >> But what about: >> >> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour >> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. >> 3) get props = skimage.regionprops(im) to get the properties of each blob >> 4) you can then find the argmax of [p.area for p in props] >> 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property >> >> Would this work? It all depends on your purposes, and I?m also not sure which would be most efficient. >> >> Juan. >> ? >> Sent from Mailbox >> >> >> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: >> >> My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: >> >> def polygonArea(poly): >> """ >> Return area of an unclosed polygon. >> >> :see: https://stackoverflow.com/a/451482 >> :param poly: (n,2)-array >> """ >> # we need a plain list for the following operations >> if isinstance(poly, np.ndarray): >> poly = poly.tolist() >> segments = zip(poly, poly[1:] + [poly[0]]) >> return 0.5 * abs(sum(x0*y1 - x1*y0 >> for ((x0, y0), (x1, y1)) in segments)) >> >> Before using that function I un-close the returned contours. >> >> Cheers >> Maik >> >> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: >> Hey Maik, >> >> Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. >> >> If that doesn?t help, if you have an example image with code it might be easier to translate your workflow. >> >> Note that we don?t attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. >> >> Juan. >> ? >> Sent from Mailbox >> >> >> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: >> >> Hi, >> >> I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. >> >> In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? >> >> Thanks >> Maik >> >> -- >> 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... at 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... at 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... at 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 at googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > From jsch at demuc.de Wed Sep 10 10:18:57 2014 From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 10:18:57 -0400 Subject: Areas of contours In-Reply-To: <460C7EBE-C3C2-4742-A64A-2738121587A0@demuc.de> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> <460C7EBE-C3C2-4742-A64A-2738121587A0@demuc.de> Message-ID: <6D951C4A-3273-47BA-838F-E31D7984F2D3@demuc.de> Sorry for the spam, but I just found your code for calculating the area. region props does not use the polygonal chain for calculating the area, but uses moments. So the bigger your blob is, the more time it takes to calculate the moments, and vice versa. Johannes Sch?nberger On Sep 10, 2014, at 10:08 AM, Johannes Sch?nberger wrote: > Forget what I said, that's certainly not the area, but can you show some code for that, please? > > Johannes Sch ?nberger > > On Sep 10, 2014, at 10:07 AM, Johannes Sch ?nberger wrote: > >> How do you calculate the are in case of the 0.13 seconds? Just the sum of the True pixels? >> >> Johannes Sch ?nberger >> >> On Sep 10, 2014, at 10:05 AM, Maik Riechert wrote: >> >>> I just did a test on a 3000x3000 image comparing both approaches. Note that I have very few (one to three) contours where there is one big that is typically 50-70% of the whole image. My contour-only way takes 0.13secs, the other one that you suggested takes 4secs where 95% of the time is spent on accessing the area property of a single region prop. Why is that so slow? >>> >>> Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan Nunez-Iglesias: >>> p.image contains an image of just that one region, within bbox. Note that regionprops have lazy evaluation, so the code mentioned above should be reasonably fast -- possibly faster than evaluating contours for the whole image first. Also note that unless you port it to Cython, your area function on the contours will be pretty slow. >>> -- >>> Sent from Mailbox >>> >>> >>> On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert wrote: >>> >>> Hi Juan, >>> >>> how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? >>> >>> I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. >>> >>> Cheers >>> Maik >>> >>> Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: >>> Hey Maik, >>> >>> But what about: >>> >>> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour >>> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. >>> 3) get props = skimage.regionprops(im) to get the properties of each blob >>> 4) you can then find the argmax of [p.area for p in props] >>> 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property >>> >>> Would this work? It all depends on your purposes, and I'm also not sure which would be most efficient. >>> >>> Juan. >>> -- >>> Sent from Mailbox >>> >>> >>> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: >>> >>> My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: >>> >>> def polygonArea(poly): >>> """ >>> Return area of an unclosed polygon. >>> >>> :see: https://stackoverflow.com/a/451482 >>> :param poly: (n,2)-array >>> """ >>> # we need a plain list for the following operations >>> if isinstance(poly, np.ndarray): >>> poly = poly.tolist() >>> segments = zip(poly, poly[1:] + [poly[0]]) >>> return 0.5 * abs(sum(x0*y1 - x1*y0 >>> for ((x0, y0), (x1, y1)) in segments)) >>> >>> Before using that function I un-close the returned contours. >>> >>> Cheers >>> Maik >>> >>> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: >>> Hey Maik, >>> >>> Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. >>> >>> If that doesn't help, if you have an example image with code it might be easier to translate your workflow. >>> >>> Note that we don't attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. >>> >>> Juan. >>> -- >>> Sent from Mailbox >>> >>> >>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: >>> >>> Hi, >>> >>> I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. >>> >>> In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? >>> >>> Thanks >>> Maik >>> >>> -- >>> 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... at 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... at 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... at 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 at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Wed Sep 10 10:43:26 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 10:43:26 -0400 Subject: Areas of contours In-Reply-To: <32dcb59b-b8fd-42dc-93b3-72a6efa6ffc1@googlegroups.com> References: <99575afc-d960-4b6f-9042-199f842b9df5@googlegroups.com> <1410355600605.958bd498@Nodemailer> <70D95E1A-864F-4F81-ACDC-C70EB2C9CC6A@demuc.de> <460C7EBE-C3C2-4742-A64A-2738121587A0@demuc.de> <6D951C4A-3273-47BA-838F-E31D7984F2D3@demuc.de> <32dcb59b-b8fd-42dc-93b3-72a6efa6ffc1@googlegroups.com> Message-ID: <03D74CAD-DBF9-4DC6-BA48-B5EDBE1E0AB6@demuc.de> Thanks for sharing this. regionprops is definitely missing a feature to extract the polygonal chain of the region boundary? this would be a very welcome feature. Nevertheless, for big regions you are for now better of using the approximation with find_contours and then using the polygon area. Johannes Sch?nberger On Sep 10, 2014, at 10:27 AM, Maik Riechert wrote: > If you still want to see the code, here it is: https://gist.github.com/neothemachine/64c70e6916eccf70464d > > You can directly run it and see some execution times. > > Am Mittwoch, 10. September 2014 16:19:01 UTC+2 schrieb Johannes Sch?nberger: > Sorry for the spam, but I just found your code for calculating the area. > > region props does not use the polygonal chain for calculating the area, but uses moments. So the bigger your blob is, the more time it takes to calculate the moments, and vice versa. > > Johannes Sch ?nberger > > On Sep 10, 2014, at 10:08 AM, Johannes Sch ?nberger wrote: > > > Forget what I said, that's certainly not the area, but can you show some code for that, please? > > > > Johannes Sch ?nberger > > > > On Sep 10, 2014, at 10:07 AM, Johannes Sch ?nberger wrote: > > > >> How do you calculate the are in case of the 0.13 seconds? Just the sum of the True pixels? > >> > >> Johannes Sch ?nberger > >> > >> On Sep 10, 2014, at 10:05 AM, Maik Riechert wrote: > >> > >>> I just did a test on a 3000x3000 image comparing both approaches. Note that I have very few (one to three) contours where there is one big that is typically 50-70% of the whole image. My contour-only way takes 0.13secs, the other one that you suggested takes 4secs where 95% of the time is spent on accessing the area property of a single region prop. Why is that so slow? > >>> > >>> Am Mittwoch, 10. September 2014 15:26:43 UTC+2 schrieb Juan Nunez-Iglesias: > >>> p.image contains an image of just that one region, within bbox. Note that regionprops have lazy evaluation, so the code mentioned above should be reasonably fast -- possibly faster than evaluating contours for the whole image first. Also note that unless you port it to Cython, your area function on the contours will be pretty slow. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 11:20 PM, Maik Riechert wrote: > >>> > >>> Hi Juan, > >>> > >>> how would I do step 5? Even if I know the bounding box it could still be that parts of other regions are in the box, right? > >>> > >>> I'm not sure if all that would be a bit too slow if it worked. My images are 4000x3000 and I guess there's a noticeable performance advantage of doing all further calculations just on the contours instead of the image itself. > >>> > >>> Cheers > >>> Maik > >>> > >>> Am Mittwoch, 10. September 2014 15:04:27 UTC+2 schrieb Juan Nunez-Iglesias: > >>> Hey Maik, > >>> > >>> But what about: > >>> > >>> 1) Do a scipy.ndimage.binary_fill_holes to ensure that objects constitute the full area from a contour > >>> 2) Do a scipy.ndimage.label to give a unique ID to each blob of 1s in the image. > >>> 3) get props = skimage.regionprops(im) to get the properties of each blob > >>> 4) you can then find the argmax of [p.area for p in props] > >>> 5) you can then compute the contour of just that object, and offset the coordinates using the .bbox property > >>> > >>> Would this work? It all depends on your purposes, and I'm also not sure which would be most efficient. > >>> > >>> Juan. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 10:29 PM, Maik Riechert wrote: > >>> > >>> My goal is to determine the biggest contour that covers 1's in the binary image and return it, therefore I thought I first use find_contours and then calculate the area of each contour to get the right one. I'm not sure if regionprops helps me here. In the meantime I adapted a function from stackoverflow: > >>> > >>> def polygonArea(poly): > >>> """ > >>> Return area of an unclosed polygon. > >>> > >>> :see: https://stackoverflow.com/a/451482 > >>> :param poly: (n,2)-array > >>> """ > >>> # we need a plain list for the following operations > >>> if isinstance(poly, np.ndarray): > >>> poly = poly.tolist() > >>> segments = zip(poly, poly[1:] + [poly[0]]) > >>> return 0.5 * abs(sum(x0*y1 - x1*y0 > >>> for ((x0, y0), (x1, y1)) in segments)) > >>> > >>> Before using that function I un-close the returned contours. > >>> > >>> Cheers > >>> Maik > >>> > >>> Am Mittwoch, 10. September 2014 11:43:59 UTC+2 schrieb Juan Nunez-Iglesias: > >>> Hey Maik, > >>> > >>> Can you be a bit more specific? The pipeline may need to be a bit different, but this seems doable. In particular, regionprops(image)[i].area will return the area of all binary-labeled regions. > >>> > >>> If that doesn't help, if you have an example image with code it might be easier to translate your workflow. > >>> > >>> Note that we don't attempt to offer feature parity with OpenCV, which has a lot of hard computer vision algorithms that we lack. But this in particular should be doable. > >>> > >>> Juan. > >>> -- > >>> Sent from Mailbox > >>> > >>> > >>> On Wed, Sep 10, 2014 at 7:40 PM, Maik Riechert wrote: > >>> > >>> Hi, > >>> > >>> I'm currently switching from OpenCV to scikit-image and came to a point where I miss a certain feature. > >>> > >>> In OpenCV I used findContours() and then contourArea() to calculate the area of each contour. I couldn't find this in scikit-image. If I didn't miss it somewhere, could that be added as a new function? > >>> > >>> Thanks > >>> Maik > >>> > >>> -- > >>> 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... at 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... at 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... at 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... at 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Wed Sep 10 13:23:39 2014 From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 13:23:39 -0400 Subject: Generic image coordinate transformation using a matrix In-Reply-To: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> References: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> Message-ID: <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> Hi Mark, You can do this with `ndimage.map_coordinates`, see https://github.com/scikit-image/scikit-image/blob/master/skimage/transform/_geometric.py#L1134 for an usage example. But we should add this feature, so that `warp` also directly takes the coordinates. I opened a new issue for this: https://github.com/scikit-image/scikit-image/issues/1141 Johannes Sch?nberger On Sep 10, 2014, at 11:06 AM, Maik Riechert wrote: > Hi, > > When I want to undistort photographs I use the lensfunpy library (https://pypi.python.org/pypi/lensfunpy) which provides me with a coordinates array of shape (h,w,2), that is for each input pixel it provides the undistorted pixel location. When using OpenCV I can do undistortedImage = cv2.remap(image, undistCoords, None, cv2.INTER_LANCZOS4). I saw that there is the skimage.transform.warp function but I'm not sure how or if I can use that in my case. I would be glad for some directions. > > Thanks > Maik > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From jsch at demuc.de Wed Sep 10 13:44:06 2014 From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=0F=F6nberger?=) Date: Wed, 10 Sep 2014 13:44:06 -0400 Subject: Generic image coordinate transformation using a matrix In-Reply-To: <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> References: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> Message-ID: <286BC2F8-E726-441C-A7E7-135D73E548E3@demuc.de> Mark, can you check, that this works for you? https://github.com/scikit-image/scikit-image/pull/1142 Johannes Sch?nberger On Sep 10, 2014, at 1:23 PM, Johannes Sch?nberger wrote: > Hi Mark, > > You can do this with `ndimage.map_coordinates`, see https://github.com/scikit-image/scikit-image/blob/master/skimage/transform/_geometric.py#L1134 for an usage example. > > But we should add this feature, so that `warp` also directly takes the coordinates. I opened a new issue for this: https://github.com/scikit-image/scikit-image/issues/1141 > > Johannes Sch ?nberger > > On Sep 10, 2014, at 11:06 AM, Maik Riechert wrote: > >> Hi, >> >> When I want to undistort photographs I use the lensfunpy library (https://pypi.python.org/pypi/lensfunpy) which provides me with a coordinates array of shape (h,w,2), that is for each input pixel it provides the undistorted pixel location. When using OpenCV I can do undistortedImage = cv2.remap(image, undistCoords, None, cv2.INTER_LANCZOS4). I saw that there is the skimage.transform.warp function but I'm not sure how or if I can use that in my case. I would be glad for some directions. >> >> Thanks >> Maik >> >> -- >> 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 at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From stefan at sun.ac.za Wed Sep 10 20:03:32 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Thu, 11 Sep 2014 01:03:32 +0100 Subject: Areas of contours In-Reply-To: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> References: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> Message-ID: Hi Mike On Wed, Sep 10, 2014 at 10:35 AM, Maik Riechert wrote: > In OpenCV I used findContours() and then contourArea() to calculate the area > of each contour. I couldn't find this in scikit-image. If I didn't miss it > somewhere, could that be added as a new function? I happened to run into very similar problems this week. I see no reason to include its calculation, especially if we can also implement additional contour finding algorithms (at the moment, we just have constant-value contours via marching squares). We can implement it as a helper method for regionprops, and then update regionprops to use it once it supports proper region boundary detection. Would you be interested in helping with this? My standard reference for polygons is http://paulbourke.net/geometry/polygonmesh/ If not, let me know and I'll give it a shot. St?fan From maik.riechert at arcor.de Thu Sep 11 04:56:56 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Thu, 11 Sep 2014 01:56:56 -0700 (PDT) Subject: Generic image coordinate transformation using a matrix In-Reply-To: <286BC2F8-E726-441C-A7E7-135D73E548E3@demuc.de> References: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> <286BC2F8-E726-441C-A7E7-135D73E548E3@demuc.de> Message-ID: I just tested it and it doesn't work yet. My image is an uint8 array of shape (2832, 4256, 3), and the coordinate array is float32 (2832, 4256, 2) but when using skimage.transform.warp(im, undistCoords) I get: Traceback (most recent call last): File ... imUndistorted = skimage.transform.warp(im, undistCoords) File "/home/mriecher/.local/lib/python2.7/site-packages/skimage/transform/_geometric.py", line 1153, in warp mode=mode, order=order, cval=cval) File "/usr/lib/python2.7/dist-packages/scipy/ndimage/interpolation.py", line 289, in map_coordinates raise RuntimeError('invalid shape for coordinate array') RuntimeError: invalid shape for coordinate array Looking at map_coordinates: if coordinates.shape[0] != input.ndim: raise RuntimeError('invalid shape for coordinate array') I tried some other array shapes but couldn't make it work. What's the correct way here? Maik Am Mittwoch, 10. September 2014 19:44:11 UTC+2 schrieb Johannes Sch?nberger: > > Mark, can you check, that this works for you? > > https://github.com/scikit-image/scikit-image/pull/1142 > > Johannes Sch?nberger > > On Sep 10, 2014, at 1:23 PM, Johannes Sch?nberger > wrote: > > > Hi Mark, > > > > You can do this with `ndimage.map_coordinates`, see > https://github.com/scikit-image/scikit-image/blob/master/skimage/transform/_geometric.py#L1134 > for an usage example. > > > > But we should add this feature, so that `warp` also directly takes the > coordinates. I opened a new issue for this: > https://github.com/scikit-image/scikit-image/issues/1141 > > > > Johannes Sch ?nberger > > > > On Sep 10, 2014, at 11:06 AM, Maik Riechert > wrote: > > > >> Hi, > >> > >> When I want to undistort photographs I use the lensfunpy library ( > https://pypi.python.org/pypi/lensfunpy) which provides me with a > coordinates array of shape (h,w,2), that is for each input pixel it > provides the undistorted pixel location. When using OpenCV I can do > undistortedImage = cv2.remap(image, undistCoords, None, > cv2.INTER_LANCZOS4). I saw that there is the skimage.transform.warp > function but I'm not sure how or if I can use that in my case. I would be > glad for some directions. > >> > >> Thanks > >> Maik > >> > >> -- > >> 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... at 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... at googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Thu Sep 11 07:59:04 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Thu, 11 Sep 2014 04:59:04 -0700 (PDT) Subject: Add line thickness for draw module functions Message-ID: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> Hi, I'm a bit surprised that the coordinate functions in the draw module don't have a thickness parameter. Is there some other way of thickening the lines? Otherwise they are only of very limited use, aren't they? Also, in addition to the polygon function there should be a function for polylines. In the meantime I hacked something together but it's not ideal: def polyline(poly): """ use skimage.draw.line repeatedly to build all pixels that belong to a polyline :param poly: (n,2) ndarray of (y,x) pairs :rtype: rr, cc : (m,) ndarray of int Indices of pixels that belong to the polyline. """ rrs, ccs = [], [] for i in range(poly.shape[0]-1): y = poly[i,0] x = poly[i,1] y2 = poly[i+1,0] x2 = poly[i+1,1] rr, cc = skimage.draw.line(y,x,y2,x2) rrs.append(rr) ccs.append(cc) # this will contain duplicates, but shouldn't be an issue rr = np.concatenate(rrs) cc = np.concatenate(ccs) return rr,cc Cheers Maik -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Thu Sep 11 08:01:24 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Thu, 11 Sep 2014 05:01:24 -0700 (PDT) Subject: Areas of contours In-Reply-To: References: <000e9f20-fe45-4bb2-8a69-61d31bb0d54b@googlegroups.com> Message-ID: Hi Stefan, I happened to run into very similar problems this week. I see no > reason to include its calculation, especially if we can also implement > additional contour finding algorithms (at the moment, we just have > constant-value contours via marching squares). We can implement it as > a helper method for regionprops, and then update regionprops to use it > once it supports proper region boundary detection. > > Would you be interested in helping with this? My standard reference > for polygons is > > http://paulbourke.net/geometry/polygonmesh/ > > I'm afraid I currently don't have enough time but I'm happy to help test it etc. Cheers Maik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Thu Sep 11 09:15:40 2014 From: jsch at demuc.de (=?iso-8859-1?Q?Johannes_Sch=0F=F6nberger?=) Date: Thu, 11 Sep 2014 09:15:40 -0400 Subject: Generic image coordinate transformation using a matrix In-Reply-To: References: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> <286BC2F8-E726-441C-A7E7-135D73E548E3@demuc.de> Message-ID: You would have to reorder the dimensions of your coordinate matrix to `(2, 2832, 4256)`. Johannes Sch?nberger On Sep 11, 2014, at 4:56 AM, Maik Riechert wrote: > I just tested it and it doesn't work yet. > My image is an uint8 array of shape (2832, 4256, 3), and the coordinate array is float32 (2832, 4256, 2) but when using skimage.transform.warp(im, undistCoords) I get: > > > Traceback (most recent call last): > File ... > imUndistorted = skimage.transform.warp(im, undistCoords) > File "/home/mriecher/.local/lib/python2.7/site-packages/skimage/transform/_geometric.py", line 1153, in warp > mode=mode, order=order, cval=cval) > File "/usr/lib/python2.7/dist-packages/scipy/ndimage/interpolation.py", line 289, in map_coordinates > raise RuntimeError('invalid shape for coordinate array') > RuntimeError: invalid shape for coordinate array > > Looking at map_coordinates: > > if coordinates.shape[0] != input.ndim: > raise RuntimeError('invalid shape for coordinate array') > > I tried some other array shapes but couldn't make it work. What's the correct way here? > > Maik > > > Am Mittwoch, 10. September 2014 19:44:11 UTC+2 schrieb Johannes Sch?nberger: > Mark, can you check, that this works for you? > > https://github.com/scikit-image/scikit-image/pull/1142 > > Johannes Sch ?nberger > > On Sep 10, 2014, at 1:23 PM, Johannes Sch ?nberger wrote: > > > Hi Mark, > > > > You can do this with `ndimage.map_coordinates`, see https://github.com/scikit-image/scikit-image/blob/master/skimage/transform/_geometric.py#L1134 for an usage example. > > > > But we should add this feature, so that `warp` also directly takes the coordinates. I opened a new issue for this: https://github.com/scikit-image/scikit-image/issues/1141 > > > > Johannes Sch ?nberger > > > > On Sep 10, 2014, at 11:06 AM, Maik Riechert wrote: > > > >> Hi, > >> > >> When I want to undistort photographs I use the lensfunpy library (https://pypi.python.org/pypi/lensfunpy) which provides me with a coordinates array of shape (h,w,2), that is for each input pixel it provides the undistorted pixel location. When using OpenCV I can do undistortedImage = cv2.remap(image, undistCoords, None, cv2.INTER_LANCZOS4). I saw that there is the skimage.transform.warp function but I'm not sure how or if I can use that in my case. I would be glad for some directions. > >> > >> Thanks > >> Maik > >> > >> -- > >> 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... at 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... at 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From hannesschoenberger at gmail.com Thu Sep 11 15:00:59 2014 From: hannesschoenberger at gmail.com (=?UTF-8?Q?Johannes_Sch=C3=B6nberger?=) Date: Thu, 11 Sep 2014 12:00:59 -0700 (PDT) Subject: Generic image coordinate transformation using a matrix In-Reply-To: References: <1dfea887-8f2f-4b46-9432-fb50ae368f08@googlegroups.com> <38E41107-463A-4BAF-8DBD-4982BA4CF4FF@demuc.de> <286BC2F8-E726-441C-A7E7-135D73E548E3@demuc.de> Message-ID: <3adb516d-0238-4169-995b-5a04cf22994c@googlegroups.com> @Mark, I see that there was a bug in my code on github. It should work now. It would be great, if you could test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Sep 11 08:39:08 2014 From: stefan at sun.ac.za (Stefan van der Walt) Date: Thu, 11 Sep 2014 13:39:08 +0100 Subject: Add line thickness for draw module functions In-Reply-To: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> References: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> Message-ID: <878ulqnxg3.fsf@sun.ac.za> On 2014-09-11 12:59:04, Maik Riechert wrote: > I'm a bit surprised that the coordinate functions in the draw module don't > have a thickness parameter. Is there some other way of thickening the > lines? Otherwise they are only of very limited use, aren't they? Juan hacked something together as well for the skimage paper, which we can look into adding here. Recently, I had a conversation with Phil Elson, who showed me that it is possible to do the actual drawing and matplotlib and then transfer the relevant parts of the canvas over. This may be a more productive approach in the long run. Phil, any advice, especially on doing alpha values? St?fan From pelson.pub at gmail.com Thu Sep 11 14:10:37 2014 From: pelson.pub at gmail.com (Phil Elson) Date: Thu, 11 Sep 2014 19:10:37 +0100 Subject: Add line thickness for draw module functions In-Reply-To: <878ulqnxg3.fsf@sun.ac.za> References: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> <878ulqnxg3.fsf@sun.ac.za> Message-ID: I'm currently out in the sticks in rural New York state with only my phone for connectivity, so can't help too much right now, but I was going to spin off a thread here about a possible interface for overlaying mpl figues (including axes) on an image (the result would always be RGBA). Of course this would include anything that mpl can draw, such as anti-aliased lines and text (through freetype) of arbitrary thickness. I actually managed to pull all the components together on my 4hr train ride to the airport the other day, so I really just need to package it up into a nice interface. I should be able to provide more details on Tuesday. Cheers, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From neothemachine at googlemail.com Fri Sep 12 05:29:17 2014 From: neothemachine at googlemail.com (Maik Riechert) Date: Fri, 12 Sep 2014 11:29:17 +0200 Subject: Add line thickness for draw module functions In-Reply-To: References: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> <878ulqnxg3.fsf@sun.ac.za> Message-ID: Phil, would using mpl mean that you actually manually have to create a figure etc.? Or would this happen behind the scenes and the current skimage.draw API is kept? My use case is drawing around 1000 circles on a 4000x3000 image, and it has to be quite fast (on-demand rendering). Cheers Maik 2014-09-11 20:10 GMT+02:00 Phil Elson : > I'm currently out in the sticks in rural New York state with only my phone > for connectivity, so can't help too much right now, but I was going to spin > off a thread here about a possible interface for overlaying mpl figues > (including axes) on an image (the result would always be RGBA). Of course > this would include anything that mpl can draw, such as anti-aliased lines > and text (through freetype) of arbitrary thickness. > > I actually managed to pull all the components together on my 4hr train > ride to the airport the other day, so I really just need to package it up > into a nice interface. > > I should be able to provide more details on Tuesday. > > Cheers, > > Phil > > -- > You received this message because you are subscribed to a topic in the > Google Groups "scikit-image" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/scikit-image/94M63REkxcE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > scikit-image+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neothemachine at googlemail.com Fri Sep 12 07:52:00 2014 From: neothemachine at googlemail.com (Maik Riechert) Date: Fri, 12 Sep 2014 13:52:00 +0200 Subject: Add line thickness for draw module functions In-Reply-To: References: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> <878ulqnxg3.fsf@sun.ac.za> Message-ID: Sorry for the spam. One more question: Which library would you recommend in the meantime for drawing circles and (poly)lines with thickness on top of an image? Is pillow my best bet or is there something more lightweight? Cheers Maik 2014-09-12 11:29 GMT+02:00 Maik Riechert : > Phil, would using mpl mean that you actually manually have to create a > figure etc.? Or would this happen behind the scenes and the current > skimage.draw API is kept? My use case is drawing around 1000 circles on a > 4000x3000 image, and it has to be quite fast (on-demand rendering). > > Cheers > Maik > > 2014-09-11 20:10 GMT+02:00 Phil Elson : > >> I'm currently out in the sticks in rural New York state with only my >> phone for connectivity, so can't help too much right now, but I was going >> to spin off a thread here about a possible interface for overlaying mpl >> figues (including axes) on an image (the result would always be RGBA). Of >> course this would include anything that mpl can draw, such as anti-aliased >> lines and text (through freetype) of arbitrary thickness. >> >> I actually managed to pull all the components together on my 4hr train >> ride to the airport the other day, so I really just need to package it up >> into a nice interface. >> >> I should be able to provide more details on Tuesday. >> >> Cheers, >> >> Phil >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "scikit-image" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/scikit-image/94M63REkxcE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> scikit-image+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Fri Sep 12 17:11:14 2014 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Fri, 12 Sep 2014 14:11:14 -0700 (PDT) Subject: String formatting style In-Reply-To: References: Message-ID: The main reason I?ve preferred the .format method in a couple of recent PRs and my own work is completely separate from readability. I feel the % operator is inappropriately overloaded when used both as the proper ?modulo? operator as well as a common shortcut to control string formatting. It always felt odd to me, like Python?s C roots were showing. It?s true, .format is not always more readable. However, I?ve found this is more of an adjustment than objectively true. The only danger is that explicit numbers must be used for all inserted brackets instead of empty brackets to retain Python 2.6 compatibility. I don?t really mind either way, just food for thought. Josh On Wednesday, September 3, 2014 5:57:56 AM UTC-4, Stefan van der Walt wrote: On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye wrote: > > It's part of the Python tutorial for many years and common standard I'd > say. > > It's basic use might be cumbersome at first, but its power is great. > > > > Things like "My name is {0[name]}".format(dict(name='Fred')) > > With great power comes great responsibility! I find the above very > close to unreadable. > > Compare to: > > "My name is %s" % name > > or > > "My name is %(name)s" % {'name': 'Fred'} > > St?fan > ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neothemachine at googlemail.com Fri Sep 12 10:44:14 2014 From: neothemachine at googlemail.com (Maik Riechert) Date: Fri, 12 Sep 2014 16:44:14 +0200 Subject: Add line thickness for draw module functions In-Reply-To: References: <5a357554-c2c5-451b-aacc-16ad2fdafea8@googlegroups.com> <878ulqnxg3.fsf@sun.ac.za> Message-ID: I found a suitable work-around for me now, using matplotlib. Basically preparing the figure and loading the image into it such that it can be saved again in native resolution. Also, drawing things is in native image coordinates: https://gist.github.com/neothemachine/ec1d11172d4edf8221af Cheers Maik 2014-09-12 13:52 GMT+02:00 Maik Riechert : > Sorry for the spam. One more question: Which library would you recommend > in the meantime for drawing circles and (poly)lines with thickness on top > of an image? Is pillow my best bet or is there something more lightweight? > > Cheers > Maik > > 2014-09-12 11:29 GMT+02:00 Maik Riechert : > >> Phil, would using mpl mean that you actually manually have to create a >> figure etc.? Or would this happen behind the scenes and the current >> skimage.draw API is kept? My use case is drawing around 1000 circles on a >> 4000x3000 image, and it has to be quite fast (on-demand rendering). >> >> Cheers >> Maik >> >> 2014-09-11 20:10 GMT+02:00 Phil Elson : >> >>> I'm currently out in the sticks in rural New York state with only my >>> phone for connectivity, so can't help too much right now, but I was going >>> to spin off a thread here about a possible interface for overlaying mpl >>> figues (including axes) on an image (the result would always be RGBA). Of >>> course this would include anything that mpl can draw, such as anti-aliased >>> lines and text (through freetype) of arbitrary thickness. >>> >>> I actually managed to pull all the components together on my 4hr train >>> ride to the airport the other day, so I really just need to package it up >>> into a nice interface. >>> >>> I should be able to provide more details on Tuesday. >>> >>> Cheers, >>> >>> Phil >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "scikit-image" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/scikit-image/94M63REkxcE/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> scikit-image+unsubscribe at googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Sat Sep 13 10:01:45 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Sat, 13 Sep 2014 10:01:45 -0400 Subject: Matplotlib style sheets In-Reply-To: References: Message-ID: <01BFC6D0-ED3F-4A8E-A584-F6091BBAB442@demuc.de> Nice. Now we only have to settle for a style? :-) I like this one here: http://matplotlib.org/examples/style_sheets/plot_bmh.html Johannes Sch?nberger On Sep 13, 2014, at 9:43 AM, St?fan van der Walt wrote: > Hi all > > A heads up about a new feature in Matplotlib 1.4, style sheets: > > http://matplotlib.org/users/style_sheets.html > http://matplotlib.org/gallery.html#style_sheets > > I imagine this will be very useful for the examples gallery and documentation. > > Regards > 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+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From stefan at sun.ac.za Sat Sep 13 09:43:06 2014 From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Sat, 13 Sep 2014 14:43:06 +0100 Subject: Matplotlib style sheets Message-ID: Hi all A heads up about a new feature in Matplotlib 1.4, style sheets: http://matplotlib.org/users/style_sheets.html http://matplotlib.org/gallery.html#style_sheets I imagine this will be very useful for the examples gallery and documentation. Regards St?fan From stefan at sun.ac.za Wed Sep 17 06:10:46 2014 From: stefan at sun.ac.za (Stefan van der Walt) Date: Wed, 17 Sep 2014 11:10:46 +0100 Subject: New core developer: Steven Silvester Message-ID: <87ha06zheh.fsf@sun.ac.za> Hi everyone I am happy to announce that Steven Silvester has joined the scikit-image core team. Welcome, Steven, we look forward to many productive collaborations and taking the project to new heights together! St?fan From kmichael.aye at gmail.com Wed Sep 17 19:28:11 2014 From: kmichael.aye at gmail.com (Michael Aye) Date: Wed, 17 Sep 2014 16:28:11 -0700 (PDT) Subject: String formatting style In-Reply-To: References: Message-ID: <12f48235-4006-4f5b-81fe-4c0a667b52b0@googlegroups.com> On Wednesday, September 3, 2014 2:57:56 AM UTC-7, Stefan van der Walt wrote: > > On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye > wrote: > > It's part of the Python tutorial for many years and common standard I'd > say. > > It's basic use might be cumbersome at first, but its power is great. > > > > Things like "My name is {0[name]}".format(dict(name='Fred')) > > With great power comes great responsibility! I find the above very > close to unreadable. > > Compare to: > > "My name is %s" % name > > This one is an unfair comparison as you have removed the dictionary part (for template codings). In this simplest case it just can be "My name is {}".format(name) and that is arguable better readable, especially considering the cluttered %s" % part in the old syntax. In this simplest case I much prefer not to have all these modulo operators flying around. When including dictionary access for run-time templates, obviously it get's more complicated. How does the old syntax deal with 2 or more dictionaries? Here it would just be another number: "Our names are {0[name]} and {1[name]}".format(dict(name="Fred"), dict(name="Susan")) Obviously, in real code, one would never define the dictionaries inside the format() but they would be determined elsewhere in the code, so in reality this would more look like: "Our names are {0[name]} and {1[name]} and we live at {0[address]} and {1[address]} respectively".format(d0, d1) Michael or > > "My name is %(name)s" % {'name': 'Fred'} > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmichael.aye at gmail.com Wed Sep 17 19:31:16 2014 From: kmichael.aye at gmail.com (Michael Aye) Date: Wed, 17 Sep 2014 16:31:16 -0700 (PDT) Subject: String formatting style In-Reply-To: <12f48235-4006-4f5b-81fe-4c0a667b52b0@googlegroups.com> References: <12f48235-4006-4f5b-81fe-4c0a667b52b0@googlegroups.com> Message-ID: <4b29b08b-6bf6-4f9d-abc9-230944b065c8@googlegroups.com> On Wednesday, September 17, 2014 4:28:11 PM UTC-7, Michael Aye wrote: > > > > On Wednesday, September 3, 2014 2:57:56 AM UTC-7, Stefan van der Walt > wrote: >> >> On Wed, Sep 3, 2014 at 1:20 AM, Michael Aye wrote: >> > It's part of the Python tutorial for many years and common standard I'd >> say. >> > It's basic use might be cumbersome at first, but its power is great. >> > >> > Things like "My name is {0[name]}".format(dict(name='Fred')) >> >> With great power comes great responsibility! I find the above very >> close to unreadable. >> >> Compare to: >> >> "My name is %s" % name >> >> This one is an unfair comparison as you have removed the dictionary part > (for template codings). > In this simplest case it just can be > > "My name is {}".format(name) > > and that is arguable better readable, especially considering the cluttered > %s" % part in the old syntax. > In this simplest case I much prefer not to have all these modulo operators > flying around. > When including dictionary access for run-time templates, obviously it > get's more complicated. > How does the old syntax deal with 2 or more dictionaries? > Here it would just be another number: > "Our names are {0[name]} and {1[name]}".format(dict(name="Fred"), > dict(name="Susan")) > Obviously, in real code, one would never define the dictionaries inside > the format() but they would be > determined elsewhere in the code, so in reality this would more look like: > > "Our names are {0[name]} and {1[name]} and we live at > {0[address]} and {1[address]} respectively".format(d0, d1) > > > BTW, these can be named of course, which improves readability, I think: "Our names are {cust1[name]) and {cust2[name]} and we live at {cust1[address]} and {cust2[address]} respectively.".format(cust1=d1, cust2=d2) > Michael > > or >> >> "My name is %(name)s" % {'name': 'Fred'} >> >> St?fan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Thu Sep 18 00:58:21 2014 From: jni.soma at gmail.com (jni.soma at gmail.com) Date: Wed, 17 Sep 2014 21:58:21 -0700 (PDT) Subject: New core developer: Steven Silvester In-Reply-To: <87ha06zheh.fsf@sun.ac.za> References: <87ha06zheh.fsf@sun.ac.za> Message-ID: <1411016300889.b227a2fc@Nodemailer> Congrats, Steven! ? Sent from Mailbox On Wed, Sep 17, 2014 at 8:10 PM, Stefan van der Walt wrote: > Hi everyone > I am happy to announce that Steven Silvester has joined the scikit-image > core team. Welcome, Steven, we look forward to many productive > collaborations and taking the project to new heights together! > 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+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Sep 22 07:54:45 2014 From: stefan at sun.ac.za (Stefan van der Walt) Date: Mon, 22 Sep 2014 13:54:45 +0200 Subject: Fwd: [Numpy-discussion] ANN: xray 0.3 released References: Message-ID: <8738bjzx8a.fsf@sun.ac.za> For those of you who do a lot of N-d processing: On 2014-09-22 05:44:37, Stephan Hoyer wrote: > I'm pleased to announce the v0.3 release for xray, N-D labeled arrays and > datasets in Python. > > xray is an open source project and Python package that aims to bring > the labeled data power of pandas to the physical sciences, by > providing N-dimensional variants of the core pandas data structures, Series > and DataFrame: the xray DataArray and Dataset. > > Our goal is to provide a pandas-like and pandas-compatible toolkit > for analytics on multi-dimensional arrays, rather than the tabular data for > which pandas excels. Our approach adopts the Common Data Model for > self-describing scientific data in widespread use in the Earth sciences > (e.g., > netCDF and OPeNDAP): xray.Dataset is an in-memory representation of > a netCDF file. > > Documentation: http://xray.readthedocs.org > Code: http://github.com/xray/xray > Mailing list: xray-dev at googlegroups.com > > Comments, feedback and contributions are all very welcome! > > Cheers, > Stephan From stefan at sun.ac.za Fri Sep 26 11:15:48 2014 From: stefan at sun.ac.za (Stefan van der Walt) Date: Fri, 26 Sep 2014 17:15:48 +0200 Subject: How to Apply the Otsu Threshold Excluding Zero Values In-Reply-To: <16f32244-b1fe-41e8-8f78-45bb800f6e65@googlegroups.com> References: <16f32244-b1fe-41e8-8f78-45bb800f6e65@googlegroups.com> Message-ID: <8761gawgyj.fsf@sun.ac.za> On 2014-09-26 08:03:24, vbubbly21 at gmail.com wrote: > I want to use "skimage.filter.threshold_otsu(image, nbins=256)" module > excluding the 0 values of my image while computing the threshold. How about: skimage.filter.threshold_otsu(image[image != 0], nbins=256) St?fan From aizvorski at gmail.com Sat Sep 27 01:08:36 2014 From: aizvorski at gmail.com (Alexander Izvorski) Date: Fri, 26 Sep 2014 22:08:36 -0700 (PDT) Subject: ANN: scikit-video 0.1.2 Message-ID: Hello, This is to announce an early version of scikit-video, a scikit for all your video needs :) Please excuse posting here, I think this may be of interest for anyone using scikit-image to work with video. Code: https://github.com/aizvorski/scikit-video Status: There is video reading and writing code, which is a drop-in replacement for opencv's VideoCapture and VideoWriter; some simple video player and transcoder examples using this; and a bunch of video quality metrics. Overall this is beta quality but usable. Motivation: This scikit is intended as a companion to scikit-image: the two are complementary and not competitive. What code is better in scikit-video than in scikit-image? Roughly, if the code *only* makes sense when applied to a sequence of images, then it may be better placed in scikit-video. An example of this would be temporal denoise. Other code which would make sense to have in here is code which is more often seen or used in a video context, even though it may in principle be used for both images or video. An example of this would be the SSIM quality metric. It is intended that scikit-image and scikit-video would "just work" together, for example you might read a video file using skvideo, use a skimage filter on each frame and write out the filtered frames to another file with skvideo. The video I/O part of this is perhaps even more useful now that skimage.io.video is not available in newer skimage releases. Roadmap: - Skeleton project from scikit-example - DONE - Video IO by wrapping ffmpeg/avconv - reading and writing DONE - Video metrics - have SSIM, VIF, PSNR (would like VQM, VQuad, polar edge coherence, ...) - Unit tests and CI - not yet :) (beyond this point are just possible future directions) - (?) TLD, CMT and other object tracking algorithms (wrap C, CUDA code) - (?) Pyramid motion estimation - (?) Details about a compressed video file: macroblock types, motion vectors, ... - (?) 3D denoise, guided filter denoise, etc - (?) Mini video player (there is already a playback example but without UI) - (?) Any existing off-the-shelf projects that would be good to merge into this I expect that if this gathers enough interest it will transition to a group-maintained project similar to skimage or sklearn. Your suggestions, ideas, and code are most welcome. Regards, Alex Izvorski -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvertrumpet999 at gmail.com Sat Sep 27 01:33:23 2014 From: silvertrumpet999 at gmail.com (Josh Warner) Date: Fri, 26 Sep 2014 22:33:23 -0700 (PDT) Subject: ANN: scikit-video 0.1.2 In-Reply-To: References: Message-ID: Hi Alex, Thanks for the notice! I haven't inspected the code, but a robust pure-Python video interface would be very helpful to the Python ecosystem as a whole. I look forward to trying this out in the next few days. As a subtle point, I see it is released under the GPL v3. Much of the scientific Python ecosystem employs the modified BSD license, and we will be unable to link directly to your package or tightly include it from the scikit-image side because of the viral nature of the GPL. Also, some of our contributors would be unable to work on a GPL'd package because of employer requirements. If you would consider re-licensing under the modified BSD, cross pollination with scikit-image and the rest of the Python ecosystem would be much easier! I know, licensing is the last thing we want to deal with - code is where all the fun is - but I figured I'd bring this to your attention in case you were unaware. Cheers, Josh On Saturday, September 27, 2014 1:08:36 AM UTC-4, Alexander Izvorski wrote: > > Hello, This is to announce an early version of scikit-video, a scikit for > all your video needs :) Please excuse posting here, I think this may be of > interest for anyone using scikit-image to work with video. Code: > https://github.com/aizvorski/scikit-video Status: There is video reading > and writing code, which is a drop-in replacement for opencv's VideoCapture > and VideoWriter; some simple video player and transcoder examples using > this; and a bunch of video quality metrics. Overall this is beta quality > but usable. Motivation: This scikit is intended as a companion to > scikit-image: the two are complementary and not competitive. What code is > better in scikit-video than in scikit-image? Roughly, if the code *only* > makes sense when applied to a sequence of images, then it may be better > placed in scikit-video. An example of this would be temporal denoise. Other > code which would make sense to have in here is code which is more often > seen or used in a video context, even though it may in principle be used > for both images or video. An example of this would be the SSIM quality > metric. > > It is intended that scikit-image and scikit-video would "just work" > together, for example you might read a video file using skvideo, use a > skimage filter on each frame and write out the filtered frames to another > file with skvideo. > > The video I/O part of this is perhaps even more useful now that skimage.io > .video is not available in newer skimage releases. > Roadmap: - Skeleton project from scikit-example - DONE - Video IO by > wrapping ffmpeg/avconv - reading and writing DONE - Video metrics - have > SSIM, VIF, PSNR (would like VQM, VQuad, polar edge coherence, ...) - Unit > tests and CI - not yet :) (beyond this point are just possible future > directions) > - (?) TLD, CMT and other object tracking algorithms (wrap C, CUDA code) - > (?) Pyramid motion estimation > - (?) Details about a compressed video file: macroblock types, motion > vectors, ... - (?) 3D denoise, guided filter denoise, etc - (?) Mini video > player (there is already a playback example but without UI) - (?) Any > existing off-the-shelf projects that would be good to merge into this I > expect that if this gathers enough interest it will transition to a > group-maintained project similar to skimage or sklearn. Your suggestions, > ideas, and code are most welcome. Regards, Alex Izvorski > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbubbly21 at gmail.com Sat Sep 27 01:25:53 2014 From: vbubbly21 at gmail.com (Artur Bercik) Date: Sat, 27 Sep 2014 14:25:53 +0900 Subject: How to Apply the Otsu Threshold Excluding Zero Values In-Reply-To: <8761gawgyj.fsf@sun.ac.za> References: <16f32244-b1fe-41e8-8f78-45bb800f6e65@googlegroups.com> <8761gawgyj.fsf@sun.ac.za> Message-ID: Thank you St?fan, it worked. On Sat, Sep 27, 2014 at 12:15 AM, Stefan van der Walt wrote: > > On 2014-09-26 08:03:24, vbubbly21 at gmail.com wrote: > > I want to use "skimage.filter.threshold_otsu(image, nbins=256)" module > > excluding the 0 values of my image while computing the threshold. > > How about: > > skimage.filter.threshold_otsu(image[image != 0], nbins=256) > > 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+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsch at demuc.de Sun Sep 28 16:43:19 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Sun, 28 Sep 2014 16:43:19 -0400 Subject: scikits-image on PyPI Message-ID: <7F413292-88EB-475E-9D4D-75F4AA529A25@demuc.de> Should we delete this old site here? Just to prevent accidental install of scikits-image, when people mistype it? https://pypi.python.org/pypi/scikits-image/0.7.1 Johannes Sch?nberger From jsch at demuc.de Sun Sep 28 17:56:26 2014 From: jsch at demuc.de (=?windows-1252?Q?Johannes_Sch=0F=F6nberger?=) Date: Sun, 28 Sep 2014 17:56:26 -0400 Subject: scikits-image on PyPI In-Reply-To: <7F413292-88EB-475E-9D4D-75F4AA529A25@demuc.de> References: <7F413292-88EB-475E-9D4D-75F4AA529A25@demuc.de> Message-ID: <27BB23AB-C0C1-401D-AE74-3EE595DF4D18@demuc.de> Especially, look at the number of downloads? a lot of people actually install a very old version. Johannes Sch?nberger On Sep 28, 2014, at 4:43 PM, Johannes Sch?nberger wrote: > Should we delete this old site here? Just to prevent accidental install of scikits-image, when people mistype it... > > https://pypi.python.org/pypi/scikits-image/0.7.1 > > Johannes Sch ?nberger > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From stefan at sun.ac.za Sun Sep 28 20:27:02 2014 From: stefan at sun.ac.za (Stefan van der Walt) Date: Mon, 29 Sep 2014 02:27:02 +0200 Subject: scikits-image on PyPI In-Reply-To: <7F413292-88EB-475E-9D4D-75F4AA529A25@demuc.de> References: <7F413292-88EB-475E-9D4D-75F4AA529A25@demuc.de> Message-ID: <87wq8nuv8p.fsf@sun.ac.za> On 2014-09-28 22:43:19, Johannes Sch?nberger wrote: > Should we delete this old site here? Just to prevent accidental install of scikits-image, when people mistype it... > > https://pypi.python.org/pypi/scikits-image/0.7.1 Good point--it's now gone. Thanks St?fan From matteo.niccoli at gmail.com Tue Sep 30 23:33:49 2014 From: matteo.niccoli at gmail.com (Matteo) Date: Tue, 30 Sep 2014 20:33:49 -0700 (PDT) Subject: Problems with coordinate ranges when doing conversion from LCH to LAB to RGB Message-ID: <25d96c44-56dd-4560-82a0-c03093ab4be3@googlegroups.com> A while ago I wrote a post on my blog with code on how to import in Python a colour palette in an ASCII file and convert it to a Matplotlib colormap: mycarta.wordpress.com/2014/04/25/convert-color-palettes-to-python-matplotlib-colormaps/ Following that post I wrote a tutorial on a geoscience magazine on how to evaluate and compare colormaps using Python: wiki.seg.org/wiki/How_to_evaluate_and_compare_color_maps In the accompanying notebook I show how to convert a 256x3 RGB colormap to a 256x256x3 RGB image, then convert it to CIELAB using scikit-image's rgb2lab, then plot the 256x1 lightness (L) array to evaluate the colormaps perceptually. You can read the relevant extract of the notebook using this nbviewer link: http://nbviewer.ipython.org/urls/dl.dropbox.com/s/54zoax2qesb71wn/evaluate_colormaps_skimage_test.ipynb?dl=0 In that case scikit-image worked really well for me. Now I am trying to follow up with a new tutorial and I run into problems with the color space conversions. You can follow what I am trying to do in this other notebook extract: http://nbviewer.ipython.org/urls/dl.dropbox.com/s/noli66nzrlk0676/make_colormap_skimage_test.ipynb?dl=0 The goal of this new tutorial is to show how to build colormaps from scratch using perceptual principles. I design a color palette in LCH (polar version of CIELAB) by keeping Chroma and Lightness fixed and interpolating Hue around the circle, then convert to LAB, then to RGB. As far as I know the code I wrote should work, but the result is a black colormap. I am thinking I got wrong one or more of the ranges for the LCH coordinates. I assumed L between (0,1), Ch between (0,1), and H between (0, 2*pi). Is that wrong, and if that's the case, what are the ranges? Many of them are not stated clearly in the documentation in here: http://scikit-image.org/docs/dev/api/skimage.color.html Is it possible to update the documentation to clearly state all ranges for all colour spaces. Thanks for your help. Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: