fwiiw, I have a similar (or the same!) issue when using BRAINS registration (here vtkMRMLScalarVolumeNode8 does indeed exist as a node), here it is itkImageFileReader that complains:

Found SharedObject Module
ModuleType: SharedObjectModule
Easy Registration (BRAINS) command line:

slicer:0x7f55356e1cb0 --processinformationaddress 0x7654940 --fixedVolume slicer:0x224b7d0#vtkMRMLScalarVolumeNode8 --movingVolume slicer:0x224b7d0#vtkMRMLScalarVolumeNode4 --linearTransform /tmp/Slicer/BFCGE_vtkMRMLLinearTransformNodeBC.h5 --useRigid --initializeTransformMode Off --initialTransform /tmp/Slicer/BFCGE_vtkMRMLLinearTransformNodeG.h5 --numberOfSamples 100000 --splineGridSize 14,10,12 --numberOfIterations 1500 --maskProcessingMode NOMASK --outputVolumePixelType float --backgroundFillValue 0 --maskInferiorCutOffFromCenter 1000 --interpolationMode Linear --minimumStepLength 0.005 --translationScale 1000 --reproportionScale 1 --skewScale 1 --maxBSplineDisplacement 0 --numberOfHistogramBins 50 --numberOfMatchPoints 10 --fixedVolumeTimeIndex 0 --movingVolumeTimeIndex 0 --medianFilterSize 0,0,0 --removeIntensityOutliers 0 --useCachingOfBSplineWeightsMode ON --useExplicitPDFDerivativesMode AUTO --ROIAutoDilateSize 0 --ROIAutoClosingSize 9 --relaxationFactor 0.5 --maximumStepLength 0.2 --failureExitCode -1 --numberOfThreads -1 --forceMINumberOfThreads -1 --debugLevel 0 --costFunctionConvergenceFactor 1e+09 --projectedGradientTolerance 0 --costMetric MMI

ERROR: In /home/kitware/Dashboards/Nightly/Slicer4/Base/QTCLI/vtkSlicerCLIModuleLogic.cxx, line 1725
vtkSlicerCLIModuleLogic (0x3f59220): Easy Registration (BRAINS) terminated with an exception:
itk::ImageFileReaderException (0x7f54ec0bb6f0)
Location: "unknown"
File: /home/kitware/Dashboards/Nightly/Slicer-build-64bits-QT4.7.4-PythonQt-With-Tcl-CLI-Release-nightly/ITKv4/Modules/IO/ImageBase/include/itkImageFileReader.hxx
Line: 143
Description: Could not create IO object for file slicer:0x224b7d0#vtkMRMLScalarVolumeNode8
The file doesn't exist.
Filename = slicer:0x224b7d0#vtkMRMLScalarVolumeNode8

Very probably a regression in ITKv4. This is currently discussed here: http://www.itk.org/pipermail/insight-developers/2013-April/022568.html

It has been confirmed and it is a regression in ITK. Patch is currently been reviewed [1]. Related discussion is [2]

[1] http://review.source.kitware.com/#/c/10645
[2] http://comments.gmane.org/gmane.comp.lib.itk.devel/1133

Fixed in r21859
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21859

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 0003008
Fixes 0003042

Closing resolved issues that have not been updated in more than 3 months