DCMTK conflict with PACS system?

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
AlreadyGoogled
Posts: 17
Joined: Wed, 2005-01-26, 16:43

DCMTK conflict with PACS system?

#1 Post by AlreadyGoogled »

Hi all,

I'm trying to push images to a PACS server with STORE-SCU, but
cannot push some select images. The PACS administrator at that
site said to try:

1) disabling store commit in the C-STORE messages.
2) Some of the images I am trying to send have a header that is too long.
3) The header length must be an even number.

I don't see any command line options related to these suggestions
in the STORE-SCU application regarding #1, and I doubt #2 & #3
have anything to do with DCMTK but if anyone has an idea what they
mean or how I could fix it that would be great,

Thanks
________
MARIJUANA DISPENSARY
Last edited by AlreadyGoogled on Sun, 2011-02-13, 00:32, edited 1 time in total.

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#2 Post by Thomas Wilkens »

Regarding storage commitment, please note that this DICOM service is totally independent from the DICOM storage service. In other words, there is no such thing as a storage commitment request in C-Store messages.

The DICOM storage service is only meant to transmit DICOM objects over a network connection and uses C-Store (request and response) messages. The DICOM storage commitment service is only meant to request a confirmation for the persistent storage of objects that have previously been transmitted through the DICOM storage service, and it uses N-Action (request and response) as well as N-Event-Report (request and response) messages.

These two services are strictly separated.

Regarding your PACS administrators comments "the header is too long" or "the header length must be an even number", I don't really know what he means by that. Only the latter comment kind of makes sense, because all attributes in a DICOM file must have an even length in the value field, and since tag, VR and length field are also coded with an even number of bytes, the entire DICOM object should be coded with an even number of bytes.

One thing you could try is to push the images in question with storescu to storescp, a command line tool that is also contained in DCMTK 3.5.3. storescp implements a server for the DICOM storage service, i.e. an application which receives DICOM objects over a network connection, just like a PACS does.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest