[Insight-users] GDCM and ITK

[Mathieu Malaterre]

Salut poireau (hercule?)

On Mon, Mar 30, 2009 at 2:36 PM, poireau <joelthelion at laposte.net> wrote:
>
> Hi all,
>
> I have a few questions regarding DICOM support in ITK. According to the documentation, ITK ships with version 1.2 of GDCM, which is a quite outdated version of the dicom library.

GDCM 1.2 was released ~2005.

> GDCM 2.x seems to have a lot of nice features which I'd like to use, but I'm not sure if I can safely mix gdcm 2.x and ITK, since ITK depends and contains the 1.2 version of the library. I'm afraid the two would collide and cause linking problems.

Indeed you'll get linking error in an application that uses both. It
is however supported to use gdcm 1.3 and gdcm 2.x thanks to a
configurable namespace in gdcm 1.3. It is however not possible to use
gdcm 1.2 and gdcm 2.x in the same application (*).

But you can safely use ITK_USE_SYSTEM_GDCM and point to a a gdcm 2.x
installation.

> So:
>
> 1) Any experience mixing gdcm2.x and ITK? How do you do it? Did you run into any problems?

See above. I have been recently reported an issue with ITK + GDCM 2.x,
I had broken the old (untested) API that was inherited from
itk::DicomImageIO. So a couple of users have started using it.
Other than that it should work as a complete (better) replacement for
gdcm 1.x. Be warned that reading DICOM file will be much faster, you
may want to insert a couple of 'wait()' function in your code, to
completely reproduce the old gdcm 1.x behavior.

> 2) Why does itk ship the old version of gdcm? Is that planned to change sometime?

GDCM 2.x does not compile (by design) on very old (and unsupported)
compiler such as VS6. So the day ITK drops support for broken c++
compiler, there should not be any major issue to replace gdcm 1.x with
gdcm 2.x.

2cts
-- 
Mathieu
(*) you'll need to dlopen/dlclose library, but that would be very
messy and I do not know if this would even work.