[Insight-developers] fixing a few remaining failing tests relating to pixel-centered coordinates
Michel Audette
michel.audette at kitware.com
Fri May 22 18:16:48 EDT 2009
Hi Bradley,
thanks for your kind reply. Please elaborate, since whatever change in the
origin should also be made available to the iterator, no?
I am not getting a passing ImportImageContainerTest, although I thought that
I'd solved this. There seems to be a similar discrepancy as for
itkStreamingImageFilterTest2.
Best wishes,
Michel
On Fri, May 22, 2009 at 7:25 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>wrote:
> Hello Michel,
> This is because of the size of the image:
>
> ShortImage::SizeType size = {{42, 64}};
>
> When the origin is calculated in the ShrinkImageFilter there is an addition
> shift of 0.5 in the y position due to 64 not being divisible by 3. This is
> not compensated for in the calculation or row.
>
> Brad
>
> On May 21, 2009, at 7:25 PM, Michel Audette wrote:
>
> Hi Bradley,
>
> I committed 3 tests that no longer fail as a result of your suggestion.
>
> I've been looking at itkStreamingImageFilterTest2, and the same
> modification seems to come up short. Starting at line 138...
>
> #ifdef ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY
> for (; !iterator2.IsAtEnd(); ++iterator2)
> {
> short col = itk::Math::RoundHalfIntegerUp(shrink->GetShrinkFactors()[0]
> * iterator2.GetIndex()[0] +
>
> (shrink->GetShrinkFactors()[0]-1.0) / 2.0);
> col += colOffset;
>
> short row = itk::Math::RoundHalfIntegerUp(shrink->GetShrinkFactors()[1]
> * iterator2.GetIndex()[1] +
>
> (shrink->GetShrinkFactors()[1] - 1.0) / 2.0);
> row += rowOffset;
> short trueValue = col + region.GetSize()[0] * row;
>
> if ( iterator2.Get() != trueValue )
> {
> passed = false;
> std::cout << "Pixel " << iterator2.GetIndex()
> << " expected " << trueValue
> << " col " << col << " row " << row
> << " region.GetSize() " << region.GetSize()
> << " colOffset " << colOffset << " rowOffset " <<
> rowOffset
> << " but got " << iterator2.Get()
> << std::endl;
> }
> }
>
> #else
> for (; !iterator2.IsAtEnd(); ++iterator2)
> {
> short col = (shrink->GetShrinkFactors()[0] * iterator2.GetIndex()[0] +
> (shrink->GetShrinkFactors()[0] - 1) / 2);
> col += colOffset;
>
> short row = (shrink->GetShrinkFactors()[1] * iterator2.GetIndex()[1] +
> (shrink->GetShrinkFactors()[1] - 1) / 2);
> row += rowOffset;
> short trueValue = col + region.GetSize()[0] * row;
>
>
> if ( iterator2.Get() != trueValue )
> {
> passed = false;
> std::cout << "Pixel " << iterator2.GetIndex()
> << " expected " << trueValue
> << " but got " << iterator2.Get()
> << std::endl;
> }
> }
> #endif
>
> If you can spot something right away, that would be terrific.
> michel at michel-desktop:~/tools/Insight_ALL/InsightDebugBuildShared/Testing/Code/BasicFilters$
> ctest -R itkStreamingImageFilterTest2 -V
> UpdateCTestConfiguration from
> :/home/michel/tools/Insight_ALL/InsightDebugBuildShared/Testing/Code/BasicFilters/DartConfiguration.tcl
> Start processing tests
> UpdateCTestConfiguration from
> :/home/michel/tools/Insight_ALL/InsightDebugBuildShared/Testing/Code/BasicFilters/DartConfiguration.tcl
> Test project
> /home/michel/tools/Insight_ALL/InsightDebugBuildShared/Testing/Code/BasicFilters
> Constructing a list of tests
> Done constructing a list of tests
> Changing directory into
> /home/michel/tools/Insight_ALL/InsightDebugBuildShared/Testing/Code/BasicFilters
> 194/309 Testing itkStreamingImageFilterTest2 .
> Test command:
> /home/michel/tools/Insight_ALL/InsightDebugBuildShared/bin/itkBasicFiltersTests2
> itkStreamingImageFilterTest2
> Test timeout computed to be: 9.99988e+06
> Input spacing: 1, 1
> Output spacing: 2, 3
> *Pixel [0, 0] expected 42 but got 85*
> Pixel [1, 0] expected 44 but got 87
> Pixel [2, 0] expected 46 but got 89
> Pixel [3, 0] expected 48 but got 91
> Pixel [4, 0] expected 50 but got 93
>
> Once again, the bolded line at [0,0] has me questioning the value
> iterator2.Get(), which is according to m_ImportPointer in
> itkImportImageContainer.txx .
>
> Thanks for your kind contribution so far.
>
> Best wishes,
>
> Michel
>
> On Wed, May 20, 2009 at 11:40 PM, Bradley Lowekamp <blowekamp at mail.nih.gov
> > wrote:
>
>> Hello Michel,
>>
>> I am not sure of your changes to itkShrinkImageFilter. First your
>> calculation of the origin, does not appear to preserve the center of the
>> image, as the current implementation. The difference will be shown when the
>> size of an image is not divisible by the shrink factors. If I understand the
>> changes involved with the pixel-centered coors ( I may not ), it should only
>> affect the transformation to index not continuous coordinates. Therefore no
>> changes should be needed to the GenerateOutputInformation method.
>>
>> Second by setting the offsetIndex to 0, you are sampling in the at a
>> different location. This will sample in the corner as opposed to the
>> center.
>>
>> I have not run these filters with centered pixel coordinates enabled, but
>> the difference in the images should come down to the following. Consider
>> running the filter on an image with a 2x2 shrink factor and 0 origin an 1
>> spacing. The new spacing will be [2,2], and the new origin will be [0.5,
>> 0.5]. At which point we have the following code: (consider it with
>> outputIndex = [0,0], which then implies tempPoint =[0.5,0.5]
>>
>> // We wish to perform the following mapping of outputIndex to
>> // inputIndex on all points in our region
>> outputPtr->TransformIndexToPhysicalPoint( outputIndex, tempPoint );
>> inputPtr->TransformPhysicalPointToIndex( tempPoint, inputIndex );
>>
>> This is where the rounding of inputIndex has changed due to the use
>> of itk::Math::RoundHalfIntegerUp.
>>
>> So with the original ShrinkImageFilter this should work for the test:
>>
>> for (; !iterator2.IsAtEnd(); ++iterator2)
>> {
>> short col =
>> itk::Math::RoundHalfIntegerUp(shrink->GetShrinkFactors()[0] *
>> iterator2.GetIndex()[0] +
>>
>> (shrink->GetShrinkFactors()[0]-1.0) / 2.0);
>> col += colOffset;
>>
>> short row =
>> itk::Math::RoundHalfIntegerUp(shrink->GetShrinkFactors()[1] *
>> iterator2.GetIndex()[1] +
>>
>> (shrink->GetShrinkFactors()[1] - 1.0) / 2.0);
>> row += rowOffset;
>> short trueValue = col + region.GetSize()[0] * row;
>>
>> if ( iterator2.Get() != trueValue )
>> {
>> passed = false;
>> std::cout << "Pixel " << iterator2.GetIndex()
>> << " expected " << trueValue
>> << " but got " << iterator2.Get()
>> << std::endl;
>> }
>> }
>>
>>
>>
>>
>> On May 20, 2009, at 5:05 PM, Michel Audette wrote:
>>
>> Hi Bradley,
>>
>> thanks for getting back to me. What I'm working on is similar to what
>> we've implemented with itkExpandImageFilter.txx. I'm including my version of
>> the shrink filter up to now, as well as the test up to now, such as this
>> *(shrink->GetShrinkFactors()[0] - 1) / 2*) offset.
>>
>> I would like to get my mind around how the current test has worked up to
>> now, with grid-centered points, to get a better idea what to do with
>> pixel-centered points.
>>
>> I'll copy to Luis and Wes if that's okay with you.
>>
>> Cheers,
>>
>> Michel
>>
>> On Wed, May 20, 2009 at 4:50 PM, Bradley Lowekamp <blowekamp at mail.nih.gov
>> > wrote:
>>
>>> The real question is what should the correct value be? Is it a problem
>>> with the filter or the test?
>>>
>>> This is the kind of thing that has recently changed due the "desire" to
>>> maintain the physical center of an image:
>>>
>>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/BasicFilters/itkShrinkImageTest.cxx?root=Insight&r1=1.31&r2=1.32
>>>
>>> I think it's trying to compute the offsetIndex, in the transformation,
>>> here is what is going on in the ShrinkFilter:
>>>
>>> // an optimized version of
>>> // outputPtr->TransformIndexToPhysicalPoint(outputIndex, tempPoint);
>>> // inputPtr->TransformPhysicalPointToIndex(tempPoint, inputIndex);
>>> // but without the rounding and precision issues
>>> inputIndex = outputIndex * factorSize + offsetIndex;
>>>
>>> I know this filter was going to be problematic for the centered pixel transformation fix. I wish I new it was happening when I made the improvements to the Shrinker filter in April!
>>>
>>>
>>> Brad
>>>
>>>
>>> On May 20, 2009, at 4:21 PM, Michel Audette wrote:
>>>
>>> Hi Bradley,
>>>
>>> I'm looking at itkShrinkImageTest.cxx, and trying to get a handle on the
>>> logic. If you don't mind, can I ask you to comment on the bolded section
>>> below? Does the test try go find a transformation in a manner that assumes
>>> pixel-centered points and compensate for for pixels that were centered on
>>> intersections of the grid, or does it try to find the transformation between
>>> 2 sets of grid-centered points?
>>>
>>> bool passed = true;
>>> for (; !iterator2.IsAtEnd(); ++iterator2)
>>> {
>>> short col = (shrink->GetShrinkFactors()[0] * iterator2.GetIndex()[0]
>>> +
>>> * (shrink->GetShrinkFactors()[0] - 1) / 2*);
>>> col += colOffset;
>>>
>>> short row = (shrink->GetShrinkFactors()[1] * iterator2.GetIndex()[1]
>>> +
>>> *(shrink->GetShrinkFactors()[1] - 1) / 2);*
>>> row += rowOffset;
>>> short trueValue = col + region.GetSize()[0] * row;
>>>
>>> if ( iterator2.Get() != trueValue )
>>> {
>>> std::cout << "Pixel " << iterator2.GetIndex()
>>> << " expected " << trueValue
>>> << " but got " << iterator2.Get()
>>> << std::endl;
>>> passed = false;
>>> }
>>> }
>>>
>>> Best wishes,
>>>
>>> Michel
>>> On Wed, May 20, 2009 at 2:23 PM, Michel Audette <
>>> michel.audette at kitware.com> wrote:
>>>
>>>> Hi Bradley,
>>>>
>>>> I think that I'm reasonably close, although right now I'm busy setting
>>>> up and testing my cron job for the Dashboard. I'll come back to it later
>>>> this afternoon, and report back to you shortly.
>>>>
>>>> Cheers,
>>>>
>>>> Michel
>>>>
>>>>
>>>> On Wed, May 20, 2009 at 2:13 PM, Bradley Lowekamp <
>>>> blowekamp at mail.nih.gov> wrote:
>>>>
>>>>> I spent entirely too much time on the ShrinkImageFilter last month. I
>>>>> think I know exactly what s going on there. So if you are not close, I could
>>>>> look at 594, 615 and 615.....
>>>>>
>>>>> On May 20, 2009, at 1:12 PM, Michel Audette wrote:
>>>>>
>>>>> Dear members of the Insight Community,
>>>>>
>>>>> in response to bug 6558, Luis and I have implemented some changes that
>>>>> produce pixel-centered coordinates, as well as a few other needed
>>>>> refinements, which are enabled by the flags
>>>>> ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY,
>>>>> ITK_USE_REGION_VALIDATION_IN_ITERATORS and
>>>>> ITK_USE_PORTABLE_ROUND
>>>>>
>>>>> With the flags turned off, the code behaves as before, with no failing
>>>>> tests. With the flags turned on there are still a number of failing tests,
>>>>> that are related to these new coordinates, and which have been whittled down
>>>>> from more than 25 to 14 currently.
>>>>>
>>>>> Nonetheless, we would like to get rid of as many of these as we can by
>>>>> next Monday, for the upcoming release of ITK, and consequently, we would
>>>>> respectfully ask interested members of the community to lend a hand with the
>>>>> remaining tests.
>>>>>
>>>>> I will be submitting an Experimental ctest on a regular basis, with the
>>>>> signature metropolis-pixelcentered.kitware<http://www.cdash.org/CDash/viewSite.php?siteid=1585&project=2¤ttime=1242781200>
>>>>> Currently the failing tests are the following.
>>>>> 169 - itkSampleSelectiveMeanShiftBlurringFilterTest (Failed)
>>>>> 340 - itkMedialNodeCorrespondencesTest (Failed)
>>>>> 543 - itkImportImageTest (Failed)
>>>>> 572 - itkNonThreadedShrinkImageTest (Failed)
>>>>> 594 - itkShrinkImageTest (Failed)
>>>>> 615 - itkStreamingImageFilterTest2 (Failed)
>>>>> 630 - itkWarpImageFilterTest (Failed)
>>>>> 632 - itkWarpVectorImageFilterTest (Failed)
>>>>> 800 - itkMattesMutualInformationImageToImageMetricTest (Failed)
>>>>> 801 - itkMattesMutualInformationImageToImageMetricTest2 (Failed)
>>>>> 802 - itkMattesMutualInformationImageToImageMetricTest3 (Failed)
>>>>> 803 - itkMattesMutualInformationImageToImageMetricTest4 (Failed)
>>>>> 816 - itkMultiResolutionPDEDeformableRegistrationTest (Failed)
>>>>> 1470 - ResampleImageFilter9Test (Failed)
>>>>>
>>>>> I plan to work on failing tests relating to the itkShrinkImageFilter
>>>>> class.
>>>>>
>>>>> Thank you for your kind consideration.
>>>>>
>>>>> Best wishes,
>>>>>
>>>>> Michel
>>>>> --
>>>>> Michel Audette, Ph.D.
>>>>> R & D Engineer,
>>>>> Kitware Inc.,
>>>>> Chapel Hill, N.C.
>>>>>
>>>>>
>>>>> ========================================================
>>>>> Bradley Lowekamp
>>>>> Lockheed Martin Contractor for
>>>>> Office of High Performance Computing and Communications
>>>>> National Library of Medicine
>>>>> blowekamp at mail.nih.gov
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michel Audette, Ph.D.
>>>> R & D Engineer,
>>>> Kitware Inc.,
>>>> Chapel Hill, N.C.
>>>>
>>>>
>>>
>>>
>>> --
>>> Michel Audette, Ph.D.
>>> R & D Engineer,
>>> Kitware Inc.,
>>> Chapel Hill, N.C.
>>>
>>>
>>> ========================================================
>>> Bradley Lowekamp
>>> Lockheed Martin Contractor for
>>> Office of High Performance Computing and Communications
>>> National Library of Medicine
>>> blowekamp at mail.nih.gov
>>>
>>>
>>>
>>
>>
>> --
>> Michel Audette, Ph.D.
>> R & D Engineer,
>> Kitware Inc.,
>> Chapel Hill, N.C.
>>
>>
>>
>
>
> --
> Michel Audette, Ph.D.
> R & D Engineer,
> Kitware Inc.,
> Chapel Hill, N.C.
>
>
>
--
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090522/4b56facd/attachment.htm>
More information about the Insight-developers
mailing list