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