ENH: Add JRC2013 visualization tutorial test script

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21844 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: rearrange parameters to make the interface more user-friendly, see #3034


git-svn-id: http://svn.slicer.org/Slicer4/trunk@21845 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Fix bug where DWIconvert does not load images.

This patch attempts to resolve http://www.na-mic.org/Bug/view.php?id=3023#c8249
bug.  the problem is that DWIConvert does not use the ITK IOFactory mechanism
to write images, and therefore the standard ITK shared library mechanisms do
not work for passing images back and forth to slicer.

This is resolved by forcing Slicer to use a command line version of
DWIConvert rather than the shared libary version.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21846 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update version PythonQt to integrate latest fixes

The "patched-3" branch is rebased against r244 of PythonQt, it integrates
all backported changes specific to "patched-2" and also
include improvements by the upstream team. For a detailed list,
see https://github.com/commontk/PythonQt/compare/e2dce4...0a2486

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21847 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Add HAVE_PYRUN_{CLOSE, OPEN}FILE anticipating build against system python

Anticipating the possibility to build Slicer against a system python,
introduced variable HAVE_PYRUN_CLOSEFILE and HAVE_PYRUN_OPENFILE variable
to be able to conditionally build Slicer library with fopen/fclose
built-in the python library.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21848 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix DCMTK build error using a working implementation of DCMTKConfig.cmake

For details: See https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9

Revert commits r21842, r21841

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21849 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 2727. converted vtkMRMLNodeReference class into a proper VTK class. Converted std::string's into char *.  vtkMRMLNodeReference is now protected class inside vtkMRMLNode class.


git-svn-id: http://svn.slicer.org/Slicer4/trunk@21850 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: fixed compile errors for Linux and Mac related to the previous commit 21850

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21851 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update OpenIGTLink external projects to use github repository

See http://na-mic.org/Mantis/view.php?id=3037

Fixes #3037

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21852 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Disable ITK_AUTOLOAD_PATH/itkMRMLIDIOPlugin for executable CLIs

Follow up of commit r21440, unset environment variable ITK_AUTOLOAD_PATH
consistently:

Unset ITK_AUTOLOAD_PATH environment variable to prevent the CLI from
loading the itkMRMLIDIOPlugin plugin because executable CLIs read images
from file and not from shared memory. Worst the plugin in the CLI
could clash by loading libraries (ITK, VTK, MRML) other than the
statically linked to the executable.
Historically, there was an nvidia driver bug that causes the module
to fail on exit with undefined symbol.


// ------------------
This fixes the following error (Ubuntu 10.04 / gcc 4.4.3):

Error(s):
    CLI executable: /home/jchris/Projects/Slicer-AHM-Superbuild-Debug/Slicer-build/lib/Slicer-4.2/cli-modules/AddScalarVolumes
    /home/jchris/Projects/Slicer-AHM-Superbuild-Debug/Slicer-build/lib/Slicer-4.2/cli-modules/AddScalarVolumes: symbol lookup error: /home/jchris/Projects/QtSDK-1.2/Desktop/Qt/474/gcc/lib/libQtGui.so.4: undefined symbol: _ZN11QMetaObject11removeGuardEPP7QObject

    CLI executable: /home/jchris/Projects/Slicer-AHM-Superbuild-Debug/Slicer-build/lib/Slicer-4.2/cli-modules/AddScalarVolumes
    Failed to retrieve Xml Description

// ------------------
.. and also the following warnings (MacOSX 10.8.3 / Gcc 4.2.1):

Error(s):
    CLI executable: /Volumes/Dashboards/Experimental/Slicer-1-Superbuild-Release-cmake-2.8.11-rc1/Slicer-build/lib/Slicer-4.2/cli-modules/ProbeVolumeWithModel
    WARNING: In /Volumes/Dashboards/Experimental/Slicer-1-Superbuild-Release-cmake-2.8.11-rc1/ITKv4/Modules/Core/Common/src/itkObjectFactoryBase.cxx, line 514
/Volumes/Dashboards/Experimental/Slicer-1-Superbuild-Release-cmake-2.8.11-rc1/Slicer-build/lib/Slicer-4.2/ITKFactories/libMGHIOPlugin.so is already loaded

WARNING: In /Volumes/Dashboards/Experimental/Slicer-1-Superbuild-Release-cmake-2.8.11-rc1/ITKv4/Modules/Core/Common/src/itkObjectFactoryBase.cxx, line 514
/Volumes/Dashboards/Experimental/Slicer-1-Superbuild-Release-cmake-2.8.11-rc1/Slicer-build/lib/Slicer-4.2/ITKFactories/libMRMLIDIOPlugin.so is already loaded


// ------------------
This fixes the problem without explaining completely the underlying cause, more
investigation is required to have a clear understanding of the problem.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21853 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Ensure DCMTK_DIR is set in SlicerConfig.cmake

Introduced in r20634, the SlicerConfig variable DCMTK_DIR has never been
set. This commit fix this by updating SlicerGenerateSlicerConfig.cmake
and setting variable DCMTK_DIR_CONFIG.

Extensions should now be able to use variables DCMTK_LIBRARIES
and DCMTK_INCLUDE_DIRS directly after doing: find_package(Slicer)

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21854 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix installation of DCMTK apps on windows

Following commit r21849, DCMTK is used from the build tree and it is required
to specify the intermediate directory. Since package are made only in Release,
the value is forced to Release.

Ideally, dcmtk apps and library should be installed using DCMTK install
system by setting CPACK_INSTALL_CMAKE_PROJECTS.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21855 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Add option allowing to enable internationalization support.

STATUS
 Internationalization support has been discussed during March 26th 2013
developer hangout.

 We reach consensus: Official support for i18n will be disabled. A CMake
option named Slicer_BUILD_I18N_SUPPORT will be added and the option
won't be actively supported or tested.

 Why? Supporting internationalization properly would require to test
all ITK/VTK/Teem/.. readers and we don't have the funding or resources
to support that effort. If it is something you are interested in, make
sure to drop an email on the developer list. We will be happy to provide
 more information.

DISCUSSION
 http://slicer-devel.65872.n3.nabble.com/Re-Rounding-to-integer-tt4027985.html
 http://slicer-devel.65872.n3.nabble.com/Re-slicer-users-Slicer4-can-t-really-use-it-yet-td4028040.html
 http://slicer-users.65878.n3.nabble.com/Slicer4-DICOM-many-problems-td4025919.html

ISSUES
 3029 - Image spacing not read correctly in Slicer 4.2.2

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21856 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: 1318. Added FOV based on Volumes, resolution based on 2D View mode into reslice functionality

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21857 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Fix missing itkdouble-conversion library when using packaged Slicer

Update ITKv4 version to include ITK commit f228cd4

// ----------
COMP: The install path for DoubleConversion lib was wrong.

As reported by Vladimir Chalupecky, the install path for
double-conversion libraries was wrong. I fixed and tested
that, and used the ITK Module-generated path variables
instead of ad hoc variables local to the DoubleConversion
Module.

See https://github.com/Kitware/ITK/commit/f228cd4
// ----------

Thanks to Marianna Jakab for reporting the issue.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21858 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Restore functioning of CLI loadable module by fixing ITKv4 regression

Problem is summarize by the discussion posted on the ITK developer list
reported below.

// --------------
Question from Jean-Christophe Fillion-Robin:

Following commit 4c47e7d [1] of February 19th and commit defb9c1 [2] of
March 1st, due to static initialization, the initialization of
ObjectFactory  now happens when ITK shared library are loaded [3][4].

This caused a regression in Slicer where the ObjectFactory were expected
to be loaded while attempting to load an image for the first time.

In Slicer case, the environment variable ITK_AUTOLOAD_PATH was set during
the initialization of the qSlicerCoreApplication, which is now too late.

By commenting line where a new ImageRegionSplitterSlowDimension is
instantiated [5][6] and updating the method "GetImageRegionSplitter /
GetGlobalDefaultSplitter" to return 0 [7][8], the initialization can
happen on demand instead of when ITK libraries are loaded.

An easy solution for us would be to ensure the "ITK_AUTOLOAD_PATH"
environment variable is set in the application launcher for Windows
and Linux application and set in Info.plist file associated with
the application bundle on MacOSX [9]

To provide more details, within Slicer we set the CMake variable
ITK_NO_IO_FACTORY_REGISTER_MANAGER before doing an
"include(${ITK_USE_FILE}) so that IOFactory are loaded only by
calling the method "itkFactoryRegistration" associated with a
shared library we named ITKFactoryRegistration. This approach allowed
us to disable the automatic registration of factory in selected part of
 the code. More details here [10]

It seems the new ITK commits 4c47e7d and defb9c1 prevent from completely
leveraging the use of ITK_NO_IO_FACTORY_REGISTER_MANAGER variable, the
code should probably be updated to consider this.

[1] https://github.com/Kitware/ITK/commit/4c47e7d
[2] https://github.com/Kitware/ITK/commit/defb9c1
[3] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
[4] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkObjectFactoryBase.cxx#L142-144
[5] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L760
[6] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
[7] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L765
[8] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L32
[9] http://www.herzbube.ch/blog/2009/01/how-set-environment-variables-mac-os-x-applications
[10] https://github.com/Slicer/Slicer/commit/03b8961
// --------------


// --------------
Answer from Brad Lowekamp:

This is quite an interesting side-effect of the changes I introduced.

I am glad that you were able to figure this out. For a variety of
reasons, it's likely a very bad thing for all that to occur during
static initialization in ITK. So it certainly needs to be fixed.

I agree that lazy initialization is the way to go. Unfortunately it
needs to be thread safe so its a little more completed.

ITKv4 performs the factory initialization when the user creates the
first ITK object.  And that changed with this patch, and need to be
fixed.

CONCLUSION:

Inside ITK, we can not use statically initialized ITK object.
// --------------

Issues:
 http://www.na-mic.org/Bug/view.php?id=3042
 http://www.na-mic.org/Bug/view.php?id=3008

ITK discussion:
 http://comments.gmane.org/gmane.comp.lib.itk.devel/1133

ITK patch:
 http://itk.org/gitweb?p=ITK.git;a=commit;h=1679816baef6b95356d9afdd9bd4a481ca08556c
 http://review.source.kitware.com/#/c/10645/

Fixes #3008
Fixes #3042

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21859 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Ensure extension Experimental targets are associated to Experimental track

Thanks for Ryan Eckbo developer of the "UKF extension" extension
for reporting and helping investigating the problem.

This regression is a side effect of commit r21682 [1] where parameters
are now written into files like:
  <extension-name>-test-command-args.cmake
  <extension-name>-upload-command-args.cmake
  <extension-name>-upload-only-command-args.cmake

And the file are then passed to the ctest using argument:

   -DSCRIPT_ARGS_FILE:FILEPATH=<path-to-args-file>

The written file are used to create custom targets:
  Experimenal .............. using EXTENSION_TEST_COMMAND
  ExperimentalUpload ....... using EXTENSION_UPLOAD_COMMAND
  ExperimentalUploadOnly ... using EXTENSION_UPLOAD_ONLY_COMMAND
  Nightly .................. using EXTENSION_TEST_COMMAND
  NightlyUpload ............ using EXTENSION_UPLOAD_COMMAND
  NightlyUploadOnly ........ using EXTENSION_UPLOAD_ONLY_COMMAND

Since the same files were used unconditionally for both Nightly and
Experimental targets, the latest value of CTEST_MODEL was used because
the latest set of files to be configured was done with CTEST_MODEL equal
to "Nightly".

This commit explicitly specify the value -DCTEST_MODEL:STRING=${CTEST_MODEL}
for each target command. Doing so ensure each command is associated with
the appropriate track.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21682

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21860 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 3046. Fixed copy-paste error, use "transform" rather than "storage"

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21861 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: fix DWI loading in DICOM module by using DWIConvert module

Adapt to updates in DWIConvert by creating a target DWI volume
to store the output.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21862 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update build-system to use CMake'ified python

Latest stable version 2.7.3 is now used instead of ancient 2.6.6

Directory layout has been updated:
 - Python-2.7.3   : source
 - python         : build system
 - python-build   : build tree
 - python-install : install tree

Associated external project has been simplified. Removed unneeded
custom configure, make and install steps. Also removed unneeded
patch steps.

Note that the pythonrun.h and pythonrun.c are still patched in order
to prevent crash (related to dll boundaries [1][2]) when building Slicer debug
against a released python.

[1] http://stackoverflow.com/questions/2322095/why-does-this-program-crash-passing-of-stdstring-between-dlls
[2] http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/57e0d522-a42c-4add-963d-c87c6e76f161

Since only library located in the "lib-dynload" folder are not duplicated
in the "site-packages" folder, removed the exclude pattern
from the fixup script and update the candidate pattern to consider the
python extension located in lib/python2.7/lib-dynload folder.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21863 3bd1e089-480b-0410-8dfb-8563597acbee