COMP: Fix ambiguous specialization of GDCM Element

To disable certain combinations of template arguments to GDCM's
Element class, ambiguous declarations where added with no
definition. These combintations are causing compilations warnings such
as:

gdcmElement.h(611): warning #889: this partial specialization would
have made the instantiation of class "gdcm::Element<4096, 218367>"
ambiguous
  template <int TVM> class Element<VR::OB, TVM>;

While simply removing ambiguous declarations, would remove the
warnings this would not preserve the authors original intent to
prevent instantiation. To achieve a additional class was added with a
concept like check, to prevent instantiation.

Change-Id: I01c7d3f663a2e97804a465fb460d964542c6bf2d
BUG: LabelGeometry matrix difference tolerance

This patch relaxes the tolerance used to compare matrices so that the
tests will pass on very different OS versions.  It also corrects a
minor bug of default values causing compiler errors on some OS
versions.

Change-Id: I0866ec3597e7abafb418f3329a00bac8ca6be371
Merge topic 'LabelGeometryTolerance'

c3a6fb4 BUG: LabelGeometry matrix difference tolerance
ENH: Added progress reporting to Masked FFT NCC

Added progress reporting to the
itkMaskedFFTNormalizedCorrelationImageFilter. The progress reporting
is calculated based on the progress of the FFT and IFFT computations,
which are the most computationally expensive steps of the algorithm.
There are 12 FFT/IFFT computations in the algorithm.

This patch address JIRA ticket: ITK-3099

Change-Id: Icd6af337f15ae359ec5bf1ab5fe84200a0575ff2
Merge topic 'MaskedFFTProgressReporting'

f471f3d ENH: Added progress reporting to Masked FFT NCC
ENH: Adding a separate template parameter to handle transform precision

For now there is a confusion between interpolation precision and transform precision : the TInterpolatorPrecision template parameter is used as a template parameter for the transform as well.

It is therefore impossible to specify different type of precision for coordinate transforms and pixel value interpolation. This is hidden by the default template parameter, but may cause some trouble to use the ResampleImageFilter with exotic pixel types or interpolation, where the TInterpolatorPrecision is not a floating point scalar type.

The proposed patch adds a 4th template parameter called TTransformPrecision and use it to set-up the transform. It is set to double by default (as is the TInterpolatorPrecision paramater), so the patch is backward compatible with any code using the unpatched version (with 3 template parameters).

Change-Id: If5c39f19b6a287a3752f91063976f788951e0fd3
Merge topic 'fix-resamplefilter-precisions'

6ce2fc1 ENH: Adding a separate template parameter to handle transform precision
Merge topic 'FixGDCMAmbiguousSpecialization'

a54fad0 COMP: Fix ambiguous specialization of GDCM Element
BUG: Assert unchanged pixels only for non-PALETTE_COLOR images

Change-Id: I1781cf8cdcaf26a54311bf1bd7e2338230465e70
BUG: Add test case for GDCMImageIO

Change-Id: Ifd9bdc15145d47e0c2a2edd6d43e454152296f33
BUG: LabelGeometry improvements

This patch corrects the eccentricity, elongation, and orientation
features to operate on the largest eigenvector rather than eigenvector
1. This is the same thing for 2D but different in 3D and higher.

The orientation is also adjusted to always fall between 0 and pi
rather than -pi and pi.  This is possible since the major axis is
symmetric about the origin.  This also makes the orientation values
easier to read and more consistent.

A memory leak in the test was corrected by deleting the matrixPointer
allocated with new.

Change-Id: I12d0d952fe04df43edd118cffb2687f6896870e5
BUG: Preserve backwards compatibility with types

The decoupling of types for float and double presision
did not preserve backwards compatibility when only 3
template arguments were given.

Change-Id: I1d5c334bf74cac72693b29e0492f83032bb875d6
Merge topic 'LabelGeometryEnhancements'

9390d37 BUG: LabelGeometry improvements
ENH: fix std::string usage
Merge topic 'FixBackwardsCompatibilityInCornerCase'

3a47ad4 BUG: Preserve backwards compatibility with types
Merge topic 'GDCMImageIO-without-assert-on-PALETTE_COLOR'

26930bc BUG: Add test case for GDCMImageIO
178d712 BUG: Assert unchanged pixels only for non-PALETTE_COLOR images
PERF: Optimizer scale caching and avoid copy

PERF: The inverse of the scales was recomputed at each iteration
during the scaling process.  Cache the inverse values and use them
directly.

BUG: Zero scales should not be supported.  In the optimizers
a parameter scale of zero would result in a division by zero
in the parameter space.  This should be checked and an exception
thrown at the time of setting the parameters.

BUG: vnl optimizers may have a different type than the ITK parameters.
There is an InternalParameter type that should be used for parameters
that are propogated to the vnl_optimizers.

Change-Id: I4353d912f976ee4a6154b3c6b98b0b4d971bb04b
WIP: Support single precision registration

This is work related to https://issues.itk.org/jira/browse/ITK-108

The current registration framework of ITK just can process data using double
precision. However, in some cases using 'float' type is enough for the
precision of computations.

This feature allows CPU to process more data in its cache in a limited
period of time, so it can increase the computations speed.
Also, writing outputs to the disk using single precision needs much less memory
rather than we save them by values in double precision.
Saving the memory space is specially important when our outputs are huge
files that need hundreds of giga bytes of memory disk. An example of
such outputs is transforms files that contain several deformation fields.

We need a lot of changes in several files of ITK to make that consistent
with this new feature.
The following provides a short describtion of the main obstacles and the
ways that are used to tackle them:

I) One of the main obstacles to do the compuatations in single precision
is the definition of "ParametersValueType" in the "itkTransformBase" class,
which is hard coded to 'double'.

This issue can be solved by re-definition of the itkTransformBase class as
a template class over the internal computation type e.g.
"itkTransformBaseTemplate<ParametersValueType>". The template parameter
can be set to 'float' or 'double'.

Also, to keep backward compatiblity, we define the original
TransformBase after the definition of this new template class as:

>> typedef TransformBaseTemplate<double> TransformBase;

At the next levels of the hierarchy, we are not worried about the other
transform classes because they are already defined as a template over
the 'ScalarType', so the backward compatibility issues are automatically
solved for them.
Also for the IO classes that are related to Reading/Writing transforms,
we use the same procedure used for TransformBase class.

While backward compatibility is met, we can use this new set of classes
to write more flexible programs that can support both single and double precision
for their internal computations.

II) The second main obstacle is that "ParametersValueType" is hard
coded as 'double' in "itkCostFunction" base class.

Therefore, I changed all the Metric and Optimizer classes the same way that
I did for transform IO classes.

All these classes are modified in a way that minimum changes be needed
from the original version of ITK.
In many of them just a new template parameter is added as
"InternalComputationType" that is set to double as default.

PS: The new template versions of metric and optimizer classes are just
added to ITKv4.

Change-Id: If55fcd401fcc9373cba2e0749e27e3c2fa4b2cd1