[Insight-users] Debugging bspline registration

Wed Sep 15 12:29:12 EDT 2010

Andriy,

Recall a while back we had some weird issues with registration running
as a shared lib versus an executable. I wonder if this is related to
that problem?

Bill

On Wed, Sep 15, 2010 at 9:55 AM, Andriy Fedorov <fedorov at bwh.harvard.edu> wrote:
> 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
>>>
>>
>