GE PATHSPEED 7.12 Proprietary Compression

[angad]

Hi All,

I have some dataset from GE PATHSPEED 7.12 and i need to parse those files.

DCMTK loadFile() API is returning me following error :

PixelData (7fe0,0010) larger (5841768) than remaining bytes in file.

I google it and found that GE PATHSPEED 7.12 PACS have some proprietary compression techniques.

Can any one in this forum have any idea how to parse these files ?

If sample DICOM file is required, please let me know.

Any help will be highly appreciated.

Thanks,
Angad Nath

[angad]

Hi All,

Any luck with my last post. Still waiting for response,

Thanks,
Angad Nath

[J. Riesmeier]

As long as the transfer syntax of this file is a standard one, GE should not use any proprietary compression technique for the Pixel Data (7fe0,0010) element. So I guess that the encoding of the data element(s) is incorrect.

Could you make a sample file available for download?

[angad]

Hi J. Riesmeier,

Thanks alot for your reply.

I have mailed you the sample DICOM file at following email id: dicom/at/offis/dot/de.

Can you please check and let me know what is the problem with this file.

Thanks in advance!!!!


Thanks,
Angad Nath

[J. Riesmeier]

Using the current version of dcmdump (from DCMTK development version 3.6.1), I don't get any errors or warnings.

However, the Pixel Data (7fe0,0010) element seems to have too less data: 2494 * 2048 * 2 = 10,215,424 != 5,841,768

Also the VR of the Pixel Data (7fe0,0010) is wrong: it should be OW instead of OB for Bits Allocated (0028,0100) > 8.

Here's the output of dcm2pnm:

Code: Select all

$ dcm2pnm -d -im -o DICOMc.dcm 
D: $dcmtk: dcm2pnm v3.6.1 DEV $
D: 
D: DcmDataDictionary: Loading file: /usr/local/share/dcmtk/dicom.dic
I: reading DICOM file: DICOMc.dcm
D: DcmMetaInfo::checkAndReadPreamble() TransferSyntax="Little Endian Explicit"
D: DcmDataset::read() TransferSyntax="Big Endian Explicit"
I: preparing pixel data
D: transfer syntax of DICOM dataset: Big Endian Explicit (1.2.840.10008.1.2.2)
W: invalid value for 'BitsAllocated' (16), > 8 for OB encoded uncompressed 'PixelData'
D: reading uncompressed pixel data completely into memory
D: convert input pixel data: case 4 (general)
D: setting number of pixels to be processed (PixelCount) to: 2920884
D: determining minimum and maximum pixel values for input data
D: using optimized routine with additional LUT
D: found 'RescaleSlope/Intercept' on main dataset level
D: detach pixel data
W: computed (5107712) and stored (2920884) pixel count differ
I: dumping image parameters
I:   filename            : DICOMc.dcm
I:   transfer syntax     : Big Endian Explicit
I:   SOP class           : ComputedRadiographyImageStorage
I:   SOP instance UID    : 1.3.51.5155.1279.20020206.1103908.1.0.1
I:   columns x rows      : 2048 x 2494
I:   bits per sample     : 12
I:   color model         : MONOCHROME1
I:   pixel aspect ratio  : 1.00
I:   number of frames    : 1
I:   VOI LUT function    : <default>
I:   VOI windows in file : 1
I:   - <no explanation>
I:   VOI LUTs in file    : 0
I:   presentation shape  : <default>
I:   overlays in file    : 0
I:   maximum pixel value : 4095
I:   minimum pixel value : 0
I: cleaning up memory

[angad]

Hi J. Riesmeier,

The sceanriou is : we are working on an inquiry where we have to migrate the data from old GE PACS (pathspeed). The archived data is in PLASOM MODs (5.25 inch) with 5.4GB capacity.

The client has given us 2-3 MODs and asked us to demonstrate the capability for data migration.

We are able to read the files from MODs (which are DICOM format). We can see the DICOM header properly, but Pixel Data is in some proprietary format.

May be GE has applied some proprietary format.

Can you please check what all they can do ? It will be great help if you can give me any directions.

Thanks in advance !!!!

Thanks,
Angad Nath

[J. Riesmeier]

As I said, this DICOM image does not conform to the DICOM standard, because the Pixel Data is not encoded according to the Transfer Syntax specified in the file meta information header (i.e. Explicit VR Big Endian). In other words, it's a violation of the DICOM standard and GE should not claim this to be a DICOM file.

If GE wanted to store a proprietary compression in a DICOM CR image, they should have used a private Transfer Syntax for this purpose.

[angad]

Hi J. Riesmeier,

Sorry for late responding.

As you mentioned in your last post, that the Pixel Data is not encoded according to the transfer Syntax specified in the file meta information header.

Can you please help me to figure out in which format they have encoded Pixel Data ?

I know that these DICOM files are not according to DICOM standards, but still we have to crack it( i have no other option).

It will be great help if you can help me to figure out Pixel Data encoding format.

Is it possible using DCMTK libraries to change file meta information header ? i have tried but nothing works for me.

Thanks in advance !!!!

Thanks,
Angad Nath

[J. Riesmeier]

Can you please help me to figure out in which format they have encoded Pixel Data ?

I'm sorry, but I have no idea. You could either ask GE directly or start a research on the Internet...

Is it possible using DCMTK libraries to change file meta information header ? i have tried but nothing works for me.

Yes, it is possible but not with dcmodify as you can read in the documentation.

You could either write a small C++ program for this purpose, or you could use dcmdump/dump2dcm or dcm2xml/xml2dcm, respectively.