[IGSTK-Developers] Building IGSTK community - Section IV
Frank Lindseth
Frank.Lindseth at sintef.no
Thu May 24 05:53:27 EDT 2007
Some thoughts from the Trondheim group triggered by the "Build a
IGSTK community" discussion:
Why would people start (and continue) to use IGSTK for real clinical
apps:
- They have to believe in the project (and open source). In order to
put a lot of time and effort into it they have to believe in the
design principles chosen and the direction the project is taking.
- They should be able to make the kind of applications that is
required by the clinical end user (the future is more comlex then the
past...), fundamental changes to the toolkit should not be necessary
in order to do this, these possibilities should be build into the
system. It should be noted that in order to advance the IGS field
some experimentation is needed, prototypes based on good ideas must
be made and tested in the clinic in order to see if this really was a
good idea, this requires some flexibility from the toolkit.
- It should be easy to use. Ideally it should be as easy as
connecting the right heigh level components and putting a gui on top
of it.
- Realistic examples shoving the proper use of the core components is
paramount. I think that if we should have ONE demo. app. that
illustrated how to put together the functionality that is common to
(almost) any IGS procedure (should be considered as the use case for
the re-factoring process (view, slicer, tracker, etc,) that have been
started)
* Read a DICOM data set.
* Display it (different slicing possibilities and view configurations)
* Mark the image-landmarks.
* Pinpoint the corresponding patient landmarks using a tracked pointer.
* Navigate to a target. (volume-based slicing, surgical-tool based
slicing, et.c)
This is functionality that potential IGSTK users are seeking, if a
complete example applications with this functionality was build in
both FLTK and Qt, most of the IGSTK components could be explained in
terms of a single "close to" realistic example at the same time a the
application developers would have a flying start.
- Practical User Guides, at lest for the app. dev. point of view but
also from the comp. dev. point of view. "The Book" is very good in
many ways but as a practical user guide it has a long way to go. The
suggested example application mentioned would be an excellent "red
thread" (maybe this is just a norwegian saying...) in such a user
guide.
- The feeling of being part of a live project. Responsive mailing
lists are very important here. And I agree that this is very good
today. Knowing Luis I'm sure that this will be good also in the
future when the load hopefully will increase.... So I guess that
IGSTK is alive today, even thought it's seems to be more alive just
before the Tcons then in between...
- Documentation is of course important, you always have the source
code, the doxygen documentation should add something more (it
shouldn't be just a list of class and method names with arguments),
and of course it should be updated to always mach the code.
- As stated by Ziv, the license is probably important for many groups
that are considering IGSTK for real apps. (a lot of time and effort
needed), so it's important that it stays BSD-like
-----
Patrick: We have a very important meeting that is scheduled to last
until 4pm norwegian time / 10am EST, we will try to make the Tcon 9am
EST, but if we are not there from the start maybe we can postpone
item 1 on the agenda until we are, e.g. towards the end?
- Frank
On May 23, 2007, at 7:57 PM, Ziv Yaniv wrote:
> Andinet Enquobahrie wrote:
>> Team,
>> Attached is a draft for a short section on "Building IGSTK user
>> community". This will be
>> section IV of the JDI paper.
>> Comments will be appreciated!
>> thanks
>> -Andinet
>> ---------------------------------------------------------------------
>> ---
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
> Andient,
>
> The following are my comments on user community building.
> I would divide the discussion into two parts, convincing users to
> adopt IGSTK and retaining them.
>
> 1. User adoption of IGSTK:
>
> a. We provide a large number of example applications. For many
> academic users this is highly attractive, as they can focus on
> incorporating
> their novel research into a fully functioning application. For
> example, a novel registration algorithm can be easily incorporated
> into an already existing application without the need for
> developing the UI or visualization components.
>
> b. The license for the toolkit is BSD-like, and is thus highly
> attractive to commercial users as they can utilize the toolkit at
> no cost to their company.
>
> These two factors make the toolkit attractive both to academia and
> business.
>
>
> We cannot make claims with regard to the IGSTK documentation
> process, at least we shouldn't claim to have wonderful documentation:
>
> c. The documentation is neither complete or sound (will probably
> talk about this on the TCon).
>
> d. Automated documentation generation is neither good nor bad, it
> is the quality of the documentation that matters. You may end up
> with many pages of documentation that contain no added value
> (unfortunately many IGSTK pages), or even erroneous information,
> for example in igstk::Transform. The documentation of SetRotation()
> and SetTranslation() states:
> "Internally the translational (rotational) part of the transform
> will be set to zero."
>
> The implementation doesn't do this. Run the following to see:
>
> #include <igstkTransform.h>
>
> int main(int argc, char *argv[])
> {
> igstk::RealTimeClock::Initialize();
>
> igstk::Transform t;
> igstk::Transform::VersorType versor;
> igstk::Transform::VectorType translation;
> //versor documentation states that it will be
> normalized, so I can give these values
> versor.Set(1,1,1,1);
> translation[0] = 1;
> translation[1] = 1;
> translation[2] = 1;
>
> std::cout<<t;
>
> t.SetTranslation(translation,0.5,10);
> std::cout<<"***************************\n";
> std::cout<<t;
>
> //translation should be [0,0,0] after this
> t.SetRotation(versor,0.5,10);
> std::cout<<"***************************\n";
> std::cout<<t;
> }
>
>
> 2. User retention:
> a. User mailing list has recently been launched, with the
> development team committed to timely responses to the user
> questions (I totaly agree, Patrick and Luis are amazing in this
> respect).
> b. Users are treated as co-developers directly influencing the
> directions in which the toolkit evolves (SINTEF example).
>
>
> Ziv
> --
> Ziv Yaniv, PhD., Research Assistant Professor
> Imaging Science and Information Systems (ISIS) Center
> Department of Radiology
> Georgetown University Medical Center
> 2115 Wisconsin Avenue, Suite 603
> Washington, DC, 20007,
>
> Phone: +1-202-687-7286
> Fax: +1-202-784-3479
> email: zivy at isis.imac.georgetown.edu
> web: http://isiswiki.georgetown.edu/zivy/
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
More information about the IGSTK-Developers
mailing list