X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;f=TODO;h=7b9bf3fe0233d0970f3ae6ccd81002c321d7c37a;hb=b0f62020f3423bf7663fdf856000dc245e417d9a;hp=f410e287caa1226334df139b34f67bb91e7fb0bc;hpb=88f0914a8dd9327056361ae14d62ead303f2a9ed;p=gdcm.git diff --git a/TODO b/TODO index f410e287..7b9bf3fe 100644 --- a/TODO +++ b/TODO @@ -10,8 +10,69 @@ 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 @@ -34,43 +95,6 @@ Comments: 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: @@ -79,49 +103,6 @@ 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: @@ -142,6 +123,7 @@ Comments: 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 @@ -158,7 +140,6 @@ 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) @@ -173,8 +154,6 @@ Comments: 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 @@ -182,9 +161,6 @@ Comments: would allow those method to avoid artificial calls to ElValue::GetElement(), ElValue::GetVR()... ----------------------------------------------------------------------------- -* Eat leading_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 @@ -227,3 +203,4 @@ Comments: a.write(output); } ----------------------------------------------------------------------------- +