regrain [Thu, 15 Jan 2004 16:36:28 +0000 (16:36 +0000)]
* src/gdcmDicSet.[h|cxx] : add virtual entries to have a reference of
entries created while parsing the header. Thus, they will be destroyed
when the gdcmDictSet will be destroyed
* src/gdcmHeader.cxx, gdcmHeaderEntrySet.cxx : uses virtual entries of
gdcmDictSet
-- BeNours
regrain [Thu, 15 Jan 2004 10:24:24 +0000 (10:24 +0000)]
* vtk/vtkGdcmReader.cxx : bug fix : before, with python only, the program
made a fatal error because of the memory release at the end of program.
The problem was in vtkGdcmReader::ExecuteData where we were allocate
some memory and vtk seems to have some problems with that.
* src/gdcmHeaderEntrySet.cxx : bug fix for std lib and cout
-- BeNours
regrain [Wed, 14 Jan 2004 09:58:37 +0000 (09:58 +0000)]
* src/gdcmHeaderEntry.[h|cxx] : gdcmElValue -> gdcmHeaderEntry
* src/gdcmHeaderEntrySet.[h|cxx] : gdcmElValSet -> gdcmHeaderEntrySet
* src/*.[h|cxx] : make changes due to class name changes
-- BeNours
regrain [Tue, 13 Jan 2004 11:13:07 +0000 (11:13 +0000)]
* src/gdcmDict.cxx, gdcmElValSet.cxx : bug fix under windows for prints.
It's lied to the stl compilation by MSVC (windows, always windows...)
-- BeNours
regrain [Mon, 12 Jan 2004 15:02:19 +0000 (15:02 +0000)]
* src/gdcmDictSet.h : set the method BuildDictPath in public
* src/gdcmTS.cxx, gdcmVR.cxx : use now a dictionnary file other than to be
directly setted in the source code
* Dicts/dicomTS.dic, dicomVR.dic : 2 new dictionnary files loaded by
gdcmTS and gdcmVR
-- BeNours
regrain [Mon, 22 Dec 2003 12:46:14 +0000 (12:46 +0000)]
* gdcmHeader is now aggregating gdcmFile, and not derived into. Thus, we
can use a gdcmHeaderHelper to load datas
* gdcmPython/testSuite.py : make the testSuite compliant with modifications
made in the source code
-- BeNours
malaterre [Thu, 13 Nov 2003 10:37:44 +0000 (10:37 +0000)]
*ENH: Add a setup.py.in that cmake will parse and give the right path to VTK ...
It creates a new setup.py in gdcm${bin}/gdcmPython (in order not to override old setup.py)
jpr [Wed, 12 Nov 2003 15:35:18 +0000 (15:35 +0000)]
*ENH gdcmHeader constructor has one more parameter (default value : false)
that allows the user to 'go inside' the SeQuences only
if he wants to.
gdcmElValSet:Print takes it into account
jpr [Mon, 10 Nov 2003 14:17:12 +0000 (14:17 +0000)]
*FIX : gdcmHeader::LoadElements is now based
on the ListTag listElem member,
not longer on the TagElValueHT tagHt member
*ENH : PrintPubElVal shows (temporarily) both results,
with the tagHt member and the listElem member.
(it's easier to 'see' the problems when using Printheader)
*FIX : old private member LgrElem is now splitted into
ReadLength : Length actually found on disk (updated only
if bug fixing is necessary), for internal
use only
UsableLength : Updated by FixFoundLength, to fix a bug
or to allow Parser going on.
Will allow to re-write a kosher header when a SeQuence
with a length (not 0000) is found
Warning : gdcmFile::Write still uses the TagHt (not ListElem)
because gdcmElValSet::Add does not update ListElem
(to be written)
jpr [Mon, 10 Nov 2003 09:21:40 +0000 (09:21 +0000)]
*FIX : gdcmHeader::LoadElements is now based
on the ListTag listElem member,
not longer on the TagElValueHT tagHt member
*ENH : PrintPubElVal shows (temporarily) both results,
with the tagHt member and the listElem member.
(it's easier to 'see' the problems when using Printheader)
jpr [Fri, 7 Nov 2003 14:34:50 +0000 (14:34 +0000)]
*ENH gdcmHeader::FixFoundLength now allow to 'go inside' tge SeQuences
when they have an actual length (not 0000 nor FFFFF)
(Nobody should care of it, but DICOMDIR explorers)
jpr [Wed, 5 Nov 2003 14:31:00 +0000 (14:31 +0000)]
* Fix :Oops ! Forgot to commit gdcmFile::GetImageDataSizeRaw();
that returns the pixel area size to the *aware* (vtk) user
that DOESN'T want to turn the PALETTE COLOR image into an RGB image
jpr [Mon, 3 Nov 2003 10:49:31 +0000 (10:49 +0000)]
2003-11-03 Jean-Pierre Roux
* add gdcmHeaderHelper::GetNumberOfScalarComponentsRaw()
to be used by aware (vtk) users that want to manage
LUT (and no to turn the PALETTE image into an RGB pixels one)
* GetPixelType now returns 8U for 24 Bits images
(vtkGdcmReader compliant)
malaterre [Fri, 31 Oct 2003 11:29:59 +0000 (11:29 +0000)]
*FIX: VC++ compilation, still for loop dummy stuff
*FIX: alpha start point was not set properly
*ENH: memset default everything to zero (in case lengthR/G/B is < 255)
*ENH: spare a few pointers operations :)
jpr [Fri, 31 Oct 2003 10:38:34 +0000 (10:38 +0000)]
* ENH : Add the functions gdcmFile::GetImageDataRaw
gdcmFile::GetImageDataIntoVectorRaw
that act as GetImageData and GetImageDataIntoVector
except the making of an RGB Plane from Gray Plane + LUT
Intended to aware (vtk) users who know how to manage
such an image :
After gdcmHeader :
GetLUTRGBA return a R,G,B,A LUT if any
lgrTotaleRaw gives the 'Raw' length
GetImageDataRaw returns the gray Plane
* FIX : no more dirty trick for 'Segmented xxx Palette Color Lookup' images
(They stay Grey, just like with other Dicom viewers :-(
* FIX : a VC++ intended syntax modif broke the 12/12 Bytes expanding
jpr [Thu, 30 Oct 2003 17:04:21 +0000 (17:04 +0000)]
2003-10-29 Jean-Pierre Roux
* adding gdcmHeader::GetLUTRGBA
returns a 4 * 256 Bytes Reg/Green/Blue/Alpha vtk compliant LUT
--> Mathieu, the modif u're waiting for is not yet committed
* removal of now useless GetLUTRed,GetLUTGreen,GetLUTBlue,GetLUTRGB
malaterre [Fri, 24 Oct 2003 15:38:56 +0000 (15:38 +0000)]
*ENH: vtkGdcmReader.cxx can now read multiframe dicom
*FIX: remove a call to ->Modified ... see comments
*FIX: vtkgdcmViewer.cxx was writting ASCII file...this is so slooooooow !
projects / gdcm.git / log