Add the capability to prescribe existing segmentations to individual findings

[fedorov]

See discussion at http://slicer-users.65878.n3.nabble.com/prescribing-existing-segmentation-and-accessing-SUV-by-parsing-DICOM-Metadata-td4028511.html

[fedorov]

@naucoin and @mehrtash can you give me an estimate how much time it will take to implement this feature?

[fedorov]

@naucoin if you are not done with the Reporting orientation precision issue (and its relatives!) you were working on, ignore this, let me know when you are done.

[fedorov]

@mehrtash @naucoin please let me know when you think you can give me an idea how difficult this will be to implement. Let me know if we need to meet to discuss. Thanks.

[naucoin]

I'm getting the next pull request together today for the precision issue, will take a look at the new feature for this issue this afternoon.

[naucoin]

As I understand it, the request is to add segmentations loaded from disk or otherwise created and use it as a finding.
The Findings section of the LongitudinalPETCT module has a node selector drop down that's currently limited to showing only nodes of type
vtkMRMLLongitudinalPETCTFindingNode
It's a subclass of a vtkMRMLNode, not a vtkMRMLScalarVolumeNode which is what would get produced if you loaded in a label map volume or created one via the editor. I haven't worked my way through all the code but it looks like it's keeping track of "annotations and markups" but I need to dig deeper to tease out how those map onto Slicer infrastructure terms.
So, from a first glance, I think that translating between a "regular" label map scalar volume and a Finding will require an import method that can distill the label map volume into it's seperate labels and add each one to a finding node.
Do you know if that conversion method already exists somewhere?

Also: it sounds like this is very much related to the work that Andras and Csaba will be doing on the new segmentations for Slicer, so it would make more sense in the long term to convert this module to use their algorithms rather than to work with the current label volumes.

[naucoin]

If I've misunderstood the problem or the code, let's meet in person to go over it for sure.

[fedorov]

Thanks! Can you look into the vtkMRMLLongitudinalPETCTFindingNode? Somewhere down there it must keep a reference to the label node, so we would just need to initialize it correctly. There is no custom internal representation for the segmentation, so no algorithmic conversion is needed.

[naucoin]

I dug more into this and ran the screencast tutorial so I could understand the workflow a bit better (the code has some copy/paste errors or at least ambiguities in the node documentation).
I think it might work if we added a new button to the Findings panel, beside Add Segmentation to Finding to add an external segmentation to the finding. The current button is defined in a .ui, a connection is set up in the qMRMLLongitudinalPETCTFindingWidget.cxx file to fire the signal addSegmentationToFinding, this is listend to from the python file SlicerLongitudinalPETCTModuleWidget.py to trigger the python method onAddSegmentationToFinding to do the book keeping. That's the method that would need to be copied and modified to make a new segementation node from an existing label map scalar volume, possibly with the assumption that the user set up the editor label etc on the finding already. I'd have to do a bit more digging and experimentation to figure out what needs to get set/reset/imported to make it work (there are some high level variables that are held onto in the module, I'd have to verify that they get reset if you reset values on nodes).

[fedorov]

Thanks! Let's talk before you do anything else on this issue. I want to take a look myself and then discuss with you.

[naucoin]

Sounds good, I'm not feeling confident yet that I have the whole workflow sussed out.

[fedorov]

Let's explore the idea to allow user to select a label volume that already exists in the scene in this popup dialog raised on "Create finding". The label volume associated with the newly created finding should be populated by resampling the user-selected label volume to the label volume matching the image geometry. If there are multiple label values in the user-selected label volume, threshold all to the color selected by the user.

It looks like there is a label volume associated with the report node created by LongitudinalPETCT DICOM plugin.

For the reference, the architecture of the extension should be described to some degree in Paul's thesis: http://www.spl.harvard.edu/publications/item/view/2444

When done, add a comment to the info button about this capability: "You can select existing label volume to initialize finding segmentation"

[naucoin]

First pass at extending the dialog, was this close to what you meant?

[fedorov]

Yes, I think this is fine

On Fri, Jun 5, 2015 at 1:08 PM, Nicole Aucoin [email protected]
wrote:

First pass at extending the dialog, was this close to what you meant?
[image: initdisabled]
https://cloud.githubusercontent.com/assets/289054/8011110/e11fc672-0b83-11e5-9b9c-14b2ceef9f6a.jpg
[image: initexpanded]
https://cloud.githubusercontent.com/assets/289054/8011112/e5f43e1c-0b83-11e5-846d-4f3337593964.jpg

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

[naucoin]

Please check out my branch and see if it does what you expect.

[fedorov]

Nicole, when do you estimate this issue will be resolved?

[naucoin]

Debugging it today (took a lot of refactoring to move the functionality), hopefully by the end of tomorrow a new version of the topic branch will be ready for feedback.

[naucoin]

I've got a missing connection (the new finding accept button isn't working correctly, though it works if you press cancel instead), but other than that it seems to be sucessfully refactored. I'll take another look at it on Monday morning and share the branch for review.

[naucoin]

The accept button is working now, and I'm trying to ensure that I don't over write the prior volume when thresholding it (makes it hard to init a second finding from the first!). Current branch does the over write:
https://github.com/naucoin/LongitudinalPETCT/tree/1-Add-the-capability-to-prescribe-existing-segmentations-to-individual-findings

[naucoin]

I think this is working now, I tested it with the PETCTFusion data set and went through each logic path. The prior segmentation drop down widget is behaving unpredicatably though so I had to hide some nodes and unset/reset the MRML scene on it.