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 ...
jpr [Tue, 11 Oct 2005 08:55:58 +0000 (08:55 +0000)]
The way we dealt with 16 bits 'Pixel Data' on Big Endian processors
*looked* us very clever.
but it does exactly the opposite of what we expected.
(i.e. we get the the result we were affraid to obtain
*without* our clever stuff :-( )
Since I've no access for the moment to a big endian proc
I comment it out, to see the result on the dash board