CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2023-10-13T18:11:11+02:00https://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/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 abo...## 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
https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/54Improved ActionWidget2024-03-25T18:04:17+01: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 informati...| | |
|--|--|
| **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 usagehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/30Easy action GUI/widget for specific properties2018-06-13T10:43:51+02:00Emmanuel PromayonEasy action GUI/widget for specific properties| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | easily add/easily manage specific high-level properties/parameters to my action |
| **So that** | my action source code is only focusing on the processing |
## Descript...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | easily add/easily manage specific high-level properties/parameters to my action |
| **So that** | my action source code is only focusing on the processing |
## Description / Overview
This story is about having an easy way to declare and manage specific high level properties in actions.
In an `Action` derived class it should be easy to add properties (and automatically create their GUI) for the following:
- `QStringList` → dropdown list
- list of instanciated/available components (with possible restriction to components of a given type) → GUI = dropdown list
- list of `MedicalImageViewer` viewers → GUI = dropdown list
- button (name + icon + tristate or not + double state or not + slot to call) → GUI = `QPushButton` automatically added to the default `ActionWidget` that calls the slot.
Therefore it should be possible to directly write something like:
```cpp
// MyAction constructor
MyAction::MyAction(..) : .. {
...
QStringList myList;
myList << "A" << "B" << "C";
addParameters(new Property(tr("List of strings"), myList, ...);
Property *listOfComp = new Property(tr("Image 1", Property::LIST_OF_COMPONENT, ...);
listOfComp->setAttribute("componentName", "ImageComponent");
addParameters(listOfComp);
addParameters(new Property(tr("Viewer to show"), Property::LIST_OF_MEDICAL_VIEWERS, ...);
Property *pushMeProp = new Property(tr("Push Me"), SLOT(pushMeSlot()), ...);
pushMeProp->setAttribute("checkable",true);
pushMeProp->setAttribute("icon",QIcon(":/images/myIcon.png"));
addParameters(pushMeProp);
...
}
```
## Acceptance test
- [ ] there is a tutorial showing how to use these highlevel
- [ ] the Action and Property API documentation is updated
- [ ] the wizard allow for the creation of such properties
- [ ] the CEP generator is aware of these properties and there are new tests in the `cepgenerator/testing/cepgernerator-test.sh`
- [ ] any action in CamiTK CE that manages this type of high-level properties otherwise should use the new way
https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/101viewer extension dependencies in wizard2023-06-02T16:49:24+02:00Maxime Calkaviewer extension dependencies in wizard## About you
Occasional CamiTK developer
## Product
Wizard
## Overview
Add in the dependencies of the extension the possibilities to link a viewer extension.
## Relevant logs and/or screenshots
Already implemented:
![image](/uploa...## About you
Occasional CamiTK developer
## Product
Wizard
## Overview
Add in the dependencies of the extension the possibilities to link a viewer extension.
## Relevant logs and/or screenshots
Already implemented:
![image](/uploads/d5dac9ba6884a5565013cbc41f370457/image.png)
Needed:
![image](/uploads/4c4851f8c2277b4c451ecd4129a12339/image.png)Maxime CalkaMaxime Calkahttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/65Unexpected image behaviors in Viewers2023-05-15T15:59:39+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...## 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.develophttps://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...## 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 https://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/151Picking a point changes selected object and makes current Action disappear2024-03-25T17:54:17+01:00Manik BhattacharjeePicking a point changes selected object and makes current Action disappear## About you
CamiTK developper
## Overview
While creating a CEP, an action that uses multiple components was written and needs to get point coordinates from a click in a viewer.
When clicking on the point, if the image in the viewer is...## About you
CamiTK developper
## Overview
While creating a CEP, an action that uses multiple components was written and needs to get point coordinates from a click in a viewer.
When clicking on the point, if the image in the viewer is not the selected imageComponent, the picking action changes the selection. The action is then hidden because the selection changed.
## Steps to Reproduce
This is visible when using Meniscare CamiTK CEP and the ManualRegistration3D action.
Load two volumes (e.g. brain.mha and sinus-displaced.mha).
In the action, select one of the images, and Ctrl+Click on the image in a slice viewer.
Click on the "pick" button in the action to get the coordinates.
## Actual VS Expected Result
If the image shown in the viewer (the one "selected" in the Action widget) is not the selected component of CamiTK Application, the image is selected, and the action disappears because the component selection changed.
## Interpretation & Possible fixes
This is due to the [selectionChanged(comp)](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/blob/develop/sdk/libraries/core/viewer/InteractiveViewer.cpp#L2165) in InteractiveViewer. The same applies to other picking modes in the same InteractiveViewer::picked() function.
I think this is done to show in the PropertyExplorer the coordinates of the picked point when it is clicked (which needs the ImageComponent to be selected), and hiding the action is a side effect of that.
I see two ways to fix this problem:
- do not change the selected component when a point is picked, but that might break the behavior of displaying the picked coordinates in the "selection" tab of the PropertyExplorer
- A large change in CamiTK: separate completely the notion of selected components in the Application with the currently running Action. I mean that when an action is open on selected components, the fact that the selection changes in the application should not hide the action. The action should only be closed if the component disappears (closed) or the action is closed by the user. This means rethinking what an action can be, e.g. an action can be instantiated multiple times, and there should be an ActionExplorer that lists currently opened actions. In this way, we could run the same action twice with different parameters at the same time.
## CamiTK Version
CamiTK 5.1.dev.develop.f3f104d8
---
**please do not remove anything below this line**https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/138Add support for RGBA color2023-06-05T17:16:25+02:00Manik BhattacharjeeAdd support for RGBA color## About you
CamiTK developer
## Product
MeshComponent
## Overview
MeshComponent can have associated data. If the display mode is COLOR, the data is read as RGB data.
If there is a 4th dimension (A for alpha transparency), this is no...## About you
CamiTK developer
## Product
MeshComponent
## Overview
MeshComponent can have associated data. If the display mode is COLOR, the data is read as RGB data.
If there is a 4th dimension (A for alpha transparency), this is not supported.
It should be checked whether data works if it is encoded as:
- double/float between 0 and 1,
- int 8/16/32 bits in their respective range
## Relevant logs and/or screenshots
Check commit d827e23daf036652c10657bd57f12d0819ba0891
In libraries/core/mesh/MeshComponent.cpp
`colorArrayToDisplay->SetTuple3(i, val[0], val[1], val[2]);`
should work when there are 4 values with setTuple4. Hopefully VTK would use that as RGBA.
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://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...| | |
|--|--|
| **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)