Re: thanks and a question
This is a kind of hard question as you are talking about open-source
project. Anyway long story-short I have also been *very* annoyed by
quality control in DICOM implementation. I have setup a modest "DICOM
Conformance Tests" which I called gdcmConformanceTests:
http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=General_questions#What_is_gdcmConformanceTests_.3F
Those files have been validated by both GDCM and dcmtk as they are the
two major DICOM implementations I am using. If you read the README(*)
that comes with the tarball you'll see that the name of dcm4che comes
in quite often, which is not really a good sign IMHO.
The problem is not really to find out which DICOM implementation is
best, but instead:
- which one is actively maintained
- fully open source, with truly transparent bug report
- which one provide a full regression test suite
I have setup a page on the typical tools I use for QA:
http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Gdcmconv/QC
Cheers,
(*) http://gdcm.svn.sourceforge.net/viewvc/gdcm/Sandbox/GDCMDataCron/README?view=markup
On Tue, Sep 29, 2009 at 4:16 AM, m laks <mlaks2000@yahoo.com> wrote:
> Mathieu,
>
> Thanks for the rapid response. I sent you the email because I figured you might have some experience and I dont know any other users. I have used ctn304 for about 8 years and am happy with it. Of course I had consulted Steve Moore about the problem long before I sent you the information.
>
> I am actively looking into the problem. I wanted to alert you in case you had more information.
>
> I had been thinking of moving to dcm4chee, both from the advice from Gunther who has been very kind to me and others who use it. Even Steve Moore has recommended it to me upon more than one occasion. However I love ctn for its incredible reliablity (I have tens of terabytes of image data in ctn and it is like a rock...) and it is hard to turn away from it...
>
> And in principle to move from a reliable c program to a java program of any kind is hard to do as I dont know it so much. (maybe something in perl would make me more adventurous).
>
> On the other hand I wondered if you had any info from other users or personal experience.
>
> Mitchell
>
>
> --- On Mon, 9/28/09, Mathieu Malaterre <mathieu.malaterre@gmail.com> wrote:
>
>> From: Mathieu Malaterre <mathieu.malaterre@gmail.com>
>> Subject: Re: thanks and a question
>> To: "m laks" <mlaks2000@yahoo.com>
>> Cc: "Debian Med Project List" <debian-med@lists.debian.org>, smmoore@users.sourceforge.net
>> Date: Monday, September 28, 2009, 5:12 AM
>> Hi mitchell,
>>
>> Sorry to hear your misfortune with ctn. did you
>> report any of the bugs you mentionned ? Are they easily
>> reproducable ?
>>
>> Thanks,
>>
>> On Thu, Sep 24, 2009 at 3:38 PM, m laks <mlaks2000@yahoo.com>
>> wrote:
>> > Mathieu,
>> > I am a great fan of debian (i use it on over 50 pcs in
>> my department and home and my parents and siblings use it
>> thanks to me). I use ctn, dcmtk and dcm4che etc. I am a
>> radiologist.
>> >
>> > I wanted to thank you for all of your efforts. I have
>> noticed your conversation with david clunie on usenet dicom
>> group. i support your efforts to make things easy to install
>> on debian...
>> >
>> > i use mir ctn. i have not switched to dcm4chee
>> although perhaps i should. i have been using it with
>> postgresql (not supported by debian install rosenberg seems
>> to like mysql version).
>> >
>> > unfortunately mir ctn is getting old. i have been
>> using 3.04 for the longest time. now some newer images are
>> rejected because the sop classes (extended sr or mammo sr
>> say were not supported. i also had problems with color
>> composite images from a pet scanner.
>> >
>> > i used a patch for postgresql to ctn304 i got from
>> sebastian meyer many years ago. there had been a problem
>> with the old ctn postgresql implementation that did not use
>> the indexes to speed up, which was a problem when the
>> database got big and caused unacceptable behavior, which was
>> solved by meyer.
>> >
>> > i tried to upgrade recently to ctn306 which according
>> to steve moore had been upgraded to account for this patch,
>> which i sent to him. unfortunately i think there is a
>> problem with quality control these days any more because no
>> one uses it :( and i had, in 1 day of usage in a small
>> office, multiple random failures of devices sending images
>> to ctn306 - cr,us,nm. the failure in each case was
>> truncation in the file the pixel data element 7fe0,0010
>> which was truncated and missing bytes in the received data.
>> >
>> > i immediately just patched 304 to the new elements i
>> needed and went back to it. i may also try using the meyer
>> patch on 306 to see if it works better, over the next couple
>> of days.
>> >
>> > we need a good testing structure for ctn. also i am a
>> postgresql person because i find it more robust than mysql
>> and with the changes in ownership of mysql i prefer
>> postgresql even more...
>> >
>> > what is your experience, any comments? i have to try
>> out clunies tools as well to see how to use them.
>> > mitchell
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Mathieu
>>
>>
>
>
>
>
--
Mathieu
Reply to: