Hi Andy > -----Original Message----- > From: Andy Buckle > Sent: 06 December 2011 19:41 > To: Kris Thielemans > Subject: Re: small changes to dicominfo for reading non-explicit files > > Hi Kris, > > I have managed to compile everything now, and I am working towards > making the first package release. >
Great. One thing we should probably do is to rename load_dict etc to load_dicom_dict. > > I discovered that the current code doesn't handle data yet where the type > of > > the data (VR) is not encoded in the file (I have some fairly old GE CT data > > as test case). In this case, gdcm gets the type from the dictionary so I > > copied some lines from gdcmPrinter::PrintDataElement to dicominfo.cpp. > They > > set the vr from the dictionary if the original was either INVALID or UN. > > Shall I check that in? > > If it works, check it in. > Done > Can you share that file (or an anonymised version)? I was wondering > about having a directory with example dicom files in, to base some > tests around. /extra/dicom/dcmfiles perhaps. I will have some files to > add too. I will have to strip this directory out for the package > releases. > Good idea. I'll have a look at what I can share. I'll try to find some "phantom" data acquisitions. Less issues with patient data. What kind of tests do you envisage? I guess we could read from octave, and compare with a list of known values (e.g. obtained from gdcmdump, or even better dcmdump from dcmtk). Looks like a lot of manual work though. > > I do seem to have some trouble with dicomread returning transposed > images in > > this case. I'll investigate this more. > > I was wondering about this. I thought it did the same as Matlab. I did > discuss this on the wiki, which is now here > > http://octave.org/wiki/index.php?title=Dicom > > If you have Matlab for reference, please change our dicomread to > behave the same. > I had matlab and recall that the image was read differently. Strangely enough, for some other (PET) data, everything is fine. I hope I'll have matlab in 1 or 2 weeks to check. If I do get matlab, we could potentially use its dicominfo to read some headers, store them as .mat, load into octave and test. Kris ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev