FW4SPL 17.0.0 released

With fw4spl-deps, thre is now an option for each additional source repository that gather all required dependencies. So we introduce:

To achieve this we move some dependencies. cgogn, cryptopp, orbslam2 and vlc are promoted to fw4spl-deps. These dependencies are used widely so this seems reasonable. Now fw4spl-ext-deps only contains aram, so really experimental deps, making it useless for most people.

Some obsolete deps were removed:

Setting the CMake variable ADDITIONAL_DEPS was tedious and error-prone. Now we explore the folders at the same level of FW4SPL to find extra repositories. Then a CMake option, set to ON by default, is proposed to enable/disable the repository. This will make CMake configuration phase easier than ever !

In a similar way to what has been done for the dependencies, new we explore the folders at the same level of FW4SPL to find extra repositories. Then a CMake option, set to ON by default, is proposed to enable/disable the repository.

We still work hard to improve our integration of reading and writing DICOM images and segmentations. This time we added a reference to DICOM tags into fw4spl data, in order to use them to create back valid DICOM to save image and/or models.

A new SSignalShortcut service in fw4spl has been added. This service allows to map keys or combination of keys to the trigger of a signal.

We added a new ChArUco board activity calibration in ARCalibration:

We reworked the way we synchronize the video frames and the extracted data in real-time.

So far, we have made an extensive use of timelines. First the video grabbers store the frames in timelines. Then we process some algorithms on them and we store all the extracted data (markers, transforms, etc…​) in timelines as well. At the end, we rely on ::videoTools::SFrameMatrixSynchronizerto pick frames, matrices, etc…​ at the same timestamp and give these synchronized objects to the renderer, i.e. the generic scene.

However this does not work well. First this is very tedious to work with timelines, since we need to create a dedicated C++ class for each kind of data we want to manage. For some big data, like meshes, we never did it because this would consume too much memory. And some services are simply not well coded and work directly on the data instead of timelines, etc…​ Eventually, the renderer even screws up the synchronization since all updated objects request the rendering to be done.

So we propose a different approach here. First we restrict the usage of timelines to synchronize video grabbers together, for instance when you use a camera with multiple sensors or simply several cameras. After that point, all algorithm process the data directly. A new data ::arData::MarkerMapis introduced to store a list of markers, since this was the only "data" that only existed in a "timeline" version. To synchronize the results of the algorithms, we propose a new service called SSignalGate. This service waits for several signals to be triggered before sending itself a signal, which indicates everyone before is done. This service is typically used to inform the renderer that it must send everything to the GPU right now. To achieve this, we introduced a new rendering mode in ::fwRenderVTK::SRender.

You can try Ex04SimpleARCV which uses the new design, but for now everything is backward compatible. But we strongly encourage to have a look at this very soon and try to port your application to benefit of this improvement.

A new adaptor to display landmarks had been introduced. Quite basic for the moment but expect it to be improved in the next releases.

We changed the way the MImP IDVR countersink geometry (CSG) is defined/computed:

The service `::uiMeasurement::editor::Distance`was also cleaned a bit, and the unused configuration option 'placeInscene' was removed.