[Insight-users] Debugging bspline registration

Wed Sep 15 09:55:12 EDT 2010

Bill,

Unfortunately, valgrind didn't identify any problems ...

I guess I would need to trim this down to a more simple test case to
be able to submit as a bug. I would still appreciate any suggestions
on how to investigate this.

Andrey

On Tue, Sep 14, 2010 at 08:47, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Looks like an unnitialized variable somewhere? Or accessing bad
> memory? Maybe valgrind will help.
>
> On Mon, Sep 13, 2010 at 7:21 PM, Andriy Fedorov <fedorov at bwh.harvard.edu> wrote:
>> Hi,
>>
>> I have a pair of 3D MRI images that I am registering using a custom
>> ITK registration code I developed. On one of the platforms I use, I
>> observe a very strange change in behavior of this code as a result of
>> a minor difference in the header of the input image. I've been trying
>> to understand this behavior for most of the day today ...
>>
>> Specifically, this minor difference is the following (from .nrrd header):
>>
>> Image1: "space origin:
>> (-79.285728454589872,-72.241912841796974,-38.198635101318366)"
>>
>> vs
>>
>> Image2: "space origin:
>> (-79.285728454589872,-72.241912841796989,-38.198635101318366)"
>>
>> (the last two decimal digits of the Y coordinate of the origin)
>>
>> If I choose Image1 as the reference image, I have a meaningful
>> registration result. If I choose Image2, I have the following painful
>> error message:
>>
>> File: /home/prostate/fedorov/Slicer-3.6-IGT/Slicer3-lib/Insight/Code/Review/itkOptMattesMutualInformationImageToImageMetric.txx
>> Line: 1077
>> Description: itk::ERROR:
>> MattesMutualInformationImageToImageMetric(0x7f1b0c3dbcc0): Too many
>> samples map outside moving image buffer: 634 / 100000
>>
>> All of the parameters of registration are otherwise identical (I run
>> both executions from the same command line just changing the reference
>> image). Some more technical details:
>>
>>  * The random number generator is initialized with the same seed
>>  * same number of threads (16) is used
>>  * my code uses multi-resolution registration approach going rigid ->
>> rigid+scaling -> rigid+anisotropic scaling -> affine -> bspline
>> transformation
>>  * I confirmed that the affine transformation that I set as bulk for
>> bspline gives good initial alignment.
>>  * I use masks for both images, and these masks overlap very well
>> after affine registration.
>>  * The bspline grid is coarse, 4x4x4 knots.
>>  * the metric is MattesMutualInformation
>>  * both images have non-identity direction cosines
>>  * code compiled in Release mode, gcc 4.4.1, Ubuntu 9.04
>>
>> When I look at the metric value during bspline registration, I see it
>> starts from the same values in both cases, but then diverges starting
>> at the third iteration:
>>
>> Image1:
>>
>> 0   -0.036445
>> 0   -0.0366935
>> 0   -0.0366935
>> 1   -0.0372417
>> 1   -0.0372417
>> 2   -0.0368946
>> 2   -0.0373551
>> 2   -0.0373551
>> 3   -0.030338
>> 3   -0.0373644
>> 3   -0.0373644
>> 4   -0.0319827
>> 4   -0.037446
>> 4   -0.037446
>> ...
>> 10   -0.0377343
>> 10   -0.0383924
>> 10   -0.0384768
>> 10   -0.0384857
>> 10   -0.0384966
>> 10   -0.0384927
>> 10   -0.0384966
>> 10   -0.0384966
>> 10   -0.0384966
>> 10   -0.0384966
>>
>> Image2:
>>
>> 0   -0.036445
>> 0   -0.0366935
>> 0   -0.0366935
>> 1   -0.0372417
>> 1   -0.0372417
>> 2   -0.0368945
>> 2   -0.0373552
>> 2   -0.0373552
>> 3   -0.030338
>> 3   -0.0373643
>> 3   -0.0373643
>> 4   -0.0319829
>> 4   -0.0374433
>> 4   -0.0374433
>> ...
>> 12   -0.0363308
>> 12   -0.0373945
>> 12   -0.037511
>> 12   -0.0375601
>> 12   -0.0375916
>> 12   -0.0375924
>> 12   -0.0375819
>> 12   -0.0375822
>> 12   -0.0375924
>> 12   -0.0375924
>> 12   -0.0375926
>> 12   -0.0375926
>> 12   -0.0375926
>>
>> When I compile the same code in Debug mode, bspline optimizer reaches
>> convergence without error independently of the image choice. When I
>> run the same example with 1 thread, I also have convergence and no
>> error.
>>
>> Interestingly, the number of iterations with 1 thread is different for
>> each of the transformation levels. BSpline converges in 6 iterations.
>> Also, execution time is very similar for 1 thread as it is for 16
>> threads (just ~1 minute!), with the registration results very similar
>> visually.
>>
>> The reason I came up with this degenerate case is that Image2 was read
>> and saved by a separate image visualization tool (3D Slicer) that uses
>> my code as a plugin. That execution initially failed with the error
>> message above. After a lengthy investigation I finally narrowed the
>> difference down to this discrepancy in the image header.
>>
>> How should I debug this problem? Is there a known open bug in ITK that
>> would explain this and/or inconsistency of the optimizers/metric
>> behavior depending on the number of threads?
>>
>> I tried 3.18 and 3.20 branches of ITK. I am running valgrind now to
>> find any possible leaks or data corruption, but this will take a
>> while.
>>
>> I would appreciate any hints.
>>
>> --
>> Andriy Fedorov, Ph.D.
>>
>> Research Fellow
>> Brigham and Women's Hospital
>> Harvard Medical School
>> 75 Francis Street
>> Boston, MA 02115 USA
>> fedorov at bwh.harvard.edu
>> (617) 525-6258 (office)
>> _____________________________________
>> 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://www.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-users
>>
>