Requesting (timely!) Dicom / VTK feedback. - DICOM

This is a discussion on Requesting (timely!) Dicom / VTK feedback. - DICOM ; Cross posted to: alt.image.medical comp.graphics.algorithms Hello everybody, Having browsed thru some of the 3D-related posts on comp.protocols.dicom, I'm wondering why everybody in the medical imaging world isn't (or, hasn't started) using VTK? VTK... 1. ... comes bundled with its own ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Requesting (timely!) Dicom / VTK feedback.

  1. Requesting (timely!) Dicom / VTK feedback.

    Cross posted to:
    alt.image.medical
    comp.graphics.algorithms

    Hello everybody,

    Having browsed thru some of the 3D-related posts on
    comp.protocols.dicom, I'm wondering why everybody in the medical
    imaging world isn't (or, hasn't started) using VTK?

    VTK...
    1. ... comes bundled with its own Dicom reader which, I suppose, would
    abstract away most of the low-level details related to pixel-spacing,
    image-orientation, voxelization, this, and that.
    2. ... is fairly generic (can be used outside of medical imaging)
    3. ... has bindings for many languages,
    4. ... comes with a fairly good conceptual documentation...

    And, OsiriX, a very popular free/open-source Dicom viewer, uses it as
    well.

    Being the seniormost software developer in our team (admittedly with a
    very basic background in graphics and Dicom), I was recently asked to
    help add 3D capability to an existing, Java-based medical imaging
    application. I need to make recommedations to our Management whether
    to leverage VTK, ITK, etc... or develop expertise in-house in the world
    of low-level details of Dicom, 3D-imaging, graphics, algorithms, etc.

    My software development experience to date has taught me that using
    packages like VTK/ITK goes all fine and great (and cool) until...
    until, you run into a dead-end and must modify or extend them... a
    non-trivial task even for seemingly simple changes if you're not
    familiar (and neither can afford time/resources for an
    unexpected/unplanned need for familiarization) with their code
    structure.

    Since VTK/ITK are not packages I can thoroughly evaluate overnight, I'd
    greatly, greatly appreciate
    if you could publicly/privately share your experiences (the more
    detailed the better) in this matter... which is: Should I recommend
    investing our scarce and precious time in building expertise in the use
    of VTK/ITK? Or, in what it takes to build something like VTK/ITK (or,
    their subsets)?

    Thanks much,
    Harry.
    (simons harry at gmail dot com)


  2. Re: Requesting (timely!) Dicom / VTK feedback.

    Harry wrote:

    > Having browsed thru some of the 3D-related posts on
    > comp.protocols.dicom, I'm wondering why everybody in the medical
    > imaging world isn't (or, hasn't started) using VTK?


    We use VTK. Have a look at http://www.mevislab.de - It is a rapid
    development platform for medical applications, image manipulation and much
    more. We have a binding to VTK/ITK which makes it very simple to use the
    hundreds of of modules in VTK/ITK. So there _are_ people, that use it.
    However, we focus on our own image library and our own modules because we
    have an own architecture which allows us to make image manipulation of
    multidimensional data very efficient. But if you have clearly defined
    requirements, VTK is a good choice (better than ITK). For DICOM we use the
    Offis implementation of the DICOM-Standard, which is a free library. It's
    very efficient also and easy to use.

    > Being the seniormost software developer in our team (admittedly with a
    > very basic background in graphics and Dicom), I was recently asked to
    > help add 3D capability to an existing, Java-based medical imaging
    > application. I need to make recommedations to our Management whether
    > to leverage VTK, ITK, etc... or develop expertise in-house in the world
    > of low-level details of Dicom, 3D-imaging, graphics, algorithms, etc.
    >
    > My software development experience to date has taught me that using
    > packages like VTK/ITK goes all fine and great (and cool) until...
    > until, you run into a dead-end and must modify or extend them... a
    > non-trivial task even for seemingly simple changes if you're not
    > familiar (and neither can afford time/resources for an
    > unexpected/unplanned need for familiarization) with their code
    > structure.


    Developing your own DICOM reader is total overkill and will cost you really
    much time. The standard is so overblown and full or tricky details, and the
    images of different vendors make so heavy use of user defined tags, that
    chances are very great, that only some test images will work with your own
    implementation and all other things fail. I strongly recommend using a good
    existing DICOM implementation such as OFFIS (which is a C-library) or VTK.
    If you are going to add 3D and Viewers, VTK is a good choice, since it
    comes with nearly everything, one can imagine, viewers included. And if
    something fails, it seems to be simple to add your own modules.

    If you are not fixed to Java, I would like to recommend MeVisLab also. The
    rapid development features are overwhelming (okay, I work at that company,
    but give it a try, the basic version (non commercial) is for for free. If
    you understand, how it works, it might be only some minutes to create a
    powerfull 3D-DICOM-Viewer with lots of image manipulation modules (even
    your own).

    > Since VTK/ITK are not packages I can thoroughly evaluate overnight, I'd
    > greatly, greatly appreciate
    > if you could publicly/privately share your experiences (the more
    > detailed the better) in this matter... which is: Should I recommend
    > investing our scarce and precious time in building expertise in the use
    > of VTK/ITK? Or, in what it takes to build something like VTK/ITK (or,
    > their subsets)?


    If you have to use Java, use VTK. Its complete, its fast and its very good
    implemented.

    Regards
    Stephan



  3. Re: Requesting (timely!) Dicom / VTK feedback.

    Hi Harry,

    > Cross posted to:
    > alt.image.medical
    > comp.graphics.algorithms


    You forgot to CC the vtkusers mailing list, which I believe would be a
    better resource for you IMHO.

    > Having browsed thru some of the 3D-related posts on
    > comp.protocols.dicom, I'm wondering why everybody in the medical
    > imaging world isn't (or, hasn't started) using VTK?


    Just for curiosity, what exactly made you believe that ?
    For instance, have you had a look at :
    http://kitware.com/profile/press/
    In particular with projects like NAMIC, Slicer3D

    > 1. ... comes bundled with its own Dicom reader which, I suppose, would
    > abstract away most of the low-level details related to pixel-spacing,
    > image-orientation, voxelization, this, and that.
    > 2. ... is fairly generic (can be used outside of medical imaging)
    > 3. ... has bindings for many languages,
    > 4. ... comes with a fairly good conceptual documentation...
    >
    > And, OsiriX, a very popular free/open-source Dicom viewer, uses it as
    > well.


    The DICOM reader made it only very late into the VTK toolkit. Basically
    it is post VTK 4.4 release. I is a very very light implementation. It
    basically only handles ACR-NEMA file (single frame, raw, no
    compression). I would suggest other implementation, some are using
    vtkGDCMReader (make use of the GDCM DICOM library), some prefer DCMTK
    implementation.

    > Being the seniormost software developer in our team (admittedly with a
    > very basic background in graphics and Dicom), I was recently asked to
    > help add 3D capability to an existing, Java-based medical imaging
    > application. I need to make recommedations to our Management whether
    > to leverage VTK, ITK, etc... or develop expertise in-house in the world
    > of low-level details of Dicom, 3D-imaging, graphics, algorithms, etc.


    I would really really highly recommend using any kind of open source
    DICOM library. Or if you prefer an already existing closed source
    implementation.

    > My software development experience to date has taught me that using
    > packages like VTK/ITK goes all fine and great (and cool) until...
    > until, you run into a dead-end and must modify or extend them... a
    > non-trivial task even for seemingly simple changes if you're not
    > familiar (and neither can afford time/resources for an
    > unexpected/unplanned need for familiarization) with their code
    > structure.


    Some say VTK has a steep learning curve, but for that you should really
    either:
    - Post your issue on vtkusers ML, chance is that people have already
    dealt with your issue,
    - Buy a support contract with kitware
    - Go to one of the course session

    > Since VTK/ITK are not packages I can thoroughly evaluate overnight, I'd
    > greatly, greatly appreciate
    > if you could publicly/privately share your experiences (the more
    > detailed the better) in this matter... which is: Should I recommend
    > investing our scarce and precious time in building expertise in the use
    > of VTK/ITK? Or, in what it takes to build something like VTK/ITK (or,
    > their subsets)?


    Building VTK or ITK on its own might be a very interesting experience
    for you. So I suggest you give it a try. It makes use of CMake the
    cross platform Make system, which is now used for building KDE (K
    Desktop Environment http://kde.org)

    -Mathieu


  4. Re: Requesting (timely!) Dicom / VTK feedback.

    Hi Stephan,

    > We use VTK. Have a look at http://www.mevislab.de - It is a rapid
    > development platform for medical applications, image manipulation and much
    > more. We have a binding to VTK/ITK which makes it very simple to use the
    > hundreds of of modules in VTK/ITK. So there _are_ people, that use it.




    > However, we focus on our own image library and our own modules because we
    > have an own architecture which allows us to make image manipulation of
    > multidimensional data very efficient. But if you have clearly defined
    > requirements, VTK is a good choice (better than ITK).


    Hum I think your sentence might be a little confusing here. Are you
    trying to say that VTK is easier to extent to support multidimensional
    data than ITK ? ITK heavily uses generic programming (template
    metaprogramming) and by design handle N-dimension data. VTK main focus
    is visualization thus class to represent an Image are designed to be
    only 3 dimensions.

    > For DICOM we use the
    > Offis implementation of the DICOM-Standard, which is a free library. It's
    > very efficient also and easy to use.


    It is also the most complete implementation (with query/retrieve).

    > Developing your own DICOM reader is total overkill and will cost you really
    > much time. The standard is so overblown and full or tricky details, and the
    > images of different vendors make so heavy use of user defined tags, that


    Standard is not that bad, it looks impressive that's all. The main
    problem is indeed support for private implementation of the DICOM
    standard. Which in some cases is simply impossible because information
    is stored in binary blobs

    > chances are very great, that only some test images will work with your own
    > implementation and all other things fail. I strongly recommend using a good
    > existing DICOM implementation such as OFFIS (which is a C-library) or VTK.


    I don't suggest the one in VTK it is very very limited. And AFAIK the
    main author is not working on it anymore. Instead consider either DCMTK
    or GDCM if you would like a BSD license open souce software.

    > If you are going to add 3D and Viewers, VTK is a good choice, since it
    > comes with nearly everything, one can imagine, viewers included. And if
    > something fails, it seems to be simple to add your own modules.
    >
    > If you are not fixed to Java, I would like to recommend MeVisLab also. The
    > rapid development features are overwhelming (okay, I work at that company,
    > but give it a try, the basic version (non commercial) is for for free. If
    > you understand, how it works, it might be only some minutes to create a
    > powerfull 3D-DICOM-Viewer with lots of image manipulation modules (even
    > your own).


    Mathieu


+ Reply to Thread