Next generation: GDCM 2.x - DICOM

This is a discussion on Next generation: GDCM 2.x - DICOM ; Hello, [Sorry for the advertisement] This is just to let you know that GDCM 2.0.5 is out. GDCM 2.0.5 is the latest release from the GDCM 2.0.x branch which is a complete ground up rewrite or GDCM 1.x. The goal ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Next generation: GDCM 2.x

  1. Next generation: GDCM 2.x

    Hello,

    [Sorry for the advertisement]

    This is just to let you know that GDCM 2.0.5 is out. GDCM 2.0.5 is
    the latest release from the GDCM 2.0.x branch which is a complete
    ground up rewrite or GDCM 1.x. The goal was simply to provide the same
    level of functionalities with an improved/easier API to use.

    GDCM comes with a VTK plugin, an ITK plugin and a wxWidgets plugin.
    While not being part of a DICOM library those are very usefull fow
    anyone using those toolkits.

    GDCM is wrapped in python, but now also : Java, PHP and C#
    (experimental). For example the devide app is using the python
    interface:

    http://devidenews.wordpress.com/2008...browser-in-85/

    While MIView is using the C++ API:

    http://gbooksoft.com/download.php

    For more info about this release, see:

    Changelog:
    http://gdcm.sourceforge.net/wiki/ind...2.0#GDCM_2.0.5

    Download area:
    http://sourceforge.net/project/showf...ease_id=603195

    A short presentation of the major 'toy' apps can be found here:

    http://gdcm.sourceforge.net/wiki/index.php/Gdcmviewer
    and
    http://gdcm.sourceforge.net/wiki/index.php/Gdcmdump

    GDCM is released under a BSD-new style license. The library is tested
    nightly, following VTK or ITK agile development, see :

    http://public.kitware.com/dashboard.php?name=gdcm

    (thanks to kitware.com for hosting)

    The main entry page for GDCM is now:

    http://gdcm.sourceforge.net/wiki/index.php/Main_Page

    Enjoy,
    -Mathieu

  2. Re: Next generation: GDCM 2.x

    On May 30, 1:42*pm, Mathieu Malaterre
    wrote:
    > Hello,
    >
    > * [Sorry for the advertisement]
    >
    > * This is just to let you know that GDCM 2.0.5 is out. GDCM 2.0.5 is
    > the latest release from the GDCM 2.0.x branch which is a complete
    > ground up rewrite or GDCM 1.x. The goal was simply to provide the same
    > level of functionalities with an improved/easier API to use.
    >
    > * GDCM comes with a VTK plugin, an ITK plugin and a wxWidgets plugin.
    > While not being part of a DICOM library those are very usefull fow
    > anyone using those toolkits.
    >
    > * GDCM is wrapped in python, but now also : Java, PHP and C#
    > (experimental). For example the devide app is using the python
    > interface:
    >
    > *http://devidenews.wordpress.com/2008...f-new-dicombro....
    >
    > *While MIView is using the C++ API:
    >
    > *http://gbooksoft.com/download.php
    >
    > *For more info about this release, see:
    >
    > Changelog:http://gdcm.sourceforge.net/wiki/ind...2.0#GDCM_2.0.5
    >
    > Download area:http://sourceforge.net/project/showf...37895&package_...
    >
    > A short presentation of the major 'toy' apps can be found here:
    >
    > http://gdcm.sourceforge.net/wiki/index.php/Gdcmviewer
    > andhttp://gdcm.sourceforge.net/wiki/index.php/Gdcmdump
    >
    > GDCM is released under a BSD-new style license. The library is tested
    > nightly, following VTK or ITK agile development, see :
    >
    > http://public.kitware.com/dashboard.php?name=gdcm
    >
    > (thanks to kitware.com for hosting)
    >
    > The main entry page for GDCM is now:
    >
    > http://gdcm.sourceforge.net/wiki/index.php/Main_Page
    >
    > Enjoy,
    > -Mathieu



    Mathieu,

    Good work.

    Although I am happy with using dcmtk for now, I would like to explore
    using gdcm instead for our (free) application SMIViewer:

    http://groups.google.com/group/medic...b1fcf4b6?hl=en

    Can you highlight main advantages of using gdcm over dcmtk? You can
    respond separately to pixel.to.life@gmail.com if you want.

    Thanks.

    Prash.





  3. Re: Next generation: GDCM 2.x

    On May 31, 10:02 am, "Science.Medical.Imaging List"
    wrote:
    > On May 30, 1:42 pm, Mathieu Malaterre
    > wrote:
    >
    >
    >
    > > Hello,

    >
    > > [Sorry for the advertisement]

    >
    > > This is just to let you know that GDCM 2.0.5 is out. GDCM 2.0.5 is
    > > the latest release from the GDCM 2.0.x branch which is a complete
    > > ground up rewrite or GDCM 1.x. The goal was simply to provide the same
    > > level of functionalities with an improved/easier API to use.

    >
    > > GDCM comes with a VTK plugin, an ITK plugin and a wxWidgets plugin.
    > > While not being part of a DICOM library those are very usefull fow
    > > anyone using those toolkits.

    >
    > > GDCM is wrapped in python, but now also : Java, PHP and C#
    > > (experimental). For example the devide app is using the python
    > > interface:

    >
    > > http://devidenews.wordpress.com/2008...f-new-dicombro...

    >
    > > While MIView is using the C++ API:

    >
    > > http://gbooksoft.com/download.php

    >
    > > For more info about this release, see:

    >
    > > Changelog:http://gdcm.sourceforge.net/wiki/ind...2.0#GDCM_2.0.5

    >
    > > Download area:http://sourceforge.net/project/showf...37895&package_...

    >
    > > A short presentation of the major 'toy' apps can be found here:

    >
    > >http://gdcm.sourceforge.net/wiki/index.php/Gdcmviewer
    > > andhttp://gdcm.sourceforge.net/wiki/index.php/Gdcmdump

    >
    > > GDCM is released under a BSD-new style license. The library is tested
    > > nightly, following VTK or ITK agile development, see :

    >
    > >http://public.kitware.com/dashboard.php?name=gdcm

    >
    > > (thanks to kitware.com for hosting)

    >
    > > The main entry page for GDCM is now:

    >
    > >http://gdcm.sourceforge.net/wiki/index.php/Main_Page

    >
    > > Enjoy,
    > > -Mathieu

    >
    > Mathieu,
    >
    > Good work.
    >
    > Although I am happy with using dcmtk for now, I would like to explore
    > using gdcm instead for our (free) application SMIViewer:
    >
    > http://groups.google.com/group/medic...owse_thread/th...
    >
    > Can you highlight main advantages of using gdcm over dcmtk? You can
    > respond separately to pixel.to.l...@gmail.com if you want.


    Hi Prash,

    dcmtk & gdcm have different purposes, so comparing them would not be
    fair.
    Basically if you are looking for a library so that you open your
    DICOM image file and 'it just works', then I'd suggest gdcm.

    1. From the C++ side, it is using template metaprogramming for type
    safety

    Element a = { 0,1,2,3,4,5,6,7 }; // C++ compiler
    is doing all the work for type checking

    Same goes for something like that:

    Attribute<0x0008,0x9007> b = {"ORIGINAL","PRIMARY","T1","NONE"};

    We also handle special VM, this way:

    Attribute<0x0018,0x1182, VR::IS, VM::VM1> fd1 = {0};
    or
    Attribute<0x0018,0x1182, VR::IS, VM::VM2> fd2 = {0,1};

    2. It's API is kept very simple so that automatic wrapping can be
    achieved using SWIG. gdcm was originally started because of this
    requirement: a DICOM library accessible from python.

    3. As of now, dcmtk does not support J2K (at least not the open source
    version).

    4. It comes with a VTK & ITK bridge so it makes integration with
    projects using those open source projects extremely easy.

    5. XML version of Part 3 & Part 6/7 of the DICOM standard, and
    numerous Conformance Statements from private vendors.

    6. Agile development, using nightly dashboard for regression (CMake/
    CTest/CDash driven).

    7. Handle all those broken DICOM implementations (so called DICOM
    files) from private vendors, see: http://gdcm.sourceforge.net/wiki/ind...GDCM:Supported

    From my point of view #1 is the most important, since it saved me from
    my own mistakes numerous times. But from a pure user point of view, I
    believe that the wrapped interface (#2) is what is the most important.
    Point 3/4/5/6 are just details. Point 7 might be important to you, if
    you are required to deal with such broken files.

    I choose to publicly answer to your question, because I have nothing
    to hide. And to tell you frankly gdcm would NOT exist today if dcmtk
    or dicom3tools did not exist first. dcmtk remains THE reference DICOM
    implementation and is far more correct than gdcm (but that's not what
    all users want). dcmtk and dicom3tools have also an open source
    license compatible with the BSD-new style from GDCM, which allowed me
    for instance to backport all the JPEG lossless fix, the dcmtk made
    (thanks guys!). And also to integrate all those nasty private
    dictionaries that have no conformance statement available anywhere
    (thanks David!).
    Special thanks also to Yves (TomoVision) for his help in understanding
    broken JPEG streams. As you may understand, DICOM toolkits have
    differents goals, and no toolkit is better than the other.

    Finally gdcm is only file oriented (no network). And something that
    might be important to you, gdcm does not offer commercial support.

    Regards,
    -Mathieu
    Ps: keep in mind that gdcm 2.x is 2yrs old, while dcmtk is a much more
    mature project !

  4. Re: Next generation: GDCM 2.x

    On May 31, 3:27*am, Mathieu Malaterre
    wrote:
    > On May 31, 10:02 am, "Science.Medical.Imaging List"
    >
    >
    >
    >
    >
    > wrote:
    > > On May 30, 1:42 pm, Mathieu Malaterre
    > > wrote:

    >
    > > > Hello,

    >
    > > > * [Sorry for the advertisement]

    >
    > > > * This is just to let you know that GDCM 2.0.5 is out. GDCM 2.0.5 is
    > > > the latest release from the GDCM 2.0.x branch which is a complete
    > > > ground up rewrite or GDCM 1.x. The goal was simply to provide the same
    > > > level of functionalities with an improved/easier API to use.

    >
    > > > * GDCM comes with a VTK plugin, an ITK plugin and a wxWidgets plugin..
    > > > While not being part of a DICOM library those are very usefull fow
    > > > anyone using those toolkits.

    >
    > > > * GDCM is wrapped in python, but now also : Java, PHP and C#
    > > > (experimental). For example the devide app is using the python
    > > > interface:

    >
    > > > *http://devidenews.wordpress.com/2008...f-new-dicombro...

    >
    > > > *While MIView is using the C++ API:

    >
    > > > *http://gbooksoft.com/download.php

    >
    > > > *For more info about this release, see:

    >
    > > > Changelog:http://gdcm.sourceforge.net/wiki/ind...2.0#GDCM_2.0.5

    >
    > > > Download area:http://sourceforge.net/project/showf...37895&package_...

    >
    > > > A short presentation of the major 'toy' apps can be found here:

    >
    > > >http://gdcm.sourceforge.net/wiki/index.php/Gdcmviewer
    > > > andhttp://gdcm.sourceforge.net/wiki/index.php/Gdcmdump

    >
    > > > GDCM is released under a BSD-new style license. The library is tested
    > > > nightly, following VTK or ITK agile development, see :

    >
    > > >http://public.kitware.com/dashboard.php?name=gdcm

    >
    > > > (thanks to kitware.com for hosting)

    >
    > > > The main entry page for GDCM is now:

    >
    > > >http://gdcm.sourceforge.net/wiki/index.php/Main_Page

    >
    > > > Enjoy,
    > > > -Mathieu

    >
    > > Mathieu,

    >
    > > Good work.

    >
    > > Although I am happy with using dcmtk for now, I would like to explore
    > > using gdcm instead for our (free) application SMIViewer:

    >
    > >http://groups.google.com/group/medic...owse_thread/th...

    >
    > > Can you highlight main advantages of using gdcm over dcmtk? You can
    > > respond separately to pixel.to.l...@gmail.com if you want.

    >
    > Hi Prash,
    >
    > * dcmtk & gdcm have different purposes, so comparing them would not be
    > fair.
    > * Basically if you are looking for a library so that you open your
    > DICOM image file and 'it just works', then I'd suggest gdcm.
    >
    > 1. From the C++ side, it is using template metaprogramming for type
    > safety
    >
    > * * Element a = *{ 0,1,2,3,4,5,6,7 }; // C++ compiler
    > is doing all the work for type checking
    >
    > Same goes for something like that:
    >
    > * Attribute<0x0008,0x9007> b = {"ORIGINAL","PRIMARY","T1","NONE"};
    >
    > We also handle special VM, this way:
    >
    > Attribute<0x0018,0x1182, VR::IS, VM::VM1> fd1 = {0};
    > or
    > Attribute<0x0018,0x1182, VR::IS, VM::VM2> fd2 = {0,1};
    >
    > 2. It's API is kept very simple so that automatic wrapping can be
    > achieved using SWIG. gdcm was originally started because of this
    > requirement: a DICOM library accessible from python.
    >
    > 3. As of now, dcmtk does not support J2K (at least not the open source
    > version).
    >
    > 4. It comes with a VTK & ITK bridge so it makes integration with
    > projects using those open source projects extremely easy.
    >
    > 5. XML version of Part 3 & Part 6/7 of the DICOM standard, and
    > numerous Conformance Statements from private vendors.
    >
    > 6. Agile development, using nightly dashboard for regression (CMake/
    > CTest/CDash driven).
    >
    > 7. Handle all those broken DICOM implementations (so called DICOM
    > files) from private vendors, see:http://gdcm.sourceforge.net/wiki/ind...GDCM:Supported
    >
    > From my point of view #1 is the most important, since it saved me from
    > my own mistakes numerous times. But from a pure user point of view, I
    > believe that the wrapped interface (#2) is what is the most important.
    > Point 3/4/5/6 are just details. Point 7 might be important to you, if
    > you are required to deal with such broken files.
    >
    > I choose to publicly answer to your question, because I have nothing
    > to hide. And to tell you frankly gdcm would NOT exist today if dcmtk
    > or dicom3tools did not exist first. dcmtk remains THE reference DICOM
    > implementation and is far more correct than gdcm (but that's not what
    > all users want). dcmtk and dicom3tools have also an open source
    > license compatible with the BSD-new style from GDCM, which allowed me
    > for instance to backport all the JPEG lossless fix, the dcmtk made
    > (thanks guys!). And also to integrate all those nasty private
    > dictionaries that have no conformance statement available anywhere
    > (thanks David!).
    > Special thanks also to Yves (TomoVision) for his help in understanding
    > broken JPEG streams. As you may understand, DICOM toolkits have
    > differents goals, and no toolkit is better than the other.
    >
    > Finally gdcm is only file oriented (no network). And something that
    > might be important to you, gdcm does not offer commercial support.
    >
    > Regards,
    > -Mathieu
    > Ps: keep in mind that gdcm 2.x is 2yrs old, while dcmtk is a much more
    > mature project !- Hide quoted text -
    >
    > - Show quoted text -


    Mathieu,

    I thank you very much for a detailed response. My application is still
    in early stages (first version released less than 2 weeks ago- so I
    still have to face and recover from details like #3 - #5. But for now,
    I don't foresee any network requirements... since SMIViewer is going
    to be opensourse soon, we will only support it for research purposes,
    no commercial flavor. Slowly we will be adding support for uncommon
    DICOM flavors like multiframe images, secondary captures, broken
    vendor specific versions, etc. I will find some time to try it out
    with SMIViewer soon. I really would like to see SMIViewer featured in
    supported aplications list at gdcm's page!

    Thanks again, and keep up the good work!

    Prash.

+ Reply to Thread