Comments:
-------------
-----------------------------------------------------------------------------
-Description: Rewrite gdcmDebug so that it works
-Date: 2004 Dec 07
-Attributed: Mathieu
+-----------------------------------------------------------------------------
+Description: GDCM does not read Spacing properly.
+Date: 2006 June 5
+Attributed:
Details:
-Comments:
-----------------------------------------------------------------------------
-Description: Need to fix cygwin + wrong path (passing UNIX path when windows patch expected)
-Date: 2004 Nov 16
+GDCM is ready completely random values to find out the spacing/origin or an
+image. It *SHOULD* first find the IOD and then deduce which tags to read
+Eg: Cross section this is in Pixel Spacing (0028,0030)
+CR is in Imager Pixel Spacing (0018,1164)
+US is in Pixel Ratio (0028,0034)
+RT is in :
+(3002,0011) Image Plane Pixel Spacing
+(3002,0012) RT Imaga ePosition
+and
+(3004,000c) for deducing Z spacing
+-----------------------------------------------------------------------------
+Description: GDCM is pretty dumb with binary data
+Date: 2006 May 1
+Attributed:
+Details:
+D 0028|0009 [AT] [Frame Increment Pointer] [gdcm::Binary data loaded;length = 4]
+-----------------------------------------------------------------------------
+Description: gdcm does not handle deflate TS
+Date: 2006 Jan 25
Attributed: Mathieu
Details:
-Comments:
-----------------------------------------------------------------------------
-Description: Need a test for gdcmHeaderHelper (iterating over gdcmData) for instance
-Date: 2004 Nov 16
+image_dfl from dclunie website is not working since the *whole* dataset
+is compressed. Therefore we cannot even parse the file.
+-----------------------------------------------------------------------------
+Description: Problem with PrintFile and OB field
+Date: 2005 Dec 30
Attributed: Mathieu
Details:
-Comments: It used to seg fault when a README file was found
-----------------------------------------------------------------------------
-Description: gdcmJpeg8 is strictly a copy/paste of gdcmJpeg12.cxx.
-Date: 2004 Oct 13
-Attributed:
+ Doing a PrintFile on RickAvila DataSet we get:
+D 0043|1028 lg : x(2) 2 Off.: x(bb2) 2994 [OB] [Unique image iden] [00]
+Whereas hexedit shows 3030 ??
+-----------------------------------------------------------------------------
+Description: Make sure that that gdcm lib can be dlopen'ed/dlclose
+Date: 2005 Sep 14
+Attributed: Mathieu
Details:
-We should write the code in a common place, then include this 'cxx' file so
-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
+ As reported in ITK mailing list, the global symbols are completely
+ skrewed up in gdcm, preventing one to dlopen/dlclose gdcm lib.
+ -> Need to add a nighlty test
+ -> Need to write the code :(
-----------------------------------------------------------------------------
-Description: Change jpeg 'exit' call to standard c++ exception using the jpeg
- error
-handler
-Date: 2004 Oct 8
-Attributed:
+Description: Add testing of valid dictionary
+Date: 2005 Aug 31
+Attributed: Mathieu
Details:
+Since that now private/shadow dictionary are available
+it would be nice to start implementing an automatic mode of loading
+those dictionary as we read the public one.
+Comments: It shouldn't be too difficult to 'manualy' ask memory merging
+ of a Private Dict into the public one (I can do it soon).
+ Automatic recognition of the Private Dict to be used seems hopeless.
+-----------------------------------------------------------------------------
+Description: gdcm::SerieHelper / UID / set of rules
+Date: 2005 Aug 30
+Attributed: Mathieu
+Details:
+ gdcm::SerieHelper now offer a mechanism to add rules to sub select image
+as we iterate over them within a subdirectory structure. But what if UID was too
+restrictive ? Therefore UID subselection become only a good default rule, which
+should ideally be removed when user need a specific task.
Comments:
-----------------------------------------------------------------------------
-Description: Add kwsys as a subdir somewhere in gdcm
-Date: 2004 Oct 8
+Description: Add testing of valid dictionary
+Date: 2005 Aug 29
Attributed: Mathieu
Details:
+It is potentially possible that user modifies the dictionary that gdcm provides
+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: ljpeg
+Description: Add kwsys as a subdir somewhere in gdcm
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.
+ kwsys is a lightweight library developped by kitware, used in project like
+ITK, VTK, CMake and ParaView. It runs and compile on almost any plateform with c++
+compiler. And it provide a cross plateform approach to any kind of system call
+(executing a process, killing a process, realpath, filename/directory management ...)
+Comments:
+ * jpr : what does 'kwsys' stand for?
-----------------------------------------------------------------------------
Description: Extent reading support
Date: 2004 Oct 8
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: gdcmDicomDir and SQItem creation
Date: 2004 Nov 16
Attributed:
-Details: DicomDir creates some SQItem (by new). After that, it creates
+Details: DicomDir creates some SQItem (by new). Then, 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
-
+Comments :
+ * JPR : Fixed
-----------------------------------------------------------------------------
Description: [BUG] Better handling of unfound Dicom dictionary.
When gdcm doesn't find the Dicom dictionary (because it's
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
+ Problem exhibiting this defect: cine loop on a stack of images
whose Origin is correct, but whose normal is not set will
plainly suck !
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:
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 !
+ * jpr : some are in gdcm/Dicts (built from pdf documents found on constructors'
+ www sites.
+ When we check them against existing images, we see the are uncomplete
+ and unaccurate ...
-----------------------------------------------------------------------------
Description: generate methods based on VM.
Date: 2004 Jul 30
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).
+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).
+ * jpr : gdcmData contains images that caus*ed* us some troubles.
+ the aim of gdcm is to read *all* the images, from *all* the
+ constructors and *all* the models.
+ Better we do a 'gdcm Dicom Hall of Shame' with bugged header images,
+ explaining *why* the header is bugged.
-----------------------------------------------------------------------------
Description: Add a GetVersion() global function.
Date: 2003 july 7
Attributed:
Details: This is to be used for version assertion with gdcmPython
-Comments:
------------------------------------------------------------------------------
+Comments: Done (August 2005)
-----------------------------------------------------------------------------
* vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
be made at the cost of memory consumption (refer to header 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.
+Comments:
+ * jpr : all the methods SetxxxByName were trashed.
+ all the methods SetxxxByNumber were renamed
+ A general method clean out was performed
-----------------------------------------------------------------------------
* All (or at least many of) the methods of gdcmHeader whose only arguments
are an ElValue* (e.g. FindLength, FindVR, LoadElementValue...) can
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 ?
+ et chaine pas trouve'e. 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: supply a method that only reads/loads (?) the Dicom elements
+ given as a list(?).
-----------------------------------------------------------------------------
* JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
suite si on a deduit que c'en est pas...
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff