[IGSTK-Developers] Viewer Requirements

[Hee-su Kim]

Rick,

Alright.. "Viewer" meant to be all viewing-related classes..

I was confused with the "View" class.

Thanks,
Hee-Su

  ----- Original Message ----- 
  From: Rick Avila 
  To: 'IGSTK-developers' 
  Sent: Thursday, June 30, 2005 5:46 PM
  Subject: RE: [IGSTK-Developers] Viewer Requirements


   

  Hee-su,

   

              It was not my intent to put all or even most of the viewing parameters directly in the "viewer" classes. Perhaps I did this incorrectly, but I wrote requirements that specify what functionality the toolkit must support, not how it should be implemented or organized in the c++ classes. I was thinking that we first define "what" the toolkit must support and once that is mostly done to define "how" it should be implemented. So I thought that during design discussions I would then propose the organization of classes that would achieve the "functional requirements" we discussed today. That is when the specific classes will be defined (e.g. image object representation) and a deeper set of "implementation requirements" will define class organization and behavior. Let me know if it is standard convention to do both at once and I will revise the requirements accordingly.

   

  - Rick

   


------------------------------------------------------------------------------

  From: igstk-developers-bounces+rick.avila=kitware.com at public.kitware.com [mailto:igstk-developers-bounces+rick.avila=kitware.com at public.kitware.com] On Behalf Of Hee-su Kim
  Sent: Thursday, June 30, 2005 4:00 PM
  To: IGSTK-developers
  Subject: [IGSTK-Developers] Viewer Requirements

   

  Hi, folks:

   

  I have a question. What is the difference between View and Viewer?

   

  I'll just give the outline.

   

  I think View just handles object representations, camera and annotation display parameters. (and updating..)

   

  When viewing images, there are a lot of parameters such as W/L, slicing, volume rendering method, volume rendering parameters and so on..

   

  I think that View requirement will be "to support displaying object representation".. not "to support specific kinds of rendering"

   

  There should be ImageSliceRepresentation and ImageVolumeRepresentation.

   

  ImageSliceRepresentation will have W/L, slicing parameters(like sagittal, coronal, something like that, and slice number), and other necessary parameters. 

   

  Patient information is in ImageObject. 

   

  Some annotations (such as Sagittal View, patient info, ...) will be displayed by View but I think this should be set by an application as multiple images or the annotation for another kind of object(not image) might be displayed.

   

  ImageVolumeRepresentation will have volume rendering-related parameters. (opacity transfer function, color transfer function, method of rendering(raycasting, texture mapping, ...), something like that)

   

  Both representations will have their own pipelines to render images.

   

  View still supports every kind of rendering but not responsible for managing parameters or constructing pipelines for specific kind of rendering.

   

  If View deals with image rendering options, then View class will be messy. (there will be a lot of methods for setting parameters)

   

  With ObjectRepresentation and SpatialObject, multiple images could be displayed readily.

   

  These design considerations were already made by IGSTK developers...

   

  I'm just reminding it..  

   

  Does this make sense?

   

  I thought it's strange that Viewer requirements are too specific with every rendering option and Image seems tied to Viewer. I think Viewer requirements need abstraction and ObjectRepresentation deals with specific rendering options.

   

  I might be wrong. Anyway, this was what I thought.

   

  Regards,

  Hee-Su

   



------------------------------------------------------------------------------


  _______________________________________________
  IGSTK-Developers mailing list
  IGSTK-Developers at public.kitware.com
  http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20050630/cfd4865d/attachment-0002.html>