Transcode error using dcmj2pnm

[JustSomeGuy]

I have a dicom file whose transfer syntax is JPEG-LS Lossless 1.2.840.10008.1.2.4.80
I trust that the file is properly encoded, but suspect that dcmj2pnm is having an issue decoding it.
What is the process to get a potential bug in dcmj2pnm fixed?

Code: Select all

$dcmtk: dcmj2pnm v3.5.4 2005-12-20 $

I have a sample dicom file:
https://drive.google.com/file/d/0ByWgZ1 ... sp=sharing

[J. Riesmeier]

The first part of the answer is easy (and should be obvious): dcmj2pnm does not support JPEG-LS compression; you should use dcml2pnm instead.

The second part of the answer is: dcml2pnm cannot decompressed the stored pixel data of this particular image file. The debug output of dcmdjpls is probably more helpful - but only a little:

Code: Select all

D: $dcmtk: dcmdjpls v3.6.1 DEV $
D: 
D: DcmDataDictionary: Loading file: /usr/local/share/dcmtk/dicom.dic
I: reading input file JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm
D: DcmMetaInfo::checkAndReadPreamble() TransferSyntax="Little Endian Explicit"
D: DcmDataset::read() TransferSyntax="JPEG-LS Lossless"
I: decompressing file
D: JPEG-LS decoder processes frame 1
F: Too much compressed data, trailing data after image: decompressing file: JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm

What is the process to get a potential bug in dcmj2pnm fixed?

I guess that the error is with the image file and not with the JPEG-LS implementation that is used by the DCMTK. However, this is something that needs to be checked before we can be sure. If this isn't urgent, I could add a new entry to DCMTK's issue tracker and we'll have a look at it as time permits...

PS: Why are you using DCMTK 3.5.4, which is more than 10 years old? As far as I remember, DCMTK 3.5.4 did not support JPEG-LS at all.

[JustSomeGuy]

As you pointed out using a different executable for this particular file may assist.
However you were unable to decompress it with the executable you recommended.

I hesitated to point fingers at the compressor, but I suppose anything is possible.
It's just that we were told about the error with this transfer syntax and I just created a file with that transfer syntax using Dicom Objects and got the same error.
So I suspect that if two different compressors and the same decompressor give the same error, it is likely the decompressor.

Maybe it's time to get a newer version of dcmtk and build it, as the executables are getting on in age as you pointed out. However I assume you have already done that.
It is of course pretty urgent.

Using 3.6.1 binaries (on a MAC) this is what I now get.

Code: Select all

./dcml2pnm +obt +Ww 1722 2225 -v ~/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm output.bmp
I: reading DICOM file: /Users/bob/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm
I: preparing pixel data
I: Current Frame Number: 0
E: can't change to unencapsulated representation for pixel data
E: can't convert input pixel data, probably unsupported compression
F: Invalid DICOM image

Using 3.6.1 binaries (on a MAC) this is what i was getting using the wrong application.

Code: Select all

./dcmj2pnm +obt +Ww 1722 2225 -v ~/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm output.bmp
I: reading DICOM file: /Users/bob/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm
I: preparing pixel data
E: can't change to unencapsulated representation for pixel data
E: can't determine 'PhotometricInterpretation' of decompressed image
E: mandatory attribute 'PhotometricInterpretation' is missing or can't be determined
F: Missing attribute

Code: Select all

./dcmdjpls -v -d ~/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm test.bmp
D: $dcmtk: dcmdjpls v3.6.0 2011-01-06 $
D: 
I: reading input file /Users/bob/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm
D: DcmItem::checkTransferSyntax() TransferSyntax="Little Endian Explicit"
I: decompressing file
I: Current Frame Number: 0
F: Too much compressed data, trailing data after image: decompressing file: /Users/bob/Downloads/JPEG_LS_Lossless_1_2_840_10008_1_2_4_80.dcm

[J. Riesmeier]

I just tried "dcunjls" from David Clunie's dicom3tools. The error message when trying to decompress your file is: "Corrupt JPEG stream ... expected SOF55 Marker"

Of course, this does not mean that the file is actually broken but... In order to be sure, one needs to analyze the file (the JPEG data stream), which would take some time.

Maybe it's time to get a newer version of dcmtk and build it, as the executables are getting on in age as you pointed out. However I assume you have already done that.

Yes, I used a recent development version of the DCMTK for testing purposes (see debug output with version number "v3.6.1 DEV").

It is of course pretty urgent.

If you cannot wait that somebody from our team has a closer look at this issue (on a "as time permits" basis), you have the following options:

• Check the source code of the DCMTK in order to find out where it fails.
• Find somebody else to do this job for you.
• ...
• Contact me by email and ask for professional support.

[JustSomeGuy]

I suppose I am going to investigate the source data to see that it isn't in error.
I trust your judgement on updating your toolkit at your discretion.
Many thanks for all the tips and advice.

[medconn]

I'm the author of DicomObjects, which generated this file, and I suspect that error may be due to the decompression codecs not recognising and therefore failing at the embedded JPEG "comment" attributes. I know that this is the case for David Clunie's codec, and I'll investigate if the dcmtk/CharLS codec might have the same issue.

I'll post again once I know more.

Dave Harvey
Medical Connections Ltd

[JustSomeGuy]

Thank you Dr. Harvey. I didn't want to point fingers in any direction.

To Offis: Can you tell me how to use movescu or getscu to accept this transfer from the originating machine.
If you will recall the client sent the data our server (into memory) using this transfer syntax and when we tried to decompress it is when we found the codec error.
We asked the client to send us a copy of the data but they sent it to us uncompressed.
I therefore used Dr. Harvey's software which I believe uses David Clunies codec to compress it to the desired transfer syntax as I was trying to validate the dcmtk decompressor.

I would like to use getscu or a combination of movescu and storescp to store it to disk compressed as they sent it. (JPEG-LS Lossless 1.2.840.10008.1.2.4.80)
Am I making sense?

[Michael Onken]

Hi,

For movescu, storescp and getscu see the --prefer options. For JPEG-LS Lossless you should choose --prefer-jls-lossless (or +xt) which is the same in all 3 tools.

If you use movescu in combination with storescp (i.e. without specifying movescu's --port option enabling movescu's internal storage server), you do not need to specify any --prefer option at all since this is negotiated between your server (sending the images) and storescp.

Best,
Michael

[JustSomeGuy]

I now have the original data right off of the PACS to disk without using Dicom Objects to compress it.

click here to download zip file of dicom data

I tried decompressing as you recommended in your first response.

Code: Select all

~/dcmtk-3.6.0-mac-i686-dynamic/bin/dcml2pnm 1.3.12.2.1107.5.3.49.22332.11.201405071004170828 test.pnm
W: unknown value for 'PresentationLUTShape' (2014-05-07 10:04:17) ... ignoring

Which makes sense. As when I dump the dicom meta data this value is indeed in the data but it hardly looks like a LUT to me.
It created pnm file but I couldn't open it.

Code: Select all

~/dcmtk-3.6.0-mac-i686-dynamic/bin/dcmdjpls 1.3.12.2.1107.5.3.49.22332.11.201405071004170828 x.dcm

Worked.

Code: Select all

~/dcmtk-3.6.0-mac-i686-dynamic/bin/dcmj2pnm 1.3.12.2.1107.5.3.49.22332.11.201405071004170828 y.bmp
E: can't change to unencapsulated representation for pixel data
E: can't determine 'PhotometricInterpretation' of decompressed image
E: mandatory attribute 'PhotometricInterpretation' is missing or can't be determined
F: Missing attribute

Perhaps this is fixed in 3.6.1?

[J. Riesmeier]

So everything is now OK: dcml2pnm is able to render the DICOM image and dcmdjpls is able to decompress it.
The tool dcmj2pnm does not work for JPEG-LS (as I said in a previous posting); see documentation for details.
If you want dcml2pnm to create a BMP file (or some other output format) you have to specify this, e.g. "+ob".

[JustSomeGuy]

Many thanks for your assistance in this matter.

We have inadvertently been using dcm2jpnm for converting all our dicom to bmp.
However JPEG-LS Lossless 1.2.840.10008.1.2.4.80 seems to require a different transcoder.

Can you tell me if there are other transfer syntaxes that dcm2jpnm doesn't support?
Does dcml2pnm only support JPEG-LS Lossless 1.2.840.10008.1.2.4.80?

I believe you said that these two applications use the exact same command line parameters. True?

[J. Riesmeier]

What about reading the documentation of both tools?

• http://support.dcmtk.org/docs-snapshot/ ... r_syntaxes
• http://support.dcmtk.org/docs-snapshot/ ... r_syntaxes

Can you tell me if there are other transfer syntaxes that dcm2jpnm doesn't support?

See above referenced documentation of this tool. E.g. JPEG 2000 (all variants) are not supported.

Does dcml2pnm only support JPEG-LS Lossless 1.2.840.10008.1.2.4.80?

Yes, see above referenced documentation. Got it?

I believe you said that these two applications use the exact same command line parameters. True?

This was probably Michael, not me, but it's almost true. There are of course some deviations (different settings that are specific to the particular compression scheme and/or output format).

If you need a single tool that reads all DICOM transfer syntaxes supported by the DCMTK and creates a rendered output in BMP format, you could/should write your own little tool. Shouldn't be too complicated.

[JustSomeGuy]

Support Matrix:
https://drive.google.com/file/d/0ByWgZ1 ... FzY28/view