CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2024-03-25T18:19:08+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/183Update Windows toolchain and docker fo CI2024-03-25T18:19:08+01:00Emmanuel PromayonUpdate Windows toolchain and docker fo CI| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CE...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CEP developer on Windows |
| **I would like to** | have a simpler way to install the toolchain and develop my extension |
| **So that** | I spend less time on the setup and have less difficulties to develop on Windows |
## Description / Overview
Windows setup is fastidious and can have side effect on the installation (or the local installation can have side effect on the CEP development, e.g. installation of some LaTeX software provides Qt DLL that conflict with the CamiTK setup).
Some package/dev environment setup systems exist on Windows
- [msys2](https://www.msys2.org/) has an [extensive list of available packages](https://github.com/msys2/MINGW-packages), and a [good documentation](https://www.msys2.org/docs/package-management/). The compiler is mingw64.
- chocolatey (that what is used at the moment). The compiler is MSVC
- [vcpkg](https://learn.microsoft.com/en-us/vcpkg/get_started/overview).
This issue contains many aspect and:
- must answer the question : Should we move to msys2 or vcpkg or stay on chocolatey+MSVC?
- must provide a new toolchain documentation
- must provide a new docker image for CI
- (if possible) must provide a new documentation on how to use the docker image to develop on windows without installing software
See:
- [msys2 description](https://www.msys2.org/docs/what-is-msys2/)
- [project that use msys2](https://www.msys2.org/docs/who-is-using-msys2/), to check how they use it, what's the impact on their toolchain, and how they manage their CI (e.g., [inkscape](https://wiki.inkscape.org/wiki/Compiling_Inkscape_on_Windows_with_MSYS2) and [inkscape CI on gitlab.com](https://gitlab.com/inkscape/inkscape/-/raw/master/buildtools/msys2installdeps.sh)).
- [dockerization tentative for msys2](https://github.com/Amitie10g/docker-msys2)
If MSys2 is adopted:
- All dependencies library should be available (xerces-c,...), including some that are not directly used in CCE but are known to be used/supported in CEPs (e.g., opencv, SDL2,...)
- MSC++ will not be used as the default compiler on windows (subsidiary question: does it have other side effects? Any impact on the future python binding?)
- that reinforce the recommendation of vscode as an ide on all platform (see #181), including windows [mingw for vscode documentation](https://code.visualstudio.com/docs/cpp/config-mingw#_adding-additional-cc-settings)
**Additional questions**
- impact CI performance (subsidiary question: is there a way to optimize the docker handling by windows? Is win11 better than win10 for handling containerized toolchain?)
- can the window docker image be used to build and run CEPs by CEP developers. That would certainly ease the setup process and will have zero impact on the developer installation. Iit is probably easy to build a CEP from vscode + devcontainer using the window docker image, but it might be harder/not possible/not efficient to run `camitk-imp` from the docker container → that remain to be tested!
- :warning: **CMake macros.** Some CamiTK CMake code (configuration and CI) depends on checking if the compiler is MSVC. There might be some problems to fix there as well if changing to mingw64.
- using mingw64 might automatically close #64 (declimport/declexport). But then another decision will have to be taken about what to do with legacy code (remove the macros for managing declimport/declexport or not). And also a decision has to be taken for using the CMake property from now on...
## Acceptance tests
- [ ] Internal document to explain the decision
- [ ] window docker image for CI (updated or renewed)
- [ ] re-generate the CamiTK5.2 package using the new image (to test the release process for future release)
- [ ] update website setup documentation
- [ ] update [support policy web page](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/camitk-website/-/blob/master/content/en/docs/advanced%20topics/developers/support%20policy.md)
- [ ] in the `develop` branch check `CMakeLists.txt` for minimal version and check if update is required
- [ ] in the `develop` branch move version requirements for the tests (VTK and ITK version) and update test file if required. For instance : `component-stl-level3-2`, `vtkimage`...
- [ ] update release documentation to add a step that uses the Windows toolchain and solve the compiler/linker warnings before adding the release tag (same as the clang)
**Note** Use tag `:2025` for the image instead of `5.3` (change of docker image naming convention)Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/182Update Ubuntu docker fo CI2024-03-22T18:08:56+01:00Emmanuel PromayonUpdate Ubuntu docker fo CIUpdate LTS docker image using Ubuntu 24.04 LTS Noble [Numbat](https://en.wikipedia.org/wiki/Numbat) that [will be released at the end of April](https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649)
**Question to answer:**
...Update LTS docker image using Ubuntu 24.04 LTS Noble [Numbat](https://en.wikipedia.org/wiki/Numbat) that [will be released at the end of April](https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649)
**Question to answer:**
- if the windows tool chain migrates to MSys2 (i.e. using mingw64 compiler instead of MSC++), would it not be better to use lvm instead of gcc on LTS so that there are at least two big compiler family in the CI?
**Note**
Use tag `:2025` for the image instead of `5.3` (change of docker image naming convention)
***Note***
Depends on Ubuntu 24.04 release, this should be planned for may/june.
- [ ] update Dockerfile
- [ ] setup CI using new image
- [ ] push image to gitlab
- [ ] update website setup documentation
- [ ] update [support policy web page](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/camitk-website/-/blob/master/content/en/docs/advanced%20topics/developers/support%20policy.md)
- [ ] in the `develop` branch check `CMakeLists.txt` for minimal version and check if update is required
- [ ] in the `develop` branch move version requirements for the tests (VTK and ITK version) and update test file if required. For instance : `component-stl-level3-2`, `vtkimage`...Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/181VS Code extension pack and settings for CamiTK developers2024-03-25T15:25:09+01:00Emmanuel PromayonVS Code extension pack and settings for CamiTK developers| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | have guideline and default settings for Visual Studio Code / codium |
| **So that** | I can quickly start and efficiently develop my CamiTK extension |
## Description /...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | have guideline and default settings for Visual Studio Code / codium |
| **So that** | I can quickly start and efficiently develop my CamiTK extension |
## Description / Overview
This should supersede Issue #143.
VS Code / Codium is more and more used among developers, including C++ developers. It has many advantages over previous recommended solution (e.g., KDevelop, Visual Studio):
- it supports both Linux and Windows the same way
- it is versatile as you can use it to write code, markdown documentation or report, article with LaTeX...
- it can be used to develop inside docker containers
- it integrates every tools that makes it easier for developer (debugger, git...)
[Check the google trend](https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0134xwrk,%2Fm%2F01r_y0,%2Fm%2F08rjyp,%2Fm%2F063zx_g,%2Fg%2F11c3kh6nh5)
It would be nice for developers if the CamiTK team recommend a list of extension and/or provide a default `VS code` configuration file that sets everything up.
## Hints
List of currently used and recommended (to cleanup/update/verify/classify in subcategories):
- MS C/C++ / MS C/C++ Extension pack
- native debug
- CMake Tools and CMake
- astyle + astyle configuration (in `${workspaceRoot}/.vscode/astylerc`)
- TODO highlight
- MS Dev Containers
- Git : git graph ???, GitLab Workflow???, GitLens ???
We can also have recommandation for other categories such as: markdown preview enhanced, markdownlint, LTeX grammar check, Atom One light theme, better C++ syntax, bookmarks, code spell checker, docker, LaTeX Workshop, project manager, Paste image, how to install plantuml local server, ...
See also [old internal doc](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/pilotage-technique/-/blob/e0f41e6493af51d73614f1a61932efee48b8ed0b/sp%C3%A9cifications/vs%20code/vs%20code.md)
## Acceptance tests
A progressive list of deliverables
- [ ] Website page describing the recommended extensions
- [ ] add the command to install the extensions (from the command line and from inside code) in the website page
- [ ] add the recommended way to install VS code and codium depending on the OS
- [ ] create a CamiTK extension pack [see this](https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup) [or that](https://www.digitalocean.com/community/tutorials/how-to-create-an-extension-pack-for-visual-studio-code)
- [ ] configuration template in the CamiTK Community Edition source (something like `.vscode/.vscode-template` or at the user level in `~/.config`)
- [ ] configuration template `.devcontainer` for working inside docker containers
## Trackhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/180Simplify CamiTKVersion.h management2024-02-23T11:20:59+01:00Emmanuel PromayonSimplify CamiTKVersion.h management| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release managem...| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release management |
## Description / Overview
This point for this issue is:
- gather explanation about/rationale behind the existence of `CamiTKVersion.h` and `CamiTKVersion.h.in` file
- explain some consequence of the existence of this file
- work on how it can be simplified
## Hints
`CamiTKVersion.h` contains static information about the version number, debug postfix and `libDir`.
This file generates some complicated maneuvers during release management and packaging (see below).
### Some background on plugins
- CamiTK has a core library and uses plugins to add I/O (components), processing (actions) and viewer functionalities
- the plugins are made available using .so stored in "camitk repository", a directory that has a specific structure with subdirectories to sort plugins depending on their nature (actions, components, viewers)
- at run time, the core library looks into different paths for locating the existing camitk repositories (working directory, user installed, locally installed, or globally installed) in order to dynamically load all the available plugins.
- The libDir variable is used to check the camitk repository paths, that should all be ending with "some/path/" + libDir + "/camitk-x.y" (where x.y are major.minor camitk version numbers).
- The CamiTKVersion.h header file is used to specify this statically.
- On the upstream develop branch, libDir is generated at configure time by CMake, using the CMAKE_INSTALL_LIBDIR variable which is either set to "lib/ARCH" (if CMAKE_INSTALL_PATH is set to "/usr") or to just "lib/" (if CMAKE_INSTALL_PATH is empty).
- on the upstream master branch (the stable version, used to generate the tar ball), this is fixed to "lib". **TODO: describe rationale behind this**
### Generated burden
It might not be the best way to proceed, it is a bit complicated... That's what we came up with at the time (pre 2011) to answer to the following support constraints :
- multiple os,
- multiple camitk repositories,
- and multiple build situation (inbuild, sdk, install, cep dev)
It looks more like technical debt and could probably be simplified as it impact
- the release management process
- the packaging process (s.g. during 5.2 release `CamiTKVersion.h` was different on debian salsa master and in the upstream tarball), see also d/r and the line that uses `sed` to correct the file on debian...
### Note on `libDir` introduction in CamiTK version
`libDir` in CamiTKVersion was introduced #109 and #117 (commit de1794622009c4edd6cf4220773b61dbd644c37e) in order to support gentoo, and was later modified to take into account more situations:
- lib (default)
- lib64 (used on some Linux/platform)
- lib/<multiarch-tuple> (on Debian)
### Fixing this issue
Fixing this issue can be done either by
- option 1: confirming that a static `CamiTKVersion.h` (part of all of it) is required in `master`
- option 2: removing `CamiTKVersion.h` in master and generated release version tarball
## Acceptance tests
- [ ] option 1: better documentation to explain why a static `CamiTKVersion.h` is required
- [ ] option 2: a branch fixing this issue is merged (therefore CI passed)
- [ ] option 2: successful debian packaging process test
## Track
## Misc
- Automatic subscription of issue creator:https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/179Persistence: select parts to save, support Action properties, automatic actio...2024-03-26T19:15:48+01:00Manik BhattacharjeePersistence: select parts to save, support Action properties, automatic action replay and processing scenarios in camitk files## About you
CamiTK developer
## Product
PersistenceManager and Actions
## Overview
- PersistenceManager should allow to select which parts to save in saveWorkspace, maybe with flags (components/actions/history/mainwindow/viewers...)...## About you
CamiTK developer
## Product
PersistenceManager and Actions
## Overview
- PersistenceManager should allow to select which parts to save in saveWorkspace, maybe with flags (components/actions/history/mainwindow/viewers...)
- Action properties should be loaded without causing a crash: add a flag to Action to say whether they support parameter reloading
- Actions should specify (with a flag) whether they should be replayed (e.g. Mesh Projection: when the workspace is loaded, we want to show again the mesh projections, SmoothingFilter should be re-applied to show smooth meshes)
- Processing scenarios and History support should be added in CamiTK files and saveWorkspace, with a corresponding load function.
- Add an "Export Workspace" that saves the workspace in a directory and "save as" all components in this directory. This avoids the problem of unsaved components when saving a workspace (e.g. with CEP Focus, ultrasound acquisitions can produce many volume images, and the user wants to save everything without entering a filename for each component, so exporting the whole workspace, components included would be useful)
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/178Pick a point in 3D Viewer, view a 3D cursor2024-01-31T18:55:06+01:00Manik BhattacharjeePick a point in 3D Viewer, view a 3D cursor## About you
CamiTK developer, from multiple users' wishlist.
## Product
Medical Image Viewer, 3D Viewer
## Overview
Currently, the user cannot ctrl+click on a point in the 3D Viewer (except to select a part of a Mesh), and the curre...## About you
CamiTK developer, from multiple users' wishlist.
## Product
Medical Image Viewer, 3D Viewer
## Overview
Currently, the user cannot ctrl+click on a point in the 3D Viewer (except to select a part of a Mesh), and the currently selected point is not visible in the 3D View.
- The users would like to be able to click on an ImageComponent to set the coordinates of a point, like when using Ctrl+Click on 2D Views.
- This should also work on a MeshComponent.
- Showing the position of this point as a 3D cursor (such as a 3D cross) would be a plus.
- Clicking on an Actor could also be used to select components (e.g. clicking on a mesh should select the associated mesh component)
---
**please do not remove anything below this line**https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/177Save All fails if a Component does not have a filename (e.g. newly reconstruc...2024-02-07T12:35:39+01:00Manik BhattacharjeeSave All fails if a Component does not have a filename (e.g. newly reconstructed mesh)## About you
CamiTK developer
## Overview
SaveAll implementation is wrong and fails in multiple ways when components to save do not have a filename. This can lead to data loss (thinking a file was saved even it was not) and segfault (w...## About you
CamiTK developer
## Overview
SaveAll implementation is wrong and fails in multiple ways when components to save do not have a filename. This can lead to data loss (thinking a file was saved even it was not) and segfault (when no component is selected).
## Steps to Reproduce
Open two masks (e.g. skull-binary.stl and head-binary from testdata).
Using action Reconstruction to create a mesh from each mask.
- Scenario 1
- Select both meshes
- Click on "Save All" from the File menu
- In the first Save As window, save as Mesh1.obj
- In the second window, save as Mesh2.obj
- Scenario 2
- Deselect all components
- Click on "Save All" from the File menu
## Actual VS Expected Result
- Scenario 1
- Expected: both meshes are saved in their own file, each now has a filename set to the one that was used to save them
- Actual: only one of the meshes was saved in both files. This mesh now has a filename set to the latest file saved. The other mesh is ignored and not saved
- Scenario 2
- Expected: both meshes are saved in their own file
- Actual result: CamiTK crashes, all work is lost
## Interpretation & Possible fixes
- `SaveAllAction::apply` calls `Application::save` on all top-level components.
- `Application::save` checks if the filename is empty. If it is, it calls
- `getAction("Save As")->apply()`.
The problem here is that the `SaveAsAction::apply` function does not know which component it must save, as this is not a parameter of `apply`.
It will try to save the last selected component, which is probably not the one we are trying to save.
`Component* comp = Application::getSelectedComponents().last();`
If there is no selected component (Scenario 2), this tries to get a Component from an empty list and crashes (qt_assert in debug mode).
If there is at least a selected component, SaveAll will save the last selected component over and over again.
**To fix this**
Modify action "Save As" so we can set a componentToSave parameter, apply it, then reset ComponentToSave to null_ptr. Apply would then check for this parameter, revert to the current behaviour if it is empty, and check if there are selectedComponents before getting the last element.
## CamiTK Version
CamiTK 5.2.0.158-camitk-file-format-metadata-scenes-processing-scenarios.c46342cd
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/176Triggering the Arbitrary Slice action crashes with 2D images2023-12-22T23:07:35+01:00Emmanuel PromayonTriggering the Arbitrary Slice action crashes with 2D images## About you
CamiTK developer
## Overview
When triggering the "Arbitrary Slice" on an image component that contains a 2D image, the application crashes.
## Steps to Reproduce
Save [this image](/uploads/43c877105d9b1b7d3fd67d85088016...## About you
CamiTK developer
## Overview
When triggering the "Arbitrary Slice" on an image component that contains a 2D image, the application crashes.
## Steps to Reproduce
Save [this image](/uploads/43c877105d9b1b7d3fd67d85088016b0/debian-logo.png) and open it with `camitk-imp`
Select the component, and select the `View` → `Arbitrary Slice`
→ `camitk-imp` crashes
## Actual VS Expected Result
No crash !
The arbitrary slice action should abort cleanly and a warning message should be displayed to explain why the action aborted.
## Interpretation & Possible fixes
The arbitrary slice's `SingleImageComponent` is only created if the image component has 3 dimensions (see ImageComponent.cpp:562 and line 571. When the arbitrary slice action is triggered it does not take into account the fact that an `ImageComponent` can have no arbitrary slice subcomponent.
Check the pointer value before accessing it (see AnglesAndTranslationAction::getWidget(), line 106).
## CamiTK Version
CamiTK 5.2.0.develop. 54c95fce
---
**please do not remove anything below this line**https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/175Add "Delete" key shortcut to close the currently selected component2023-12-15T14:10:00+01:00Emmanuel PromayonAdd "Delete" key shortcut to close the currently selected componenthttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/174Generic user interface improvements2023-12-08T23:29:36+01:00Emmanuel PromayonGeneric user interface improvements## About you
CamiTK developer that listen to my users
## Overview
This issue covers all small UI improvements.## About you
CamiTK developer that listen to my users
## Overview
This issue covers all small UI improvements.https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/173In Action viewer's search panel, the Family combo box does not filter actions2023-11-29T14:58:33+01:00Manik BhattacharjeeIn Action viewer's search panel, the Family combo box does not filter actions## About you
CamiTK developer
## Overview
In the action viewer, the "Family" combo box does nothing.
## Steps to Reproduce
- from a newly built CamiTK, run camitk-imp
- open testdata/sinus-displaced.mha
- In the menu click on View/To...## About you
CamiTK developer
## Overview
In the action viewer, the "Family" combo box does nothing.
## Steps to Reproduce
- from a newly built CamiTK, run camitk-imp
- open testdata/sinus-displaced.mha
- In the menu click on View/Toggle Docked Viewers/Action Viewer to show the Action viewer panel
- Select the component
- Click on the Action combobox in the actions panel and see the list of available actions
- Select a Family e.g. Frame
- Click on the Action combobox, all actions are still there
## Actual VS Expected Result
All actions are visible, nor only the actions from the selected family.
## Interpretation & Possible fixes
This bug was introduced by commit 1bdd9a84 with a change to ImpMainWindow.cpp around line 111.
The line
`actionViewer->setSearchPanelVisible(true);`
was removed.
We could either restore this line (and the necessary dynamic_cast to ActionViewer) or call it from the ActionViewer constructor.
I am not certain why setSearchPanelVisible should disconnect the link from the combobox'signals to the relevant methods.
## CamiTK Version
CamiTK 5.2.0.157-reference-frames-and-transformations-management.a9f78af5
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/172On Windows, CamiTK applications may block or wait indefinitely2023-11-27T15:47:09+01:00Manik BhattacharjeeOn Windows, CamiTK applications may block or wait indefinitely## About you
CamiTK developer, reported by two windows users
## Overview
After a crash, and even after reinstalling CamiTK, camitk-imp does not open or takes a very long time (several minutes) before opening. camitk-config can display ...## About you
CamiTK developer, reported by two windows users
## Overview
After a crash, and even after reinstalling CamiTK, camitk-imp does not open or takes a very long time (several minutes) before opening. camitk-config can display paths, but will not return for a very long time, or display a locking timeout in a command window.
## Steps to Reproduce
Not obvious. It seems to involve .lock or .rmlock files in %username%/AppData/Roaming/CamiTK directory.
Removing the entire directory seems to fix it.
## Actual VS Expected Result
Expected: camitk-imp starts in a few seconds (not minutes), and camitk-config returns less than a second after displaying the info (not minutes).
## Relevant logs and/or screenshots
A Qt message is sometimes displayed in a loop in a terminal while camitk-config is waiting to exit (data already displayed, but the software is not exiting): "Got unexpected locking error 123"
## Interpretation & Possible fixes
Not obvious. It seems that in some circumstances, in the %username%/AppData/Roaming/CamiTK directory, some lock files are present and Qt tries to lock settings files but fails to do so. It might also come from a conflict between camitk-config and camitk-imp trying to access the file at the same time.
This stems from the Application class creating a QSettings object in Application.cpp (global static object):
`QSettings Application::settings(QSettings::IniFormat, QSettings::UserScope, "CamiTK", QString(Core::version).remove(QChar(' ')));`
From [Qt documentation](https://doc.qt.io/qt-6/qsettings.html#accessing-settings-from-multiple-threads-or-processes-simultaneously) IniFormat should work and manage locking correctly, but it seems that sometimes it fails to do so.
Turning the locking safety off might solve this problem as stated [in the documentation](https://doc.qt.io/qt-6/qsettings.html#setAtomicSyncRequired) but it might create other issues (if multiple camitk applications are running and overwrite each other's settings).
## CamiTK Version
Stable 5.0 windows version
---
**please do not remove anything below this line**https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/171Crash when printing debug information (F2 key)2023-11-24T16:35:20+01:00Manik BhattacharjeeCrash when printing debug information (F2 key)## About you
CamiTK developer
## Overview
When a component is displayed in InteractiveViewer, pressing the F2 key should display debug information in the log.
Instead, CamiTK crashes (segfault).
## Steps to Reproduce
- Run camitk-imp...## About you
CamiTK developer
## Overview
When a component is displayed in InteractiveViewer, pressing the F2 key should display debug information in the log.
Instead, CamiTK crashes (segfault).
## Steps to Reproduce
- Run camitk-imp
- Open a mesh (.obj) or an image (.nii)
- Push F2 key
## Actual VS Expected Result
IMP crashes and does not display debug information
## Interpretation & Possible fixes
Crash happens in InteractiveViewer.cpp when creating a list of all props from a component:
`std::list<vtkSmartPointer <vtkProp> > allActors(actorMap.values(c).begin(), actorMap.values(c).end());`
## CamiTK Version
Current develop branch of camitk-5.2
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/170Elastix registration using the elastix command2023-11-26T18:34:59+01:00Emmanuel PromayonElastix registration using the elastix command| | |
|--|--|
| **As a** | camitk-imp user... |
| **I would like to** | register image using the elastix software from CamiTK |
| **So that** | I can change the main parameter, call elastix and see the registration result in CamiTK witho...| | |
|--|--|
| **As a** | camitk-imp user... |
| **I would like to** | register image using the elastix software from CamiTK |
| **So that** | I can change the main parameter, call elastix and see the registration result in CamiTK without using the command line |
| **Epic/Topics** | medical image registration |
## Description / Overview
Select main registration parameters in an Action interface. Apply registration using "Apply" button
Basically this issue is to perform [MISR tutorial 3](https://promayoe.gricad-pages.univ-grenoble-alpes.fr/walnut/tutorials/misr/03/index.html) using camitk-imp instead of the command line.
## Hints
Call elastix/elastix.exe from the action
## TrackEmmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/169add dbus connection2023-10-29T13:49:12+01:00Emmanuel Promayonadd dbus connection## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be ru...## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be run and stopped automatically after a while. For example, in the case of `camitk-fancy` that would have allowed for a simple start and exit. In the presence of a bug similar to #168, the test would then have failed.
A possible way of offering extended testing for application would be to add the possibility for any CamiTK application to listen to dbus messages.
- it would then be possible to send message from outside the application (e.g. a shell, a test script or program...) such as "run action `Quit`".
- it would also add the **great** advantage of opening a whole lot of testing and automation. For instance by sending message analog to state in the action state machine (e.g. by sending XML/json message containing the action to apply and its parameter).
## Relevant logs and/or screenshots
### Adding dbus message support in CamiTK::Application
For instance by using:
```cpp
QDBusConnection::sessionBus().connect(QString(), QString(), "camitk.action", "apply", this, SLOT(applyActionFromDBus(QString)));
...
void Application::applyActionFromDBus(const QString &message) {
if(message=="...") {
...
}
}
```
### From the test application
```cpp
QProcess myProcess;
myProcess.start("camitk-fancy", "");
if (!myProcess.waitForStarted())
return false;
QDBusMessage msg = QDBusMessage::createSignal("/", "camitk.action", "apply");
message="Quit"
QDBusConnection::sessionBus().send(msg);
if (!myProcess.waitForFinished())
return false;
```
**Note**
DBus is supported on Linux desktops by default. A [windows port exists](https://www.freedesktop.org/wiki/Software/dbus/#download) but this need further checks.
### dbus not allowed by default
For security reason, the default behaviour should be _not_ to listen to DBus, and flag `--dbus` should be added to the arguments to enable the feature in the application.
### See also
[KDE doc for creating dbus interface](https://develop.kde.org/docs/features/d-bus/creating_dbus_interfaces/)
---https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/168Fancy segfault2023-10-29T15:05:39+01:00Emmanuel PromayonFancy segfault## About you
CamiTK dev
## Overview
Application camitk-fancy crashed with segfault as soon as it starts.
## Steps to Reproduce
- build CamiTK with -DCEP_TUTORIAL=TRUE
- cd build
- bin/camitk-fancy
## Actual VS Expected Result
Crash...## About you
CamiTK dev
## Overview
Application camitk-fancy crashed with segfault as soon as it starts.
## Steps to Reproduce
- build CamiTK with -DCEP_TUTORIAL=TRUE
- cd build
- bin/camitk-fancy
## Actual VS Expected Result
Crash versus fancy main window opening
## Interpretation & Possible fixes
`comp` attribute is not set to nullptr
## CamiTK Version
CamiTK 5.2.0.develop.3480339c
Compiled using git Hash: 3480339c7626584d1ad62f045dbc5cf5b472345f, Date: Fri Jul 28 14:49:32 2023 +0200.Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/167ITK Registration Action2023-10-26T16:58:56+02:00Celine FouardITK Registration Action| | |
|--|--|
| **As a** | CamiTK User / Student |
| **I would like to** | Use basic registration technics to align 2 images |
| **So that** | I could visualize registration results directly on CamiTK |
| **Epic/Topics** | Integrate ITK ...| | |
|--|--|
| **As a** | CamiTK User / Student |
| **I would like to** | Use basic registration technics to align 2 images |
| **So that** | I could visualize registration results directly on CamiTK |
| **Epic/Topics** | Integrate ITK Registration into CamiTK |
## Description / Overview
Select mandatory registration parameters on an Action interface. Apply registration
## Acceptance tests
[Please enter acceptance tests as TODOs. Acceptance test explains how to test that this issue is solved]
- [ ] [Test 1]
- [ ] [Test 2]
- [ ] [...]
## Track
[Please keep only one of the following label]
## Misc
- Automatic subscription of issue creator:
**If appropriate, do not forget to mark this issue as "confidential"** by checking the corresponding tick box belowCeline FouardCeline Fouardhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/166Python bindings: Python CEP and scripting2023-10-13T18:11:11+02:00Manik BhattacharjeePython bindings: Python CEP and scripting## About you
CamiTK developers
## Product
CamiTK
## Overview
Allow Python CEP and Python scripting
---
**please do not remove anything below this line**## About you
CamiTK developers
## Product
CamiTK
## Overview
Allow Python CEP and Python scripting
---
**please do not remove anything below this line**Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/158CamiTK File Format - metadata, scenes, processing scenarios...2024-02-13T23:09:12+01:00Manik BhattacharjeeCamiTK File Format - metadata, scenes, processing scenarios...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | define a file format for CamiTK I/O |
| **So that** | CamiTK can load and save scenes, metadata associated with files, user preferences, scenarios for the state machin...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | define a file format for CamiTK I/O |
| **So that** | CamiTK can load and save scenes, metadata associated with files, user preferences, scenarios for the state machine... |
| **Epic/Topics** | |
## Description / Overview
CamiTK needs to store multiple types of data. An extensible file format should be designed for the following use cases:
- Metadata files: storing LUT settings/color settings and geometrical transformations associated with a file, as well as CamiTK properties.
- Storing scenes (objects loaded, geometrical transformations, actions settings)
- Storing processing scenario such as used by the state machine to allow batch processing of data
- Storing user preferences
## Hints
- A human-readable format would be better (e.g. JSON)
- For scenes, CardioModel CEP and Meniscare CEP have scene formats to load multiple registered images together. but they should be made more generic
- The CamiTK state machine already has a XML-based format to define processing steps
## Acceptance tests
- [ ] Load a volume, register it to another image, set its LUT. Close CamiTK. When opening the image again, it should still be registered and keep its LUT settings.
- [ ] Any action should have its settings saved in the metadata of the file it was used on, and the settings should be loaded when opening the file again
- [ ] Loading a scene file reopens the scene as it was before closing it (all images, actions, viewers...)
- [ ] Opening a file, using multiple actions to get an output and saving it could be saved as a processing scenario, and applied to another input.
## Track
## Misc
- Automatic subscription of issue creator:
**If appropriate, do not forget to mark this issue as "confidential"** by checking the corresponding tick box belowManik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/157Reference frames and transformations management2024-03-28T14:25:48+01:00Manik BhattacharjeeReference frames and transformations management| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | support and document reference frames, geometrical transformations and orientation conventions |
| **So that** | CamiTK can load, register and display volumes and mesh...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | support and document reference frames, geometrical transformations and orientation conventions |
| **So that** | CamiTK can load, register and display volumes and meshes with explicit reference frames, transformations and anatomical orientations |
| **Epic/Topics** | Referential Management Epic |
## Current state overview
**Geometrical transformations in CamiTK are currently managed by**:
- Frames which are attached to all components
- A transformation from each frame to its parent Frame
- A World Frame
- A default orientation for volumes (RAI convention)
- Depending on the file format used (DICOM, MHD/MHA, Nifti...) the transformation to the parent frame may or may not be loaded/saved
- Depending on the file format, the anatomical orientation may be loaded/saved or not, and conversion to RAI may or may not work.
- There is no standard way to store a registration between two images so that CamiTK reloads it when the software loads images again
## Solutions
### 1. Documentation
- Document every detail of geometrical conventions using illustrations when needed to avoid confusion
- For DICOM, there is the position of the patient in the machine, the position of the image relative to the machine, and the convention of the order to save the pixels. [Illustrations are useful](https://dicom.nema.org/medical/Dicom/2016e/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.2).
- Matrices may be stored in row-major (Nifti) or column-major order (MHA file format)
- For each image and mesh file format, detail how we read and write it (e.g. ITK and VTK do not read and write the same information in the header and do not assume the same conventions for MHA format). This should explain how CamiTK may differ with other software and why we took those decisions.
### 2. Main (core) changes
- Define a CamiTK unique ID : **CamiUID** so that each object has a unique ID, maybe associated with a name, a description and a type ?
- Define a **ReferenceFrame** class (mostly a CamiUID) so that every displayable component has an instance of it
- We have to keep the **anatomical orientation** information. It might be stored in the Referential object and specify which axes (if known) are Right/Left, Superior/Inferior, Anterior/Posterior. This information is transitive (e.g. if there is no large rotation (> 45°) or axes flipping, the anatomical orientation is the same between two reference frames linked by a transformation). It can be set to UNKNOWN (in which case a viewer should not display the anatomical directions).
- Define a **Transformation** class that has an origin and a destination (from/to) ReferenceFrame, a vtkTransform (by default a linear transform represented by a 4x4 matrix), and a CamiUID. Make it generic enough so that it could manage a 4th dimension (e.g. for a time offset between videos) and non-linear transformations
- The Frame interface should be updated
- A Referential and Transformation Manager should be included in CamiTK Application to manage the list of known reference frames and transformations
- In this manager, keep the source of referentials and transformations. E.g. if a Nifti file contains two transforms, the loaded nifti component, when saved, should save again both transforms. and not other transforms to other referentials. Or maybe this information should be stored in the Image Component itself (which transformations to save).
- A CamiTK world referential will exist by default, and components that are loaded without specific transformations to CamiTK will have an identity transform from their referential to CamiTKWorldReferential
- There is no reason to force an orientation convention in CamiTK (e.g. RAI for all volumes).
### 3. UI changes
- An explorer for referential and transformations should be provided, (like the Component explorer, the property explorer and so on). It should be able to display/edit transformations, to link referentials with new transformations (identity, loaded from file...).
- A color code for each referential will be displayed next to each component name, and next to each viewer name, and can be changed by clicking on it to choose another one
### 4. I/O ###
- Define a way to store metadata associated to files (e.g., keep the UID of the referential of a MHD file).
This is linked to a metadata format (see specific issue #158) that should be defined for all CamiTK-related data (such as the LUT settings associated to an image, a list of actions to run for a state machine, a scene description and so on). If possible, choose a human-readable format and try to be compatible with other software or norms, e.g. the JSON format used by [BIDS](https://bids.neuroimaging.io/) or in the metadata files of [Brainvisa](https://brainvisa.info). Maybe a .camitk file.
- test
### 5. Viewers
- Each viewer is attached to a reference frame (e.g. all coordinates of a selected point in the viewer are expressed in this referential), and a camera position and orientation.
- Slice viewers may use their reference frame orientation information to display R/L, A/P, I/S directions
- In viewer preferences, the user can set its own convention (Right displayed on the left, or right displayed on the right)
- When adding a volume to a SliceViewer, it should get its reference frame from it, use anatomical orientation information of the frame, and user preference to orient its camera transform (no need to have RAI/LAS or other convention forced on the volume).
- Viewers should be in charge of the way they want to display a volume (e.g. no Axial View Component, just a SliceViewer with a camera orientation that matches Axial, and a volume image).
- Medical Image Viewer should manage the slices displayed in the 3D view in relation to the slices displayed in the SliceViewers by itself (not using subcomponents)
- A common cursor between viewers can be achieved by following the transformation graph from one view's reference frame to another viewer's reference frame. We can display a 3D cross with its own reference frame, and moving the cursor means changing the transformation between this frame and the selected object's frame. This allows a 3D cursor in a SliceViewer to be displayed in a 3D viewer, rotated with the angle of the slice currently being clicked on.
## Acceptance tests
- [ ] [Documentation is clear and complete]
- [ ] [Reading an image, registering it with another, saving both, then closing the software and reading both again should load all referentials and transforms so that the images are still aligned]
- [ ] [Same test with an image and a mesh segmented from it]
- [ ] [Same test with two meshes registered then saved and loaded again]
- [ ] [3D cursor synchronized between views with different referentials]
- [ ] [Displaying a volume in a SliceViewer using a referential of another volume (should display "arbitrary" slices of the volume aligned with the slices of the other volume)]
- [ ] [Loading two volumes from the same MRI acquisition should show volumes aligned because of the common scanner-based reference]
- [ ] use QUuid as a map key in TransformationManager, not QString
- [ ] Cleanup the TransformationManager API (maybe too complete/complex)
- [ ] Better API Documentation
- [ ] Remove C++23 specific code (too early)
## Track
## Misc
- Automatic subscription of issue creator:
**If appropriate, do not forget to mark this issue as "confidential"** by checking the corresponding tick box belowManik BhattacharjeeManik Bhattacharjee