"Uility extension for 3D Slicer containing tools and algorithms for building image guided surgery applications"

Today's build of SlicerIGSIO failed on Arch Linux, while it used to build seamlessly and there does not seem to have been commits since 10/12/2022.

CL/cl.hpp could not be found.

A quick and dirty fix has been editing IGSIO/CMakeLists.txt in the build tree as such :

include_directories(/opt/rocm/include /opt/rocm/opencl/include)

A better fix would be to allowing passing an OpenCL_DIR when configuring. As stated above, Arch Linux does not install these files in /usr/include.

Just a ping for a future improvement if you find it important.

Regards.

I was building slicer with SlicerIGSIO included and the build fails for VP9 with
CMake Error: Problem with archive_write_finish_entry(): Can't restore time

This is a known problem for some zip files https://gitlab.kitware.com/cmake/cmake/-/issues/19132

This was under VS2022 building on an external drive with exFat filesystem, so it does affect the libvpx_v1.12.0_msvc17.zip file, i don't know if the same issue exist for the other vs versions

After building latest Slicer, configuring of inner project fails

CMake Error at C:/d/Slcr/S4/Extensions/CMake/SlicerBlockAdditionalLauncherSettings.cmake:97 (string):
  string sub-command REPLACE requires at least four arguments.

Offending code is

  # External projects - library paths
  foreach(varname IN LISTS ${SUPERBUILD_TOPLEVEL_PROJECT}_EP_LABEL_LIBRARY_PATHS_LAUNCHER_BUILD)
    set(value ${${varname}})
    string(REPLACE "<CMAKE_CFG_INTDIR>" "\${CMAKE_CFG_INTDIR}" value ${value})
    list(APPEND EXTENSION_LIBRARY_PATHS_BUILD ${value})
  endforeach()

Do any of you guys know of a change in the Slicer level variable that might break this?

Performing update step for 'IGSIO'
Performing update step for 'libwebm'.
Since I downloaded the code manually, is it possible to disable the update?
most of the time, the SSL error occured..

Started failing on March 31st, probably related to CMAKE_OSX_DEPLOYMENT_TARGET (now 11.0).
Seems to be an issue with libwebm.
https://slicer.cdash.org/viewBuildError.php?buildid=2985304

We need to add support to markups ROI. It would allow specifying rotated ROIs.

error MSB6003: The specified task executable "rc.exe" could not be run. System.ComponentModel.Win32Exception (0x80004005): The filename or extension is too long

https://slicer.cdash.org/viewBuildError.php?buildid=2609910

Based on the error, it would seem that the issue may be the path or command length for the new calibration classes in IGSIO.

Reducing the path length in IGSIO hasn't had an effect yet. (IGSIO/IGSIO@cad184d, IGSIO/IGSIO@4bc46c5).

Slicer 4.11 compiled successfully.
And the IGSIO compiled successfully.
But as to the SlicerIGSIO compiling, only one error :
CMake Error at C:/Slicer/SlicerSource/Extensions/CMake/SlicerFunctionGenerateExtensionDescription.cmake:70 (message):
8> CMake variable EXTENSION_WC_REVISION is empty !
thanks for any help or suggestion.

MetafileImporter module was moved here from Sequences module (which is now part of Slicer core in Slicer-4.11). Now we have two modules for reading PLUS sequence files (image+transforms) from mhd and nrrd files.

SequenceIO is newer, it uses code from IGSIO instead of its own logic, and handles color images and compressed video. MetafileImporter might be faster in parsing large text files (tens of minutes of recording of 6-8 transforms).

Parsing speed of MetafileImporter and SequenceIO has to be compared on large files. If there is no significant difference then MetafileImporter module can be simply deleted. If MetafileImporter is much faster then its parsing code should be ported to IGSIO before the module is removed.

There is also a difference in what file formats are supported. MetafileImporter accepts seq.mha and simple .mha, but since these may interfere with plain volume sequence and volume reading, it is probably better not to offer these file extensions (keep current SequenceIO implementation).

This is not urgent, it is enough to work on this if a related issue comes up.

Could you associate the 3d-slicer-extension GitHub topic so that it is listed here: https://github.com/topics/3d-slicer-extension

To learn more about topic, read https://help.github.com/en/articles/about-topics

Hello,

SlicerIGSIO extension not show up in Slicer version 4.13.0 revision 30557 built 2022-01-26. I manually installed the 30117-win-amd64-SlicerIGSIO-git8f61201-2021-07-19.zip and run Slicer got the following errors.

Thanks

DLL load failed while importing vtkSlicerMetafileImporterModuleLogicPython: The specified module could not be found.
DLL load failed while importing vtkSlicerSequenceIOModuleLogicPython: The specified module could not be found.
DLL load failed while importing vtkSlicerVideoUtilModuleLogicPython: The specified module could not be found.
DLL load failed while importing vtkSlicerVolumeReconstructionModuleLogicPython: The specified module could not be found.
DLL load failed while importing vtkSlicerSequenceIOModuleMRMLPython: The specified module could not be found.
DLL load failed while importing vtkSlicerVolumeReconstructionModuleMRMLPython: The specified module could not be found.

When attempting to integrate SlicerIGSIO as part of a Slicer custom application, I was using SlicerIGSIO at specific commit d38a5a2. This commit specifies to use IGSIO's master branch

Can we set SlicerIGSIO to use a non-changing git tag of IGSIO so that a specific version of this extension can be included in a Slicer custom application?

cc: @Sunderlandkyl

Slicer's VTK has been updated and it no longer contains vtkSimpleCriticalSection. It seems it has been replaced by std::mutex.

SlicerIGSIO depends on vtkSimpleCriticalSection to implement vtkRecursiveCriticalSection and so its build fails and all extensions depending on it fails, too.

The problem may be resolved by either replacing vtkSimpleCriticalSection by std::mutex or std::recursive_mutex.

I am trying to access to Volume Reconstruction module logic so that I can automate the process using python.

I've observed in my Slicer custom application an issue with packaging due to SlicerIGSIO. I observed that in my "C:\MyCustomApp-build\Slicer-build\CPackConfig.cmake" that there was a vtkAddon section of CPACK_INSTALL_CMAKE_PROJECTS that when I removed it allow custom app packaging to not fail anymore.

set(CPACK_INSTALL_CMAKE_PROJECTS ";C:/SApp/IGSIO-build/inner-build;IGSIO;RuntimeLibraries;/;;vtkAddon;RuntimeLibraries;/;C:/SApp/OpenIGTLink-build;OpenIGTLink;RuntimeLibraries;/;C:/SApp/OpenIGTLinkIO-build;OpenIGTLinkIO;RuntimeLibraries;/;

Does vtkAddon runtime libraries actually need to be added as shown in the code below? Or is Slicer already including them with Slicer_BUILD_vtkAddon being on? Or is the vtkAddon_DIR not set appropriately as it appears to have been left blank in CPACK_INSTALL_CMAKE_PROJECTS?

Related SlicerIGSIO commits regarding vtkAddon:
fef9a39 and b0263b2.

Slicer switched to vtkAddon as remote project in Slicer/Slicer@aaf75e2.

cc: @Sunderlandkyl