+-----------------------------------------------------------------------------
+Proposed Template of an entry in this TODO:
+(Note: Date is the date of registering of first demand.)
+
+-------------
+Description:
+Date:
+Attributed:
+Details:
+Comments:
+-------------
+
+
+-----------------------------------------------------------------------------
+-----------------------------------------------------------------------------
+Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
+Date: 2004 Oct 1
+Attributed:
+Details: vtkGdcmReader::CheckFileCoherence() sets the DataOrigin[i]
+ but doesn't set the plane (image seen in 3D) normal (is it
+ possible any how). This plane normal could be extracted from
+ the "orientation" info of the gdcmHeader ( refer to
+ grep "Orientation" Dicts/dicomV3.dic).
+ Problem exhibiting this defect: cine loop on a pile of images
+ whose Origin is correct, but whose normal is not set will
+ plainly suck !
+Comments:
+ * vtkGdcmReader inherits from vtkImageReader which aggregates
+ a vtkTranform. vtkGdcmReader could store (when the user requires
+ it, see below) the origin/normal taken from the Dicom Header
+ within this vtkTransform (looks like a natural place to store
+ this spacial information).
+ * Both settings of the origin and/OR the normal of the plane (image)
+ should be an option defined with a flag (On/Off) in the
+ vtkGdcmReader...
+-----------------------------------------------------------------------------
+Description: Fix the Python wrappers
+Date: 2004 Sep 24
+Attributed: no
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: clean up gdcmFile/gdcmHeader relationship
+Date: 2004 Sep 24
+Attributed:
+Details:
+ * simplify the API for the user (no need to call GetImageData() before
+ calling Write().
+ * avoid memory leaks with with Pixel_Data.
+Comments:
+-----------------------------------------------------------------------------
+Description: remove all autotools references
+Date: 2004 Sep 24
+Attributed: no
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: introduce namespace "gdcm"
+Date: 2004 Jul 30
+Attributed:
+Details:
+Comments:
+ 1/ Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin
+ causes problems.
+ 2/ Question: when introducing the namespace, should we remove the gdcm
+ prefix from classes or keep it ?
+-----------------------------------------------------------------------------
+Description: complete the doxygen Documentation
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: test the private dictionary part.
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments:
+ * Frog: where can we obtain such a private/dictionary and the corresponding
+ Dicom file ? Any examples on-line ?
+-----------------------------------------------------------------------------
+Description: fix definitively the memory leaks problems.
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: test gdcm on a big endian OS.
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: More tests !
+Date: 2004 Sep 24
+Attributed:
+Details:
+ * an example of new test could be to clone a Dicom image by
+ copying gdcmDocEntry one after the other
+Comments:
+ * look at traversal used in Example/FlatHashTablePrint.cxx
+-----------------------------------------------------------------------------
+Description: revoir la gestion des resources, win32 permet d'inclure des
+ fichiers texte (=dicomV3.dic) dans une dll ou quelquechose du genre.
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments:
+ * Frog: no comprendo !? De plus est-ce portable ?
+-----------------------------------------------------------------------------
+Description: Convert the C-like IO to C++ IO:
+Date: 2004 Jul 30
+Attributed:
+Details:
+ remove all the C-oriented IO references like FILE*, fread...
+ and replace them with the C++ fstream notation.
+ Provide overload of operators << and >> for any gdcm class using file IO.
+Comments:
+ * Question: the underlying jpeg libraries (written in C) use the FILE*
+ notation. Is there a way to still use fstream in gdcm, and
+ build or pass the proper FILE* to jpeg libs ?
+ * Binary IO references are available at
+ http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
+-----------------------------------------------------------------------------
+Description: generate methods based on VM.
+Date: 2004 Jul 30
+Attributed:
+Details:
+ * cmake should parse le DICOM dictionary to generate methods like
+ gdcm???::SetImagePosition(int, int)
+ {
+ //generated content do not edit
+ ...
+ }
+ gdcm???::SetImageNumber(int)
+ {
+ //generated content do not edit
+ ...
+ }
+Comments:
+ * Regrain: a dicom dictionary entry name is NOT UNIQUE [this means
+ two tags=(group, element) can share the same name].
+ What should the wrapper do in such a case !?
+ * Frog: what does VM stand for ?
+-----------------------------------------------------------------------------
+Description: Add information on supported imagers (constructor/model)
+Date: 2004 9 7
+Attributed:
+Details: in order to promote gdcm make a list (on the web pages)
+ of images successfully parsed based on a constructor/model ordering
+Comments: * frog: gdcmData only lists pathological images. How to collect
+ the ones gdcm works smoothly with (hopefully gdcmData is a small
+ subset of what we would like).
+-----------------------------------------------------------------------------
+Description: Add a GetVersion() global function.
+Date: 2003 july 7
+Attributed:
+Details: This is to be used for version assertion with gdcmPython
+Comments:
+-----------------------------------------------------------------------------
+-----------------------------------------------------------------------------
+* vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
+ be made at the cost of memory consumption (refer to header of
+ vtk/vtkGdcmHeader.cxx)
+-----------------------------------------------------------------------------