[Insight-developers] fixing a few remaining failing tests relating to pixel-centered coordinates

Wes Turner wes.turner at kitware.com
Thu May 21 09:05:24 EDT 2009 

I think a warning makes sense until we have better validation.
Michel/Luis is this something that fits in with what you are doing?
- Wes

On Thu, May 21, 2009 at 8:37 AM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> Simon,
>
> My point is that we have not validated the new code as far as I can tell.
>
> Bill
>
> On Thu, May 21, 2009 at 7:57 AM, Simon Warfield
> <simon.warfield at childrens.harvard.edu> wrote:
> > Bill Lorensen wrote:
> >>
> >> Yes, I think that will be OK. We should add an Attention: warning to
> >> the CMakeLists.txt file. Something like:
> >>
> >>  SET(msg "Attention: You have chosen to enable the use of
> >> cell-centered coordinates.")
> >>
> >
> > The tool kit currently uses a mixture of both, so the above is a bit
> > misleading. How about instead:
> > SET(msg "Attention: You have chosen to enable the consistent use of
> centered
> > pixel coordinates.")
> >
> > We should explain the pros and cons of the choice e.g.:
> >>
> >>  SET(msg "${msg} This new functionality has not been fully validated.
> >> USE AT YOUR OWN RISK.")
> >>
> >
> > SET(msg "${msg} The old functionality creates an inconsistent physical
> > coordinate system.")
> >>
> >>  SET(msg "${msg} With this ON, you can expect to see differences in
> >> registration and interpolation results.")
> >>
> >
> > differences -> improvements
> >>
> >> # display the message during the setup
> >> MESSAGE("${msg}")
> >>
> >
> > --
> > Simon
> >>
> >> On Wed, May 20, 2009 at 11:23 PM, Wes Turner <wes.turner at kitware.com>
> >> wrote:
> >>
> >>>
> >>> Bill,
> >>> I think the idea is to disable the cell-centered functionality until
> >>> after
> >>> the release.  I.e. the code will be in, but not enabled in the CMake
> >>> options.  Is this an acceptable alternative?
> >>> - Wes
> >>> On Wed, May 20, 2009 at 7:20 PM, Bill Lorensen <
> bill.lorensen at gmail.com>
> >>> wrote:
> >>>
> >>>>
> >>>> I understand the current situation. I do believe however that we
> >>>> should validate the new techniques. Regression testing is meant to
> >>>> track changes in the code but they do not validate the code. Before we
> >>>> release ITK with these new capabilities I think we should make sure
> >>>> the code is correct. Even if this means we have to delay the release.
> >>>>
> >>>> Bill
> >>>>
> >>>> On Wed, May 20, 2009 at 1:57 PM, Michel Audette
> >>>> <michel.audette at kitware.com> wrote:
> >>>>
> >>>>>
> >>>>> Hi Bill,
> >>>>>
> >>>>> so far we are only modifying existing tests that were failing. The
> >>>>> following
> >>>>> tests include new code,
> >>>>>
> >>>>> Code/BasicFilters/itkExpandImageFilterTest.cxx:
> >>>>> Code/BasicFilters/itkVectorExpandImageFilterTest.cxx:
> >>>>> Code/Common/itkBSplineDeformableTransformTest2.cxx
> >>>>>
> >>>>> which assume pixel-centeredness. Moreover, many other tests have new
> >>>>> regression data committed, and ctest selects the appropriate data set
> >>>>> depending on the value of these flags.
> >>>>>
> >>>>> Best wishes,
> >>>>>
> >>>>> Michel
> >>>>>
> >>>>> On Wed, May 20, 2009 at 1:48 PM, Bill Lorensen
> >>>>> <bill.lorensen at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> Do we have a test that validates the centered pixel and portable
> round
> >>>>>> options? For example, a 1D example that can be manual verified.
> >>>>>>
> >>>>>> Bill
> >>>>>>
> >>>>>>
> >>>>>> On Wed, May 20, 2009 at 1:12 PM, Michel Audette
> >>>>>> <michel.audette at kitware.com> 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
> >>>>>>> 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.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Powered by www.kitware.com
> >>>>>>>
> >>>>>>> Visit other Kitware open-source projects at
> >>>>>>> http://www.kitware.com/opensource/opensource.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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Michel Audette, Ph.D.
> >>>>> R & D Engineer,
> >>>>> Kitware Inc.,
> >>>>> Chapel Hill, N.C.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Powered by www.kitware.com
> >>>>
> >>>> Visit other Kitware open-source projects at
> >>>> http://www.kitware.com/opensource/opensource.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
> >>>>
> >>>
> >>> --
> >>> Wesley D. Turner, Ph.D.
> >>> Kitware, Inc.
> >>> R&D Engineer
> >>> 28 Corporate Drive
> >>> Clifton Park, NY 12065-8662
> >>> Phone: 518-371-3971 x120
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>



-- 
Wesley D. Turner, Ph.D.
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x120
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090521/6d356c75/attachment.htm>

More information about the Insight-developers mailing list