jpr [Tue, 20 Jun 2006 16:26:08 +0000 (16:26 +0000)]
Some more explanations about PMS oddities :
Private Sequences are 'Implicit VR', (and their length is *not* 0xffffffff)
Readers cannot know it's a Sequence; they just read it as a long value.
If we take into account Phillips Intera 'shadow dictionnary', same problem as
for MR_Philips_Intera_Broken.dcm occurs again, *for 2 reasons* :
endianess is swapped inside Private Sequence 2001|105f,
The TS was Implicit VR; it becomes EXPLICIT VR !
jpr [Wed, 15 Feb 2006 13:51:21 +0000 (13:51 +0000)]
This image is not very legal from a DICOM point of view :
The 'public' groups are Explicit VR
The 'shadow' groups are Implcit VR
(Probabely a bug at some write time !)
Since a lot of these 'illegal Dicom' images exist, it's interesting to know if
there are still gdcm-readable.
jpr [Fri, 9 Dec 2005 09:53:44 +0000 (09:53 +0000)]
Standard ACR-NEMA/DICOM straight fashion to store overlays :
In a bytes, 8 pixels are concerned (Overlay Bits Allocated = [1] )
Overlay Data length = 29282 (Overlay Rows * Overlay Columns)/8
D 6000|0010 lg : x(2) 2 [US] [Overlay Rows] [484]
D 6000|0011 lg : x(2) 2 [US] [Overlay Columns] [484]
D 6000|0015 lg : x(2) 2 [IS][Number of Frames in Overlay] [1 ]
D 6000|0022 lg : x(1e) 30 [LO] [Overlay Description] [Siemens MedCom Object Graphics]
D 6000|0040 lg : x(2) 2 [CS] [Overlay Type] [G ]
D 6000|0050 lg : x(4) 4 [SS] [Overlay Origin] [1\1]
D 6000|0051 lg : x(2) 2 [US] [Image Frame Origin] [1]
D 6000|0100 lg : x(2) 2 [US] [Overlay Bits Allocated] [1]
D 6000|0102 lg : x(2) 2 [US] [Overlay Bit Position] [0]
D 6000|3000 lg : x(7262) 29282 [OW] [Overlay Data] [gdcm::NotLoaded]
Get the Data, expand them !
Hope there is never some oddities in Number of Frames in Overlay,
Overlay Origin,Overlay Bit Position, etc .
S 0029|263d lg : x(7088) 28808 [SQ] (starts at offset x(1b4a) 6986 )
there is a 'true length SQItem'
V fffe|e000 lg : x(7080) 28800 [UL] (starts at offset x(1b52) 6994 )
inside, a 'true length' Sequence
S 0029|2a06 lg : x(116) 278 [SQ] (starts at offset x(1bda) 7130 )
inside, a 'true length SQItem'
V fffe|e000 lg : x(2c) 44 [UL] (starts at offset x(1be2) 7138)
that contains ( at offset x(1c02) 7170) the *impossible* tag :
V fffe|0000 lg : x(4) 4 [UL]
It's taken as a group length, some oddities occur, like :
V 0008|0000 lg : x(e000fffe) 3758161918 [UL]
but the parsing goes on, successfully.
jpr [Thu, 25 Aug 2005 16:08:21 +0000 (16:08 +0000)]
Oops again !
David Clunie's image was not fully anonymized (Patient name hidden in a Private
element + Implicit VR)
Now gdcmData *should be* fully anonymized ;-)
jpr [Thu, 25 Aug 2005 15:16:57 +0000 (15:16 +0000)]
Oops!
Patient Name was hidden in a Private 'Bin'Entry.
It's now displayed wiyh the new PrintFile.
--> Remove from the server, anonymize, cvs add -b again
jpr [Tue, 18 Jan 2005 14:46:26 +0000 (14:46 +0000)]
# Multiframe Papyrus format image
# Just to remember this format exists, and is gdcm::Header compliant
# (NOT gdcm::File ...)
# All the necessary fields can be retrieved with low-level
# SeqEntry/SQItem accesors
# Any contribution is welcome
#
# Will be black listed next commit
regrain [Wed, 8 Dec 2004 11:38:59 +0000 (11:38 +0000)]
* Change some Baseline files due to a bug fix in vtkGdcmReader
* Rename SIEMENS_MAGNETOM-12-MONO2-Seq*.dcm
to SIEMENS_MAGNETOM-12-MONO2-FileSeq*.dcm
to be easy found in the directory by a glob search (CMAKE)
-- BeNours