From jjhelmus at gmail.com  Tue Jul  1 11:29:51 2014
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Tue, 01 Jul 2014 10:29:51 -0500
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com> <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com> <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com> <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com> <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com> <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com> <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com> <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com> <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com> <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com> <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
Message-ID: <53B2D3EF.4010805@gmail.com>

On 07/01/2014 09:42 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Jul 1, 2014 at 1:08 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
>> On Tue, Jul 1, 2014 at 2:01 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>>> I've forked the repo to the scikit-image organization and added you to
>>>> the packaging team with the necessary administrative rights.
>>> Oops - sorry - I transferred the repo to scikit-image, but now I don't
>>> have admin rights.
>> I think you should have those back now.
>>
>>> I put in a PR to give the right credentials for travis and rackspace - I hope.
>> Merged.
>>
>>> Could you enable travis testing on that repo also?
>> It looks like it's activated from my side.
> Yup - all working :
> https://travis-ci.org/scikit-image/scikit-image-wheels/builds/28845582
>
>>> By the way - would you consider uploading the latest built wheels to pypi?
>>>
>>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>> Sure, is this the latest wheel 0.10.1 that I pushed out earlier this
>> evening?  I'm off to bed for now, but I've also given you maintainer
>> permission on PyPi so that you don't have to wait on me.
> Thanks - I uploaded the automated builds to pypi (using twine).  Any
> problems - please do let me know.
>
> Cheers,
>
> Matthew
>
Great work Matthew! Thanks for getting the idea integrated 
scikit-image's framework, I was busy this weekend finishing a poster for 
SciPy.  One though I had was to use Travis CI's PyPI deploy [1] to 
upload the wheels directly to pypi.  I tested this out a bit last night 
and the PyPI deploy seems to expect a certain layout of the package, 
Python install, etc which just leads to trouble.  Having the files on 
Rackspace and having to manually push them to pypi for each release 
seems reasonable.

Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has 
able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more 
difficult.

Cheers,

     - Jonathan Helmus

[1] docs.travis-ci.com/user/deployment/pypi/
[2] http://www.appveyor.com/
[3] 
https://ci.appveyor.com/project/JonathanHelmus/scikit-image-ci-wheel-builder/build/1.0.5




From jjhelmus at gmail.com  Tue Jul  1 11:47:29 2014
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Tue, 01 Jul 2014 10:47:29 -0500
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5oiwQQ3EHctP8bMJe1c2+WDw9-mKypps-vOxeh672YGzw@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de> <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com> <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com> <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com> <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com> <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com> <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com> <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com> <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com> <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com> <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com> <53B2D3EF.4010805@gmail.com> <CAH6Pt5oiwQQ3EHctP8bMJe1c2+WDw9-mKypps-vOxeh672YGzw@mail.gmail.com>
Message-ID: <53B2D811.8080906@gmail.com>

On 07/01/2014 10:35 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Jul 1, 2014 at 4:29 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
>> On 07/01/2014 09:42 AM, Matthew Brett wrote:
>>> Hi,
>>>
>>> On Tue, Jul 1, 2014 at 1:08 AM, St?fan van der Walt <stefan at sun.ac.za>
>>> wrote:
>>>> On Tue, Jul 1, 2014 at 2:01 AM, Matthew Brett <matthew.brett at gmail.com>
>>>> wrote:
>>>>>> I've forked the repo to the scikit-image organization and added you to
>>>>>> the packaging team with the necessary administrative rights.
>>>>> Oops - sorry - I transferred the repo to scikit-image, but now I don't
>>>>> have admin rights.
>>>> I think you should have those back now.
>>>>
>>>>> I put in a PR to give the right credentials for travis and rackspace - I
>>>>> hope.
>>>> Merged.
>>>>
>>>>> Could you enable travis testing on that repo also?
>>>> It looks like it's activated from my side.
>>> Yup - all working :
>>> https://travis-ci.org/scikit-image/scikit-image-wheels/builds/28845582
>>>
>>>>> By the way - would you consider uploading the latest built wheels to
>>>>> pypi?
>>>>>
>>>>>
>>>>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>>>> Sure, is this the latest wheel 0.10.1 that I pushed out earlier this
>>>> evening?  I'm off to bed for now, but I've also given you maintainer
>>>> permission on PyPi so that you don't have to wait on me.
>>> Thanks - I uploaded the automated builds to pypi (using twine).  Any
>>> problems - please do let me know.
>>>
>>> Cheers,
>>>
>>> Matthew
>>>
>> Great work Matthew! Thanks for getting the idea integrated scikit-image's
>> framework, I was busy this weekend finishing a poster for SciPy.  One though
>> I had was to use Travis CI's PyPI deploy [1] to upload the wheels directly
>> to pypi.  I tested this out a bit last night and the PyPI deploy seems to
>> expect a certain layout of the package, Python install, etc which just leads
>> to trouble.  Having the files on Rackspace and having to manually push them
>> to pypi for each release seems reasonable.
>>
>> Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has
>> able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more
>> difficult.
> Wow - nice discovery, that looks as though it will be very useful.
>
> Will you run into the same problem with conda, that the wheels aren't
> compatible with Python.org python?
>
> Cheers,
>
> Matthew
>
I'm not sure about the conda issue.  NumPy doesn't provide wheels for 
windows (yet) as they are still trying to figure out what BLAS library 
to include.  If they did, it would be possible to use the pre-installed 
Python on the system which appears to be the official Python.org 
interpreter.  The bigger issue is that only Visual C++ 10.0 is installed 
(VS 2010) which can only build binaries for Python 3.3 and 3.4.  VC++ 
9.0 is needed for Python 2.6 and 2.7 but AppVeyor doesn't provide it and 
installing the SDK seems a bit extreme.  I'm hoping to chat with folks 
at SciPy and see if anyone has any good suggestions for Windows based 
build VMs.

     - Jonathan Helmus


From stefan at sun.ac.za  Tue Jul  1 05:14:43 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Tue, 1 Jul 2014 11:14:43 +0200
Subject: Doctest failures
In-Reply-To: <CA+JHcKSVWQV6D=5aQaABw4VALqTR6PQU7E_TtwMtQgunsBPP=g@mail.gmail.com>
References: <CA+JHcKROeyjVKWeiVT1jwL-Yp4B8iudaQYLrVv0phpZOot6ZMg@mail.gmail.com>
 <d9026c7b-ed98-47db-bda4-398f74fabe0a@googlegroups.com> <CABDkGQnAgnSnay5AcCm4YwPZ4EvW-HEU1Lz93qTaK6hELrSAdw@mail.gmail.com>
 <CA+JHcKSVWQV6D=5aQaABw4VALqTR6PQU7E_TtwMtQgunsBPP=g@mail.gmail.com>
Message-ID: <CABDkGQmAgU-wR8KqV4oDiqhezTBbwa2AC6AyvJELdNTXEXGtvQ@mail.gmail.com>

On Tue, Jul 1, 2014 at 5:34 AM, Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
> I did not, nor do I think I will until post-SciPy. (Or at the sprint itself,
> really.)

No problem--just file it for us somewhere, please.  I will try to help
during the sprints where possible.

Regards
St?fan


From matthew.brett at gmail.com  Tue Jul  1 10:42:17 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 1 Jul 2014 15:42:17 +0100
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com> <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
Message-ID: <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>

Hi,

On Tue, Jul 1, 2014 at 1:08 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> On Tue, Jul 1, 2014 at 2:01 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> I've forked the repo to the scikit-image organization and added you to
>>> the packaging team with the necessary administrative rights.
>>
>> Oops - sorry - I transferred the repo to scikit-image, but now I don't
>> have admin rights.
>
> I think you should have those back now.
>
>> I put in a PR to give the right credentials for travis and rackspace - I hope.
>
> Merged.
>
>> Could you enable travis testing on that repo also?
>
> It looks like it's activated from my side.

Yup - all working :
https://travis-ci.org/scikit-image/scikit-image-wheels/builds/28845582

>> By the way - would you consider uploading the latest built wheels to pypi?
>>
>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>
> Sure, is this the latest wheel 0.10.1 that I pushed out earlier this
> evening?  I'm off to bed for now, but I've also given you maintainer
> permission on PyPi so that you don't have to wait on me.

Thanks - I uploaded the automated builds to pypi (using twine).  Any
problems - please do let me know.

Cheers,

Matthew


From matthew.brett at gmail.com  Tue Jul  1 11:13:32 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 1 Jul 2014 16:13:32 +0100
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com> <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>
Message-ID: <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com>

Yo,

On Tue, Jul 1, 2014 at 4:02 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> On Tue, Jul 1, 2014 at 4:42 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Thanks - I uploaded the automated builds to pypi (using twine).  Any
>> problems - please do let me know.
>
> Neat.  How do we access the built wheels from this system?  Also, does
> twine automate any part of the process, or do you still have to upload
> wheels by hand?

The wheels should appear in this directory:

http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/

after travis has run.  It's obviously possible to automate it more,
but what I did was something like:

cd scikit-image
git co v0.10.1
cd dist
curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp33-cp33m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
cd ..
twine upload dist/*.whl

Is that what you meant?

Cheers,

Matthew


From matthew.brett at gmail.com  Tue Jul  1 11:35:48 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 1 Jul 2014 16:35:48 +0100
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <53B2D3EF.4010805@gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com> <53B2D3EF.4010805@gmail.com>
Message-ID: <CAH6Pt5oiwQQ3EHctP8bMJe1c2+WDw9-mKypps-vOxeh672YGzw@mail.gmail.com>

Hi,

On Tue, Jul 1, 2014 at 4:29 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
> On 07/01/2014 09:42 AM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Tue, Jul 1, 2014 at 1:08 AM, St?fan van der Walt <stefan at sun.ac.za>
>> wrote:
>>>
>>> On Tue, Jul 1, 2014 at 2:01 AM, Matthew Brett <matthew.brett at gmail.com>
>>> wrote:
>>>>>
>>>>> I've forked the repo to the scikit-image organization and added you to
>>>>> the packaging team with the necessary administrative rights.
>>>>
>>>> Oops - sorry - I transferred the repo to scikit-image, but now I don't
>>>> have admin rights.
>>>
>>> I think you should have those back now.
>>>
>>>> I put in a PR to give the right credentials for travis and rackspace - I
>>>> hope.
>>>
>>> Merged.
>>>
>>>> Could you enable travis testing on that repo also?
>>>
>>> It looks like it's activated from my side.
>>
>> Yup - all working :
>> https://travis-ci.org/scikit-image/scikit-image-wheels/builds/28845582
>>
>>>> By the way - would you consider uploading the latest built wheels to
>>>> pypi?
>>>>
>>>>
>>>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>>>
>>> Sure, is this the latest wheel 0.10.1 that I pushed out earlier this
>>> evening?  I'm off to bed for now, but I've also given you maintainer
>>> permission on PyPi so that you don't have to wait on me.
>>
>> Thanks - I uploaded the automated builds to pypi (using twine).  Any
>> problems - please do let me know.
>>
>> Cheers,
>>
>> Matthew
>>
> Great work Matthew! Thanks for getting the idea integrated scikit-image's
> framework, I was busy this weekend finishing a poster for SciPy.  One though
> I had was to use Travis CI's PyPI deploy [1] to upload the wheels directly
> to pypi.  I tested this out a bit last night and the PyPI deploy seems to
> expect a certain layout of the package, Python install, etc which just leads
> to trouble.  Having the files on Rackspace and having to manually push them
> to pypi for each release seems reasonable.
>
> Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has
> able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more
> difficult.

Wow - nice discovery, that looks as though it will be very useful.

Will you run into the same problem with conda, that the wheels aren't
compatible with Python.org python?

Cheers,

Matthew


From matthew.brett at gmail.com  Tue Jul  1 11:56:51 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 1 Jul 2014 16:56:51 +0100
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <53B2D811.8080906@gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <53B2D3EF.4010805@gmail.com> <CAH6Pt5oiwQQ3EHctP8bMJe1c2+WDw9-mKypps-vOxeh672YGzw@mail.gmail.com>
 <53B2D811.8080906@gmail.com>
Message-ID: <CAH6Pt5q48PXuPehkzE8Dbxrpetcuf-rruG3Jzns482Uif9QS4w@mail.gmail.com>

Hi,

On Tue, Jul 1, 2014 at 4:47 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
> On 07/01/2014 10:35 AM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Tue, Jul 1, 2014 at 4:29 PM, Jonathan Helmus <jjhelmus at gmail.com>
>> wrote:
>>>
>>> On 07/01/2014 09:42 AM, Matthew Brett wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Tue, Jul 1, 2014 at 1:08 AM, St?fan van der Walt <stefan at sun.ac.za>
>>>> wrote:
>>>>>
>>>>> On Tue, Jul 1, 2014 at 2:01 AM, Matthew Brett <matthew.brett at gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> I've forked the repo to the scikit-image organization and added you
>>>>>>> to
>>>>>>> the packaging team with the necessary administrative rights.
>>>>>>
>>>>>> Oops - sorry - I transferred the repo to scikit-image, but now I don't
>>>>>> have admin rights.
>>>>>
>>>>> I think you should have those back now.
>>>>>
>>>>>> I put in a PR to give the right credentials for travis and rackspace -
>>>>>> I
>>>>>> hope.
>>>>>
>>>>> Merged.
>>>>>
>>>>>> Could you enable travis testing on that repo also?
>>>>>
>>>>> It looks like it's activated from my side.
>>>>
>>>> Yup - all working :
>>>> https://travis-ci.org/scikit-image/scikit-image-wheels/builds/28845582
>>>>
>>>>>> By the way - would you consider uploading the latest built wheels to
>>>>>> pypi?
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>>>>>
>>>>> Sure, is this the latest wheel 0.10.1 that I pushed out earlier this
>>>>> evening?  I'm off to bed for now, but I've also given you maintainer
>>>>> permission on PyPi so that you don't have to wait on me.
>>>>
>>>> Thanks - I uploaded the automated builds to pypi (using twine).  Any
>>>> problems - please do let me know.
>>>>
>>>> Cheers,
>>>>
>>>> Matthew
>>>>
>>> Great work Matthew! Thanks for getting the idea integrated scikit-image's
>>> framework, I was busy this weekend finishing a poster for SciPy.  One
>>> though
>>> I had was to use Travis CI's PyPI deploy [1] to upload the wheels
>>> directly
>>> to pypi.  I tested this out a bit last night and the PyPI deploy seems to
>>> expect a certain layout of the package, Python install, etc which just
>>> leads
>>> to trouble.  Having the files on Rackspace and having to manually push
>>> them
>>> to pypi for each release seems reasonable.
>>>
>>> Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has
>>> able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more
>>> difficult.
>>
>> Wow - nice discovery, that looks as though it will be very useful.
>>
>> Will you run into the same problem with conda, that the wheels aren't
>> compatible with Python.org python?
>>
>> Cheers,
>>
>> Matthew
>>
> I'm not sure about the conda issue.  NumPy doesn't provide wheels for
> windows (yet) as they are still trying to figure out what BLAS library to
> include.  If they did, it would be possible to use the pre-installed Python
> on the system which appears to be the official Python.org interpreter.  The
> bigger issue is that only Visual C++ 10.0 is installed (VS 2010) which can
> only build binaries for Python 3.3 and 3.4.  VC++ 9.0 is needed for Python
> 2.6 and 2.7 but AppVeyor doesn't provide it and installing the SDK seems a
> bit extreme.  I'm hoping to chat with folks at SciPy and see if anyone has
> any good suggestions for Windows based build VMs.

Yeah - the windows binary problems are really awful:

https://github.com/numpy/numpy/wiki/windows-dll-notes
https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

Carl Kleffner is currently working on a mingw-w64 toolchain that can
compile numpy and scipy with static linking of the c++ mingw-w64
runtime:

https://github.com/numpy/numpy/wiki/Mingw-static-toolchain

I think that would be the way to go for general wheel building.  I've
Cc'ed Carl in case he has any thoughts on that.

Cheers,

Matthew


From stefan at sun.ac.za  Tue Jul  1 11:02:38 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Tue, 1 Jul 2014 17:02:38 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com> <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
Message-ID: <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>

On Tue, Jul 1, 2014 at 4:42 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Thanks - I uploaded the automated builds to pypi (using twine).  Any
> problems - please do let me know.

Neat.  How do we access the built wheels from this system?  Also, does
twine automate any part of the process, or do you still have to upload
wheels by hand?

St?fan


From stefan at sun.ac.za  Tue Jul  1 16:13:03 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Tue, 1 Jul 2014 22:13:03 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <53B2D3EF.4010805@gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com> <53B2D3EF.4010805@gmail.com>
Message-ID: <CABDkGQkpTAR7mo7HS=rBCo+xWmaVamB-VFew+ZLMMjgJkvRt1A@mail.gmail.com>

Hi Jonathan

On Tue, Jul 1, 2014 at 5:29 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
> Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has
> able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more
> difficult.

My attempt just to get a working test suite is here:

https://github.com/stefanv/scikit-image/tree/appveyor

If you have any ideas on how to fix that, I'd be happy to merge the PR
and have official Windows tests.

St?fan


From stefan at sun.ac.za  Tue Jul  1 16:21:11 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Tue, 1 Jul 2014 22:21:11 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com> <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com>
Message-ID: <CABDkGQ=372Yt9fRcUf-=Koa7K1cUpH_QkmYEa2vky7DOmbPnPg@mail.gmail.com>

Hi Matthew

On Tue, Jul 1, 2014 at 5:13 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> The wheels should appear in this directory:
>
> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/

Is there a way to get a friendlier URL for this location?

> cd scikit-image
> git co v0.10.1
> cd dist
> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp33-cp33m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
> cd ..
> twine upload dist/*.whl

A script that automatically does this would make the release manager's
life so much easier.

St?fan


From matthew.brett at gmail.com  Tue Jul  1 18:29:48 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 1 Jul 2014 23:29:48 +0100
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CABDkGQ=372Yt9fRcUf-=Koa7K1cUpH_QkmYEa2vky7DOmbPnPg@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>
 <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com> <CABDkGQ=372Yt9fRcUf-=Koa7K1cUpH_QkmYEa2vky7DOmbPnPg@mail.gmail.com>
Message-ID: <CAH6Pt5rgdHJK8+eb8Jc_TGZwj7+RSxYBTaqT7vXQSvyjCamqww@mail.gmail.com>

Hi,

On Tue, Jul 1, 2014 at 9:21 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Hi Matthew
>
> On Tue, Jul 1, 2014 at 5:13 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> The wheels should appear in this directory:
>>
>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>
> Is there a way to get a friendlier URL for this location?

Do y'all have a cname you can use?

>> cd scikit-image
>> git co v0.10.1
>> cd dist
>> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
>> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp33-cp33m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
>> curl -O http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/scikit_image-0.10.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
>> cd ..
>> twine upload dist/*.whl
>
> A script that automatically does this would make the release manager's
> life so much easier.

Here's a very simple bash script to do that...

https://github.com/scikit-image/scikit-image-wheels/blob/master/check_upload.sh

Cheers,

Matthew


From stefan at sun.ac.za  Tue Jul  1 18:57:43 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Wed, 2 Jul 2014 00:57:43 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5rgdHJK8+eb8Jc_TGZwj7+RSxYBTaqT7vXQSvyjCamqww@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>
 <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com>
 <CABDkGQ=372Yt9fRcUf-=Koa7K1cUpH_QkmYEa2vky7DOmbPnPg@mail.gmail.com> <CAH6Pt5rgdHJK8+eb8Jc_TGZwj7+RSxYBTaqT7vXQSvyjCamqww@mail.gmail.com>
Message-ID: <CABDkGQ=wwpwiLQqw0wVo=knFaPdDrm5f6+ESZ0CLNLVFaz3L4Q@mail.gmail.com>

Hi Matthew

On Wed, Jul 2, 2014 at 12:29 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Do y'all have a cname you can use?

I'll set this up quickly.

> Here's a very simple bash script to do that...
>
> https://github.com/scikit-image/scikit-image-wheels/blob/master/check_upload.sh

Perfect!  How does this look:

https://github.com/scikit-image/scikit-image/pull/1046

St?fan


From stefan at sun.ac.za  Tue Jul  1 19:05:53 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Wed, 2 Jul 2014 01:05:53 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CAH6Pt5rgdHJK8+eb8Jc_TGZwj7+RSxYBTaqT7vXQSvyjCamqww@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <e398fadf-c73f-4320-8b4e-1d46dc4828a1@googlegroups.com> <CABDkGQnMdNRj8EBOBZnawdWJkVy5dgOVPqTd2zOSfQs_9Y96tA@mail.gmail.com>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <CABDkGQ=b3dKQwsNon_SvuYKF36fYUN-EQ6ZVK3+tKrv3qCykHg@mail.gmail.com>
 <CAH6Pt5p3ara_9TZsG1XWx8bEVitH=ebybOc_6jKmTQM=DRzJiA@mail.gmail.com>
 <CABDkGQ=372Yt9fRcUf-=Koa7K1cUpH_QkmYEa2vky7DOmbPnPg@mail.gmail.com> <CAH6Pt5rgdHJK8+eb8Jc_TGZwj7+RSxYBTaqT7vXQSvyjCamqww@mail.gmail.com>
Message-ID: <CABDkGQ=5D3OyPVP3YW65LEijBvp4t3+trB5XkKL44UTjk+6bxA@mail.gmail.com>

On Wed, Jul 2, 2014 at 12:29 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
>>
>> Is there a way to get a friendlier URL for this location?
>
> Do y'all have a cname you can use?

Here we go:

http://wheels.scikit-image.org/


From jjhelmus at gmail.com  Wed Jul  2 08:35:27 2014
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Wed, 02 Jul 2014 07:35:27 -0500
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <CABDkGQkpTAR7mo7HS=rBCo+xWmaVamB-VFew+ZLMMjgJkvRt1A@mail.gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de> <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com> <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com> <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com> <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com> <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com> <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com> <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com> <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com> <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com> <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com> <53B2D3EF.4010805@gmail.com> <CABDkGQkpTAR7mo7HS=rBCo+xWmaVamB-VFew+ZLMMjgJkvRt1A@mail.gmail.com>
Message-ID: <53B3FC8F.5050902@gmail.com>


On 7/1/14, 3:13 PM, St?fan van der Walt wrote:
> Hi Jonathan
>
> On Tue, Jul 1, 2014 at 5:29 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
>> Next up, is to use AppVeyor [2] to build wheel files for Windows.  I has
>> able to get a wheel for Python 3.3 built [3] but Python 2.7 looked more
>> difficult.
> My attempt just to get a working test suite is here:
>
> https://github.com/stefanv/scikit-image/tree/appveyor
>
> If you have any ideas on how to fix that, I'd be happy to merge the PR
> and have official Windows tests.
>
> St?fan
>
I think I should be able to get the test suite running at least for 
Python 3.3/3.4 on AppVeyor.  I'll look into it in detail during the 
sprints at the SciPy conference.

      - Jonathan Helmus


From stefan at sun.ac.za  Wed Jul  2 08:38:55 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Wed, 2 Jul 2014 14:38:55 +0200
Subject: Building skimage wheels for OS X using Travis CI
In-Reply-To: <53B3FC8F.5050902@gmail.com>
References: <A67C4CED-B32A-4252-89E8-AAADC3F64496@demuc.de>
 <26342482-774b-4047-b17f-e8a51d5f0054@googlegroups.com> <CABDkGQky9FbR+y-rp9COWaTAcd7xJSE-fyhP8vkUdTf9U4tduw@mail.gmail.com>
 <00dd3148-a64c-4909-9e8a-e0a6dcc0cd9c@googlegroups.com> <5e1bd660-1f47-4531-8df7-6e9d211ec4eb@googlegroups.com>
 <CABDkGQmQS91JaPA_CuEwop+C4c8h1soMcifcJPLy8Vc3_oxXPQ@mail.gmail.com>
 <53AD800E.10901@gmail.com> <CAH6Pt5pj92h+4OfOFe88X3GGLJFFUYYJqqEe-Etvok56iqEszw@mail.gmail.com>
 <CAH6Pt5o3L3d9_Vj4s__uHbA6Q3dNWLp7t8dBVnhDLeca2UVp2w@mail.gmail.com>
 <CAH6Pt5pseqD2VwS4T1116PgEG3F6hMF6cJhK7Pc8HCLnDAeqBw@mail.gmail.com>
 <CABDkGQmsrq6Oq9Qrkg52ecVW34LTf+RqiFpV6-JW4NDfMYKCNg@mail.gmail.com>
 <CAH6Pt5q5c4+VPQMGZM2zMy4S+bWvjqR1_1RRk02eb6q3+8wmqA@mail.gmail.com>
 <CABDkGQ=EFye1UkjrAS0FdYe5gYhD_PeKPvtJ0nOe27FzRF1ftA@mail.gmail.com>
 <CAH6Pt5orkv1xJDpN558fYCxLFXJWB9+7ZRzc4UUijnThWV3xJw@mail.gmail.com>
 <53B2D3EF.4010805@gmail.com> <CABDkGQkpTAR7mo7HS=rBCo+xWmaVamB-VFew+ZLMMjgJkvRt1A@mail.gmail.com>
 <53B3FC8F.5050902@gmail.com>
Message-ID: <CABDkGQmru+FG+TA=zbxq8kYcf1eysbkcRdkB__Ki2oMaMM4JHA@mail.gmail.com>

On Wed, Jul 2, 2014 at 2:35 PM, Jonathan Helmus <jjhelmus at gmail.com> wrote:
> I think I should be able to get the test suite running at least for Python
> 3.3/3.4 on AppVeyor.  I'll look into it in detail during the sprints at the
> SciPy conference.

Thanks, that'd be a big step forward.  Feel free to ping me at any
time, should you need some extra hands.

St?fan


From jni.soma at gmail.com  Thu Jul  3 14:03:54 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Fri, 4 Jul 2014 04:03:54 +1000
Subject: Doctest failures
In-Reply-To: <CABDkGQmAgU-wR8KqV4oDiqhezTBbwa2AC6AyvJELdNTXEXGtvQ@mail.gmail.com>
References: <CA+JHcKROeyjVKWeiVT1jwL-Yp4B8iudaQYLrVv0phpZOot6ZMg@mail.gmail.com>
 <d9026c7b-ed98-47db-bda4-398f74fabe0a@googlegroups.com> <CABDkGQnAgnSnay5AcCm4YwPZ4EvW-HEU1Lz93qTaK6hELrSAdw@mail.gmail.com>
 <CA+JHcKSVWQV6D=5aQaABw4VALqTR6PQU7E_TtwMtQgunsBPP=g@mail.gmail.com> <CABDkGQmAgU-wR8KqV4oDiqhezTBbwa2AC6AyvJELdNTXEXGtvQ@mail.gmail.com>
Message-ID: <CA+JHcKTw5W87M9uUACSi_Qk42P9F0GDxOLETMh42yca-VPBcoA@mail.gmail.com>

Done: https://github.com/scikit-image/scikit-image/issues/1048


On Tue, Jul 1, 2014 at 7:14 PM, St?fan van der Walt <stefan at sun.ac.za>
wrote:

> On Tue, Jul 1, 2014 at 5:34 AM, Juan Nunez-Iglesias <jni.soma at gmail.com>
> wrote:
> > I did not, nor do I think I will until post-SciPy. (Or at the sprint
> itself,
> > really.)
>
> No problem--just file it for us somewhere, please.  I will try to help
> during the sprints where possible.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140704/e9ad427e/attachment.html>

From njs at pobox.com  Fri Jul  4 17:15:01 2014
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 4 Jul 2014 22:15:01 +0100
Subject: [Numpy-discussion] Questions about fixes for 1.9.0rc2
In-Reply-To: <CAB6mnxK6Y8dVU_3Yu=YQCvtK6gSXNZ_H-XuqH1BqtmXNw6_uQg@mail.gmail.com>
References: <CAB6mnxK+bEN4ToMk0O_LUWbHjB7s2eAO+XAY9YxpJ45D4ZYsaQ@mail.gmail.com>
	<CAB6mnxJ=Pjj8sFh0KqssCUNKESQQqgNUP-OYpfP6nGCtk1WL4A@mail.gmail.com>
	<CABL7CQjQxOVWFSFG3nf9s9pQop05NK2+6X7XHaEFjF3HH8xbUQ@mail.gmail.com>
	<CAPJVwB=WcTd2O+gr1GAcgW+F2=S=5bH6hd9_9xHjhCjmt4XnkA@mail.gmail.com>
	<CAB6mnxJvEPCKm8cRaWXHKaGJwFM2_3j+-E9QdQ-gAQZ8kkLe8g@mail.gmail.com>
	<CAPJVwBmd0iuPe6MfJTfJEbEEKV8SimKLDZN5zejO_8VRePtLtA@mail.gmail.com>
	<CAB6mnxK6Y8dVU_3Yu=YQCvtK6gSXNZ_H-XuqH1BqtmXNw6_uQg@mail.gmail.com>
Message-ID: <CAPJVwBnneoJhOqcD87wU2_-pzphObfubPovrGEG8N7K-1_4FPA@mail.gmail.com>

On Fri, Jul 4, 2014 at 9:48 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
> On Fri, Jul 4, 2014 at 2:41 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Fri, Jul 4, 2014 at 9:33 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> > On Fri, Jul 4, 2014 at 2:09 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> >>
>> >> On Fri, Jul 4, 2014 at 9:02 PM, Ralf Gommers <ralf.gommers at gmail.com>
>> >> wrote:
>> >> >
>> >> > On Fri, Jul 4, 2014 at 10:00 PM, Charles R Harris
>> >> > <charlesr.harris at gmail.com> wrote:
>> >> >>
>> >> >> On Fri, Jul 4, 2014 at 1:42 PM, Charles R Harris
>> >> >> <charlesr.harris at gmail.com> wrote:
>> >> >>>
>> >> >>> Sebastian Seberg has fixed one class of test failures due to the
>> >> >>> indexing
>> >> >>> changes in numpy 1.9.0b1.  There are some remaining errors, and in
>> >> >>> the
>> >> >>> case
>> >> >>> of the Matplotlib failures, they look to me to be Matplotlib bugs.
>> >> >>> The
>> >> >>> 2-d
>> >> >>> arrays that cause the error are returned by the overloaded
>> >> >>> _interpolate_single_key function in CubicTriInterpolator that is
>> >> >>> documented
>> >> >>> in the base class to return a 1-d array, whereas the actual
>> >> >>> dimensions
>> >> >>> are
>> >> >>> of the form (n, 1). The question is, what is the best work around
>> >> >>> here
>> >> >>> for
>> >> >>> these sorts errors? Can we afford to break Matplotlib and other
>> >> >>> packages on
>> >> >>> account of a bug that was previously accepted by Numpy?
>> >> >
>> >> >
>> >> > It depends how bad the break is, but in principle I'd say that
>> >> > breaking
>> >> > Matplotlib is not OK.
>> >>
>> >> I agree. If it's easy to hack around it and issue a warning for now,
>> >> and doesn't have other negative consequences, then IMO we should give
>> >> matplotlib a release or so worth of grace period to fix things.
>> >
>> >
>> > Here is another example, from skimage.
>> >
>> > ======================================================================
>> > ERROR: test_join.test_relabel_sequential_offset1
>> > ----------------------------------------------------------------------
>> > Traceback (most recent call last):
>> >   File "X:\Python27-x64\lib\site-packages\nose\case.py", line 197, in
>> > runTest
>> >     self.test(*self.arg)
>> >   File
>> >
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\tests\test_join.py",
>> > line 30, in test_relabel_sequential_offset1
>> >     ar_relab, fw, inv = relabel_sequential(ar)
>> >   File
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\_join.py",
>> > line 127, in relabel_sequential
>> >     forward_map[labels0] = np.arange(offset, offset + len(labels0) + 1)
>> > ValueError: shape mismatch: value array of shape (6,) could not be
>> > broadcast
>> > to indexing result of shape (5,)
>> >
>> > Which is pretty clearly a coding error. Unfortunately, the error is in
>> > the
>> > package rather than the test.
>> >
>> > The only easy way to fix all of these sorts of things is to revert the
>> > indexing changes, and I'm loathe to do that. Grrr...
>>
>> Ugh, that's pretty bad :-/. Do you really think we can't use a
>> band-aid over the new indexing code, though?
>
>
> Yeah, we can. But Sebastian doesn't have time and I'm unfamiliar with the
> code, so it may take a while...

Fair enough!

I guess that if what are (arguably) bugs in matplotlib and
scikit-image are holding up the numpy release, then it's worth CC'ing
their mailing lists in case someone feels like volunteering to fix
it... ;-).

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org


From tsyu80 at gmail.com  Wed Jul  9 23:59:52 2014
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 9 Jul 2014 22:59:52 -0500
Subject: SciPy 2014 Tutorial and Sprints
Message-ID: <CAEym_HrTVhGyf6JkupYoE7OWSV_Ls1mJvmZBUa_UBPpTPLLxUg@mail.gmail.com>

Juan and I put together a tutorial for SciPy 2014. If anyone has 4 hours to
kill, here's a link to the first video, which should link to the other 3
videos in the sidebar

http://www.youtube.com/watch?v=MP-MTiCETYg&list=PLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog&feature=share&index=27

The accompanying notebooks are here:

https://github.com/scikit-image/skimage-tutorials/tree/master/scipy-2014


Also, Juan and I are planning to hold a sprint on Friday. I know Steven
Sylvester and Thomas Caswell frequent this list (and are currently here for
the conference), so this is me putting you on the spot to get you to join
us for the sprint. Anyone else that reads this list should join in as well.

I put together a list of possible sprint items on the wiki. Juan: I wrote
down what I remembered from our discussion; make sure you give it a look
over to make sure I didn't forget anything we talked about. Everyone: If
you have any ideas, now is the time to throw it out there:

https://github.com/scikit-image/scikit-image/wiki/SciPy-2014-sprint-ideas

By the way, a couple of the suggestions I wrote down might be
controversial, specifically, these two:


   - Move and deprecate functions
      - canny from filter to feature
      - threshold_* from filter to exposure


Thoughts?

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140709/3d66f9d3/attachment.html>

From jni.soma at gmail.com  Thu Jul 10 03:02:58 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Thu, 10 Jul 2014 02:02:58 -0500
Subject: SciPy 2014 Tutorial and Sprints
In-Reply-To: <CAEym_HrTVhGyf6JkupYoE7OWSV_Ls1mJvmZBUa_UBPpTPLLxUg@mail.gmail.com>
References: <CAEym_HrTVhGyf6JkupYoE7OWSV_Ls1mJvmZBUa_UBPpTPLLxUg@mail.gmail.com>
Message-ID: <CA+JHcKR4_=-+-fJ1rmdrVzw3RWefsM6zbSh49fe4jvf8vqZ4Ww@mail.gmail.com>

Hi all!

I've added a few items to Tony's list:

=======

Add default structuring elements to morphology operations, and fall back on
scipy.ndimage when parameters don't fit our optimized functions based on
rank filters (2D images, bitdepth<12).

Distribute tifffile.py with scikit-image and make it the default for TIFF
files

Other IO improvements, such as reordering plugin preferences, issuing
warnings when certain plugins are used that rescale the image to float, etc.

Improve 3D support (a few attendees requested this and expressed interest
in helping with that)

=======

Additionally, as I mentioned at the end of my talk and to all who would
listen, I have no interest in locking myself in a basement for 8h while
it's a nice day out. (You might recall that I was just as adamant 2 years
ago, but back then I wasn't leading. =P) As such, I propose holding the
skimage in one of:

201 (an official sprinting room) *only* if the shades are opened
the tables outside of the Tejas dining room
Gabriel's bar, either inside or outside.

The last one is my preferred choice since we can also enjoy drinks while
sprinting!

Finally, depending on how things go, we may only sprint on skimage on
Friday so that we can mingle with the other teams on Saturday. But we'll
play this by ear.

Juan.

PS: Regarding the tutorials, I have been busy with my own talk and didn't
have a chance to upload my solutions. Will do those now.

PPS: I am also hereby proposing #skimage as the official hashtag of the
scikit-image library. =)


On Wed, Jul 9, 2014 at 10:59 PM, Tony Yu <tsyu80 at gmail.com> wrote:

> Juan and I put together a tutorial for SciPy 2014. If anyone has 4 hours
> to kill, here's a link to the first video, which should link to the other 3
> videos in the sidebar
>
>
> http://www.youtube.com/watch?v=MP-MTiCETYg&list=PLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog&feature=share&index=27
>
> The accompanying notebooks are here:
>
> https://github.com/scikit-image/skimage-tutorials/tree/master/scipy-2014
>
>
> Also, Juan and I are planning to hold a sprint on Friday. I know Steven
> Sylvester and Thomas Caswell frequent this list (and are currently here for
> the conference), so this is me putting you on the spot to get you to join
> us for the sprint. Anyone else that reads this list should join in as well.
>
> I put together a list of possible sprint items on the wiki. Juan: I wrote
> down what I remembered from our discussion; make sure you give it a look
> over to make sure I didn't forget anything we talked about. Everyone: If
> you have any ideas, now is the time to throw it out there:
>
> https://github.com/scikit-image/scikit-image/wiki/SciPy-2014-sprint-ideas
>
> By the way, a couple of the suggestions I wrote down might be
> controversial, specifically, these two:
>
>
>    - Move and deprecate functions
>       - canny from filter to feature
>       - threshold_* from filter to exposure
>
>
> Thoughts?
>
> -Tony
>
> --
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140710/60d9517a/attachment.html>

From jni.soma at gmail.com  Fri Jul 11 11:32:23 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Fri, 11 Jul 2014 10:32:23 -0500
Subject: Make Pillow a requirement
Message-ID: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>

@jjhelmus and I are having a discussion regarding IO and how tests fail if
you don't have any of Pillow, PyQt, freeimage, etc, none of which are
actually a requirement. As one of the sprint topics is fixing up IO, this
would be a great thing to fix.

Cheap solution: make Pillow a requirement.

Expensive solution: write/pilfer our own  IO modules, however inefficient
they may be. (e.g. tifffile.py for tifs, maybe similar PNG)

I don't see any *other* solution. Making mpl a requirement is not useful
since their IO is also broken (e.g. images convert to float by default).

Juan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140711/8c1c1868/attachment.html>

From jni.soma at gmail.com  Fri Jul 11 11:38:01 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Fri, 11 Jul 2014 10:38:01 -0500
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
Message-ID: <CA+JHcKRVjJDfG2XYV6dqB9k_POmdNA5uxbASsfaotvwbPuG4XQ@mail.gmail.com>

In a related note, we just found that Travis *installs FreeImage and Pillow
for ALL tests*!!! This is completely ludicrous given that these are not
requirements!!!


On Fri, Jul 11, 2014 at 10:32 AM, Juan Nunez-Iglesias <jni.soma at gmail.com>
wrote:

> @jjhelmus and I are having a discussion regarding IO and how tests fail if
> you don't have any of Pillow, PyQt, freeimage, etc, none of which are
> actually a requirement. As one of the sprint topics is fixing up IO, this
> would be a great thing to fix.
>
> Cheap solution: make Pillow a requirement.
>
> Expensive solution: write/pilfer our own  IO modules, however inefficient
> they may be. (e.g. tifffile.py for tifs, maybe similar PNG)
>
> I don't see any *other* solution. Making mpl a requirement is not useful
> since their IO is also broken (e.g. images convert to float by default).
>
> Juan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140711/677258a4/attachment.html>

From jjhelmus at gmail.com  Fri Jul 11 12:28:50 2014
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Fri, 11 Jul 2014 11:28:50 -0500
Subject: Make Pillow a requirement
In-Reply-To: <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com> <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
Message-ID: <53C010C2.2020007@gmail.com>


On 7/11/14, 10:44 AM, St?fan van der Walt wrote:
> Hi Juan
>
> On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
>> Cheap solution: make Pillow a requirement.
> My suggestion last time was to make 'imread' a requirement--what do you think?
>
> St?fan
>

 From my experience, imread is not as widely available as PIL and 
pillow.  PIL and pillow are both provided in the Anaconda repositories 
but imread is not.  I set up a test environment on OS X and Windows with 
the current master and tried running the skimage unit tests with the 
required dependencies as well as with pillow and PIL, results are:

Only Required Dependencies: 2 Errors (Win); 2 Errors/2 Fails (OS X)
"" + pillow: 106 Errors, 4 Fails (Win); 1 Error (OS X)
"" + PIL: tests pass (Win); 1 Error (OS X).

All packages were from Anaconda's repo, 32 bit Windows, OS X 10.9.

     - Jonathan Helmus



From jni.soma at gmail.com  Fri Jul 11 12:31:18 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Fri, 11 Jul 2014 11:31:18 -0500
Subject: Make Pillow a requirement
In-Reply-To: <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
 <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
Message-ID: <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com>

Hey Stefan,

Pillow is in conda, imread is not. My experimentation over the last 15
minutes suggests that it will be much more of a challenge to install imread
than pillow. (I'm also not sure whether imread supports Python 3 and that's
why things are failing.)

I also just saw @jjhelmus's email so maybe PIL should throw its hat into
the ring...


On Fri, Jul 11, 2014 at 10:44 AM, St?fan van der Walt <stefan at sun.ac.za>
wrote:

> Hi Juan
>
> On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni.soma at gmail.com>
> wrote:
> > Cheap solution: make Pillow a requirement.
>
> My suggestion last time was to make 'imread' a requirement--what do you
> think?
>
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140711/93ccae3b/attachment.html>

From fboulogne at sciunto.org  Fri Jul 11 11:41:03 2014
From: fboulogne at sciunto.org (=?ISO-8859-1?Q?Fran=E7ois_Boulogne?=)
Date: Fri, 11 Jul 2014 11:41:03 -0400
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
Message-ID: <53C0058F.4000001@sciunto.org>

Le 11/07/2014 11:32, Juan Nunez-Iglesias a ?crit :
> @jjhelmus and I are having a discussion regarding IO and how tests
> fail if you don't have any of Pillow, PyQt, freeimage, etc, none of
> which are actually a requirement. As one of the sprint topics is
> fixing up IO, this would be a great thing to fix.
>
> Cheap solution: make Pillow a requirement.
>
>

I remember I submitted a PR (accepted) to add Pillow in DEPENDS.txt. But
it's not un requierements.txt...

I follow the Pillow project, and I believe it's definitely the solution
to invest in. :)

Best,

-- 
Fran?ois Boulogne.
http://www.sciunto.org
GPG: 32D5F22F



From stefan at sun.ac.za  Fri Jul 11 11:44:39 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Fri, 11 Jul 2014 17:44:39 +0200
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
Message-ID: <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>

Hi Juan

On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
> Cheap solution: make Pillow a requirement.

My suggestion last time was to make 'imread' a requirement--what do you think?

St?fan


From stefan at sun.ac.za  Fri Jul 11 17:47:03 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Fri, 11 Jul 2014 23:47:03 +0200
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
 <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com> <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com>
Message-ID: <CABDkGQkiP6Lsmd1Ud2xXUX4JN9K+O=Q=wQWnGgbzk3qGawEaug@mail.gmail.com>

I imagine it would take only one email to Illan Schnell to get it included.


From jim at rybarski.com  Sat Jul 12 16:11:09 2014
From: jim at rybarski.com (jim at rybarski.com)
Date: Sat, 12 Jul 2014 13:11:09 -0700 (PDT)
Subject: Potential contribution: subpixel cross correlation
In-Reply-To: <CABDkGQmZArfBxiGV3XNuAFfC2vssF23_emEXugXM6czfRdLhgA@mail.gmail.com>
References: <ef1461b6-aced-44d9-8d25-e2c195d389bf@googlegroups.com>
 <CABDkGQn0t+Jo2nuDPLB2FUa5RpKH=vtBOtxP9owQ3Oqn90GFSA@mail.gmail.com>
 <CAB9hrOoqwE3ZZo2fZ0hNC9y0+9yTMKag5YmogMmnZejNLrJggQ@mail.gmail.com>
 <CABDkGQn=Tfq-VVDm9X27GxjFaUEsJkxQcyox6yH--zV47CcBvg@mail.gmail.com>
 <CAB9hrOq-5YegcCnRi+vz4uXXeq824QTJMfHY4nK63dhoty4z9g@mail.gmail.com>
 <CABDkGQno3DAR4iFYKOkSSU+HU+EEV-nTZ-0DpNfnEQyJeoVkyQ@mail.gmail.com>
 <CA+JHcKSnMeyvdiXNugZRbKyubNYyWE98Yd6VFxfJnVzca6YFpA@mail.gmail.com>
 <CAB9hrOpaU2jsi6pc+xv+HNUihPbdA69c4QwdxjhE_s5oWJzo1A@mail.gmail.com>
 <CABDkGQnHrm3NxY+7g-JES55b6eftZHfB=wm1Tei=Fv7cGt4C7g@mail.gmail.com> <CAB9hrOqOBgZU5X=RcO2LHryHZND5o-r80Xo-EfjtesDgCF0t3A@mail.gmail.com>
 <CABDkGQmZArfBxiGV3XNuAFfC2vssF23_emEXugXM6czfRdLhgA@mail.gmail.com>
Message-ID: <eff61c10-8179-4ea4-95b8-360f7ba9bfe7@googlegroups.com>

Where are things at with this? The method works incredibly well and my 
current project is pretty much impossible without it.

On Tuesday, May 13, 2014 1:16:02 AM UTC-5, Stefan van der Walt wrote:
>
> Hi Michael 
>
> On Tue, May 13, 2014 at 6:02 AM, Michael Sarahan <msar... at gmail.com 
> <javascript:>> wrote: 
> > I wrote to Prof. Fienup last Tuesday, but haven't heard back.  The work 
> is 
> > published, and to the best of my knowledge unpatented (Google patent 
> search 
> > turns up nothing.)  Let me know if you'd still be up for a PR. 
>
> I would prefer to get Prof. Fienup's approval of the work.  However, 
> if that cannot be obtained we can still publish code if we can show 
> that it was derived purely from the published information (not from 
> the "tainted" code the current version is based on). 
>
> Regards 
> St?fan 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140712/6f0764a9/attachment.html>

From jim at rybarski.com  Sat Jul 12 18:53:07 2014
From: jim at rybarski.com (jim at rybarski.com)
Date: Sat, 12 Jul 2014 15:53:07 -0700 (PDT)
Subject: Potential contribution: subpixel cross correlation
In-Reply-To: <CABDkGQk6UhyHgaPK-ica+=_F1smow=eXVWTn_O8mggfUqbZR4Q@mail.gmail.com>
References: <ef1461b6-aced-44d9-8d25-e2c195d389bf@googlegroups.com>
 <CABDkGQn0t+Jo2nuDPLB2FUa5RpKH=vtBOtxP9owQ3Oqn90GFSA@mail.gmail.com>
 <CAB9hrOoqwE3ZZo2fZ0hNC9y0+9yTMKag5YmogMmnZejNLrJggQ@mail.gmail.com>
 <CABDkGQn=Tfq-VVDm9X27GxjFaUEsJkxQcyox6yH--zV47CcBvg@mail.gmail.com>
 <CAB9hrOq-5YegcCnRi+vz4uXXeq824QTJMfHY4nK63dhoty4z9g@mail.gmail.com>
 <CABDkGQno3DAR4iFYKOkSSU+HU+EEV-nTZ-0DpNfnEQyJeoVkyQ@mail.gmail.com>
 <CA+JHcKSnMeyvdiXNugZRbKyubNYyWE98Yd6VFxfJnVzca6YFpA@mail.gmail.com>
 <CAB9hrOpaU2jsi6pc+xv+HNUihPbdA69c4QwdxjhE_s5oWJzo1A@mail.gmail.com>
 <CABDkGQnHrm3NxY+7g-JES55b6eftZHfB=wm1Tei=Fv7cGt4C7g@mail.gmail.com>
 <CAB9hrOqOBgZU5X=RcO2LHryHZND5o-r80Xo-EfjtesDgCF0t3A@mail.gmail.com>
 <CABDkGQmZArfBxiGV3XNuAFfC2vssF23_emEXugXM6czfRdLhgA@mail.gmail.com> <eff61c10-8179-4ea4-95b8-360f7ba9bfe7@googlegroups.com>
 <CABDkGQk6UhyHgaPK-ica+=_F1smow=eXVWTn_O8mggfUqbZR4Q@mail.gmail.com>
Message-ID: <2fc0b6f8-3c73-4c4f-99e8-06c89c7fa1ab@googlegroups.com>

His contact info is all 
here: http://www.optics.rochester.edu/workgroups/fienup/Professor.htm

On Saturday, July 12, 2014 3:55:37 PM UTC-5, Stefan van der Walt wrote:
>
> On Sat, Jul 12, 2014 at 10:11 PM,  <j... at rybarski.com <javascript:>> 
> wrote: 
> > Where are things at with this? The method works incredibly well and my 
> > current project is pretty much impossible without it. 
>
> If anyone can provide me the original author's contact information, 
> I'd be happy to contact him and ask permission.  I'll be traveling for 
> a few days, so I may not be able to respond immediately. 
>
> Regards 
> St?fan 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140712/5011771b/attachment.html>

From stefan at sun.ac.za  Sat Jul 12 16:55:15 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Sat, 12 Jul 2014 22:55:15 +0200
Subject: Potential contribution: subpixel cross correlation
In-Reply-To: <eff61c10-8179-4ea4-95b8-360f7ba9bfe7@googlegroups.com>
References: <ef1461b6-aced-44d9-8d25-e2c195d389bf@googlegroups.com>
 <CABDkGQn0t+Jo2nuDPLB2FUa5RpKH=vtBOtxP9owQ3Oqn90GFSA@mail.gmail.com>
 <CAB9hrOoqwE3ZZo2fZ0hNC9y0+9yTMKag5YmogMmnZejNLrJggQ@mail.gmail.com>
 <CABDkGQn=Tfq-VVDm9X27GxjFaUEsJkxQcyox6yH--zV47CcBvg@mail.gmail.com>
 <CAB9hrOq-5YegcCnRi+vz4uXXeq824QTJMfHY4nK63dhoty4z9g@mail.gmail.com>
 <CABDkGQno3DAR4iFYKOkSSU+HU+EEV-nTZ-0DpNfnEQyJeoVkyQ@mail.gmail.com>
 <CA+JHcKSnMeyvdiXNugZRbKyubNYyWE98Yd6VFxfJnVzca6YFpA@mail.gmail.com>
 <CAB9hrOpaU2jsi6pc+xv+HNUihPbdA69c4QwdxjhE_s5oWJzo1A@mail.gmail.com>
 <CABDkGQnHrm3NxY+7g-JES55b6eftZHfB=wm1Tei=Fv7cGt4C7g@mail.gmail.com>
 <CAB9hrOqOBgZU5X=RcO2LHryHZND5o-r80Xo-EfjtesDgCF0t3A@mail.gmail.com>
 <CABDkGQmZArfBxiGV3XNuAFfC2vssF23_emEXugXM6czfRdLhgA@mail.gmail.com> <eff61c10-8179-4ea4-95b8-360f7ba9bfe7@googlegroups.com>
Message-ID: <CABDkGQk6UhyHgaPK-ica+=_F1smow=eXVWTn_O8mggfUqbZR4Q@mail.gmail.com>

On Sat, Jul 12, 2014 at 10:11 PM,  <jim at rybarski.com> wrote:
> Where are things at with this? The method works incredibly well and my
> current project is pretty much impossible without it.

If anyone can provide me the original author's contact information,
I'd be happy to contact him and ask permission.  I'll be traveling for
a few days, so I may not be able to respond immediately.

Regards
St?fan


From eduardoarnoldh at gmail.com  Tue Jul 15 07:28:21 2014
From: eduardoarnoldh at gmail.com (Eduardo Henrique Arnold)
Date: Tue, 15 Jul 2014 04:28:21 -0700 (PDT)
Subject: Non-linear distance based filter
Message-ID: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>

Hi there.

I need to implement a filter that takes each white pixel in a binary image 
and look for the distance between the top and bottom closest 
background (black) pixels. If this distance is smaller than a threshold T 
all the pixels between this two background pixels should be set to 0 
(background pixels).

I know I could iterate through all the image columns and pixels, but I 
think this would yield a poor performance. Is there any suggestion of how I 
could develop this filter in a more efficient way?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140715/a4419f11/attachment.html>

From silvertrumpet999 at gmail.com  Tue Jul 15 08:03:03 2014
From: silvertrumpet999 at gmail.com (Josh Warner)
Date: Tue, 15 Jul 2014 05:03:03 -0700 (PDT)
Subject: Non-linear distance based filter
In-Reply-To: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
References: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
Message-ID: <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com>



Hi Eduardo,

What you are looking for is called a *distance transform*. We have one 
function (skimage.morphology.medial_axis) which can be coerced into 
returning a distance transform with an optional argument, but I recommend 
you look to SciPy?s NDImage module (scipy.ndimage) for a more general set 
of transforms. We haven?t reimplemented these since we depend on SciPy.

Specifically, for your purposes, you will likely want to use 
scipy.ndimage.distance_transform_edt and then either mask or threshold the 
result.

import scipy.ndimage as ndi
# Load your data here as `image`

dist = ndi.distance_transform_edt(image)
dist[dist < T] = 0  # Could also operate on the original image with image[dist < T] = something
# Optional, uncomment if you want a binary result# dist[dist >= T] = 1

Hope that helps,
Josh

On Tuesday, July 15, 2014 6:28:21 AM UTC-5, Eduardo Henrique Arnold wrote:

Hi there.
>
> I need to implement a filter that takes each white pixel in a binary image 
> and look for the distance between the top and bottom closest 
> background (black) pixels. If this distance is smaller than a threshold T 
> all the pixels between this two background pixels should be set to 0 
> (background pixels).
>
> I know I could iterate through all the image columns and pixels, but I 
> think this would yield a poor performance. Is there any suggestion of how I 
> could develop this filter in a more efficient way?
>
> Thanks.
>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140715/0373d98d/attachment.html>

From eduardoarnoldh at gmail.com  Tue Jul 15 10:56:29 2014
From: eduardoarnoldh at gmail.com (Eduardo Henrique Arnold)
Date: Tue, 15 Jul 2014 07:56:29 -0700 (PDT)
Subject: Non-linear distance based filter
In-Reply-To: <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com>
References: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
 <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com>
Message-ID: <762a46ef-7aea-4cfe-b766-b736da95736b@googlegroups.com>

Hi Josh, 

I appreciate your reply, it was very helpful. Looking at the Scipy docs 
<http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.morphology.distance_transform_edt.html#scipy.ndimage.morphology.distance_transform_edt>, 
I've realized I could use the *sampling* argument to get only vertical 
distances. However this does not seem to work, it shows me an empty matrix 
no matter what. If I invert the order of the sampling list, [1,0], it shows 
me some line strips, but not the result I was expecting. I cannot figure 
out what is wrong or if this method is not supposed be used like this.

from scipy.ndimage.morphology import distance_transform_edt as distTransform

distMatrix = distTransform(imgBin, sampling=[0,1])


BTW, did you format your code in the last post manually? I could not find a 
way of doing it here. 

Thanks again!

On Tuesday, July 15, 2014 1:03:04 PM UTC+1, Josh Warner wrote:
>
> Hi Eduardo,
>
> What you are looking for is called a *distance transform*. We have one 
> function (skimage.morphology.medial_axis) which can be coerced into 
> returning a distance transform with an optional argument, but I recommend 
> you look to SciPy?s NDImage module (scipy.ndimage) for a more general set 
> of transforms. We haven?t reimplemented these since we depend on SciPy.
>
> Specifically, for your purposes, you will likely want to use 
> scipy.ndimage.distance_transform_edt and then either mask or threshold 
> the result.
>
> import scipy.ndimage as ndi
> # Load your data here as `image`
>
> dist = ndi.distance_transform_edt(image)
> dist[dist < T] = 0  # Could also operate on the original image with image[dist < T] = something
> # Optional, uncomment if you want a binary result# dist[dist >= T] = 1
>
> Hope that helps,
> Josh
>
> On Tuesday, July 15, 2014 6:28:21 AM UTC-5, Eduardo Henrique Arnold wrote:
>
> Hi there.
>>
>> I need to implement a filter that takes each white pixel in a binary 
>> image and look for the distance between the top and bottom closest 
>> background (black) pixels. If this distance is smaller than a threshold T 
>> all the pixels between this two background pixels should be set to 0 
>> (background pixels).
>>
>> I know I could iterate through all the image columns and pixels, but I 
>> think this would yield a poor performance. Is there any suggestion of how I 
>> could develop this filter in a more efficient way?
>>
>> Thanks.
>>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140715/66b42757/attachment.html>

From silvertrumpet999 at gmail.com  Tue Jul 15 12:13:49 2014
From: silvertrumpet999 at gmail.com (Josh Warner)
Date: Tue, 15 Jul 2014 09:13:49 -0700 (PDT)
Subject: Non-linear distance based filter
In-Reply-To: <762a46ef-7aea-4cfe-b766-b736da95736b@googlegroups.com>
References: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
 <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com>
 <762a46ef-7aea-4cfe-b766-b736da95736b@googlegroups.com>
Message-ID: <51b3ad2e-1900-4cf9-9c5f-4645ce4b5dd9@googlegroups.com>



I don?t believe sampling works like this. The sampling= kwarg tells the 
algorithm the spacing of each pixel/voxel in each spatial dimension. It 
then calculates the distance transform. So if you put a zero in, it will 
traverse in that dimension with a distance cost of zero for each step. This 
will generate a result that has mostly spurious zero distances, rather than 
select a particular axis to calculate the distance transform along.

To calculate the correct distance function along a specific axis probably 
requires repeated calls along that axis; since scipy.ndimage is by 
definition n-dimensional it should be able to efficiently handle rank-1 
arrays without issue.

I use the super handy Chrome extension ?Markdown Here? to write in Markdown 
and then have my free entry fields converted to pretty HTML prior to 
posting. At this point I pretty much think in Markdown?

Josh

?
>>
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140715/0979d913/attachment.html>

From jni.soma at gmail.com  Tue Jul 15 20:16:12 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Tue, 15 Jul 2014 19:16:12 -0500
Subject: Non-linear distance based filter
In-Reply-To: <51b3ad2e-1900-4cf9-9c5f-4645ce4b5dd9@googlegroups.com>
References: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
 <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com> <762a46ef-7aea-4cfe-b766-b736da95736b@googlegroups.com>
 <51b3ad2e-1900-4cf9-9c5f-4645ce4b5dd9@googlegroups.com>
Message-ID: <CA+JHcKQBqeB-UaWb9As-Z1PMo3hy70TNFg7omUTzQrHJMjXP7A@mail.gmail.com>

@JDWarner, actually, instead of iterating, setting one of the sampling
dimensions to a very large number should produce the desired output, no? =)


On Tue, Jul 15, 2014 at 11:13 AM, Josh Warner <silvertrumpet999 at gmail.com>
wrote:

> I don't believe sampling works like this. The sampling= kwarg tells the
> algorithm the spacing of each pixel/voxel in each spatial dimension. It
> then calculates the distance transform. So if you put a zero in, it will
> traverse in that dimension with a distance cost of zero for each step. This
> will generate a result that has mostly spurious zero distances, rather than
> select a particular axis to calculate the distance transform along.
>
> To calculate the correct distance function along a specific axis probably
> requires repeated calls along that axis; since scipy.ndimage is by
> definition n-dimensional it should be able to efficiently handle rank-1
> arrays without issue.
>
> I use the super handy Chrome extension "Markdown Here" to write in
> Markdown and then have my free entry fields converted to pretty HTML prior
> to posting. At this point I pretty much think in Markdown...
>
> Josh
>
>   --
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140715/9e30065b/attachment.html>

From patricksnape at gmail.com  Wed Jul 16 11:36:13 2014
From: patricksnape at gmail.com (Patrick Snape)
Date: Wed, 16 Jul 2014 08:36:13 -0700 (PDT)
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
 <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
 <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com>
Message-ID: <5e447c6a-b4d7-4c45-bfa8-0f76a5916b1f@googlegroups.com>

There is currently a bug in the Anaconda repositories whereby Anaconda 
ship, by default, a package they call 'imaging'. This seems to be some 
custom version of Pillow, as it still namespaces the PIL Image class. 
Pillow, on the other hand, is incorrectly linked against the libraries that 
Anaconda ships on Windows, and so lots of things will fail. I've opened 
this bug here: 

https://github.com/ContinuumIO/anaconda-issues/issues/30#issuecomment-42466975

I've resolved this at the moment by requiring the `imaging` package instead 
of `pillow` within my conda build script (for a project I maintain).

On Friday, 11 July 2014 17:31:39 UTC+1, Juan Nunez-Iglesias wrote:
>
> Hey Stefan,
>
> Pillow is in conda, imread is not. My experimentation over the last 15 
> minutes suggests that it will be much more of a challenge to install imread 
> than pillow. (I'm also not sure whether imread supports Python 3 and that's 
> why things are failing.)
>
> I also just saw @jjhelmus's email so maybe PIL should throw its hat into 
> the ring... 
>
>
> On Fri, Jul 11, 2014 at 10:44 AM, St?fan van der Walt <ste... at sun.ac.za 
> <javascript:>> wrote:
>
>> Hi Juan
>>
>> On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni.... at gmail.com 
>> <javascript:>> wrote:
>> > Cheap solution: make Pillow a requirement.
>>
>> My suggestion last time was to make 'imread' a requirement--what do you 
>> think?
>>
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140716/8619037f/attachment.html>

From patricksnape at gmail.com  Wed Jul 16 12:18:33 2014
From: patricksnape at gmail.com (Patrick Snape)
Date: Wed, 16 Jul 2014 09:18:33 -0700 (PDT)
Subject: Question: Placement of channels as the last axis - is this a
 sensible memory layout?
Message-ID: <904da8ba-48de-4ab2-b477-20643a360960@googlegroups.com>

Hi,

I'm one of the maintainers of a project that has some overlap with 
scikit-image. Recently, I've been working on optimising some of our slower 
code paths, and I came across an interesting result. In our package, we 
order our image data in the same way as in scikit-image:

image.shape = [height, width, channels]

Given that cPython runs on top of C, this means that the normal memory 
layout is generally row-major. Therefore, in the C-contiguous layout of the 
above memory pattern, it means that the rightmost channel indexes fastest. 
For example, when iterating over a vectorised image (stolen shamelessly 
from Wikipedia):

int A[2, 3, 4] = np.array([[[1,2,3,4], [5,6,7,8], [9,10,11,12]], [[13,14,15,16}, [17,18,19,20], [21,22,23,24]])


We walk that memory:


1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24


Practically, this means that we can most efficiently walk along the channels. 


However! In my experience, especially with 2D images, you usually store most of your relationships across the image and leave the channels as independent of one another. A simple example of this, and the one I was considering, is calculating the gradient of a multi-channel image (so a 3 channel RGB image will return a 6-channel image that represents the x and y gradient over each channel R, G and B).


Now, by calculating the gradient on a [height, width, channels] image, I have to jump a lot further in memory to find my neighbours, because I'm also skipping over channels. This is actually very inefficient, and in my testing (implementing the gradient method in cython) this actually causes a huge bottleneck. For example, the more channels you have, the closer in performance my code comes to Numpy's pure Python gradient implementation. This is because both pieces of code are being hurt by having to work 'against' the memory layout. 


A practical example of this can be seen here: http://nbviewer.ipython.org/gist/patricksnape/7b31c14c7103c2995956


As mentioned, I have some code I've been working on that implements the gradient directly in Cython and uses OpenMP to parallelize the gradient over the channels, which is *significantly* faster for the channels first case.


So, my question is: *why did you choose to place the channels on the last axis rather than the first?*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140716/d39aeec0/attachment.html>

From eduardoarnoldh at gmail.com  Wed Jul 16 12:56:59 2014
From: eduardoarnoldh at gmail.com (Eduardo Henrique Arnold)
Date: Wed, 16 Jul 2014 09:56:59 -0700 (PDT)
Subject: Non-linear distance based filter
In-Reply-To: <CA+JHcKQBqeB-UaWb9As-Z1PMo3hy70TNFg7omUTzQrHJMjXP7A@mail.gmail.com>
References: <e6e591a2-2f3a-4f9e-8ee3-1e3f03095bd0@googlegroups.com>
 <4436d368-0af8-4cd3-8618-3c5ef497ca3f@googlegroups.com> <762a46ef-7aea-4cfe-b766-b736da95736b@googlegroups.com>
 <51b3ad2e-1900-4cf9-9c5f-4645ce4b5dd9@googlegroups.com>
 <CA+JHcKQBqeB-UaWb9As-Z1PMo3hy70TNFg7omUTzQrHJMjXP7A@mail.gmail.com>
Message-ID: <6e857c6a-9b75-42be-83b7-b4f22fdfe69e@googlegroups.com>

Yes, setting the vertical sampling value to a high value (i.e. 10000) did 
the trick. It makes sense since it is going to sample the the next pixel in 
a vertical position that does not exist in the image. With the right 
distance matrix I could use Josh's idea, as he suggested on the first 
reply. That was simpler than implementing something with several loops.

Thank you both, those were very quick and effective answers. :)

On Wednesday, July 16, 2014 1:16:34 AM UTC+1, Juan Nunez-Iglesias wrote:
>
> @JDWarner, actually, instead of iterating, setting one of the sampling 
> dimensions to a very large number should produce the desired output, no? =)
>
>
> On Tue, Jul 15, 2014 at 11:13 AM, Josh Warner <silvertr... at gmail.com 
> <javascript:>> wrote:
>
>> I don?t believe sampling works like this. The sampling= kwarg tells the 
>> algorithm the spacing of each pixel/voxel in each spatial dimension. It 
>> then calculates the distance transform. So if you put a zero in, it will 
>> traverse in that dimension with a distance cost of zero for each step. This 
>> will generate a result that has mostly spurious zero distances, rather than 
>> select a particular axis to calculate the distance transform along.
>>
>> To calculate the correct distance function along a specific axis probably 
>> requires repeated calls along that axis; since scipy.ndimage is by 
>> definition n-dimensional it should be able to efficiently handle rank-1 
>> arrays without issue.
>>
>> I use the super handy Chrome extension ?Markdown Here? to write in 
>> Markdown and then have my free entry fields converted to pretty HTML prior 
>> to posting. At this point I pretty much think in Markdown?
>>
>> Josh
>>
>>   -- 
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140716/ab677835/attachment.html>

From jni.soma at gmail.com  Wed Jul 16 18:16:40 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Wed, 16 Jul 2014 17:16:40 -0500
Subject: Question: Placement of channels as the last axis - is this a
 sensible memory layout?
In-Reply-To: <904da8ba-48de-4ab2-b477-20643a360960@googlegroups.com>
References: <904da8ba-48de-4ab2-b477-20643a360960@googlegroups.com>
Message-ID: <CA+JHcKTEJ3CZS01r6soVSSzMurJkmFx9zR3DefB6+5FaS=NvQA@mail.gmail.com>

Hey Patrick,

Good question! And one that I've thought about repeatedly. In my own work I
usually "unwrap" the channels as the first step of my analysis, for the
reasons you've outlined.

All these conventions were in place when I got into image analysis so I
can't comment on the history, but I can offer a few hypotheses:

0. Image storage formats group the channels together by default (e.g. TIFF).
1. Matlab uses this convention, where it actually makes computational sense
since they use column-major array storage.
2. It makes sense from a notational perspective: image[i, j] -> color.
3. It actually is useful for certain functions, such as SLIC, in which all
the channels are considered together.

I'm guessing you are also interested in a follow-up question, namely, is
this ever likely to change, to which I would say, probably not, as the
convention is too embedded in the collective consciousness. In applications
where each channel requires separate processing, storing the channels as
separate grayscale files might make sense as a workaround.

Juan.



On Wed, Jul 16, 2014 at 11:18 AM, Patrick Snape <patricksnape at gmail.com>
wrote:

> Hi,
>
> I'm one of the maintainers of a project that has some overlap with
> scikit-image. Recently, I've been working on optimising some of our slower
> code paths, and I came across an interesting result. In our package, we
> order our image data in the same way as in scikit-image:
>
> image.shape = [height, width, channels]
>
> Given that cPython runs on top of C, this means that the normal memory
> layout is generally row-major. Therefore, in the C-contiguous layout of the
> above memory pattern, it means that the rightmost channel indexes fastest.
> For example, when iterating over a vectorised image (stolen shamelessly
> from Wikipedia):
>
> int A[2, 3, 4] = np.array([[[1,2,3,4], [5,6,7,8], [9,10,11,12]], [[13,14,15,16}, [17,18,19,20], [21,22,23,24]])
>
>
> We walk that memory:
>
>
> 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24
>
>
> Practically, this means that we can most efficiently walk along the channels.
>
>
> However! In my experience, especially with 2D images, you usually store most of your relationships across the image and leave the channels as independent of one another. A simple example of this, and the one I was considering, is calculating the gradient of a multi-channel image (so a 3 channel RGB image will return a 6-channel image that represents the x and y gradient over each channel R, G and B).
>
>
> Now, by calculating the gradient on a [height, width, channels] image, I have to jump a lot further in memory to find my neighbours, because I'm also skipping over channels. This is actually very inefficient, and in my testing (implementing the gradient method in cython) this actually causes a huge bottleneck. For example, the more channels you have, the closer in performance my code comes to Numpy's pure Python gradient implementation. This is because both pieces of code are being hurt by having to work 'against' the memory layout.
>
>
> A practical example of this can be seen here: http://nbviewer.ipython.org/gist/patricksnape/7b31c14c7103c2995956
>
>
> As mentioned, I have some code I've been working on that implements the gradient directly in Cython and uses OpenMP to parallelize the gradient over the channels, which is *significantly* faster for the channels first case.
>
>
> So, my question is: *why did you choose to place the channels on the last axis rather than the first?*
>
>  --
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140716/f25f8712/attachment.html>

From jni.soma at gmail.com  Wed Jul 16 18:25:09 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Wed, 16 Jul 2014 17:25:09 -0500
Subject: Make Pillow a requirement
In-Reply-To: <5e447c6a-b4d7-4c45-bfa8-0f76a5916b1f@googlegroups.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com>
 <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com>
 <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com> <5e447c6a-b4d7-4c45-bfa8-0f76a5916b1f@googlegroups.com>
Message-ID: <CA+JHcKSNe8Wjv2ptvHJoazk-_tc_Xj--asS_3VTBDhbvArs5ig@mail.gmail.com>

@stefanv, despite the possibility of getting imread included in Anaconda, I
would argue that it's better to go with the most widely supported package
by default. Will you also campaign to have it included in Canopy,
NeuroDebian, Python(x,y), etc.?

@jjhelmus and I also looked into grabbing BSD-licensed, pure Python readers
for TIFF, PNG, and JPEG, and including them in our code, to fall back on
when none of the plugins are available. As I recall we found a candidate
for PNG but I don't remember continuing on the search for a JPEG reader...

Patrick, thanks for the input! Hopefully the Pillow package will be updated
in Anaconda soon! I would not be happy shipping a release with a
vaguely-supported workaround as a dependency.


On Wed, Jul 16, 2014 at 10:36 AM, Patrick Snape <patricksnape at gmail.com>
wrote:

> There is currently a bug in the Anaconda repositories whereby Anaconda
> ship, by default, a package they call 'imaging'. This seems to be some
> custom version of Pillow, as it still namespaces the PIL Image class.
> Pillow, on the other hand, is incorrectly linked against the libraries that
> Anaconda ships on Windows, and so lots of things will fail. I've opened
> this bug here:
>
>
> https://github.com/ContinuumIO/anaconda-issues/issues/30#issuecomment-42466975
>
> I've resolved this at the moment by requiring the `imaging` package
> instead of `pillow` within my conda build script (for a project I maintain).
>
>
> On Friday, 11 July 2014 17:31:39 UTC+1, Juan Nunez-Iglesias wrote:
>
>> Hey Stefan,
>>
>> Pillow is in conda, imread is not. My experimentation over the last 15
>> minutes suggests that it will be much more of a challenge to install imread
>> than pillow. (I'm also not sure whether imread supports Python 3 and that's
>> why things are failing.)
>>
>> I also just saw @jjhelmus's email so maybe PIL should throw its hat into
>> the ring...
>>
>>
>> On Fri, Jul 11, 2014 at 10:44 AM, St?fan van der Walt <ste... at sun.ac.za>
>> wrote:
>>
>>> Hi Juan
>>>
>>>
>>> On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias <jni.... at gmail.com>
>>> wrote:
>>> > Cheap solution: make Pillow a requirement.
>>>
>>> My suggestion last time was to make 'imread' a requirement--what do you
>>> think?
>>>
>>> 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.
>>>
>>
>>  --
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140716/1191ec3e/attachment.html>

From patricksnape at gmail.com  Thu Jul 17 05:33:52 2014
From: patricksnape at gmail.com (Patrick Snape)
Date: Thu, 17 Jul 2014 02:33:52 -0700 (PDT)
Subject: Question: Placement of channels as the last axis - is this a
 sensible memory layout?
In-Reply-To: <CA+JHcKTEJ3CZS01r6soVSSzMurJkmFx9zR3DefB6+5FaS=NvQA@mail.gmail.com>
References: <904da8ba-48de-4ab2-b477-20643a360960@googlegroups.com>
 <CA+JHcKTEJ3CZS01r6soVSSzMurJkmFx9zR3DefB6+5FaS=NvQA@mail.gmail.com>
Message-ID: <3af0d9d5-fd4a-4670-b470-9e8edc651f86@googlegroups.com>

Hi Juan,

Thanks for getting back to my lengthy post!

I assumed that it was convention. As you said, we originally followed this 
scheme when we moved from Matlab and have only recently realised that it 
makes complete sense for Matlab to have that format, but not for us. It's 
also true that packages such as PIL return images in that format 
(presumably to maintain consistency with file formats, as you mentioned).

I agree that it makes more sense from a notational perspective, however, 
channels first allows you to do really nice things like:

for channel in image:
    channel[i, j]

which I like a lot.

My follow up was merely going to be more of a comment that a question to be 
honest. I just wanted to make sure I wasn't missing a trick somewhere 
whereby all my woes could be fixed via some magic I had failed to see. In 
our package, we implement a lot of image alignment methodologies and thus 
computations like the gradient etc are more important to us than treating 
channels as related features. We are very interested in algorithms like 
HOG, DSIFT, LBP that treat all the channels separately, so I'm seriously 
considering flipping our image type to get the performance boost.

It's just that I also dislike the idea of losing our current simple 
compatibility with scikit-image!

I will think hard on it. Thanks again for the reply!


On Wednesday, 16 July 2014 23:17:02 UTC+1, Juan Nunez-Iglesias wrote:
>
> Hey Patrick,
>
> Good question! And one that I've thought about repeatedly. In my own work 
> I usually "unwrap" the channels as the first step of my analysis, for the 
> reasons you've outlined.
>
> All these conventions were in place when I got into image analysis so I 
> can't comment on the history, but I can offer a few hypotheses:
>
> 0. Image storage formats group the channels together by default (e.g. 
> TIFF).
> 1. Matlab uses this convention, where it actually makes computational 
> sense since they use column-major array storage.
> 2. It makes sense from a notational perspective: image[i, j] -> color. 
> 3. It actually is useful for certain functions, such as SLIC, in which all 
> the channels are considered together.
>
> I'm guessing you are also interested in a follow-up question, namely, is 
> this ever likely to change, to which I would say, probably not, as the 
> convention is too embedded in the collective consciousness. In applications 
> where each channel requires separate processing, storing the channels as 
> separate grayscale files might make sense as a workaround.
>
> Juan.
>
>
>
> On Wed, Jul 16, 2014 at 11:18 AM, Patrick Snape <patric... at gmail.com 
> <javascript:>> wrote:
>
>> Hi,
>>
>> I'm one of the maintainers of a project that has some overlap with 
>> scikit-image. Recently, I've been working on optimising some of our slower 
>> code paths, and I came across an interesting result. In our package, we 
>> order our image data in the same way as in scikit-image:
>>
>> image.shape = [height, width, channels]
>>
>> Given that cPython runs on top of C, this means that the normal memory 
>> layout is generally row-major. Therefore, in the C-contiguous layout of the 
>> above memory pattern, it means that the rightmost channel indexes fastest. 
>> For example, when iterating over a vectorised image (stolen shamelessly 
>> from Wikipedia):
>>
>> int A[2, 3, 4] = np.array([[[1,2,3,4], [5,6,7,8], [9,10,11,12]], [[13,14,15,16}, [17,18,19,20], [21,22,23,24]])
>>
>>
>>
>> We walk that memory:
>>
>>
>>
>> 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24
>>
>>
>>
>> Practically, this means that we can most efficiently walk along the channels. 
>>
>>
>> However! In my experience, especially with 2D images, you usually store most of your relationships across the image and leave the channels as independent of one another. A simple example of this, and the one I was considering, is calculating the gradient of a multi-channel image (so a 3 channel RGB image will return a 6-channel image that represents the x and y gradient over each channel R, G and B).
>>
>>
>> Now, by calculating the gradient on a [height, width, channels] image, I have to jump a lot further in memory to find my neighbours, because I'm also skipping over channels. This is actually very inefficient, and in my testing (implementing the gradient method in cython) this actually causes a huge bottleneck. For example, the more channels you have, the closer in performance my code comes to Numpy's pure Python gradient implementation. This is because both pieces of code are being hurt by having to work 'against' the memory layout. 
>>
>>
>> A practical example of this can be seen here: http://nbviewer.ipython.org/gist/patricksnape/7b31c14c7103c2995956
>>
>>
>> As mentioned, I have some code I've been working on that implements the gradient directly in Cython and uses OpenMP to parallelize the gradient over the channels, which is *significantly* faster for the channels first case.
>>
>>
>> So, my question is: *why did you choose to place the channels on the last axis rather than the first?*
>>
>>  -- 
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140717/748a8cf1/attachment.html>

From jjhelmus at gmail.com  Thu Jul 17 14:56:12 2014
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Thu, 17 Jul 2014 13:56:12 -0500
Subject: Make Pillow a requirement
In-Reply-To: <CA+JHcKSNe8Wjv2ptvHJoazk-_tc_Xj--asS_3VTBDhbvArs5ig@mail.gmail.com>
References: <CA+JHcKRjHpnFND26dJ85_aJ_PMS4zpnzQ+-jhRytrLg60SZVnQ@mail.gmail.com> <CABDkGQnxMMkcT_L0gNPEQ4v678y77H91+x41stvhNLQh23+AJw@mail.gmail.com> <CA+JHcKT2VEEhwqCZUgobmHoUsdNCXpOMhpVuHB73A2S2XzN7cQ@mail.gmail.com> <5e447c6a-b4d7-4c45-bfa8-0f76a5916b1f@googlegroups.com> <CA+JHcKSNe8Wjv2ptvHJoazk-_tc_Xj--asS_3VTBDhbvArs5ig@mail.gmail.com>
Message-ID: <53C81C4C.1000903@gmail.com>

The original reason for suggesting making Pillow a requirements is that 
during the SciPy conference sprints Juan and I found that the unit tests 
were failing when only the modules required for scikit-image were 
installed.  I think parts of this should be fixed by Pull Request #1060 
[1] which will make the matplotlib related tests skippable.  This was 
compounded by the fact that the version of Pillow Continuum's provides 
for windows is broken, and the version of QT they link matplotlib to has 
some issues.  Let me do some additional testing and see if this is still 
an issue, if it is I'll open a GitHub issue.

  If anyone is interested there is an MIT licensed pure Python PNG 
reader at: https://github.com/drj11/pypng.

Cheers,

     - Jonathan Helmus

[1] https://github.com/scikit-image/scikit-image/pull/1060


On 07/16/2014 05:25 PM, Juan Nunez-Iglesias wrote:
> @stefanv, despite the possibility of getting imread included in 
> Anaconda, I would argue that it's better to go with the most widely 
> supported package by default. Will you also campaign to have it 
> included in Canopy, NeuroDebian, Python(x,y), etc.?
>
> @jjhelmus and I also looked into grabbing BSD-licensed, pure Python 
> readers for TIFF, PNG, and JPEG, and including them in our code, to 
> fall back on when none of the plugins are available. As I recall we 
> found a candidate for PNG but I don't remember continuing on the 
> search for a JPEG reader...
>
> Patrick, thanks for the input! Hopefully the Pillow package will be 
> updated in Anaconda soon! I would not be happy shipping a release with 
> a vaguely-supported workaround as a dependency.
>
>
> On Wed, Jul 16, 2014 at 10:36 AM, Patrick Snape 
> <patricksnape at gmail.com <mailto:patricksnape at gmail.com>> wrote:
>
>     There is currently a bug in the Anaconda repositories whereby
>     Anaconda ship, by default, a package they call 'imaging'. This
>     seems to be some custom version of Pillow, as it still namespaces
>     the PIL Image class. Pillow, on the other hand, is incorrectly
>     linked against the libraries that Anaconda ships on Windows, and
>     so lots of things will fail. I've opened this bug here:
>
>     https://github.com/ContinuumIO/anaconda-issues/issues/30#issuecomment-42466975
>
>     I've resolved this at the moment by requiring the `imaging`
>     package instead of `pillow` within my conda build script (for a
>     project I maintain).
>
>
>     On Friday, 11 July 2014 17:31:39 UTC+1, Juan Nunez-Iglesias wrote:
>
>         Hey Stefan,
>
>         Pillow is in conda, imread is not. My experimentation over the
>         last 15 minutes suggests that it will be much more of a
>         challenge to install imread than pillow. (I'm also not sure
>         whether imread supports Python 3 and that's why things are
>         failing.)
>
>         I also just saw @jjhelmus's email so maybe PIL should throw
>         its hat into the ring...
>
>
>         On Fri, Jul 11, 2014 at 10:44 AM, St??fan van der Walt
>         <ste... at sun.ac.za> wrote:
>
>             Hi Juan
>
>
>             On Fri, Jul 11, 2014 at 5:32 PM, Juan Nunez-Iglesias
>             <jni.... at gmail.com> wrote:
>             > Cheap solution: make Pillow a requirement.
>
>             My suggestion last time was to make 'imread' a
>             requirement--what do you think?
>
>             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.
>
>
>     -- 
>     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
>     <mailto: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 
> <mailto:scikit-image+unsubscribe at googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140717/9cd78191/attachment.html>

From jni.soma at gmail.com  Thu Jul 17 19:01:17 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Thu, 17 Jul 2014 18:01:17 -0500
Subject: Question: Placement of channels as the last axis - is this a
 sensible memory layout?
In-Reply-To: <3af0d9d5-fd4a-4670-b470-9e8edc651f86@googlegroups.com>
References: <904da8ba-48de-4ab2-b477-20643a360960@googlegroups.com>
 <CA+JHcKTEJ3CZS01r6soVSSzMurJkmFx9zR3DefB6+5FaS=NvQA@mail.gmail.com> <3af0d9d5-fd4a-4670-b470-9e8edc651f86@googlegroups.com>
Message-ID: <CA+JHcKQ07-a+tPwxQAh9OwAsHKH-kXdtwzbju2Zsh0t1mkiNVA@mail.gmail.com>

Hey Patrick,

Honestly, since you have to store your images somehow, and most file
formats store the pixels together, you are going to have to pay the cost of
unwrapping the channels at some point. If you are doing a lot of
manipulations in sequence, it makes sense to do it early on in your
pipeline -- but at that point it might make the most sense to unwrap the
channels altogether into separate grayscale images, getting both speed and
compatibility, at the cost of perhaps some readability.

Another option would be to just use column-major order for all your images.
Although it's not the default, Numpy provides for this (`order='F'`). I
think all of our functions and Numpy's would work out of the box, and you'd
get your performance boost! Come to think of it, that might be the magic
you were looking for! =P

Juan.


On Thu, Jul 17, 2014 at 4:33 AM, Patrick Snape <patricksnape at gmail.com>
wrote:

> Hi Juan,
>
> Thanks for getting back to my lengthy post!
>
> I assumed that it was convention. As you said, we originally followed this
> scheme when we moved from Matlab and have only recently realised that it
> makes complete sense for Matlab to have that format, but not for us. It's
> also true that packages such as PIL return images in that format
> (presumably to maintain consistency with file formats, as you mentioned).
>
> I agree that it makes more sense from a notational perspective, however,
> channels first allows you to do really nice things like:
>
> for channel in image:
>     channel[i, j]
>
> which I like a lot.
>
> My follow up was merely going to be more of a comment that a question to
> be honest. I just wanted to make sure I wasn't missing a trick somewhere
> whereby all my woes could be fixed via some magic I had failed to see. In
> our package, we implement a lot of image alignment methodologies and thus
> computations like the gradient etc are more important to us than treating
> channels as related features. We are very interested in algorithms like
> HOG, DSIFT, LBP that treat all the channels separately, so I'm seriously
> considering flipping our image type to get the performance boost.
>
> It's just that I also dislike the idea of losing our current simple
> compatibility with scikit-image!
>
> I will think hard on it. Thanks again for the reply!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140717/db854531/attachment.html>

From eduardoarnoldh at gmail.com  Mon Jul 21 06:54:12 2014
From: eduardoarnoldh at gmail.com (Eduardo Henrique Arnold)
Date: Mon, 21 Jul 2014 03:54:12 -0700 (PDT)
Subject: Clarification on Transform classes description
Message-ID: <26e2cd28-dd71-4802-bc95-4b0869012566@googlegroups.com>

Hi. I have been trying to use the *ProjectiveTransform* class to fix 
perspective deformation and it took me a while to realize the *estimate* method 
uses (x, y) coordinates and that was the source of my unexpected results. 
Even though the vector is described in the class description, I think it 
should either explicitly define the form of coordinates or use the default 
convention for images (y, x).

I appreciate your attention,
   Eduardo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140721/efb9970e/attachment.html>

From jim at rybarski.com  Mon Jul 21 22:23:24 2014
From: jim at rybarski.com (jim at rybarski.com)
Date: Mon, 21 Jul 2014 19:23:24 -0700 (PDT)
Subject: nd2 support
Message-ID: <80368e16-c2d9-4da7-8a44-e61707afd8ee@googlegroups.com>

I'm looking for something that can directly read .nd2 files (an 
undocumented Nikon format that seems to be similar to multipage TIFFs). 
I've found 
this: https://pythonhosted.org/SLOTH/_modules/sloth/read_nd2.html which 
sorta works, though I'd like to clean it up and get it working in 
scikit-image. But before I dive into that, I'd like to know:

1) Is there a better implementation somewhere, or does anyone have 
experience parsing .nd2 files?
2) Since the format can contain hierarchical and multidimensional image 
sets, would this require a new kind of abstraction for the io module? To 
give a concrete example, the microscope data I'm working with contains 16 
fields of view from different xy-positions on the sample slide, and in each 
field of view there are three images for each time index (different 
fluorescence filters). So while it would make sense to use io.MultiImage 
for any given combination of field-of-view and filter, it wouldn't make 
sense to do so for the entire nd2 file. I'm thinking perhaps there could be 
some kind of intermediary object that allows you to drill down through the 
hierarchy and at the end it returns a MultiImage object, or something like 
that.

I'd appreciate any suggestions and I'd love to hear what everyone thinks. 
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140721/14ee075d/attachment.html>

From jni.soma at gmail.com  Mon Jul 21 22:37:43 2014
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Mon, 21 Jul 2014 21:37:43 -0500
Subject: nd2 support
In-Reply-To: <80368e16-c2d9-4da7-8a44-e61707afd8ee@googlegroups.com>
References: <80368e16-c2d9-4da7-8a44-e61707afd8ee@googlegroups.com>
Message-ID: <CA+JHcKSVWLsxG1a=hmKJmFEBrBDQYR-psVgqu2uzc8TQn0aFdQ@mail.gmail.com>

Hi Jim,

The gold-standard for microscopy formats is (imho) the BioFormats library:
http://www.openmicroscopy.org/site/support/bio-formats5/supported-formats.html

which includes support for .nd2.

The CellProfiler team recently released Python bindings for that library:
http://pythonhosted.org/python-bioformats/

I've been successfully using that to load up some 5D (3D + time + channels)
Leica microscopy stacks. I recommend you try that, and focus contributions
there.

The IO module in skimage is due for a major cleanup, and I don't think we
are ready to support fully nD stacks yet. What I would like to do
eventually is to make it easier to call BioFormats from skimage.io. But
before that, we are aiming to *properly* support jpg, png, and tif stacks.
See a recent discussion on this mailing list for details.

Thanks for the interest!

Juan.



On Mon, Jul 21, 2014 at 9:23 PM, <jim at rybarski.com> wrote:

> I'm looking for something that can directly read .nd2 files (an
> undocumented Nikon format that seems to be similar to multipage TIFFs).
> I've found this:
> https://pythonhosted.org/SLOTH/_modules/sloth/read_nd2.html which sorta
> works, though I'd like to clean it up and get it working in scikit-image.
> But before I dive into that, I'd like to know:
>
> 1) Is there a better implementation somewhere, or does anyone have
> experience parsing .nd2 files?
> 2) Since the format can contain hierarchical and multidimensional image
> sets, would this require a new kind of abstraction for the io module? To
> give a concrete example, the microscope data I'm working with contains 16
> fields of view from different xy-positions on the sample slide, and in each
> field of view there are three images for each time index (different
> fluorescence filters). So while it would make sense to use io.MultiImage
> for any given combination of field-of-view and filter, it wouldn't make
> sense to do so for the entire nd2 file. I'm thinking perhaps there could be
> some kind of intermediary object that allows you to drill down through the
> hierarchy and at the end it returns a MultiImage object, or something like
> that.
>
> I'd appreciate any suggestions and I'd love to hear what everyone thinks.
> Thanks!
>
> --
> 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: <http://mail.python.org/pipermail/scikit-image/attachments/20140721/472b5c0b/attachment.html>

From adam at adamfeuer.com  Fri Jul 25 10:53:09 2014
From: adam at adamfeuer.com (Adam F)
Date: Fri, 25 Jul 2014 07:53:09 -0700 (PDT)
Subject: adding ability to import and export PIL image objects from memory
Message-ID: <37021f5c-6a58-4fa2-94e5-921747038bb9@googlegroups.com>

Hi,

I'm a first-time contributor to scikit-image. Me and my team ran into a 
problem yesterday - we want to import and export PIL images into 
scikit-image without reading or writing from disk. The current version of 
pil_plugin.py doesn't have APIs for this.

I refactored the plugin a bit to add APIs for importing and exporting PIL 
images directly. Here's the pull request:

https://github.com/scikit-image/scikit-image/pull/1083

I'm not sure who to ask - but will someone review this pull request and let 
me know if there are problems with it? Or if it could be improved?

cheers
adam
--
Adam Feuer
Seattle, WA, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140725/50818d7e/attachment.html>

From adam at adamfeuer.com  Fri Jul 25 14:40:19 2014
From: adam at adamfeuer.com (Adam F)
Date: Fri, 25 Jul 2014 11:40:19 -0700 (PDT)
Subject: adding ability to import and export PIL image objects from
 memory
In-Reply-To: <CABDkGQ=ORk+6MeDGsmVif_dpGkb+JBB+tvPzV5qcXx+hy1h7KA@mail.gmail.com>
References: <37021f5c-6a58-4fa2-94e5-921747038bb9@googlegroups.com>
 <CABDkGQ=ORk+6MeDGsmVif_dpGkb+JBB+tvPzV5qcXx+hy1h7KA@mail.gmail.com>
Message-ID: <cc8dd2da-aaae-43d4-8e28-b50afa5dd92c@googlegroups.com>

On Friday, July 25, 2014 10:53:15 AM UTC-7, Stefan van der Walt wrote:
>
> Sure, I'll have a look. 
>

Thanks St?fan!

cheers
adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140725/f84d0a16/attachment.html>

From stefan at sun.ac.za  Fri Jul 25 13:52:53 2014
From: stefan at sun.ac.za (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=)
Date: Fri, 25 Jul 2014 19:52:53 +0200
Subject: adding ability to import and export PIL image objects from memory
In-Reply-To: <37021f5c-6a58-4fa2-94e5-921747038bb9@googlegroups.com>
References: <37021f5c-6a58-4fa2-94e5-921747038bb9@googlegroups.com>
Message-ID: <CABDkGQ=ORk+6MeDGsmVif_dpGkb+JBB+tvPzV5qcXx+hy1h7KA@mail.gmail.com>

Hi Adam

On Fri, Jul 25, 2014 at 4:53 PM, Adam F <adam at adamfeuer.com> wrote:
> I'm a first-time contributor to scikit-image. Me and my team ran into a
> problem yesterday - we want to import and export PIL images into
> scikit-image without reading or writing from disk. The current version of
> pil_plugin.py doesn't have APIs for this.

Thank you for taking the time to send us your changes.

> https://github.com/scikit-image/scikit-image/pull/1083
>
> I'm not sure who to ask - but will someone review this pull request and let
> me know if there are problems with it? Or if it could be improved?

Sure, I'll have a look.

Regards
St?fan


From raphael at aims.ac.za  Tue Jul 29 13:01:14 2014
From: raphael at aims.ac.za (Raphael Okoye)
Date: Tue, 29 Jul 2014 10:01:14 -0700 (PDT)
Subject: Analyse images
Message-ID: <82d5b212-b031-4efe-b687-a24d59384875@googlegroups.com>

hi all,

 I want to analyze these images. See links below. The background and the 
crystals have the same color thus, making it difficult to segment. And 
since the background and crystals have the same color, it is difficult to 
simply subtract the background. Please, I need ideas on how to proceed with 
this analysis. Thanks.

Raphael.

https://drive.google.com/file/d/0B6nj1d7RmQ7TRmNwZzI1ajdhbFk/edit?usp=sharing

https://drive.google.com/file/d/0B6nj1d7RmQ7TUUNpNEl4VzlWOEE/edit?usp=sharing

https://drive.google.com/file/d/0B6nj1d7RmQ7TcHpoNjM0ZFhSZ1U/edit?usp=sharing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140729/da8bdc8a/attachment.html>