On Tue, May 4, 2010 at 5:05 AM, Andy Buckle <[email protected]> wrote: > follows from: > http://octave.1599824.n4.nabble.com/dicom-support-tt2122699.html#a2122699 > > Following from my comment on storing the dicom dictionary. I tried a > few options;
One of the issues is that if we want full M compatibility with dicomdict() we should support modifying the dictionary in run-time including changing value representations; however, it is questionable whether M's approach of allowing all modifications even to the portion of the dictionaries specified by the standard is a good idea. I hesitate to pronounce this as obvious law to guide implementation because I know from experience that vendors can both ship with bugs and get ahead of the standards. I think we need to determine how much of the gdcm dictionaries can be modified in run-time versus creating a new Part3.xml or recompiling gdcm source. Tag mapping isn't too difficult, it's what is involved overriding of VR's and adding new private tags or replacing existing private tags that I don't know about yet. I do like that gdcm already includes and extensive repository of known private tags. --judd ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
