Compressing 10 bit images

[mukoya]

I have a CR that is storing relatively large images. These need to be pushed to a cloud server and re-downloaded by radiologist for reporting. In low bandwidth scenario here, this is quite a pain with timeouts etc.

It seems JPEG extended codec is only for 8 and 12 bit images. JPEG lossless is not sufficient. I am considering trying J2K.

What would be tha best way to manage this images to get least size?

What about 16-bit.

Can these images somehow be transformed to 12bit?

Of course this is for images where option for 12-bit is not present on the equipment.

Thanks.

[pacsone]

Yes, PacsOne Server supports JPEG2000 compression which will work for all 8-16 bit depth images.

[mukoya]

Thanks for your reply.

The problem I now have is that I cannot get Pacsone to use JPEG2000.

The server forwarding studies to Pacsone (Clearcanvas Image Server 2.0) does not support jpeg2000 and because studies are forwarded via internet, I am using JPEG lossless for 10bit and 16-bit images. Uncompressed would be a challenge over the slow network.

Asking pacsone to compress these lossless images from clearcanvas fails.

Asking pacsone to prefer Explicit VR LE does not seem to work because, i guess, Clearcanvas proposes to send study in its stored Transfer Syntax (JPEG Lossless) and pacsone accepts. This leads to failed compression.


Question: Is there a way to force pacsone to decompress incoming studies and re-compress them to the preferred syntax? Is there a way to disable certain transfer syntax e.g Jpeg lossless in this case, forcing source AE to decompress before sending to pacsone?

Thank you.

[pacsone]

Asking pacsone to compress these lossless images from clearcanvas fails.

Asking pacsone to prefer Explicit VR LE does not seem to work because, i guess, Clearcanvas proposes to send study in its stored Transfer Syntax (JPEG Lossless) and pacsone accepts. This leads to failed compression.

Not sure about what you meant above, i.e., if this ClearCanvas client proposes a particular Dicom transfer syntax and PacsOne Server has accepted that transfer syntax, it is up to this client to select that accepted transfer syntax for the subsequent transfer. So exactly what do you mean by "failed compression"?

[mukoya]

Thank you for your reply,

Your question is valid. It is best if the source AE could send correct syntax in the first place. It is not strictly an issue of pacsone.

I just needed to find out if it were possible to reversibly configure pacsone not to accept a certain T.syntax from a specific AE. That way, The source AE I am using would then decompress the jpeg lossless study and send it uncompressed. There is no option within the source AE to decompress when sending to, say, pacsone once pacsone accepts the default behavior, which is sending study in its current syntax, which is usually JPEG Lossless.

Another option is for pacsone to be able to decompress and then re-compress appropriately whenever it is necessary to compress an already losslessly compressed incoming study.

There are other reasons that make it difficult to store the images uncompressed.

I hope I am making sense here!

Thank you.

[pacsone]

There are 2 possible scenarios with regard to the Dicom transfer syntax selection when a client sends images over to PacsOne Server:

1. The sending client proposes a separate Dicom Presentation Context each with a different Transfer Syntax:

In this case, the client sends a list of Presentation Contexts to PacsOne Server, each with the same Abstract Syntax but a different Transfer Syntax. PacsOne Server will accept all supported transfer syntaxes for each proposed Presentation Context, i.e., in the A-ASSOCIATE-AC message returned to the sending client, PacsOne will return the same list of proposed Presentation Contexts, with the Result field set to Accept for any supported Transfer Syntax, and Reject for any un-supported Transfer Syntax. So in your case, PacsOne will accept both the un-compressed Little-Endian Explicit VR transfer syntax, the JPEG Lossless transfer syntax, as well as the JPEG2000 transfer syntax. So in this scenario, it'll up to the sending AE to select from the list of Accepted transfer syntaxes returned from PacsOne Server, whether it's the un-compressed, JPEG Lossless or JPEG2000 transfer syntax.

2. The sending client proposes a single Presentation Context with the list of Dicom transfer syntaxes:

In this case, PacsOne Server will accept the 1st supported Dicom transfer syntax from the list of proposed transfer syntaxes by default. If you have configured a preferred Inbound (Rx) transfer syntax for the sending client AE, and the preferred transfer syntax is on the list of transfer syntaxes proposed by the sending client, then PacsOne Server will accept that preferred transfer syntax instead of the default 1st supported syntax.

SO in summary, you should check the Dicom Conformance Statement of this sending client, and see how it proposes the Dicom transfer syntaxes when it sends Dicom studies to a remote SCP/Server (1st or 2nd scenario), and if it uses the 1st scenario then how it selects which transfer syntax when a list of Dicom transfer syntaxes are returned by the SCP/Server.

[mukoya]

Thank you for your detailed answer.

Below are the relevant areas from the user manual and conformance statement of the sending server:

When negotiating a DICOM association to send a compressed study to another DICOM application, the ImageServer will propose sending the study in the transfer syntax it is already encoded in. It will also propose an uncompressed transfer syntax for the study. If the compressed transfer syntax is not negotiated, it will automatically decompress the study and send it in the decompressed transfer syntax.


For each SOP Class being transferred, STORAGE-SCU will propose two Presentation Contexts. One
containing the transfer syntax that the SOP class is encoded on for the server, and a second Presentation
Context using the uncompressed transfer syntaxes. When the server cannot decompress an image
because it does not have the appropriate codec(s), the second Presentation Context (uncompressed
syntaxes) is not proposed.

STORAGE-SCU prefers to send each instance using its current Transfer Syntax, and will find the first
Presentation Context where the Transfer Syntax was accepted. In the case where the Transfer Syntax
was not accepted by the remote STORAGE-SCP, STORAGE-SCU will check for the acceptance of
Explicit VR Little Endian and Implicit VR Little Endian, in that order. If STORAGE-SCU cannot change the
Transfer Syntax, the sub-operation will fail and it will not store the instance.

This is what I was hoping to utilize, but once pacsone accepts the lossless syntax, the sending AE happily sends the study without bothering to decompress it, despite the setting in pacsone AE configuration.

This server does not support JPEG2000 and yet that is what I would like pacsone to utilize for at least 10 and 16-bit images. So it will send in jpeg lossless.

It appears that pacsone does not decompress the jpeg lossless and re-compress them as jpeg2000 despite a setting asking pacsone to store images from the particular sending AE in jpeg2000 syntax. Logs show failure to compress. My guess is that compression to jpeg2000 by pacsone would be possible if images are received uncompressed.

There is no setting to select a preferred syntax when sending out studies from this sending AE.

So, that is why I was thinking that if it was possible for pacsone to reject JPEG lossless, the sending AE will then have to decompress and send studies in uncompressed TS, as indicated in the quoted segments of the documentation.

So, well, I guess it is scenario 2. But what happens is that it appears like the sending AE only resorts to sending uncompressed images when the jpeg lossless is not negotiated.

I will try to look for a workaround somehow. I am actively working on this because it is causing issues with teleradiology. I guess this is an isolated case of an a strange feature request probably not needed by a whole lot of pacsone users!

Anyway, thanks, I will keep working on it. May need to install a third party application. I have considered dcm4chee, but this is heavy on resources slows down transmission and introduces another point of possible failure.

regards,

Mukoya.

[pacsone]

According to your posted Dicom Conformance Statement for this sending client, it falls under scenario#1 which proposes a separate presentation context for each transfer syntax, i.e., the 1st presentation context would be the original transfer syntax (compressed or not) in which the Dicom study was encoded, and the 2nd presentation context would be the Dicom default Little-Endian Implicit VR transfer syntax (uncompressed). This sending client will select the 1st accepted presentation context returned by the SCP/Server (PacsOne in this case).

Not sure what you are trying to do, but if the sending client is adhering to its Dicom Conformance Statement, it will propose 2 presentation contexts when sending studies to PacsOne Server: 1st presentation context will contain the original Dicom transfer syntax in which the study was encoded (e.g., JPEG Lossless, etc), while the 2nd presentation context will be the Dicom default Little-Endian Implicit VR transfer syntax. PacsOne Server will accept both proposed presentation contexts and therefore, the sending client will select the 1st accepted presentation context which will be whatever transfer syntax the original Dicom study was encoded in.

[mukoya]

I resolved this issue by routing images via Conquest server.

8 and 12 bit images come directly to pacsone in JPEG lossy syntax.

10 and 16 bit images go via Conquest.

The 16-bit images at the moment are CT and MR. Such images come out with unacceptable artifacts when compressed to j2k by conquest. Conquest therefore has instructions to decompress them from jpeg lossless and forward uncompressed to pacsone. Pacsone does a great job compressing to j2k...if the ratios are right!

10-Bit CR images are, for some reason, unable to be compressed by pacsone. Images are compressed on site by clearcanvas to JPEG lossless (JPEG Extended codec) then sent to cloud. Here the images are decompressed and then re-compressed to j2k by conquest before sending as j2k files to pacsone.

I tried sending these images to pacsone directly uncompressed, but it resulted in 2KB to 24KB j2k images which are then unable to be viewed by mediview. Found this quite interesting!

Thank you very much pacsone for your assistance.

[pacsone]

JPEG2000 compression supports all bit depths including 10-bit, so if you have configured PacsOne Server to apply JPEG2000 compression on received 10-bit images, they should be compressed just fine. If not, you can send us a sample 10-bit image to mailto:pacsone@pacsone.net/u] and we'll check it out.

[mukoya]

I have sent you the sample images,

Thank you.

[Nana111]

HI there
I am a newbie here ,and i have encountered a similar problem .i tried to compress the image using this code:
using System.IO;
using System.Drawing.Printing;
using RasterEdge.Imaging;
using RasterEdge.Imaging.Codec.Compression;

ImageCompression.infile(@"C:\1.tif");
ImageCompression.Outfile(@"C:\2.tif");
ImageEncoder = ImageEncoder.Group3Encoding

RasterEdgeImaging Image = new RasterEdgeImaging();
Image.Image Compression(@"C:\1.tif", "C:\2.tif", ImageEncoder ImageEncoder.Group3Encoding);
But it display nothing.What's wrong with my code?
I have found this code from a google image tool.
Thanks for any suggestion.

[pacsone]

This is a users' forum for PacsOne Server, but the sample codes you posted does not seem to have anything to do with PacsOne Server, so we would not be of too much help for you.