jpr [Fri, 21 Oct 2005 12:11:06 +0000 (12:11 +0000)]
// -->
// --> Can't understand *why* TestWriteSimple fails since the commit
// --> for dealing with GE Private Transfer Syntax.
// --> commented out, to be sure the troubles started from here.
// --> JP
regrain [Thu, 20 Oct 2005 15:24:05 +0000 (15:24 +0000)]
* Add a RefCounter object that is deleted only when it's reference count is
to 0.
* DicomEntry (thus, DictEntry) inherits from RefCounter... next stage to do,
all classes inherit from RefCounter
* Remove the VirtualDictEntry use, now useless due to the reference
counting. So, there will be no memory leaks.
-- BeNours
jpr [Thu, 20 Oct 2005 07:38:08 +0000 (07:38 +0000)]
-> Fix the pb of 'Private GE Transfer Syntax' for 16 bits images.
-> The expressions related to 'ImplicitVRLittleEndianDLXGE' are changed to talk
about 'Implicit VR Big Endian Transfer Syntax', that's the term commonly used in
the literature.
--> Merge ITK comments (much more detailled than mines) in the gdcm code.
regrain [Tue, 18 Oct 2005 12:58:23 +0000 (12:58 +0000)]
* Correctly use the VRKey for all vr variables... instead of TagName
or std::string
* Replace the definition of VRKey from std::string to a class
containing a char[2]. All methods are inline to have no speed low
* Create the GDCM_VRUNKNOWN = " " for the VR values
-- BeNours
jpr [Tue, 18 Oct 2005 11:10:45 +0000 (11:10 +0000)]
Fix cleanly (hope so) the mess in gdcm-MR-PHILIPS-16-Multi-Seq.dcm header
(a fffe|0000 impossible tag + a spurious item starter!)
--> Probabely we shouls propagate this fix to yesterday branch)
regrain [Tue, 18 Oct 2005 09:17:07 +0000 (09:17 +0000)]
* Remove useless constructor of gdcm::Document
* Remove useless parameter in the constructor of gdcm::ElementSet
* Split gdcmCommon to separate the System specifications to the gdcm
specifications
-- BeNours
regrain [Tue, 18 Oct 2005 08:35:42 +0000 (08:35 +0000)]
* Minor coding-style clean up
* Replace the ContentEntry and its derived classes (BinEntry and ValEntry)
by the DataEntry. This unique entry considers all datas like binary datas.
Some methods are added to interpret - at fly - the binary datas.
Due to this important change, some methods of the DocEntrySet, concerning
the BinEntry and ValEntry classes, are erased ; and new methods for the
DataEntry class are created.
Some methods to set the ValEntry or the BinEntry are renamed to
correspond to the new DataEntry, like for example :
- SetValEntry -> SetEntryString
- SetBinEntry -> SetEntryBinArea
This change will remove all useless creation of the string when working
directly on values.
-- BeNours
jpr [Mon, 17 Oct 2005 09:52:41 +0000 (09:52 +0000)]
SerieHelper Normalization : stage 1
-------------------------
- Put as 'deprecated' the confusing method names GetFirstCoherentFileList(),
GetNextCoherentFileList()
(the only 'cohenrence' they have is that they all have the same "Series
Instance UID")
- Add less confusing method names GetFirstSingleSerieUIDFileSet,
GetNextSingleSerieUIDFileSet().
The 3 following are not seen by end user :
- Replace the private attribute CoherentFileListHT by SingleSerieUIDFileSetHT
- Replace private typedef CoherentFileListmap by SingleSerieUIDFileSetmap.
- Replace iterator ItListHt by iterator ItFileSetHt
- Keep the public 'FileList' typedef, in order not to break the API
(this -little bit- confusing name should be changed to FileSet : it's not a
std::list, it's a std::vector; user don't care about it, but it's better to
use meaningfull names)
SerieHelper Extention : stage 1
---------------------
In the following stuff, 'XCoherent' stands for 'Extra Coherent',
(The name 'Coherent' would be enough but it was used before;
I don't want to put a bomb in the code)
Any 'better name' is welcome !
Add some methods, to split a 'SingleSerieUID' Fileset into 'Extra Coherent'
FileSets.
They return a std::map of Filesets (actually : std::vector of gdcm::File*)
The key is the 'Orientation', the 'Position' or the 'Tag value'
jpr [Thu, 13 Oct 2005 07:14:45 +0000 (07:14 +0000)]
Add, as a 'Note to developpers' a very detailled post from David Clunie,
on the troubles caused 'non standard' LUT and LUT description
We shall have to take it into accound in our code.
Some day ...