[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Aeskulap-devel] suggestions

From: Alexander Pipelka
Subject: Re: [Aeskulap-devel] suggestions
Date: Mon, 10 Apr 2006 10:36:40 +0200

Hi Mitchell

Am Sonntag, den 09.04.2006, 13:27 -0400 schrieb Mitchell Laks:
> Dear Alexander,
> I am very impressed and excited about your important work on releasing 
> Aeskulap. 
Thanks. Currently only basic functionality is implemented but that will
change in the future.

> I am going through your code base. Why did you make the design    decision to 
> use  Gdk for  image display and not  gtkglext?
Well, decisions always cause splitted reactions.
I think that it's not necessary to use an OpenGL context for "simple"
image display and manipulations. Another reason was that i already had
(previously written) very fast display and transformation functions
which are proven and stable. Stability on image display should be the
primary goal of a DICOM viewer. People told me that Aeskulap is very
stable and doesn't crash all the time like other apps of this type.
If i would have used OpenGL some people would complain that they can't
use the application on remote X11 displays because many "thin clients"
have problems with remote GL.

> As a radiologist, the ability to do simple manipulations such as rotate, zoom 
> etc is crucial.  I see you have zoom. It is nice. Your Pan seems to be very 
> limited here. Why? 
Yes. The functionality is currently limited. I need input from the
community to add new features and improve functionality.
Why is the "Pan" function limited ?
What would be needed on the "Pan" functionality from your point of
view ?

>  Also annotations are important. Measure distances and 
> measure Hounsefield units and pixel density and averages and standard 
> deviations for circel regions on overlays.
Yes. I'm working on distance measurement (this will cause a rewrite of
the display system). My development plan is to introduce these features
with the 0.3.0 release version.

What I'm currently missing is a list of needed features on "pixel value"
operations. In CVS is currenly a new tool for displaying the raw value
of a pixel under the cursor (e.g. HU in CT images). Other variations are
possible but i need input.

> OpenGl is very well developed and supported. Also well developed acceleration 
> for proprietary OpenGl on  linux - closed source drivers as well as DRI.
As told above. Plain image display shouldn't need GL.

> Also in the future you will you want to incorporate the vtk engine so that 3d 
> applications can be incorporated into the application. Have you reviewed the 
> application  OsiriX available to the mac that is designed in this way?
I took a look at VTK. I'm sure it will be included for 3D
reconstructions in future.

> What is your plan for database backing for the application. Both local exams 
> as well as import from other dicom device. That is crucial. Flat file 
> databases, or basic use of file system are dead in the water for a working 
> radiologist workstation.  Need data persistence and fast startup. 
As soon as the measurement tools are in i need to think about that. I
don't have the proper solution right now. I also need to fully evaluate
the possibilities using DICOM standard procedures.

> I recommend Postgresql, (myssql is also good but Postgresql is very very 
> robust - I have 15 terabytes of images and never did a rebuild of database).
I'm also a PostgreSQL fan and have a lot of experience on this DB.
We'll see, ..


reply via email to

[Prev in Thread] Current Thread [Next in Thread]