CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2020-05-29T19:21:52+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/100Wizard cannot generate viewer extension2020-05-29T19:21:52+02:00Emmanuel PromayonWizard cannot generate viewer extension| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | create a new viewer using the viewer |
| **So that** | I can forget about the CMake and plugin management technicalities and focus on the development of a new viewer |
## Description / Overview
`camitk-wizard` is not aware of the new viewer extension. Therefore there is no GUI to create the skeleton of a new viewer extension (although cepgenerator is able to do it from an XML coreschema document)
## Hints
Use the current wizard GUI parts that deal with the creation of action/component extension to add a viewer extension GUI
## Acceptance tests
- [ ] As a user I can run the wizard to create a new CEP that has "myviewer" viewer extension
- [ ] As a user I can run the wizard to create a new CEP that has an action that can use the "myviewer" extension
## Track
## Misc
See MR !145| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | create a new viewer using the viewer |
| **So that** | I can forget about the CMake and plugin management technicalities and focus on the development of a new viewer |
## Description / Overview
`camitk-wizard` is not aware of the new viewer extension. Therefore there is no GUI to create the skeleton of a new viewer extension (although cepgenerator is able to do it from an XML coreschema document)
## Hints
Use the current wizard GUI parts that deal with the creation of action/component extension to add a viewer extension GUI
## Acceptance tests
- [ ] As a user I can run the wizard to create a new CEP that has "myviewer" viewer extension
- [ ] As a user I can run the wizard to create a new CEP that has an action that can use the "myviewer" extension
## Track
## Misc
See MR !145Story AcceptableTrack Prototyping ExperienceMaxime CalkaMaxime Calkahttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/98CMake code generation over viewer&#39;s extension targets2020-06-02T10:44:52+02:00Emmanuel PromayonCMake code generation over viewer's extension targets## About you
CamiTK dev
## Overview
If a component or action declares a dependency to a viewer extension, CMake generates an error during generation.
```bash
CMake Error in actions/testactions/CMakeLists.txt:
The dependency target "viewer-medicalimageviewer" of target
"action-testactions_autogen" does not exist.
```
→ The viewer's extension targets are not exported properly and generate an error
## Steps to Reproduce
In an action `CMakeLists.txt`, add the following line inside the `camitk_extension` parameters:
```cmake
camitk_extension(ACTION_EXTENSION
...
NEEDS_VIEWER_EXTENSION medicalimageviewer
...
)
```
## Actual VS Expected Result
When running the CMake generation on the project, the following error is generated
```bash
CMake Error in actions/testactions/CMakeLists.txt:
The dependency target "viewer-medicalimageviewer" of target
"action-testactions_autogen" does not exist.
```
The target is not known by the CEP as it is not exported by CamiTK CE.
The expected result is a error free CMake generation
I created a specific branch and MR (see !147) with cepgenerator test files.
This can be considered as fixed when the test `application-cepgenerator-bash-test` in MR !147 returns no error.
To run the test :
- checkout branch `bug/target-export`
- configure and build
- run the corresponding test:
```bash
ctest -VV -R application-cepgenerator-bash-test
```
## Interpretation & Possible fixes
Two possible fixes:
- [ ] either fix CamiTK CMake files so that extensions are exported
- [ ] tweak the cepgenerator to add the following lines in the generated action `CMakeLists.txt` AND document the manual fix in the wiki.
```cmake
# Add this line in the action or component CMakeLists.txt, before the call to the camitk_extension macro
add_library(viewer-medicalimageviewer INTERFACE IMPORTED)
```
- [ ] FindCamiTK.cmake includes these export lines
Note that a similar line has to be added from each added NEEDS_VIEWER_EXTENSION dependencies
## CamiTK Version
`CamiTK version........................... CamiTK 4.2.dev.bug-target-export.0cf6a8fa`
~"Track Debugging"## About you
CamiTK dev
## Overview
If a component or action declares a dependency to a viewer extension, CMake generates an error during generation.
```bash
CMake Error in actions/testactions/CMakeLists.txt:
The dependency target "viewer-medicalimageviewer" of target
"action-testactions_autogen" does not exist.
```
→ The viewer's extension targets are not exported properly and generate an error
## Steps to Reproduce
In an action `CMakeLists.txt`, add the following line inside the `camitk_extension` parameters:
```cmake
camitk_extension(ACTION_EXTENSION
...
NEEDS_VIEWER_EXTENSION medicalimageviewer
...
)
```
## Actual VS Expected Result
When running the CMake generation on the project, the following error is generated
```bash
CMake Error in actions/testactions/CMakeLists.txt:
The dependency target "viewer-medicalimageviewer" of target
"action-testactions_autogen" does not exist.
```
The target is not known by the CEP as it is not exported by CamiTK CE.
The expected result is a error free CMake generation
I created a specific branch and MR (see !147) with cepgenerator test files.
This can be considered as fixed when the test `application-cepgenerator-bash-test` in MR !147 returns no error.
To run the test :
- checkout branch `bug/target-export`
- configure and build
- run the corresponding test:
```bash
ctest -VV -R application-cepgenerator-bash-test
```
## Interpretation & Possible fixes
Two possible fixes:
- [ ] either fix CamiTK CMake files so that extensions are exported
- [ ] tweak the cepgenerator to add the following lines in the generated action `CMakeLists.txt` AND document the manual fix in the wiki.
```cmake
# Add this line in the action or component CMakeLists.txt, before the call to the camitk_extension macro
add_library(viewer-medicalimageviewer INTERFACE IMPORTED)
```
- [ ] FindCamiTK.cmake includes these export lines
Note that a similar line has to be added from each added NEEDS_VIEWER_EXTENSION dependencies
## CamiTK Version
`CamiTK version........................... CamiTK 4.2.dev.bug-target-export.0cf6a8fa`
~"Track Debugging"CamiTK 4.2 Sprint # 1BacklogBug ConfirmedTrack DebuggingJean-Loup HaberbuschJean-Loup Haberbuschhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/89Used the last viewer that display a component2020-05-18T17:23:12+02:00Maxime CalkaUsed the last viewer that display a component## About you
Meniscare developper
## Product
CamiTK (imp)
## Overview
When a component is selected the viewer corresponding to this component need to be displayed.
## Relevant logs and/or screenshots
For now the normal workflow is like that. I select a component and I see the last action that has been applied on it.
![image](/uploads/d1e0e43b1daf3b8ba23f16eea859adaf/image.png)
But now, I would that the last viewer that display this component are reused.
![image](/uploads/f0f00dd17059ea0488bcb04cb99a2aa4/image.png)
Ask me if it's not well describe.
---
**please do not remove anything below this line**## About you
Meniscare developper
## Product
CamiTK (imp)
## Overview
When a component is selected the viewer corresponding to this component need to be displayed.
## Relevant logs and/or screenshots
For now the normal workflow is like that. I select a component and I see the last action that has been applied on it.
![image](/uploads/d1e0e43b1daf3b8ba23f16eea859adaf/image.png)
But now, I would that the last viewer that display this component are reused.
![image](/uploads/f0f00dd17059ea0488bcb04cb99a2aa4/image.png)
Ask me if it's not well describe.
---
**please do not remove anything below this line**Feature RequestTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/85Bug install qtpropertybrowser debian2020-05-18T17:27:12+02:00Clement BeitoneBug install qtpropertybrowser debianOn linux if the package manager is used to install camitk, the package qtpropertybrowser is installed by default in /usr/include. In case of a manual compile / installation this package is installed in ${CAMITK_INCLUDE_DIR}/libraries/
The CamiTKConfig.cmake is not aware of this system path.
To fix this issue the variable `QTPROPERTYBROWSER_ROOT_INCLUDE_DIR` should be used in CamiTKConfig.cmake and added in:
`set(CAMITK_INCLUDE_DIRECTORIES...)`On linux if the package manager is used to install camitk, the package qtpropertybrowser is installed by default in /usr/include. In case of a manual compile / installation this package is installed in ${CAMITK_INCLUDE_DIR}/libraries/
The CamiTKConfig.cmake is not aware of this system path.
To fix this issue the variable `QTPROPERTYBROWSER_ROOT_INCLUDE_DIR` should be used in CamiTKConfig.cmake and added in:
`set(CAMITK_INCLUDE_DIRECTORIES...)`Bug ConfirmedTrack DebuggingTrack Dev Supporthttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/83Remove console on windows version of all GUI CamiTK application (camitk-imp, ...2020-05-29T10:19:47+02:00Emmanuel PromayonRemove console on windows version of all GUI CamiTK application (camitk-imp, camitk-actionstatemachine, camitk-wizard)| | |
|--|--|
| **As a** | camitk-imp user and CamiTK developer |
| **I would like to** | optimize the application performance and not have a visible (1990's) dark console when I launch imp |
| **So that** | I am not disturbed by another window on the screen, and therefore I focus on the task I need to do in the main window of camitk-imp |
| **Epic/Topics** | ] |
## Description / Overview
By default, MSVC compile camitk-imp and all other GUI-based CamiTK programs as a console program.
As stated [here](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/), this mode results in Windows allocating and showing a console for you when starting the program up (e.g. CamiTK-imp). This console will require a redraw on every std::cerr or std::cout print, resulting in massive performance issues.
The best would be have a specific option in the `camitk_application` macro to declare the application as a console application (by default, and considering the CAMI domain, I suppose it is better to say that an application has a GUI by default, only specific CamiTK application are console only).
E.g.:
```cmake
camitk_application(...
NO_GUI
...
)
```
## Hints
As stated [here](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/):
> If you program shows a graphical window, then you should change it to a Windows program. There are three methods to do this.
> The first option is to set the executable type to WIN32 in CMake:
```cmake
if(WIN32)
add_executable(${EXECUTABLE_NAME} WIN32 ${SRC})
else()
add_executable(${EXECUTABLE_NAME} ${SRC})
endif()
```
This is confirmed to work in [this answer on stackoverflow](https://stackoverflow.com/a/36528717/9890401).
The [second proposed option](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/) seems a bit to windowesque and rely on the MSVC compiler. The third proposed option should not be considered here as it won't be a nice way considering the CamiTK objectives (it make use of a `#pragma`)
See also the [CMake documentation for add_executable](https://cmake.org/cmake/help/latest/command/add_executable.html) and [WIN32_EXECUTABLE property/flag](https://cmake.org/cmake/help/latest/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE)
## Acceptance tests
- [ ] When run camitk-imp, camitk-actionstatemachine, and camitk-wizard do not show any console
- [ ] All other CamiTK CE application seem to work as before (e.g. the config and cepgenerator test pass)
- [ ] The `camitk_application` macro has a new option for console application
- [ ] The `camitk_application` macro documents this new option (so that generated doxygen talks about it)
## Track
~"Track Prototyping Experience" | | |
|--|--|
| **As a** | camitk-imp user and CamiTK developer |
| **I would like to** | optimize the application performance and not have a visible (1990's) dark console when I launch imp |
| **So that** | I am not disturbed by another window on the screen, and therefore I focus on the task I need to do in the main window of camitk-imp |
| **Epic/Topics** | ] |
## Description / Overview
By default, MSVC compile camitk-imp and all other GUI-based CamiTK programs as a console program.
As stated [here](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/), this mode results in Windows allocating and showing a console for you when starting the program up (e.g. CamiTK-imp). This console will require a redraw on every std::cerr or std::cout print, resulting in massive performance issues.
The best would be have a specific option in the `camitk_application` macro to declare the application as a console application (by default, and considering the CAMI domain, I suppose it is better to say that an application has a GUI by default, only specific CamiTK application are console only).
E.g.:
```cmake
camitk_application(...
NO_GUI
...
)
```
## Hints
As stated [here](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/):
> If you program shows a graphical window, then you should change it to a Windows program. There are three methods to do this.
> The first option is to set the executable type to WIN32 in CMake:
```cmake
if(WIN32)
add_executable(${EXECUTABLE_NAME} WIN32 ${SRC})
else()
add_executable(${EXECUTABLE_NAME} ${SRC})
endif()
```
This is confirmed to work in [this answer on stackoverflow](https://stackoverflow.com/a/36528717/9890401).
The [second proposed option](https://blog.rubenwardy.com/2019/02/15/porting-cpp-to-windows-vcpkg/) seems a bit to windowesque and rely on the MSVC compiler. The third proposed option should not be considered here as it won't be a nice way considering the CamiTK objectives (it make use of a `#pragma`)
See also the [CMake documentation for add_executable](https://cmake.org/cmake/help/latest/command/add_executable.html) and [WIN32_EXECUTABLE property/flag](https://cmake.org/cmake/help/latest/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE)
## Acceptance tests
- [ ] When run camitk-imp, camitk-actionstatemachine, and camitk-wizard do not show any console
- [ ] All other CamiTK CE application seem to work as before (e.g. the config and cepgenerator test pass)
- [ ] The `camitk_application` macro has a new option for console application
- [ ] The `camitk_application` macro documents this new option (so that generated doxygen talks about it)
## Track
~"Track Prototyping Experience" BacklogFeature RequestTrack End User ExperienceTrack Prototyping ExperienceJean-Loup HaberbuschJean-Loup Haberbuschhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/82Problem to save an mhd/raw image with voxel data type float2020-05-18T17:28:22+02:00Maxime CalkaProblem to save an mhd/raw image with voxel data type float## About you
CALKA Maxime, M2 trainee. I realize volumic image registration on CamiTK and I need to load/save MRI images.
## Overview
They are a problem when you save a mhd/raw image with a voxel type float. After saving the voxel type is change to unsigned char and the image is not workable.
## Steps to Reproduce
- Load in CamiTK an mhd/raw image with Voxel Data Type : float (ElementType = MET_FLOAT)
- Save the image with CamiTK in mhd/raw format (Save As)
- Load the new image
Normally, a entire grey image appear with the Voxel Data Type : unsigned char (ElementType = MET_UCHAR) (that is a problem)
## Actual VS Expected Result
I load the image : okay
I save the image : okay
I load the new image : no expected result (I am supposed found my original image but the voxel type has change and the image is totally grey)
## Relevant logs and/or screenshots
[bug](/uploads/6a74f9fe3e6a69ce429327af33dd9ceb/bug.png)
## Interpretation & Possible fixes
Sorry, I haven't idea.
## CamiTK Version
CamiTK Version:
- CamiTK version........................... CamiTK 4.1.2
- CamiTK Short Version..................... camitk-4.1
- CamiTK SO NAME........................... 4
- Operating System......................... WIN32
- Build type............................... DEBUG
- QT Version............................... 5.6.1
- VTK Version.............................. 6.3.0
- Global Installation Directory [G]........ C:/dev/CamiTK/install
- Local Installation Directory [L]......... C:/Users/calkam/AppData/Roaming/CamiTK
- Current Working Directory [W]............ C:/dev/CamiTK/install/bin
- Test Data Directory...................... C:/dev/CamiTK/install/share/camitk-4.1/testdata
- Component Extension Directories.......... C:/dev/CamiTK/install/lib/camitk-4.1/components
- Action Extension Directories............. C:/dev/CamiTK/install/lib/camitk-4.1/actions
- Number of Component Extensions........... 9 (locations: 9 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of File Extensions Supported...... 31
- Number of Action Extensions.............. 18 (locations: 18 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of Actions........................ 88
- Registered components:
- [G] Alias Wavefront OBJ Component...... obj
- [G] ItkImages Component................ hdr, spr, gipl, pic, lsm, nrrd, hdr.gz, nii, nii.gz, img, img.gz
- [G] Msh Component...................... msh
- [G] Off Component...................... off
- [G] STL Component...................... stl, STL
- [G] VRML 2 Component................... vrml, wrl
- [G] VTK Component...................... vtk
- [G] vtkImages Component................ jpg, png, tiff, tif, bmp, pbm, pgm, ppm, mhd, mha, raw
- [G] DICOM.............................. directory
- Registered actions:
- [G] Application Level Actions.......... 21 actions
- [G] Basic Mesh Extension............... 9 actions
- [G] Basic Topology..................... 2 actions
- [G] BoxVOIExtension.................... 1 actions
- [G] Frame Edition Extension............ 1 actions
- [G] ITK Filters........................ 14 actions
- [G] ITK Segmentation................... 3 actions
- [G] Image LUT.......................... 1 actions
- [G] ImageAcquisitionActionExtension.... 7 actions
- [G] Mesh Processing.................... 17 actions
- [G] MultiPickingExtension.............. 1 actions
- [G] Pixel Color Changer................ 1 actions
- [G] Reconstruction..................... 1 actions
- [G] Reorient Image Extension........... 1 actions
- [G] ResampleExtension.................. 1 actions
- [G] SegmentorExtension................. 1 actions
- [G] ShowIn3DExtension.................. 5 actions
- [G] VolumeRenderingExtension........... 1 actions
---
**please do not remove anything below this line**## About you
CALKA Maxime, M2 trainee. I realize volumic image registration on CamiTK and I need to load/save MRI images.
## Overview
They are a problem when you save a mhd/raw image with a voxel type float. After saving the voxel type is change to unsigned char and the image is not workable.
## Steps to Reproduce
- Load in CamiTK an mhd/raw image with Voxel Data Type : float (ElementType = MET_FLOAT)
- Save the image with CamiTK in mhd/raw format (Save As)
- Load the new image
Normally, a entire grey image appear with the Voxel Data Type : unsigned char (ElementType = MET_UCHAR) (that is a problem)
## Actual VS Expected Result
I load the image : okay
I save the image : okay
I load the new image : no expected result (I am supposed found my original image but the voxel type has change and the image is totally grey)
## Relevant logs and/or screenshots
[bug](/uploads/6a74f9fe3e6a69ce429327af33dd9ceb/bug.png)
## Interpretation & Possible fixes
Sorry, I haven't idea.
## CamiTK Version
CamiTK Version:
- CamiTK version........................... CamiTK 4.1.2
- CamiTK Short Version..................... camitk-4.1
- CamiTK SO NAME........................... 4
- Operating System......................... WIN32
- Build type............................... DEBUG
- QT Version............................... 5.6.1
- VTK Version.............................. 6.3.0
- Global Installation Directory [G]........ C:/dev/CamiTK/install
- Local Installation Directory [L]......... C:/Users/calkam/AppData/Roaming/CamiTK
- Current Working Directory [W]............ C:/dev/CamiTK/install/bin
- Test Data Directory...................... C:/dev/CamiTK/install/share/camitk-4.1/testdata
- Component Extension Directories.......... C:/dev/CamiTK/install/lib/camitk-4.1/components
- Action Extension Directories............. C:/dev/CamiTK/install/lib/camitk-4.1/actions
- Number of Component Extensions........... 9 (locations: 9 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of File Extensions Supported...... 31
- Number of Action Extensions.............. 18 (locations: 18 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of Actions........................ 88
- Registered components:
- [G] Alias Wavefront OBJ Component...... obj
- [G] ItkImages Component................ hdr, spr, gipl, pic, lsm, nrrd, hdr.gz, nii, nii.gz, img, img.gz
- [G] Msh Component...................... msh
- [G] Off Component...................... off
- [G] STL Component...................... stl, STL
- [G] VRML 2 Component................... vrml, wrl
- [G] VTK Component...................... vtk
- [G] vtkImages Component................ jpg, png, tiff, tif, bmp, pbm, pgm, ppm, mhd, mha, raw
- [G] DICOM.............................. directory
- Registered actions:
- [G] Application Level Actions.......... 21 actions
- [G] Basic Mesh Extension............... 9 actions
- [G] Basic Topology..................... 2 actions
- [G] BoxVOIExtension.................... 1 actions
- [G] Frame Edition Extension............ 1 actions
- [G] ITK Filters........................ 14 actions
- [G] ITK Segmentation................... 3 actions
- [G] Image LUT.......................... 1 actions
- [G] ImageAcquisitionActionExtension.... 7 actions
- [G] Mesh Processing.................... 17 actions
- [G] MultiPickingExtension.............. 1 actions
- [G] Pixel Color Changer................ 1 actions
- [G] Reconstruction..................... 1 actions
- [G] Reorient Image Extension........... 1 actions
- [G] ResampleExtension.................. 1 actions
- [G] SegmentorExtension................. 1 actions
- [G] ShowIn3DExtension.................. 5 actions
- [G] VolumeRenderingExtension........... 1 actions
---
**please do not remove anything below this line**BugTrack DebuggingTrack End User Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/74Changing description in automatic actions2020-05-18T17:30:15+02:00Jean-Loup HaberbuschChanging description in automatic actions## About you
CamiTK User
## Product
ImageAcquisitionComponent
## Overview
Currently, when implementing a component inherited from ImageAcquisitionComponent one cannot modify the description of the linked automatic actions. To be able to customise more and be more "user-friendly" could not there be a way to change the descriptions of the actions?
## Relevant logs and/or screenshots
---
**please do not remove anything below this line**## About you
CamiTK User
## Product
ImageAcquisitionComponent
## Overview
Currently, when implementing a component inherited from ImageAcquisitionComponent one cannot modify the description of the linked automatic actions. To be able to customise more and be more "user-friendly" could not there be a way to change the descriptions of the actions?
## Relevant logs and/or screenshots
---
**please do not remove anything below this line**Feature RequestTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/73Procedure entry point not located when building a CEP from Sources with Cmake2020-05-18T17:35:14+02:00Guillaume LapougeProcedure entry point not located when building a CEP from Sources with Cmake## About you
PhD Student at TIMC-IMAG, I work on CamiTK for needle steering
## Overview
On windows 10 64bits (Family edition) with CamiTK 4.1.2 successfully installed with the community package.
Cmake version 3.9.6, QT 5.6.1.
Any CEP won't be built by CMAKE. Windows displays an error "Procedure entry point not located" concerning some QT5 dlls.
## Steps to Reproduce
See above
## Actual VS Expected Result
We expect the CEP to be built because CamiTK was sucessfully installed with the same softwares. But Cmake displays an error before even building the project.
## Relevant logs and/or screenshots
![issueCamiTK](/uploads/7a66ee2d6238455af656ada8ee8a7ca5/issueCamiTK.png)
## Interpretation & Possible fixes
My interpretation is that the QT dll in QT 5.6.1 install folder are not found by Cmake.
Instead, Cmake seems to use the QT .dll files at \CmakeInstallFolder\CMake\bin.
A fix is to force Cmake to use the right dlls by pasting them in the folder mentioned above, replacing the old ones.
From QtInstallFolder\Qt5.6.1\5.6\msvc2015_64\bin, copy the following files :
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
Qt5Xml.dll
To replace those in \CmakeInstallFolder\CMake\bin. (Make a copy of the old ones for more safety).
## CamiTK Version
CamiTK Version:
- CamiTK version........................... CamiTK 4.1.2
- CamiTK Short Version..................... camitk-4.1
- CamiTK SO NAME........................... 4
- Operating System......................... WIN32
- Build type............................... RELEASE
- QT Version............................... 5.6.1
- VTK Version.............................. 6.3.0
- Global Installation Directory [G]........ D:/dev/CamiTK/CamiTK-4.1.2/install
- Local Installation Directory [L]......... C:/Users/guill/AppData/Roaming/CamiTK
- Current Working Directory [W]............ D:/dev/CamiTK/CamiTK-4.1.2/install/bin
- Test Data Directory...................... D:/dev/CamiTK/CamiTK-4.1.2/install/share/camitk-4.1/testdata
- Component Extension Directories.......... D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/components
- Action Extension Directories............. D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/actions
- Number of Component Extensions........... 11 (locations: 11 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of File Extensions Supported...... 34
- Number of Action Extensions.............. 19 (locations: 19 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of Actions........................ 91
- Registered components:
- [G] Alias Wavefront OBJ Component...... obj
- [G] ItkImages Component................ hdr, spr, gipl, pic, lsm, nrrd, hdr.gz, nii, nii.gz, img, img.gz
- [G] MML Component...................... mml, scn
- [G] Msh Component...................... msh
- [G] Off Component...................... off
- [G] PML Component...................... pml
- [G] STL Component...................... stl, STL
- [G] VRML 2 Component................... vrml, wrl
- [G] VTK Component...................... vtk
- [G] vtkImages Component................ jpg, png, tiff, tif, bmp, pbm, pgm, ppm, mhd, mha, raw
- [G] DICOM.............................. directory
- Registered actions:
- [G] Application Level Actions.......... 21 actions
- [G] Basic Mesh Extension............... 9 actions
- [G] Basic Topology..................... 2 actions
- [G] BoxVOIExtension.................... 1 actions
- [G] Frame Edition Extension............ 1 actions
- [G] ITK Filters........................ 14 actions
- [G] ITK Segmentation................... 3 actions
- [G] Image LUT.......................... 1 actions
- [G] ImageAcquisitionActionExtension.... 7 actions
- [G] MML................................ 2 actions
- [G] Mesh Processing.................... 17 actions
- [G] MultiPickingExtension.............. 1 actions
- [G] PMLExploreExtension................ 2 actions
- [G] Pixel Color Changer................ 1 actions
- [G] Reconstruction..................... 1 actions
- [G] Reorient Image Extension........... 1 actions
- [G] ResampleExtension.................. 1 actions
- [G] ShowIn3DExtension.................. 5 actions
- [G] VolumeRenderingExtension........... 1 actions
---
**please do not remove anything below this line**## About you
PhD Student at TIMC-IMAG, I work on CamiTK for needle steering
## Overview
On windows 10 64bits (Family edition) with CamiTK 4.1.2 successfully installed with the community package.
Cmake version 3.9.6, QT 5.6.1.
Any CEP won't be built by CMAKE. Windows displays an error "Procedure entry point not located" concerning some QT5 dlls.
## Steps to Reproduce
See above
## Actual VS Expected Result
We expect the CEP to be built because CamiTK was sucessfully installed with the same softwares. But Cmake displays an error before even building the project.
## Relevant logs and/or screenshots
![issueCamiTK](/uploads/7a66ee2d6238455af656ada8ee8a7ca5/issueCamiTK.png)
## Interpretation & Possible fixes
My interpretation is that the QT dll in QT 5.6.1 install folder are not found by Cmake.
Instead, Cmake seems to use the QT .dll files at \CmakeInstallFolder\CMake\bin.
A fix is to force Cmake to use the right dlls by pasting them in the folder mentioned above, replacing the old ones.
From QtInstallFolder\Qt5.6.1\5.6\msvc2015_64\bin, copy the following files :
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
Qt5Xml.dll
To replace those in \CmakeInstallFolder\CMake\bin. (Make a copy of the old ones for more safety).
## CamiTK Version
CamiTK Version:
- CamiTK version........................... CamiTK 4.1.2
- CamiTK Short Version..................... camitk-4.1
- CamiTK SO NAME........................... 4
- Operating System......................... WIN32
- Build type............................... RELEASE
- QT Version............................... 5.6.1
- VTK Version.............................. 6.3.0
- Global Installation Directory [G]........ D:/dev/CamiTK/CamiTK-4.1.2/install
- Local Installation Directory [L]......... C:/Users/guill/AppData/Roaming/CamiTK
- Current Working Directory [W]............ D:/dev/CamiTK/CamiTK-4.1.2/install/bin
- Test Data Directory...................... D:/dev/CamiTK/CamiTK-4.1.2/install/share/camitk-4.1/testdata
- Component Extension Directories.......... D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/components
- Action Extension Directories............. D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/actions
- Number of Component Extensions........... 11 (locations: 11 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of File Extensions Supported...... 34
- Number of Action Extensions.............. 19 (locations: 19 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of Actions........................ 91
- Registered components:
- [G] Alias Wavefront OBJ Component...... obj
- [G] ItkImages Component................ hdr, spr, gipl, pic, lsm, nrrd, hdr.gz, nii, nii.gz, img, img.gz
- [G] MML Component...................... mml, scn
- [G] Msh Component...................... msh
- [G] Off Component...................... off
- [G] PML Component...................... pml
- [G] STL Component...................... stl, STL
- [G] VRML 2 Component................... vrml, wrl
- [G] VTK Component...................... vtk
- [G] vtkImages Component................ jpg, png, tiff, tif, bmp, pbm, pgm, ppm, mhd, mha, raw
- [G] DICOM.............................. directory
- Registered actions:
- [G] Application Level Actions.......... 21 actions
- [G] Basic Mesh Extension............... 9 actions
- [G] Basic Topology..................... 2 actions
- [G] BoxVOIExtension.................... 1 actions
- [G] Frame Edition Extension............ 1 actions
- [G] ITK Filters........................ 14 actions
- [G] ITK Segmentation................... 3 actions
- [G] Image LUT.......................... 1 actions
- [G] ImageAcquisitionActionExtension.... 7 actions
- [G] MML................................ 2 actions
- [G] Mesh Processing.................... 17 actions
- [G] MultiPickingExtension.............. 1 actions
- [G] PMLExploreExtension................ 2 actions
- [G] Pixel Color Changer................ 1 actions
- [G] Reconstruction..................... 1 actions
- [G] Reorient Image Extension........... 1 actions
- [G] ResampleExtension.................. 1 actions
- [G] ShowIn3DExtension.................. 5 actions
- [G] VolumeRenderingExtension........... 1 actions
---
**please do not remove anything below this line**BugTrack Dev Supporthttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/72use setProperty with QString instead of char*2020-05-18T14:55:02+02:00Matthias Tummersuse setProperty with QString instead of char*| | |
|--|--|
| **As a** | CEP developer |
| **I would like** | a `setProperty` with `const QString name` instead of `const char * name` |
| **To** | improve camitk code consistency |
| **Epic/Topics** | Property setProperty QString char* |
## Description / Overview
I noticed that the `QObject::setProperty` method prototype demands a `const char *` type for the first argument whereas the `camitk::Property` constructor and the `getProperty` method use a `QString` type.
I think it might be a good idea to implement a method looking like
```cpp
//PropertyObject.h
virtual bool setProperty(const QString name, const QVariant &value);
```
```cpp
//PropertyObject.cpp
bool PropertyObject::setProperty(const QString name, const QVariant &value) {
if (propertiesMap.contains(name)) {
return setProperty(name.toStdString().c_str(), value);
}
else {
return false;
}
}
```
,
to be re-implemented in component and action.
(just like `getPropertyValue` (which I think should be re-implemented in component and action too (for the same reason)))
This would allow manipulating camitk properties only with QStrings and not with a mix of qstrings and char* types depending on the method being used.
## Acceptance tests
- **SetProperty works with QString**
One is able to set a property with the setProperty method using a QSting for the first argument
- **All uses of setProperty in CamiTK and CEPs are updated**
CamiTK and CEPs compile without errors regarding the setProperty method
## Track
One (or two) of:
## Misc
- Automatic subscription of issue creator:
**Do not forget to mark this issue as "confidential"** by checking the tick box below (if appropriate)| | |
|--|--|
| **As a** | CEP developer |
| **I would like** | a `setProperty` with `const QString name` instead of `const char * name` |
| **To** | improve camitk code consistency |
| **Epic/Topics** | Property setProperty QString char* |
## Description / Overview
I noticed that the `QObject::setProperty` method prototype demands a `const char *` type for the first argument whereas the `camitk::Property` constructor and the `getProperty` method use a `QString` type.
I think it might be a good idea to implement a method looking like
```cpp
//PropertyObject.h
virtual bool setProperty(const QString name, const QVariant &value);
```
```cpp
//PropertyObject.cpp
bool PropertyObject::setProperty(const QString name, const QVariant &value) {
if (propertiesMap.contains(name)) {
return setProperty(name.toStdString().c_str(), value);
}
else {
return false;
}
}
```
,
to be re-implemented in component and action.
(just like `getPropertyValue` (which I think should be re-implemented in component and action too (for the same reason)))
This would allow manipulating camitk properties only with QStrings and not with a mix of qstrings and char* types depending on the method being used.
## Acceptance tests
- **SetProperty works with QString**
One is able to set a property with the setProperty method using a QSting for the first argument
- **All uses of setProperty in CamiTK and CEPs are updated**
CamiTK and CEPs compile without errors regarding the setProperty method
## Track
One (or two) of:
## Misc
- Automatic subscription of issue creator:
**Do not forget to mark this issue as "confidential"** by checking the tick box below (if appropriate)Feature RequestTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/67Protocol file associated with the action state machine2018-07-09T15:39:29+02:00Emmanuel PromayonProtocol file associated with the action state machine## About you
CamiTK team member.
## Product
action state machine
## Overview
This is issue was created by splitting issue #57 originally submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11.
This issue is about providing an associated protocol file to enable double-click to start the action state machine from a desktop without using the command line.
> Currently, we need to open a terminal and type this kind of command to start asm:
>
> camitk-actionstatemachine -f <ProtocolFile> -o <LogFolder>
>
> Since Action State Machine can be used by 'basic user' to run new protocol, it would be easier if a launcher or an interface were available.
>
> ~~For instance:#~~
> ~~- a gui interface in order to select which protocol should be started~~
> ~~or~~
> a specific protocol file (only changing extension by .asm, .prot, .protocolASM ...) to be associated to asm executable. Thus, users only have to double click to start application
>
> -- Antoine Tacheau
## Hints
The best would probably be to :
- add another option to the command line `--protocol-file` (or something like that)
- parse the corresponding `.prot` file (or `.casm` of, as `.asm` extension is [already used a lot, especially for assembler](https://fileinfo.com/extension/asm) and the other suggestion is very looong!)
- a `.prot` can be a very simple file with
- first line: the filepath to the `.scxml`
- second line: filepath to the output directory
- add another page to the Qt Wizard describe above to ask the user if she/he wants to save a corresponding `.prot` for later reuse
- make sure that at file can be associated to the application (on windows reproduce what is done in camitk-imp: at first launch, ask the user if s⋅he wants `.prot` to be associated directly to the application).
- write a wiki documentation to show how to associate `.prot` files to the action state state machine for Windows, KDE and MacOS X
## About you
CamiTK team member.
## Product
action state machine
## Overview
This is issue was created by splitting issue #57 originally submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11.
This issue is about providing an associated protocol file to enable double-click to start the action state machine from a desktop without using the command line.
> Currently, we need to open a terminal and type this kind of command to start asm:
>
> camitk-actionstatemachine -f <ProtocolFile> -o <LogFolder>
>
> Since Action State Machine can be used by 'basic user' to run new protocol, it would be easier if a launcher or an interface were available.
>
> ~~For instance:#~~
> ~~- a gui interface in order to select which protocol should be started~~
> ~~or~~
> a specific protocol file (only changing extension by .asm, .prot, .protocolASM ...) to be associated to asm executable. Thus, users only have to double click to start application
>
> -- Antoine Tacheau
## Hints
The best would probably be to :
- add another option to the command line `--protocol-file` (or something like that)
- parse the corresponding `.prot` file (or `.casm` of, as `.asm` extension is [already used a lot, especially for assembler](https://fileinfo.com/extension/asm) and the other suggestion is very looong!)
- a `.prot` can be a very simple file with
- first line: the filepath to the `.scxml`
- second line: filepath to the output directory
- add another page to the Qt Wizard describe above to ask the user if she/he wants to save a corresponding `.prot` for later reuse
- make sure that at file can be associated to the application (on windows reproduce what is done in camitk-imp: at first launch, ask the user if s⋅he wants `.prot` to be associated directly to the application).
- write a wiki documentation to show how to associate `.prot` files to the action state state machine for Windows, KDE and MacOS X
BacklogFeature RequestTrack Dev SupportTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/66Load mha rotation/translation in the proper order2018-06-21T09:58:44+02:00Emmanuel PromayonLoad mha rotation/translation in the proper order## About you
This was a bug submitted to the old bugzilla by Guillaume Custillon on 2016-03-17
## Overview
> When loading an mhd/mha image that contains some transformation, the translation (offset) is not handled correctly.
> Indeed, the rotation matrix should be applied and then the translation in the world frame. However, on CamiTK the rotation is applied, and then the translation in the rotated frame.
## Steps to Reproduce
> - Open imp and load the attached mha test image:
>
> [test_frame_image.mha](/uploads/f3a59f67822c289391ac36321be032af/test_frame_image.mha)
>
> It is a 2D image with a rotation of 45° around z axis and a translation of 10 mm on the x axis.
> - Display the world frame.
## Actual VS Expected Result
> - Observe the location of the image: the translation is not made on the x axis of the world frame, but on the x axis of > the rotated image frame.
## Relevant logs and/or screenshots:
## Interpretation & Possible fixes:
This is the answer given by @jaffarda on 2016-03-22
> Following is based on the test image provided by Guillaume.
>
> ***** The Bug, reworded ******
> According to the data in file:
> TransformMatrix (which contains rotation matrix of frame) is
> 0.707 -0.707 0 0.707 0.707 0 0 0 1
> and
> Offset (which contains translation of frame) is
> 10 0 0
>
> Opening this image with camiTK:
> rotation is OK
> translation become 7.07 7.07 0
>
> in other words, the translation is applied in rotated frame, but we expect it to be applied in world frame
>
> ***** suggested fix *****
>
> based on tests on this image,
>
> in ImageComponent.cpp (line 290), the line
> ```cpp
vtkMatrix4x4::Multiply4x4(rotationMatrix, initialTranslation->GetMatrix(), initialFrameMatrix);
> ```
> should become :
> ```cpp
> vtkMatrix4x4::Multiply4x4(initialTranslation->GetMatrix(), rotationMatrix, initialFrameMatrix);
> ```
>
> ***** WARNING *****
> This change in a core file should only be commit after deep tests on every thing it may impact.
## CamiTK Version:
This was submitted for CamiTK 3.5.0.svn but is still present in CamiTK 4.1.develop## About you
This was a bug submitted to the old bugzilla by Guillaume Custillon on 2016-03-17
## Overview
> When loading an mhd/mha image that contains some transformation, the translation (offset) is not handled correctly.
> Indeed, the rotation matrix should be applied and then the translation in the world frame. However, on CamiTK the rotation is applied, and then the translation in the rotated frame.
## Steps to Reproduce
> - Open imp and load the attached mha test image:
>
> [test_frame_image.mha](/uploads/f3a59f67822c289391ac36321be032af/test_frame_image.mha)
>
> It is a 2D image with a rotation of 45° around z axis and a translation of 10 mm on the x axis.
> - Display the world frame.
## Actual VS Expected Result
> - Observe the location of the image: the translation is not made on the x axis of the world frame, but on the x axis of > the rotated image frame.
## Relevant logs and/or screenshots:
## Interpretation & Possible fixes:
This is the answer given by @jaffarda on 2016-03-22
> Following is based on the test image provided by Guillaume.
>
> ***** The Bug, reworded ******
> According to the data in file:
> TransformMatrix (which contains rotation matrix of frame) is
> 0.707 -0.707 0 0.707 0.707 0 0 0 1
> and
> Offset (which contains translation of frame) is
> 10 0 0
>
> Opening this image with camiTK:
> rotation is OK
> translation become 7.07 7.07 0
>
> in other words, the translation is applied in rotated frame, but we expect it to be applied in world frame
>
> ***** suggested fix *****
>
> based on tests on this image,
>
> in ImageComponent.cpp (line 290), the line
> ```cpp
vtkMatrix4x4::Multiply4x4(rotationMatrix, initialTranslation->GetMatrix(), initialFrameMatrix);
> ```
> should become :
> ```cpp
> vtkMatrix4x4::Multiply4x4(initialTranslation->GetMatrix(), rotationMatrix, initialFrameMatrix);
> ```
>
> ***** WARNING *****
> This change in a core file should only be commit after deep tests on every thing it may impact.
## CamiTK Version:
This was submitted for CamiTK 3.5.0.svn but is still present in CamiTK 4.1.developBugSandboxTrack DebuggingTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/65Unexpected image behaviors in Viewers2018-07-11T13:30:11+02:00Emmanuel PromayonUnexpected image behaviors in Viewers## About you
Bug filed on Bugzilla by @jaffarda on 2016-04-22
## Overview:
> when looking at an image in 2D viewer (axial for exemple)
> - pb1/ border voxels are only half-sized (both in 2D and in 3D)
> - pb2/ border box does not adjust to displayed image
> - pb3/ picking is not possible a all places inside pixels
> - pb4/ picking is possible outside the image
> - pb5/ picking actor (crossing bars are not always visible)
> attached images are very small in number of voxels for a better view
> provided:
> - testImage.bmp (the expected visble result)
> - testData.raw (raw file for 2D images)
> - testData3D.raw (raw file for 3D image)
> - test1.mhd ( image 5x5x1 black & white grid, spacing 10x10x1)
> - test2.mhd ( image 5x5x1 black & white grid, spacing 1x1x1)
> - test_3D.mhd ( image 5x5x5 black & white grid, spacing 1x1x1)
[testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Steps to Reproduce
> - step 1/ Load test1.mhd in camitk
> - step 2/ click on centralViewer and press I (to toogle off image interpolation)
> - step 3/ open axial viewer (ctrl + 2)
> - step 4/ Pick a point (ctrl + click) close to the middle of a pixel
> - step 5/ Pick a point (ctrl + click) close to the border of a pixel
> - step 6/ Pick a point (ctrl + click) close to the middle of a pixel but on the outside of the displayed image
> - step 7/ Load test2.mhd, open axial viewer, toogle off interpolation
> - step 8/ Pick a point (ctrl + click) close to the middle of a pixel
## Actual VS Expected Result
> - at step 2/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb2 the border does not match the image but should
> - at step 5/ we see pb3 picking works close to centre of pixel but nowhere else
> picking should be available everwhere
> - at step 6/ we see pb4 it is possible to pick a point outside the image,
> it should not
> - at step 8/ we see pb5 when picking works (see with pb3) the actor (small lines) are not visible, it should
## Relevant logs and/or screenshots:
See [testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Interpretation & Possible fixes:
> - pb1/ maybe miss set of dimensions?
> - pb2/ probably linked to pb1 the boxing seems to be the good size if pixels were correctly displayed
> - pb3/ maybe bad use of pixel size?
> - pb4/ probably linked to pb1 the selection box should be in pixel if pb1
> - pb5/ no ideas
## CamiTK Version:
Filed for CamiTK 3.6, but confirmed still on 4.1.develop## About you
Bug filed on Bugzilla by @jaffarda on 2016-04-22
## Overview:
> when looking at an image in 2D viewer (axial for exemple)
> - pb1/ border voxels are only half-sized (both in 2D and in 3D)
> - pb2/ border box does not adjust to displayed image
> - pb3/ picking is not possible a all places inside pixels
> - pb4/ picking is possible outside the image
> - pb5/ picking actor (crossing bars are not always visible)
> attached images are very small in number of voxels for a better view
> provided:
> - testImage.bmp (the expected visble result)
> - testData.raw (raw file for 2D images)
> - testData3D.raw (raw file for 3D image)
> - test1.mhd ( image 5x5x1 black & white grid, spacing 10x10x1)
> - test2.mhd ( image 5x5x1 black & white grid, spacing 1x1x1)
> - test_3D.mhd ( image 5x5x5 black & white grid, spacing 1x1x1)
[testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Steps to Reproduce
> - step 1/ Load test1.mhd in camitk
> - step 2/ click on centralViewer and press I (to toogle off image interpolation)
> - step 3/ open axial viewer (ctrl + 2)
> - step 4/ Pick a point (ctrl + click) close to the middle of a pixel
> - step 5/ Pick a point (ctrl + click) close to the border of a pixel
> - step 6/ Pick a point (ctrl + click) close to the middle of a pixel but on the outside of the displayed image
> - step 7/ Load test2.mhd, open axial viewer, toogle off interpolation
> - step 8/ Pick a point (ctrl + click) close to the middle of a pixel
## Actual VS Expected Result
> - at step 2/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb2 the border does not match the image but should
> - at step 5/ we see pb3 picking works close to centre of pixel but nowhere else
> picking should be available everwhere
> - at step 6/ we see pb4 it is possible to pick a point outside the image,
> it should not
> - at step 8/ we see pb5 when picking works (see with pb3) the actor (small lines) are not visible, it should
## Relevant logs and/or screenshots:
See [testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Interpretation & Possible fixes:
> - pb1/ maybe miss set of dimensions?
> - pb2/ probably linked to pb1 the boxing seems to be the good size if pixels were correctly displayed
> - pb3/ maybe bad use of pixel size?
> - pb4/ probably linked to pb1 the selection box should be in pixel if pb1
> - pb5/ no ideas
## CamiTK Version:
Filed for CamiTK 3.6, but confirmed still on 4.1.developBug ConfirmedSandboxTrack DebuggingTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/64Make management of decl export/import easier on Windows2018-06-18T14:56:01+02:00Emmanuel PromayonMake management of decl export/import easier on Windows| | |
|--|--|
| **As a** |CEP developer] |
| **I would like to** | have a hassle free development time on windows |
| **So that** | I can spend more time prototyping |
## About you
This is a merge between
- a feature request submitted on the old bugzilla by Céline on 2016-01-18, and titled "The wizard should create a API.h file when an action depends on a local CEP component"
- a story suggested on the old icescrum by myself on 2013-01-15, and titled "simplification of declspec export etc..."
- a story suggested on the old icescrum by Céline on 2014-06-04, and titled "Inclure les decl_export dans le Wizard"
## Product
cepgenerator and wizard
## Overview
On windows you need to declare that you "export" the symbols when you are compiling a library and "import" the symbol when you are linking to the library.
That means that you have to **modify** your code for these two phases. This is generally done by using a macro (defined as export and import when MSVC is used or as nothing for other compiler).
This feature requests ask for automatic management of this not obvious behaviour.
This can be done by:
- use a specific macro that (with the combination of `Q_DECL_EXPORT`/`Q_DECL_IMPORT` or the basic `__declspec(dllexport)`/`__declspec(dllimport)`
- automatically include all symbols thanks to [CMake WINDOWS_EXPORT_ALL_SYMBOLS property](https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/)
- smoothly integrated this in the wizard/cepgenerator (see below)
### cepgenerator/wizard integration
> The wizard should create a API.h file when an action depends on a local CEP component
>
> Create a new CEP with the wizard, containing a new Component (e.g. Albert's Component). Then create an action extension (e.g. Albert's Action) which depends on Albert's Component.
> The wizard adds a
> `NEEDS_COMPONENT_EXTENSION albertscomponents`
> in the action extension `CMakeLists.txt`, which is really great as the user do not have to look at the CMakeLists.txt anymore.
>
> However, if the user is on Windows (which do not really know how to make real dynamic libraries), he/she will need a file name AlbertsComponentAPI.h in his/her Albert's Component extension, a
> `DEFINES COMPILE_ALBERTSCOMPONENTS_API`
> in Component's extension CMakeList and a
> `class ALBERTSCOMPONENTAPI AlbertsComponent `
> declaration in its .h file...
>
> -- Céline
### References
- https://doc.qt.io/qt-5/qtglobal.html#Q_DECL_EXPORT
- https://doc.qt.io/qt-5/sharedlibrary.html
- https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/
- old doc: https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/BuildingWinDLL
- old doc: https://cmake.org/cmake/help/v2.8.10/cmake.html#module:GenerateExportHeader| | |
|--|--|
| **As a** |CEP developer] |
| **I would like to** | have a hassle free development time on windows |
| **So that** | I can spend more time prototyping |
## About you
This is a merge between
- a feature request submitted on the old bugzilla by Céline on 2016-01-18, and titled "The wizard should create a API.h file when an action depends on a local CEP component"
- a story suggested on the old icescrum by myself on 2013-01-15, and titled "simplification of declspec export etc..."
- a story suggested on the old icescrum by Céline on 2014-06-04, and titled "Inclure les decl_export dans le Wizard"
## Product
cepgenerator and wizard
## Overview
On windows you need to declare that you "export" the symbols when you are compiling a library and "import" the symbol when you are linking to the library.
That means that you have to **modify** your code for these two phases. This is generally done by using a macro (defined as export and import when MSVC is used or as nothing for other compiler).
This feature requests ask for automatic management of this not obvious behaviour.
This can be done by:
- use a specific macro that (with the combination of `Q_DECL_EXPORT`/`Q_DECL_IMPORT` or the basic `__declspec(dllexport)`/`__declspec(dllimport)`
- automatically include all symbols thanks to [CMake WINDOWS_EXPORT_ALL_SYMBOLS property](https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/)
- smoothly integrated this in the wizard/cepgenerator (see below)
### cepgenerator/wizard integration
> The wizard should create a API.h file when an action depends on a local CEP component
>
> Create a new CEP with the wizard, containing a new Component (e.g. Albert's Component). Then create an action extension (e.g. Albert's Action) which depends on Albert's Component.
> The wizard adds a
> `NEEDS_COMPONENT_EXTENSION albertscomponents`
> in the action extension `CMakeLists.txt`, which is really great as the user do not have to look at the CMakeLists.txt anymore.
>
> However, if the user is on Windows (which do not really know how to make real dynamic libraries), he/she will need a file name AlbertsComponentAPI.h in his/her Albert's Component extension, a
> `DEFINES COMPILE_ALBERTSCOMPONENTS_API`
> in Component's extension CMakeList and a
> `class ALBERTSCOMPONENTAPI AlbertsComponent `
> declaration in its .h file...
>
> -- Céline
### References
- https://doc.qt.io/qt-5/qtglobal.html#Q_DECL_EXPORT
- https://doc.qt.io/qt-5/sharedlibrary.html
- https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/
- old doc: https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/BuildingWinDLL
- old doc: https://cmake.org/cmake/help/v2.8.10/cmake.html#module:GenerateExportHeaderFeature RequestSandboxTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/63Allow the wizard to create an action that target a custom component2018-06-15T18:26:42+02:00Emmanuel PromayonAllow the wizard to create an action that target a custom component## About you
Submitted as a bug by Nicolas Saubas on Bugzilla on 2015-07-22 as "Wizard does not allow an action to target a custom component others than the ones proposed"
Submitted for CamiTK Version 3.5 (SVN) but still present in 4.0.x and 4.1.develop
## Product:
wizard
## Overview:
> When creating an action, we can not specify a custom component other than the ones proposed by default (ImageComponent, > MeshComponent, CameraComponent, PhysicalModelComponent).
>
> Create a CEP using the wizard. Add a action using the GUI of the wizard. Once you reach the step of adding an action, the Wizard proposes you with a dropdownlist the different default components.
> You cannot add a custom one (one that you will add AFTER creating this action, one that you have already created in another CEP ...)
>
> A custom textbox should proposes a custom component for the action to target on.
>
> --- Nicolas
---
**please do not remove anything below this line**## About you
Submitted as a bug by Nicolas Saubas on Bugzilla on 2015-07-22 as "Wizard does not allow an action to target a custom component others than the ones proposed"
Submitted for CamiTK Version 3.5 (SVN) but still present in 4.0.x and 4.1.develop
## Product:
wizard
## Overview:
> When creating an action, we can not specify a custom component other than the ones proposed by default (ImageComponent, > MeshComponent, CameraComponent, PhysicalModelComponent).
>
> Create a CEP using the wizard. Add a action using the GUI of the wizard. Once you reach the step of adding an action, the Wizard proposes you with a dropdownlist the different default components.
> You cannot add a custom one (one that you will add AFTER creating this action, one that you have already created in another CEP ...)
>
> A custom textbox should proposes a custom component for the action to target on.
>
> --- Nicolas
---
**please do not remove anything below this line**Feature RequestSandboxTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/60Developer documentation for MainWindow2018-06-13T18:11:57+02:00Emmanuel PromayonDeveloper documentation for MainWindow## About you:
Submitted by Guillaume Custillon on Bugzilla, 2014-04-07
## Product:
CamiTK CE (SDK)
## Overview:
> The global documentation for MainWindow is not enough.
> It would be a good idea to write a more detailed one (listing step by step what you have to do to create a MainWindow, ie how to add viewers etc…).
> This could be added in the global documentation for MyMainWindow or maybe in a wiki page## About you:
Submitted by Guillaume Custillon on Bugzilla, 2014-04-07
## Product:
CamiTK CE (SDK)
## Overview:
> The global documentation for MainWindow is not enough.
> It would be a good idea to write a more detailed one (listing step by step what you have to do to create a MainWindow, ie how to add viewers etc…).
> This could be added in the global documentation for MyMainWindow or maybe in a wiki pageFeature RequestSandboxTrack Dev Supporthttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/59Auto center option in InteractiveViewer2018-06-15T18:17:15+02:00Emmanuel PromayonAuto center option in InteractiveViewer## About you
This is a feature request that summarizes two bugs submitted on the old bugzilla:
- "InteractiveViewer option for specifying whether the scene must be centered when a Component is added" submitted by Hadrien Oliveri on 2015-07-07
- "Impossible to scroll through a zoomed image without the image automatically de-zooming" submitted by Nikolai on 2015-01-16
## Product:
imp
## Overview:
### Hadrien's submission
> Hello everyone,
> I'm developping a surgery simulator, and I need to add Components during the simulation. By default, the scene is
> recentered by the InteractiveViewer each time a Component is added (which is quite annoying). I modified this locally in
> my sdk and it works well for my ad hoc needs.
>
> I would be great if recentering the scene by default could be specified in the Imp user preferences for example.
>
> Thank you
>
> -- Hadrien Oliveri
### Nikolai's submission
> Imp de-zooms automatically when it's not expected. In this case, the 2D medical viewer panes de-zoom when you try to scroll through the image's volume with the vertical slider.
>
>
> Steps to Reproduce:
> Open Imp. Open any 3D image. Zoom in on any of the 2D viewers using the scroll wheel of your mouse. Move the vertical slider to another image plane. You will see the viewer de-zoom automatically.
>
>
> The viewer should stay zoomed while scrolling with the sliders.
>
> -- Nikolai
## Interpretation & Possible fixes
Both problems can be solved by implementing a special "Auto Center" option for the `InteractiveViewer`s.
Auto center
- [ ] When a new component is loaded (default is yes)
- [ ] When a slice is changed (default is yes)
As well as a "Center" Icon on the toolbar or the slice viewer side bar.
Depends on #17 ## About you
This is a feature request that summarizes two bugs submitted on the old bugzilla:
- "InteractiveViewer option for specifying whether the scene must be centered when a Component is added" submitted by Hadrien Oliveri on 2015-07-07
- "Impossible to scroll through a zoomed image without the image automatically de-zooming" submitted by Nikolai on 2015-01-16
## Product:
imp
## Overview:
### Hadrien's submission
> Hello everyone,
> I'm developping a surgery simulator, and I need to add Components during the simulation. By default, the scene is
> recentered by the InteractiveViewer each time a Component is added (which is quite annoying). I modified this locally in
> my sdk and it works well for my ad hoc needs.
>
> I would be great if recentering the scene by default could be specified in the Imp user preferences for example.
>
> Thank you
>
> -- Hadrien Oliveri
### Nikolai's submission
> Imp de-zooms automatically when it's not expected. In this case, the 2D medical viewer panes de-zoom when you try to scroll through the image's volume with the vertical slider.
>
>
> Steps to Reproduce:
> Open Imp. Open any 3D image. Zoom in on any of the 2D viewers using the scroll wheel of your mouse. Move the vertical slider to another image plane. You will see the viewer de-zoom automatically.
>
>
> The viewer should stay zoomed while scrolling with the sliders.
>
> -- Nikolai
## Interpretation & Possible fixes
Both problems can be solved by implementing a special "Auto Center" option for the `InteractiveViewer`s.
Auto center
- [ ] When a new component is loaded (default is yes)
- [ ] When a slice is changed (default is yes)
As well as a "Center" Icon on the toolbar or the slice viewer side bar.
Depends on #17 Feature RequestSandboxTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/58CamiTK Wizard display current state2018-06-13T13:31:46+02:00Emmanuel PromayonCamiTK Wizard display current state## About you:
Submitted on bugzilla by Claire Sery, 2015-09-24
## Product:
CamiTK Wizard
## Overview:
> It would be nice (and usefull) to add a tree in the wizard to follow what you create. For example:
>
> CEP NiceCEP
>
> - Library extension
> - First library
> - Second library
> - Action extensions
> - First Action extension
> - action 1
> - action 2
> - Second action extension
> - action 1
> - action 2
> - Component extensions
> - etc
>
> And to can select one of these item to modify it, delete it, etc…
>
> Well, it will be possible to do that with a nice catalog !
Note : this is a good idea of design for the update wizard (that can read an existing CEP). This probably should not be called the wizard anymore, but the "CEP explorer" or something like that.## About you:
Submitted on bugzilla by Claire Sery, 2015-09-24
## Product:
CamiTK Wizard
## Overview:
> It would be nice (and usefull) to add a tree in the wizard to follow what you create. For example:
>
> CEP NiceCEP
>
> - Library extension
> - First library
> - Second library
> - Action extensions
> - First Action extension
> - action 1
> - action 2
> - Second action extension
> - action 1
> - action 2
> - Component extensions
> - etc
>
> And to can select one of these item to modify it, delete it, etc…
>
> Well, it will be possible to do that with a nice catalog !
Note : this is a good idea of design for the update wizard (that can read an existing CEP). This probably should not be called the wizard anymore, but the "CEP explorer" or something like that.Feature RequestSandboxTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/57Launcher wizard for Action State Machine interface2018-07-09T15:59:03+02:00Emmanuel PromayonLauncher wizard for Action State Machine interface## About you
Submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11
## Product
Action state machine
## Overview
> Currently, we need to open a terminal and type this kind of command to start asm:
>
> camitk-actionstatemachine -f <ProtocolFile> -o <LogFolder>
>
> Since Action State Machine can be used by 'basic user' to run new protocol, it would be easier if a launcher or an interface were available.
>
> ~~For instance:~~
> a gui interface in order to select which protocol should be started
> ~~or~~
> ~~- a specific protocol file (only changing extension by .asm, .prot, .protocolASM ...) to be associated to asm executable. Thus, users only have to double click to start application~~ (moved to issue #67)
>
> ~~It is also required to set a default behavior for log file argument~~
>
> -- Antoine Tacheau
As of 4 July 2018, this issue was split in two. Current issue is about showing a dialog if no command line argument is given.
The other issue (issue #67) is about defining a specific "protocol" file that contains the SCXML file as well as the log folder and adding a `-protocol` option to provide this file.
## Hints
I think the best would be to:
- detect the case when the user launches `camitk-actionstatemachine` without any command line arguments (not even `--help`)
- in this case, offer a mini Qt Wizard with:
- 1 page with explanation why the user is asked for more
- 1 page to choose the `scxml`
- 1 page to choose the output directory
- launch the normal process## About you
Submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11
## Product
Action state machine
## Overview
> Currently, we need to open a terminal and type this kind of command to start asm:
>
> camitk-actionstatemachine -f <ProtocolFile> -o <LogFolder>
>
> Since Action State Machine can be used by 'basic user' to run new protocol, it would be easier if a launcher or an interface were available.
>
> ~~For instance:~~
> a gui interface in order to select which protocol should be started
> ~~or~~
> ~~- a specific protocol file (only changing extension by .asm, .prot, .protocolASM ...) to be associated to asm executable. Thus, users only have to double click to start application~~ (moved to issue #67)
>
> ~~It is also required to set a default behavior for log file argument~~
>
> -- Antoine Tacheau
As of 4 July 2018, this issue was split in two. Current issue is about showing a dialog if no command line argument is given.
The other issue (issue #67) is about defining a specific "protocol" file that contains the SCXML file as well as the log folder and adding a `-protocol` option to provide this file.
## Hints
I think the best would be to:
- detect the case when the user launches `camitk-actionstatemachine` without any command line arguments (not even `--help`)
- in this case, offer a mini Qt Wizard with:
- 1 page with explanation why the user is asked for more
- 1 page to choose the `scxml`
- 1 page to choose the output directory
- launch the normal processBacklogFeature RequestTrack Dev SupportTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/54Improved ActionWidget2018-06-12T16:36:23+02:00Emmanuel PromayonImproved ActionWidget| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | change just the parameters tab of the action widget (and have more space for my action widget) |
| **So that** | I can deliver the same user experience (doc and information about selected target) without reimplementing everything |
## Description / Overview
This story is about improving the `ActionWidget` API/usage:
- It should be possible to get/set only the `QFrame` parameters section of default `ActionWidget` (and hence modifying just the "Parameters" part of the widget, see below)
![Screenshot_20180612_143335](/uploads/a1d13000f8029b6b73afde7bd9a97818/Screenshot_20180612_143335.png)
- It should be possible to easily access the frame itself in order to restrict the space used in the GUI (for instance in the action state machine, as in the screenshot below, should we use all this space for description and targets that nobody really look at) ?
![Screenshot_20180612_143650](/uploads/98f907763249155e8ae9f1b4314b8aea/Screenshot_20180612_143650.png)
- The `Description` / `Targets` / `Parameters` section should take less space (use stacked widget like in the mockup below? Tab widget?)
![Screenshot_20180612_160056](/uploads/d513f0839e4f0acb48fc44db33e97027/Screenshot_20180612_160056.png)
![Screenshot_20180612_160109](/uploads/919244814c8295d69b31f7066f52253c/Screenshot_20180612_160109.png)
## Hints
- Add `set/getFrame()` to `ActionWidget`
- modify action state machine to use the `getFrame()` not the full default widget
- rewrite default widget to take less space
## Acceptance test
- [ ] a tutorial showing a demo
- [ ] asm for reconstruction improve the space for parameter interaction
- [ ] Action API doc updated to show this usage| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | change just the parameters tab of the action widget (and have more space for my action widget) |
| **So that** | I can deliver the same user experience (doc and information about selected target) without reimplementing everything |
## Description / Overview
This story is about improving the `ActionWidget` API/usage:
- It should be possible to get/set only the `QFrame` parameters section of default `ActionWidget` (and hence modifying just the "Parameters" part of the widget, see below)
![Screenshot_20180612_143335](/uploads/a1d13000f8029b6b73afde7bd9a97818/Screenshot_20180612_143335.png)
- It should be possible to easily access the frame itself in order to restrict the space used in the GUI (for instance in the action state machine, as in the screenshot below, should we use all this space for description and targets that nobody really look at) ?
![Screenshot_20180612_143650](/uploads/98f907763249155e8ae9f1b4314b8aea/Screenshot_20180612_143650.png)
- The `Description` / `Targets` / `Parameters` section should take less space (use stacked widget like in the mockup below? Tab widget?)
![Screenshot_20180612_160056](/uploads/d513f0839e4f0acb48fc44db33e97027/Screenshot_20180612_160056.png)
![Screenshot_20180612_160109](/uploads/919244814c8295d69b31f7066f52253c/Screenshot_20180612_160109.png)
## Hints
- Add `set/getFrame()` to `ActionWidget`
- modify action state machine to use the `getFrame()` not the full default widget
- rewrite default widget to take less space
## Acceptance test
- [ ] a tutorial showing a demo
- [ ] asm for reconstruction improve the space for parameter interaction
- [ ] Action API doc updated to show this usageBacklogFeature RequestTrack Prototyping Experiencehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/36Interface Data2018-06-13T10:41:45+02:00Emmanuel PromayonInterface Data| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | add easily manipulate array of data (values, signals, vectors...) to any type of component (not MeshComponent nor ImageComponent) |
| **So that** | I can visualize/interact data as colors on a mesh, as graph/curve |
| **Epic/Topics** | Interface Data |
## Description / Overview
The epic is called "Interface Data" or how to include 1D temporal signal in CamiTK.
This is a new facet for `Component` that enables storage, manipulation, visualization and interaction with/of array of data. The idea is to offer data abstraction and minimal default behaviour for signal and temporal values.
In the design stage, first check:
- Check the Pulse project to check how they store the signals
- Check the work done by Nico (see `incubator-local/respirm` CEP) in order to handle 1D signal and their representation using a dedicated viewer based on vtkChart library (and some action to process them). In particular check the viewer and the defined actions.
- Check open-source application that help manipulate data and display charts to deduce best practices
- Check for standard in signal processing data format and processing library (if any)
One idea would be to be able to use a python interface/shell/script in order to process the signal directly from a console...
## Hints
As for any creation of interface in CamiTK, this can be done following these steps:
- Create a new interface that add the management of a list of `vtkDataArray` in `Component`
- Create the corresponding helper class
- Create the corresponding viewer (using vtkChart and the possibility to add data as if it was a live physiological signal) and integrate it to camitk-imp
- Create another viewer to display data in a table/spreadsheet
- Take into account the fact that `MeshComponent` can project the data as colors
- move addPointData/addCellData in `InterfaceGeometry` or to the new `InterfaceData` interface (may be use an enum for `FREE`, `ATTACHED_TO_CELLS`, `ATTACHED_TO_POINTS` etc...
## Acceptance tests
- [ ] a new tutorial component that shows how to add/remove/show these data in the new viewer
- [ ] a new tutorial MeshComponent that shows how data can be displayed directly _on_ the mesh surface
- [ ] a new tutorial that shows generates random value based on a sinus function to show how update/acquisition can be done
## Track
/label ~"Track Technology Integration"| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | add easily manipulate array of data (values, signals, vectors...) to any type of component (not MeshComponent nor ImageComponent) |
| **So that** | I can visualize/interact data as colors on a mesh, as graph/curve |
| **Epic/Topics** | Interface Data |
## Description / Overview
The epic is called "Interface Data" or how to include 1D temporal signal in CamiTK.
This is a new facet for `Component` that enables storage, manipulation, visualization and interaction with/of array of data. The idea is to offer data abstraction and minimal default behaviour for signal and temporal values.
In the design stage, first check:
- Check the Pulse project to check how they store the signals
- Check the work done by Nico (see `incubator-local/respirm` CEP) in order to handle 1D signal and their representation using a dedicated viewer based on vtkChart library (and some action to process them). In particular check the viewer and the defined actions.
- Check open-source application that help manipulate data and display charts to deduce best practices
- Check for standard in signal processing data format and processing library (if any)
One idea would be to be able to use a python interface/shell/script in order to process the signal directly from a console...
## Hints
As for any creation of interface in CamiTK, this can be done following these steps:
- Create a new interface that add the management of a list of `vtkDataArray` in `Component`
- Create the corresponding helper class
- Create the corresponding viewer (using vtkChart and the possibility to add data as if it was a live physiological signal) and integrate it to camitk-imp
- Create another viewer to display data in a table/spreadsheet
- Take into account the fact that `MeshComponent` can project the data as colors
- move addPointData/addCellData in `InterfaceGeometry` or to the new `InterfaceData` interface (may be use an enum for `FREE`, `ATTACHED_TO_CELLS`, `ATTACHED_TO_POINTS` etc...
## Acceptance tests
- [ ] a new tutorial component that shows how to add/remove/show these data in the new viewer
- [ ] a new tutorial MeshComponent that shows how data can be displayed directly _on_ the mesh surface
- [ ] a new tutorial that shows generates random value based on a sinus function to show how update/acquisition can be done
## Track
/label ~"Track Technology Integration"BacklogFeature RequestTrack Technology Integration