COMP: fixing error when instatiated with image of double

This patch is for the release branch.

Addressed compilation errors when images of double are turned on for
wrapITK.

Change-Id: I04c11dfd183dadbb7b9bdee13533365fba12ee7b
PERF: Faster distance computation and fixed reflective iterator bug

Sped up the distance map computation by ignoring non-zero values in
the original image. The goal of the distance map computation by
definition is to find the distance at every pixel that has a value of
zero to its closest non-zero neighbor.  Therefore, the non-zero
neighbor values can be ignored when solving for the distance map, but
the old version simply processed all pixels in the image.  When large
portions of the image are non-zero, this results in significant
overhead.  The new version simply ignores these non-zero values from
the original image.  Added a test to
itkDanielssonDistanceMapImageFilterTest.cxx that creates a 3D image
that is mostly non-zero.  The distance map computation before and
after this fix is the same, but the new version is about 30 times
faster.

Corrected a bug in the ReflectiveImageRegionIterator that resulted in
differences in the pixel value returned by an iterator and the pixel
value defined by image at the iterator index.  This is a bizarre bug
because calling "rit.Get()" gives a different result than
"myImage->GetPixel( rit.GetIndex())", where "rit" is the iterator
iterating over "myImage".  I added a test in
itkReflectiveImageRegionIteratorTest.cxx that checks these values
across the image, and this test fails.  However, with the new fix, it
passes, as expected.  The problem is that the m_PositionIndex is
incremented and then tested, but the m_Position is only incremented if
the test passes.  Thus, they become out of sync.  Now, the test checks
whether one past the current m_PositionIndex and then increments both
if the test passes.  Also, previously m_Position was not reset when
the iterator reached the end of a line even though m_PositionIndex was
reset; now m_Position is also reset.

Change-Id: I224ebc5b0814c17789be4fabf58a3280dc4bbb0c
BUG:  Voxel size scaling needed

The output of the exponential displacement filter had to be
rescaled to be on the order of the voxel size. Now the
registrations look reasonable coming out of the modified
antsRegistration.

BUG:  Second bug is unrelated involving an additional call
to UpdateTransformParameters which was producing unwanted
behavior.

Change-Id: Ia65b280e88ee0c32d39aa6889ee3a884415f654d
Merge topic 'FixWrapITKDoubleInstatiated'

9c01ef3 COMP: fixing error when instatiated with image of double
Merge topic 'ExpUpdate'

acf3f95 BUG:  Voxel size scaling needed
COMP: Revert use of itkLegacyMacro

The itkRigid3DTransform class was intended
to be an abstract base class for Rigid Transform
child classes that adds constraints to the SetMatrix
funciton.

In ITKv3 this class was often mis-used.  In our attempts
to maintain backwards compatibility/warn on use of legacy
code, and provide a forward clean path for ITKv4 this
base class has become very difficult to set the proper usage
on member functions that is compatible with all the desired
compilation options.

When ITKv3 compatibility is selected, the GetInverse and
GetInverseTransform functions must be traversed from
child classes, and are therefore part of protected interface
that can not be designated as itkLegacyMacro (otherwise warnings
are issued even though they are not called directly).

In ITKv4, they do not need to be defined at all because
they can simply use the MatrixOffsetBase class version
of those functions.

Change-Id: Id0651d1ecc5ada38470f139325883065e5e2cc53
ENH: Improve testing of GetInverse

GetInverse was not tested on some
of the Transform types.

Change-Id: Ic12e0086ac3aebc8f96fe7a6118fc89775f93744
Merge topic 'FixRigid3DCompilerWarnings'

072b6ee COMP: Revert use of itkLegacyMacro
COMP: WrapITK generates non-unique typedefs in FFT submodule

This topic is is intended for the release branch.

CMake generates the typedefs for wrapping support in
Wrapping\Modules\ITKFFT whereas these typedefs are not unique.

Aditionally I've found out that the underlying FFT implementation
supports only up to 4 dimensions.

To get rid of errors that are generated during compilation if
ITK_WRAP_DIMS are e.g. 5 or 6 an if construct was implemented.

Enable the instatiation of complex of double pixel by correcting the
itk_wrap_template types for FFT filters.

Change-Id: Ib639eddae51ec09f7f1cd37e02cdf58f1332ac63
COMP: fixing error when instatiated with image of double

This patch is for the release branch.

Addressed compilation errors when images of double are turned on for
wrapITK.

Change-Id: I04c11dfd183dadbb7b9bdee13533365fba12ee7b
PERF: Pull expensive GetInput/GetOutput calls out of inner loops

Between ITK3 and ITK4 a new scheme was set up for managing filter
inputs and outputs by name instead of by index.  This has made
the GetInput & GetOutput methods much slower. This has had a
serious performance penalty in several filters who call these
functions in inner loops.  In some cases this is a
straightforward fix, in others the input and output handles need
to be cached at the class level.

The fixes in this patch were accomplished by instrumenting the
ProcessObject methods and throwing an exception if they were
called an unreasonable number of times.  I started with a
threshold of 100,000 and after an initial pass, decreased this to
2000, at which point 'false positives' showed up.

Outstanding Issue:

PipelineMonitorImageFilter::PropogateRequestedRegion
Test Failure: itkJoinSeriesImageFilterStreamingTest
Solution: Cache pointers to input and output
Problem: Not sure where these could be initialized in such a way
that they would be updated if the input or output changed.

BinaryFunctorImageFilter::ThreadedGenerateData
Test Failure:  itkLabelMapContourOverlayImageFilterTest2
Solution: Cache input/output, possibly in BeforeThreadedGenerateData
Problem: I suspect that the test failure arises more from the
re-use of an instance of SubtractImageFilter, than any actual
problem of over-use.

WarpVectorImageFilter::GenerateInputRequestedRegion
Test Failures: itkDiffemorphicDemonsRegistrationFilterTests
(those numbered 01,02,03,04,05,06,07,09,10,11)
Solution: Not clear if one is needed; or if a simple fix is
possible.
Problem: itkExponentialDisplacementFieldImageFilter::GenerateData
uses a sort of a mini-pipeline; in a loop it re-uses the same
instance of WarpVectorImageFilter.  This racks up the count of
calls to GetInput/GetOutput in
WarpVectorImageFilter::GenerateInputRequestedRegion. It might be
good to go back and re-examine how this filter is built.

Change-Id: I2a92882098be6e8d026ff92d3de057f049b55cc7
COMP: WrapITK generates non-unique typedefs in FFT submodule

This topic is is intended for the release branch.

CMake generates the typedefs for wrapping support in
Wrapping\Modules\ITKFFT whereas these typedefs are not unique.

Aditionally I've found out that the underlying FFT implementation
supports only up to 4 dimensions.

To get rid of errors that are generated during compilation if
ITK_WRAP_DIMS are e.g. 5 or 6 an if construct was implemented.

Enable the instatiation of complex of double pixel by correcting the
itk_wrap_template types for FFT filters.

Change-Id: Ib639eddae51ec09f7f1cd37e02cdf58f1332ac63
Merge topic 'wrapITK-FFT-bugfix'

aae6b9a COMP: WrapITK generates non-unique typedefs in FFT submodule
Merge branch 'release'

Conflicts:
	Modules/Filtering/FastMarching/include/itkFastMarchingExtensionImageFilter.hxx

Change-Id: I4c38f2b38c2efe763571894e7e9356c5b2212d12
DOC: Modify VectorIndexSelectionCastImageFilter comments.

Author: joel.schaerer@gmail.com
Add a link to the converse filter

Change-Id: I43341a237f6cdcea2d194d05cb41762d0cc39ce9
DOC: Modify ComposeImageFilter comments.

Author: joel.schaerer@gmail.com
Add a link to the converse filter

Change-Id: I4afffde816cc69a9a9cb085a857b6a4893e88f01
STYLE: Refine usage of static_cast

1. Remove places where static_cast is used but isn't necessary.

The rationale is that if no static_cast is needed to make the
program work to programmer's expectations, it's just complicating
the code to no useful purpose.

2. Replace certain calls to static_cast with a call to a template
function defined in itkMacro.h that does a dynamic_cast and
checks the return value in Debug builds, but just does a static_cast
in release mode.

The rationale is that there are many cases (particularly those
associated with calls to ProcessObject::GetInput & GetOutput where
it is assumed that an object of the correct type has been stored
in the filter instance at a particular index.  A dynamic_cast
will catch any violation of that assumption, before the code gets
committed and deployed.

Change-Id: I9140704b33dbb42093265243e52e1ab39c4176a4
PERF:  Const correct optimize initialization.

Make variables const where available, and
use initialization over assignment.

Change-Id: Ibec019bb1744f02c898073ab00f5842eb14d97dd
Merge topic 'StaticCastCleanup'

00b1bbe STYLE: Refine usage of static_cast
BUG: Fix GCC_XML and SWIG ExternalProject dependencies.

The Ninja CMake generator is more demanding than the Unix Makefile generator.
Instead of implicitly specifying the GCC_XML and SWIG ExternalProject build
executables, we use CMake targets from the ExternalProject as DEPENDS.

This does not completely fix building WrapITK with the Ninja generator, but
makes a step.  It also improves building with other generators.

Also, remove some old code used when the repository was CVS or SVN.

swig-install project is created for win32 so dependencies are also working under
windows.
Additionally swigwin.exe is swig.exe

Change-Id: Ia487ab5909009bf4fb8c706fec3afecdfc4a415e