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