Decoding JPEG Lossless, Non-hierarchical, 1st Order Prediction

[petr....@gmail.com]

Hi all,

I started use your great library, version 1.1 and it mostly works great. However there are several dicom files that can't be decoded (retrieved via C-STORE)

I found this image for testing http://barre.nom.fr/medical/samples/files/CT-MONO2-16-chest.gz (ungzipped of course)
I'm sending this file to your example application C-STORE SCP with tool from dcmtk-3.6.0-win32-i386 package.
I'm sure Dicom.Native.DLL is loaded and JPEG Lossless is presented

Searching D:\....\bin\x86\Release\Dicom.Native*.dll for Dicom codecs
Codec: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression
Codec: JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12Bit Image Compression (Process 4 only)
Codec: JPEG Lossless, Non-Hierarchical (Process 14)
Codec: JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression
Codec: JPEG 2000 Image Compression (Lossless Only)
Codec: JPEG 2000 Image Compression
Codec: JPEG-LS Lossless Image Compression
Codec: JPEG-LS Lossy (Near-Lossless) Image Compression
Codec: RLE Lossless

However transfer ends unsuccessfully - see log from dcmtk

XMIT: W: DIMSE Warning: (STORESCU,ANY-SCP): sendMessage: unable to convert dataset from 'JPEG Lossless, Non-hierarchical, 1st Order Prediction' transfer syntaxto 'Little Endian Explicit'


My questions are:

- do I something wrong or this codec is not fully supported or sended file have some quirks?
- can I request to transcode image on sender? (can be even to loss codec)
- can I retrieve DICOM file even if some error occur - for later investigation/evidence?
- what event is raised if such error happened and is there any detail message? OnReceiveAbort has Source=Unknown & Reason=Unspecified

Thanks and hope one day I could contribute :)
Petr

[Anders Gustafsson Cureos AB]

Hi Petr,

- If I am not mistaken, you need to tell the DCMTK server to accept images of the format you are sending them in. To double-check that the problem is not with fo-dicom, you could try to start the fo-dicom C-STORE SCP sample application to see if this server accepts the format you are sending.

- Yes, you can convert the image to any format before sending. An example is given here on the Github README page.

- Regarding retrieving erroneous files; are you asking if the DCMTK C-Store SCP application can retrieve? As far as I know, this application will reject, but maybe there are ways to temporarily store invalid files. I recommend that you consult the DCMTK for more information on this.

- Regarding the error reporting, could you share the client code you are using?

Generally, I recommend that you give version 2.0 a try. It is still in pre-release, but it should be fairly stable and it contains a lot of bug fixes on parsing etc.

Regards,

Anders @ Cureos

[petr....@gmail.com]

Hi Anders,

I'm sorry for my misleading description. DCMTK is sending part and fo-dicom is receiving. I'm trying to build some automatic logging solution on top of fo-dicom, however I received some announcements that some files are not being received by my app (fo-dicom library). Mainly lose less JPEG. So I tried to send one and I randomly choose DCMTK as sending app.

So my questions actually were:

- can receiving part (fo-dicom lib) request sender to transcode picture to some other format? Or send it without picture?
- can I detect with fo-dicom that error occur during DICOM transmission or later during decode and can I save that "faulty" file for later investigation (without decoding, just as a binary file) ?
- what event is raised in fo-dicom if such error happened and is there any detail message? OnReceiveAbort has Source=Unknown & Reason=Unspecified

Thanks
Petr

[Anders Gustafsson Cureos AB]

Hi again Petr,

When you talk about receiving part as the fo-dicom lib, what are you actually referring to then?

In the samples in the repository, there is a C-Store SCP application, is this the software you are using? You should be able to fine-tune this application to suit at least some of your needs.

- You should be able to control which image formats to support. As it is right now, I believe that the application accepts all compression formats. I am not sure if the sender can ask in beforehand which if a specific format is supported, maybe someone else has an answer to that?

- In the OnCStoreRequest event handler, you are able to make decisions about the incoming file, for example to store it temporarily for later validation.

- In that same method you should be able control the response based on your initial validation of the incoming file.

Regards,

Anders