[Dcmlib] gdcm versus dcmtk

[Mathieu Malaterre]

Steve,

On 11/16/06, Steve Robbins <smr at sumost.ca> wrote:
> Oh, it simply never occurred to me.  I'm fine with continuing this on
> the mailing list, including forwarding the first two messages or
> any content thereof.

ok :)

> > On 11/15/06, Steve M. Robbins <steve at sumost.ca> wrote:
>
> >> I've seen some mention of the fact that it is "lightweight" and simply
> >> implements the file format of DICOM.  Fine, but why not simply use the
> >> bits of DCMTK that you need (libdcmdata)?
> >
> > GDCM was started simply because dcmtk could not simply be wrapped into
> > python. For whoever has used dcmtk you would now that the parser is
> > not very robust and can die in some very bizarre part of the code on
> > some simple DICOM file.
>
> I am painfully aware of the chasm between DICOM specs and vendor
> implementations, yes.  My experience with DCMTK is mainly limited to
> using "dcmdump" and "storescu" so I hadn't noticed any non-robustness.
>
> Unfortunately for us, we need the network layer, so gdcm is not an
> option.  Do you happen to have a repository of files that choke DCMTK?
>   Or can you remember some types of breakage that choke DCMTK?  I'd
> like to consider how hard it would be to adapt DCMTK to accept such,
> even if the patches are never accepted upstream.

Our nightly regression testing is done against gdcmData, the cvs
version can be found here:

http://cvs.creatis.insa-lyon.fr/viewcvs/viewcvs.cgi/gdcmData/

We even have some brain damaged DICOM file (meta header declare big
endian, when the dataset is indeed in little endian! This one was only
recently fixed in GDCM). Most of those files can be found here:

http://www-creatis.insa-lyon.fr/~jpr/PUBLIC/gdcm/gdcmBreakers/

Thanks to JP for doing the maintaining and creatis for hosting this
huge reference !

> > Anyway in short, no jasper cannot be easily fix or if it was, nobody
> > has volonteer to find out where the floating point precision actually
> > creates an error. You should check the jasper ML for my posts.
>
> Thanks, I'll have a look.  Any idea whether swapping out jasper for
> Kakadu or the Aware library is an option?  Or openjpeg?

Kakadu is IMHO the best option if you can afford the license. This is
the fastest implementation I have tried. Kudos to Dr. Taubman !
In my wild dream this would be a matter of configuration on whether
you want the ijg jpeg implementation, the intel jpeg, kakadu, openjpeg
... but that's just a dream :)

> > (*) I am the maintainer of http://jpeg.sf.net and I thought I would be
> > able to maintain a non official jasper CVS version so that patch are
> > not lost, but I simply gave up. Too much work and nobody seems to
> > really care...
>
> FWIW: that URL gives me an empty directory listing.

Oops I did not pay attention, I meant the sf.net projects default page:

http://sf.net/projects/jpeg

--
Mathieu