[ITK-users] Can I alter the way SliceBySliceImageFilter defines the origin of the internal slices?

Discussion:

hellman

2017-09-08 13:31:31 UTC

Hi,

I am using the SliceBySliceImageFilter (to slice against the last dimension)
on a 3D image with the following meta data and region settings:

orign = [0, 0, 0]
direction = identity
spacing = [0.3, 0.3, 1]

all regions: index = [5, 5, 0] and size = [770, 710, 200]

The internal 2D images that are produced after slicing (let's call such an
image A) have the following meta data

orign = [1.5, 1.5]
direction = identity
spacing = [0.3, 0.3]

regions: index = [5, 5] and size = [770, 710]

The filter thus **redefines the origin** but keeps the index for the
internal images. This is a problem for me since the filter that I tell
SliceBySliceImageFilter to apply to the slices is a BinaryFunctorImageFilter
where the second input has been set to an image (let's call it B) with
meta-data:

orign = [0, 0]
direction = identity
spacing = [0.3, 0.3]

regions: index = [5, 5] and size = [770, 710].

I would like the the images A and B to have the same physical extent after
slicing. The BinaryFunctorImageFilter is an ImageToImageFilter where the
physical extent of the two images are verified to be the same by comparing
Origin, Direction, and Spacing (in function
ImageToImageFilter::VerifyInputInformation()). In my case, A and B do not
have matching origins (since SliceBySliceImageFilter redefined it), and thus
this verification fails.

Now, if SliceBySliceImageFilter would set the new origin to the projection
of the 3D origin onto the new 2D plane passing through the 3D origin, I
believe this would have worked. Can I make it not to have this default
behavior?

It does not appear like that from the code. The relevant code is on line 216
in SliceBySliceImageFilter.hxx for ITK 4.12.0:

Then, inputOrigin (except for the its last component in my case) is set as
the origin of the new internal inputs. I would like something like:

Perhaps there is a better way to do what I want to do? I am happy to hear
any thoughts on this.

Best regards,
Fredrik Hellman

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Matt McCormick

2017-09-08 13:45:36 UTC

Permalink

Hi Fredrik,

The Origin set by SlicerBySlicerImageFilter ensures that the slice
keeps its position in physical space.

An alternative approach to the issue encountered is to inherit from
BinaryFunctorImageFilter or SlicerBySliceImageFilter and override
VerifyInputInformation so it does not check the Origin.

HTH,
Matt

Post by hellman
Hi,
I am using the SliceBySliceImageFilter (to slice against the last dimension)
orign = [0, 0, 0]
direction = identity
spacing = [0.3, 0.3, 1]
all regions: index = [5, 5, 0] and size = [770, 710, 200]
The internal 2D images that are produced after slicing (let's call such an
image A) have the following meta data
orign = [1.5, 1.5]
direction = identity
spacing = [0.3, 0.3]
regions: index = [5, 5] and size = [770, 710]
The filter thus **redefines the origin** but keeps the index for the
internal images. This is a problem for me since the filter that I tell
SliceBySliceImageFilter to apply to the slices is a BinaryFunctorImageFilter
where the second input has been set to an image (let's call it B) with
orign = [0, 0]
direction = identity
spacing = [0.3, 0.3]
regions: index = [5, 5] and size = [770, 710].
I would like the the images A and B to have the same physical extent after
slicing. The BinaryFunctorImageFilter is an ImageToImageFilter where the
physical extent of the two images are verified to be the same by comparing
Origin, Direction, and Spacing (in function
ImageToImageFilter::VerifyInputInformation()). In my case, A and B do not
have matching origins (since SliceBySliceImageFilter redefined it), and thus
this verification fails.
Now, if SliceBySliceImageFilter would set the new origin to the projection
of the 3D origin onto the new 2D plane passing through the 3D origin, I
believe this would have worked. Can I make it not to have this default
behavior?
It does not appear like that from the code. The relevant code is on line 216
Then, inputOrigin (except for the its last component in my case) is set as
Perhaps there is a better way to do what I want to do? I am happy to hear
any thoughts on this.
Best regards,
Fredrik Hellman
--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.kitware.com/products/protraining.php
http://www.itk.org/Wiki/ITK_FAQ
http://public.kitware.com/mailman/listinfo/insight-users

hellman

2017-09-08 14:38:47 UTC

Permalink

Thanks for the quick reply!

(Btw, some code snippets disappeared from my first post, but they are not so
important).

Perhaps I missed something about the transformation to physical coordinates,
but this is my understanding:

The physical position P of the [5,5,0]-index pixel in the 3D volume
(according to my meta-data above) is:

P = O + D*diag(S)*Index = (0, 0, 0) + (0.3*5, 0.3*5, 1*0) = (1.5, 1.5, 0).

For a pixel in a different slice, say pixel [5, 5, 20], the physical point
is (1.5, 1.5, 20)

Now after slicing, the physical position (according to
SliceBySliceImageFilter) of the [5, 5]-pixel of any internal image created
by slicing is:

(recall new origin is (1.5, 1.5))

(1.5, 1.5) + (0.3*5, 0.3*5) = (3, 3).

The position of the [5, 5, 0]-pixel is thus (3, 3) after slicing, while it
was at (1.5, 1.5, 0) before slicing.
Similarly: The position of the [5, 5, 20]-pixel at (3, 3) after slicing,
while it was at (1.5, 1.5, 20) before slicing.

To me, it would make more sense for them to be at (1.5, 1.5).

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Matt McCormick

2017-09-08 14:56:11 UTC

Permalink

Yes, that description is correct, but the index of the slice set to
[0, 0] instead of [5, 5].

HTH,
Matt

Post by hellman
Thanks for the quick reply!
(Btw, some code snippets disappeared from my first post, but they are not so
important).
Perhaps I missed something about the transformation to physical coordinates,
The physical position P of the [5,5,0]-index pixel in the 3D volume
P = O + D*diag(S)*Index = (0, 0, 0) + (0.3*5, 0.3*5, 1*0) = (1.5, 1.5, 0).
For a pixel in a different slice, say pixel [5, 5, 20], the physical point
is (1.5, 1.5, 20)
Now after slicing, the physical position (according to
SliceBySliceImageFilter) of the [5, 5]-pixel of any internal image created
(recall new origin is (1.5, 1.5))
(1.5, 1.5) + (0.3*5, 0.3*5) = (3, 3).
The position of the [5, 5, 0]-pixel is thus (3, 3) after slicing, while it
was at (1.5, 1.5, 0) before slicing.
Similarly: The position of the [5, 5, 20]-pixel at (3, 3) after slicing,
while it was at (1.5, 1.5, 20) before slicing.
To me, it would make more sense for them to be at (1.5, 1.5).
--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.kitware.com/products/protraining.php
http://www.itk.org/Wiki/ITK_FAQ
http://public.kitware.com/mailman/listinfo/insight-users

hellman

2017-09-08 15:13:24 UTC

Permalink

I am not sure. In SliceBySliceImageFilter.hxx for ITK 4.12.0, on line 188, it
says:

// copy the requested region to the internal slice region in
// dimension order
unsigned int internal_i = 0;
for ( unsigned int i = 0; internal_i < InternalImageDimension; ++i,
++internal_i )
{
if ( i == this->m_Dimension )
{
++i;
}
internalOutputRegion.SetSize( internal_i, requestedSize[i] );
internalOutputRegion.SetIndex( internal_i, requestedIndex[i] );

internalInputRegion.SetSize( internal_i,
this->GetInput(0)->GetRequestedRegion().GetSize(i) );
internalInputRegion.SetIndex( internal_i,
this->GetInput(0)->GetRequestedRegion().GetIndex(i) );

}

This will copy all indices (except the slicing dimension) of input 0 to
internalInputRegion, which is set as the regions for the internal image
further down. In my case, the 5s get copied here.

I have also stopped in a debugger in ImageToImageFilter (of my
BinaryFunctorImageFilter) where the check that the physical regions overlap
is performed. At this point, both images have the same region index [5, 5],
but one image has origin (0, 0) and the sliced image has origin (1.5, 1.5).

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Matt McCormick

2017-09-08 19:08:52 UTC

Permalink

Yes, that is an issue -- good catch!

If we change:

internalOutputRegion.SetIndex( internal_i, requestedIndex[i] );

to:

internalOutputRegion.SetIndex( internal_i, 0 );

and

internalInputRegion.SetIndex( internal_i,
this->GetInput(0)->GetRequestedRegion().GetIndex(i) );

to:

internalInputRegion.SetIndex( internal_i,
0 );

is the behavior corrected?

Thanks,
Matt

Post by hellman
I am not sure. In SliceBySliceImageFilter.hxx for ITK 4.12.0, on line 188, it
// copy the requested region to the internal slice region in
// dimension order
unsigned int internal_i = 0;
for ( unsigned int i = 0; internal_i < InternalImageDimension; ++i,
++internal_i )
{
if ( i == this->m_Dimension )
{
++i;
}
internalOutputRegion.SetSize( internal_i, requestedSize[i] );
internalOutputRegion.SetIndex( internal_i, requestedIndex[i] );
internalInputRegion.SetSize( internal_i,
this->GetInput(0)->GetRequestedRegion().GetSize(i) );
internalInputRegion.SetIndex( internal_i,
this->GetInput(0)->GetRequestedRegion().GetIndex(i) );
}
This will copy all indices (except the slicing dimension) of input 0 to
internalInputRegion, which is set as the regions for the internal image
further down. In my case, the 5s get copied here.
I have also stopped in a debugger in ImageToImageFilter (of my
BinaryFunctorImageFilter) where the check that the physical regions overlap
is performed. At this point, both images have the same region index [5, 5],
but one image has origin (0, 0) and the sliced image has origin (1.5, 1.5).
--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.kitware.com/products/protraining.php
http://www.itk.org/Wiki/ITK_FAQ
http://public.kitware.com/mailman/listinfo/insight-users

hellman

2017-09-11 09:39:41 UTC

Permalink

I have been thinking a bit about this and realized this is slightly more
complex problem than I first thought.

Yes, as far as I can see, your suggested solution would (in my case) make
the physical extents of the internal image and the image input projected to
the XY 2D plane the same.

But the current implementation ((even) with this bugfix) has two problems:

1. The projection of the original 3D origin onto the XY plane does not
coincide with the new internal origin (there is nothing that says it should
be, but to me it seems natural).
2. If the Direction matrix if the input would not be identity, the physical
interpretation is unclear.

It would be nice to have a procedure to compute the internal image meta-data
that has some interpretation also when the Direction matrix is not identity.
There are some conceptual problems the whole procedure of going to a
3D-origin to a 2D-origin:

The input image 3D origin is defined in the physical frame of reference
(FoR), while the image data is indexed in a different FoR that can be
arbitrarily rotated with respect to the physical one, through the direction
matrix.

The SliceBySliceImageFilter slices in the index FoR and not in the physical
FoR. This means that any plane (or line for 2D input, or hyperplane for
higher dimensions) in the physical FoR can be the slicing plane. This in
turn means it makes no sense to favor certain physical dimensions as is done
in the current code. For example, just because we slice _index dimension 3_,
does not mean we should (as is done today) compute the origin coordinates of
the first pixel in physical coordinates and keep all physical coordinates
except the one corresponding to _physical dimension 3_ in the new origin. I
fail to see what is the physical interpretation of this.

One solution that has a clear physical interpretation is the following.
Consider the plane P orthogonal to the slicing dimension (spanned by the all
columns of the input Direction matrix except the sliced dimension)
intersecting the physical origin. The Direction matrix for the internal
image would be Identity. This means we choose the _index FoR_ as slice FoR
for expressing points in plane P in the slice. When considering a slice, the
Origin of this slice would be projected onto this plane P and it would be
expressed in the coordinates of the slice FoR. The Region from the input can
simply be copied to the internal image (except for the sliced dimension),
since it is just a matter of collapsing the sliced dimension.

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Matt McCormick

2017-09-11 15:24:28 UTC

Permalink

Yes, there are many ways handle the direction dimension collapse, and
it should be handled with care. If possible, we should follow the
behavior in ExtractImageFilter:

https://itk.org/Doxygen/html/classitk_1_1ExtractImageFilter.html

which has multiple options.

Thanks,
Matt

Post by hellman
I have been thinking a bit about this and realized this is slightly more
complex problem than I first thought.
Yes, as far as I can see, your suggested solution would (in my case) make
the physical extents of the internal image and the image input projected to
the XY 2D plane the same.
1. The projection of the original 3D origin onto the XY plane does not
coincide with the new internal origin (there is nothing that says it should
be, but to me it seems natural).
2. If the Direction matrix if the input would not be identity, the physical
interpretation is unclear.
It would be nice to have a procedure to compute the internal image meta-data
that has some interpretation also when the Direction matrix is not identity.
There are some conceptual problems the whole procedure of going to a
The input image 3D origin is defined in the physical frame of reference
(FoR), while the image data is indexed in a different FoR that can be
arbitrarily rotated with respect to the physical one, through the direction
matrix.
The SliceBySliceImageFilter slices in the index FoR and not in the physical
FoR. This means that any plane (or line for 2D input, or hyperplane for
higher dimensions) in the physical FoR can be the slicing plane. This in
turn means it makes no sense to favor certain physical dimensions as is done
in the current code. For example, just because we slice _index dimension 3_,
does not mean we should (as is done today) compute the origin coordinates of
the first pixel in physical coordinates and keep all physical coordinates
except the one corresponding to _physical dimension 3_ in the new origin. I
fail to see what is the physical interpretation of this.
One solution that has a clear physical interpretation is the following.
Consider the plane P orthogonal to the slicing dimension (spanned by the all
columns of the input Direction matrix except the sliced dimension)
intersecting the physical origin. The Direction matrix for the internal
image would be Identity. This means we choose the _index FoR_ as slice FoR
for expressing points in plane P in the slice. When considering a slice, the
Origin of this slice would be projected onto this plane P and it would be
expressed in the coordinates of the slice FoR. The Region from the input can
simply be copied to the internal image (except for the sliced dimension),
since it is just a matter of collapsing the sliced dimension.
--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.kitware.com/products/protraining.php
http://www.itk.org/Wiki/ITK_FAQ
http://public.kitware.com/mailman/listinfo/insight-users

Lowekamp, Bradley (NIH/NLM/LHC) [C]

2017-09-11 17:58:41 UTC

Permalink

I agree that filter has a nice option set for how to reduce the dimension of direction cosine matrix and update the physical coordinates. However, I would not try to re-implement or copy all those options and their implementations. If a new version of the filter was to be created, I’d recommend just reusing this recommended ExtractImageFilter in a mini-pipeline style composite filter.

Brad

On 9/11/17, 11:25 AM, "Matt McCormick" <***@kitware.com> wrote:

Yes, there are many ways handle the direction dimension collapse, and
it should be handled with care. If possible, we should follow the
behavior in ExtractImageFilter:

https://itk.org/Doxygen/html/classitk_1_1ExtractImageFilter.html

which has multiple options.

Thanks,
Matt

_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-u

hellman

2017-09-12 10:39:22 UTC

Permalink

I tried shifting the origin such that the input image had region index 0 and
then it worked.

I also applied the patch http://review.source.kitware.com/#/c/22601/ and now
it works also with non-zero region index in my case, so my particular
problem is solved by this patch.

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Lowekamp, Bradley (NIH/NLM/LHC) [C]

2017-09-12 19:09:23 UTC

Permalink

Thank you for testing the patch, and confirming the non-zero index was the cause.

The fix has been merged into ITK master.

Brad

On 9/12/17, 6:40 AM, "hellman" <***@gmail.com> wrote:

I tried shifting the origin such that the input image had region index 0 and
then it worked.

I also applied the patch http://review.source.kitware.com/#/c/22601/ and now
it works also with non-zero region index in my case, so my particular
problem is solved by this patch.

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users
_______________________________________________
Community mailing list
***@itk.org
http://public.kitware.com/mailman/listinfo/community

_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

Lowekamp, Bradley (NIH/NLM/LHC) [C]

2017-09-11 15:31:50 UTC

Permalink

Hello,

I few years ago I spent a bit of time with the SliceBySliceImageFilter to get the filter to “stream”. The way it was implemented was to expand the requested region of the output to the full size of the input’s in the non-slice-by-slice dimensions so that whole slices could be streamed through the filter. From your post, it may be the case that if the input image’s largest possible region starts with a non-zero index, then the computation of the origin per-slice is not proper. Can you please try to the filter with a zero-indexed input image?

I am not certain the previous prosed fix will work properly with streaming, and it may change the number of pixels in the regions…

However, for your case with an input image and an identity direction cosine matrix but with an non-zero largest possible index, it appears that the origin for the internal images is not correct. The non-zero index is a case that is not often checked by the ITK testing infrastructure, so I am not surprised it has a bug. Generally, it’s best to avoid such complex images with complex filters such as the SliceBySliceImageFilter. I have a proposed fix which may solve the problem for your case:
http://review.source.kitware.com/#/c/22601/

I need to add tests and verify this is proper. Perhaps, you can test it to see if it meets your needs and behaves as expected for you?

Also for reference here is the Slicer module I implemented which streams the SliceBySliceImageFilter. The streaming and proper geometry are critical for this application, so any changes made to this filter, I’ll need to ensure it still operates correctly.
https://github.com/blowekamp/Slicer-IASEM/blob/master/IASEMImportSeries/IASEMImportSeries.cxx

Brad

On 9/11/17, 5:40 AM, "hellman" <***@gmail.com> wrote:

I have been thinking a bit about this and realized this is slightly more
complex problem than I first thought.

Yes, as far as I can see, your suggested solution would (in my case) make
the physical extents of the internal image and the image input projected to
the XY 2D plane the same.

But the current implementation ((even) with this bugfix) has two problems:

1. The projection of the original 3D origin onto the XY plane does not
coincide with the new internal origin (there is nothing that says it should
be, but to me it seems natural).
2. If the Direction matrix if the input would not be identity, the physical
interpretation is unclear.

It would be nice to have a procedure to compute the internal image meta-data
that has some interpretation also when the Direction matrix is not identity.
There are some conceptual problems the whole procedure of going to a
3D-origin to a 2D-origin:

The input image 3D origin is defined in the physical frame of reference
(FoR), while the image data is indexed in a different FoR that can be
arbitrarily rotated with respect to the physical one, through the direction
matrix.

The SliceBySliceImageFilter slices in the index FoR and not in the physical
FoR. This means that any plane (or line for 2D input, or hyperplane for
higher dimensions) in the physical FoR can be the slicing plane. This in
turn means it makes no sense to favor certain physical dimensions as is done
in the current code. For example, just because we slice _index dimension 3_,
does not mean we should (as is done today) compute the origin coordinates of
the first pixel in physical coordinates and keep all physical coordinates
except the one corresponding to _physical dimension 3_ in the new origin. I
fail to see what is the physical interpretation of this.

One solution that has a clear physical interpretation is the following.
Consider the plane P orthogonal to the slicing dimension (spanned by the all
columns of the input Direction matrix except the sliced dimension)
intersecting the physical origin. The Direction matrix for the internal
image would be Identity. This means we choose the _index FoR_ as slice FoR
for expressing points in plane P in the slice. When considering a slice, the
Origin of this slice would be projected onto this plane P and it would be
expressed in the coordinates of the slice FoR. The Region from the input can
simply be copied to the internal image (except for the sliced dimension),
since it is just a matter of collapsing the sliced dimension.

--
Sent from: http://itk-users.7.n7.nabble.com/
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users

_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
ht