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 !
jpr [Tue, 14 Oct 2003 15:39:32 +0000 (15:39 +0000)]
Missing elements added
(just to be affraid : have a look at
ftp://medical.nema.org/medical/dicom/2003/01v03dif/01v03_06.pdf
and do it again next year ;->
jpr [Mon, 13 Oct 2003 13:41:57 +0000 (13:41 +0000)]
According to PS 3.3-2003 C.11.1.1.2 p 619, when each pixel of a PLATTE COLOR
is stored on 2 Bytes, theese 2 Bytes must be equal.
But there are NOT.
It's fixed !