[Insight-developers] DiffusionTensor3DReconstructionWithMaskImageFilter enhancement question.

Thu Jan 27 11:11:44 EST 2011

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
>> 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>
>> 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
>>> 
>>> 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
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110127/56bec963/attachment.htm>