[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Aeskulap-devel] suggestions
From: |
Mitchell Laks |
Subject: |
Re: [Aeskulap-devel] suggestions |
Date: |
Mon, 10 Apr 2006 08:31:51 -0400 |
User-agent: |
KMail/1.9.1 |
On Monday 10 April 2006 04:36, Alexander Pipelka wrote:
> 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 ?
It does not allow to move the image completely around the window in 2d. It
seems to be constrained.... It allows to move the image "up and down" a very_
little_ bit_ and nothing more :)
You need to be able to use the pan to move any feature anywhere in the image
to the center of the screen - to use in conjunction with zoom.
Also scroll is not a "second level" activity and so should not use ctl-right
button. More appropriate might be
left button press drag - scroll and
right button press drag - window level
ctl - left button drag (or alt)- accelerated scroll - (i routinely have
studies with 1000's of images to read :( and I need to get to a level of
interest quickly for review.)
Better yet - make it configurable by user :).
> 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.
1) button activate "probe button" so that point will display pixel value.
2) draw circle centered on point arbitrary radius and then calculate average
and standard deviation.
You need to download a excellent application such as efilm workstation on web
and try out functionality. Have you seen terarecon workstation? have you
played with osirix. You should not be reinventing the wheel, and these
functionality are well understood in the field.... These are excellent models
of radiologist driven functionality design.
Although Osirix is a marvelous example of great open source coding, with
amazing 3d features, the user interface is NOT a model to be emulated. It did
not receive the attention it deserved cause that was apparently not the
driving force in development.
>
> > 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.
the dicom qr model is important of course, and your local storage will
facilitate responding to dicom qr faster.
However the radiologist will need access to local exams transparently to be
able to review them. A radiologist might want to recieve exams locally off
line and then come to workstation to read with them already in the local
database.
>
> > 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
>
>
>
>
> _______________________________________________
> Aeskulap-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/aeskulap-devel