I’m trying to compile the example ImageRegistration8.cxx for WebAssembly without success. I have followed the tutorial in https://wasm.itk.org/tutorial/inputs_outputs and it works correctly. However, when I follow the same steps for ImageRegistration8.cxx I get some errors when launching
A example of the errors I get:
" … /ITK/Modules/Registration/Metricsv4/include/itkMattesMutualInformationImageToImageMetricv4GetValueAndDerivativeThreader.hxx:210:35: error: no member named ‘m_JointPDFDerivativesLock’ in ‘itk::MattesMutualInformationImageToImageMetricv4<itk::Image<float, 3>, itk::Image<float, 3>>’
&this->m_MattesAssociate->m_JointPDFDerivativesLock, …"
I suppose that the problem comes from the CMakeLists.txt file I use (see attached files), could anybody tell me what I am doing wrong?:
One way to debug this is to build ITK with just the components you declared as your dependencies. In CMake, turn off ITK_BUILD_DEFAULT_MODULES, and group Core, then enable these individual modules. Does your project build against such trimmed-down ITK?
Hi Dzenanz,
Sorry but, i understand that itkwasm/wasi docker image contains ITK build and i don’t have the hand on ITK build options. But maybe I didn’t understand your answer ?
Hi, here is the result:
By disabling ITK_BUILD_DEFAULT_MODULE and ITKGroup_Core, the imageRegistration8 sample does not work.
To make it work, it was necessary to activate the following modules:
-ITKGroup_IO
-ITKGroup_Registration
On the other hand, I modified the CMakeLists.txt to remove all the dependent modules and add the path of ITK-build so that it works.
1/ Cool, everything works with cmake locally, but now what should be done to make it work with ITK-WASM?
2/ Is it possible to modify the optional modules in itkwasm/wasi docker container itk-build?
3/ Are the examples provided in the kit all supposed to work?
The proper solution is to list ALL the dependent modules in the list. When compiling programs for the web, we should be careful about not including unnecessary libraries.
Enabling entire groups in your ITK build is not overly helpful in identifying the exact dependent module. WhatModulesITK.py script should be helpful with that. Also take a look at this thread.
If you build ITK with only these modules turned on, does the example with against it? I would like to eliminate this variable before needing to look into the wasi build process.
You are not doing anything wrong – improvements are required to make the Metricsv4 code used in ImageRegistration8.cxx work with the WASI toolchain
There is a bit of documentation on how to build / test / contribute to the WASI toolchain in the Docs → Development → Hacking itk-wasm section of the itk-wasm documentation.
I created an example from ImageRegistration8, called it mean-squares-versor-registration, addressed the associated build issues, and added it to our CI testing in this PR.
The example will build / run / produce the same output as a native build, although it is currently not the fastest (we will add multi-threading) and there is a backtrace that occurs on exit – we will work on these.
Are there good practices that we must respect to make a web assembly dev? For example, I see the mean-squares-versor-registration example has different code than ImageRegistration8.
Can an example that works in server side always work in web assembly?
I am asking because currently if running the wasi build on ImageRegistration8 from the kit then I am getting errors.
For WASI builds, nearly all the IO’s are supported but HDF5 ImageIO is currently not supported. I see GDCM related errors, although we do have GDCM WASI ImageIO.
I general, it is best to not build support for all the ImageIO code into wasm executable – it bloats their size. If possible build support for only the IO’s needed. Or, use the dedicated IO modules, built with,
npm run build:wasi
and found in dist/wasi-image-io/. Eventually these will be distributed in a registry (once it is available ).
Convert the images from their original format to .iwi.cbor, which is supported by all WebAssemblyInterface modules.
