Build template normalize weights

[dyollb]

Fixes #729

This PR adds an option (default OFF) to re-normalize the contribution from each input image at a per-pixel level.
It also adds a helper method ones_like(img, pixeltype) along the lines of np.ones_like

[ntustison]

Thanks for all this. I haven't had time to look but will do so asap. Re. the normalization---how much have you coordinated with the template building scrips in the core ANTs repo, specifically antsMVTC.sh and antsMVTC2.sh?

[dyollb]

Thanks for all this. I haven't had time to look but will do so asap. Re. the normalization---how much have you coordinated with the template building scrips in the core ANTs repo, specifically antsMVTC.sh and antsMVTC2.sh?

not at all. I am not familiar with the scripts, but looking at them now I couldn't see the equivalent of the normalization I propose here. Basically, I am trying ensure the weighted sum up to one, for every pixel. As an example, if only half the images include the C3 vertebra, then without re-normalizing the intensity will be half of the "true average" intensity (for the C3 vertebra).

[ntustison]

If you haven't coordinated with the original scripts, I'd be inclined to recommend that you implement any normalization locally for your purposes.

However, I think the modification of deleting the temporary files is a good idea.

[stnava]

that should be optional - not a default. I've not looked at your implementation but you would be "changing the method" if you added this. eg you are implying that there is an underlying "partial matching" problem here and that is somewhat outside the assumption of the method. so the implication goes all the way back to the design of the objective function for template building. not sure you want to get into that with what should be a simple pull request. maybe you could do that 2nd.

[dyollb]

that should be optional - not a default. I've not looked at your implementation but you would be "changing the method" if you added this. eg you are implying that there is an underlying "partial matching" problem here and that is somewhat outside the assumption of the method. so the implication goes all the way back to the design of the objective function for template building. not sure you want to get into that with what should be a simple pull request. maybe you could do that 2nd.

I can split the PR so the temp file issue doesn't get mixed into the discussion.
Regarding the normalization question. I guess you could label it as partial matching, however unless you mask out adjacent body regions, you will surely always get some variability in the field of view. In my example above the C3 vetrebra is at the periphery of the region of interest. It just seems more correct to me, if the brightness does not decrease because of the variability in the field of view.

[stnava]

"more correct" is a different method. just keep this PR simple.

[dyollb]

"more correct" is a different method. just keep this PR simple.

I'm sorry if this sounded like a criticism of your tool. I really appreciate your great work and that it is openly available. That is why I am enthusiastic about contributing back.

Update: I have split the PR

• moved all temp file stuff to a different PR
• made the behavior optional and disabled by default

It's also ok if you prefer that this implementation does not diverge from your original scripts and papers.