[SOLVED] DICOM C_MOVE with gdcm's "CompositeNetworkFunctions"

DICOM C_MOVE with gdcm's "CompositeNetworkFunctions"

I am trying to get DICOMS from a server using gdcm's CompositeNetworkFunctions. My test server is set up using "Orthanc".

When I run the Move request, I get:

terminate called after throwing an instance of 'gdcm::Exception'

what(): /home/myname/Builds/GDCM/Source/Source/Common/gdcmException.h:74 ():

When I catch that Exception, I find that it is an "unhandled exception", no more info. So instead of catching it, I run the program using gdb. Here's what I get:

0x00007ffff3e4dcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff3e4dcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff3e510d8 in __GI_abort () at abort.c:89
#2  0x00007ffff44526b5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff4450836 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff4450863 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff4450aa2 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x0000000000781772 in std::istream& gdcm::DataSet::ReadWithLength<gdcm::ExplicitDataElement, gdcm::SwapperNoOp>(std::istream&, gdcm::VL&) ()
#7  0x00000000007cd268 in gdcm::network::PresentationDataValue::ConcatenatePDVBlobsAsExplicit(std::vector<gdcm::network::PresentationDataValue, std::allocator<gdcm::network::PresentationDataValue> > const&) ()
#8  0x00000000007d6af1 in gdcm::network::ULConnectionManager::RunEventLoop(gdcm::network::ULEvent&, gdcm::network::ULConnection*, gdcm::network::ULConnectionCallback*, bool const&) ()
#9  0x00000000007d5190 in gdcm::network::ULConnectionManager::RunMoveEventLoop(gdcm::network::ULEvent&, gdcm::network::ULConnectionCallback*) ()
#10 0x00000000007d4acf in gdcm::network::ULConnectionManager::SendMove(gdcm::BaseRootQuery const*, gdcm::network::ULConnectionCallback*) ()
#11 0x00000000007c1750 in gdcm::CompositeNetworkFunctions::CMove(char const*, unsigned short, gdcm::BaseRootQuery const*, unsigned short, char const*, char const*, char const*) ()
#12 0x0000000000666c5c in PACSCMove::run (this=0x25a9dd0) at /home/myname/Projects/Hiwi/Source/src/PACSCMove.cpp:67
#13 0x00007ffff4798384 in ?? () from /home/myname/Qt/5.4/gcc_64/lib/libQt5Core.so.5
#14 0x00007ffff70fa182 in start_thread (arg=0x7fffd8cf5700) at pthread_create.c:312
#15 0x00007ffff3f1147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Here's my code:

mQuery.InitializeDataSet( mQueryLevel );
setSearchParameter( gdcm::Tag( 0x20, 0x000d ), studyUID.toStdString() );    // Study UID
setSearchParameter( gdcm::Tag( 0x20, 0x000e ), seriesUID.toStdString() );   // Series UID

std::cout << "New Move Query: " << mQuery.ValidateQuery(true) << std::endl;


mQuery.WriteQuery("MoveQuery.dcm");


bool res = gdcm::CompositeNetworkFunctions::CMove(
                "localhost", 4242,
                &mQuery,
                11110,
                "IMHOTEP",
                NULL,
                "/home/myname/TestPatient" );

mQueryLevel is gdcm::eSeries

The interesting thing is that with the written Query File "MoveQuery.dcm", I can download the file just fine using movescu:

movescu -v -p -aet IMHOTEP -od /home/myname/TestPatient/ --port 11110 localhost 4242 MoveQuery.dcm

I've tried:

Different values for AET and CALL
Relative and absolute paths
Different ports (although that shouldn't be it - my movescu call uses the same ports, after all!)
mQuery is currently of type gdcm::MovePatientRootQuery, but I've tried MoveStudyRootQuery, FindPatientRootQuery, FindStudyRootQuery
Diving into the GDCM code, following the stacktrace - but I don't understand enough of what's going on
Adding the value for "PatientID" to the query as well, or only supplying the "SeriesUID" (same result)

With PatientID also added to the query, here's the contents of the MoveQuery.dcm:

$ dcmdump MoveQuery.dcm 

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Unknown Transfer Syntax

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0008,0052) CS [SERIES]                                 #   6, 1 QueryRetrieveLevel
(0010,0020) LO [4589301]                                #   8, 1 PatientID
(0020,000d) UI [1.2.840.113619.2.55.1.1762893669.2104.1060778173.267] #  52, 1 StudyInstanceUID
(0020,000e) UI [1.2.840.113619.2.55.1.1762893669.2104.1060778173.271] #  52, 1 SeriesInstanceUID

Solution

C-GET service is not retired in DICOM standard. C-GET uses the same connection to retrieve the image from SCP but C-MOVE uses a parallel connection where server switches its role to SCU (client) and will try to connect to move Destination AE (destination server). In this case, you need to have a DICOM listener (SCP) on your side to handle incoming connection.

I think you are saying Calling AE Title (C-Move service requester) is "IMHOTEP" and you should have a DICOM listener listening on port “11110”. You are requesting Remote AE “ORTHANC” (Called AE) to move the series to C-Move Destination AE ( this should be your side DICOM listener (SCP) that is "IMHOTEP").