[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Aeskulap-devel] suggestions
Re: [Aeskulap-devel] suggestions
Mon, 10 Apr 2006 10:14:06 -0400
On Monday 10 April 2006 08:31, Mitchell Laks wrote:
> > 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 :).
Rotate (arbitrary angles!) and Flip are important too.
Arbitrary rotation angle is very useful when patients are at lying at funny
angles in the CT scan gantry and we need to compare two studies.
(Thats why people use OpenGL, it is easy to implement all of these
functionalities without reinventing the wheel).
I agree that it can be nice to have work done over network, but less important
for a workstation whichwill have lots of ram and fast graphics card optimized
for OpenGL by Nvidia or ATI.
Work with the standards of the entire universe, dont reinvent the wheel.
Gamers don't use private graphics approaches. You want your workstation
optimized for fast image display, don't be stuck on prior work you did.
Need to be able to display two studies in parallel and to synchronize them by
Need to reorder the slices sometimes - by location by time (contrast enhanced
studies). Need to split subseries into sparate series.
> > 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
> > > 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
> Aeskulap-devel mailing list