[Insight-developers] DiffusionTensor3DReconstructionWithMaskImageFilter enhancement question.

Fri Jan 28 10:19:54 EST 2011

I have a pretty good understanding of at least the broad outlines of how the filter works, if not the inner functioning of the algorithm.

I just need one simple question answered before I can rectify the weakness you perceived in my implementation, to wit:

Can I reserve an input index for the Mask Input?  If SetMaskImage is never called, and e.g. Input 1 isn't assigned, will the pipeline still work?

I'm not a huge fan of how this filter is implemented, but I'm trying to work with it as best I can to preserve backwards compatibility, and doing the minimum necessary change so as not to louse things up.

But as to how the filter works, I can explain:

There are two modes, where the Gradiant is a single image, or where the Gradient is several images.

Multiple Image Mode: Several Images are added using AddGradientImage.  The reference image is used as a normal brain scan, whose voxels are compared to a threshold. Voxels below the threshold are background and skipped when reconstructing tensors.

Single Image Mode:
The single gradient image is itk::VectorImage<GradientPixelType,3>.  In this case, the 'reference' image is computed from this GradientImage a voxel at a time in the main loop, and used for comparison with the threshold.

Internally this is handled in a somewhat convoluted manner:

Depending on whether SetGradientImage or AddGradientImage are called first, the mode is selected.   It's an error to call one and then the other.

Single Image Mode: Input 0 == the VectorImage representing the gradient.
Multiple Image Mode: Input 0 == the reference Image, Input 1...N the N Gradient Images.

In a normal filter, I could just set Input 0 (or the first N inputs) with the inputs, and test the number of inputs to see whether the mask image was input N+1.

In this case, I don't have the luxury of knowing how many inputs there are, and therefore it's difficult to know whether the mask input is present, and if I set the mask input before setting the Gradient Image(s), I don't know what mode the filter will be in.

On Jan 27, 2011, at 5:36 PM, Bradley Lowekamp wrote:

Hello Kent,

I am beginning to look a little closer at this filter. I have not used this class, and have only attended a couple of lectures on DTI, so not too familiar with the matter. But reading through the class it appears there are two modes of operation. So there is already some complexity there and adding additional permutations may be too much complexity. Currently, there could be a vector image or a set of scalar. But what is the reference image used for? It looks like it can be used as a mask for one of the cases. This appears to be controlled by the Threshold parameters. It may be that this feature just needs to be extended to the case when just a vector image is provided. So adding another image may not actually be needed.

It sounds like a consultation with someone more familiar with this filter is really needed to determine what is the best approach.

Brad

On Jan 27, 2011, at 2:02 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

On Jan 27, 2011, at 12:01 PM, Williams, Norman K wrote:

Yeah what you're saying make's sense.  So before starting, verify size, spacing, directions and origin are the same? Or would it be enough to just verify the size is the same and document up front that the masks need to be in the same space?

Checking that the index and spacing match what is needed should be enough to prevent catastrophic failure.  I would likely just check that the largest possible region of all inputs match.

The latter approach would have the advantage of working with synthetic masks created by a user who might neglect to set the origin, spacing, and directions.

Perhaps just printing a warning in this case? I don't think that we should really let people get away with that type of carelessness.

I think a function to do this full comparison would be very useful, and would be a good reusable method. Perhaps adding to ImageBase?

Looking at the source code, it's set up to be threaded, but it has this comment at the top:
//
// Until we fix netlib svd routines, we will need to set the number of thread
// to 1.

That is what I read and why I said it was single threaded. Is the SVD method still not compatible with multithreading? My other 23 cores would feel very left out if I used this filter.

Brad

On Jan 27, 2011, at 10:11 AM, Bradley Lowekamp wrote:

Hello Kent,

I would make the argument that all mask images should be in the same coordinates as the images they are trying to mask. And that this should be verified at run-time, and if false an exception should be thrown. There may be some details of this particular algorithm I don't understand but it appears to be just an advanced point-wise operation(?).

Essentially what you are integrating into the filter is a reimplementation of a resample image filter with the nearest neighbor interpolant. This has the usual potential issues of aliasing during resampling, which are exacerbated by the fact that the image being interpolated is essentially a binary images. I do not believe this resampling should be hidden or implicit from the user. By requiring the images to be concurrent, the user is forced to deal the issue of resampling directly.

Additionally, I would imaging that the usual usage is to have the images being congruent. This additional transformation needlessly penalizes then common use case. Reading the documentation of the regular DiffustionTensor3DReconstructionImageFilter, it says that the filter is single threaded. This would exacerbate this penalty as well, while a separate ResampleImageFilter would be multi-threaded and more efficient.

On Jan 27, 2011, at 10:43 AM, Williams, Norman K wrote:

The MaskImageFilter makes the assumption that I'm trying to avoid, that the mask and the input image are identically oriented in space, have the same spacing and the same size.

If it is OK to make this an implicit precondition for the mask image for the DiffustionTensor3DReconstructionImageFilter,  it would make the code much simpler, but since there's no (simple) way to enforce this, we'd just be crossing our fingers and hoping for the best.

Why can you not check this during the execution of the filter? check that the size, spacing origin etc match up...?

On a side note, I have argued for a new method in the standard pipeline called "VerifyInputsAndParameters" (or something similar). This would be the perfect place to add this type of check along with the common tasks of making sure the input and outputs are not null, and parameters of with in range etc.

As it happens the overhead of working in physical space is probably less than that of calling the solver for voxels of no interest.

On Jan 27, 2011, at 9:12 AM, Magnotta, Vincent A wrote:

Kent,

My lazy solution would be to use the MaskImageFilter and then just iterate
though the image. I am not sure how it handles the size correspondence
between the mask and image, but would allow us to potentially implement a
solution and only one filter that could be reused many places.

Vince

--
Associate Professor
Department of Radiology
0453-D JCP
200 Hawkins Drive
Iowa City, IA 52242
E-mail: vincent-magnotta at uiowa.edu<mailto:vincent-magnotta at uiowa.edu>
Phone: 319-356-8255 Fax: 319-353-6275
Website: http://www.healthcare.uiowa.edu/Radiology

On 1/27/11 8:58 AM, "Williams, Norman K" <norman-k-williams at uiowa.edu<mailto:norman-k-williams at uiowa.edu>>
wrote:

I am in the process of adding a mask input to
itk:DiffusionTensor3DReconstructionWithMaskImageFilter.

Currently, there is a threshold parameter, so that it ignores voxels in
the reference image with values below the threshold.  What I'm adding is
some code at the same point to look up the corresponding voxel in a mask
image.

The problem is that at that point in the filter, it's stepping through
the image with an ImageRegionConstIterator.  I could use an
ImageRegionConstIterator to step through the mask at the same time, but
the filter can't no for a fact that the mask and the reference image are
congruent in space.  So I'm doing this:

     ItIndexType index(it.GetIndex()); // get index from reference
image iterator
     MaskImageType::PointType pt;
     refImage->TransformIndexToPhysicalPoint(index,pt); // find
physical point for index

     MaskImageType::IndexType maskIndex; // find index in mask from
physical point
     this->m_MaskImage->TransformPhysicalPointToIndex(pt,maskIndex);
     MaskImageType::PixelType pix =
       this->m_MaskImage->GetPixel(maskIndex);

This seems to be the right thing to do, but it has to add considerable
overhead compared to a ImageRegionConstIterator. Is there a better way to
do this?

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by
the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
confidential and may be legally privileged.  If you are not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution, or copying of this communication is strictly prohibited.
Please reply to the sender that you have received the message in error,
then delete it.  Thank you.
________________________________
_______________________________________________
Powered by www.kitware.com<http://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://kitware.com/products/protraining.html

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://www.itk.org/mailman/listinfo/insight-developers

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
_______________________________________________
Powered by www.kitware.com<http://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://kitware.com/products/protraining.html

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://www.itk.org/mailman/listinfo/insight-developers

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>

<ATT00001..txt>

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110128/23c74f84/attachment.htm>