important: repository changes for slicer4 and slicer3.6

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

important: repository changes for slicer4 and slicer3.6

pieper
Administrator
[Note: this is information is important for people using the slicer svn
repositories.  I cc'd slicer-users just to be sure I catch everyone who
is impacted - if you don't know/care what a slicer svn repository is,
feel free to ignore this message...  Followups and future messages on
this topic will go to slicer-devel only.]

*Summary:* there is now a Slicer4 svn repository [1] which is a copy of
the Slicer3 trunk as of earlier today.  The Slicer3 existing trunk will
soon be used only for slicer 3.6 maintenance purposes.

[1] http://svn.slicer.org/Slicer4


*Background:* Slicer4 [2] is a significant re-write of the user
interface to use Qt.  Along the way, several structural improvements to
the non-UI code are being made as well.  Until now, we had been
maintaining the ability to build either a KWWidgets-based GUI or a
Qt-based GUI on the same code base in the Slicer3 svn trunk.  Having
both Slicer3 and Slicer4 both hosted in a repository named "Slicer3" has
been, frankly, confusing.  But it was useful, since many changes
impacted both versions.  As the code has progressed this is no longer
needed so the two code streams will now diverge.  Essentially the
Slicer3 code will remain  stable with the exception of fixes for the
issues identified for fixes in the 3.6.x patch releases [3].

[2] http://www.slicer.org/slicerWiki/index.php/Slicer4
[3] http://www.slicer.org/slicerWiki/index.php/Slicer3:3.6_Final_Issues


*Changes to the Slicer3 svn*

By the end of the day today I expect to have the following layout in the
Slicer3 svn.  Please take care to adjust your practices accordingly.

http://svn.slicer.org/Slicer3/oldtrunk - will be trunk at the time I
make the change (this is a backup as a place to find code that was
committed to the trunk after revision 15031 when the Slicer4 repository
was created).

http://svn.slicer.org/Slicer3/trunk - will be a copy of
http://svn.slicer.org/Slicer3/branches/Slicer-3-6.


*Nightly builds*

Recently the nightly slicer builds have been unstable because because
they were built from the Slicer3 trunk which included both bug fixes
intended for 3.6.x and reworked code intended for 4.  In the coming
weeks we will be start making two sets of nightly builds: one for
Slicer3.6.2-beta and one for Slicer4-alpha.  The "3.7" numbering from
the current nightly builds will no longer be used.

The process for developers working on 3.6.x bug fixes should be:

- test your fixes on a checkout from the (new) Slicer3 trunk
- point users to the nightly builds for testing
- if the tests are good, merge the code to the Slicer-3-6 branch.
- if the fixes apply to slicer4, they should also be merged to the
Slicer4 trunk



*Dashboards*

Dashboard machines should point to the Slicer3 trunk for testing Slicer3
or to the Slicer4 trunk for testing Slicer4 (see how much more logical
that is?).  In the coming weeks we plan to set up a new set of nightly
builds of Slicer4 on various platforms.


*The future of the Slicer4 svn repository*

In the coming months we will be stripping away the KWWidgets code from
slicer4 as well as the getbuildtest build system (People should already
be using the SuperBuild approach exclusively when building slicer4).
There will be many more exciting improvements too.  Stay tuned...


Hope this is all clear for the people who need to act on this info.
Please send follow-up info or questions to the slicer-devel list.

Thanks,
Steve
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: [slicer-devel] important: repository changes for slicer4 and slicer3.6

Daniel Haehn
Hi Steve,

great work!

I just checked out the new Slicer4 trunk and performed a SuperBuild. In general it worked fine!

Unfortunately, I still had to compile python manually on my Mac (PythonQT enabled) to prevent the following error:
[  0%] Built target vtkWrapHierarchy
make[5]: *** No rule to make target `/Users/daniel/SLICER/QT_TRUNK/Slicer4-SuperBuild/python-build/lib/libpython2.6.dylib', needed by `bin/vtkWrapPython'.  Stop.
make[4]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [VTK-prefix/src/VTK-stamp/VTK-build] Error 2
make[1]: *** [CMakeFiles/VTK.dir/all] Error 2
make: *** [all] Error 2

Anyway, I updated the Slicer 4 Build instructions on the wiki:
http://www.slicer.org/slicerWiki/index.php/Slicer4:Build_Instructions

(I also updated the QT links to v4.7 which was released 2 days ago..)

Daniel

On Sep 22, 2010, at 2:50 PM, Steve Pieper wrote:

> [Note: this is information is important for people using the slicer svn
> repositories.  I cc'd slicer-users just to be sure I catch everyone who
> is impacted - if you don't know/care what a slicer svn repository is,
> feel free to ignore this message...  Followups and future messages on
> this topic will go to slicer-devel only.]
>
> *Summary:* there is now a Slicer4 svn repository [1] which is a copy of
> the Slicer3 trunk as of earlier today.  The Slicer3 existing trunk will
> soon be used only for slicer 3.6 maintenance purposes.
>
> [1] http://svn.slicer.org/Slicer4
>
>
> *Background:* Slicer4 [2] is a significant re-write of the user
> interface to use Qt.  Along the way, several structural improvements to
> the non-UI code are being made as well.  Until now, we had been
> maintaining the ability to build either a KWWidgets-based GUI or a
> Qt-based GUI on the same code base in the Slicer3 svn trunk.  Having
> both Slicer3 and Slicer4 both hosted in a repository named "Slicer3" has
> been, frankly, confusing.  But it was useful, since many changes
> impacted both versions.  As the code has progressed this is no longer
> needed so the two code streams will now diverge.  Essentially the
> Slicer3 code will remain  stable with the exception of fixes for the
> issues identified for fixes in the 3.6.x patch releases [3].
>
> [2] http://www.slicer.org/slicerWiki/index.php/Slicer4
> [3] http://www.slicer.org/slicerWiki/index.php/Slicer3:3.6_Final_Issues
>
>
> *Changes to the Slicer3 svn*
>
> By the end of the day today I expect to have the following layout in the
> Slicer3 svn.  Please take care to adjust your practices accordingly.
>
> http://svn.slicer.org/Slicer3/oldtrunk - will be trunk at the time I
> make the change (this is a backup as a place to find code that was
> committed to the trunk after revision 15031 when the Slicer4 repository
> was created).
>
> http://svn.slicer.org/Slicer3/trunk - will be a copy of
> http://svn.slicer.org/Slicer3/branches/Slicer-3-6.
>
>
> *Nightly builds*
>
> Recently the nightly slicer builds have been unstable because because
> they were built from the Slicer3 trunk which included both bug fixes
> intended for 3.6.x and reworked code intended for 4.  In the coming
> weeks we will be start making two sets of nightly builds: one for
> Slicer3.6.2-beta and one for Slicer4-alpha.  The "3.7" numbering from
> the current nightly builds will no longer be used.
>
> The process for developers working on 3.6.x bug fixes should be:
>
> - test your fixes on a checkout from the (new) Slicer3 trunk
> - point users to the nightly builds for testing
> - if the tests are good, merge the code to the Slicer-3-6 branch.
> - if the fixes apply to slicer4, they should also be merged to the
> Slicer4 trunk
>
>
>
> *Dashboards*
>
> Dashboard machines should point to the Slicer3 trunk for testing Slicer3
> or to the Slicer4 trunk for testing Slicer4 (see how much more logical
> that is?).  In the coming weeks we plan to set up a new set of nightly
> builds of Slicer4 on various platforms.
>
>
> *The future of the Slicer4 svn repository*
>
> In the coming months we will be stripping away the KWWidgets code from
> slicer4 as well as the getbuildtest build system (People should already
> be using the SuperBuild approach exclusively when building slicer4).
> There will be many more exciting improvements too.  Stay tuned...
>
>
> Hope this is all clear for the people who need to act on this info.
> Please send follow-up info or questions to the slicer-devel list.
>
> Thanks,
> Steve
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: [slicer-devel] important: repository changes for slicer4 and slicer3.6

pieper
Administrator
Interesting - I'll try a build too on mac and see what happens.

p.s. follow-ups to slicer-devel only ;)

On 09/23/2010 12:08 PM, Daniel Haehn wrote:

> Hi Steve,
>
> great work!
>
> I just checked out the new Slicer4 trunk and performed a SuperBuild. In general it worked fine!
>
> Unfortunately, I still had to compile python manually on my Mac (PythonQT enabled) to prevent the following error:
> [  0%] Built target vtkWrapHierarchy
> make[5]: *** No rule to make target `/Users/daniel/SLICER/QT_TRUNK/Slicer4-SuperBuild/python-build/lib/libpython2.6.dylib', needed by `bin/vtkWrapPython'.  Stop.
> make[4]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2
> make[3]: *** [all] Error 2
> make[2]: *** [VTK-prefix/src/VTK-stamp/VTK-build] Error 2
> make[1]: *** [CMakeFiles/VTK.dir/all] Error 2
> make: *** [all] Error 2
>
> Anyway, I updated the Slicer 4 Build instructions on the wiki:
> http://www.slicer.org/slicerWiki/index.php/Slicer4:Build_Instructions
>
> (I also updated the QT links to v4.7 which was released 2 days ago..)
>
> Daniel
>
> On Sep 22, 2010, at 2:50 PM, Steve Pieper wrote:
>
>> [Note: this is information is important for people using the slicer svn
>> repositories.  I cc'd slicer-users just to be sure I catch everyone who
>> is impacted - if you don't know/care what a slicer svn repository is,
>> feel free to ignore this message...  Followups and future messages on
>> this topic will go to slicer-devel only.]
>>
>> *Summary:* there is now a Slicer4 svn repository [1] which is a copy of
>> the Slicer3 trunk as of earlier today.  The Slicer3 existing trunk will
>> soon be used only for slicer 3.6 maintenance purposes.
>>
>> [1] http://svn.slicer.org/Slicer4
>>
>>
>> *Background:* Slicer4 [2] is a significant re-write of the user
>> interface to use Qt.  Along the way, several structural improvements to
>> the non-UI code are being made as well.  Until now, we had been
>> maintaining the ability to build either a KWWidgets-based GUI or a
>> Qt-based GUI on the same code base in the Slicer3 svn trunk.  Having
>> both Slicer3 and Slicer4 both hosted in a repository named "Slicer3" has
>> been, frankly, confusing.  But it was useful, since many changes
>> impacted both versions.  As the code has progressed this is no longer
>> needed so the two code streams will now diverge.  Essentially the
>> Slicer3 code will remain  stable with the exception of fixes for the
>> issues identified for fixes in the 3.6.x patch releases [3].
>>
>> [2] http://www.slicer.org/slicerWiki/index.php/Slicer4
>> [3] http://www.slicer.org/slicerWiki/index.php/Slicer3:3.6_Final_Issues
>>
>>
>> *Changes to the Slicer3 svn*
>>
>> By the end of the day today I expect to have the following layout in the
>> Slicer3 svn.  Please take care to adjust your practices accordingly.
>>
>> http://svn.slicer.org/Slicer3/oldtrunk - will be trunk at the time I
>> make the change (this is a backup as a place to find code that was
>> committed to the trunk after revision 15031 when the Slicer4 repository
>> was created).
>>
>> http://svn.slicer.org/Slicer3/trunk - will be a copy of
>> http://svn.slicer.org/Slicer3/branches/Slicer-3-6.
>>
>>
>> *Nightly builds*
>>
>> Recently the nightly slicer builds have been unstable because because
>> they were built from the Slicer3 trunk which included both bug fixes
>> intended for 3.6.x and reworked code intended for 4.  In the coming
>> weeks we will be start making two sets of nightly builds: one for
>> Slicer3.6.2-beta and one for Slicer4-alpha.  The "3.7" numbering from
>> the current nightly builds will no longer be used.
>>
>> The process for developers working on 3.6.x bug fixes should be:
>>
>> - test your fixes on a checkout from the (new) Slicer3 trunk
>> - point users to the nightly builds for testing
>> - if the tests are good, merge the code to the Slicer-3-6 branch.
>> - if the fixes apply to slicer4, they should also be merged to the
>> Slicer4 trunk
>>
>>
>>
>> *Dashboards*
>>
>> Dashboard machines should point to the Slicer3 trunk for testing Slicer3
>> or to the Slicer4 trunk for testing Slicer4 (see how much more logical
>> that is?).  In the coming weeks we plan to set up a new set of nightly
>> builds of Slicer4 on various platforms.
>>
>>
>> *The future of the Slicer4 svn repository*
>>
>> In the coming months we will be stripping away the KWWidgets code from
>> slicer4 as well as the getbuildtest build system (People should already
>> be using the SuperBuild approach exclusively when building slicer4).
>> There will be many more exciting improvements too.  Stay tuned...
>>
>>
>> Hope this is all clear for the people who need to act on this info.
>> Please send follow-up info or questions to the slicer-devel list.
>>
>> Thanks,
>> Steve
>> _______________________________________________
>> slicer-devel mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
>
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

convert DWI images into DICOM

Juan Francisco Garamendi
In reply to this post by Daniel Haehn
Hello Everyone,

Are there any way to convert a DWI set series loaded in Slicer into DICOM files? We think that module Converter->Create Dicom Series doesn't work with DWI,

Thanks in advance
Juanfran.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: convert DWI images into DICOM

swallace
Hi Juan Francisco,

We typically suggest that poeple convert their DWI datasets to nrrd format
in order to process them in Slicer.

Are there other reasons for converting them to DICOM?

Stuart



On Fri, September 24, 2010 10:48 am, Juan Francisco Garamendi Bragado wrote:

> Hello Everyone,
>
> Are there any way to convert a DWI set series loaded in Slicer into DICOM
> files? We think that module Converter->Create Dicom Series doesn't work
> with DWI,
>
> Thanks in advance
> Juanfran.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to
> [hidden email] with unsubscribe as the
> subject
>
>
>


--
Stuart
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: convert DWI images into DICOM

Isaiah Norton
In reply to this post by Juan Francisco Garamendi
Hi Juanfran,
That makes my head hurt :) The simple answer is: no, Create Dicom Series
module doesn't have this capability. The main issue is that the gradient
information must be included in the dicom header, and that module does
not know about or expose the proprietary tags used to hold this info
(this is vendor and even scanner-specific).

See here:
http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:DICOM_for_DWI_and_DTI

The medium answer is: if the target software supports *manual* entry of
the gradient and dimensions info, then you could split the DWI volume
nrrd file along the volumes axis, then convert each volume to dicom,
then import to program, then enter the gradients manually...... The DWI
volume header will look like this:

   NRRD0005
   content: epi-dti-asset
   dimension: 4
   sizes: 256 256 53 56
   ...
so need to split the volume along axis 4. The slicer disribution (at
least linux) has a tool called unu in //Slicer-2010-xyz/bin which will
do it, with a command like this: (note that 3 == axis 4 since it is 0-based)

"unu dice -a 3 -i epi-header-SB.nhdr -o test/volume-"

will give a set of ie 56 volumes (each 256x256 with each volume
corresponding to baseline or gradient.

(for unu see here:
http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:TeemExamples )

The hard answer is: yes, you could in principle create a dicom series
directly from the slicer dicom libraries, but you would need to program
the dicom header creation.

Note: if you just want to use some "derived" value, for example the FA
or Trace volume, then use the module Diffusion->Utilities->Diffusion
Tensor Scalar Measurements to create such a volume, then write it out
with the converter.

Hope that helps!

-Isaiah



On 09/24/2010 10:48 AM, Juan Francisco Garamendi Bragado wrote:

> Hello Everyone,
>
> Are there any way to convert a DWI set series loaded in Slicer into DICOM files? We think that module Converter->Create Dicom Series doesn't work with DWI,
>
> Thanks in advance
> Juanfran.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
>    

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: convert DWI images into DICOM

Xiaodong Tao-2
In reply to this post by Juan Francisco Garamendi
Hello Juanfran,

Right now there is no such function in Slicer. "Converter->Create Dicom Series" only exports limited and public-only image information into DICOM header.

What is the use case for converting a DWI dataset into DICOM series?

Thanks.
Xiaodong


-----Original Message-----
From: [hidden email] on behalf of Juan Francisco Garamendi Bragado
Sent: Fri 9/24/2010 10:48 AM
To: [hidden email]
Subject: [slicer-users] convert DWI images into DICOM
 
Hello Everyone,

Are there any way to convert a DWI set series loaded in Slicer into DICOM files? We think that module Converter->Create Dicom Series doesn't work with DWI,

Thanks in advance
Juanfran.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: convert DWI images into DICOM

Juan Francisco Garamendi
Hello,
Thanks Stuart, Isaiah and Xao for your answers. The reason why we need to save DWI volumes in DICOM format is that we preprocess  DWI images in Slicer3 (we filter it) and then we want to load that filtered DWI images into the Advantage Windows System (from GE). The only file format that Advantage Windows accepts is DICOM.

Thanks.
Juanfran.

El 25/09/2010, a las 04:03, Tao, Xiaodong (GE Global Research) escribiĆ³:

> Hello Juanfran,
>
> Right now there is no such function in Slicer. "Converter->Create Dicom Series" only exports limited and public-only image information into DICOM header.
>
> What is the use case for converting a DWI dataset into DICOM series?
>
> Thanks.
> Xiaodong
>
>
> -----Original Message-----
> From: [hidden email] on behalf of Juan Francisco Garamendi Bragado
> Sent: Fri 9/24/2010 10:48 AM
> To: [hidden email]
> Subject: [slicer-users] convert DWI images into DICOM
>
> Hello Everyone,
>
> Are there any way to convert a DWI set series loaded in Slicer into DICOM files? We think that module Converter->Create Dicom Series doesn't work with DWI,
>
> Thanks in advance
> Juanfran.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
>

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: important: repository changes for slicer4 and slicer3.6

ZX5B
This post has NOT been accepted by the mailing list yet.
In reply to this post by pieper
Is there any way to save file as DICOM in the current version of Slicer? We need to coregister MRI scans with DTI and export it as DICOM. Is that possible? Any thoughts will be appreciated.
Reply | Threaded
Open this post in threaded view
|

Re: important: repository changes for slicer4 and slicer3.6

ZX5B
Is there any way to save file as DICOM in the current version of Slicer? We
need to coregister MRI scans with DTI and export it as DICOM. Is that
possible? Any thoughts will be appreciated.

Zhiyuan
Reply | Threaded
Open this post in threaded view
|

Re: important: repository changes for slicer4 and slicer3.6

Xiaodong Tao-3
Hello Zhiyuan,

Slicer does have a module to create a dicom series (under Converters)
from a volume with only the absolutely essential dicom tags. Not sure
if that module meets your requirements.

Is there a reason that you have to save the processed images as DICOM files?

Xiaodong

On Wed, Jan 12, 2011 at 5:07 PM, ZX5B <[hidden email]> wrote:

>
> Is there any way to save file as DICOM in the current version of Slicer? We
> need to coregister MRI scans with DTI and export it as DICOM. Is that
> possible? Any thoughts will be appreciated.
>
> Zhiyuan
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/important-repository-changes-for-slicer4-and-slicer3-6-tp1563167p2244545.html
> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
>



--
Xiaodong Tao
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: important: repository changes for slicer4 and slicer3.6

Isaiah Norton-3
Hi Zhiyuan,

Is this for loading into a navigation system? For DTI scalar measure volumes the module Xiaodong mentioned should be all you need...

For tractography results overlaid on structural DICOM you could take the intersection of the tracts with each slice and set the intersected pixel to a suprathreshold value. There is a tool from ANSIR at Wake Forest to do something similar with fMRI from SPM. If this is what you want, I can give some help on it. We used to do something like this in slicer2 but we have a newer nav system now with built in dti processing.

-Isaiah

On Wed, Jan 12, 2011 at 5:19 PM, Xiaodong Tao <[hidden email]> wrote:
Hello Zhiyuan,

Slicer does have a module to create a dicom series (under Converters)
from a volume with only the absolutely essential dicom tags. Not sure
if that module meets your requirements.

Is there a reason that you have to save the processed images as DICOM files?

Xiaodong

On Wed, Jan 12, 2011 at 5:07 PM, ZX5B <[hidden email]> wrote:
>
> Is there any way to save file as DICOM in the current version of Slicer? We
> need to coregister MRI scans with DTI and export it as DICOM. Is that
> possible? Any thoughts will be appreciated.
>
> Zhiyuan
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/important-repository-changes-for-slicer4-and-slicer3-6-tp1563167p2244545.html
> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
>



--
Xiaodong Tao
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject