Some emails describing one set of use cases that require this feature.

---------- Forwarded message ----------
From: Johnson, Hans J <hans-johnson@uiowa.edu>
Date: Wed, Jul 25, 2012 at 10:26 AM
Subject: Re: Plans for final year NAC
To: "pieper@bwh.harvard.edu" <pieper@bwh.harvard.edu>
Cc: "kikinis@bwh.harvard.edu" <kikinis@bwh.harvard.edu>, Daniel Rubin <dlrubin@stanford.edu>, Jim Miller <millerjv@ge.com>, Andriy Fedorov <fedorov@bwh.harvard.edu>, Stephen Aylward <Stephen.Aylward@kitware.com>, Dominik Meier <meier@bwh.harvard.edu>, Tiffany Ting Liu <tiffanytingliu@gmail.com>, "william.a.du@gmail.com" <william.a.du@gmail.com>

From my (very biased) point of view, there is a cascade of updates that
need to fall into place before this can really happen well.

1) Add SimpleITK (i.e. Move to ITKv4)
2) Improve Python build support (Don't strip so much of the core python
functionality when installing python)
(https://github.com/hjmjohnson/Slicer/commit/83ba4df768a8cdc5aeb5691d62fa5e
1d8e6971db)
3) Modernize NumPy version build support
4) Add back SciPy version build support
5) get easy_install (or pip) install working for Slicer install trees

Hans

--
Hans J. Johnson, Ph.D.
hans-johnson@uiowa.edu
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive

Iowa City, Iowa 52242
Phone: 319-353-8587

-----Original Message-----
From: Steve Pieper <pieper@ibility.net>
Reply-To: "pieper@bwh.harvard.edu" <pieper@bwh.harvard.edu>
Date: Wednesday, July 25, 2012 8:49 AM
To: Hans Johnson <hans-johnson@uiowa.edu>
Cc: Ron Kikinis <kikinis@bwh.harvard.edu>, Daniel Rubin
<dlrubin@stanford.edu>, Jim Miller <millerjv@ge.com>, Andriy Fedorov
<fedorov@bwh.harvard.edu>, Stephen Aylward <Stephen.Aylward@kitware.com>,
Dominik Meier <meier@bwh.harvard.edu>, Tiffany Ting Liu
<tiffanytingliu@gmail.com>, "william.a.du@gmail.com"
<william.a.du@gmail.com>
Subject: Re: Plans for final year NAC

I'm with Hans - I think nipype has a great potential to unify the
interfaces. I think we were pretty close last time I looked (January
project week).

-Steve

On Wed, Jul 25, 2012 at 9:43 AM, Johnson, Hans J <hans-johnson@uiowa.edu>
wrote:

At one point I was hoping that nipype could act as the simple interface
to
many of these external tools in slicer. Most of the work for wrapping
fsl
(and afni, and spm, and ...) has already been done very cleanly in
nipype.
We would then just have to provide python based interface wrapping for
the command line arguments.

That was my hope.

Hans

Hans J. Johnson, Ph.D.
hans-johnson@uiowa.edu
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive

Iowa City, Iowa 52242
Phone: 319-353-8587

-----Original Message-----
From: Ron Kikinis <kikinis@bwh.harvard.edu>
Reply-To: Ron Kikinis <kikinis@bwh.harvard.edu>
Date: Wednesday, July 25, 2012 8:34 AM
To: Daniel Rubin <dlrubin@stanford.edu>
Cc: 'Jim Miller' <millerjv@ge.com>, 'Andriy Fedorov'
<fedorov@bwh.harvard.edu>, 'Steve Pieper' <pieper@bwh.harvard.edu>,
'Stephen Aylward' <Stephen.Aylward@kitware.com>, Hans Johnson
<hans-johnson@uiowa.edu>, 'Dominik Meier' <meier@bwh.harvard.edu>,
Tiffany
Ting Liu <tiffanytingliu@gmail.com>, "william.a.du@gmail.com"
<william.a.du@gmail.com>
Subject: Re: Plans for final year NAC

Also, have you tried grow cut?

Ron

On 7/25/12 9:27 AM, Daniel Rubin wrote:

Hi Tiffany and William,

What specific FSL modules are you using, and with what parameters? I've
been in contact with the Slicer people about your requests and they
would
like to know this.

Thanks
DR

---

Daniel L. Rubin, MD, MS
Assistant Professor of Radiology and Medicine (Biomedical Informatics)
Department of Radiology | Stanford University
Richard M. Lucas Center | 1201 Welch Road, Office P285
Stanford, CA 94305-5488
Phone: 650-723-9495 | Fax: 650-723-5795
Web: http://rubin.web.stanford.edu/

-----Original Message-----
From: Ron Kikinis [mailto:kikinis@bwh.harvard.edu]
Sent: Tuesday, July 24, 2012 8:09 PM
To: Daniel Rubin
Cc: Jim Miller; Andriy Fedorov; Steve Pieper; Stephen Aylward; Hans
Johnson;
Dominik Meier
Subject: Re: Plans for final year NAC

Daniel,

I am forwarding your suggestions to different people and hopefully, we
will
hear back.

-The problem with FSL is the license, which is not compatible with the
slicer
license. I am not opposed to having such a plug-in, but will not spend
nac
or
namic resources on it.
-What specific FSL modules are your people using, and with what
parameters? Hans and Dominik might be able to recommend equivalent
settings for the brains tools that we use in slicer.
-DCE: It has been in the works for a while (Jim Miller), and I am told
its
imminent. At latest, it will be available at RSNA, I am told.

Ron

On 7/24/12 10:02 PM, Daniel Rubin wrote:

Hi Ron,

I spoke with my students who are using Slicer on their current
projects and I have this feedback that may be helpful to you.

They are doing a lot of brain tumor segmentation and DCE-MRI analysis.
They had the following specific feedback:

1)Current scalp exclusion methods are lacking/missing from Slicer, and
registration to atlases is not as good as in FSL. Thus they would
really like an FSL plugin in slicer to let them integrate that
functionality into Slicer

2)They would like if someone would implement DCE-MRI analysis in
slicer.
That way they could do lesion segmentation and then DCE-MRI analysis
in Slicer. We have an implementation of DCE-MRI analysis in matlab and
Tom Yankeelov at Vanderbilt has one in IDL. I think Greg Sorenson has
an old one in C, but I was never able to get him to share it.

These might be some ways to improve slicer to enable our work, and if
you pursue any of this we'd be happy to give feedback.

Thanks

Daniel

I think that Nipype will be a great addition. I'm all for this and chipping in

D

PyXNAT (and its dependencies) would be awesome. The dependencies are as follows:

lxml v1.3.6+
httplib2 v0.6+

Package site: http://packages.python.org/pyxnat/index.html

-Sunil

http://www.lfd.uci.edu/~gohlke/pythonlibs/

SSL should also be added to the standard python build if possible:

Kumar, Sunil kumars@mir.wustl.edu via bwh.harvard.edu
12:09 PM (21 hours ago)

to slicer-devel
Hi,

My question pertains specifically to OSX 10.8 64-bit.

I've tried several different approaches to get SSL to build with Python (via a Slicer build). I can't get any to work. They are as follows:

1) SSL is not found in the default Slicer build. (I get errors when typing "import ssl" in the Python command prompt.)

2) If I try to "make" Slicer's Python alone, the SSL directories are incorrect and Python builds without it.

3) When I direct "Slicer4-superbuild/python/Modules/Setup" and "Slicer4-superbuild/python/setup.py" to the native install of SSL, I get architecture errors when I build Python.

4) When I direct "Slicer4-superbuild/python/Modules/Setup" and "Slicer4-superbuild/python/setup.py" to a 64-bit build of OpenSSL, I also get architecture errors when I build Python.

Would you know of a way to get around this? Any suggestions are appreciated.

Thanks,
Sunil

Is there a suggested workaround how to compile Slicer with OpenSSL enabled?

Will keep you posted of the progress soon. Thanks. Jc

I'd also like to add pyMC and pyZMQ to my wish list of python packages.

it seems that Lauren would need it in addition to numpy

On 5/2/13 2:05 PM, Steve Pieper wrote:
Hi Ron -

Nothing has changed yet except that the package is now based on python
2.7.3 rather than 2.6. But now that this is working, Jc envisions
simplifying the process of bringing new python packages into the slicer
distribution.

Here's the bug report:

http://www.na-mic.org/Bug/view.php?id=2352

we can add joblib to the list.

-Steve

On Thu, May 2, 2013 at 9:32 AM, Ron Kikinis <kikinis@bwh.harvard.edu
<mailto:kikinis@bwh.harvard.edu>> wrote:

how about joblib?

On 5/2/13 9:29 AM, Ron Kikinis wrote:

    Steve,

    Now that python has been cmake-ified for Slicer, which python
    packages
    are currently available in the Slicer ecosystem?

    numpy, scipy, ? What else?

    Ron

I agree that a way to fork multiple python processes such as done by the package joblib, would be useful. This is impossible from the current Slicer python interpreter. Alternatively, a tutorial/examples on how best to do multiprocessing in python-slicer would be helpful.

Other packages I am using are within scipy. These include scipy.optimize, scipy.cluster, scipy.stats

Is there a good reason for not just adding pydicom into Slicer superbuild? It is a small package, and the capability to access DICOM is pretty much essential for Slicer tasks, but not possible from python!

I understand I can install pydicom, but on some systems I am unable to build Slicer, since they don't have a GUI head and X related libraries -- so I cannot use Slicer in batch mode for DICOM related tasks in my scripts. I am also unable to compile Slicer on the machines of my clinical users.

DICOM support is such a basic and essential functionality that I do not see why we can't just integrate it.

+1 for integrating pydicom in the superbuild.

@jc: can you give some hints what should be done to include this package into the superbuild? It does not have any dependencies.

for the reference, pydicom has been integrated a while ago

https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_python-pydicom.cmake

It looks like these were all addressed or not relevant anymore.