> > > > 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. > > hardcode what the answer should be reading various VRs, delving into > nested SQs. In the future, if it is tinkered with, can run the suite > of tests to make sure everything is still handled correctly. Also I > can play with more types of file that I don't come across in my own > work. I think I tested stuff, and inadvertently broken it again: like > the thing you fixed near the if statement to ignore group length. > >
OK. I had another look at the 'transpose or not' issue. Contrary to what I thought, it seems that we're reading the data transposed compared to matlab, for both my PET and CT data. This is rather strange, as as far as I know, matlab just reads the data as-is, and stores it in the usual column-first fashion. As far as I can see, you're doing the same (i.e. just calling gdcm::Bitmap::GetBuffer). This puzzles me. Is there anything obvious that I'm missing? How would we transpose the image (we could call permute of course). 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
