problems reading DICOMs
mauro
I got a problem reading DICOMs from a CT scans.
The images come directly from the CT scans, without the .dcm
extension.
I assume they are DICOM, since I can read the header with the program
dicom2, and I can successfully anonymize them with "DICOM Anonymizer
Light", but I cannot open/see the images with any program I know: i.e.
I tried ITK-snap, imagej, and also dicom2 is unable to convert the
files.
I'm clueless.
In a first stage I was thinking to a kind of encryption, but actually
the header is totally clear, with even the name of the patient
visible. Raw data? I don't think so: IMG Window Center and Width are
setted, also the values of "IMG Rows" and "IMG columns" are setted.
In the other hands, from the proprietary software (Philips) it is
possible to see the images.
I'm driving crazy, anyone else encountered a similar problem?
cheers,
Mauro
Mathieu Malaterre
Hi Mauro,
You are dealing with the well-known ELSCINT LOSSLESS compressed
image. One way to recognize them (eventhough they are incorrectly
reported as 1.2.840.10008.5.1.4.1.1.2 [CT Image Storage]), is to
check for the presence of 7fe0,0010: the Pixel Data element. It is
missing from your image, but instead you can find a data element
(07a1,100a) which AFAIK is the place holder for the compressed Pixel
Data bytes.
I was about to recommend you to either:
1. Ask your PACS admin to correctly export the image via the console,
so that you get a correct (conforming) DICOM file
2. If you are stuck and have no access to the console, you have some
intermediate solution like TomoVision
HTH
-Mathieu
Ps: it is actually a pain to recognize them, but I'll try to fix ITK-
snap which is underneath calling GDCM so that at least we report a
meaningful error message.
mauro
first of all, thanks for the useful information!
> 2. If you are stuck and have no access to the console, you have some
> intermediate solution like TomoVision
this is exactly my case. TomoVision is an excellent program, it
recognize the ELSCINT LOSSLESS, but unfortunately it actually doesn't
recover my images.
Do you have any clue about other solutions? I also unsuccessfully
tried xmedcon...
> Ps: it is actually a pain to recognize them, but I'll try to fix ITK-
> snap which is underneath calling GDCM so that at least we report a
> meaningful error message.
indeed ;-)
cheers,
Mauro
Mathieu Malaterre
> Hi Mathieu,
> first of all, thanks for the useful information!
>
> > 2. If you are stuck and have no access to the console, you have some
> > intermediate solution like TomoVision
>
> this is exactly my case. TomoVision is an excellent program, it
> recognize the ELSCINT LOSSLESS, but unfortunately it actually doesn't
> recover my images.
> Do you have any clue about other solutions? I also unsuccessfully
> tried xmedcon...
xmedcon is open source and as such does not have access to the
proprietary information required to decompressed the binary blob at
element with tag (07a1,0a,ELSINT1)
You need to wait for Yves to give a complete answer, but it looks like
that this is not a true 'LOSSLESS RICE' image as I have previously
seen, look carefully at the header and you'll see that element with
tag (07a1,11,ELSCINT1) is in fact PMSCT_RLE1 (which I have never seen
before).
...
(07a1,0010) LO [ELSCINT1] #
8,1 Private Creator
(07a1,100a) OB 5a\92\00\ef\9b\e4\00\00... # 1316426,1 Tamar
Compressed Pixel Data
(07a1,1010) LO [3.5 ] #
4,1 Tamar Software Version
(07a1,1011) CS [PMSCT_RLE1] #
10,1 Tamar Compression Type
(7fdf,0010) LO [ELSCINT1] #
8,1 Private Creator
(7fdf,10f0) OB (no value) #
0,1 ?
(7fdf,10ff) SH (no value) #
0,1 ?
HTH
-Mathieu
Yves Martel at
I just added your Philips compression format to my programs. You can
now use TomoVision to display the images and DICOMatic to convert them
to normal (uncomressed) DICOM.
Merci,
Yves
Mathieu Malaterre
GDCM 2.x now also supports this image. this will be part of the GDCM
2.0.5 release.
-Mathieu