Mailman 3 July 2016 - scikit-image

Warping images using control points
by Sid 11 Jul '16

11 Jul '16

Hi I have two images of faces, the source image and the destination image. For each face, I have a set of x and y coordinates stored in two separate numpy arrays. These coordinates correspond to various facial features, as well as the four corners of the image, and points on half the length of the borders. I want to warp the features of the source image onto the destination, such that the corresponding control points in each image are aligned. I used the PiecewiseAffineTransform method, as in the example here <http://scikit-image.org/docs/dev/auto_examples/transform/plot_piecewise_aff…> . My code is: src_pts = # numpy array of coordinates for the source image dst_pts = # numpy array of coordinates for the destination image image = # image of dimensions (550, 420, 3) tform = skimage.transform.PiecewiseAffineTransform() tform.estimate(src_pts, dst_pts) out = skimage.transform.warp(image, tform) I get an image that is warped but also cropped. To see if I could get the code to work (in case there were errors in my control points), I tried warping the image using the same control points for the source and destination. tform.estimate(src_pts, src_pts) The output is still cropped and is also warped slightly, as can be seen in the attached images. Logically, it doesn't make sense as there should not be any warping since I am using the same points. A big difference between the example and my implementation is that the example has uniformly spaced points, whereas I have 76 points which are much more sparse. Is this the right function to achieve what I want or should I be using something else? Thanks -- Sid <https://lh3.googleusercontent.com/-noDhRC6CbkE/V34EvUCZgtI/AAAAAAAACFc/8-Q5…> <https://lh3.googleusercontent.com/-7PTIVXGCCg8/V34E2M6yEUI/AAAAAAAACFg/z2zo…> <https://lh3.googleusercontent.com/-7PTIVXGCCg8/V34E2M6yEUI/AAAAAAAACFg/z2zo…> <https://lh3.googleusercontent.com/-7PTIVXGCCg8/V34E2M6yEUI/AAAAAAAACFg/z2zo…>

2 1

Re: Dropping support for 2.7 in 2020
by Josh Warner 11 Jul '16

11 Jul '16

I think we should support 2.7 through end-of-life. 2020 sounds right. There are a tremendous amount of systems out there still running 2.7. I know more than one lab which standardized on 2.7 years ago, and while we're evaluating the move to 3.x it won't be without major pains. Small, niche packages which work perfectly under 2.7 break in 3.x, and they may or may not be maintained. It only takes a couple of these to render lab equipment with price tags in the 6 figures buggy, problematic, or useless in 3.x. This is problematic when you want a consistent Python experience across a lab or team, but certain pieces just won't work in 3.x. Sounding the trumpets is appropriate, as 2.7 won't be around forever. Quarterly or bi-annually it would be reasonable to send out a reminder. Three years sounds like a long time, but that's about right for this kind of transition. On Monday, July 4, 2016 at 4:55:34 AM UTC-5, Thomas Kluyver wrote: > > On 4 July 2016 at 10:47, François Boulogne <fboulogne(a)sciunto.org> wrote: > >> Does it mean that all new version of those libraries will support >> python2.7 until 2020 or just that you can release a bugfix to already >> released version supporting 2.7? >> >> If it's the first option, it means we can't use python3 features before >> 2020 and we will be "in late" with these features. >> > > The statement doesn't commit projects to support 2.7 until any specific > date - scikit-bio already went Python 3 only with its release last month, > for instance. We're agreeing to end Python 2 support by 2020, but projects > are welcome to do it earlier than that. > > For IPython, we're planning for the 6.0 feature release (some time in > 2017) to be Python 3 only, while we'll make bugfix releases of the 5.x > series for longer than normal to support users on Python 2. >

2 1

Implementing Kadir and Brady's saliency detector in skimage?
by parul sethi 10 Jul '16

10 Jul '16

Hi, I required to use Kadir and Brady's saliency detector for feature extraction process, and didn't found it's python implementation. So, i was in process of implementing the same. Will it be of interest to skimage too? I can use some advice from skimage maintainers to build it with specific suitability for skimage module. Thank you.

2 1

Re: Dropping support for 2.7 in 2020
by Juan Nunez-Iglesias 04 Jul '16

04 Jul '16

I would drop 2.7 sooner. NumPy/SciPy dropping it is the absolute cutoff, but there’s no reason why we can’t jump the gun (and lead rather than follow). Py2.7 users can make do with older releases. As Stéfan mentioned, this is not about erasing Py2.7 support, but not releasing new features on Py2.7. Very different. I envision that we stop producing Py2.7 releases after 0.13, but we call that an “LTS” release which will get bugfix backports until 2020. imho, with Py3.4 and especially Py3.5, Py3-only suddenly became very attractive. My three favourite features are type annotations, keyword-only arguments (these two together make it much easier to produce correct code and debug), and the @ matrix multiplication operator. The latter makes linear algebra code *so* *much* nicer to read and write, and we have our fair share in scikit-image. For my own projects, I am now Py3.5-only, always. Finally, as others have mentioned, but is worth restating: - Conda allows user-space installs of Python versions and packages, so you don’t ever depend on your sysadmin-controlled environment. - It is *absolutely false* that conda packages are only useful on Windows — I have failed to compile scipy both on OSX and Ubuntu boxes. - It is also *not* a requirement to download the monolithic Anaconda distro — with miniconda (which should be the default), you just install precisely what you need. - With conda-forge we now have a community-run repository of binary conda packages. So, in short, the switch to Py3 is easier than ever for *all* users, some might just not realise it yet ;), and switching to a Py3-only programming environment is a boon to all the scikit-image devs… though again some might not realise it yet ;). Juan. On 21 May 2016 at 12:20:38 PM, Nathaniel Smith (njs(a)vorpus.org) wrote: On May 20, 2016 07:30, "Michael Sarahan" <msarahan(a)gmail.com> wrote: > I don't think this is a concern for cython or scikit-image, but many people at bumping into the language support limit in the C++11 sense with Python 2.7 on Windows. Since VS 2008 is the de-facto standard compiler for Python 2.7, people are unable to use C++11 code in modules for Python 2.7. Some people use newer compilers anyway, which sometimes works, but is mixing runtimes, and can lead to bugs or crashes. Many people would like to support Python 2.7 using a different compiler for the whole ecosystem. One example is Ilastik, by folks at HHMI, using VS 2012 to have a custom stack: https://github.com/ilastik/ilastik-build-conda I think getting mingwpy finished and polished is probably an easier solution for this problem than forking the entire py27-on-windows ecosystem :-) -n -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. To post to this group, send email to scikit-image(a)googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAPJVwB%3DjRQtHn9Xj0xwv3hxtD…. For more options, visit https://groups.google.com/d/optout.

3 3

DOI in references?
by François Boulogne 01 Jul '16

01 Jul '16

Hi, I have a question about the references. Is it a choice to do not put DOI pointers when available? For my usage, I have to use a search engine to find papers referenced in our documentation and it would be more simple to add and use the DOI. It's also relatively short, the length is not really a problem. Any comment on this? Thanks. -- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

2 1

Import error when importing from skimage.transform
by sja353＠nyu.edu 01 Jul '16

01 Jul '16

The environment I'm using is a Jupyter notebook running python 3.5. I can import other packages, but importing anything from skimage.transform results in the following error: ImportError Traceback (most recent call last)<ipython-input-19-741b6a154664> in <module>()----> 1 from skimage.transform import resize /home/jupyter/anaconda3/envs/py35/lib/python3.5/site-packages/skimage/transform/__init__.py in <module>()----> 1 from .hough_transform import (hough_line, hough_line_peaks, 2 probabilistic_hough_line, hough_circle, 3 hough_ellipse) 4 from .radon_transform import radon, iradon, iradon_sart 5 from .finite_radon_transform import frt2, ifrt2 /home/jupyter/anaconda3/envs/py35/lib/python3.5/site-packages/skimage/transform/hough_transform.py in <module>() 2 from scipy import ndimage as ndi 3 from .. import measure----> 4 from ._hough_transform import (_hough_circle, 5 hough_ellipse as _hough_ellipse, 6 hough_line as _hough_line, ImportError: cannot import name '_hough_circle' We've already tried uninstalling skimage, updating cython and then re-installing. Anyone else encounter this problem?

3 3