-Use namespace gdcm:
- Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin
- causes problems.
- Question: when introducing the namespace, should we remove the gdcm
- prefix from classes or keep it ?
------------------------------------------------------------------------------
-Convert the C-like IO to C++ IO:
- Goal: remove all the C-oriented IO references like FILE*, fread...
- with the C++ fstream notation. Provide overload of operators
- << and >> for any gdcm class using file IO.
- 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 ?
- References:
- binary IO are available at
- http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
------------------------------------------------------------------------------
-Switch from errno C-style to exceptions:
- Goal: remove all the C-oriented errno (#include <errno.h>) and switch
- to C++ exceptions.
- Note: - only src/gdcmDocument.cxx includes errno.h
- - when exceptions were first introduced within gdcm, it caused
- gdcmPython to be uncompatible within the corresponding version
- of wxPython (refer to the first lines of
- Test/ExceptionAndPython/README). Hence we reverted to the old
- errno mecanisme. Since wxPython seems not to be problem anymore
- (check it with Test/ExceptionAndPython) we can now move back to C++
- exceptions.
------------------------------------------------------------------------------
-CLEANUP:
- - Remove ignore_shadow from gdcmDocument().
+Proposed Template of an entry in this TODO:
+(Note: Date is the date of registering of first demand.)
+
+-------------
+Description:
+Date:
+Attributed:
+Details:
+Comments:
+-------------
+
+-----------------------------------------------------------------------------
+Description: Add kwsys as a subdir somewhere in gdcm
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: Extent reading support
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: All ITK/VTK readers support selecting extent. gdcm should support
+selecting extent before being inserted into ITK
+-----------------------------------------------------------------------------
+Description: gdcmDicomDir and SQItem creation
+Date: 2004 Nov 16
+Attributed:
+Details: DicomDir creates some SQItem (by new). After that, it creates
+ the corresponding DicomDirPatient, etc. using the content of the SQItem
+ (the content is composed with some DocEntry's that can't be destroyed).
+ So, if the SQItem is deleted, then it's content is deleted to. But the
+ DicomDirPatient, etc. use the content of the SQItem. Then, the SQItem can't
+ be deleted, and when have memory leaks
+
+-----------------------------------------------------------------------------
+Description: [BUG] Better handling of unfound Dicom dictionary.
+ When gdcm doesn't find the Dicom dictionary (because it's
+ path to the directory of dictionary is uncorrect, either
+ because the install relative layout was broken after file moves
+ or because the environnement variable GDCM_DICT_PATH is
+ unpropely set), gdcm will:
+ 1/ print a warning
+ 2/ throw an exception (that is internaly UNcatched by gdcm)
+ that in most cases provoques the caller application to
+ exit uncleanly (uncatched excpetions in fine call abort() ).
+ Additionaly on Win32 the warning print isn't displayed because
+ exiting occurs prior to cerr or cout is flushed properly.
+Date: 2004 Oct 15
+Attributed:
+Details: fixes (from dirty to clean)
+ 1/ force Win32 to flush it's buffer so at least the user gets some
+ reason why it's application exited (when called in command
+ environement). Note: it looks like the "cerr << flush" fails. Sigh.
+ 2/ within gdcm catch the exception, display a decent warning, and
+ return to caller.
+ 3/ see the comment below on how to enhance the API and fix things
+ really cleanly.
+Comments: ENH proposal:
+ The caller migth not be aware of the path to the dictionaries
+ on invocation of gdcm (think this path is set by the Interface
+ because the caller wants to skip the default gdcm dictionary in order
+ to provide his own ones e.g. another language based one).
+ Hence, gdcm should postpone the parsing of the default dictionary
+ instead of doing it on library entry.
+ This would enable two things:
+ - It would give a chance to the caller to set the path to
+ the dictionaries he whishes to use, through a call to
+ newly created DictSet::SetDictionaryPath( string ).
+ - It would avoid the burden of using the GDCM_DICT_PATH
+ environnement variable and enable GDCM CONTROL FROM WITHIN
+ THE API. Optionaly, if the caller didn't use the API to
+ provide his prefered path, gdcm could still default to
+ GDCM_DICT_PATH...
+-----------------------------------------------------------------------------
+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: 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: 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 ?
+ * VM = Value Multiplicity
+-----------------------------------------------------------------------------
+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: