QuadDIRECT based registration

[Cody-G]

This supersedes #81

Major changes:

1. Added qd_translate and qd_affine

2. fixed handling of the sample spacing matrix SD: it must be updated between each pair of steps in a multi-step registration.

3. Stop recentering the output transform in the qd_* family of registration functions and update docs to encourage users to call centered on inputs

4. Add tests, strengthen test criteria

Some 3D affine registration tests don't pass reliably so I have commented them out. I spent some time looking into this and my suspicion is that when optimizing full affine transforms the mismatch objective function is especially prone to local minima for scaled versions of the images. So typically QuadDIRECT jumps directly to the most extreme scaling in the search space, and sometimes it gets stuck there and never finds the better, more moderate scaling. Typically it expands (rather than contracts) the moving image.

I have a guess at why it tends to do this: expanding moving means that there will be fewer pixels of overlap so the denominator of the mismatch will go down. Ideally the numerator would also go down proportionally (that's the whole purpose of the normalization, to get similar answers with many or few pixels of overlap). However since the moving image is expanded the space between overlapping pixels is larger than one pixel in the fixed image. This gives the algorithm an unwanted degree of freedom to work with: if a particular pixel in fixed can't be matched well then the moving image can be positioned to skip over that pixel so that it doesn't get compared to a moving pixel and never enters into the mismatch calculation. With larger scale factors the algorithm gets more and more freedom to avoid unwanted pixel comparisons.

This can be seen as a kind of aliasing, so one way that I could imagine addressing this particular issue is to lowpass filter the fixed image before comparing it to an expanded moving image. I'm not convinced this would solve all issues but it may help. Another idea is to address this by changing the default indices where warp gets evaluated so that the moving image gets oversampled and we avoid skipping pixels in fixed. I kind of prefer the second idea, but this seems to require that warp allow evaluations at non-integer indices which doesn't seem possible right now. Since neither of these seems extremely easy to implement I didn't include them in this PR.

And by the way I tried to reduce the runtime of the tests, but they're still taking 2 minutes on my laptop. Not sure how long that would take on Travis...

[Cody-G]

The Travis failure reminded me that I had to patch ImageTransformations. So these tests won't pass until https://github.com/JuliaImages/ImageTransformations.jl/pull/49 is merged and tagged.

[timholy]

Beautiful work! I don't see a single thing that should stand in the way of merging this. (Just to prove I read it, if you do have some good reason you need to fix/rebase/push again, you could use a space in "translation)to"---but totally not worth worrying about otherwise.)

Thank you so much for tackling this, this is a really spectacular contribution!

[timholy]

(Merge at will. I don't see a need to wait for ImageTransformations unless you want to be certain.)

[Cody-G]

Awesome, thanks for reviewing quickly! I'll merge and create an issue describing the aliasing issue from above so I don't forget.