[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, ..
Alex