> -----Original Message----- > From: carandr...@gmail.com [mailto:carandr...@gmail.com] On Behalf Of > Carnë Draug > Sent: 24 November 2011 12:42 > To: Andy Buckle > Cc: Kris Thielemans; octave-dev@lists.sourceforge.net > Subject: Re: [OctDev] experimental dicom support: changing code for > multiple elements and byteorder etc > > On 24 November 2011 09:34, Andy Buckle <andybuc...@gmail.com> wrote: > > On 23 November 2011 23:05, Kris Thielemans > <kris.f.thielem...@gmail.com> wrote: > >> Hi > >> > >> I'm modifying octave-forge/extra/dicom/src/dicominfo.cpp to handle > data > >> which are arrays, i.e. VM>1. I realize that not many people will know > DICOM, > >> let alone GDCM, but I'd appreciate any feedback in any case. (There's > some > >> generic octave questions at the end) > >> > >> Also, it would be good if someone could test the current dicominfo on > >> systems with different byteorders. I suspect that it'll only work when the > >> byteorder of the dicom file is the same as the one of the machine you're > >> running it on. > >> > >> I had a look at gdcm example code and it seems to me that we cannot > really > >> use memcpy to get from the dicom raw data to octave data. This > presumably > >> wouldn't work when byteswapping is needed (or other "transfer > syntax"). In > >> any case, I wouldn't know if memcpy would work with arrays (I'm not sure > if > >> it's guaranteed by DICOM that the subsequent members are stored > >> consecutively, although it's very likely of course). In an attempt to handle > >> this (and avoid horrible code repetition) I came up with the following > >> modification for element2value() in dicominfo.cpp: > >> > >> ------------------ current code ------------------- > >> if (vr & gdcm::VR::US) {// unsigned short > >> uint16_t usval ; > >> memcpy(&usval, elem->GetByteValue()->GetPointer(), 2); > >> *ov=usval; > >> if(chatty) octave_stdout << '[' << usval << "]\n"; > >> } else ... > >> // almost repeated for lots of VRs and types > >> return DICOM_OK; > >> -------------------- new code ----------------- > >> if (vr & gdcm::VR::US) {// unsigned short > >> return element2intvalueHelper<gdcm::VR::US>(ov, elem, chatty); > >> } else ... > >> // repeated for lots of VRs > >> > >> ---------------------- new function definition (in dicominfo.cpp) > >> --------------------- > >> template <gdcm::VR::VRType vrtype> > >> int element2intvalueHelper(octave_value *ov, const gdcm::DataElement > * elem, > >> const int chatty) { > >> if( !elem->IsEmpty() ) { > >> // find type that corresponds to this VR > >> typedef typename gdcm::VRToType<vrtype >::Type actual_type; > >> gdcm::Element<vrtype,gdcm::VM::VM1_n> el; > >> el.Set( elem->GetValue() ); > >> intNDArray<octave_int<actual_type> > val(dim_vector > (el.GetLength(),1)); > >> for (unsigned i=0; i<el.GetLength(); ++i) > >> val(i) = el.GetValue(i); > >> *ov=val; > >> if(chatty) octave_stdout << '[' << val << "]\n"; > >> return DICOM_OK; > >> } > >> else > >> { > >> return DICOM_NOTHING_ASSIGNED; > >> } > >> } > >> ------------------------------------------------------------------------- > >> > >> This seems to work. It might be somewhat inefficient though, as we're > >> creating a temporary array, copying to an octave_value, and then getting > rid > >> of it. I'm not sure how to avoid this, or even if it's an issue. > >> Also, it's annoying that I need to have 2 separate code sets for ints and > >> floats (as I need intNDArray<octave_int<short> > etc because of missing > >> constructors in octave_value). > >> > >> Any suggestions for improvements? > >> > >> Thanks > >> > >> Kris Thielemans > >> Algorithms and Software Consulting Ltd > >> Honorary Lecturer at Imperial College London > > > > It's really nice to see someone else working on the dicom package. > > > > Have you timed it on your system? How much slower is it? > > > > It did occur to me that memcpy may cause problems. Do you have a > > system where it does? I have used it on a few and it always works. I > > guess having someone with different types of mac to have a try might > > be useful. > > > > Do you have write acces to sf.net svn? If not please can this be > > granted. Carnë, is that your remit now? > > > > Driver issues with my linux system are still consuming my spare time, > > so I have not actually tried your code yet. I would not actually > > commit this yet unless; > > - The timed performance degradation is tiny, or, > > - We have confirmation of our suspicion that it does cause a problem > > on some systems. > > > > -- > > /* andy buckle */ > > Hi Kris > > do you have any experience with svn? If so, I can give you write > access to the repo as requested by Andy. You'll need a sourceforge > account for that (you can use openID such as your google account to > create one). > > Carnë
Hi I have used CVS a lot. SVN is a bit newer to me, but I guess I'll manage. My SF account is krthie. Thanks! Kris ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
