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
DCMTK conflict with PACS system?
Moderator: Moderator Team
-
- Posts: 17
- Joined: Wed, 2005-01-26, 16:43
DCMTK conflict with PACS system?
Last edited by AlreadyGoogled on Sun, 2011-02-13, 00:32, edited 1 time in total.
-
- DCMTK Developer
- Posts: 117
- Joined: Tue, 2004-11-02, 17:21
- Location: Oldenburg, Germany
- Contact:
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.
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.
Who is online
Users browsing this forum: Bing [Bot] and 1 guest