DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Sun, 2017-12-17, 03:27

All times are UTC + 1 hour




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: ProgressBar c-move
PostPosted: Thu, 2017-08-10, 10:03 
Offline

Joined: Mon, 2017-07-17, 15:33
Posts: 6
Hello,

I have C-Move implementation which is based on the DcmSCU example:

http://support.dcmtk.org/redmine/projec ... wto_DcmSCU

and would like to add a progess bar for a single image. I know that i can get the number of images received via remaining sub ops, but that is not what i want - I want the progress of an single image transfer. The bytes received are available but i dont know how to get the total size of the received dataset. how can i get the total size of the received dataset?


Top
 Profile  
 
 Post subject: Re: ProgressBar c-move
PostPosted: Thu, 2017-08-10, 10:36 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1650
Location: Oldenburg, Germany
Hi,

You need the size of the dataset being transferred beforehand, however, that size is never explicitly sent by the Storage SCU. Actually, using undefined length encoding and / or compressed Pixel Data with empty offset table the sender may not even know or compute that size beforehand but encodes or recodes while sending.

So there is no exact solution to this problem.

You could introduce estimates for certain modalities, since you can assume typical sizes of some modalities (eg MG will be larger than a classic CT), maybe even based on specific machines in your lab (ie take the ae title into account) but that is all just good guessing.

Best,
Michael


Top
 Profile  
 
 Post subject: Re: ProgressBar c-move
PostPosted: Fri, 2017-08-11, 11:54 
Offline

Joined: Mon, 2017-07-17, 15:33
Posts: 6
Hello Michael,

That is what i was expecting from my reading before - just wanted to make it clear that i dont have missed anything.

I use only uncompressed DX images. For this use case a rough estimate based on the image size (Which i can get from the sendFINDRequest() call before doing the move) might be possible for me. The other data in the dataset is mostly minimal compared to the image.

How can i make sure that no compression happens during the network transfer:

I already use this function from the examples, but to be true not really understand what happens there: Is UID_LittleEndianExplicitTransferSyntax uncompressed and UID_LittleEndianImplicitTransferSyntax compressed?

static Uint8 findUncompressedPC(const OFString& sopClass, DcmSCU& scu)
{
Uint8 pc;
pc = scu.findPresentationContextID(sopClass, UID_LittleEndianExplicitTransferSyntax);
if (pc == 0)
pc = scu.findPresentationContextID(sopClass, UID_BigEndianExplicitTransferSyntax);
if (pc == 0)
pc = scu.findPresentationContextID(sopClass, UID_LittleEndianImplicitTransferSyntax);
return pc;
}

Also i have seen "setDatasetConversionMode( OFalse )" which is by default uncompressed.

Greetings Gerd


Top
 Profile  
 
 Post subject: Re: ProgressBar c-move
PostPosted: Fri, 2017-08-11, 13:11 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1650
Location: Oldenburg, Germany
Hi Gerd,

All three posted transfer syntaxes are uncompressed. So per default DcmSCU (as well as the storescp by the way) only send uncompressed. Since DcmSCU in the MOVE scenario only sends the C-MOVE Request (which does not contain pixel data at at all), nothing else makes any sense.

The PACS, that then does start the storage connection to your storage receiver (storescp?) in order to send the requested images, proposes any transfer syntaxes (=encoding) that it likes. Your storage receiver (storescp) now can select from the proposals the one that it prefers. The PACS has to at least propose Little Endian Implicit, the DICOM default transfer syntax (one of the 3 uncompressed). So you can always expect to force the sender on disabling compression*. storescp, as a storage receiver, actually only accepts uncompressed transfer syntaxes per default which can be changed by its various --prefer-xxx options.

HTH,
Michael

* There is one exception: If the original image data is lossy compressed (e.g. MPEG4 video, or JPEG Lossy from a standard digital camera) then it must not offer an uncompressed transfer syntax.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC + 1 hour


Who is online

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


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group