[Insight-developers] DiffusionTensor3DReconstructionWithMaskImageFilter enhancement question.

Thu Jan 27 14:02:46 EST 2011

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

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