dcmcjpeg quality parameter

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
cmerrick02
Posts: 5
Joined: Tue, 2023-05-30, 11:40

dcmcjpeg quality parameter

#1 Post by cmerrick02 »

Hello all. I'm having an issue storing an image to a PACs system, in which the node sending to only accepts Little endian explicit or JPEG Baseline process 1 transfer syntaxes.

We currently have the images in little endian explicit, but the target PACs is not accepting it, we believe the issue to be in the pixel data. Compressing the image using dcmjpeg to JPEG baseline (1.2.840.10008.1.2.4.50), I'm able to store the image into the new PACs. However, we are aware this is a lossy compression and some fidelity may be lost. Which brings me to my question - if setting the quality parameter to 100 and JPEG Baseline lossy compression, does this technically mean it is not lossy? Are we safe to assume we're not losing any pixel data using +q 100?

Thank you for any help.

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#2 Post by Michael Onken »

Hi,

setting quality factor to 100 will not make JPEG Baseline lossless. Probably it's better to fix the source image. Also maybe the problem in the image is just disguised by applying JPEG Baseline transfer syntax, so you might store "garbage" to your PACS as well. Does dcmcjpeg gives some hints (warnings) on what the problem with the file might be? You can also check the original file using the dciodvfy tool from dicom3tools.

If the basic DICOM encoding is broken but DCMTK can parse the file, you could also try to repair that by using dcmconv, just run

Code: Select all

dcmconv <input_file> <output_file>
and check whether the output file can be transferred to the PACS then.

Best regards,
Michael

cmerrick02
Posts: 5
Joined: Tue, 2023-05-30, 11:40

Re: dcmcjpeg quality parameter

#3 Post by cmerrick02 »

Thanks for the quick response, Michael. This one has me scratching my head!

Running dcmcjpeg with verbose and debug on, no errors or warnings seen.

We did verify the images with a couple of validators including the dciodvfy. There are some errors/warnings, but nothing different from other images that are storing with the same SOP class and transfer syntax. The problem images are all coming from a specific modality. I've also compared the results of dciodvfy between the original image and the compressed JPEG baseline image that does store, but there are no differences.

One thing we noticed was an error message from another validator stating "Pixel Data has a VR 'OW'. The VR 'OB' would have been more relevant since Bits Allocated is less or equal to 8". I noticed when using dcmcjpeg to compress, it did change the Pixel data to a sequence and used OB instead of OW.

Thank you for the tip on the dcmconv. I did try that just now, but still unable to push to the target system.

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#4 Post by Michael Onken »

Hi,

yes the OW/OB issues points at some unusual pixel data setup used. You can try the following to fix it:

Use dcmcjpeg <input_file> <output_file> to create JPEG lossless, and then dcmdjpeg <output_file> <result_file> to decompress it again (thus not loosing quality). IIRC DCMTK will then use only use as many bits (i.e. 8) as required by the pixel data, and then also choose VR = OB. At least worth trying.

Note that compressed data always has VR=OB, while uncompressed may have OB or OW.

Best,
MIchael

cmerrick02
Posts: 5
Joined: Tue, 2023-05-30, 11:40

Re: dcmcjpeg quality parameter

#5 Post by cmerrick02 »

Thanks again, Michael.

Great thoughts. I'm attempting this process of compressing to a lossless format, but I'm unable to get the "OB" VR for PixelData when uncompressing back to Little Endian with dcmdjpeg. With the Lossless (+e1 or +el), the new image does contain OB as the VR for that tag. I'm seeing in dcmdjpeg using (-u) should convert to OB. Is this correct? Or is there another tool I can utilize to change this?

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#6 Post by J. Riesmeier »

One thing we noticed was an error message from another validator stating "Pixel Data has a VR 'OW'. The VR 'OB' would have been more relevant since Bits Allocated is less or equal to 8".
If the Pixel Data is uncompressed, a VR of OW would also be appropriate for Bits Allocated = 8 (see DICOM PS3.5 Section 8.2).

By the way, did you already try to use the DICOM Default Transfer Syntax, i.e. Implicit VR Little Endian (ILE)?

cmerrick02
Posts: 5
Joined: Tue, 2023-05-30, 11:40

Re: dcmcjpeg quality parameter

#7 Post by cmerrick02 »

Thank you for the clarification and direction to the DICOM Standard, J.

I did just do an attempt converting it to ILE (1.2.840.10008.1.2), converts file successfully, and is viewable in MicroDICOM, but I can't get it to store to the target still. Thank you for the suggestion, though. I'm up to try anything at this point :shock: . I know we're drifting away from the initial question I had, and the issue I'm having isn't related to any of the DCMTK tools, so I may end up moving this to a more generic forum if I/my team can't work out the issue soon. Thank you all for the suggestions and tips!

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#8 Post by Michael Onken »

Hey Jörg, the issue was not whether it is appropriate or not but that it might be reason that the PACS does not digest it. Also OP noted that the PACS only supports LEE and JPEG Baseline.

Cmerrick: You understood correctly, I dont have any other tool in mind. But, since Jörg brought this up, I also wondered that the receiver does not handle default transfer syntax as well.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#9 Post by J. Riesmeier »

If the PACS does not accept uncompressed Pixel Data with a VR of OW or does not accept ILE (if proposed by the SCU, and there is no other option for the respective SOP Class), it would violate the DICOM standard.

To the OP: Do you have a log of the network negotiation? By the way, do you use DCMTK's storescu or dcmsend for sending the SOP Instance? And, did you already check the DICOM Conformance Statement of the PACS?

To Michael: Did you already give "dcmscale +Sxf 1 input.dcm output.dcm" a try?

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#10 Post by Michael Onken »

Nope, good idea, I never used dcmscale myself actually :D

cmerrick02
Posts: 5
Joined: Tue, 2023-05-30, 11:40

Re: dcmcjpeg quality parameter

#11 Post by cmerrick02 »

I do, and just for correction, the conformance statement accepts the following Transfer Syntaxes

1.2.840.10008.1.2 Implicit VR Endian: Default Transfer Syntax for DICOM
1.2.840.10008.1.2.1 Explicit VR Little Endian
1.2.840.10008.1.2.2 Explicit VR Big Endian
1.2.840.10008.1.2.4.50 JPEG Baseline (Process 1)

Sorry for that misunderstanding.

We are using DCMTK's storescp when retrieving the images from the Source PACs. They are viewable in Microdicom and we can send the images to other test devices. But even those devices (Known to fix some issues when sending in/out), won't send to the desired location. The files are all dicom compliant for the target pacs (correct transfer syntax, photometric for this SOP Class UID). We are using an already existing app to send the images which is utilizing DCM4CHE's send method. We did try to send using DCMTK's toolset as well.

The error on the receiving PACs does not point to a specific tag but says "MCdata.data must contain an even number of bytes > zero". And the error occurs within writing the first 24 bytes of the file to STS. We went through the DICOM header by header, but there is nothing that is an odd length or zero bytes. I have ran into issues with other devices making DICOM with odd bytes and fixing those files by adding a null byte, but this does not seem to be the case. Additionally, these problem images are all coming from one ultrasound modality, so we believe it's an issue with that. The fact that we can store the images in JPEG Baseline fine, makes me believe the issue is within the Pixel Data.

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: dcmcjpeg quality parameter

#12 Post by Michael Onken »

Hm, this sounds like a weird problem. Using a DCMTK tool to re-write the file (dcmconv, or dcmcjpeg+dcmdjpeg, or dcmscale) should rule out any simple encoding errors (like odd length) already. Maybe you need to talk to the vendor support of the target location or get better logs from the server.

BR, Michael

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest