BUG: Only thread 0 should report progress.

The progress update observer is frequently used to update GUI
progress. The progress should only be updated by the main thread,
otherwise this common uses will segfault with the gui update.

The LabelMapFilter was updated with a manual update to the filters
progress, additionally the abort status is also check.

Change-Id: I1540ee5785a26b196524f51ac604d3bfcd18d0b0
PERF: Replace fill and copy with std alternatives

Use vcl_fill_n and vcl_copy, which are synonyms for std::fill_n
and std::copy, when possible in vnl_vector and vnl_matrix.

Filling vnl_vector using the std variant showed an increase in
performance with a factor between 1-10 for two different systems
(Win7 64bit VS2008 and Ubuntu Linux gcc 4.6.3), tested for short,
int, float and double, for array sizes between 1e2 and 1e7.
For relatively short sizes (<10) a decrease in performance was
noticed, but these operations are fast anyway.

Change-Id: I9e3284ebc1468c47eb84aee5f18165699a0ebbd6
BUG: Only thread 0 should report progress in LabelMapFilters

The progress update observer is frequently used to update GUI
progress. The progress should only be updated by the main thread,
otherwise this common use will segfault with the gui update.

The LabelMapFilter was updated with a manual update to the filters
progress, additionally the abort status is also check.

Additionally, the mutex lock was change to use a holder to follow the
Resource Acquisition Is Initialization (RAII), principle. If an
exception occurs the locked block, the lock will automatically be
released.

Change-Id: I001066f59cc336bc8f54ef7299e2f8a030f32ce8
COMP: Must reinterpret the pointers to match

complex<double> and double[2] types are compatible
memory layouts. The reinterpret_cast is used here
to make the "C" fftw libary compatible with the
c++ complex<double>.

Change-Id: I8eda7aa61d0dae4b16607cafcea6ec834d678a7b
PERF: couple of speed up improvements for QuadEdgeMesh processing

In QuadEdgeMeshBoundaryEdgesMeshFunction::Evaluate(), change a local
container from std::list<> to std::set<> to improve performance of removing
elements.

In QuadEdgeMesh, make use of GetElementIfIndexExists to avoid doing
too many ::find on the MapContainer.

Change-Id: Ic76674c64c3959f527e68b6c0ce9893deb0e1155
COMP: Adding missing header

WrapITK builds are getting a compilation error from
ProgressReporter not being defined.

Change-Id: I191a02acef380b560c4cd3cc752ec815a9a5f998
ENH: Allow block matching on diff size images

Allow block matching on images of different
dimensions.

Change-Id: Id1d6547b4714499614c1b3fca80b7981ede81326
STYLE: Enforce using ITK macros when available

During careful review of this calss, some ivars were identified
that could be removed and made local variables of one function.

Identified where a pointer could be made const.

Prefer initialization to assignment for class constuctor.

Logic for printing message about too many interations was moved
to the parent class where the other termination messages are appended
to build up the message string.

Change-Id: I4767db52c0979c85bdf1a482d809e30aa6d1191c
BUG: Using CMake variable in external builds with autoconf environment

Previously, the external projects of FFTW, SWIG and PCRE were affected
by environmental variable such as CC, CXX, CFLAGS etc. The could be
tested by setting CXX=/dev/null in the environment. Additionally,
these setting could change from when cmake was first run to when the
external project was (re)configured and compiled.

Now, the environment variable which effect the autoconf are not set in
via the "env" command before configuration.

Change-Id: Ie2d4f43c10d40186062a2e2917eff26b03b9815c
BUG: initialize InverseCovariance size with degenerate matrix

This patch fixes a segfault with VectorConfidenceConnected when used
with VectorImages and only one initial seed. This was caused by an
inverse matrix not being initialized correctly for variable length
measurement vectors.

Change-Id: I81bd2c9afe35f726d552c08849dd3c80710bca05
BUG: Fix InverseDisplacementFieldImageFilter bug

Further description can be found in jira issue (#3009).

A displacement field represent the displacement required to move from image1 to image2 :

image2_position = f(image1_position) + image1_position

Inverting such a field consist in estimating f^-1 such that
image1_position = f^-1(image2_position) + image2_position

at each location of image2 grid, while we in fact know f^-1 only at f(image1_position) + image1_position, which are most likely off image2 grid.

To do so, the InverseDisplacementFieldImageFilter makes use of Splines function, which will interpolate the displacement at image2 grid positions.

The spline transform is given source and target points from the function to estimate, which is f^-1. for each grid position in image1 :

    source point should be f(image1_position) + image1_position
    target point should be image1-image2 = -f(image1)

But in the filter code before this patch, we can read that source point given to the spline is only image1_position, not f(image1_position) + image1_position.

As a result, the inverse function estimated by the spline transform is wrong.

As asked in the review, the filter test has been modified to show the improper behaviour before the patch and the correct behaviour after the patch. Please note that the previous version of the test did not test for output validity, but only for correct execution (no regression testing on algorithm output).

As asked by the last review, I slightly rewrote the filter code to enhance readibility by avoiding confusion between landmarks and displacements.

Change-Id: Iddfb0a4332f12212feaec8a3e54f48c7ce41e272
COMP: Further changes to the use of std::copy_n

1. Add preprocessor test for condition (detected by David
Doria) where ITK was configured & built with a compiler that
supports C++11 std::copy_n, but a user program was not.

2. Small changes suggested by Bradley Lowencamp that didn't
make it into the last patch.

Change-Id: I1635cccc52b2dbf3621b896db9a139f33cda4fe2
COMP: Fix project linking against ITK that does not use VtkGlue.

The problem:

ITK is built with the ITKVtkGlue or ITKLevelSetsv4Visualization module enabled.
A project that uses ITK, but does not use VTK, does a

find_package(ITK REQUIRED)
include(${ITK_USE_FILE})

but if the VTK_DIR that was specified for ITKVtkGlue is at a build tree
location, CMake does not know where to find the VTK libraries.

The solution:

In the per-VTK-module export code, we should include VTKTargets.cmake so CMake
knows where to find the VTK libraries.  To do so, run find_package(VTK_DIR
NO_MODULE REQUIRED) with the VTK_DIR used during ITK configuration.

Change-Id: I6c74891f97da80c1b1ac352b8f7495439c80d610
ENH: Adding numeric_traits specializations for "long long"

This patch applies commits r34558 and r36873 from VXL upstream
authored by Brad King.

Change-Id: Ie233754645f3d4fc434578b5eb0871d3dd74c860
ENH: instantiate vnl types with "long long" on all platforms

This works toward portable instantiation of images with int64_t
types.

Change-Id: Id228cbd38794336898b0b0df06cf9524641d01b0
Revert "ENH: Use named inputs in BinaryReconstruction filters."

The reverted patch broke the method
ProcessObject::SetInput. Previously, filter->SetInput() would work for
setting the input images, it no longer does. SimpleITK uses this
method to set filter inputs. These filter silently compile and give a
run-time exception with the prior patch applied.

This reverts commit 285f3ac2d50c54803657458ee529a7c8ce602150.

Change-Id: I99fd84cbfc2da8714dbbb1343e3b8faf55ad4f29
WIP: Add single point precision to ITK transform

The current registration framework of ITK just can process transform
data using double precision.
However, in some cases base on our need, using 'float' type is enough
for the computations precision. This allows CPU to process more data
in its cache so increases the computations speed.

Yet one of the main obstacles to achive this goal is the definition of
"ParametersValueType" in the "itkTransformBase" class, which is hard
coded to 'double'.

This obstacle can be removed by changing the itkTransformBase class to
a template class named "itkTransformBaseTemplate<TScalar>" that TScalar
can be set to 'float' or 'double'.

As the "itkTransformBase" is at the top hierarchy of many other classes,
we should be careful to keep backward compatiblity.

Two groups of classes are important in this regard:
1- All transform classes because they are derived from the transformBase
class.
2- All the IO classes that are related to Reading/Writing transforms.

As all transform classes are already defined as a template over 'ScalarType',
the first group of files does not cause any incompatibility issue here.

To keep compatibility for the IO group classes, I have created the following
template classes:

I)   itkTransformBaseTemplate<TScalar>
II)  itkTransformFileReadTemplate<TScalar>
III) itkTransformFileWriteTemplate<TScalar>

Then the legacy IO classes are derived from the above classes as
follows:

itkTransformBase : Public itkTransformBaseTemplate<double>
itkTransformFileRead : Public itkTransformFileReadTemplate<double>
itkTransformFileWrite: Public itkTransformFileWriteTemplate<double>

Hence, by keeping these three classes as before, the backward
compatibilty will be maintained for the rest parts of ITK.

The second main obstacle is that "ParametersValueType" again is hard
coded as 'double' at "itkCostFunction" base class.

At the next phase, the definition of this class will be changed to a
template class over ScalarType, and the other modifications  will be
made to keep backward compatibility.

Change-Id: I6a3aee367c8c2e02fb49eb49860cf8ac9e59b3b7
WIP: Template version for Metric and Optimizer Classes

This patch is resulted by melting several commits together.

Metric and optimizer classes are redifined as templates over computation
type i.e. 'float' for single precision and 'double' for the double
precision.

A bunch of files have changed;

The computation type is added as a new template value
called "InternalComputationType". However, some of newly added
template values are called "ValueType". They should be changed
to more proper names like "ParameterValueType" or
"InternalCompuationType".

Metric and Optimizer classes are not derived from their template
version.
To keep the backward compatiblity, I have to keep the inheritance
hierarchy; therefore, I made a hierarchy of optimizer template
classes, and I kept the legacy hierarchy independent of that.
Backward compatiblity is met, ITK is compiling

The structure for ITKv3 has not changed.

ITK is built completely and all tests are passed after changes of this patch.

Change-Id: I8525555a01316ab60c3e36578d47955995bbefb6
WIP: Template version for TransformIO and TransformIOFactory classes

Change-Id: If55fcd401fcc9373cba2e0749e27e3c2fa4b2cd1