ProgressBar c-move

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
geke
Posts: 6
Joined: Mon, 2017-07-17, 15:33

ProgressBar c-move

#1 Post by geke »

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?

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: ProgressBar c-move

#2 Post by Michael Onken »

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

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

Re: ProgressBar c-move

#3 Post by geke »

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

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: ProgressBar c-move

#4 Post by Michael Onken »

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.

Post Reply

Who is online

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