-----------------------------------------------------------------------------
-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
+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 testing of valid dictionary
+Date: 2005 Aug 29
+Attributed: Mathieu
+Details:
+It is potentially possible that user modify the dictionary that gdcm provide
+and this is also possible that the dictionary generated from pdf is buggy
+(see 2001,xx5F. VR = SQ, VM = 1-n, from
+www.medical.philips.com/main/company/connectivity/assets/docs/dicomcs/mr91.pdf)
+Therefore gdcm should check for any typo, and report it (if possible)
+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:
-----------------------------------------------------------------------------
* 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)
-* Add a GetVersion() global function.
+-----------------------------------------------------------------------------
* gdcmElValSet::SetElValueLengthByNumber IMNSHO should be trashed.
It's only purpose is a onliner substitute to calling GetElValueByNumber
and then SetLength. This only obfuscates the caller code more than
gdcmElValSet::GetElValueByNumber except for the returned code.
gdcmHeader::SetPubElValLengthByNumber (which is based on
gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
-* Fix the bug in Test/bug1.cxx (see first comment line): Win32 only.
+-----------------------------------------------------------------------------
* All (or at least many of) the methods of gdcmHeader whose only arguments
are an ElValue* (e.g. FindLength, FindVR, LoadElementValue...) can
be moved away to ElValue class on condition of transmitting the
gdcmHeader.fp attribute. This change should be considered since it
would allow those method to avoid artificial calls to ElValue::GetElement(),
ElValue::GetVR()...
-* Eat leanding_trailing_whitespace (found in python/gdcmPython/gdcmi) should
- be used when parsing the dictionary in C++ !
+-----------------------------------------------------------------------------
* Group length is not a unique tag in a file. Hence avoid putting it
in the element values dictionary without doing something smarter
(say, instead of storing the length store the group and the length
so we can related a length to a group).
+-----------------------------------------------------------------------------
* GetPubElValByNumber doit faire la difference entre chaine vide
et chaine pas touve''. Eventuellement raiser une exception ?
+-----------------------------------------------------------------------------
* gdcmHeader::LoadElements only loads the element whose length is
below the specified size. When accessing the value of such an element
the content is unfound ! Find a decent way of loading the value on
explicit demand.
+-----------------------------------------------------------------------------
* JPR: fournir une method qui ne fait que lire les elements passes en arguments
sous forme d'une liste.
+-----------------------------------------------------------------------------
* JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
suite si on a deduit que c'en est pas...
+-----------------------------------------------------------------------------
* python /usr/lib/python2.2/site-packages/DaVaW/demo/dvwDcmReader.py
and load image /home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
will yield wrong coloring scheme as opposed to
affim filein=/home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
-* gdcmFile should implement the following:
+-----------------------------------------------------------------------------
+* gdcmFile should implement the following API:
gdcmFile WriteDicom;
WriteDicom.SetFileName("MyDicomFile.dcm");
string * AllTags = gdcmHeader.GetDcmTagNames();
a.SetPubValueByName("Study Date", "");
a.write(output);
}
+-----------------------------------------------------------------------------
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff