TODO

   1 -----------------------------------------------------------------------------
   2 Proposed Template of an entry in this TODO:
   3 (Note: Date is the date of registering of first demand.)
   4
   5 -------------
   6 Description:
   7 Date:
   8 Attributed:
   9 Details:
  10 Comments:
  11 -------------
  12
  13 -----------------------------------------------------------------------------
  14 Description: GDCM does not read Spacing properly.
  15 Date: 2006 June 5
  16 Attributed:
  17 Details:
  18 GDCM is ready completely random values to find out the spacing/origin or an
  19 image. It *SHOULD* first find the IOD and then deduce which tags to read
  20 Eg: Cross section this is in Pixel Spacing (0028,0030)
  21 CR is in Imager Pixel Spacing (0018,1164)
  22 US is in Pixel Ratio (0028,0034)
  23 RT is in :
  24 (3002,0011) Image Plane Pixel Spacing
  25 (3002,0012) RT Imaga ePosition
  26 and
  27 (3004,000c) for deducing Z spacing
  28 -----------------------------------------------------------------------------
  29 Description: GDCM is pretty dumb with binary data
  30 Date: 2006 May 1
  31 Attributed:
  32 Details:
  33 D 0028|0009 [AT] [Frame Increment Pointer] [gdcm::Binary data loaded;length = 4]
  34 -----------------------------------------------------------------------------
  35 Description: gdcm does not handle deflate TS
  36 Date: 2006 Jan 25
  37 Attributed: Mathieu
  38 Details:
  39 image_dfl from dclunie website is not working since the *whole* dataset
  40 is compressed. Therefore we cannot even parse the file.
  41 -----------------------------------------------------------------------------
  42 Description: Problem with PrintFile and OB field
  43 Date: 2005 Dec 30
  44 Attributed: Mathieu
  45 Details:
  46   Doing a PrintFile on RickAvila DataSet we get:
  47 D 0043|1028 lg :        x(2)        2 Off.:      x(bb2)     2994 [OB]                                                  [Unique image iden] [00]
  48 Whereas hexedit shows 3030 ??
  49 -----------------------------------------------------------------------------
  50 Description: Make sure that that gdcm lib can be dlopen'ed/dlclose
  51 Date: 2005 Sep 14
  52 Attributed: Mathieu
  53 Details:
  54   As reported in ITK mailing list, the global symbols are completely
  55   skrewed up in gdcm, preventing one to dlopen/dlclose gdcm lib.
  56   -> Need to add a nighlty test
  57   -> Need to write the code :(
  58 -----------------------------------------------------------------------------
  59 Description: Add testing of valid dictionary
  60 Date: 2005 Aug 31
  61 Attributed: Mathieu
  62 Details:
  63 Since that now private/shadow dictionary are available
  64 it would be nice to start implementing an automatic mode of loading
  65 those dictionary as we read the public one.
  66 Comments: It shouldn't be too difficult to 'manualy' ask memory merging
  67           of a Private Dict into the public one (I can do it soon).
  68                          Automatic recognition of the Private Dict to be used seems hopeless.
  69 -----------------------------------------------------------------------------
  70 Description: gdcm::SerieHelper / UID / set of rules
  71 Date: 2005 Aug 30
  72 Attributed: Mathieu
  73 Details:
  74   gdcm::SerieHelper now offer a mechanism to add rules to sub select image
  75 as we iterate over them within a subdirectory structure. But what if UID was too
  76 restrictive ? Therefore UID subselection become only a good default rule, which
  77 should ideally be removed when user need a specific task.
  78 Comments:
  79 -----------------------------------------------------------------------------
  80 Description: Add testing of valid dictionary
  81 Date: 2005 Aug 29
  82 Attributed: Mathieu
  83 Details:
  84 It is potentially possible that user modifies the dictionary that gdcm provides
  85 and this is also possible that the dictionary generated from pdf is buggy
  86 (see 2001,xx5F. VR = SQ, VM = 1-n, from
  87 www.medical.philips.com/main/company/connectivity/assets/docs/dicomcs/mr91.pdf)
  88 Therefore gdcm should check for any typo, and report it (if possible)
  89 Comments:
  90 -----------------------------------------------------------------------------
  91 Description: Add kwsys as a subdir somewhere in gdcm
  92 Date: 2004 Oct 8
  93 Attributed: Mathieu
  94 Details:
  95   kwsys is a lightweight library developped by kitware, used in project like
  96 ITK, VTK, CMake and ParaView. It runs and compile on almost any plateform with c++
  97 compiler. And it provide a cross plateform approach to any kind of system call
  98 (executing a process, killing a process, realpath, filename/directory management ...)
  99 Comments:
 100    * jpr : what does 'kwsys' stand for?
 101 -----------------------------------------------------------------------------
 102 Description: Extent reading support
 103 Date: 2004 Oct 8
 104 Attributed: Mathieu
 105 Details:
 106 Comments: All ITK/VTK readers support selecting extent. gdcm should support
 107 selecting extent before being inserted into ITK
 108 -----------------------------------------------------------------------------
 109 Description: gdcmDicomDir and SQItem creation
 110 Date: 2004 Nov 16
 111 Attributed:
 112 Details: DicomDir creates some SQItem (by new). Then, it creates
 113   the corresponding DicomDirPatient, etc. using the content of the SQItem
 114   (the content is composed with some DocEntry's that can't be destroyed).
 115   So, if the SQItem is deleted, then it's content is deleted to. But the
 116   DicomDirPatient, etc. use the content of the SQItem. Then, the SQItem can't
 117   be deleted, and when have memory leaks
 118 Comments :
 119    * JPR : Fixed
 120 -----------------------------------------------------------------------------
 121 Description: [BUG] Better handling of unfound Dicom dictionary.
 122              When gdcm doesn't find the Dicom dictionary (because it's
 123              path to the directory of dictionary is uncorrect, either
 124              because the install relative layout was broken after file moves
 125              or because the environnement variable GDCM_DICT_PATH is
 126              unpropely set), gdcm will:
 127              1/ print a warning
 128              2/ throw an exception (that is internaly UNcatched by gdcm)
 129                 that in most cases provoques the caller application to
 130                 exit uncleanly (uncatched excpetions in fine call abort() ).
 131              Additionaly on Win32 the warning print isn't displayed because
 132              exiting occurs prior to cerr or cout is flushed properly.
 133 Date: 2004 Oct 15
 134 Attributed:
 135 Details: fixes (from dirty to clean)
 136          1/ force Win32 to flush it's buffer so at least the user gets some
 137             reason why it's application exited (when called in command
 138             environement). Note: it looks like the "cerr << flush" fails. Sigh.
 139          2/ within gdcm catch the exception, display a decent warning, and
 140             return to caller.
 141          3/ see the comment below on how to enhance the API and fix things
 142             really cleanly.
 143 Comments: ENH proposal:
 144           The caller migth not be aware of the path to the dictionaries
 145           on invocation of gdcm (think this path is set by the Interface
 146           because the caller wants to skip the default gdcm dictionary in order
 147           to provide his own ones e.g. another language based one).
 148              Hence, gdcm should postpone the parsing of the default dictionary
 149           instead of doing it on library entry.
 150           This would enable two things:
 151            - It would give a chance to the caller to set the path to
 152              the dictionaries he whishes to use, through a call to
 153              newly created DictSet::SetDictionaryPath( string ).
 154            - It would avoid the burden of using the GDCM_DICT_PATH
 155              environnement variable and enable GDCM CONTROL FROM WITHIN
 156              THE API. Optionaly, if the caller didn't use the API to
 157              provide his prefered path, gdcm could still default to
 158              GDCM_DICT_PATH...
 159 -----------------------------------------------------------------------------
 160 Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
 161 Date: 2004 Oct 1
 162 Attributed:
 163 Details: vtkGdcmReader::CheckFileCoherence() sets the DataOrigin[i]
 164          but doesn't set the plane (image seen in 3D) normal (is it
 165          possible any how). This plane normal could be extracted from
 166          the "orientation" info of the gdcmHeader ( refer to
 167          grep "Orientation" Dicts/dicomV3.dic).
 168          Problem exhibiting this defect: cine loop on a stack of images
 169                whose Origin is correct, but whose normal is not set will
 170                plainly suck !
 171 Comments:
 172         * vtkGdcmReader inherits from vtkImageReader which aggregates
 173           a vtkTranform. vtkGdcmReader could store (when the user requires
 174           it, see below) the origin/normal taken from the Dicom Header
 175           within this vtkTransform (looks like a natural place to store
 176           this spacial information).
 177         * Both settings of the origin and/OR the normal of the plane (image)
 178           should be an option defined with a flag (On/Off) in the
 179           vtkGdcmReader...
 180 -----------------------------------------------------------------------------
 181 Description: test the private dictionary part.
 182 Date: 2004 Sep 24
 183 Attributed:
 184 Details:
 185 Comments:
 186  * Frog: where can we obtain such a private/dictionary and the corresponding
 187          Dicom file ? Any examples on-line ?
 188  * jpr : some are in gdcm/Dicts (built from pdf documents found on constructors'
 189         www sites.
 190         When we check them against existing images, we see the are uncomplete
 191         and unaccurate ...
 192 -----------------------------------------------------------------------------
 193 Description: generate methods based on VM.
 194 Date: 2004 Jul 30
 195 Attributed:
 196 Details:
 197  * cmake should parse le DICOM dictionary to generate methods like
 198    gdcm???::SetImagePosition(int, int)
 199    {
 200      //generated content do not edit
 201      ...
 202    }
 203    gdcm???::SetImageNumber(int)
 204    {
 205      //generated content do not edit
 206      ...
 207    }
 208 Comments:
 209  * Regrain: a dicom dictionary entry name is NOT UNIQUE [this means
 210      two tags=(group, element) can share the same name].
 211      What should the wrapper do in such a case !?
 212  * Frog: what does VM stand for ?
 213  * VM = Value Multiplicity
 214 -----------------------------------------------------------------------------
 215 Description: Add information on supported imagers (constructor/model)
 216 Date: 2004 9 7
 217 Attributed:
 218 Details: in order to promote gdcm make a list (on the web pages)
 219          of images successfully parsed based on a constructor/model ordering
 220 Comments:
 221  * frog: gdcmData only lists pathological images. How to collect
 222          the ones gdcm works smoothly with (hopefully gdcmData is a small
 223          subset of what we would like).
 224   * jpr : gdcmData contains images that caus*ed* us some troubles.
 225           the aim of gdcm is to read *all* the images, from *all* the
 226           constructors and *all* the models.
 227           Better we do a 'gdcm Dicom Hall of Shame' with bugged header images,
 228           explaining *why* the header is bugged.
 229 -----------------------------------------------------------------------------
 230 Description: Add a GetVersion() global function.
 231 Date: 2003 july 7
 232 Attributed:
 233 Details: This is to be used for version assertion with gdcmPython
 234 Comments: Done (August 2005)
 235 -----------------------------------------------------------------------------
 236 * vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
 237   be made at the cost of memory consumption (refer to header of
 238   vtk/vtkGdcmHeader.cxx)
 239 -----------------------------------------------------------------------------
 240 * gdcmElValSet::SetElValueLengthByNumber IMNSHO should be trashed.
 241   It's only purpose is a onliner substitute to calling GetElValueByNumber
 242   and then SetLength. This only obfuscates the caller code more than
 243   clarifying it.
 244   Besides the definition of gdcmElValSet::SetElValueLengthByNumber itself
 245   it quite poor since it is a almost exact copy of
 246   gdcmElValSet::GetElValueByNumber except for the returned code.
 247   gdcmHeader::SetPubElValLengthByNumber (which is based on
 248   gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
 249 Comments:
 250    * jpr : all the methods SetxxxByName were trashed.
 251            all the methods SetxxxByNumber were renamed
 252            A general method clean out was performed
 253 -----------------------------------------------------------------------------
 254 * All (or at least many of) the methods of gdcmHeader whose only arguments
 255   are an ElValue* (e.g.  FindLength, FindVR, LoadElementValue...) can
 256   be moved away to ElValue class on condition of transmitting the
 257   gdcmHeader.fp attribute. This change should be considered since it
 258   would allow those method to avoid artificial calls to ElValue::GetElement(),
 259   ElValue::GetVR()...
 260 -----------------------------------------------------------------------------
 261 * Group length is not a unique tag in a file. Hence avoid putting it
 262   in the element values dictionary without doing something smarter
 263   (say, instead of storing the length store the group and the length
 264    so we can related a length to a group).
 265 -----------------------------------------------------------------------------
 266 * GetPubElValByNumber doit faire la difference entre chaine vide
 267   et chaine pas trouve'e. Eventuellement raiser une exception ?
 268 -----------------------------------------------------------------------------
 269 * gdcmHeader::LoadElements only loads the element whose length is
 270   below the specified size. When accessing the value of such an element
 271   the content is unfound ! Find a decent way of loading the value on
 272   explicit demand.
 273 -----------------------------------------------------------------------------
 274 * JPR: supply a method that only reads/loads (?) the Dicom elements
 275   given as a list(?).
 276 -----------------------------------------------------------------------------
 277 * JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
 278   suite si on a deduit que c'en est pas...
 279 -----------------------------------------------------------------------------
 280 * python /usr/lib/python2.2/site-packages/DaVaW/demo/dvwDcmReader.py
 281   and load image /home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
 282   will yield wrong coloring scheme as opposed to
 283   affim filein=/home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
 284 -----------------------------------------------------------------------------
 285 * gdcmFile should implement the following API:
 286    gdcmFile WriteDicom;
 287    WriteDicom.SetFileName("MyDicomFile.dcm");
 288    string * AllTags = gdcmHeader.GetDcmTagNames();
 289    WriteDicom.SetDcmTag(AllTags[5], "253");
 290    WriteDicom.SetDcmTag("Patient Name", "bozo");
 291    WriteDicom.SetDcmTag("Patient Name", "bozo");
 292    WriteDicom.SetImageData(Image);
 293    WriteDicom.Write();
 294
 295    Anonymize(ostream& output) {
 296       a = gdcmFile("toto1");
 297       a.SetPubValueByName("Patient Name", "");
 298       a.SetPubValueByName("Date", "");
 299       a.SetPubValueByName("Study Date", "");
 300       a.write(output);
 301    }
 302 -----------------------------------------------------------------------------
 303