| Re: iTool Example [message #42384 is a reply to message #42032] |
Wed, 26 January 2005 20:31  |
Robert Barnett
Messages: 70
Registered: May 2004
|
Member |
|
|
Hi,
I'm currently writing some tools for arranging image, plots and tables
from many different sources including graphics devices (e.g ZBuffer) and
pixeldata (e.g 24 bit image or 8 bit image with a LUT). These sources
are to be laid out over one or several pages. The pages are then
converted into DICOM images and sent to a remote location. The process
must be automatic without requiring user interaction.
Most of my code makes use of object graphics. This is the kind of
project that I thought would be suitable for iTools. However, I found
that iTools is really just geared towards interactive visualisation
(funny that). The closest I have come to iTools is to make use of
widget_propertysheet as a debugging tool and IDLitContainer to hold
objects.
It seems to me that iTools was never designed for medical imaging. This
was probably so because Watsyn was under development by RSI at the time.
Although the user interface is completely useless to me, I really like
the underlying concepts within iTools. Notably:
* Having Identifiers to access objects easily
* Using data observers/notifiers for event driven programming
Has anyone extended the iTools framework for their own use without
actually using the iTools UI?
p.sommer@comcast.net wrote:
> Group,
>
> In a recent thread, there was some discussion about how I used the
> iTool framework to build a data acquisition (DAQ) client. I was
> expressing some positive experiences having used the iTools for this
> project which was challenged by some. At the time, I offered to reform
> the example so that the user community could take a look at a fully
> featured, user defined iTool. It is now available for anyone
> interested:
>
>
> http://www.rsinc.com/codebank/search.asp?search=category& ;product=IDL&catid=43
>
>
> Now, if I may put my sales hat on, in addition to providing an
> excellent platform for rapid application development, I also made some
> mention about making sure the problem fit the tool which was also
> challenged. In short, what I meant by that statement was to try using
> an existing iTool [iPlot, iContour, iSurface, iVolume, iImage or iMap]
> on similar data that one needs to support to make sure the framework
> can support it. For example, since the iTools are based on IDL's
> Object Graphics, much of the data needs to reside in physical memory to
> maintain interactivity. Without going into too much detail, I think
> you power users know what I mean.
>
> Someone also asked for more detail for why one would want to start
> using the iTool framework at all for building new tools. My rational
> is that the framework takes care of a lot of important details like
> setting up views, operators, manipulators, file I/O, property sheets,
> annotation, zoom control, undo/redo buffer and now with 6.1, macro
> recording. It's just very nice to have all this taken care of so I can
> focus on the elements that make the tool truly unique as apposed to
> spending hours and hours building up the basic functionality end users
> have come to expect from a nice piece of software. Okay...enough said.
> Go easy on me as I am learning right along with you. Just hope the
> example helps someone, somewhere.
>
> -Paul
>
>
--
nrb@
Robbie Barnett
imag
Research Assistant
wsahs
Nuclear Medicine & Ultrasound
nsw
Westmead Hospital
gov
Sydney Australia
au
+61 2 9845 7223
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
