Can't modify a table in "Tables" module after using "Landmark Registration" module

Development
1

To reproduce:

  • Use the “Landmark Registration” module to register any pair of RGB images (I used ThinPlate Registration type);

  • Go to the “Tables” module, create a new table, and try to add columns or rows using the interface. It will be irresponsive;

2

Can you share with us a scene with that you can reproduce this? Have you tried with the latest Slicer Preview Release?

3

I have tried with the latest preview, and had the same problem.

Sending a scene won’t do much since the problem only happens when you acess the Landmark Registration module (you don’t even need to finish a registration, just add and select two plain jpg images to register and click apply to start the registration), and then access the Tables module, create a table and try to add columns and rows.

4

Yes, I was able to replicate this behavior. After using LandmarkRegistration the qMRMLTableView gets into a bad state somehow. I have no idea why at this point.

5

I could reproduce the issue, too. I’ll submit a fix today.

1 Like
6

The problem is caused by incorrect handling of batch processing in qMRMLTableView. I’ve pushed a fix.

It is related to Landmark Registration module, which uses batch processing mode excessively. Probably the original intent was to speed up things, but switching to batch processing mode is a very expensive operation by itself, because it invalidates contents of widgets, so they need to rebuild themselves from scratch. Doing it for simple operations can cause very significant performance hit, especially when the scene has many nodes. Instead of scene-level batch processing, node-level start/end-modified and pause/resume-render should be used for performance optimization.

7

Thanks for the fix @lassoan :+1:

I suppose LandmarkRegistration could change, but I’ve never notice any performance issues related to batch processing mode, even in scenes with dozens of volumes and other things loaded (there are lots of other things that have do need fixing in Landmark Registration though to make it more useful).

8

Each node selector, subject hierarchy view, etc. widget contain a scene model, which may take significant amount of time to rebuild from scratch after batch processing. If you load the brain atlas scene (it contains 1200 nodes) then each node selector adds about 5 ms, each subject hierarchy tree view adds about 15 ms to the time to get out of batch processing, which can easily add up to hundreds of ms. It may still be hardly noticeable, but if modules started to use batch processing to try to speed up simple operations then it would actually slow down the application.

I fully agree, though, that there are much more important things to improve in landmark registration.

9

Thank you @lassoan and @pieper. :+1: