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 -----------------------------------------------------------------------------
  15 -----------------------------------------------------------------------------
  16 Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
  17 Date: 2004 Oct 1
  18 Attributed:
  19 Details: vtkGdcmReader::CheckFileCoherence() sets the DataOrigin[i]
  20          but doesn't set the plane (image seen in 3D) normal (is it
  21          possible any how). This plane normal could be extracted from
  22          the "orientation" info of the gdcmHeader ( refer to
  23          grep "Orientation" Dicts/dicomV3.dic).
  24          Problem exhibiting this defect: cine loop on a pile of images
  25                whose Origin is correct, but whose normal is not set will
  26                plainly suck !
  27 Comments:
  28         * vtkGdcmReader inherits from vtkImageReader which aggregates
  29           a vtkTranform. vtkGdcmReader could store (when the user requires
  30           it, see below) the origin/normal taken from the Dicom Header
  31           within this vtkTransform (looks like a natural place to store
  32           this spacial information).
  33         * Both settings of the origin and/OR the normal of the plane (image)
  34           should be an option defined with a flag (On/Off) in the
  35           vtkGdcmReader...
  36 -----------------------------------------------------------------------------
  37 Description: Fix the Python wrappers
  38 Date: 2004 Sep 24
  39 Attributed: no
  40 Details:
  41 Comments:
  42 -----------------------------------------------------------------------------
  43 Description: clean up gdcmFile/gdcmHeader relationship
  44 Date: 2004 Sep 24
  45 Attributed:
  46 Details:
  47  * simplify the API for the user (no need to call GetImageData() before
  48    calling Write().
  49  * avoid memory leaks with with Pixel_Data.
  50 Comments:
  51 -----------------------------------------------------------------------------
  52 Description: remove all autotools references
  53 Date: 2004 Sep 24
  54 Attributed: no
  55 Details:
  56 Comments:
  57 -----------------------------------------------------------------------------
  58 Description: introduce namespace "gdcm"
  59 Date: 2004 Jul 30
  60 Attributed:
  61 Details:
  62 Comments:
  63   1/ Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin
  64               causes problems.
  65   2/ Question: when introducing the namespace, should we remove the gdcm
  66               prefix from classes or keep it ?
  67 -----------------------------------------------------------------------------
  68 Description: complete the doxygen Documentation
  69 Date: 2004 Sep 24
  70 Attributed:
  71 Details:
  72 Comments:
  73 -----------------------------------------------------------------------------
  74 Description: test the private dictionary part.
  75 Date: 2004 Sep 24
  76 Attributed:
  77 Details:
  78 Comments:
  79  * Frog: where can we obtain such a private/dictionary and the corresponding
  80          Dicom file ? Any examples on-line ?
  81 -----------------------------------------------------------------------------
  82 Description: fix definitively the memory leaks problems.
  83 Date: 2004 Sep 24
  84 Attributed:
  85 Details:
  86 Comments:
  87 -----------------------------------------------------------------------------
  88 Description: test gdcm on a big endian OS.
  89 Date: 2004 Sep 24
  90 Attributed:
  91 Details:
  92 Comments:
  93 -----------------------------------------------------------------------------
  94 Description: More tests !
  95 Date: 2004 Sep 24
  96 Attributed:
  97 Details:
  98  * an example of new test could be to clone a Dicom image by
  99    copying gdcmDocEntry one after the other
 100 Comments:
 101  * look at traversal used in Example/FlatHashTablePrint.cxx
 102 -----------------------------------------------------------------------------
 103 Description: revoir la gestion des resources, win32 permet d'inclure des
 104    fichiers texte (=dicomV3.dic) dans une dll ou quelquechose du genre.
 105 Date: 2004 Sep 24
 106 Attributed:
 107 Details:
 108 Comments:
 109  * Frog: no comprendo !? De plus est-ce portable ?
 110 -----------------------------------------------------------------------------
 111 Description: Convert the C-like IO to C++ IO:
 112 Date: 2004 Jul 30
 113 Attributed:
 114 Details:
 115    remove all the C-oriented IO references like FILE*, fread...
 116    and replace them with the C++ fstream notation.
 117    Provide overload of operators << and >> for any gdcm class using file IO.
 118 Comments:
 119  * Question: the underlying jpeg libraries (written in C) use the FILE*
 120    notation. Is there a way to still use fstream in gdcm, and
 121    build or pass the proper FILE* to jpeg libs ?
 122  * Binary IO references are available at
 123    http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
 124 -----------------------------------------------------------------------------
 125 Description: generate methods based on VM.
 126 Date: 2004 Jul 30
 127 Attributed:
 128 Details:
 129  * cmake should parse le DICOM dictionary to generate methods like
 130    gdcm???::SetImagePosition(int, int)
 131    {
 132      //generated content do not edit
 133      ...
 134    }
 135    gdcm???::SetImageNumber(int)
 136    {
 137      //generated content do not edit
 138      ...
 139    }
 140 Comments:
 141  * Regrain: a dicom dictionary entry name is NOT UNIQUE [this means
 142      two tags=(group, element) can share the same name].
 143      What should the wrapper do in such a case !?
 144  * Frog: what does VM stand for ?
 145 -----------------------------------------------------------------------------
 146 Description: Add information on supported imagers (constructor/model)
 147 Date: 2004 9 7
 148 Attributed:
 149 Details: in order to promote gdcm make a list (on the web pages)
 150          of images successfully parsed based on a constructor/model ordering
 151 Comments: * frog: gdcmData only lists pathological images. How to collect
 152     the ones gdcm works smoothly with (hopefully gdcmData is a small
 153     subset of what we would like).
 154 -----------------------------------------------------------------------------
 155 Description: Add a GetVersion() global function.
 156 Date: 2003 july 7
 157 Attributed:
 158 Details: This is to be used for version assertion with gdcmPython
 159 Comments:
 160 -----------------------------------------------------------------------------
 161 -----------------------------------------------------------------------------
 162 * vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
 163   be made at the cost of memory consumption (refer to header of
 164   vtk/vtkGdcmHeader.cxx)
 165 -----------------------------------------------------------------------------
 166 * gdcmElValSet::SetElValueLengthByNumber IMNSHO should be trashed.
 167   It's only purpose is a onliner substitute to calling GetElValueByNumber
 168   and then SetLength. This only obfuscates the caller code more than
 169   clarifying it.
 170   Besides the definition of gdcmElValSet::SetElValueLengthByNumber itself
 171   it quite poor since it is a almost exact copy of
 172   gdcmElValSet::GetElValueByNumber except for the returned code.
 173   gdcmHeader::SetPubElValLengthByNumber (which is based on
 174   gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
 175 -----------------------------------------------------------------------------
 176 * Fix the bug in Test/bug1.cxx (see first comment line): Win32 only.
 177 -----------------------------------------------------------------------------
 178 * All (or at least many of) the methods of gdcmHeader whose only arguments
 179   are an ElValue* (e.g.  FindLength, FindVR, LoadElementValue...) can
 180   be moved away to ElValue class on condition of transmitting the
 181   gdcmHeader.fp attribute. This change should be considered since it
 182   would allow those method to avoid artificial calls to ElValue::GetElement(),
 183   ElValue::GetVR()...
 184 -----------------------------------------------------------------------------
 185 * Eat leading_trailing_whitespace (found in python/gdcmPython/gdcmi) should
 186   be used when parsing the dictionary in C++ !
 187 -----------------------------------------------------------------------------
 188 * Group length is not a unique tag in a file. Hence avoid putting it
 189   in the element values dictionary without doing something smarter
 190   (say, instead of storing the length store the group and the length
 191    so we can related a length to a group).
 192 -----------------------------------------------------------------------------
 193 * GetPubElValByNumber doit faire la difference entre chaine vide
 194   et chaine pas touve''. Eventuellement raiser une exception ?
 195 -----------------------------------------------------------------------------
 196 * gdcmHeader::LoadElements only loads the element whose length is
 197   below the specified size. When accessing the value of such an element
 198   the content is unfound ! Find a decent way of loading the value on
 199   explicit demand.
 200 -----------------------------------------------------------------------------
 201 * JPR: fournir une method qui ne fait que lire les elements passes en arguments
 202   sous forme d'une liste.
 203 -----------------------------------------------------------------------------
 204 * JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
 205   suite si on a deduit que c'en est pas...
 206 -----------------------------------------------------------------------------
 207 * python /usr/lib/python2.2/site-packages/DaVaW/demo/dvwDcmReader.py
 208   and load image /home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
 209   will yield wrong coloring scheme as opposed to
 210   affim filein=/home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
 211 -----------------------------------------------------------------------------
 212 * gdcmFile should implement the following API:
 213    gdcmFile WriteDicom;
 214    WriteDicom.SetFileName("MyDicomFile.dcm");
 215    string * AllTags = gdcmHeader.GetDcmTagNames();
 216    WriteDicom.SetDcmTag(AllTags[5], "253");
 217    WriteDicom.SetDcmTag("Patient Name", "bozo");
 218    WriteDicom.SetDcmTag("Patient Name", "bozo");
 219    WriteDicom.SetImageData(Image);
 220    WriteDicom.Write();
 221
 222    Anonymize(ostream& output) {
 223       a = gdcmFile("toto1");
 224       a.SetPubValueByName("Patient Name", "");
 225       a.SetPubValueByName("Date", "");
 226       a.SetPubValueByName("Study Date", "");
 227       a.write(output);
 228    }
 229 -----------------------------------------------------------------------------