about dicom transfer speed!!

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
mpx1983
Posts: 5
Joined: Sun, 2010-05-02, 04:07

about dicom transfer speed!!

#1 Post by mpx1983 »

i have a task: transfer 2000 CT dicom images in 8 secends in 1G network!

i have tried my best to do this.now the best resualt is 30 secends with multi dicom transfer .

now i have a new thinking : convert the series images of the 2000 dicoms to a dicom-mpeg2 file,so that can decrease the times of parse dicom. and can decrease the size of the total file with inter-frame compress.

do you have other method to do this. help me ,thank you very much.

i will mark and look this topic later~

Per
Posts: 99
Joined: Mon, 2007-09-03, 10:53
Location: Trondheim, Norway
Contact:

#2 Post by Per »

How big is each CT image? If you suppose each is 500k uncompressed (not unusual), then simply applying zip compression would reduce them sufficiently that bandwidth should not be a problem. JPEGLS compression would be even better.

However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.

J. Riesmeier
DCMTK Developer
Posts: 2496
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#3 Post by J. Riesmeier »

However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.
I'm sorry but I don't agree. It's mainly a question of the implementation / configuration. Many systems were not designed for transferring huge amounts of data / objects (sometimes because of historical reasons). E.g. asynchronous communication might be a good idea ...

The following blog posting might be interesting in this context: http://dclunie.blogspot.com/2011/06/fra ... oblem.html

Here's one of the key sentences: "The bottom line is probably that the protocol used is less important than the architecture and implementation details on both end, and in comparing performance claims for specific commercial implementations, one needs to be sure one is comparing apples with apples rather than oranges."

mpx1983
Posts: 5
Joined: Sun, 2010-05-02, 04:07

#4 Post by mpx1983 »

The following blog posting might be interesting in this context: http://dclunie.blogspot.com/2011/06/fra ... oblem.html
sorry,i'm a chinese ,i can't access this website.
perhanps our govement has forbiden this website......

so ,please copy the content of this link to there,i want to look at it .

other,my test dicom images is like these: 512K,512*512, and they will be some huge series . now i got a best test resualt with jpeg-lossless compress and multi-thread-dicom-transfer. but only be in 30 secends. i want to konw how can i transfer these 2000 CT in 8 secends.

J. Riesmeier
DCMTK Developer
Posts: 2496
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#5 Post by J. Riesmeier »

so ,please copy the content of this link to there,i want to look at it .
You should ask the author of this blog post, David Clunie, whether he can send the text to you (email: dclunie/at/dclunie/dot/com). I will not copy the text to this forum because of copyright reasons.
i want to konw how can i transfer these 2000 CT in 8 secends.
I never tried that, but using an asynchronous DICOM communication with an appropriate PDU size and TCP configuration as well as a short list of presentation contexts should be a good starting point. A transparent ZIP compression (Deflated Transfer Syntax) might also be helpful, unless the images are already compressed.

Per
Posts: 99
Joined: Mon, 2007-09-03, 10:53
Location: Trondheim, Norway
Contact:

#6 Post by Per »

J. Riesmeier wrote:
However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.
I'm sorry but I don't agree. It's mainly a question of the implementation / configuration. Many systems were not designed for transferring huge amounts of data / objects (sometimes because of historical reasons). E.g. asynchronous communication might be a good idea
The problem is that the DICOM transfer protocol was not designed in a way that allows you to implement it efficiently. Too many useless layers of abstraction getting in the way. On a modern OS, you will want to try very hard to utilize zero-copy semantics to avoid moving buffers around and stream everything in as few operations as possible. DICOM, however, really wants everything hacked into arbitrary pieces and encourages re-conversion rather than a streamlined workflow. (Who thought it was a good idea to add a packet interface on top of a stream-oriented protocol (TCP), when you want to interpret it as a stream again on receipt anyway?)

What does all the abstraction buy you in the end? There is no support for transactions, caching, redirection, authentication, or load balancing. Reporting and error handling is anywhere from weak to non-existent.

Sorry about the rant. I have been experimenting a bit with the protocol lately, and it has not been pleasant ;-)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest