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 <mlaks2...@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.malate...@gmail.com> wrote: > >> From: Mathieu Malaterre <mathieu.malate...@gmail.com> >> Subject: Re: thanks and a question >> To: "m laks" <mlaks2...@yahoo.com> >> Cc: "Debian Med Project List" <debian-med@lists.debian.org>, >> smmo...@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 <mlaks2...@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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
