Hi Stefan, That absolutely makes sense. I think using weights to determine the influence of each point is an excellent approach. I have a few additional thoughts that might help improve the method: 1. We could use a temporary storage approach to prevent modifications to the original contour in place. For example, when hovering over a position on the contour, we can store the contour vertices that lie within distance D (whether existing or programmatically created) in a temporary data structure. This would allow changes to be previewed before they are committed. Once finalized, the temporary vertices can be applied to the original contour, which will later help with traversal, as you mentioned earlier. 2. Instead of randomly sampling X vertices within distance D, I think it might make more sense to add a fixed number of vertices within D. However, I’m still uncertain about how you plan to handle this, as it depends entirely on the model we’re working with.
For reference, I’ve attached a skull-based sample DICOM dataset, which represents the type of data I’ll be working with. Feel free to use it to generate a model and observe how the static contour appears. I hope this helps in understanding whether the vertices are densely or sparsely distributed, as well as other relevant factors. Looking forward to your thoughts! Best*,* Mujassim Skull_sample.zip <https://drive.google.com/file/d/1NXJ_ZnmvTCnJsXR5VN--xIa_r572svM6/view?usp=drive_web> On Mon, 24 Mar 2025 at 13:52, Dinkelacker, Stefan < s.dinkelac...@dkfz-heidelberg.de> wrote: > > Hi Mujassim, > > yes, an approach in that direction is reasonable. I think I would write a > function that traverses from the hover point in both directions along the > contour for a certain distance D (should be easy since two points are > always connected by a straight line). Each contour vertex that is within D > I would pair with a weight like a vertex at the hover point would have > weight 1, a vertex in distance D/2 would have weight 0.5 and a vertex in > distance D would have weight 0. The returned list of pairs (probably made > up of vertex index and weight) I would use to decide on which points the > move operation has influence on and how much. The weight can also be > directly used to calculate a color for rendering like in my example picture. > > There's an edge case for tiny contours, though, when basically more or > less all points are within distance D. So probably I would also take the > contour's complete circumferrence into account to decide if D should be > decreased to never cover more than a certain percentage of a contour's > circumferrence, or simething similar. A strategy for this is greatly > dependent on the contour's you are expecting in the first place, like will > they have dense or sparse vertices, what is the typical ratio of distance > between vertices and the whole circumferrence etc... > > Best, > Stefan > > ________________________________________ > Von: Mujassim Jamal <mujassimjama...@gmail.com> > Gesendet: Freitag, 21. März 2025 12:21 > An: Dinkelacker, Stefan > Cc: mitk-users@lists.sourceforge.net > Betreff: Re: [Extern] - [mitk-users] Contour Editing in MITK > > Hi Stefan, > > While implementing the custom mapper for neighbor highlighting, I realized > that I first need to identify the neighboring points before I can highlight > them. This means that creating and identifying neighbor points within the > contour itself is an essential prerequisite. > > It might be more effective to focus on neighbor detection first before > moving on to the rendering and appearance aspects. For reference, I have > attached a picture showing the contour I am working on, which consists of > six vertices. Here’s the basic approach I have in mind: > > 1. A position is hovered over on the contour (marked in red at vertex 1 > or between vertices 5 and 4). > 2. If a vertex is found at that position, proceed to the next step; > otherwise, first add a point at that location. > 3. The algorithm will then attempt to find neighboring points on both > sides of the hovered position within a specified radius (marked in green). > 4. If no neighboring points are found, 'X' number of points will be added > in both directions of the hovered position within the radius. > 5. Finally, the identified points to be highlighted will be passed to the > rendering process. > > Does this approach make sense to you? I’d appreciate your thoughts on it. > > Best, > Mujassim > > > On Mon, 17 Mar 2025 at 19:36, Dinkelacker, Stefan < > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de>> > wrote: > Hi Mujassim, > > interactors typically just change state/properties of data. The > transformation into render primitives happens in mapper classes, which > (re-)generate the VTK (or OpenGL in legacy cases) primitives on any > data/property updates. Long story short: if you want to change anything > regarding the appearance of data, you would need to write (potentially > derive) your own mapper. Unfortunately mappers in the regime of > PlanarFigures or ContourModelSets are, let's say, part of a technical dept > that were never resolved, and while they are working, they shouldn't > probably be used as examples for new implementations. You still can do so, > of course, but in general new mappers should be derived from > mitk::VtkMapper. > > Best regards, > Stefan > ________________________________________ > Von: Mujassim Jamal <mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>> > Gesendet: Montag, 17. März 2025 13:10 > An: Dinkelacker, Stefan > Cc: mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net> > Betreff: Re: [Extern] - [mitk-users] Contour Editing in MITK > > Hi Stefan, > > Yes, the Lasso tool better aligns with my needs. I tested > ContourModelInteractor, set up the MITK-ProjectTemplate, created a custom > interactor class inheriting from ContourModelInteractor, and implemented a > function to enable interaction on the saved contour node, following your > instructions. I also prefer this approach from scratch rather than the > vtkCutter approach you mentioned in your other post. > > Before implementing the OnMovePoint function, I plan to first develop a > neighbor highlighting feature for the contour. This feature will highlight > the neighboring areas of a point when hovered over with the mouse. Users > will also be able to adjust the highlighted area, allowing modifications to > only that portion of the contour rather than the entire area between two > points (which I believe is the default behavior). Currently, > ContourModelInteractor highlights the entire contour when hovered over. > > Could you share your thoughts on this approach? > > Best regards, > Mujassim > > On Fri, 21 Feb 2025 at 12:14, Dinkelacker, Stefan < > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de > ><mailto:s.dinkelac...@dkfz-heidelberg.de<mailto: > s.dinkelac...@dkfz-heidelberg.de>>> wrote: > Hi Mujassim, > > let's assume you would start with the lasso tool [1] instead of the > livewire tool, which uses the same base class but seems to fit your needs > even better. The base class EditableContourTool [2] sets up the state > machine "EditableContourTool.xml" for the creation of the contour and > connects most of the functions. The derived LassoTool class then only > connects the MovePoint action in addition. But all of this interaction is > for the creation of the contour, not for editing. In > LassoTool::FinishTool() you will see, however, that another > DataInteractor/StateMachine is associated with the created contour data > node: ContourModelInteractor [3] with > ContourModelModificationInteractor.xml as state machine. In this class you > find the OnMovePoint() method which is called when moving a point of the > contour. That's where you want to hook in to add your functionality. You > can do this for example by subclassing ContourModelInteractor and > overriding the OnMovePoint() method. > > To understand/test the ContourModelInteractor in the MITK Workbench first, > activate the Segmentation plugin, create a segmentation, select the Lasso > tool from the 2D tools and remove the checkmark from "Auto-confirm > contour". This is crucial. Start a contour with a double click, add points > with single clicks and add the last point again with a double click. Now > the editable contour should still be on the screen and you can test the > ContourModelnteractor by moving an existing point of the contour for > example. > > To start with such a contour right from the beginning I recommend to save > the contour so you can simply open it later without having to use the > segmentation plugin. The contour node from the lasso tool is invisible by > default, though. To make it visible, open the preferences (Ctrl+P), click > on Data Manager on the very top and set the checkmark for "Show helper > objects". While the Lasso tool is active with an editable contour, you will > see a "working contour node" node in the Data Manager now. You can > right-click on it and "Save..." it to a .cnt file, that you can later open > again. > > When you implement your subclass you can activate the interaction by > calling either DataInteractor::SetDataNode() or > DataNode::SetDataInteractor() on a contour node. A good starting point for > that is probably your own plugin/view and to wire up a button to do so. > Start best with the MITK-ProjectTemplate [4] where you could modify the > Example View for your first prototype [5]. > > [1] https://docs.mitk.org/2024.12/classmitk_1_1LassoTool.html > [2] https://docs.mitk.org/2024.12/classmitk_1_1EditableContourTool.html > [3] https://docs.mitk.org/2024.12/classmitk_1_1ContourModelInteractor.html > [4] https://github.com/MITK/MITK-ProjectTemplate/blob/master/README.md > [5] > https://github.com/MITK/MITK-ProjectTemplate/blob/master/Plugins/org.mitk.gui.qt.exampleplugin/src/internal/QmitkExampleView.cpp > > Best, > Stefan > ________________________________________ > Von: Mujassim Jamal <mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>>> > Gesendet: Dienstag, 18. Februar 2025 13:41 > An: Dinkelacker, Stefan > Cc: mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net><mailto:mitk-users@lists.sourceforge.net > <mailto:mitk-users@lists.sourceforge.net>> > Betreff: Re: [Extern] - [mitk-users] Contour Editing in MITK > > Hi Stefan, > > I followed your instructions and explored the LiveWire tool, which helped > me understand how it leverages ContourModelLiveWireInteractor for various > interactions. I also reviewed its corresponding state machine and > configuration XML files, which were quite easy to follow. > > Next, I traced the inheritance hierarchy of ContourModelLiveWireInteractor > up to DataInteractor, where each class has a ConnectActionsAndFunctions > function responsible for linking state machine actions to interactor > functions (as you mentioned in an earlier response). The description of the > DataInteractor class also states that new interactor classes can be derived > from it. > > From this point, what would you recommend as my next step? Should I > proceed with creating a new interactor and its associated XML files, or is > there anything else I should refer to before diving into the implementation? > > Looking forward to your guidance. > > Best, > Mujassim > > On Tue, 11 Feb 2025 at 15:33, Dinkelacker, Stefan < > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de > ><mailto:s.dinkelac...@dkfz-heidelberg.de<mailto: > s.dinkelac...@dkfz-heidelberg.de>><mailto:s.dinkelac...@dkfz-heidelberg.de > <mailto:s.dinkelac...@dkfz-heidelberg.de><mailto: > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de>>>> > wrote: > Hi Mujassim, > > I think at this stage an example-based exploration is probably the most > efficient way of going forward. For the Live Wire tool, see [1] for example > and move up the inheritance until you find the code using an Interactor. An > Interactor is connected to a state machine and a separate config for that > statemachine. Both are written as .xml files. The Interactor code connects > actions and conditions of a statemachine to its methods. > > Best, > Stefan > > [1] https://docs.mitk.org/2024.12/classmitk_1_1LiveWireTool2D.html > ________________________________________ > Von: Mujassim Jamal <mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>>>> > Gesendet: Dienstag, 11. Februar 2025 04:46 > An: Dinkelacker, Stefan > Cc: mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net><mailto:mitk-users@lists.sourceforge.net > <mailto:mitk-users@lists.sourceforge.net>><mailto: > mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net > ><mailto:mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net>>> > Betreff: Re: [Extern] - [mitk-users] Contour Editing in MITK > > Hi, > > Yes, I previously built MITK v2023.12, but I encountered several compiler > errors related to ITK (conversion type errors) and POCO (OpenSSL version > mismatch). > > Thank you for suggesting these four tools. I have explored all of them and > found that the Draw Polygon and LiveWire tools closely match my use case, > though I will still need to make significant customizations. I plan to > refer to the code of these two tools to get an initial understanding of > point adding, dragging, picking, etc. > > I would appreciate it if you could share any resources on developing a > custom interactor in MITK. > > Best, > Mujassim > > On Wed, 5 Feb 2025 at 17:28, Dinkelacker, Stefan < > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de > ><mailto:s.dinkelac...@dkfz-heidelberg.de<mailto: > s.dinkelac...@dkfz-heidelberg.de>><mailto:s.dinkelac...@dkfz-heidelberg.de > <mailto:s.dinkelac...@dkfz-heidelberg.de><mailto: > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de > >>><mailto:s.dinkelac...@dkfz-heidelberg.de<mailto: > s.dinkelac...@dkfz-heidelberg.de><mailto:s.dinkelac...@dkfz-heidelberg.de > <mailto:s.dinkelac...@dkfz-heidelberg.de>><mailto: > s.dinkelac...@dkfz-heidelberg.de<mailto:s.dinkelac...@dkfz-heidelberg.de > ><mailto:s.dinkelac...@dkfz-heidelberg.de<mailto: > s.dinkelac...@dkfz-heidelberg.de>>>>> wrote: > Hi and welcome to MITK! > > The last version of MITK that supported Qt 5 was MITK v2023.12, as far as > I know. Starting with later versions, Qt 6.6+ is a strict requirement. > > To get started, I recommend running the MitkWorkbench application and > exploring the contour interaction functionalities available in two > different plugins: > > - Measurement [1]: The Draw Polygon and Draw Subdivision Polygon tools > demonstrate how contours can be interacted with. > > - Segmentation [2]: The Lasso and LiveWire tools are both based on contour > interaction. > > MITK provides at least two approaches for working with contours and > interacting with them. However, you will need to write some code—for > example, handling a Modified event to map contour changes back to a 3D > model (referred to as a Surface in MITK). Additionally, MITK's current > interactors only operate on individual contour vertices. > > If you aim to implement an approach similar to what you showed in your > video—where multiple neighboring vertices of a contour are modified > simultaneously—you will need to develop a custom interactor. While this is > certainly possible, it is not the simplest task for a first MITK project. > > Best, > Stefan > > [1] https://docs.mitk.org/2024.12/org_mitk_views_measurement.html > [2] > https://docs.mitk.org/2024.12/org_mitk_views_segmentation.html#org_mitk_views_segmentationlivewiretool > > ________________________________________ > Von: Mujassim Jamal <mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>>><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com><mailto:mujassimjama...@gmail.com<mailto: > mujassimjama...@gmail.com>>>>> > Gesendet: Mittwoch, 5. Februar 2025 11:27 > An: mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net><mailto:mitk-users@lists.sourceforge.net > <mailto:mitk-users@lists.sourceforge.net>><mailto: > mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net > ><mailto:mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net>>><mailto: > mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net > ><mailto:mitk-users@lists.sourceforge.net<mailto: > mitk-users@lists.sourceforge.net>><mailto:mitk-users@lists.sourceforge.net > <mailto:mitk-users@lists.sourceforge.net><mailto: > mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net > >>>> > Betreff: [Extern] - [mitk-users] Contour Editing in MITK > > Hi, > > First of all, I am new to using MITK. I am working with Qt 5.15.2, but I > couldn't find an MITK version compatible with this Qt version. Therefore, I > built the latest version of MITK (v2024.12). > > My question is: Can I use the MITK toolkit to create a contour editing > feature such that, after projecting a 3D model as a contour onto the 2D > segmentation, I can pick and drag the points on the contour in 2D and see > the effect directly on the 3D model? I found that MITK provides various > contour-related classes, but I am unsure whether they can be used for my > specific use case. > > I am attaching a Google Drive link that contains a video showcasing what I > want to achieve using MITK. > Video: > https://drive.google.com/file/d/1Wu3UJmQQeewlR0Thvx7TPP0iYLEmfu1J/view?usp=sharing > > Thank you. >
_______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
