+-----------------------------------------------------------------------------
+Proposed Template of an entry in this TODO:
+(Note: Date is the date of registering of first demand.)
+
+-------------
+Description:
+Date:
+Attributed:
+Details:
+Comments:
+-------------
+
+
+-----------------------------------------------------------------------------
+Description: gdcmJpeg8 is strictly a copy/paste of gdcmJpeg12.cxx.
+Date: 2004 Oct 13
+Attributed:
+Details:
+We should write the code in a common place, then include this 'cxx' file so the the define from gdcm_mangle redefine to the proper one.
+Comments:
+This will be usefull since I may need in the future a 16bits version of this reading
+-----------------------------------------------------------------------------
+Description: Change jpeg 'exit' call to standard c++ exception using the jpeg error
+handler
+Date: 2004 Oct 8
+Attributed:
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: Add kwsys as a subdir somewhere in gdcm
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: ljpeg
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: ljpeg was rip from medcon and not the official one. medcon tried to
+optimised function using MACRO (doh!), so it make its very unreadable and very
+hard to fix warnings. Should go back to official source, copy proper copyright
+and fix warnings on dashboard
+13/10: update apparently no dicom toolkit use this lib as it is too buggy. We should use the ls-patch for ijg instead. Thus we can safely get rid of that lib.
+14/10: PHILIPS_Gyroscan-12-MONO2-Jpeg_Lossless.dcm prove that I was right the old Cornwell lib is buggy and does not read anything.
+-----------------------------------------------------------------------------
+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: Generate new UID each time we write DICOM
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: According to DICOM ref a new UID should be created each we write a
+DICOM images. I guess it should be an option so that we can still use md5sum to
+check dicom file. The proposed way was:
+http://www.creatis.insa-lyon.fr/pipermail/dcmlib/2004-September/000611.html
+
+Bah, comme Win32 pose encore pb:
+ echo "gdcm" | od -b
+ 0000000 147 144 143 155 012
+et si on prenait:
+ radical + 147.144.143.155 + IP + time()
+
+-----------------------------------------------------------------------------
+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: 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: There is a nightly dashboard that run valgrind every night
+(zorglub | GDCM-Linux-g++)
+-----------------------------------------------------------------------------
+Description: test gdcm on a big endian OS.
+Date: 2004 Sep 24
+Attributed:
+Details:
+Comments: There is a nightly dashboard that run on MacOSX each nite
+(midworld.kitwarein | GDCM-DarwinG5-g++ )
+-----------------------------------------------------------------------------
+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: Mathieu
+Details:
+Comments:
+ * Frog: no comprendo !? De plus est-ce portable ?
+ * To improve load time it could be usefull to have the dictionary directly in
+ 'c++' code or in a more binary format.
+ * This will also solve some issues where /dummy/ user did nor set
+ GDCM_DICT_PATH properly neither 'make install'
+-----------------------------------------------------------------------------
+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
+ * The internal API should be rewritten so that gdcm speaking to jpeg lib is
+ done with stream/string and not directly opened FILE*
+ * No stdio.h anymore anywhere tolerated !
+-----------------------------------------------------------------------------
+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)
+-----------------------------------------------------------------------------
+* 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
+ clarifying it.
+ Besides the definition of gdcmElValSet::SetElValueLengthByNumber itself
+ it quite poor since it is a almost exact copy of
+ 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 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
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 API:
+ gdcmFile WriteDicom;
+ WriteDicom.SetFileName("MyDicomFile.dcm");
+ string * AllTags = gdcmHeader.GetDcmTagNames();
+ WriteDicom.SetDcmTag(AllTags[5], "253");
+ WriteDicom.SetDcmTag("Patient Name", "bozo");
+ WriteDicom.SetDcmTag("Patient Name", "bozo");
+ WriteDicom.SetImageData(Image);
+ WriteDicom.Write();
-GetPubElValByNumber doit faire la difference entre chaine vide
-et chaine pas touve''. Eventuellement raiser une exception ?
-
-gdcmHeader::ReadNextElement: retarder le stockage en mem des gros elements
- * etablir une taille limite sur les elements a ramener en memoire
- (parametrisable en public dans la classe)
- * ne pas ramener les elements au dela de ce seuil, mais les flaguer
- comme a charger plus tard
- * a l'acces (pour le groupe des pixels par exemple) retourner au fichier
- pour trouver la bonne valeur (GetPixelData).
- * fournir une method qui ne fait que lire les elements passes en arguments
- sous forme d'une liste.
-
-grep str2num *.cxx: c'est une macro sans doute proprifiable
-
-gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de suite
-si on a deduit que c'en est pas...
+ Anonymize(ostream& output) {
+ a = gdcmFile("toto1");
+ a.SetPubValueByName("Patient Name", "");
+ a.SetPubValueByName("Date", "");
+ a.SetPubValueByName("Study Date", "");
+ a.write(output);
+ }
+-----------------------------------------------------------------------------
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff