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