Talk:Reslicing P3 REQ

From IGSTK

Jump to: navigation, search

Comments from April 03 Tcon

  1. There are too many classes (3 new representation classes + 3 new plane classes)
  2. Not clear how it could be used in a more complex case when dynamic switching between different reslicing mode is frequent
  3. Suggestion: One single representation class, and a hyper-class for different SicePlaneSpatialObject class?

  1. Notice: To be able to reslice and view the image, the pipe line need to be connected first, thus a TrackerTool's transform can be transformed into the ImageSpatialObject's coordinate system.
    • So there is no need to create another node in the scene graph for ReslicePlaneSpatialObject, this extra node might lead to loop
    • Instead we should use the the internal ImageSpatialObject's coordinate system, since it's already connected to the TrackerTool in the scene graph, and reslicing should always done with respect to the ImageSpatialObject
    • I don't like the idea of changing the View node in the scene graph (In the case of attaching it as the child of a ReslicePlaneSpatialObject)
      1. Drawback 1: It will break the scene graph in Case 1. disconnect ImageSpaitalObject to TrackerTool
      2. Drawback 2: Letting the View sit stable in the scene graph (probably attached to a ImageSpatialObject) and DIRECTLY control its camera, it's more deterministic, controllable, and intuitive to user
        • Imagine if we just attach View to a surgeon with Camera fixed, as the relative position changes, we can not guarantee the Camera is always looking at the patient
      3. Drawback 3: Changing camera position is more similar to the real world: The patient lays stable(Image and View fixed), and the surgeon (Camera) moves around.

  1. Proposed design:
    • Have three different reslicing mode
      1. Orthogonal ( Axial, Sagital, Coronal )
      2. OffOrthogonal ( OffAxial, OffSagital, Perpendicular )
      3. Oblique ( Axial, Sagital, Coronal defined by a 6DOF tool )
    • These different reslicing mode can be implemented as Function class, and set to the ReslicePlaneSpatialObject class
    • Other inputs include:
      1. ImageSpatialObject
      2. TrackerTool, indices, and points


  1. Here illustrate the interaction of two reslicing mode
  2. Notice, View will not be attached to ReslicePlaneSpatialObject as a child, instead it will something called CameraFollow, This can be done by adding an observer to the ResliceMatrix.


Additional thoughts (FL):

  • Our main (initial) concern is the number of classes / couplings introduced. And I'm still a bit confused about how many more there would be in order to support the functionality listed in the requirements section (mouse vs. tracking mode, presenting slice information in 2D views vs. 3D views, etc.). In addition there will be the more advanced slicing of many images + blending wrapping classes as discussed in Washington. It would be nice if the design could present the hole picture (even though everything could not be implemented and once).
  • A "concern-case" could be to dynamically switch from one "view-configuration" to another during navigation, or as simple as switching from orthogonal to oblique slicing (and vice versa), or the switching between the images that is going to be sliced, or switching between the tools that defines how the image should be re-sliced. Our surgeons does this all the time. We had somewhat similar concerns about the modality dependence (MR/CT/USImageSO/SORep), we are happy that the new Generic framework will make multimodal-navigation manageable, we hate to see that similar things are introduced, unless absolutely necessary of course.
  • I'm still confused about why the original design with functions for setting the reslice orientations and ImageSO as well as ToolSO directely connected to the new ImageResliceRep was left. What is the motivation for introducing the new PlaneSO ? Not possible without (automatic pipeline update? why?), more convenient (at least in ways)? And how should the the PlaneSO be connected to the surgical scene graph? What would be the parent (ImageSO, ToolSO, ?). Could you elaborate a little bit about this Andinet? Andinet Consistent with the updating cycle driven by the current design: View --> Representation --> SpatialObject --> TrackerTool <-- Tracker


  • Regarding the 3 (sensible grouping) different slicing modi:
    • All modi takes position from the tool tip (or virtual tool tip), the orientation source differs (image=orthogonal, tool=oblique, image/tool/external=hybrid).
    • The first two are general, well-defined and should well-known to the IGS community.
    • The Hybrid/Combined/Composite/OffOrthogonal/?? modi should be considered carefully:
      • All combinations off image, tool and external axes are possible (as long as enough axis are specified), but not all combinations are sensible.
      • (external axis could be OR up vector (set by a tracked pointer e.g.), camera up vector, direction taken from an endoscope (possible, corresponding/blending views), surgical path, etc.)
      • Patrick et. al. have found a good combination for a given clinical application, and I'm sure that this combination could be useful for other applications as well, but a lot of other useful combinations exists (some that never have been tested I'm sure), so it would be great if it would be possible to create an interface that made it possible to specify these combinations in a generic way (and a new class for all the possible and useful cases is not an option....).
  • RequestSetSliceNumber and slider driven slicing is mentioned.
    • I don't see the need for a an "indexed" mode in navigation and slider-based slicing in order to locate a point in 3D (e.g. landmark reg.) is not optimal from a user-perceptive, but I guess that this could be added without affecting the general framework (forcing the orthogonal mode to be indexed for example)?
  • Size / Spacing is not specified.
    • Making it possible to set the ImageReslic size/spacing equal to the in plane ImageSO size/spacing would probably be useful.
  • Some final words about naming: Consistency is everything....
    • Is the intension that all:
      • SpatialObject subclasses should end with this, i.e. <subclassname>SpatialObject
      • SpatialObjectRepresentations subclasses should end with this, i.e. < subclassname>SpatialObjectRepresentation
    • If this is important (not consistent in the toolkit today) and we would like to have some characters left for the sub-class-name (describing it in a good way) without creating to long names, maybe we could consider something like <subname>SO and <subname>SORep (yes, I know that this is cursing in the church...).
    • For this component I think that it's important that slice or reslice is part of the name, e.g. ImageResliceSORep (or maybe ResliceImageSORep...)
Retrieved from "http://public.kitware.com/IGSTKWIKI/index.php/Talk:Reslicing_P3_REQ"
Personal tools
TOOLBOX
LANGUAGES