Difference between revisions of "2012 Summer Project Week:XNATSlicerIntegration"

From NAMIC Wiki
Jump to: navigation, search
 
(45 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
<gallery>
 
<gallery>
 
Image:PW-MIT2012.png|[[2012_Summer_Project_Week#Projects|Projects List]]
 
Image:PW-MIT2012.png|[[2012_Summer_Project_Week#Projects|Projects List]]
Image:XNATSlicer_SC_07_08_12.png|Module Screenshot - June 2012
+
Image:XNATSlicer_SC_07_08_12.png|Module Screenshot 1 - June 2012
 +
Image:XNATSlicerSC23--6-12.PNG|Module Screenshot 2 - June 2012
 +
Image:XNATSlicerSC2--6-12.PNG|Module Screenshot 3 - June 2012
 
</gallery>
 
</gallery>
  
Line 8: Line 10:
 
* Washington University in St. Louis: Daniel Marcus, Sunil Kumar
 
* Washington University in St. Louis: Daniel Marcus, Sunil Kumar
 
* Isomics: Steve Pieper
 
* Isomics: Steve Pieper
 +
 +
<div style="margin: 20px;">
 +
<div style="width: 27%; float: left; padding-right: 3%;">
  
 
<h3>Objective</h3>
 
<h3>Objective</h3>
Allow data exchange between XNAT and Slicer.  A detailed objective list can be found [here][http://www.na-mic.org/Wiki/index.php/Talk:2012_Summer_Project_Week:XNATSlicerIntegration].
+
Allow data exchange between XNAT and Slicer.  A detailed objective list can be found [http://www.na-mic.org/Wiki/index.php/Talk:2012_Summer_Project_Week:XNATSlicerIntegration here].
<br>1) Download and view scans (as DICOMS).
+
 
<br>2) Create and upload Slicer Scenes to XNAT, using XNAT-downloaded scans OR locally stored files.
+
</div>
<br>3) Any uploaded Slicer scene package that references XNAT data will be linked to the data via a URL.  The module will recognize the remote links and conduct the necessary legwork such that when a scene is downloaded, the referenced files will also be downloaded.  This involves parsing the mrmls, linking the referenced directories to XNAT URLs, for uploading scenes and vice-versa for downloading scenes.
+
 
<br>4) Update Slicer scenes stored in XNAT.  The interface will be contained entirely within Slicer.  The end-state aims to leverage XNAT's web interface. The current state uses the XNAT REST API to construct a tree view.
+
<div style="width: 27%; float: left; padding-right: 3%;">
<br>5) The widget will also allow for the storage and reference of Slicer-related files such as annotations, fiducials, volumes, etc.  In the end-state, the widget will have the capacity to specifically isolate annotation files to be integrated in XNAT search queries. 
 
  
 
<h3>Approach, Plan</h3>
 
<h3>Approach, Plan</h3>
Line 22: Line 26:
 
Phase 2: Solidify UI and functionality though user testing.<br>   
 
Phase 2: Solidify UI and functionality though user testing.<br>   
 
Phase 3: Port the REST API-based UI into a web-based UI.<br>
 
Phase 3: Port the REST API-based UI into a web-based UI.<br>
 +
 +
</div>
 +
 +
<div style="width: 40%; float: left;">
  
 
<h3>Progress</h3>
 
<h3>Progress</h3>
 
As of June 2012, a beta version of this widget is being tested.
 
As of June 2012, a beta version of this widget is being tested.
  
<br>
+
 
 +
</div>
 +
</div>
  
 
==Known Issues==
 
==Known Issues==
<h3>Crashing Frequency During "Update Scene" Workflow (MEDIUM) </h3>
+
<h3>Increased Crash Frequency</h3>
The module tends to crash more frequently during the "Update Scene" workflow.  <br> Next step: define a replicatable test.
+
<i>Downloading Larger Data Sets - XNAT REST API</i><br>
 +
The module tends to crash more frequently during the download of larger data sets.  Likely a thread issue.  Determination of next steps currently in process.<br>
 +
<i>Closing scenes</i><br>
 +
The close scene command (ctrl+w) sometimes results in Slicer crashing.  Unsure if the cause is internal to Slicer, or the widget.
 +
 
 +
<h3>DICOM Details Popup </h3>
 +
The XNAT-Slicer module utilizes the DICOM Details Popup (from the DICOM module) after a user loads a scan folder of DICOM images from the XNAT.  While this communication is incredibly useful, we believe a few adjustments to the DICOM module would streamline the workflow of XNAT-Slicer.<br>
 +
 
 +
<i>1 - Refreshing DICOM Details Popup:</i><br>After downloading a scan in the XNAT-Slicer module, the "DICOM Details" popup lists the downloaded DICOMs only when the popup hasn't yet been used in the current Slicer session.  If the popup has already been used/opened, the "DICOM Details" popup does not list the new set.  This is  in spite of the downloaded files being successfully inserted in Slicer's SQL DICOM database.  In this scenario, when the user restarts Slicer and opens the DICOM module, they will find that the "DICOM Details" popup contains the newly downloaded set.  This is likely the result of a highly controlled "refresh" condition in reading the updated database.  This may be by design, and consequently a "fix" by be out of reach.  <br> Next step: Inquire if the popup can be refreshed or a one-off "Details Popup" window can be developed that will allow the developer to control its behavior.<br>
  
<h3>DICOM Details Popup (NICE TO HAVE)</h3>
+
<i>2 - Customization of DICOM Details Popup:</i><br>If a user downloads a DICOM folder off of XNAT, it would be nice to have the ability to load a customized "DICOM Details" popup where the only DICOM set presented is the one the user just downloadedRight now, the popup lists all DICOM sets downloaded by the user.<br> Next Step: inquire what the effort would be to create such a customized popup.
The XNAT-Slicer module utilizes the DICOM Details Popup (from the DICOM module) after a user downloads a scan folder of DICOM imagesWhile this communication is incredibly useful, we believe a few adjustments to the DICOM module would improve the workflow of the XNAT-Slicer integration.<br><br>
 
  
Issue 1 - Refreshing: After downloading a scan in the XNAT-Slicer module, the "DICOM Details" popup lists the downloaded DICOMs only when the popup hasn't yet been used in the current Slicer session.  If the popup has already been used/opened, the "DICOM Details" popup does not list the new set, in spite of being successfully inserted in the cache/database. In this scenario, when the user restarts Slicer and opens the DICOM module, they will find that the "DICOM Details" popup contains the newly downloaded set. This is likely the result of a highly controlled "refresh" condition in reading the updated database. This may be by design, and "fixing" it may be involved. <br> Next step: Inquire if the popup can be refreshed or a one-off "Details Popup" window can be developed that will allow the developer to control its behavior.<br><br>
+
<h3>Scene Packaging: </h3>
 +
(Refers to command "slicer.app().applicationLogic().SaveSceneToSlicerDataBundleDirectory()")<br>
 +
<i>1 - Spaces in file names:</i><br>
 +
Investigate the possibility of eliminating the use of spaces in the packaged filenames. (Ex. "Master Scene View.png" should become "MasterSceneView.png").<br>
 +
<i>2 - More Control Over How Scenes Are Packaged:</i><br>
 +
Assess to what control is given over how scenes are packaged: compression of DICOMS, file localization (paths), etc.
  
Issue 2 - Customization: If a user downloads a DICOM folder off of XNAT, it would be nice to have the ability to load a customized "DICOM Details" popup where the only DICOM set presented is the one the user just downloadedRight now, the popup lists all DICOM sets downloaded by the user.<br> Next Step: inquire what the effort would be to create such a customized popup.
+
<h3>MRML Adjusting: </h3>
 +
<i>1- Altering directory references and volumes:</i><br>
 +
Parsing the MRML and changing URLs from local references to remote references has some consequences in terms of how volumes are built.  It appears that volume names are stored deeper than the MRML file itself.  Therefore, changing filenames and filepaths could lead to Slicer not being able to find the volumes.  This is evidenced in testing conducted with a potential user -- renamed filenames in the MRML apparently reference volume names not apparent in the MRML itself (likely embedded in the referenced files)Consequently, changing the filenames in the MRML is only one step of many that need to occur in changing the filenames.
  
==Delivery Mechanism==
+
<h3>XNAT Install Check: </h3>
 +
<i>Check for relevant files:</i><br>
 +
Right now the module checks for the XNAT install folder, but does not check for the relevant files.  Needs to be a check in place to make sure they exist.
  
This work will be delivered to the NA-MIC Kit as a (please select the appropriate options by noting YES against them below)
+
<h3>Check for Updated Nodes </h3>
 +
<i>Lag times:</i><br>
 +
About 60% of the lag time in the "Update Scene" workflow comes from resending unmodified data sets back to XNAT.  Need to determine the simplest way to get Slicer to check if a node has been modified.
  
#Slicer Module - YES
+
<h3>Empty or Unmodified Scene </h3>
 +
Determine the best way to check for an empty or unmodified scene.
  
==Known Issues==
+
<h3>Firewall issues for some users</h3>
 +
Acquire thoughts on ways to circumvent firewall issues -- sample data, access to XNAT server and extensions behind a firewall.
  
 
==References==
 
==References==

Latest revision as of 16:50, 18 June 2012

Home < 2012 Summer Project Week:XNATSlicerIntegration

Key Investigators

  • Washington University in St. Louis: Daniel Marcus, Sunil Kumar
  • Isomics: Steve Pieper

Objective

Allow data exchange between XNAT and Slicer. A detailed objective list can be found here.

Approach, Plan

Phase 1: Develop a beta module that fulfills the outlined objectives.
Phase 2: Solidify UI and functionality though user testing.
Phase 3: Port the REST API-based UI into a web-based UI.

Progress

As of June 2012, a beta version of this widget is being tested.


Known Issues

Increased Crash Frequency

Downloading Larger Data Sets - XNAT REST API
The module tends to crash more frequently during the download of larger data sets. Likely a thread issue. Determination of next steps currently in process.
Closing scenes
The close scene command (ctrl+w) sometimes results in Slicer crashing. Unsure if the cause is internal to Slicer, or the widget.

DICOM Details Popup

The XNAT-Slicer module utilizes the DICOM Details Popup (from the DICOM module) after a user loads a scan folder of DICOM images from the XNAT. While this communication is incredibly useful, we believe a few adjustments to the DICOM module would streamline the workflow of XNAT-Slicer.

1 - Refreshing DICOM Details Popup:
After downloading a scan in the XNAT-Slicer module, the "DICOM Details" popup lists the downloaded DICOMs only when the popup hasn't yet been used in the current Slicer session. If the popup has already been used/opened, the "DICOM Details" popup does not list the new set. This is in spite of the downloaded files being successfully inserted in Slicer's SQL DICOM database. In this scenario, when the user restarts Slicer and opens the DICOM module, they will find that the "DICOM Details" popup contains the newly downloaded set. This is likely the result of a highly controlled "refresh" condition in reading the updated database. This may be by design, and consequently a "fix" by be out of reach.
Next step: Inquire if the popup can be refreshed or a one-off "Details Popup" window can be developed that will allow the developer to control its behavior.

2 - Customization of DICOM Details Popup:
If a user downloads a DICOM folder off of XNAT, it would be nice to have the ability to load a customized "DICOM Details" popup where the only DICOM set presented is the one the user just downloaded. Right now, the popup lists all DICOM sets downloaded by the user.
Next Step: inquire what the effort would be to create such a customized popup.

Scene Packaging:

(Refers to command "slicer.app().applicationLogic().SaveSceneToSlicerDataBundleDirectory()")
1 - Spaces in file names:
Investigate the possibility of eliminating the use of spaces in the packaged filenames. (Ex. "Master Scene View.png" should become "MasterSceneView.png").
2 - More Control Over How Scenes Are Packaged:
Assess to what control is given over how scenes are packaged: compression of DICOMS, file localization (paths), etc.

MRML Adjusting:

1- Altering directory references and volumes:
Parsing the MRML and changing URLs from local references to remote references has some consequences in terms of how volumes are built. It appears that volume names are stored deeper than the MRML file itself. Therefore, changing filenames and filepaths could lead to Slicer not being able to find the volumes. This is evidenced in testing conducted with a potential user -- renamed filenames in the MRML apparently reference volume names not apparent in the MRML itself (likely embedded in the referenced files). Consequently, changing the filenames in the MRML is only one step of many that need to occur in changing the filenames.

XNAT Install Check:

Check for relevant files:
Right now the module checks for the XNAT install folder, but does not check for the relevant files. Needs to be a check in place to make sure they exist.

Check for Updated Nodes

Lag times:
About 60% of the lag time in the "Update Scene" workflow comes from resending unmodified data sets back to XNAT. Need to determine the simplest way to get Slicer to check if a node has been modified.

Empty or Unmodified Scene

Determine the best way to check for an empty or unmodified scene.

Firewall issues for some users

Acquire thoughts on ways to circumvent firewall issues -- sample data, access to XNAT server and extensions behind a firewall.

References