Extension review request : should it be made widely available?

Development
1

Hi,

I tinkered these custom markups that draw primitive shapes, and intend to add a few more shapes.

Apart from this practical use, I don’t find any useful application yet, at least in the surgical field of my concern.

I’m wondering if core developers would find value in these and if yes, whether any should be made available to others.

They can of course be updated following your advice, slowly though.

Thank you for any input and regards.

1 Like
2

I like it.

You may combine your efforts with @rbumm about the labels

3

Thank you for considering contributing this, I think it would be useful.

The only thing I’m not sure about if it is better to provide it in Markups module or Dynamic modeller module. If it is mainly for quantification (measuring diameters, areas, distances, etc.) then Markups make more sense; if it is for modelling (cutting out regions, building new shapes, etc.) then Dynamics modeller would be more appropriate. Maybe we could have both, but the redundancy could confuse users and increase maintenance workload.

I would also consider implementing a single “Basic shape” markup instead of having a 4 separate markup type. It would mean less code to maintain and would allow users to switch between different shapes.

1 Like
4

Well it does not have any goal yet ! All this sprung from the post I mentioned above. I thought about inclusion in the SandBox extension, and honestly, don’t know how useful it can be.

Here, I find it much easier to maintain in separate objects. Once an object is being edited, reasoning is focused and constrained. A single markup managing multiple shapes implies a lot of conditionals and it’s easy to get lost in the mind this way. Moreover, reading the code becomes more complex, at least to me.

Please refer me to prior work about labels in this case. @rbumm

5

I am working on ENH: Add connector line for fiducial markup label texts (ENH: Add connector line for fiducial markup label texts by rbumm · Pull Request #6188 · Slicer/Slicer · GitHub)

but the PR needs to be activated somehow (fell behind perhaps because of Slicer 5 release). I am ready to restart this any time but need input from the core developers @lassoan

6

If you have any remaining questions then post them in the pull request. If you have time we can work on this as a project at the upcoming project week. Maybe we can finalize everything and get it integrated by the end of the week.

7

Ring, disk, ellipse, sphere, and ellipsoid are all just special cases of a “hollow ellipsoid”. Ring and disk are special case of ellipsoid (size along the third axis = 0). Disk is a special case of ring (hole size is 0). Disk is a special case of ellipse (both axes have the same size). etc.

If we add one module for each markup then we end up with 5 * 25 = 125 files. This is a very large number. In contrast, if we add a single module then probably we only need to have separate classes for the VTK widget and representation, which would mean 19 + 5 * 6 = 49 files. Still a large number, but somewhat more manageable. It is also nice that you can switch between a sphere and ellipsoid without deleting and recreating a markup.

The manual label markup is indeed somewhat overlaps with @rbumm’s automatic label display work. I’m not sure if both are needed. Some kind of arrow markup could be useful, but maybe improving the line markup to allow oriented line ending would be sufficient.

There are a number of things to improve, but these markups might be already usable for some things, so it could make sense to make it available for users for experimenting.

1 Like
8

Hi @lassoan,

I merged the three primitives in one single Shape markups. Please comment.

If you still think that wide availability is of interest, a Slicer related repository (Sandbox?) should be found. I still don’t wish to propose it as an extension, because in a few months, I won’t have my mind deep in it. Someone else may find useful work to do with it. It would then be easier for him to extend from a Slicer controlled repository.

Regards.

1 Like
9

Hi,

Sorry to request your attention one last time.

This project has been much improved since its inception, with more shapes and a module. I still think it might be useful to others, that’s why it’s open source on github.

I suggest that core devs have a look when they find spare time(!), and say whether built binaries should be made available to Slicer users.

I know only 2 ways to that end :

  • share the project as a Slicer extension (with some kind of bureaucracy, sorry)
  • integrate the project in an existing extension.

Looking forward for your comments.

Regards.