[IGSTK-Developers] Viewer Requirements

[Rick Avila]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20050630/0a6c9a70/attachment.html>