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