2018.12.04 Hangout

(Jean Christophe Fillion Robin) #1


We will be having our weekly hangout at 10:00 AM EST.

Since we will have the project week call at 10:30 AM (details here), this call will last only 30mins.

On the agenda:

Other topics are always welcome!!

Anyone is welcome to join to ask questions at https://bit.ly/slicer-googlemeet-hosted-by-kitware



Hi JC,
I am traveling this week and will not be able to make the phone call.


(Sara Rolfe) #3

I tried to join this call, but am having trouble. Is it going on now?

(Andras Lasso) #4

I’m waiting to be let in, too.

(Sara Rolfe) #5

Hi @lassoan, I was hoping to ask if there are updates on the changes being made to the markups module. Could you let me know if you have any new information?

(Andras Lasso) #6

Markups are being completely reworked. There will be markups for points, lines, angles, curves, they will be much simpler (so that we can add many new features) and faster. Probably they will be ready for public testing in January.

(Murat Maga) #7


Do these changes include other things we discussed previously like the glyph size taking now of voxel sizes?

These are important for our user base and project.

(Andrey Fedorov) #8

@lassoan this is great news! Do you have something like a labs page with the summary of what types of markups will be supported? It would be nice to coordinate this with what is commonly used by radiologists. Are you planning to support circle/ellipse, for example? Bi-dimensional measurements? Do you anticipate it will be a big effort to add new types of annotations with the new infrastructure?

It would be very nice to work out the DICOM interoperability for those annotations, especially since we have several other tools that support planar markups. I am interested to help with that.

Sorry I had a conflict and would not be able to join the meeting, even if I knew this was going to be discussed.

(Steve Pieper) #9

+1 for a labs page about new markups/annotation infrastructure.


Hi all,

Are there any plans to switch to Python 3 and IPython? I haven’t seen anything in the Slicer 5 roadmap.


Also, two more topics that might be worth discussing:

(Andras Lasso) #12

Yes, we’ll soon switch to Python3 - I’ve added this explicitly to the page: https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/MigrationGuide/Slicer50#Python3

I’m not sure we’ll bundle IPython packages in the Slicer installer, but we’ll consider it.

Is this related to Slicer5? Is any change in Slicer code needed to make build scripts available?

4D image support was added in Slicer several years. We now have DICOM import/export, sequence registration, cropping, visualization, recording, video compression, intensity plotting, etc. Moreover, 4D record/replay/editing/saving/loading is supported not just for volumes but all nodes - models, markups, segmentations, etc.

Could you be a bit more specific about what features you are looking for?

(Andras Lasso) #13

I’ve updated the markups lab page with some more details - mostly high-level design considerations and long-term plans: https://www.slicer.org/wiki/Documentation/Labs/Improving_Markups

In the first step, we’ll rework markups module and add a few new markup widgets (line, angle, curve). The new design should make it feasible to add new features and new widgets.

(Davide Punzo) #16

Yes, I confirm that most likely the new infrastructure will be available around January. Here there are few preview videos (in the audio, I explain the interactions) (pure VTK) of what we are developing:

Reading the lab page, the new widget rework that I am doing should cover the majority of the desired improvements.

Our idea is to have for a first implementation everything within Slicer (vtkwidgets in Modules/Loadable/Markups/VTKWidgets, and for each widget a relative markups node, etc…). This will allow a much faster prototype, dev and test (then in future we may move them upstream in VTK). In addition, having the widget directly in Slicer will allow additional feature: save the state of the scene for undo at each widget interaction, easier communication between different 2D/3D views, etc…

The vtkwidgets have few layers of abstract classes, so it should be relatively easy to implement a new annotations with the new widgets.

From point of view of implementation at VTK level we don’t use anymore the vtkHandle to interact with the widget. This will greatly boost the performance (the fps while interacting with a closed curve with 2000 points were still > 30) and make all the infrastructure much easier/lighter.